Tactical Risk on IT Projects

Part I of this series talked about IT Risk at the strategic level. Part II is tactical: now that your project is approved and rolling, where are your risks and how do you manage them? Here’s my Top 10 List of IT Project Risks:

1. Constantly shifting business needs and priorities. Being nimble is great, but when business needs don’t settle into a clear vision after a while, it’s time to step back and reassess. Is your IT project tightly aligned with a well-articulated business objective? Is your software implementation team able to complete the tasks being asked of them? Does your project have a clear release plan? IT Project risk is greatly reduced when everyone agrees that the business objective is worth the effort and expense.
2. Unrealistic implementation plans. Employees take vacations, get sick and leave the company unexpectedly. Even the best teams are subject to simple mistakes with far-reaching consequences, less than stellar decisions and taking short-cuts under pressure. Building implementation plans based on best case scenarios are all but certain to fall short.
3. Unaligned stakeholders. An IT project cannot be all things to all influencers. There can only be one vision. It can be a tough negotiation but it is worth every minute it takes.
4. Lack of ownership. If you’re going out on a limb with an implementation project, it is one thing to say you’ll cut the strings at a certain benchmark. It’s quite another to know how you’ll be monitoring that benchmark data, how it will be communicated, and who is ultimately responsible for pulling the plug.
5. Inconsistent productivity levels. Developers love the cutting edge of not-quite-yet-proven new technologies but their quirks can consume a lot of time. So can bringing too many new team members up to speed at once or expecting employees to sustain unreasonably long hours for an extended period of time. Any of these strategies can negatively impact productivity for a period of time. If you plan to use any of these tactics on your project, it would be wise to monitor its impact on your team’s productivity.
6. Inappropriate productivity tools. No team can sustain a momentum without decent version control software. But even the best version control tool on paper might not be aligned with how your team likes to operate. Choose software productivity tools that complement how your team works. This applies to bug tracking, build and release, and test tools too. Don’t ignore desktop hardware either. A little more CPU muscle can often see a ROI in a matter of weeks or months, especially if the performance of your software productivity tools is sluggish.
7. Conflict of interest regarding “customer-ready.” A developer makes code work, a tester makes it break. A tester thinks like an end user. The Test organization should never report into Development.
8. Burnout. Find out your team’s burnout point by correlating overtime hours to the number of software bugs found in new code. Then stay well below this point of diminishing returns.
9. Learning organization. Many organizations have post-project reviews where team members discuss what went well and where they could improve next time. But how many take it a step further, actually incorporating those opportunities for improvement into business practices? This doesn’t have to be elaborate or formal if your company values neither. The goal is to share the learning beyond the original team members so that everyone benefits from the lesson.
10. Unstable maintenance costs. Fluctuating maintenance costs can be a key indicator of inconsistently applied version control policy or inadequate testing. It’s is generally not difficult to cost-justify infrastructure improvements as a more manageable expense than unanticipated rework.