Take Credit for Your Risk Management Activities
I recently received a detailed briefing on a complex, high-visibility implementation project that would suffer significant financial penalties if it missed the inflexible go-live date five months in the future. The team thoroughly reviewed progress and obstacles and discussed risks and issues openly. They seemed to have a handle on where they should be focusing their attention.
Almost apologetically they explained how they determined what functionality was essential on day one of go-live and what they had elected to phase in later because it wasn’t critical at go-live. They were trying to minimize risk and maximize focus on what was important.
I commended them on their planning and encouraged them to take credit for the way they had identified and deferred nonessential functions. They seemed surprised. Their instincts were good, but they appeared to feel guilty about the fact that they were already planning to defer some functionality this far in advance.
They were engaging in what I believe was very proactive and effective risk management, and I told them that I supported them 100 percent.
I try not to use the word “deadline” carelessly. My understanding is that the word comes from 19th-century prisons and describes a line on the ground between prisoners and the fence intended to keep them in—cross the deadline, and the guards shoot to kill.
Most projects have target dates, some less flexible than others. Sometimes there are severe penalties for missing a date. Even if no one gets shot, losing millions of dollars can be hazardous to your career.
Too often teams attempt to do too much, setting unrealistic expectations for the user community and potentially squandering resources that could be used to assure that what is important is delivered well and on time. Even when an ambitious team succeeds in delivering more than the essentials, the implementation can often be perceived as less than stellar because the team is spread too thin at go-live, trying to support questions and resolve issues for both essential and nonessential functionality.
If you are trying to defend an important implementation date, early identification of the minimum viable product is a vital risk-management step that helps focus your team’s energy and attention on what is important.
Rather than feel guilty or apologize for intelligent phasing of functionality to manage risk, promote it. Explain to stakeholders what you are doing and why. Get early buy-in on functionality that will be phased in later, and take credit for your risk management efforts.
If we can help stakeholders understand that we are looking out for their interests and doing our best to give them a successful implementation without needless drama, most will appreciate it. Those who don’t may not be people you want to work for anyway.
