The delicate balancing act of estimates, commitments and targets

“The act of not basing commitments on tangible estimates might make stakeholders feel warm and fuzzy, but they are living a lie that will eventually catch up with them.”

Software Estimation balancing act

Most people have never learnt the balancing act of good software estimation and are pretty terrible at communicating it.

I recently did an article talking about the inherent complexity of doing software estimation. I delved into the phenomenon of discovered complexity and how it is at the heart of why it is so hard to do reliable estimation in software projects.

Beyond the inherent complexity of doing estimation lies another problem. One of bad communication. Most people have never learnt what good software estimation looks like or what the right way of communicating it is. Business people involved in software projects typically view estimation as the domain of the geeks and as such make no attempt at understanding the nuances. Geeks themselves have spent most of their lives giving gut-feel estimates never learning the importance of communicating estimates in the right way.

Universally estimates get treated as commitments and commitments get communicated as targets. Most don’t even know that there is a difference between these concepts.

The general disregard for the purpose and value of software estimation has led to untold amounts of project failures that in turn has caused unprecedented amounts of frustration and trust erosion in many business domains. And as already alluded to it all boils down to the fact that people simply don’t understand the difference between estimates, commitments and targets.

Each of these concepts have their own unique purpose, so allow me to disseminate it for you:

Estimate

An estimate is just that, it is best guess at how long something will take given the information that is known at this point. As I explained in my previous article, it is inherently flawed and will change over time as unknowns become known and problems find solutions that can be estimated on more reliably.

As such a good estimate should be plotted against a probability curve that tries to quantify the uncertainty and risk that surrounds the estimate. Put in simpler terms you should never communicate a single point estimate (‘I think this will take 6 months’) but rather a range (‘given what we know this could take anything from 6-9 months’).

“Thinking of estimates as a range of possibilities (between the best and worst case) reduces the stress of having to be perfectly right.”

Thinking of estimates as a range of possibilities (between the best and worst case) reduces the stress of having to be perfectly right and caters for the inherent ambiguity and uncertainty involved in the software development process.

Commitment

This is the promise to deliver functionality at a certain level of quality by a certain date. The really critical thing here is to realize that estimates inform commitments. But a commitment cannot and should never drive the estimate. The working position should be that the estimate is flawed and commitments have to be based on the most pessimistic estimate maybe even building in more fat. If the estimate is not palatable then business stakeholders should actually do the job they are tasked with and make the hard choices of prioritizing what is truly needed in order to give the project a quantified chance of success.

Too often in corporate environments existing commitments are made even before a project is understood or a project team has even been formed. Unfortunately this is done purely to look good and to make people feel better about their reality. Frequently this is done to mask incompetence and hide how poorly a portfolio is being managed. Regardless, the act of not basing commitments on tangible estimates might make stakeholders feel warm and fuzzy, but they are living a lie that will eventually catch up with them. Sadly most of the time stakeholders will consequently blame delivery teams for failures, never their bad decisions.

“If you are trying to make a commitment that is palatable instead of based in what is the best version of reality (aka the estimate) you might as well sit in a boardroom talk about all your dreams and wishes (regardless of how realistic they are), high five each other and hit the bar to celebrate since that is all you are essentially doing.”

In summary, if you are trying to make a commitment that is palatable instead of based in what is the best version of reality (aka the estimate) you might as well sit in a boardroom talk about all your dreams and wishes (regardless of how realistic they are), high five each other and hit the bar to celebrate since that is all you are essentially doing.

Target

A target is a single-point hard deadline, usually driven by some business need. It is has absolutely no relationship to the estimate of how long a project will take. In a perfect world estimation would happen before planning. The team will then come up with commitments on realistic sets of features and the business will then set strategic business targets based on reality never on fiction.

Similar to commitments it happens too much that targets are already fixed before estimation is even done. Or estimates are done by people that are not actually involved with building the software.

The key thing here is that if the estimation is subsequently done properly, stakeholders have to have the maturity to accept that what is being asked might simply not be possible. However many act like spoiled children that refuse to accept that what they are demanding is not possible. Instead they choose to play the guilt card on the delivery team for not being willing to go above and beyond. They remain oblivious to the fact that they still get to go home every night to see their children and live their lives whilst their teams bleed.

“They remain oblivious to the fact that they still get to go home every night to see their children and live their lives whilst their teams bleed.”

Forcing engineering teams to commit to a date that is more palatable to the business might make stakeholders feel better about situations, but if it is not based in reality (most of the time) it will result in dramatic failures at a later stage. This is not what it means to be a responsible corporate leader and you certainly are not operating with the best interest of the organization at heart. Put simply causing chaos in the lives of your employees to make yourself feel better about things does not make you a good leader.

Tips for being better

Understand the difference between these three concepts and live them in your day-to-day life.
I understand that it is hard to face senior stakeholders and tell them that what they want is not possible, but as a leader that is your job. If you are not willing to act in the best interest of the team and organization by being truthful about situations it means that you are just pulling the wool over everyone’s eyes to cover your own faults.

Don’t give estimates on the spot.
A rudimentary functional breakdown and sizing exercise is already much more accurate than a thumb-suck gut feel. As soon as you communicate any date people will treat it as a commitment. So best be sure that it is based in reality.

Never ever give a single point estimate.
As explained an estimate should always indicate a likely range and should be treated as information and nothing more. It provides context for discussions about commitments and business targets.

An estimate range is allowed to be wide.
For some reason there is an obsession to make estimates as narrow as possible since people are actually really looking for a commitment. The range indicates uncertainty and the fact that it is wide is relevant information. It illustrates the amount of uncertainty that is present in the project and should form part of the discussion.

Estimates should constantly be revisited and updated.
As you progress in your project and figure out some of the uncertainty you should be adjusting and refining your estimates.

Us the most pessimistic estimate to inform business targets and commitments.
You are not doing anyone any favors by committing to unrealistic timelines because it makes you look better. It will fail and result in people blaming each other leading to resentment and a breakdown in trust.

Always ask whether people are looking for an estimate, commitment or target.
If expectations in conversations are clear so much of this dysfunction could be avoided.

Advertisements

Project Delays: Why corporate companies are terrible at estimation

“‘The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” – Bollinger, T

Why corporate companies are terrible at estimation

At the heart of this problem lies the phenomenon of discovered complexity.

One of the biggest problems in software projects is the inherent difficulty of planning and estimation. It is a problem as old as the industry and almost everybody in the life of a project regardless of their role will have a strong opinion on the matter.

Similarly every company will have its collection of war stories about projects that have slipped spectacularly or seemed to perennially overrun on their budgets and targets. Jobs may have been lost, careers ended and most importantly relationships destroyed.

For some companies this is such a common occurrence that the devastation wreaked by bad estimation may have become the norm instead of an exception. It could have become part of their culture to operate in a state of constant project flux. In environments such as these the trust between business and technology may be so eroded that any real attempt at even coming up with reasonable project estimates get abandoned regularly.

Instead it gets replaced with a constant barrage of unrealistic business demands that is framed as ‘critical-delivery’, typically based on no quantitative reality of effort but exclusively on what business would want to happen by a certain date for some particular reason. These ‘immovable’ business targets generally are manufactured to squeeze out as much delivery in a world that is hard to quantify. Where it gets ugly is that these targets are often arbitrarily tied to people’s KPIs even before the feasibility of the piece of work is explored. Typically the lucky recipients on these KPIs are people that have no experience in how to do proper software estimation, and who have no understanding of the differences between an estimate, target and goal (go read Software Estimation: Demystifying the Black Art by Steve McConnell).

At the heart of this problem lies the phenomenon of discovered complexity. For some reason people view software as a mechanical task similar to that of an assembly line in a factory. But as research has shown (even mathematically), ‘the creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.’ [Bollinger, T]. It is a creative process that requires a lot of thinking about as of yet unknown problems that constantly present themselves. These accidentally discovered problems may in turn actually lead to more subtle and indirect problems that also require solving. This is called accidental discovered complexity.

Put simply at a particular point in time, you don’t know what you don’t know yet and there is no way to tell how long it will take you to figure it out when you discover it. In a world such as this how can you definitively estimate how long something is going to take? At best you can give a reasonable guess using the information you have at your disposal at that point in time. But even this is a problem since what you know about the problem domain develops and changes as the project progresses.

Given that it seems virtually impossible to estimate these creative tasks with reasonable accuracy. It therefore becomes imperative that you follow an iterative development methodology where there is a constant feedback loop on estimates. If you are not continually re-estimating how long a piece of work is going to take based on all the new information constantly learned, you are putting your project and more importantly your organizational goals and commitments at risk. Do that often enough and watch the carnage unfold.