However, there is a class of software projects that are legitimately IT driven. Enterprise IT departments are often under heavy budget constraints that impact their ability to maintain and deliver new software. As technology evolves, many IT departments get to the point where they want to substantially rearchitect their systems so that the maintenance and change of those systems is less costly. In this case, the main business stakeholder for these projects is legitimately the IT department. Success metrics may be defined as a reduction in maintenance costs, or in the ability to deliver new functionality faster or more cheaply.

These redesign projects rarely occur in a vacuum. Often when IT announces that they are redesigning the system, this will lead to the business wondering what they get out of the redesign. This frequently leads the business to ask for features that support their business objectives. This might lead to a collection of orthogonal project success metrics that become more difficult to measure:

* The call center can reduce staffing by 20%

* The IT department can deliver new functionality in half the time that it previously took

Note that these success metrics are orthogonal but not contradictory. The challenge will be for the business to evaluate the success of the project as a whole. If they meet the business objective of reducing staffing by 20%, but don’t see the full improvement in delivery time, is the project a success? Probably not from IT’s perspective. What if both objectives are half met?

The key to success on these projects is to ensure that all of the monetary stakeholders (in this case both the business and IT) are aware of everyone else’s success metrics for this project, and a clear plan is in place to prioritize those objectives. Without understanding who’s metrics we are driving for, it’s impossible to prioritize the elements of the software that are going to deliver value.