Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Thu, Oct 29, 2009 9:22 EDT

|
Posted by: bcrowell in Best Practices Topic: Enterprise Management
Current Rating: |
I think any CIO would agree that one of our greatest fears is the probability that we'll oversee one of the vast majority of projects that fail, estimated at around 70%. This means we've participated in the waste of our organizations resources and placed our own careers at risk. Given the reality of this risk we've historically lacked any quantitative means to monitor projects health. Unfortunately, much of the information we've had to rely on is anecdotal and we're forced many times to make decisions based solely on gut feel.
What do I mean by quantitative measures of project health? I like to use the analogy of going to the doctor for a check up. The doctor will order a series of tests that help him identify things that are OK and things that are risks or vulnerabilities that need to be treated. In IT we've lacked such tools or test, like those used by the doctor, to help diagnose problems that a project maybe facing and need to be treated.
The problem is that as “techies” we tend to focus our attention on the technical aspects of the project. Is the right hardware in place, is the network properly configured, is the system meeting performance expectations, is the project on schedule, are we on budget? These are all important issues but they neglect one of the most important factors that lead to success or failure, the human factor. Specifically, how do the principle stakeholders including executives, the IT department, the prospective users, and the external vendors perceive the initiative to be going.
Someone who has studied project successes and failures extensively, Michael Krigsman, and I had a recent conversation on this very topic and we both agreed that project failures were not usually due to poor management practices or short comings in the hardware and software technologies being implemented. As Michael likes to say, "It's failures in the human factor that is the root cause". I agree completely.
Based upon his extensive work and expertize in this area, Micheal has defined "seven pillars" for the success or failure of projects. These pillars or categories include:
The Business Case - how well is it defined and supported?
Stakeholder Involvement - are all the stakeholders up and down the organization really involved?
Executive Sponsorship - how important and deep is top management support?
Project Management - is a strong project management discipline in place and working?
Change Management - is the project scope being effectively controlled by the stakeholders?
Third Party Relationships - is the working relationship with hardware, software and integration vendors being effectively managed?
Resource Availability - are the stakeholders allocating adequate resources to the project?
As we all know,
This article makes many good points. But to clarify, these types of tools have existed in the org change management realm for quite a number of years (since at least the early 90's, though not always automated) to test for the implementation risk and implementation success factors of major change initiatives (e.g., IT projects) in many of the same factors you look at, with key stakeholders. Guess there really are no new ideas out there, as the saying goes!