A Big Reason Why Large Government IT Projects Fail

Greetings Leaders!

I’ve been consulting in State and Local Government for 15 years and have seen quite a few things during my career. There have been successful projects for sure, but sadly, there have been many failures too. As I look back on my experiences, there are patterns that stand out between the good and the bad. I want to pass one of these on to anyone preparing to launch a large multi-million dollar IT project, in the hopes that you can avoid this deadly mistake.

A major reason that large government IT projects fail is because the Project is poorly phased.

Successful projects are broken down into phases. Large multimillion dollar projects should be broken up into several phases, with checkpoints after each phase to ensure that the project still makes sense. To illustrate this point, let’s say that a department wants to write a custom built application to replace an aging legacy application written in outdated technology. The department does some research on similar applications and comes up with a price estimate and a deadline. The department gets the go ahead to start the project, creates an RFP and awards it to a vendor. Sounds reasonable, right? Wrong!

I can almost guarantee that this project is going to come in late and over budget. Why? Because the project was sized before the requirements were developed. What normally happens in this case is that the requirements will be poorly done because a potential solution(s) was identified during the early research. At this point, have the end users, the ones who will actually use the system or application, been consulted? The answer is usually no.

An RFP is then written with unclear requirements, and vendors, not knowing what they are getting into, bid on the project based on high level requirements. As work begins, more detailed requirements are finally gathered (if you’re lucky), and the scope of the project begins to increase. The reason it increases is that the end users are finally allowed to define the requirements, and they use this opportunity to fix all the things that were previously broken, or that are on their wish list. Things that weren’t considered when the project was first conceptualized. What was a “like for like” project, now takes on a new twist as new requirements are being thrown into the mix.

The increase in scope begins to push hard on the original project date, and people start to get uncomfortable. The vendor begins to push back on the department, saying these requirements are out of scope. The department begins to sweat as the end users begin to complain that the system will not meet their needs if these additional things aren’t added to the project. In the meantime, the clock is ticking and the requirements are beginning to extend the schedule and perhaps at this point, several million dollars have already been spent doing the RFP and initial requirements.

Not having a phased approach, the department has already committed itself to the project and  continues down the path of trying to complete the project with these additional requirements. One of two things will happen at this point, neither of them necessarily good. The project continues pushing towards the end date without officially changing the scope, budget or schedule. The due date comes, the project is not delivered and the vendor and department end up in court. The second option is that the scope is increased, the schedule pushed out, and the budget increased to deal with the increased scope. While one could argue that this is a good outcome as the project gets done, my argument for failure would be that the project ended up costing the tax payer a lot more than originally planned for. If the final budget were known at the beginning, perhaps the project should never have been started.

How to Avoid This Situation

The answer is simple. A Phased approach. If a department wants to upgrade an application, start off with getting approval to define the requirements properly. Estimate how long it will take to gather the requirements, and take this as Phase I. With requirements in hand, enter Phase II and prepare an RFP – with detailed requirements – and let the vendors come back with their proposals. Assess the proposals and do a cost benefit analysis of doing the project. If the project is justifiable, get approval for it and begin  Phase III, the actual project itself.

Following this Phased Approach will help define requirements up front, allowing the vendors to give you a proper estimate and bid. This will in turn allow for a good cost benefit analysis. If at any point the project seems unreasonable, you spent just a small percentage of what you would have, if you went down the original path described before.

All the best!
All the time!
JT

Enhanced by Zemanta

One thought on “A Big Reason Why Large Government IT Projects Fail”

  1. John,

    Thanks for the reference! Great Blog and I entirely agree. Even in the speedy days of Agile, an overall phased approach will tend to lend a sense of security to the successful completion of a project.

    Regards,

    Carl

Leave a Reply