Spending Other People’s Money (Responsibly)

One of the comments to my recent post on estimation is that people want to know how much “a thing” will cost.  I totally agree!  They also want to know how long “a thing” will take.  Once again you will find no disagreement from me there!  I understand that people want to ensure that their money is being spent responsibly.  I do too!

The issue is not really about what people want as much as it is about whether you can give them an honest, accurate and beneficial answer.  I believe the nature of the (knowledge) work you do highly influences your ability to do so.

If you happen to provide a service/solution that is highly repetitive, for example, your organization specializes in the development of tele-medicine websites, then the odds are that after doing this for a while, you’ll have enough data and experience to pull from such that if you are asked for a cost/schedule estimate, you’ll be able to provide one with a high level confidence and probably with a narrow estimate range  (this will prevent people from rolling their eyes when you give them estimates).  This doesn’t guarantee that it will cost what you say (because stuff happens), it just means that because you have the requisite experience, you can confidently predict (assuming all things remain equal) the outcome.  I know this first hand, as my basement certificate of occupancy inspection which should have been done in a few days has been delayed due to the polar vortex and a subsequent inspection backlog.

But what if you don’t happen to provide such a service?  What if you happen to be one of the many product development companies out there that spend their days developing brand new stuff? One of the product development companies that is learning what to build based on customer interaction and feedback?  How do prove that you will “spend our/their money wisely”?  Of course, you can fall back on some reliable estimation techniques out there, give them the possibly outcomes and then subject your team to the burden of that.  That is definitely an option.  It’s just not my first (or second really).  I suggest another way.

Tell them you don’t know (yet).  Tell them that that you’d like to take an approach that is focused on learning, risk mitigation and building trust. Tell them you’ll focus the team on the highest priority item(s) for a few iterations and then have an inspection with everyone involved.  If this is a contract type situation, they pay for those iterations only.  Tell them that if they don’t like the progress, then discussions can be had around what can be done better (or even if the team should continue).  Assuming the team continues, over subsequent iterations, the team will learn enough to begin “predict” cost and schedule (if that is truly needed).

I know this sounds unreasonable but progress is dependent on the unreasonable man isn’t it?


After typing this, I realized that the question of “how much” and “how long” could also be an indicator of a bigger dysfunction within an organization, low trust.  In my experience, in high trust relationships, organizations trust that the team(s) is making every effort to get things done as soon as is possible. If you are in an environment of low trust, what can be done to change that?


How About #NoEstimates?

Let’s get this out of the way from the very onset.  I don’t believe estimates (and estimation) are evil and should NEVER be used.  Now that we have that out of the way, let me share estimation stories about two product teams.

Product Development – Commercial

There was a software development team that did annual releases of their software product. The team size was fixed as management realized that it was hard to have more than a certain number of people working on the same codebase at the same time.  Every year they’d spend a couple of weeks estimating items that were to make up the release.  They would decompose big items into smaller items that they thought were easier to estimate.  They would estimate by assigning hour ranges to the items assuming a sustainable development pace i.e. an individual working 35 or so hours a week. The estimators were experts in both the domain and the technology.  These estimates became a commitment of sorts because the plan(s)  for the year that went to upper management were based on the estimate they provided.  In spite of experience of the team, they would always find themselves scrambling at the end of the year, working at an unsustainable pace and having uncomfortable discussions on what needed to be cut.  After a while, the concluded that was just how software development worked.

Product Development – Internal Use

There was an internal IT software development team building a product to support a new service that the company would be providing.  Even though business leaders had a “general idea” of what the product needed to do, there was uncertainty as to exact pieces of functionality that needed to be provided and the order that these features would need to be provided in.  In other words, the “requirements” were fluid because everyone was still learning about the new service that was being offered.  The organization determined how big the team size would be based on a set budget and then set the team off the work.  For two years, this team worked without estimates, rather they would identify the work item of highest priority (note that these were the smallest slices of functionality that provided value) and would focus as many people they could (swarm) to complete the item as quickly as was possible.  When the organization decided that more needed to be delivered, more individuals were added to the team.  Over time, the team learned that in the worst case, in 6 weeks an item of value could be delivered.  At a certain point, there was a change in leadership and the new management team wanted the development team to provide single point estimates for a long (pages) feature list to which the team obliged.  This new management was uncomfortable with single point estimates returned and that led to a lot of back and forth with the development team until the team decided to give management what they wanted to hear/see.  As the saying goes “nine women cannot have a baby in one month”, and the team members told themselves that it was going to take whatever it would take regardless of whatever numbers they had provided. 

I realize that these two scenarios do not capture every product development scenario under the sun but that’s not the point.  The question in my opinion is this: Is estimation required all the time?  Should we just provide an estimate every time we’re asked to do so?  Some would say yes, but I beg to differ.  The act of estimation should provide value, in many cases, significant value.  If it isn’t, it’s most likely a waste of time and cause of much (unnecessary) pain.  It’s been suggested that professionals just provide estimates.  I disagree.  Professionals create/provide value and if an activity is a non-value add then it should be okay to have a discussion about the necessity of that activity.

 In the first story, we see that the team, estimated all the time.  But did they really need to?  Both cost (team size) and schedule (yearly releases) were practically fixed and they knew the items of highest value that had to make the release.  Could they have operated without estimating at all?  I’d venture to say yes.

Then there is the question of when something will be done.  Well, as we see in the second story, if we get into the practice of delivering working software in regular and frequent intervals, we can actually predict more effectively yet differently.  The team in story two was able to predict that in the worst case, after six weeks, they would deliver something of business value.  Note however that they did not predict when ALL the business value would be delivered as that’s a different game entirely.

There are those who believe that cost and schedule must be determined upfront at all times via estimates.  Is this true?  Are there not situations where cost and schedule are pre-determined via other methods as identified in the stories?  Isn’t it a concern if decision making is solely driven off of estimates?  It may surprise you to find out that this is very often the case in software development shops because its the easy (lazy) thing to do.  This results in teams often working on the shortest job with the least amount of value.

If we estimate, it’s because we need this information as an additional input into our decision making process.  The estimate must be of value and the more valuable the estimate needs to be, the better our estimation approach needs to be.  However, this requires that we’ve already estimated the value of the initiative we are undertaking ( when we have no estimate of the value of initiative, why are we estimating how long it will take or how long it will cost?  Of what value is the estimate in that particular scenario?)  and are trying answer questions such as the following:

  • Is the effort required to create something worth it?
  • Will the job complete on time for us to realize the value we estimated on it?
  • Which job should I start since I have two jobs of the same value?

If you believe that in your situation you need to answer the questions mentioned above, then I’d suggest the following:

  1. Read a good estimation book like How To Measure Anything before you start
  2. Use mature estimation techniques like Monte Carlo
  3. Gather a decent understanding of variation and how it applies in  your context
  4. Realize the output of mature estimation techniques is the probability of a set of different outcomes
  5. Plan based on the set of outcomes (and not just one outcome)

This applies to those asking (managers) for estimates and to those providing (development teams) estimates. Unfortunately many senior managers (vice-presidents, general managers, C-level execs etc etc) that I’ve come in contact with are not as educated as they should be about estimating in knowledge work.  This is extremely unfortunate as a manager with a misunderstanding of estimation, is unfortunately a very dangerous manager.

It has been suggested that any estimation is better than no estimation.  Um, I don’t think so.   At least, that’s not my experience.  Estimation done poorly, improperly or recklessly is harmful as unrealistic commitments are often its product.  Stress and de-motivation and a shoddy product follow shortly thereafter as its by-products.  

Some of us have gotten very good at gaming estimates and as a result have convinced ourselves that we are good estimators i.e. we are always spot on .  But let’s be honest now.  How about the extra hours you made the team work by reminding them of the estimate?  If your estimate is correct, how come the team did not work at a sustainable pace throughout?  Why did you decide that certain features can be deferred to the next release?

If you are the business of doing projects (hard start/stop dates) then I can also understand how the idea of always estimating may be essential to you.  But if you are in the business of developing and growing a strategic product over decades, then I believe there are other approaches that can be leveraged.  After all, the decision about whether to build the product has already been made.

I respect the fact (and the people) that some (many probably) within my profession believe that we must always estimate but I simply disagree with them.  I would hope that they could respect my opinion as well.  I will suggest you take a look at your particular situation and determine if estimates are critical to being successful at what you do.  Conduct an experiment of working without estimates if its possible.  If estimates are crucial to your success, then I charge you to estimate responsibly and if they aren’t, well how about #noestimates?