Control Plan: Driving Change and Confirming Business Cases

There are many mantras around how measurements drive behavior.  The example I always used happened early in my career.  As a newly minted MBA I was assigned to analyze the purchase of timberland.  The CFO wanted to set up the purchase as a lease via an insurance company.  I determined the implicit interest rate was much higher than our debt rate.  When I questioned the CFO on why we would want to pay such a high rate, he told me that he and the GM were evaluated and compensated based on Return on Net Assets Employed (RONAE).  Because the lease would keep the assets off the books, RONAE was indeed higher with the lease.  We pursued the lease even though it did not add as much value as if we had purchased the land outright.  His behavior was based on how he was being measured.

Almost all IT enabled projects obtain their value by changing the way business gets done.  Ultimately this boils down to changing the way people behave.  One of the most effective ways to get people to change behavior within an organization is to change how they are measured.  The question becomes what should be measured to avoid the unintended consequences that arise from measuring the wrong thing.  Six Sigma concepts focus on identifying the root cause of a problem and setting up control plans to correct the issue.  In IT we utilized the Six Sigma principles to identify the key measures that would drive the outcomes embedded into a project business case.   

As an example, one of the benefits we expected from an ERP implementation was a reduction in inventory.  Inventory dollars and days on hand were frequently influenced on a day to day basis by factors that had nothing to do with effective use of the ERP system, and so were not good daily tracking measures.   We found that a key driver of enabling inventory reductions was inventory accuracy.  Drilling down further we were able to correlate negative inventory locations (locations where the system inventory value was less than 0) with inventory accuracy.  The only way to avoid negative inventory was to correctly and timely record inventory movements and usage.  Negative inventory therefor became our control measure. 

Depending on the implementation we identified 8-10 KPI’s that were used to drive the required behavior changes.  The key characteristics of these KPI’s were:

  • Availability on a timely basis: normally by shift or day
  • There was an effective way to measure and track the KPI’s: Normally directly from the system being implemented
  • It was possible to set target levels for the KPI that tied to realization of the business case

To effectively use the KPI’s requires the following:

  • Each KPI must have an owner
  • KPI results must be reviewed on a regular schedule
  • KPI’s that are not tracking to target should trigger immediate problem solving and corrective action processes

With our KPI’s as part of an overall change management process we were able to identify, prioritize and mitigate issues quickly and drive adoption of new processes reducing time to benefit by 50%.

Another way we used our control plan was to validate achievement of the business case.  Many times, the results of an IT enabled solution are hard to track back to the implementation, because of all the other variables that can influence the results.  Go back to my example of using an ERP system to reduce inventory.  Many factors that are ongoing between project kick off and the end of support, such as personnel upgrades, mix changes, supply changes, and business wins and loses can have a much greater impact on inventory than the ERP implementation.  However, we knew that when all the KPI’s were on target the solution was being utilized as intended.  In the case of an ERP implementation this meant we had improved our planning capabilities.  Because our initial business case had linked improved planning to inventory reductions, we were confident that the implementation had delivered its business case.  When we had chosen the right KPI’s this confidence was justified by longer term trends that correlated to the expected improvements.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Agile Work Team

Agile IT and Lessons Learned from Nimble Manufacturers

Reuse, incremental innovation, knowledge sharing, and common values are keys to agility.

Key Success Factors in IT Projects

Capabilities of the business resources and process governance system are critical to success.

Agile is a Mindset, More Than a Methodology

Highly successful Agile teams have team members with Agile Mindsets