Estimates Are Only Guesses
One huge source of stress at work is estimates. They’re invariably missed, resulting in disputes where business blames tech, who in return blame business for changing the requirements after the project started. This blame game erodes the trust and team spirit needed for people to work together. People feel stressed when there’s an upcoming deadline. Work-life balance is hurt. Other work items planned based on the estimate are disrupted. I’ve seen managers become too demanding, only to eventually lose credibility and be ignored. I’ve seen consultants fired or be threatened with lawsuits. I’ve seen consultants fire clients, too.
All this comes from a fundamental misunderstanding of estimates as being commitments. If you accept this premise, then broken commitments reflect negatively on the person who made them. But estimates are only guesses. If you accept this premise, then holding people accountable for a guess that didn’t work out doesn’t make sense.
The reason estimates are guesses is that the time a project takes depends on the following factors:
Scope
Quality
Number of person-hours spent on the project.
None of these are known at the beginning of a project.
First, scope should be communicated via an interactive prototype. It often isn’t. Many product owners toss out vague one-sentence requirements like “We want an X. How long will it take?” That’s like asking, “I want you to build me a vehicle. How long will it take?” It could be a few hours if it’s a bicycle, or years if it’s a nuclear submarine. I have also seen 30-page PDFs which no one will read or understand. Static mocks are another bad way of communicating scope, because you have to put them together in your head and imagine how it will be to use it. Watching someone click through a prototype is another bad way of communication; you have to click through it yourself to understand it:
Second, communication is inherently imprecise. No matter how hard you try, there will be misunderstandings, causing rework.
Third, different stakeholders often have different ideas on what to build, and these differences are not known at the outset of a project. People may use the same terms but imagine different things. You and I may agree on building an elegant house, but your idea of what constitutes an elegant house is different from mine. I have seen stakeholders surprised to discover months into a project that they had different goals in mind, causing some of the work done in those months to need rework.
Fourth, a project entails dozens or hundreds of micro-decisions. Say you’re building an e-commerce app. You may agree on features like categories, search, reviews, regular vs fast delivery, and so on, and think that you’ve defined scope well. But you may not have specified how login works, thinking it’s a minor part of the app, and a standard one, so what surprises could lurk there? Actually, there are tons: do you go with a traditional user ID and password? Then do you need Forgot Password, or can that wait till the next version? Do you have third-party log ins like Google and Facebook? If so, which third parties? What about Sign In with Apple, which Apple forces you to support under some circumstances? If you create an account with a user name and password, but later login with Google, using a Google account with the same email ID, does the app correctly log in you to the same account, rather than creating a new account? Do you need to validate the email ID? If so, does it need to block the account creation process, or can you use the site and validate your email ID only when you place an order? Do you want a system like Medium where every time you log in, you get an email with a link to click? In other words, you don’t need a password. Do you need to validate the phone number? If so, should the phone number be the primary identifier rather than the email ID? Do you see how many decisions even a minor, routine part of a product has? These hundreds of micro-decisions significantly change scope. This is why assurances by well-intentioned stakeholders that scope won’t change don’t change the reality.
Fifth, people have a misconception that a project runs like this:
Plan → Execute
If this were the case, you should be able to make an accurate estimation before execution begins. In reality, decisions are made throughout the project that change the scope. It’s more like:
Plan → Execute → Plan → Execute → Plan → Execute
Each of these “Plan” steps changes the scope. How can you estimate a moving target?
Incidentally, the first model is waterfall, which doesn’t work well, and the second is agile, which does, even if it goes against some people’s preconceived notions.
Sixth, it’s not just scope but also quality that can’t be communicated. I have had prospects tell me that they want a “good” app. What does that mean? That’s like saying, “I want a good car. How much will it cost?”
Seventh, we’re not clear at the beginning of a project how many people are working on a project. And what other initiatives they’ll be working on. Again, assurances by stakeholders that these people are dedicated to this project and won’t be pulled into anything else don’t change the reality that there’s always something that takes up time, like dealing with an outage. Or interviewing candidates for hiring. Or company overhead like team meetings. There’s always something going on. Or multiple things.
Eighth, sometimes well-meaning stakeholders insist that if you’re competent, you should be able to foresee and plan for things going wrong. This doesn’t work because of unknown unknowns — you don’t know what you don’t know. If you knew that (say) a web app might have problems on Safari and Edge, you can budget some time for it. But you often don’t know what will go wrong. The world is not predictable.
For all these reasons, estimates are only guesses. There’s nothing wrong with guessing, as long as you call a spade a spade. It avoids heartburn for everyone.
Sometimes business stakeholders may gave a date by which they want it done. That’s a target. An estimate is what the engineering team comes up with. Don’t confuse the two. If you say it will take a quarter but business says they need it in a month, the quarter is your estimate and the month is their target. Knowing the target is still useful information. For example, maybe you can deliver the two most important features by the targeted date.
Stakeholders sometimes try to negotiate estimates: “We don’t have a quarter. Can you do it in a month?” Once you acknowledge that estimates are only guesses, you realise that negotiating a guess doesn’t achieve anything. If I’m en-route to your place and tell you it will take 45 minutes, and you ask, “Can you be here in 30?” saying yes doesn’t make the journey shorter. Saying no doesn’t make the journey longer. The time depends on traffic and road closures, not on what we say to each other. To get to the destination faster, we need to stop talking and get moving.
Similarly, the time a project takes depends on scope, quality and the number of person-hours spent on the project. It doesn’t depend on the target business gives. Nor on the estimate engineering gives. To get to the goal faster, we need to stop pointless debates and instead spend that time executing the project.
Instead of fixating on the date, work in an agile manner. Break the project down into deliverables, prioritise them, and work on delivering them in order of importance, in small batches: