The latest version of PMBOK divides risks into individual risks, and overall project risks. And it clarifies the point that risks can have a positive impact. One of your jobs, as a project manager, is to be able to capitalize on positive risks and reduce any damage from negative risks.
I have written many times on risk management, including this blog on the secret sauce. In that blog, I outlined a simple three-step process for managing risks.
But all project problems do not need to be managed as risks; some problems just need to be solved. There is a difference between managing future problems (risks) that may or may not occur, and solving problems in the present. Here is a three-step process to try for problems that just need to be solved in the present.
Identify the project problem.
Try to uncover enough detail to understand who is best equipped to solve the problem, and the severity of the problem. Document this information in some kind of register. At a minimum, I’d suggest tracking the following data points:
- Short name and/or a number for the problem (how will you refer to this problem in communications?)
- Description (a brief description of the problem)
- Date discovered
- Date solved
- Expert (who knows the most about this problem?)
- Assignee (who is assigned to solve this problem?)
- Resolution
Solve the project problem.
The person assigned to the problem can hopefully solve the problem and document the resolution in the register. You may or may not need to review solved problems in your Checkpoint Meetings, but you will want to review unsolved problems then. (Checkpoint meetings are a time when teams gather to assess the accomplishments, identify the lessons that have been learned, review what it’s costing the client, review any outstanding problems, and identify and analyze the project risks. Additionally, the team plans the next time block of work.)
Reevaluate seemingly unsolvable project problems.
If a problem cannot be solved, what’s the next step? This requires some conversation and soul searching. And it likely requires the involvement of the project sponsor. Do you need to put through a change request on the project? Is it really a risk that needs to be managed as such? Is it really a problem?
Let’s take an example. Suppose you’re working on a good-sized project and one of your critical resources is badly injured. Suddenly, you don’t have that resource. You’ve gone to HR and tried to acquire another resource in-house, but you can’t find anyone. You’ve tried to find an independent resource who you can contract with, and that effort has failed. The team simply cannot take on the extra work that this resource was doing in the time frame that is left. Can you cut scope? Can you delay the finish? Perhaps, you can cut some quality on upcoming activities without sacrificing the ultimate project results. Or, re-distribute some of the work to other people on the team, even if all of the work can’t be re-distributed. It could be that your solution is a hodgepodge of smaller actions that might add up to a solution, albeit not a perfect solution. Skip perfection.
There are no right or wrong answers here. In this case, I might record the problem as a risk and continue efforts to acquire another resource, but with plenty of documentation that we may need to consider a scope or deadline change if that effort continues to fail. And I might try to re-distribute some smaller activities to others on the team in the short-term, and reduce the quality on some activities of lesser importance.
If you are struggling and need some help, give me a call.
