As everyone involved in the infamous launch of Healthcare.gov knows, you can deliver your project on time only to have it crash on takeoff. And as everyone involved in a large project knows, tough constraints (deadline, budget, regulations) require project tradeoffs that can lead to unforeseen difficulties or failure after delivery.
But if you follow these steps to take regular healthchecks during project development, you'll be celebrating a commencement instead of a postmortem after delivery.
Before you begin, gather a small team of great minds from your project, plus one or two from other successful projects for a fresh perspective. You might choose an experienced developer, a supportive business leader, a customer service manager, an implementation consultant, and a midlevel manager from a key client. Invite them to join you in a comfortable setting for a few hours to help you predict the project's many possible outcomes.
Start with your critical success factors (CSF)
Beside the all-important deadline, ask what are the three most important aspects of this project for success? For online registration, it might be availability (users can access the system at any time), completion time (time to complete the registration), or ease of use (users can complete registration on the first attempt, without having to ask questions or abandon in search of further information).
What are the top reasons each of these could fail? Regarding online registration availability, you may hear “Too many users hitting the system when it opens” or “Our capacity testing was inadequate.”
Write all potential causes on a flip chart and keep brainstorming reasons, saving discussion of how to handle these problems for the steps below. Use a second chart or large sticky notes to capture ideas that belong to a future step, so you can stop that discussion and get back to the task at hand.
Rank the risks
When you’ve been around the table a few times and there are no new reasons the project could fail, ask your team to refocus on the first CSF and review the listed threats. As you work down the list, ask the group if anyone feels strongly that a given risk is particularly likely or dangerous or not, and why. Encourage the team to ask as many questions as they can.
Next, give everyone a stack of ballots and ask them to score each risk (where 1 is low and 10 is high): How likely is this to happen? And how much impact will this have on the project?
Collect the ballots and post the total scores for each risk. Anything falling above the median (perhaps a score of 28 for a group of five) for either likelihood or impact needs a mitigation plan.
Have the group review the rankings, and agree on the outcome of this exercise. Thank your participants, reward them with a treat, and let them go.
Check for sanity
Hope is not a strategy, so you need to develop a strategy of your own. Take the identified high-priority risks and work their mitigation plans into your project timeline and budget.
Ask yourself when will each issue be addressed? How? What resources are required?
Most importantly, have the answer to these questions. A good project manager must set aside the resources required for mitigation and testing, and must periodically ascertain whether those mitigations are being implemented according to plan.
Although you may be tempted to cut testing, don't. It may reduce budget or schedule overages, but the defects which testing would have revealed will still be there, lying in wait. (As an example, because of an error in the grinding of the primary lens, the Hubble telescope needed a “contact lens” after it was launched. Had there been testing, this flaw would have been caught before launch.)
Reassess CSF and their risks during the course of your project
As risks are mitigated, their likelihood will reduce. But during the lifecycle of any project, new potential crises can pop up at any time, so it's important to reassess your CSF frequently.
Have new risks arisen? Have you changed your priorities for the impact of identified risks? Adjust your mitigation plans accordingly, and deliver that project—not just on time and under budget, but functioning as promised at implementation.