Project Management: Four of the Best Ways to Do Project Estimates
I learned a thing or two about estimates when I started as a project manager. My employer at the time had hired me to lead a fairly large development project. My first task was to find a company to do the work. I got asked to produce a request for proposals (RFP), gather the offers, pick the best one, and work with the developers at producing a wonderful tool that would solve all of our problems (and also make coffee).
So I got to work, sent a carefully curated RFP into the world, and waited until the deadline to select a winner.
Then the offers came in.
They were all great, for sure. Most of the proposals included the main elements I’d highlighted in my RFP. The organisations seemed awesome to work with. I was excited to start the work.
But the estimates? They were all over the place. One company promised they could do the work for under $40,000. The other said around $200,000. How could the numbers differ so vastly? How was I to know which team would do the work best? Which one was the right choice, the cheapest or the most expensive, or neither?
I had encountered what I call the estimations quandary.
The estimations quandary
Providing time estimates for technical tasks is notoriously difficult. Ask anyone who’s ever had to do it - the only way to provide an accurate estimate of how long a task will take is to do it first. This problem will affect anyone, large corporations and small companies alike. It’s an issue for other industries too - road construction, home repairs, automotives, hardware, you name it - everyone who ever has had to provide an estimate will know exactly what this quandary is.
Why is it so hard to come up with an estimate? Well, many reasons:
- It’s really difficult to provide an estimate for a task that has never been done before - who knows what it might turn out to actually be? Even when it’s been done before in another context, a slight difference in the new context might make a huge difference.
- The task description might not really encompass all the work that needs to be done. “Change the font size on this page” might mean that the developer will need to learn a whole new CMS to find out where the CSS is located before they can perform that “easy fix”.
- Providing a reasonable time estimate for a task may require a few hours of investigation, research, coding a proof of concept, etc. Providing a “quick estimation” for a small list of 5 tasks could take days!
- One word: browsers. With mobile phones, tablets, the variety of OS and the different versions of each browser, we sometimes end up spending most of the budget trying to make this button look just right on Chrome on Android 4.
- Who can predict that a small change to, say, the social icons to the top corner, might mean we need to switch font providers? Even with an in-depth analysis beforehand, predicting the side effect of some changes is nearly impossible.
It’s simple: estimates are possibly one of the least useful way to talk about a project.
Yet, we still need them. On the receiving end of the estimate, there are budget makers, boards and people who can’t necessarily afford to just “see how much it will cost”. For a client, open ended engagements are risky and can lead to misunderstandings. And budgets are an easy way to keep track of how well the project is doing.
Then what? How can we give a fair idea of how much a project will cost while also understanding that however talented and experienced we are, we still don’t know what we might find once we get our hands dirty?
There might be hope on the horizon.
Can this get better?
At CoLab, we’ve encountered this problem many times over. And, every time the estimates question gets brought up, it sparks a new conversation. What’s the best way to go about doing this? Many people have their favourite estimation technique which, they often seem to think, is the best thing since sliced bread.
Let’s see which one really is the best.
What about we don’t even talk about how much it’ll cost? What about we instead talk about how much money it’ll bring in?
Let’s say there’s a client who says: “I want to boost our newsletter subscribers”. This client might be selling a product and more subscribers could mean increased revenue. To help them, we may come up with some good ideas to boost newsletter subscribers taking 20 hours. These 20 hours could provide him with tremendous value and lead to increased revenue. The traditional way of working is thus: we say “we estimate the work at 20h, it will cost this much.” And depending on whether the client has the money available they might or might not go ahead with the project. In this case, the need for an initial investment can be a blocker for improvements which might actually bring in more money down the road.
An alternative approach would be to say, “Boosting newsletter subscribers is a good idea to increase revenue, and we've identified some additional adjustments to the checkout flow, especially for mobile users, who now make up X% of all visitors, etc.” And we provide a proposal for that work priced based on how the work will benefit the client’s business.
Instead of evaluating if paying for 20 hours of time seems worth it, clients can evaluate based on how the work will impact a goal. It allows them to focus on outcomes rather than costs. After all, most clients would readily spend $100,000 to generate $150,000.
PROS: Isn’t is pleasant to look at it positively? Thinking about the added revenues instead of the money needing to be spent?
CONS: It does require a lot more work from the developers, can feel a little bit like a leap of faith, and certainly only applies to companies which measure in revenues.
The #NoEstimates philosophy isn’t really a new way of producing cost estimations. Instead, it challenges the concept of estimations as we know them and asks project leads to explore new avenues. As Woody Zuill puts it, #NoEstimates means: “question everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.”
It makes a lot of sense. Why would we continue using a tool that wastes everybody’s time and proves to be repeatedly flawed? #NoEstimates wants us - rightfully - to question our methods and to strive to produce the best work we can - from the very start of the project.
PROS: Let’s stop using a tool which doesn’t work!
CONS: But finding solutions takes time and a lot of trial and error. Maybe it’s better to stick with the devil we know?
This one’s tricky. Because budget making is a chicken and egg story: clients need an estimate to see how much budget they’ll need for the project. But a good estimate will be based on the client’s budget. Which comes first?
With budget-driven development, we start by setting limits. The client establishes how much money they’re willing to spend on the project. A list of desired features is created and prioritized. And work is performed until the budget runs out. This means some low-priority features may be cut, some features may be altered from their original conception, but at the end of the day the client will still be provided with a great solution without any budget surprises. And this avoids the practice of providing granular time estimations for each individual task.
This approach requires strong project management techniques. And that’s probably why I like it the most. It means that everybody’s expectations are clearly laid out, and leaves it to the project manager to keep track of the work done and of changed needs. I believe a project well done is one where you’re often checking in with the client and making sure they’re happy with the work done. And something like budget-driven development will only work if everybody’s working together.
PROS: No surprises! None! Seems impossible...
CONS: Requires the client to have a very clear idea of what their needs are and of how much money they have to work with.
The CoLab Way
The beauty of an organisation like CoLab is that there is room for evolution. For now, we’ve developed an estimate template which takes into account how much risk there is for a given task (adding a new feature in an unknown site will have a higher risk factor than, say, changing a password on a site we’ve been managing for years) and which provides a high and a low estimate for each task. If all goes well, we’ll be at the low. If problems come up, hopefully we’ll stay within the high.
But this is only the current iteration of our method. And, thankfully, it’s far from being treated as gospel truth. We adapt to our clients and refine our estimate template with each lesson we learn. The most important thing for us is to always keep in mind that estimates are always a guess. The best we can do is work with the client to ensure that the final product can be as close to their expectations while respecting their budget. It takes hard work, constant communication and a lot of love for us to get there.
PROS: Well, it’s the CoLab way, it must be the best, right?
CONS: It can be hard for a newcomer to understand the intricacy of so many levels of estimations (a low and high risk what?)
The method to rule them all
What now? Which one is the best?
Well. Unsurprisingly, all of them.
There is no such thing as a one size fits all estimation technique. Any given project has different needs - budget and timelines are the most obvious - and different goals - more profit! More users! In this situation, a skilled project manager will use their judgment and adapt to the client. Still, a movement like #NoEstimates can teach us something important: don’t limit yourself to one method. Every new project should bring a fresh way of looking at things.
So - what happened to the neophyte project manager that I was? I followed my gut. One of the proposals had sparked my eye: the company was straightforward and honest, recognized the difficulty for them to provide an estimate and listed the potential issues they saw with the project (one of which was how competent the project manager would be!) Their estimate ranged from $100,000 to $200,000 and instead of scaring me off this reassured me: they knew that they didn’t know. It was a hard pitch for my board, who had to be convinced that the wide range didn’t mean that the company was inexperienced. But I never regretted my choice. And the final product we delivered is one of the things I’m most proud of in my career: it was the result of a deep, collaborative work, which stayed within budget. What else could I have asked for?