For many years now, we’ve read studies such as the CHAOS report, expounding on the relatively high failure rate of IT projects. High, relative to what – highway construction projects? The typical highway construction project is proposed, studied, risk managed, and planned for years before the first shovel of earth is turned. A massive body of laws, regulations, standards, and technical requirements drive every design. Materials, products, and processes are mature and standardized, and a coterie of safety experts, inspectors, and regulators watch over every step. With all of that, one would reasonably expect highway construction projects to have a low failure rate. Yet, these projects still fail. The Big Dig in Boston stands out as a monument to cost and schedule over-runs.
IT projects, on the other hand, tend to be subject to snap decisions by sponsors, with little executive oversight. There is typically limited time allowed for planning, due to short schedules driven by “competitive pressure” and ever-shorter product life cycles. Scope is frequently vague. Stakeholders are usually too busy with “business as usual” to participate in planning, defining requirements, or testing. Project team members are rarely dedicated to the project, and their work priorities are constantly shifting. Software tools are buggy, poorly documented, and poorly supported by the vendors (or “supported” by a user community). No wonder so many software development teams are using Agile methods to shorten their development cycle, limit their scope, and keep “the bar” within reach.
All of those constraints and challenges aside, we should assess success in terms of results delivered. Project management isn’t about budgets and schedules; those are just the means to an end. A successful project would:
- Deliver usable results, quickly enough to be of benefit, to customers that understand how to use them
- Delivery didn’t “break” something else
- All non-functional requirements were met
- Knowledge transfer was compete and effective
- Maintenance throughout the product life cycle will be cost-effective, and major business process surgery won’t be required in order to replace it at end-of-life
- Quality is commensurate with the criticality of the delivered product to the business
- Organizational change management efforts were sufficient to meet adoption goals
- The risk profile did not exceed the organizations appetite for risk, and the risk management budget was spent wisely
- All contracts were completed satisfactorily and relations with the vendors remain positive
- The core project team was retained, and their experience will benefit the organization in the future
- After some reasonable period of time in operation, it looks like the ROI that will be achieved at least matches what was expected in the original business case
- Any lessons learned have benefited other activities within the organization
You can make your own list, based on the nature of your project, but the key point in making it should be that success isn’t about the project; it’s about the results.