Would you be satisfied if you paid for five cabbages, but got only four?

Would you be satisfied if you paid for five cabbages, but got only four?

Estimates and customer satisfaction are intertwined because they set expectations. Estimates set the development team’s expectations about resources that will be available to deliver the project, including effort, people, calendar time.  From the customer’s point of view, an estimate will generate expectations about what will be delivered, when it will be delivered and what the project will cost.  The dark side of estimation is that once an estimate is even whispered, it quickly become set in stone and gains the power to dissatisfy. 

A project estimate is an outline of the resources that the team or estimator needs to deliver a given scope of work.  Regardless of the ultimate veracity, most organizations require an estimate for a project to secure funding and team resources.  Estimates create parameters that the team(s) will operate within.  Missing an estimate, whether due to lack of information, increased scope or changing business decisions, will impact other projects.  This ripple effect impacts other projects as overall portfolio is adjusted to deal with changing realities. This leaves very few within the IT department satisfied. 

IT customers and stakeholders have been trained that they need to ask how much a project will cost before they begin and many have been trained that answer is at best a guess.  However, it is a guess to which they will hold the team.  This leads teams to pad the estimate in a vain attempt to not to have break the news that something that was not anticipated (and probably could not be anticipated) has caused the estimate to be wrong.  The project estimate, which is typically generated at the point in a project where the team knows the least about what will be needed to deliver the customer’s vision, generates a substantial anchor bias.  The anchor puts teams and their customers in an almost immediate customer satisfaction hole that is difficult to remediate. 

Most customers and stakeholders have purchased large ticket items, like a car, and paid the negotiated price.  A significant proportion have purchased products that either had to be customized for them, including clothing (suits or prom dresses) or houses.  Rarely do the prices vary significantly from the negotiated price. But, those of us in the business would challenge the relationship between these examples and developing, enhancing or supporting software. However most of customers and stakeholders would not be impressed with the distinction.  When pressed they will be happy to tell you that they can find a supplier to meet their needs for a fixed price (and someone will always say yes).

Why should project teams care about customer satisfaction?  Simply put:

  • Customers supply the budget or pay the bills.
  • Selling to happy customers costs far less than finding new customers.
  • In the long run ALL customers can change suppliers (internal or external).
  • Happy customers promote your team or organization.
  • Satisfaction leads to less in-fighting and better relationships.

In the end, unless we can change the estimation landscape, we will need to get better at estimation if we want to keep our customers satisfied. In part this means that we need to include more people in the process and to hone our ability to predict the future.