Customer Satisfaction

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.  

We should be getting back to normal on the blog starting now.  As many of you know I have working on a project management book with Murali Chemuturi which has now gone to the publisher.  While I know there is more work on it in the future I intend to start catching up starting now!

IT Value and Customer Satisfaction
Thomas M. Cagley Jr

IT value is an outcome that can be expressed as a transaction; a summation of debits and credits resulting in a number.   Unfortunately, even if we can create a specific formula, interpretation of the number is problematic.   Measures of the economy of inputs, the efficiency of the transformations and the effectiveness of specific outputs are components of a value equation but they only go so far.   I would like to suggest that customer satisfaction makes interpretation of value possible.

I believe that value is perceived by those receiving the service therefore tends to be specific to the project or service, to be predictable there must be an assumption that there is a relationship between how the product or service is created and the value perceived.  When we are assessing the value delivered by a department like Information Technology (IT) which is part of a larger organization, it is rare that we are allowed the luxury of being able to declare that the group we are appraising is a black box which means we have to create transparency.  Because we have to create transparency into the appraised organization we have to define value as a synthesis of inputs and raw materials, the efficiency of the processes used in the transformation process (where value is typically added) and finally whether the  output meets the users need and is fit for use.  While this sounds complex, every small business has had to surmount the complexity to stay in businesses.  A simple value example from the point of view of a restaurant owner:

  • A customer enters the restaurant and orders a medium-rare New York Strip steak (price $32.00)
  • The kitchen retrieves the steak from the cooler and cooks the steak so that it is done at the proper time and temperature.  (The inputs include requirement for the steak, effort of waiter and kitchen staff.)
  • The customer receives a medium-rare New York Strip steak

From the restaurant owner’s point of view the value equation begins as the price of the steak minus the cost of steak, preparation, overhead and the free tap water.   If the cost of steak and servicing the customer was more than the price charged, an accounting loss would have resulted and if the costs were less  . . .  an accounting profit.  The simple calculation of profit and loss provides an important marker in understanding value but it is not sufficient.   For example, let’s say the customer was the restaurant reviewer for a large local newspaper and the owner comp’ed the meal AND the reviewer was happy with the meal.  The owner would derive value from the transaction regardless of the accounting loss from that single transaction.  As I noted earlier, customer satisfaction is a filter that allows us to interpret the transaction.   Using our example, if the customer was unhappy with his or her steak the value derived by the restaurant will be less than totaling of the accounting debits and credits would predict.  While a large IT department has many inputs and outputs I believe the example presents a path for address value without getting lost in the complexity of technology.

In a perfect world, IT value would be established in a perfect market place.  Customers would weigh the economy, efficiency, effectiveness and customer satisfaction they perceive they would garner to decide who should do their work.  Unfortunately, perfect market places seldom exist and participants could easily leverage pricing strategies that internal organizations would not be able to match.  The idea however has merit and benchmarking projects is a means of injecting external pressure without the potential for pricing abuse.

Measuring IT Value whether at a macro or project level needs to be approached as more than a simple assessment of the processes that convert inputs into a product or service the business requires.  Measure the inputs and raw materials, measure and appraise the processes used in transformation and then determine the user’s perception of the output (where the customer and user are different you need to understand both points of view).  Knowing the value of all of these components while having your thumb on the filter of customer satisfaction will put you in a position to not only determine the value you are perceived to be delivering (at least over the short-term) but to predict how your customers are perceiving the value you are delivering.  Remember forewarned is forearmed.