Every technology project has risks

Introduction

The focus of every manager / executive's concern has to be risk. Every technology project has risks, and some have more than others. Here is a sampler of risk types...

Emergent risks

• New technology
• New platform
• New application area
• New architecture
• Unexpected bugs in the substrate

External risks

• Requirements changes
• Scope creep
• Budget shrinkage
• Budget expansion (yes, this is a risk)
• Management loses confidence
• Operational personnel resistance to changes

Design risks

• Inflexible design cannot meet minor scope / requirement changes
• Design has a strong and comprehensive critical path
• Thrashing the design during development
• Neglect of key ethnographic factors in the user population

Implementation risks

• Unexpected implementation fan-out
• Unexpected component interdependencies

Decision risks

• Wrong decision on buy vs. build
• Wrong priorities

Personnel risks

• Bad morale
• Unconsolidated team
• Loss of a key performer
• Poor development or debugging styles
• Deathmarch "get it done, no matter how" mentality
• Premature optimization mindset

Project management risks

• Poor reporting leads to surprise delays
• Detailed task oriented scheduling leads to massive PM overhead
• Excessive coupling between independent development teams
• Too many meetings
• Meetings too large, poorly focused
• Too little communication
• Too much communication (mythical man-month)
• Not enough knowledge management
• Failing to identify the actual customers of the system (who they are may surprise you)

Almost every one of these risks can be mitigated by the right management style and the proper due diligence in investigation and design. Others can be mitigated by pilot projects and proof-of-concept implementations. And a few are uncontrollable, but can be dealt with using a "SWAT team" strategy. Let's have a look...

Dealing with Risk

Risk is something you need to deal with right from the beginning. When you have a concern about a component or a platform, you need to do testing of those concerns before attempting to schedule a project. When you have concerns about personnel or project management, you need to select a style and a methodology that will suit the project and stick with it.

Above all, you need to be consistent. The appearance of a risk factor as a real problem can be intimidating and disruptive, but it will be even more damaging if you allow it to throw chaos into your project. In almost every case, your design, your methodology and your management style, if properly selected, will be resilient enough to stand the strain - but if you throw them away or radically change them to deal with a problem, you will introduce a whole new set of risks - including personnel risks - that may be impossible to correct.

Mitigation in General

There are a few general strategies that can mitigate risk...

• Know your customers well.
• Design well.
• Use an incremental and evolutionary methodology to keep the rhythm of delivery at the right tempo.
• Build a proof of concept for anything worrisome, and build it right away. To mitigate concerns by management that you are wasting time, try to design the proof of concept so it can be evolved into the actual system, or so that its components can be reused.
• Keep your team on the "rested edge" not the "ragged edge".
• Never let the politics filter down into the team.
• Let the customers steer, but provide the road, and make sure you are driving.