We Needed A Miracle: We Created a Risk Plan

Last Updated on

The lead software developer on my team came by my desk to tell me she needed to tell me something.

She wanted to talk in private, in a conference room, apparently due to the sensitive nature of the message.

Once in the small room, she broke the news.

“We’re screwed. The team and I have discussed it extensively, and there’s no way we can finish this project with current requirements and schedule. There’s a risk we may be fired.”

While it sounded like we may need a miracle, I also knew, from the extreme language and emotional content, maybe we just needed to reframe the situation.

We Worked Together

“Ok,” I said. “I get it. Can we discuss this in a little more detail? I’ll deliver the message to management, and I’ll support the team, but I need to take complete information when I do.”

“Sure,” she said. “I thought this conversation was going to be harder than this.”

“No,” I said. “Everyone involved knows we’re operating in reality. There are limitations. But they need as much advance notice as possible, and they need enough information to understand alternatives. If we can provide that, we all win together, one way or another.”

“Wow,” she said. “We were afraid you might throw us under the bus.”

“No,” I said. “Wherever we go, we go together.”

I asked what circumstances had the team conclude it would be impossible to meet our goal.

We Built A Risk Plan in 4 Questions

She listed several things: the team lacked understanding of a specific technology, needed software licenses, access to subject matter experts, and more computing hardware.

I asked her to define the missing things in detail.

  1. Exactly what could go wrong (the risk).
  2. What resources or mechanisms would be necessary to address the risk?
  3. The schedule impact of acquiring the missing resources.
  4. The financial implications of acquiring the missing resources.

On a whiteboard, in bright blue marker, I itemized what was missing, what we needed, the schedule and cost impacts.

What Could Go WrongWhat We NeedSchedule Impact$ Cost
We don’t have the right toolsSoftware1 Week$5,000
We don’t have the right knowledgeSoftware Training2 Weeks$4,000
We need a short term mentorSoftware Expert2 Weeks$20,000
We don’t have a Test EnvironmentHardware4 Weeks (in parallel with development work)$20,000

The list filled the whiteboard with blue lines and lettering.

“Is there anything that’s missing, that would hinder our ability to succeed? Is there anything else that would improve our ability to deliver?”

In Under an Hour, We Created a Risk Plan and Performed A Miracle

“No,” she said. “I hate to say I came to you certain it can’t be done, and now you’ve convinced me it’s possible.”

In fact, I hadn’t convinced her of anything. I just respected her concerns, asked questions, and helped her build a risk plan that would save the team and the project.

“We can do it if we get these things, and we can’t do it if we don’t. Is that right?”, I asked.

“Exactly.”

I wrote up the project change request, for about $50,000. It was just a sliver of the value of the overall initiative.

Because we’d identified and communicated the concerns early, the team was able to accommodate the additional responsibilities in the existing schedule.

Because the requests were small dollars and very practical in nature, it was an easy funding choice for those with investment accountability.

We received an approval the same day. The team went on to order the resources and complete the work.

For more Information

  • While I’ve placed conversations in quotes, they’re not exact quotes of the conversations. They’re representative of the spirit and content of the conversations, as I recall them.
  • What I’m calling a “risk plan” here is more commonly called a risk management plan, or a risk response plan, or even a premortem. I’ll leave wrangling definitions to Ph.D.’s and certified project managers. My primary goal here has been to quickly illustrate that it is fairly easy and straightforward to develop a practical plan to move forward most reasonably sized projects in most situations. While very complicated methods have been devised for identifying and managing risks, if they are necessary, the large size and complexity of the project are likely the biggest and gravest risks of the initiative. As much as possible, keeping projects small pretty much assures success from the beginning.
  • This risk planning event went well because I had a good development lead and a good team of software professionals. Learn more about how to build, assess, and lead a good team.

Make a comment here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.