Seven Potentially Fatal Pitfalls on Major IT Projects
Studies continue to find a high percentage of major enterprise IT projects end up costing much more than estimated, taking much longer than expected or never delivering promised benefits. I have seen some estimates of how much money is wasted every year on IT projects that are never completed - and the numbers are huge!
What happens? Why do so many good IT projects go bad?
Over the years, I have led many IT projects and I have taken over and completed several major projects that had run into problems. Building on this experience, I have put together a list of seventeen factors I use to determine a major project's probability of success. Here are seven of the factors that can be potentially fatal on a major IT project:
Project Being Undertaken For the Wrong Reasons
The first thing I check on a major IT initiative is whether the project is being undertaken for the right reasons.
From my perspective, any major IT initiative that doesn't produce significant business value for the enterprise is probably being undertaken for the wrong reasons. In most cases, producing major business value means making the enterprise more competitive and more profitable. In today's environment, that usually means increasing sales, reducing operating costs, improving product and service quality, improving access to critical information, creating direct links with business partners or improving operating flexibility.
Many major IT initiatives are driven by technology issues instead of business benefits or requirements. If problems develop on a project driven by technology instead of business value, support for the project can disappear very quickly.
Weak Project Leadership Skills
Successfully driving a major enterprise IT project requires a blend of business expertise and project management, change facilitation and communication skills. Without this mix of project leadership skills, the probability of project success is decreased considerably.
I have seen situations where a talented person without project leadership experience has been given overall responsibility for a major enterprise IT initiatives. Some of these projects were successful - but most of the projects ended up in trouble.
Learning how to be an effective project leader in the heat of battle is not a good option. The best way to develop project leadership skills is by leading small projects and growing into larger projects.
Weak Project Management Processes
My assessment of unsuccessful projects found ineffective project management processes was a major contributor to problems with the projects. Either the required project management processes did not exist or, for various reasons, defined processes were not being used. Whenever I find a company is not using effective project management processes, I immediately start waving a red flag because I know their major IT projects are going to run into problems.
In spite of various claims that I have read, I don't think there is one project management methodology that is superior to all others. I have worked with several different methodologies that provide effective processes for defining project requirements, controlling project scope, managing vendors and service providers, controlling resource utilization, monitoring project status and resolving project problems. A methodology doesn't need to be complex or based on expensive tools to be effective. The key is having a sound methodology and using it.
Poorly Defined Requirements
Having well defined functional and technical requirements for a project is also very important. In many cases, there is a big push to get a project started and the project requirements are only superficially defined. Cutting time in the requirements definition phase of a project is very likely to come back and bite you later on a major project.
In most cases, it will pay big dividends to have a good handle on the functional and technical requirements of the project before moving ahead. The focus on the importance of requirements definition is another benefit of using an effective project management methodology.
Resistance to Change
I remember reading an article a few years ago that contended resistance to change was the only reason why so many IT projects fail. I don't buy that change resistance is the only reason why projects fail - but I certainly agree that resistance to change can trip up a good project if it isn't anticipated and addressed.
Three things to remember in terms of resistance to change on a major IT initiative. First, it will always be there. It may be well hidden, but it's there. I've found resistance to change is actually easier to address when it's open and vocal. It's a lot harder to handle change resistance when it's subtle and sneaky.
The second thing to remember is that overcoming resistance to change is a never-ending challenge on major IT projects. Building buy-in for a new system and new technology begins in the earliest stages of an IT initiative and continues throughout the life of the project.
I have found the best way to overcome change resistance is by building support from the bottom up on major projects. Getting buy-in and support from the people who will actually be using the new system or technology works a lot better than trying to force change on people. From my experience, people will actually embrace change if they understand the benefits change will bring - for them and for the enterprise.
The third point on change is that many organizations are at or very near their capacity for chance because of ongoing streamlining and the frenetic pace of today's highly competitive environment. Project related changes that would not normally be a problem may run into stiff resistance now because an organization just can't handle any more change. That makes anticipating and addressing change resistance even more critical to the success of major IT initiatives.
Critical Processes are Not Optimized
The importance of redesigning critical processes before introducing new technology has also received a lot of attention over the last few years, but it's still a problem with many major IT initiatives. New technology is implemented without optimizing the underlying processes - or new systems are implemented and then an effort is made to redesign critical processes as an afterthought.
There is an old cliché in the IT world about "not paving the cow paths" - which means don't use new technology to automate old, inefficient processes. Installing new technology without optimizing basic processes first can create significant problems and minimize - or eliminate - the benefits that should be achieved with new systems. Don't pave the cow paths!
Poor Project Communication
The importance of effective communication - both inside and outside the project - seems so obvious, but I continue to see it as a major factor on problem projects. I guess I shouldn't be too surprised, because ineffective communication seems to be a problem with a lot of organizations.
Without effective communication, even minor issues or problems can have a significant impact on a project. Effective communication is also a key to breaking down change resistance and other barriers that are typically associated with a major IT project.
I recommend 50% of a project leader's time be spent on communication - with members of the project team, project customers, project partners, project sponsors, enterprise IT management, other functions within IT and senior executives of the enterprise. It's impossible to over-communicate on a major IT initiative.
MORAL OF THE STORY
I think it was Albert Einstein who defined insanity as doing the same thing over and over again and expecting different results. By his definition, many companies would have to be declared insane when it comes to major IT projects. They keep making the same mistakes over and over again - and then they wonder why their projects run into problems or never deliver promised benefits.
The next time you are preparing to launch a major enterprise IT project, ask these questions:
1. Is this project being undertaken for the right reasons? Will the project produce significant business benefits and value?
2. Does our project leader have a track record of success with major IT projects?
3. Are we using an effective project management methodology?
4. Are the project's functional and technical requirements well defined and understood?
5. Are we prepared to effectively address anticipated and unanticipated change resistance associated with the project?
6. Have critical functional processes been optimized or will the processes be optimized as part of this project?
7. Do we have structures in place to ensure effective project communication - within the project and at all levels of our organization?
If the answer to any of the questions is "no," there is a good chance your project is headed for trouble and someone should start working on the explanation of why the project cost much more than estimated, took much longer than expected and never delivered promised benefits.
Bruce Skaistis is the founder of eGlobal CIO. He began his career as a consultant with Arthur Andersen and was CIO of a large bank group before forming his own management services firm. He has extensive enterprise IT management, process optimization, and action facilitation experience.
Copyright ©2007 Global CIO, Inc. All rights reserved. Used by permission.