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.
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.
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.
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.
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.
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 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?
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?