The US Air Force recently announced one of the largest IT project failures in history. My favorite line from the article comes from Michael Krigsman, CEO of consulting firm Asuret and an expert on IT project failures – who asked, “Why did it take the [Air Force] $1 billion and almost 10 years to realize this project is a disaster? What kind of planning process accepts a billion dollars of waste?” Now, I’m sure you’re asking yourself the same thing I did, how does one exactly become an expert on IT project failures anyway? But all jokes aside and getting back to the point on hand, let’s examine some common areas that show us how IT projects fail.
- Setting Accurate Expectations. This is actually common sense that everyone carry everywhere in their lives. And yet, this is what most often gets violated. We all love to impress folks and make them happy, it’s in our nature to spotlight the good and shadow the bad. Don’t do it. Rarely does anyone intentionally weave a web of deceit; it’s something that incrementally becomes built as a result of piling fibs onto each other. It happens way too often because it’s too easy to start and too hard to stop. So simply, don’t start. If you do, remember there will be a day of reckoning. I guarantee this rule is violated in all IT project failures.
- Strong Initial Design. Identify and decide on all design requirements upfront, this will minimize delays and critical changes to specifications. This is an important point folks not intimately familiar with a technical design environment may often need some help understanding. Speaking metaphorically in terms the audience can better understand to illustrate the picture can sometimes help. For example, you can’t bake and make a cake and then decide afterwards to change the filling. The bigger a project is, the more important this becomes. If this aspect is neglected in any shape or form I promise you the project will go down in a spectacular ball of flames.
- How, Not Just What. Let me explain. Too often during design do people focus on what they want rather than just how they’re going to get it. I especially see this neglected most in projects where the “how” should be most important. Often times in data-centric projects. If someone is not intimately familiar with the data or general data integration concepts it’s easy to underestimate the complexity. If you ever hear anyone say, “Oh, it’s just data” you should either A) run away or B) prepare the guns. The easiest way to explain this is to picture each computer, system, or application being from another country and speaks a different language. You need data “translators” to make things work. Anyone who is bilingual will be first to explain everything isn’t 100% translatable and this fact is exacerbated with computer data. This area is very technical which is why it is not even brought unless there’s someone technical present during discussions. If you don’t hear words like XML, SQL, databases, files, data integration, ETL, or something of that nature, you’re painting a bull’s-eye on the project for failure.
- Mitigating Design Changes. This goes hand-in-hand with the above items. It’s unrealistic to expect everything is completely frozen and nothing can be changed, but it has to be understood the fundamentals have to stay the same. But just envision that every time a change is made, no matter how small, that deadline likely has travelled further away from you. So take that into consideration and determine if it’s worth the risk to jeopardize the project and patience of your target audience. Explain changes thoroughly and don’t hide any delays. This is an ongoing, relentless, battle that won’t be won until well after delivery. So keep fighting the fight or you’ll lose enough ground to be considered a failure.
- Testing. If we lived in a world where everyone is perfect in all communication, design, implementation, execution, and delivery we wouldn’t need it. But such a world doesn’t exist. Be prepared to spend as much time on testing as you did on implementation, or more. If you don’t, be prepared to be booed off the stage when handing over the product to the target audience. Everyone must also learn to embrace the inevitability of finding something during testing that will require plenty of tweaks and unforeseen changes. You have to consider your project still in progress (incomplete) during this stage. So leave enough time, resources, and money for it otherwise the project will be considered a disaster before it’s even considered finished.
- Delivery. It should go without saying that all the above needs to be completed before reaching this stage, and yet I feel an absolute need to say it. I always picture this part of the stage like those last moments on the stretch before crossing the finish line. The project should be given every last ounce of effort instead of sputtering or prematurely calling the project complete. Plenty of things can still go wrong, and they do. Ensure there is a proper delivery schedule laid out, proper training is given, and documentation is provided.
Here’s a list of the most infamous IT project disasters over the past decade to show you these things happen to even the best of the “best”. Here’s a cartoon for anyone who has worked on a difficult project would find some humor in:
Most people would agree, you can do anything with enough time and money. But it’s usually one or both of those ingredients which makes a project call out “mayday“. However if you are considering an admission application software project I encourage you to browse our solutions. We proudly carry 100% customer satisfaction and success rate. So feel free to contact us or drop us a line to reshape the way your collect and store applicant information today.