Every project and every project stakeholder deserves some risk management, no matter how small or simple the project.
That is a sentiment I often share with my project management students, inspired by an experience I had managing a small project years ago.
I was assigned to a project that had to be delivered in a short period of time. Fortunately, the product was very familiar to me and the team, and we had done similar types of projects in the past. Further, team members already knew each other and the SMEs in the organization who would be providing support.
Even though I had worked with the team members previously, I had concerns about one of them, Jon, because we hadn’t used him in this particular role. I did not think that what he was providing on the project played to his strengths. But since no one else seemed concerned and we were in a rush, I decided to move ahead without any discussion around project risks. I didn’t want to be a nay-sayer. We had done this before and these team members were familiar with the product, the organization, and each other. What could possibly go wrong? I figured we would just cross that bridge if, and when, we got to it.
Well, many weeks into the project, we got to that bridge. Jon produced his deliverable – and it was a mess. Way worse than I could have imagined. Total show stopper. What was even messier, however, was having to tell my sponsor about the problem. As much as anything, I was frustrated with having to present what appeared to be a “surprise” to my sponsor. I wasn’t looking to say, “I told you so,” but the burden of the mad scramble to respond felt heavier than it no doubt would have if the sponsor and others had been aware.
Many late-night phone calls and floor pacing ensued along with considerable stress just trying to figure out how to communicate what had happened. Actually, developing a response to the issue felt entirely secondary to the challenge of communicating that it had occurred. I couldn’t see clear to a solution because I was so concerned about my sponsor’s reaction.
For many, the reaction to something like this on projects is often emotional and poorly scaled. Further, the inclination is to spend time figuring out how a problem could have happened, what could have prevented it, what should have been done differently, etc. While the intention of those reactions isn’t always to place blame, they often leave people feeling like they did something wrong and it can create negative energy on the project. That was certainly the case with this project.
Looking back, a conversation with my sponsor about my concern would have better served the interests of the project and the organization, as opposed to ignoring it in order to move faster to meet an aggressive deadline. In fact, I am certain that we would have accepted the risk and not done anything proactive about it. Talking about it early on, however, would have changed the tone of the conversation once it did happen.
Early discussions about potential threats serve to get concerns in the open so that if they do occur, the reaction from the project manager, sponsor, and others can be more constructive and get to problem-solving faster.
It’s the conversation that matters, and having it early about potential problems is a lot easier than having to initiate a conversation mid-project after an issue has already created problems. They help create a project culture of openness and trust. Most importantly, better project decisions get made, resources are used more wisely, and project tempo is sustained when the risks do occur.
I learned a lot from that experience. No matter how small, how familiar, or how “been here done this” I feel about a project, I make sure we take some time early on to talk about what could go wrong. That makes risks a safe topic, and one that’s likely to be revisited throughout the project – in a tone of partnership.
How about you? What has your risk management experience been on small projects?