Introduction
Have you ever been part of a failed IT project? If analyst research over the past 5 years is even close to being accurate, the answer is YES. Lets take a look at the definition of a successful IT project. A successful project is any initiative that satisfies all 5 of these criteria:
- • Completed at or under budget.
- • Completed on schedule.
- • Meets sponsor objectives.
- • Meets defined requirements of features and functions.
- • Customers score the product as satisfactory or better.
If your projects do not meet all five success criteria, all the time, you need to read further to learn the roadblocks to avoid and the actions to take to make current and future projects successful.
Numbers Talk
The Standish Group Chaos Report (2003), a study of over 13,000 projects, shows project success rates have increased over the past 10 years, but still shows that 2 out of 3 projects are not successful. The Chaos report shows only 34% of projects meet all the criteria for a successful project. Challenged projects, those that only met a few project successes criteria measurements, contributed to 51% of the projects. Failed projects, those meeting none of the project success criteria, contributed to 15% of the projects. As with other research reports, it is safe to assume that today's IT project success rate is between 28 to 35%.
The Standish Group Chaos Report (2003) also shows the lost dollar value for US projects is estimated at $38 billion with another $17 billion in cost overruns for a total project waste of $55 billion against $255 billion in project spending.
The bottom line is, 21% of the money your organization spends on IT projects is thrown away. That means, for an organization that budgets $10 million for IT projects this year, they will be receiving no value from $2.1 million of the money spent.
For consulting service organizations who specialize in turn-key projects, the data can be viewed another way. If their organization is financially responsible for the success of $10 million in a project portfolio, they could be performing $10 million of services work while only generating $7.9 million in revenue.
In the article Why Do System Implementations Fail (Sommers, 2003) a survey of 417 IT executives and managers lists 36 items to mitigate during a project to improve project performance.
After years of project successes and roundtable discussions with IT and business executives across the country, I have identified the “TOP 12” IT project mistakes that must be avoided.
1. Project Is Not Part Of The Strategic Plan
A strategic plan identifies your company's business goals and the solutions needed to support those business goals. If a project does not line up with one of the items on the strategic plan, you should not do the project.
Many organizations are in “re-active” mode. Their focus is on the hottest fire of the day. These organizations usually look at a strategic plan once a year or sometimes never create one. Within these organizations, project failure is more prominent than project success. What is the key? Projects aligned with business goals on the strategic plan will “add value” to the business and your customers.
A large manufacturing organization implemented an expensive application monitoring solution that was implemented on-time and 13% over budget. The justification for the project: Help desk staff would better understand the user application needs and problems when they called in with an issue. The project team considered this a success, plus they had some cool technology to play with.
Unfortunately for the project team, the CFO attended the project de-briefing. The CFO's only question to the team was: “How does this product help us produce more widgets, reduce inventory, or improve customer service?” After a minute of silence and blank faces, the CFO then stated that this project was a failure and just cost us $300,000 plus, returning no value to the business.
This project team learned a lesson the hard way.
Roadblocks
- • Non-strategic projects are first to be cancelled.
- • Team members and other resources are pulled for high priority “strategic” projects.
- • Executive and business unit time commitments are limited.
- • Project budget is reduced.
- • Executives and business units are slow to respond to critical issues, risks, or project activities.
Action To Take
- • Identify which item on the strategic plan your project supports.
- • Understand the priority of this strategic plan item.
- • Understand the “value” your project brings to the business.
- • Decide whether the risks are to high to continue.
2. No Executive Sponsorship
Executive sponsorship of your project is vital for project success. Active sponsor participation has historically ensured a project will be on-time, within budget, and meet the business goals. Take a look at the projects you have been involved in over the past year. When there is an executive sponsor sitting in status meetings, reviewing plans, meeting with team members, etc. the project team stays focused on the project objectives, roadblocks are removed immediately, and morale is up.
Project teams seem to feed off the executives leadership and focus. Projects that are delegated down to line level managers seem to float along, stop when issues arise, and go in fragmented directions. These projects have a higher risk of failure.
Roadblocks
- • Project does not get the right level of support when needed.
- • Project goes in fragmented directions.
- • Issue resolutions are slow to arrive, sometimes causing a stoppage of the project.
- • Project lacks focus.
- • No leadership.
Action To Take
- • Identify the technical, business, and financial sponsor.
- • Determine the sponsors participation in the project.
- • Elicit sponsorship from C-Level executives who will receive the greatest value from the project.
3. Poor Technology Evaluation
Many project failures start at the beginning. The evaluation team is knowledgeable on some aspects of the technology but they do not spend enough time researching solutions and they believe all the hype from vendors and industry media.
We have found successful project teams perform an intensive due diligence upfront by using tools like RFI's, RFP's, client visits, demo's using live customer data, etc. Asking the tough detail questions in the beginning can save your return on investment at the end.
Roadblocks
- • Products selected do not work.
- • Products selected have never been implemented before.
- • The correct components were not budgeted or purchased until later in the project.
- • Vendor goes out of business before project completion.
Action To Take
- • Perform an intensive due diligence upfront.
- • Verify reality vs. vaporware.
- • See it, tough it, and use it in a comparable environment.
4. No Customer Involvement
Successful projects need input from the people who will be affected most by the project. The customers should be consulted on the value they will receive from a product. When implementing an inventory control system, your best feedback will come from the inventory control clerks and supervisors. They better understand the business processes and how to improve efficiencies than anyone else on a project team. These customers can best help with process improvements, features, and functions.
Another key factor on customer involvement is “who” will be included on the team. Successful projects have the best and brightest customers on the team. These individuals make the best decisions in a more timely manner. Also, their time is committed to the project to avoid day to day business priorities that would normally take them away from the project.
Roadblocks
- • Products developed do not meet customer needs.
- • New business process reduces productivity.
- • Product design takes longer than expected.
- • Product is not accepted by the customers.
- • Products developed do not provide a return on investment or add value to the business.
Action To Take
- • Assign the best and brightest customers to the project.
- • Commit customer time to the project to avoid day to day priorities.
5. Scope Creep
Adding additional scope without testing it against the business case and evaluating the impact on the cost, schedule, and risks is the easiest way to sink a project. Modifying products is risky and the most common form of scope creep. The project best practice is to implement quickly, get the benefit quickly, and modify later. As an example, waiting on software features is better than getting off the vendor upgrade path.
A large retailer implementing a retail management system decided their operations were so unique that they changed 90% of the programs during a two year, $11 million implementation. During the development phase of this project, the vendor released a new and improved version of the software. Once the modified package was implemented, the retailer looked at upgrading to the new release. First, they found that they were not eligible for software upgrades since they modified the code. Second, analysis determined that they would need one full year of programming effort to input the same modifications into the new release. End result, they will be customizing and running this system until it breaks or they can cost justify the purchase of a new system.
Roadblocks
- • Development never ends, product changes frequently.
- • Modifications to product during initial development drastically increases your risk of failure.
- • Getting off the vendor upgrade path.
- • Unexpected increase in cost, effort, and duration.
Action To Take
- • Only modify products if business critical.
- • Test the change in scope against the business case.
- • Evaluate impact on cost, schedule, and risks.
- • Implement scope changes in the next release.
- • Set up a Change Management Committee.
6. Invalid Pilots
Pilot phases of a project can be very enlightening. What a great tool, test the product in a smaller real life environment. Failure occurs when the pilot does not simulate reality.
A mid west distribution company built a brand new lab environment for the new Back Office System project. The pilot was a complete success. Problems started occurring during the rollout of the software to remote locations. Unknowingly, a project lead asked “What is the hardware configuration of the pilot test lab?” What did they find? The lab was built with the latest and greatest server and desktop hardware. The remote facilities were running hardware from five years ago and did not support the new software.
Roadblocks
- • Pilot lab equipment does not mimic reality.
- • Works in the lab, not on the product floor.
- • Product can be a complete failure on the first day it is released.
Action To Take
- • Before starting, document an accurate inventory of all hardware, software, and other production environment information.
- • Validate the pilot tests for all environment configurations.
7. Inadequate Testing
Question: What is the second item cut when a project is low on funding or over budget? Answer: Testing of course.
Limiting your testing of a solution will increase the chance of system failure or unknown bugs that can cripple your business. Do not skimp on testing to save time or money. Eliminate features first.
To limit project failure, the testing phase should consist of system test, customer acceptance testing, volume testing, and stress testing to test scalability.
Roadblocks
- • Dramatic increase in product bugs.
- • Dramatic increase in quality issues.
- • Increased risk of product failure.
- • Increased costs during deployment and support.
- • Low customer satisfaction.
Action To Take
- • Eliminate features before cutting back on testing.
- • Testing should include system test, customer acceptance test, volume test, and stress testing.
8. Poor Planning
Rolling out a product to one location is fairly simple. Now, take the same product and try deploying it to hundreds of locations across the country simultaneously. Multiple location deployments are more of a challenge to do quickly and cost effectively. Larger deployments require more planning due to greater chances of conflicts and timing issues. Proper planning of equipment and resources will make or break the project.
Roadblocks
- • Number of outside locations to deploy products increases project complexity and risk exponentially.
- • Unknown conflicts and timing issues delay project.
- • Unexpected staffing needs.
- • Unexpected equipment and supply needs, increasing cost of project.
Action To Take
- • Perform a detail plan before the start of the project
- • Review and adjust plan on a daily basis
9. Rolling Out At The Wrong Time
Proper timing of a project “Go Live” is an important success factor that is often challenged by missed milestone dates. Business sponsors want solutions implemented before peak times where it will provide the greatest benefit. However, pilots and testing cannot be sacrificed. Pressing your luck on the timing of a rollout can be disastrous.
A small specialty retailer was behind schedule on a warehouse system implementation. The original planned completion date of the project was one month prior to the Christmas rush where the facility pushed through 1/3 of the yearly volume. Scope creep added an additional 2 months to the project, but the new date was not acceptable. Limiting the software testing reduced this overage by 1 month. Therefore, the team was behind schedule by 1 month, but could be implemented days before the Christmas rush.
This new software was so important to the business that they made a decision to “Go Live” the weekend before the heaviest volume would arrive. Due to poor testing, the system could not handle the warehouse volume which slowed productivity and delayed shipments to the stores. A project post mortem review estimated a $13 million loss of sales caused by the poorly timed system roll out.
Roadblocks
- • Missed milestones and a “Go Live” date that cannot move will sacrifice other key project needs (i.e. testing, pilot, etc.).
- • Peak volume season sounds good to the business but adds unnecessary stress and risk.
- • Conflicts with other projects and initiatives targeted for the same period of time.
Action To Take
- • Once a “Go Live” date is available, evaluate the business cycle, other project dependencies, alternative dates, etc.
- • Understand why the business needs a solution by a certain date.
- • Allocate enough time between “Go Live” and Peak Season to work out any last minute kinks.
10. Limited Training
Training is the first thing cut from a project when funding is low or over budget. You get the product released and the sponsors will not spend additional money on training. Without proper training, the new system will not provide the expected return on investment. Additionally, poor or no training will lead to low customer acceptance resulting in a failed project. To receive value, the customer must know how to use the new product.
Roadblocks
- • Low customer acceptance.
- • Increased costs during deployment and support.
- • Low morale and decreased productivity.
- • Lost revenue.
Action To Take
- • Prepare a low cost training alternative.
- • Involve customers more during the product testing.
- • Eliminate features before cutting back on training.
- • Delay the project if possible.
11. Underestimating Change To The Business
Change management involves the business process changes necessary to succeed. When implementing software, failure occurs most of the time when the project sponsors do not understand that they must change the business to work with the software or change the software to work like the business.
Managing change is more difficult in organizations with high turnover, lack of education, or high stress environments. To successfully manage change, a project should have 25 to 35% of the budget allocated to change management. This allocation will lower the project risk and provide a cushion toward project success.
Take, for example, the shoe company that implemented a warehouse management system to increase inventory accuracy and throughput. The project was, from the beginning, focused on software features and functions. Little attention was given to current and future operating practices on the warehouse floor, how they could improve and must change. In the end, the implementation resulted in a 1.2 million square foot facility that was very adept at quickly losing product. If process improvements are identified early, as part of the business case effort, they are much more likely to be carried through to implementation.
Roadblocks
- • Project and business processes are not aligned.
- • Business process changes are not considered until the end of the project.
- • Drastic process or project changes required at the last minute causing overages and delays.
- • Results in reduced or negative ROI.
Action To Take
- • Understand the business process impact of the solution at the beginning of the project.
- • Allocate a 25 to 35% change management budget (time and cost).
- • Set up a Change Management committee with the business.
12. Avoiding Risk Analysis
No one likes discussing project risks. It is human nature to think positive, that nothing will go wrong. Sometimes success or failure is determined by how well prepared a project team is when disaster occurs. If they project team or organization is not prepared, the project may stop unexpectedly until a new plan can be executed.
During a project milestone review session at one financial services company, the project manager was asked “risk type” questions like, “What are the chances that vacations will slow down the project?” and “What affects will a union strike have on the project?”. The project manager answered with one statement, “We don't worry about those things, we are her to code, test and install this application”. As you guessed, no one analyzed the risks so no mitigation plan was in place. In the end, consultants were hired to make up for low staff counts, the project was over budget by 43% and implemented 4 months late.
An insurance company that ran a skeleton staff always ran projects by the seat of their pants. Plan were sketched out on scrap pieces of paper and planning for the unexpected was considered a waste of time. During a hardware and software upgrade that was to be implemented before year end processing, there was no contingency plan if the hardware was late. Due to production problems, the new hardware was delayed for 2 months. Two weeks before the “Go Live”, they were scrambling around looking to rent hardware. Unfortunately, the project was not implemented before year end.
Roadblocks
- • Nobody likes discussing “risks”.
- • Project teams are not prepared for disaster.
- • Unrealistic view of the project status.
- • A .01% risk probability can stop a $100 million project dead.
- • Unexpected project delays and cost overruns.
Action To Take
- • Day 1, start a risk management log.
- • Identify risks throughout the project.
- • Continually revise risk mitigation and contingency plans.
