6 reasons why your IT project will fail

​Here are six of the most common project implementation problems—and how you can avoid them.

Tips for how to become a project manager In this intro for TechRepublic's how to become a project manager cheat sheet, Alison DeNisco Rayome discusses what the job entails, why it's in demand, skills needed, interview questions, and more.

There are many reasons why IT project implementations can go wrong: Lack of planning and management participation, underestimating resources, failing to manage user expectations, too much customization and tweaking at the end of the project, and insufficient testing, to name a few.

All of the above are project implementation problems that can come back to haunt you.

The good news is that you can eliminate these problems if you recognize them early.

SEE: Policy pack: Workplace ethics (Tech Pro Research)

Here are six of the most common project implementation problems—and how you can avoid them.

1. IT doesn't understand what project implementation is

In my career, I have managed three different IT departments in three different industries. None of them understood what project implementation was. From an IT standpoint, a project was deemed complete once all technical project tasks were checked off, and the project was installed. Not so.

The solution: Define and task out project implementation as thoroughly as you task out project planning, development, testing, staging, and installation.

To properly implement a project, you must fully perform the last stage of project acceptance and adoption—a stage that won't successfully complete unless you train users on the new product you developed, support them through deployment, ensure that end business expectations are being realized, etc.

SEE: IT project cost/benefit calculator (Tech Pro Research)

2. Users don't like the finished product

Many projects fail because users and IT get together at the beginning of a project and define requirements, but then IT works independently of those users to develop the system. When this happens, "drift" occurs between what IT builds and what users want. This is where concepts like Agile software development really help, because users, and IT work hand-in-hand throughout the project's lifecycle, which ensures that the product IT develops stays true to what users wanted in the first place.

You also want to avoid unveiling a product, which is finished in IT's eyes but totally (and unfavorably) surprises end users. There should never be any surprises in projects that IT installs for end users.

The solution: Throughout your project, whether you use agile or traditional waterfall development, continuously communicate and work with end users to ensure that the project stays in sync with user expectations.

3. Users can't use the product

Many brilliant IT projects fall into disuse because user interfaces are so unfriendly that users just abandon the projects. Designing an effective user interface is as important as doing the application logic itself.

The solution: Ensure that end user interface design stays a major focal point in IT project work, and do not implement a project without a sign-off from the users on the user interface.

4. Users don't want the project to end

Changes to project code (except for eliminating bugs) should be put on hold during project implementation. Unfortunately, some users (and IT) continue to tweak and enhance apps during implementation. This creates issues. Why? Because now you have "enhancement creep" entering your project—and there might be a need to retrain users as well.

The solution: Implementation is not the time to tweak any apps—unless you are resolving errors. Once the app is installed, and users have a chance to exercise it, a future enhancement phase can be scheduled.

SEE: Cloud providers 2019: A buyer's guide (TechRepublic download)

5. The product doesn't work

To meet project deadlines, I have seen IT department throw apps "over the wall" before apps were ready for production. Once, I even came across a subroutine from an outside vendor that didn't even compile cleanly.

There is no excuse for this.

The solution: Before you implement any project in production, the project should be:

  1. Unit tested;
  2. Integration tested;
  3. User tested;
  4. Regression and stress tested in staging—and only then ported over to production.

6. IT moves on to other things

There are many important projects on IT's plate, so it's tempting to wash your hands of one project that you feel is completed and move on. Meanwhile, the users of a recently installed new project are still experiencing issues as they learn to work with the new app or system.

The solution: Implementation doesn't end when you move an app or system into production. For the first three to six weeks of a new system, IT should continue to provide heightened levels of support and issue resolution to users so that successful system adoption can be assured.

Also see

istock-1018188310projectworkers.jpg
Image: jacoblund, Getty Images/iStockphoto