As someone who is passionate about business, Diana has a diverse background in many industries, most notably in a marketing or project management capacity. No matter which direction she went, she was always handed a website to upgrade, create, design, or manage. She took this as a sign to head into the web industry, and has since worked as a project manager combining her knowledge of business and marketing to help clients achieve their project vision.
I’m going to start with a bold statement: Estimates are always wrong.
Unless we are talking about a very small timeframe and only a few clearly defined deliverables, a technical project is almost never completed in the exact same number of hours/dollars as was originally estimated.
It's not for lack of trying, or that someone has been grossly inaccurate on purpose. It's essentially just the nature of creation: a client doesn’t know exactly what they want, often until they see it. Similarly, a vendor often doesn’t know exactly how they will deliver the requirements until they are elbow-deep in building it.
I am lucky enough to have been both a client and a vendor on web projects. From a client's perspective, you need an idea of how much that big idea will cost, so you can make decisions about ROI, or compare vendors. You also want to have a pretty good idea as to what you will have at the end of the project - will it meet the business requirements? No one likes to throw money at a vendor and hope for the best. You are accountable to internal streams and stakeholders - often many of them. The pressure to deliver quality and value as cost-effectively as possible is, in some cases, extreme.
As a Project Manager, I have heard my clients say “heads will roll if we don’t deliver” or “my boss is expecting everything we talked about at the beginning”, more times than I can count. I’m sure that these statements are true, but they create a very stressful situation for all involved.
Having a vendor commit to fixed scope and budget gives a sense of security, however false. It gives you a contractual ‘big stick’ to protect yourself from overruns and ensures that you get what you pay for. All of this is perfectly understandable and reasonable. I get it. Clients often wonder why vendors push back on signing up for this. Fixed scope and fixed budget gives vendors no room to move, so why would they?
Let's look at the other side of the coin.
From a vendor’s perspective, when presented with scope from a client, they are actually being asked ‘how long is a piece of string?’.
I have been involved in meetings that have gone like this:
Client: ‘I want a website’
Me: ‘Okay, what type of website are you thinking?’Client: ‘I dunno, maybe like YouTube, but better. That went well for them.’
Me: ‘Um, okay, YouTube was created and built over several years, and cost them many millions of dollars. Is that what you have budgeted?’
Client: ‘But I thought you guys were open source - surely you could do it for less than $50K?’
I’m sure you get the idea. Without knowing how long some things can take to develop in reality, the expectations of client and vendor might not be just in different ballparks, but different states! The art of a good site is to make it look simple and easy. In reality, it may actually be hard, time consuming and expensive to get to that point.
When my team look at a feature-set to estimate, many parameters are taken into account.
First up, and most telling, is our experience. If we have built something similar before, we can make some pretty good assumptions. If the business requirements are well defined, we can make even better assumptions. If it explains the acceptance criteria, or what ‘done’ looks like, even better. We think about how long we might think it would take us to complete, if it went well. Then, we ask ourselves how much longer would we need if everything hit the fan. Based on the risks around the feature at hand, we consider what would be the most likely scenario. This gives us a range of time or effort required to give the client that feature. We usually supply the assumptions and risks to the client to validate these are actually right. If the assumptions are incorrect, then it's back to the drawing board.
So now the client has a range. And with that, a dollar value. This might be a small range, or it might be ±200%: it all depends on how much detail we have about the features required. For example, I can say to you right now, we can build you a website for somewhere between $15K and $2million. Of course, what you get in that website will vary wildly.
If a client needs a more accurate estimate, then the detail needs to be more accurate. Even so, you can only go so far down that road - there will always be ambiguity in projects of any kind. I have watched as Business Analysts have written 150-page Functional Specifications for one feature of a site, thinking that this would give accuracy and clarity, and mean that changes won’t be required, only to have it fall over on day one, when some basic assumption is proven incorrect.
We all need to agree on one thing: an estimate is a baseline to start a project, based on information and risks we understand on day one. On day two, it will change, and day 12, and day 50, with many other days in-between. As far as I know, no one can foretell the future, and as a big risk management person, the best you can do is:
- Plan for the worst case,
- Hope for the best case,
- Identify where any change is likely to come from,
- Mitigate those actively as you traverse the project timeline,
- Be honest,
- Make good decisions based on all you can know at the time, and
- Have a contingency plan/budget for when the thing you didn’t know was coming hits you.
Be prepared to change everything. Always reassess what you have done to date, and whether what you plan to do next will still add the business value. If not, change the plan until it does. Accept that you don’t know what you don’t know, until you do. If a client and vendor can work openly and honestly with each other as a team, keeping an eye on the original goal, then you will have a successful delivery.
Clients - cut vendors some slack. Estimates are always educated guesses, and the accuracy of that guess depends on you, and the experience of the team.
Vendors - realise there is more at stake than just getting a project signed up. There are business outcomes and KPI’s relying on you to not screw this up, so be upfront, show them the potential worst case. It’s better than pretending it will all go swimmingly. And then, at the end of the project, you can then tell them how long the piece of string was!
