Posts

Bad Risk Response Habits to Avoid

/in /by

Effective risk management is crucial to project success. Unfortunately, many project managers fall into traps when developing risk responses. Bob McGannon and Bonnie Biafore share some tips for avoiding common mistakes in risk response planning:

  • *Do not* base your risk response on using standard project management tools. Saying that you will address a potential stakeholder relationship issue through your communication plan isn’t helpful. Instead, develop a response that describes how you will work differently with the stakeholder: such as: inviting the stakeholder to your risk assessment meetings or increasing the frequency of status reports to that stakeholder. You can use PM tools as long as you describe in detail the difference from standard approaches.
  • *Do not* omit details. Specifics are helpful when crafting risk responses. They help you examine conditions you need to address. For example, a common risk response is “add more resources.” Sure, that could be exactly what you need, but you need to describe that action in more detail. Specify the resources you need, the skills and experience required, and where you will get them. If you will contract resources, identify the lead time needed to engage those resources.
  • *Do not* create overly generalized responses. Risk responses need to address the risk’s cause and impact. Let’s say you have a project task to transport parts. There’s a risk that the truck won’t show up on time to pick up the parts. Your response could be to keep an extra truck on standby. This would be appropriate if the risk event is a truck breakdown. But what if truck drivers go on strike! Instead, make sure your risk responses are complete by addressing the impact while considering the causes. In this example, the impact is a delay in delivering crucial parts, which requires two risk responses. One for potential truck breakdown and a second for a potential driver strike.
  • *Do not* use extra checking or verification as a risk response. Verification activities show if a risk may happen or is happening. They do not address what you will do if the risk occurs. Instead, create a response that describes the actions you will take to address the risk if it occurs.
  • *Do not* define certain, or near certain events, as a risk. In a 6-month construction project, it will rain at some point. So you need to build your schedule to handle that. Addressing flooding due to excess rain is different, because flooding isn’t a certainty. Likewise, a project team member might miss a few days of work. Your schedule needs to accommodate that. Address short resource absences with scheduled breaks or by including extra time to complete critical tasks. A team member resigning and joining another company is a risk and requires a specific risk response action.

For more about risk, check out Bob’s Project Management Foundations: Risk course. That course and my Project Management Foundations course are both unlocked through December 31, 2025, in the LinkedIn Learning path: Career Essentials in Project Management by Microsoft and LinkedIn to support you in gaining digital skills for tomorrow’s workforce. 

Coming Up:

Leading with Curiosity- How do you get better at asking questions? Natalie Nixon has invited me to join her on Wednesday December 14th at 12pm ET to explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.

The Worst Mistakes PMs Make with Risk- Bob McGannon and Bonnie Biafore are holding a LinkedIn Office Hours on December 19, 2022, at 3:30PM MT (5:30 ET and 8:30 AM AEST December 20, 2022). Join us for an in-depth discussion about developing risk responses.

Project Assumptions: Types and the Risks They Pose

/in /by

Photo by Kaleidico on Unsplash

Every assumption you make for a project introduces risk. By raising your awareness of types of assumptions and the risks they pose, you can make sure that you develop solid risk management plans for them.

  • Initial assumptions are part of every project proposal. When project ideas surface, you must make assumptions to estimate project benefits. In addition, you usually assume that business stakeholders will accept the solution approach. 

These assumptions are low risk because you validate them early in the project. If you’re diligent, initial assumptions can facilitate the early stages of a project without incurring undue risk. You can create a case study to validate benefit assumptions. Paper-based models or simple diagrams can show a proposed solution. Flowcharts can demonstrate how a new business process might work. Or you can build quick product to validate the project solution. 

  • Planning assumptions relate to how you will execute your project. For example, you might have to assume the level of skill required to complete your project. You will validate these assumptions during planning as team members explore potential solutions (and determine whether they are simple or complex.) 

Risks like these are usually manageable — under one condition. The team members doing the planning should not feel pressure to say the project is doable. They should be free to identify complexities without consequences. In short, project planners need to be able to communicate the difficulties the project may face.

  • Fundamental assumptions are resolved through execution of project scope. These assumptions are often necessary. But they are high risk because you might spend lots of money and time before you realize your assumption was wrong. For example, you might want to add functions to a system component that has a response-time constraint. You might have to assume the component can handle the extra workload, but you won’t know that for sure until you build the function and run the component.

For example, architects build models to help customers evaluate the appearance of a building. Once the building is under construction, the customer might not like it and request changes. 

  • Project premise assumptions are the riskiest. These can be validated only by completing the project, for example, building a new product and introducing it to the market. While there were signs the iPad would be successful, there was also criticism of the idea. Only by producing the iPad and having customers use it were Apple’s assumptions validated. Projects with premise assumptions are gambles, so diligence is needed. Conduct as much market research as is feasible.

Bottom line: Make assumptions and follow up on them! We need them to launch our projects. By understanding the nature of your assumptions and when you can resolve them to assess your project risk.

If you have any tips or questions about assumptions, share with us in the comments section.

For more about assumptions and risk management, check out Bob McGannon’s Project Management Foundations: Risk course.