How to Plan For Failure in IT Projects

Problems? What Problems?

Information Technology projects are complex by nature. Projects will have myriad heterogeneous components interconnected on multiple layers. With this complexity, opportunities for failure abound. Some failures will be unexpected, if not entirely unpredictable. We’re sure to have problems, large or small, so we should plan for them. Let’s identify the types of problems specific to IT projects.

• Bugs

Unforeseen problems with software applications, application servers, platforms, and APIs are just part of the development process. Modern bug checking and testing software helps with “ordinary” bugs, but they aren’t perfect. Build in contingencies for intractable bugs before they happen.

• Development & Integration Difficulties

Some IT difficulties arise from the fact that some goals are harder to reach than others. Take time up front to assess the ease of integration of chosen components. Objectively determine how difficult development will be. Don’t guess!

• Feature Failure

When a feature can’t deliver what it promises, that’s Feature Failure. It’s related to bugs, but distinct because the feature may simply not do what’s needed, rather than crash or do the unexpected. It’s not always possible to test all functionality in advance.

• Scope Creep

It’s important to define in advance precisely what the goals are and the requirements to meet those goals for each phase of an IT project. Stick with what’s planned and get done on time and within budget. Even if something seems simple to add, if it’s not part of the plan–don’t do it. Don’t succumb to scope creep, it’s the kiss of death for IT projects.

Solution Strategies

Your strategy for dealing with major problems should include options that allow (as much as possible and practical) for the project to continue to completion. Identify what may be show-stopping failures in advance. Lay out options to resolve potential critical problems. Have a fallback position that preserves what successes you have had during the project, when possible. No one with an interest in the project wants to scrap everything and start over because you can’t find a way forward.

For software component problems where the developers, administrators, or vendor support just can’t make something work, have time, resource, and level-of-effort estimates prepared in advance for the best alternative solutions. Yes, it’s more work up front, but not as much as it might seem. During the needs assessment and architecture planning stage of the project, you should compare and contrast the pros and cons of various solutions.

For example, whether your application server platform is .Net or Java, you have looked at multiple vendor solutions (unless your project consists entirely of custom code written in-house). Vendor A’s offering costs more, but has less integration required. Vendor B’s solution has more features and costs less, but would take more time to integrate. You also evaluate the time and cost for a purely custom solution coded in-house or by contract. You should already have a good estimate of how much additional time and money is needed to switch tracks and go forward with an alternative solution.

Planning Techniques

A few simple additions to your project plan can make a big difference in problem identification and resolution.

• Have a project recovery plan.
• Create a flow chart for the project technical path.
• Critical decision points and major changes in direction are easy to visualize graphically, and logical decisions can more easily be made. Define decision trees for potential failure points. Having an “if this happens, then do that” logic outlined in advance can save time and effort.
• At the beginning, create matrices for scoring solutions to find the best fit. Rank options by time, money, difficulty/complexity, and merit or value. If you need to change solutions later, you’ll know which option is the next best choice.

Moving On

My best advice, in short, is “don’t throw up your hands,” “don’t dig in your heels,” and “don’t get emotionally invested in a particular solution.” Flow charts and decision trees with critical decision points clearly visible and understood in advance will be a big help when failures happen.