You can find endless research, opinion pieces, and guides for the best ways to plan and manage projects. There are debates about waterfall versus agile methodologies, where each applies best, or arguments that one is always superior to the other. You can attend training to learn the exact way to apply the proper principles and techniques.
Many of us in the Project Management profession begin our careers pursuing that knowledge of the “right” way to plan and run projects. We learn how to calculate the critical path. We learn how to develop a work breakdown structure. We learn complex methods of gathering requirements, robust stakeholder management matrices, and quantifiable ways to assess risks.
Armed with these tools, we approach our projects with a rigid framework for how we progress through project phases, if you’re in Camp Waterfall, or through sprints, if you’re in Camp Agile.
Eventually, we’re all faced with a moment, or moments, where our project doesn’t go as planned. No matter how well we adhere to our methodologies and templates, we find ourselves having to improvise. It’s here that we start to appreciate flexibility. We begin planning buffer time into our schedules. We start identifying as risks things that have caused us angst on previous projects and planning contingencies.
We learn that no project will 100% adhere to our perfect plan, but we appreciate the immense value of building the perfect plan and then being able to flex. To borrow a phrase from Dwight D. Eisenhower, “The plan is nothing, but planning is everything.” This is the first stage of maturing as a Project Management professional.
The next step might be a bit of a leap. First, we need to recognize that the right way of doing something might not be the best way. There are times when the most thorough, most efficient method simply won’t be effective for reasons you won’t find in any project management handbook. Let me give you a real life example I experienced.
I had just started a new job and was staffed on a very high-stakes project. Knowing the potential consequences if the project failed, I leaned into risk management more strongly than I would have on other projects.
We didn’t have any project management tools at this company, so I built a risk calculator in Excel. I had space to identify risks, define them, identify impacts should the risk be realized, and detail the mitigation plan to avoid the risk.
I built a calculator with axes for Impact and Probability, defined criteria for high/medium/low, and assigned a numeric value to an assessment of high/medium/low. I also had a calculation for composite score based on the Impact and Probability ratings so we could objectively rank, assess, and discuss each risk based on its severity. I added conditional formatting to make the most severe risks pop to facilitate the conversation.
I scheduled time with the right stakeholders to begin risk identification and assessments. I imagined a brainstorm session similar to those I’d run at previous companies. What happened was not close to what I expected. There was immediate resistance to the entire exercise and even to using the word “risk.” I hadn’t realized how starkly company cultures could differ from one to the next.
At this company, there was a high value on collaboration and a strong aversion to conflict. The risk management document I built, with all its formulas and color coding, elicited dread of process and barriers. The focus on risks felt like negativity. If a risk involved people, it felt like confrontation.
My initial reaction was to be frustrated. The word “risk” is an industry standard term in Project Management. Risk identification, assessment, and management are critical to any project. I wanted to push the team to use the tool I built, but I realized that would not only be unsuccessful but would alienate them. I took the feedback from our session and tried again. Identifying risks was still critical, but maybe the best way for this team at this time wasn’t the robustness of the “right” way, with calculations and objective rankings.
So I softened my request of the team. I asked them to think of bumps in the road we might encounter, instead of using the word “risk.” I asked them how big a deal it would be if that happened instead of asking them to assess Probability and Impact numerically. This gave me enough to prioritize risks and talk through how we could avoid them.
It wasn’t the perfect way to do Risk Management, but it was better than not doing it at all. It was progress. I changed my mindset to accept progress, knowing we could make a little more progress next time. I knew that as I managed more projects we would eventually get to a more robust risk planning framework without creating a negative experience for the team.
I maintained a strong relationship with my project team instead of alienating them, we took a small step toward robust risk planning, and I got enough to build a fortified plan and see my project through.
Lauren Zinsmeister is Director PMO at Movable Ink
