The Biggest Cost You Never Think About
The Biggest Cost You Never Think About
Project hold-ups cost a huge amount of time and money for consultants. You can use our tactics here to tackle many of them proactively. Better client relationships and quicker turnaround awaits!
Hi, I’m Richard Millington. Welcome to my consultancy newsletter. Please subscribe to discover our systems for scaling your consultancy practice to $1m+ in revenue.
The Real Cost Of Project Bottlenecks
I suspect many consultants grossly underestimate the cost of bottlenecks.
This is when a project gets held up because of an unforeseen situation.
This is costly for several reasons.
You’re not getting paid until the project is complete. While it’s lovely to get paid in advance, most consultants get paid a 50/50 before/after split (watch those acceptance clauses) or paid upon completion. Every extra day the project is delayed is a risk that you won’t be paid. Sudden budget cuts, your main sponsor leaving, or simply the bottleneck never being resolved can result in you never being paid. It’s also an opportunity cost — you can’t use that money until you receive it.
It’s time-consuming. Bottlenecks can stall projects for weeks or months. While this shouldn’t theoretically cost you, you’re likely to still have regular calls and communications with the client in practice. This takes time—time you didn’t budget for when the project began (see high-value meetings).
It creates a sense of malaise. This is more of an observation, but delays create a sense of malaise about the project. The consultants and clients become frustrated — even if it’s nobody’s fault. It’s hard to balance your workload or plan future engagements if you don’t know when a project will be complete. This is like an unresolved issue which takes up space in your brain and prevents you from planning for the future. You want a project to be planned to start, in progress, or complete. When a project stalls, it begins to seep into a relationship.
Bottlenecks are a silent money-vortex, yet there’s remarkably little information about how to tackle them.
The Five Types of Bottlenecks (and how to solve them)
Not all bottlenecks are equal - some you can tackle and others you can’t.
While we can’t always avoid each of them, we can take steps to prevent them from becoming major problems.
1. Getting set up as a vendor
Sometimes, you can get started and go. This is common in smaller organisations with more relaxed arrangements for vendors (albeit, even some larger organisations are surprisingly calm about vetting vendors).
It’s more common for larger firms to conduct at least some vendor vetting to ensure the organisation abides by its policies and promises towards customers. This vetting can range from simple tick-box exercises to thorough examinations of your finances.
It can take days, weeks, or even months to be approved as a vendor. At the more extreme end, this includes:
Sending your insurance certificates.
Completing data privacy and security surveys (or sending your ISO27001 certificate).
Sending your anti-slavery policies.
Sending your information security policies / green/environmental policies.
Sending bank statements showing your revenue (notably, they don’t represent a high percentage of your revenue).
Undertaking criminal background checks.
Sending official offers on company-headed paper (it’s remarkably company-headed paper is still proof of anything).
Arranging to receive client laptops (all client work must be done on their laptops).
You might also have to work with procurement teams to negotiate the fee.
There are two ways to speed this process up.
Create a folder containing all the information above in one simple package. Do this once, and it’s there permanently. You might also want to consider getting ISO27001 certified—this can speed up the process significantly with information security folks.
Ensure your contact knows in advance what’s required for the onboarding process. Your key contact might not have hired external help before and may be unfamiliar with the process. This can result in endless delays and surprises. So it’s important to urge them to find out so you can begin preparing the documents while waiting for the project to be approved.
If you’re both sure the project will move forward, it’s worth beginning the vendor onboarding process early (especially with OneTrust).
2. Access To Documentation
Assuming you’re not asking for anything containing PII, documentation hasn’t typically been a problem for us. Most of the clients we work with can quickly send information across. That’s because they can often access it directly from their system and attach it to an email.
It becomes slightly more complicated when an organisation wants to send documentation only through their system (typically Box, Teams, or Sharepoint). This is good practice from an infosec perspective, but it can be challenging because you must be set up on that system first.
Getting set up on the system often means the IT team must first approve you through some internal channels. This may or may not be included in the actions covered in step one.
The only way to speed this up is to ensure your contact knows in advance what’s required. Prompt them to find out what's needed at the earliest opportunity so you can work out what's needed from your side.
In practice, we’ve found this to be the least problematic of the five bottlenecks.
3. Access To Data
Organisations are curiously comfortable sending documentation containing all their secret plans but are increasingly reluctant to share any data.
In the not-too-distant past, clients often granted us direct access to their systems to explore the available data and extract what we needed. This kept things quick and easy. But these days, all organisations need to minimise the risk of a data breach, so granting access to third parties is less common.
This creates a problem. You might agree to analyse data in your proposal with your contact only for the IT team to refuse access - thus making it impossible to complete your work.
It’s useful here to plan for different scenarios.
Since you often don’t know what data to anticipate, it’s good to plan for different scenarios and ensure your contact knows in advance how you will tackle them.
Scenario 1: Full Data Export. You review the available metrics by speaking with the client or vendor documentation and request only the anonymised information you need. You receive, analyse, and present the information while deleting the raw data once the project is complete.
Scenario 2: Partial Data Export. You receive a fraction of the data you want (especially common if the data comes from two different sources). You undertake the analysis you can with the data you have access to and explain the limitations you faced.
Scenario 3. No Access To Data. You cannot access or review any of the data you need. In this scenario, you shift from doing the analysis to explaining how to do it themselves to the client. Use your actions in step one to explain what the client should do to undertake the analysis. They might not do it, but it’s as far down the journey as you can get them. You can also look for any available proxy metrics which might make sense to use instead.
It’s important here to respect the organisation’s stance on sharing data. Remember, they can be fined up to 4% of their worldwide turnover if they share data with you and your systems are later compromised. So it’s hardly a surprise organisations are incredibly sensitive about this.
4. Access to staff.
You can create the most beautiful project plan in the world, but if the VP you need approval from is on sabbatical for the next three months, you have a difficult bottleneck to solve.
The solution is to ask in advance whose approval will be needed for your deliverables and ensure they are available within that time frame. If not, factor that in.
However, sign-off isn’t the only reason why access to staff might be a problem. In the research phase of projects, we often need to interview various stakeholders to understand their current level of knowledge of the problem, needs, past attempts to solve their problems, and unique constraints.
In pre-Covid days I often flew to the company’s HQ and did most of these interviews in a day or two. Because my availability was scarce (‘he’s only in the office for a day’), stakeholders prioritised me. On Zoom, this is generally flipped, and it can take 2 to 3 weeks to schedule a call with a key stakeholder. These extra weeks can consume a lot of the project timeline.
The solution to this is to create scarcity.
Create an allotted amount of time for interviews. If someone isn’t available at that time, you move ahead anyway. If you like, you can make an exception, but you can’t wait months (which we’ve done before) for a stakeholder to become available.
Ensure your contracts clearly state your deliverables' response/approval time.
Projects shouldn’t be delayed unnecessarily due to staff unavailability. If an approver is away, shut everything down until they are back to avoid malaise and additional costs creeping in.
5. Access To Customers
Depending on the type of consulting you offer, you might want access to customers. This might be to:
Understand their needs and pain points.
Validate assumptions and hypothesis.
Developing customer-centric strategies.
Enhancing customer experiences.
Identifying market trends.
Measuring impact
etc…
A consultant might thus want to undertake interviews, surveys, workshops, user testing, customer panels/focus groups, ethnographic studies, advisory boards, and more.
However, organisations often have restrictions on:
Who can contact customers. This prevents customers (especially top customers) from being contacted by different individuals with different requests.
When customers can be contacted. This prevents the organisation from contacting customers too frequently and ignoring them.
Which customers can be contacted. Customers can no longer be contacted if they opt out of communications.
How customers can be contacted. Different people are responsible for different channels—you may need approval from other departments to reach out to a customer through a specific channel (say, email).
Why customers can be contacted. Customer contact might be limited to sales information or customer feedback. Research might not be an acceptable reason to contact a customer.
You’re unlikely to change the organisation’s processes or have them grant exceptions for you, so it’s important to scenario plan for each of the above.
e.g.
Working with another department if they are responsible for contacting customers.
Timing the contact to avoid any other major activity (and finding out what else is going on).
Selecting a specific group of customers you can contact.
Using a channel you can control to contact customers.
You might also scenario plan how you will proceed if you don’t have ANY means of contacting a customer. This is where you might rely on external research or gather insights from existing information.
Give A More Detailed Time Estimate
A quick word of warning when you begin a project. It’s quite common for a client to ask how long a project will take.
You might answer with a specific time frame, say, 12 weeks, based on your knowledge of past projects. However, the problem with this answer is that you might hit bottlenecks on the client’s side.
What if a client doesn’t respond to your emails for a few days, takes a vacation, or can’t get senior stakeholders on calls within the desired time frame? What if the critical VP is on sabbatical for three months? What if any of the issues above arise?
This is why couching your answer with more context and pragmatism is wise. A better answer might be:
Based on our experience working on similar projects, this usually takes twelve weeks. However, this depends on us not hitting any major internal bottlenecks in our plan, quick responses and approval of deliverables, and getting access to all systems within the first month.
Now you’re giving an answer with the full context and information the client needs. You’re being clear about the extent to which it’s within your locus of control.
Good luck!
Thanks for reading