Simply put, IT projects fail not because of what we do, but because of what we haven’t done!
Conventional wisdom suggests that we can identify a set of reasons for project failures post implementation. As Michael Krigsman highlighted in his blog "Six types of IT project failure", classifying the reasons for failure can often illuminate Root Cause for project failure. However, in my opinion by simply categorizing failures often leads organizations to incorrectly believe that there were only one or two aspects of their project that caused it to fail.
My research has identified that the genesis of project failures is in fact an organization's pre-implementation strategic decision making (or lack thereof). The symptoms or reasons for the failure are easily classified but the root cause is often buried because it becomes almost impossible to unravel the causes after a protracted period once the project has failed.
Furthermore, I have found that simply identifying reasons for IT project failures can in itself lead to "Scapegoating" of the parties that were responsible for that element of the project (e.g. the Project Sponsor, Vendor or Project Manager ).
In the case of the Project Sponsor, mentioned in Michael Krigsmans blog, they need to be given the authority and accountability to make project decisions otherwise they will not remain actively and positively involved in the project. If they are not actively involved (with skin in the game), then they are just the "Go To” person, (which can be a pretty unenviable and arduous position to be in). This is just one example (not assigning accountability) of how poor strategic decision making by the organization before the project is initiated puts IT projects at risk.
"Failure is not a single, cataclysmic event. You don't fail overnight. Instead, failure is a few errors in judgment, repeated every day" Jim Rohn.
More often than not, what I have found is that the "Root Cause" is generally embedded in the organization as an underlying and fundamental flaw in its pre-investment strategic planning and pre-implementation strategic decision making processes.
These are executive decisions that provide the strategy for How the project will commence and What and Who needs to be included or involved.
Many of the reasons for IT project failures that I have identified, and that Mike Kavis has covered extensively, can be eliminated by addressing these key strategic decisions at the outset of a project, because the potential Root Cause will thereby be identified and addressed before the project has even begun.
Kind Regards
Sarah Jane Runge
Conventional wisdom suggests that we can identify a set of reasons for project failures post implementation. As Michael Krigsman highlighted in his blog "Six types of IT project failure", classifying the reasons for failure can often illuminate Root Cause for project failure. However, in my opinion by simply categorizing failures often leads organizations to incorrectly believe that there were only one or two aspects of their project that caused it to fail.
My research has identified that the genesis of project failures is in fact an organization's pre-implementation strategic decision making (or lack thereof). The symptoms or reasons for the failure are easily classified but the root cause is often buried because it becomes almost impossible to unravel the causes after a protracted period once the project has failed.
Furthermore, I have found that simply identifying reasons for IT project failures can in itself lead to "Scapegoating" of the parties that were responsible for that element of the project (e.g. the Project Sponsor, Vendor or Project Manager ).
In the case of the Project Sponsor, mentioned in Michael Krigsmans blog, they need to be given the authority and accountability to make project decisions otherwise they will not remain actively and positively involved in the project. If they are not actively involved (with skin in the game), then they are just the "Go To” person, (which can be a pretty unenviable and arduous position to be in). This is just one example (not assigning accountability) of how poor strategic decision making by the organization before the project is initiated puts IT projects at risk.
"Failure is not a single, cataclysmic event. You don't fail overnight. Instead, failure is a few errors in judgment, repeated every day" Jim Rohn.
More often than not, what I have found is that the "Root Cause" is generally embedded in the organization as an underlying and fundamental flaw in its pre-investment strategic planning and pre-implementation strategic decision making processes.
These are executive decisions that provide the strategy for How the project will commence and What and Who needs to be included or involved.
Many of the reasons for IT project failures that I have identified, and that Mike Kavis has covered extensively, can be eliminated by addressing these key strategic decisions at the outset of a project, because the potential Root Cause will thereby be identified and addressed before the project has even begun.
Kind Regards
Sarah Jane Runge
2 comments:
I like your article on Scapegoating (linked from here).
Now about IT Project Failure, I think there is one root cause for all the reasons behind project failure, which is lack of communication. You can think of any reason, and you can easily find that the root cause is lack of communication.
Let's say the reason is we used ASP instead of PHP, and ASP is proprietary and the client does not want to pay for a proprietary software. Had the requirements been gathered properly from the client (lack of communication) that would've not been a problem.
Another example is "The interface is not usable". Again, had there been a constant communication with the client and his/her end users that would've not been a problem.
I cannot think of any example, whether related to the client, the stakeholders, or the team where the root cause is the lack of communication.
PS: check this article on why most IT projects fail.
I think PM Hut makes a good point, however, I still think that although senior managers are capable of visualizing the benefits of a new system, they often don't realize how complex implementations can become.
Their all to often "Ready, Fire, Aim" approach where premature decisions are made is the starting point of an IT project disaster.
Sure, they should have communicated more effectively but with whom?
This brings me to my point.
Before communicating, they need to take a hard look at who the affected parties in their organization are that need to be involved or not.
This is at the all-important pre-investment stage when management needs to make sure that they have gained support for their project and that the affected parties are fully committed and accountable for their roles in the implementation.
Often this is not the case and the parties pay lip-service (poor communications in this case being a symptom of bad planning and not the cause).
Anyway, I think we're both on the same wave-length.
Cheers, Mark.
Post a Comment