THE ROAD TO PROJECT COMPLETION IS LITTERED WITH RISK

Have you ever been involved in the software project from hell? Many of us have. It begins with plenty of enthusiasm and optimism. Goals are defined. Staffing is assigned. Delivery dates and budgets are handed out. Everyone is excited.

But somewhere along the road to completion unexpected turns are encountered that impact the goals, dates and budgets. Some of the turns are minor while others feel like a roller coaster ride.

The project team seems able to regroup and move on yet the goals seem harder to achieve, the dates appear more and more unrealistic and the budget is all but exhausted.

How could this happen? What went wrong? The goals were reasonable. The schedule was detailed. The staffing was solid. What did you miss?

The answer is risk. Every project faces many risks during its lifetime. Risks are the opposite of opportunities. They are the bad things that can happen along the road to completion. Risks can be avoided using good planning. They can be mitigated with forethought. Or, they can be accepted because the benefits outweigh the drawbacks.

While risks can be sliced and diced into dozens of categories, let's examine a simple risk management approach using just four categories:

Minor Impact / Low Likelihood

These types of events might be called "glitches". They crop up from time to time on just about every project. You simply deal with them as they happen and move on. As long as some extra time is built into the schedule to manage glitches, they are not likely to cause trouble.

One example of a glitch from my own experience is a software application under development that was performing poorly. Because the production system would be much faster than the development system, we simply purchased the production system ahead of schedule and used it for development.

Minor Impact / High Likelihood

These events are "obstacles". You know that some number of them will happen so planning is essential. You need to identify the obstacles and either a) define a plan for dealing with them when the time comes, or b) plot a course around them.

Examples of obstacles are the defects/deficiencies present in an off-the-shelf software package purchased for a project. Assuming reasonable care went into the selection of the software, problems encountered with its use are unlikely to derail the project.

Major Impact / Low Likelihood

These are "surprises". They aren't likely so you don't spend much time thinking about them but if they strike, your project is in trouble. As always, forewarned is forearmed. Lay out these surprises at the start of the project and decide what you can do up front to mitigate them. Then prepare an alternate plan to deal with the surprise should it actually occur.

For example, most of us have seen projects get into serious trouble when a key contributor leaves the team.

However unlikely it may be that your "chief whatever" will leave before the project ends, it can happen and a contingency plan is required.

Major Impact / High Likelihood

Finally, there are the "tragedies". Any project facing risks in this category is in serious trouble at the outset. The management team better have lots of time and money available.

An all-too-frequent example is the geographically dispersed project team that has little in common technically, culturally or linguistically and a management team that expects them to march in unison. If you find yourself on such a project, run, don't walk, to the nearest exit.

7 Common Sources of Unforeseen Problems

Here are some places where risks hide out waiting for the innocent project manager to drive by.

Unknown Stakeholders - These are people who have influence over a project's goals, deliverables, resources or schedule. Yet the project team is unaware of them at the outset of the planning process. These folks represent a major risk factor because they often display unexpected resistance.
Fuzzy Project Scope - Every project has goals but unless the goals are detailed enough and clear enough, the result is a lack of a common understanding about what the project is intended to accomplish. If the team doesn't agree on what they are attempting to accomplish, they can't possibly get it done.
Gold Plated Requirements - Many project teams find themselves in possession of functional requirements that resemble a wish list. There are just too many nice-to-have features. Prioritize early and avoid unnecessary gold plating.
Inappropriate Staffing - The project plan shows ten people working on the application so ten people are assigned. But are they the right people? Do they have the proper skill sets? It takes more than just warm bodies to deliver success.
Infrequent Deliverables - The software industry is notorious for delivering what nobody wants, later than anyone expected, at a cost no one can afford. Demand frequent deliverables and checkpoints. The longer the time period between checkpoints, the greater the risk of the team getting off track.
Inadequate Controls on External Providers - Any external provider depended upon for success of the project must be monitored. Never assume a supplier will deliver simply because they always have or because there is a forfeiture clause in their contract.
Disastrous Events - External events beyond your control can have a profound affect on a project. Natural disasters, accidents, competitor announcements, mergers, etc. can all stop a project dead in its tracks. Ask the "what if" questions up front and be prepared for the unlikely.

Vin D'Amico is Founder and President of DAMICON, your ADJUNCT CIO™. He is an expert in leveraging open software to drive growth. DAMICON provides Freelance Technical Writing, IT Disaster Response Planning, and Network Security Management services to firms throughout New England.

This article appeared in Vin's monthly Virtual Business column for the IndUS Business Journal in September 2005.

To learn more about how DAMICON can help your business, please take a look at our service programs.