Estimates, Targets and Commitments


A fine Monday morning finds me sitting across the client. Clearly a powerful executive. Next to me is my immediate boss negotiating for our side .This particular meeting has been called because the client needs to go over our proposal. So far all is good and our price and timeline seems fair.  All nice and dandy before this conversation happens:

Client: We like the product concept, do you think would be too much work to build an Android app as well? A lot of our customers are on the platform

Project Manager: Not a problem what would you like added

Client(Pointing items on the proposal): This and this screens

Project Manager: The team can definitely handle it, what do you think Chencha?

Me: Yes we can

Client: How long will it take and how much will it cost us?

Me: I will have to sit down with the team to evaluate and prepare a new proposal

Client: That is ok, but what about a ball park figure?

Me: At the moment we can’t tell but we know it can’t be more than 4 weeks

Client: That is too long and we must have the android application before our launch in June

Me: I am sorry that is the best we can do

Project Manager: But of course we will meet the target we understand the urgency of this product

What just happened there?

Before I explain let us first delve into some definitions.

What is a software estimate

A guess for the time it will take your development team to complete a task.

What is a target

A point in the schedule to meet. Think about it as an ideal deadline circled in red on your calendar

What is a commitment

A commitment is an agreement to complete a task within a certain time frame.

Yet there is an insidious relation between mixing up the terms and ending up with a failed project.

In preparation of your proposal you have to give an estimate. But you and the team understand that at best the estimate is just an educated guess. The release schedule which represents your target is also based on that guess. The problem is that for most work, the target is set externally to the development team. You then end up in this awkward situation where the client and thus your business would rather have you massage your numbers to ensure that the release schedule hits the target date.

In the case above we had put in our best estimate for the project which the client would have wished was shorter but accepted it none the less. Problem now was  he wanted more things done and did not want to adjust the schedule commensurately.

Even worse the project manager just agreed to a near impossible schedule. And here is where we get to our last term, commitment. While you can easily renegotiate or even publish new estimates and thus targets. Commitments for most part are legally enforceable agreements.

Now while the project manager in this case meant that we could estimate the extra work to get done by June. The client interpreted that as a commitment to get the work done by June!

By trying to please the client, we have just found ourselves in a situation where the client will likely not be happy with the time it takes us to complete the project, no matter how fast we are!

Thankfully remedies exist for this exact situation:

  1. Separate size estimation from time estimation. See Invest in user stories
  2. Separate costing from estimation. Bill per sprint
  3. Ensure to explain to the client that estimates are just guesses
  4. Select a project management model that shows progress. Agile practises are perfect for this

Have you ever been in a situation where the distinction between estimates, targets and commitments came into play? Share your experience on the comment section below or tweet to me @ jchex


Published by


Software Project Manager