With Difficult Risks, Consider Your Options

/in /by

Photo by Burst on Unsplash

Risk management can be difficult when risks are hard to address. Some difficult risks are abandoned too quickly as unmanageable when they could be addressed. Be persistent! Here are four approaches to consider when you are struggling to derive a response to a risk.

  • Try to reduce the probability or impact if the risk occurs. People often think risk management is eliminating risks. Many difficult risks can’t be eliminated. But there are might be actions that can make the risk more manageable. You might be able to reduce the risk’s probability of occurring or its impact if it occurs. OK, this is common practice. But people often don’t do this for difficult risks. Why? Because they assume the impact reduction will be minimal. Instead, do some research to determine what the reductions truly are. For example, time buffers in your schedule can address schedule impacts. Contingency funding can reduce cost impacts. Even a 10 or 20% cost reduction in the risk impact can make a difference at the end of your project.
  • Think about who might be able to help. Maybe you can’t address a risk yourself. But someone else might be able to. Contact them. If you can’t do that yourself, look for a common connection who might put you in touch. People are often happy to help if they can. For example, a colleague of mine asked a local government official to address a risk. The official made an exception which helped the project. Because of their discussion, the council passed updates to local laws, which made many projects easier to deliver. 
  • Explore scope alternatives. Teams often become attached to their approach to completing a project. The scope can become inflexible for no good reason. Often multiple approaches could work to deliver the desired scope. Maybe a different approach to delivering that scope would reduce risk.

Also, some parts of project scope might be less important. Look at removing riskier, less important scope elements. And check whether the adjusted scope delivers enough business value. One word of warning though. People often react negatively to scope reductions because they want the benefits from the scope. Perform a pragmatic analysis of the risks and benefits. But, if achieving those benefits introduces undue risk, they may not be worth it. Do your homework to figure out if the benefits are worth the risk. And if they aren’t, determine whether reduced scope still benefits the business.

  • Conduct progressive status checks, while considering plan alternatives. Let me share a story. There was a project that would benefit by using a software product due for release in four months. The project had a 12-month schedule. Planning on using unreleased software is high risk. To address this risk, the project team took four actions.
    • They developed all aspects of the scope that didn’t depend on the unreleased software.
    • They planned regular status checks on the progress of the new software. In those checks, they focused on any changes to the release date and client reactions to beta test results.
    • They determined the latest date they could wait to buy the new software without impacting their deadline.
    • They planned a way to deliver most of their project scope without the new software–just in case the new software was delayed or didn’t live up to expectations.

These actions reduced risk. The project team could take advantage of the new software if feasible. If not, they had an alternative approach to deliver most of the scope.

Have you had success with other approaches for handling difficult risks? Are you struggling with a risk you can’t figure out how to handle? Share your thoughts and questions in the comments section.

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

Coming up:

Want to improve your project management and don’t know where to start? I’m a guest on Kim Kaupe’s Coffee with Kim series to talk about what it takes to go from good to great as a superstar project manager. 👉🏼 What can you do to increase the success of your projects? 👉🏼 How do you keep a virtual team on the same page? 👉🏼 What skills should project managers aim to level up in 2023? Here’s the link to sign up: https://www.linkedin.com/video/event/urn:li:ugcPost:7026641716040355840/

Do You Need to Re-estimate Your Whole Project?

/in /by

Estimating projects is never easy. There are too many variables. Team performance can be inconsistent. And even with sound risk management, issues arise. These variables can require adjustments to estimates for part of a project. Sometimes, re-estimating the entire project might be in order. Here are circumstances when a complete project re-estimation is in order.

  • Scope changes by more than 20%. In managing project change, you examine the implications of a single proposed change and propose whether to approve or reject the change based on its cost and benefits. Each change is evaluated on its individual merits. What doesn’t occur is an overall evaluation of the project after many changes have been approved. Multiple changes can increase risk and complexity and the need for personnel and contract management. So, if your project has increased by 20% or more from its original scope, it’s time to re-estimate the remaining project work to assess the aggregate impact of all the changes. That way, you ensure the project is still appropriate for the business.
  • Critical team members change. In most projects, there will be business and/or technical team members who are critical to success. If a critical team member changes, you might consider re-estimating the project. You might need multiple people to replace that team member. Or the replacement will be an expensive contracted resource. Either way, you might end up with significant unplanned costs. The replacement resource might take longer to deliver their assignments due to a lack of internal business knowledge. Re-estimating after critical personnel changes ensures realistic expectations for the project.
  • The project has varied by 30% or more from your initial project estimate. Don’t continue to use an estimate that isn’t accurate enough. If you’re variance is over 30% from your original estimate, it’s time to re-evaluate the project’s viability. Revisit all your estimates. Use the difference between actual performance and your estimates to revise remaining work estimates. Look for opportunities to cut scope. While you want to deliver value to offset the money you have spent, it may not be feasible. The project should continue only if future spending will justify the business value.
  • The project intent changes. Projects can go a different direction due to business strategy changes. Or a change of sponsor can alter your project’s direction. The priority of requirements can change or new requirements arise. The team members and project name are the same, but you could be managing a very different project. If so, it’s time to re-estimate! Evaluate risks and examine the tasks needed to meet the revised expectations, so you can verify that the altered project can meet business expectations.

Have you ever re-estimated an entire project? If so, why, and how did that turn out. Share with us in the comments section. 

For more about estimating, check out my Project Management Foundations course.

Working with a Sponsorship Committee

/in /by

Sometimes, the time and extent of authority needed to sponsor a project is beyond what one person can handle. In that case, a sponsorship committee is the answer. Here are tips for working with a sponsorship committee.

  • Request an individual to represent the committee when you need quick responses. At times, you will need a quick decision. Communicating with multiple sponsors is time-consuming, so it’s important to have a single sponsorship representative you can contact on short notice. That person can make decisions for the project, or they can poll other committee members if needed.
  • Propose logistics for the committee. A project manager can’t dictate how steering committee logistics will work, but the committee usually appreciates reasonable recommendations. Consider the priority and risk elements of the project. Then propose meeting frequency, definition of a quorum, and a standard agenda. The committee may not adopt your suggestions. But proposing sound logistics increases the chances things will run smoothly. Sound logistics also centralize communications, easing the burden on the project manager.
  • Strive for a single set of priorities. Work with the sponsorship committee to develop a common set of project priorities. If you’re lucky, members of the committee will agree on the priority of project requirements and the relative importance of project constraints (cost, time, scope, and quality). Hold discussions early to identify potential conflicts. These talks can set the stage for future debates and decision making.
  • Propose a decision-making process. It’s important for the committee to agree upon a decision-making process. Will all decisions require a consensus, or is a majority decision acceptable? Will a committee chairperson break ties or logjams? Agreeing to a decision-making process in advance saves considerable time. Without a process, needed decisions might not be made. Influential stakeholders in conflict can kill a project whether you have one or several sponsors. An unmade decision could stall or halt projects,  as the committee tries to develop a decision-making process and make a controversial decision at the same time.
  • Define the relationship between the sponsorship and steering committees. Many organizations appoint a steering committee for major projects. Members are typically key managers and customer personnel. Things can get confusing when you have both a steering committee and a sponsorship committee. So, it’s wise to draft a mission statement for the steering committee and one for the sponsorship committee, explaining how the committees work together. This can avoid confusion about where project related decisions will be made.

Have you ever worked with a sponsorship committee? What were the pros and cons? If you have tips or questions about sponsorship committees, share with us in the comments section.

For more about working with sponsors, check out my Project Management Foundations course.

Common Project Approval Blockers

/in /by

Photo by Quick PS on Unsplash

Critical projects sometimes die prematurely when blockers prevent projects from getting management approval. Here are some tips for addressing these common approval blockers.

  • Your organization hasn’t established project success metrics. A lack of success criteria can raise obstacles to project approval. Is the payback period 1 year or less than that? Do you need a significant reduction in the risk of using old processes or systems? What does significant mean? Do projects have to achieve a cost reduction of greater than 10%? Or is it a combination of these? Sometimes, the best way to get a project approved is to propose success criteria so management can talk about them and make a decision.
  • Conflicting stakeholder goals prevent agreement. Goal conflicts between senior stakeholders are common. Financial personnel might focus on reducing costs, while marketing personnel want to spend more on initiatives to increase profit. Stakeholder conflicts that aren’t understood or identified can kill your project. They may have started from past projects or personality clashes. Work with your sponsor to facilitate conversations between conflicted stakeholders. Meet one-on-one with influential stakeholders who aren’t enthusiastic about your project. That way, you can identify these conflicts and work to resolve them.
  • Past project failures. Many organizations have a poor project success rate. Stakeholders remember the pain and pressure of those failures, which makes them hesitant to take on new projects. Work to understand their fears. Review documented lessons learned, but don’t assume they tell the full story! If possible, talk with the people involved in past project failures. Personnel and contractor failures might not be identified. Do research to understand these failures and put risk plans in place to address them. Discuss how you will manage the project differently. 
  • “We are too busy.” Does busy mean the organization is productive? Often, antiquated processes and languishing projects persist. Time wasters may contribute to being busy, but don’t help the business. People don’t like stopping a project that has consumed resources without delivering value. As a project manager, you can do your homework to help your sponsor why they should stop a project. This can free up critical resources to work on more viable projects. If that doesn’t work, at least it raises awareness of the need to examine whether busyness is producing anything of value. 

Have you encountered other obstacles to project approval? If you have tips or questions, share with us in the comments.

For more about project approval, check out my Project Management Foundations course.

The Benefits of Baselines

/in /by

Many project managers work hard to build an accurate schedule and then, omit the final step of saving a baseline! A baselined schedule provides so many benefits you don’t want to miss. Here are some key benefits of schedule baselines:

  • Track your project against the original plan. Experienced project managers know that no plan survives contact with reality! To get automated project status, you need to use a scheduling tool (such as MS Project, Primavera, and others). And those tools need a baseline before they can provide reports comparing actual progress and cost to your original plan. Actuals compared to the baseline can then be used to forecast time and cost going forward.
  • Improve your estimating. Baselined project schedules help show when actuals diverge from the original plan. Seeing the variances from the plan can help improve estimates. Estimators get feedback on the accuracy of their estimates. Without this feedback, estimation won’t improve. Say you ask someone to estimate a task, and they tell you it will take two weeks. It ends up taking four weeks. If the person never hears about that variance, they’ll still say two weeks next time, when the task will likely take four.
  • Reinforce accountability with team members and management. Sharing a baselined schedule reinforces the schedule and the time team members have committed to your project. The same is true for management. It helps reinforce management’s commitment to dedicate staff to the project. As business priorities change, project staff time might change as well. You can compare the baseline staff allocations to the actual time spent  to show why a project is behind schedule.
  • Manage thresholds. Project status reporting often uses traffic light indicators. Green means all is well. Yellow indicates trouble brewing. And red means there are issues. These colors usually indicate a level of variance from plan. For example, 0-2% over schedule may be green. 2-5% over schedule is yellow. And greater than 5% over schedule is red. Tracking actuals against the baseline plan forms the basis for these variations.
  • Make program planning easier. When managing a program, a deliverable from one project can be a predecessor to a task on another project. In this instance, it’s vital to understand when tasks will be completed. A baselined schedule along with updated, actual task completion dates helps you understand how one project’s performance will affect another in a program.

What other ways do you use baselines to improve project performance? Share with us in the comments section.

For more about schedule baselines, check out my Project Management Foundations: Schedules course, which is unlocked through the end of 2025 with this link.

A Spreadsheet Isn’t a Scheduling Tool!

/in /by

Spreadsheets have so many uses, but project scheduling tool is not one of them. You can use one to create something that looks like a Gantt chart schedule. But you can’t manage that schedule without a ton of menial work. Here’s why you should use a scheduling tool rather than a spreadsheet:

  • You can manage lag and lead times. Task relationships aren’t always straightforward. Scheduling tools manage this automatically through lag or lead time between two tasks. Say you submitted a building permit application. You need to receive approval before starting your first construction task. In a scheduling tool, you can add lag between the predecessor and successor to automatically maintain the delay between the tasks. You can also overlap tasks. For example, you have to draft a long book chapter. Editing that chapter could start before the entire chapter to shorten the schedule. Lead time specifies when the successor task can start before the predecessor tasks finishes. For the chapter, you add lead time between the two tasks to give the author a head start before the editor starts editing the chapter. With a spreadsheet, you would have to keep track of lag or lead time as the schedule changes.
  • A scheduling tool automatically updates start and finish date when you input actuals. Project schedules change all the time. Tasks go more quickly or take longer than expected. Resource availability isn’t what you planned for. A good scheduling tool automatically recalculates dates to show the revised schedule. Try this with a spreadsheet and you’re in for a resource-intensive, and error-prone exercise even for a small project. You can also use a scheduling tool to explore what-if scenarios. Have a change you’re considering that would add or delete several tasks? Make those changes with a scheduling tool and evaluate the results.
  • Calculate costs based on actual hours spent (without having to building those calculations in a spreadsheet). Scheduling tools have built-in functions to calculate costs. The calculated cost is based on the time spent to complete tasks that you enter in the tool) and the hourly rates for each person. Scheduling tools can also calculate equipment and materials costs. The tool calculates overall project cost from the individual task costs.
  • Automatically compare the status of your project to your baseline. Knowing where you are on the project compared to what you originally planned is crucial to keeping a project on track. The differences, called variance, are a fundamental part of status reporting. With a scheduling tool, you can save a baseline of your schedule, and then compare the actual time and cost spent to that baseline. A scheduling tool can also forecast the variance from the baseline finish date and cost based on where the project is today.

For more about what several scheduling tools can do, check out my Project Management: Choosing the Right Online Tool course.

When do I Share Issues With my Sponsor?

/in /by

Photo by Amy Hirschi on Unsplash

Sharing issues with your sponsor is like walking a tight rope. You don’t want to bother them with trivial matters. But you want them to feel informed. And you never want them to be blindsided. Here are situations when you need to share issues with your sponsor.

  • The sponsor’s confidence is low. Sponsors are afraid of not being in control. They also don’t like to report project concerns to their superiors. To address their fears, give them detailed project status. In status reports, include issues that you are addressing and how. If the project progresses well, your sponsor’s confidence will increase and the need to discuss minor issues will decrease. Use your perception of the sponsor’s confidence to determine which problems you should review proactively.
  • Issues will affect project time or cost. The potential impact of an issue is a good measure of when you need to talk with your sponsor. How do you get this right? By setting a threshold in advance for when the sponsor wants to be informed. Is it when there’s a 1% impact on the budget, 5%, or some other number? Do the same for impacts to your schedule. (The percentages might be different for budget and schedule. Sometimes, meeting the schedule is more critical than staying within budget, or vice versa!)
  • An issue affects a critical stakeholder. Influential stakeholders watch your project carefully and are likely to talk to your sponsor if problems arise.  Prevent surprises by sharing details of brewing problems and what you’re doing to address them. That way, your sponsor will be ready to address stakeholders’ concerns. And it’ll also keep stakeholder follow-up tasks out of your to-do list!
  • You might need a decision. If you have a problem that might require your sponsor to make a decision, tell them about it! For example, let’s say you have problems with a new component and that component is the only way to meet some lower priority requirements. Dropping those requirements from the project might be best, but only your sponsor can drive decisions like that. By sharing the problem early, your sponsor has time to consider options and make the best decision.
  • The problem might affect the sponsor’s critical performance measures. Sponsors and key stakeholders typically have operational responsibilities with measures to assess their effectiveness. For example, a target for the weekly output of a production line. If your project could impact that production line, speak up as soon as possible. That way, the sponsor and stakeholders can work with their operational team and the project to manage business impacts.

As you develop a relationship with your sponsor and confidence grows, you can shift your focus. You can spend more time resolving problems versus reporting on them. Use these guidelines along with your sponsor’s concerns to decide when you should work to solve a problem or focus on reporting it to your sponsor first.

Are there other situations where you share issues with your sponsor? Or do you have questions about how to handle sponsor discussions? Share in the comments section.

For more about working with your project sponsor, check out my Project Management Foundations course.

Use a Product Breakdown Structure for Complex Solutions

/in /by

You probably use a Work Breakdown Structure (WBS) in your projects, but sometimes, it isn’t enough. A product breakdown structure is helpful when you need to deliver a complex solution. A Product Breakdown Structure (PBS) is like a WBS, except it shows product details and how its components fit together. Here are the benefits of using a PBS.

  • It creates a common vocabulary for discussing the product. A PBS uses nouns, versus a WBS with verb-based tasks. The PBS defines the pieces that make up your project’s product. Because projects create unique products or services, you probably need definitions for the solution components. The PBS is where you keep those definitions. It also shows how components fit together. This helps reduce errors due to misunderstandings about what the product is and how it will be assembled.
  • It helps clarify development assignments. The PBS defines the product components, so the skills needed to build the product are easier to understand. It also helps people come up with ideas for product improvements and refinements. A PBS helps your technical team members understand where their responsibilities begin and end. This saves time and potential confusion as the project progresses.
  • A PBS helps identify alternate approaches for building the product. The PBS clarifies what is being built. The process of creating the PBS will help team members come up with ideas for how to build the product, too. It provides different perspectives for how components can be assembled and tied together. It also helps visualize how stakeholders can use the product. Because it shows the tasks you need for construction, it helps you build your WBS as well!
  • It helps identify who builds and tests interfaces. The PBS defines how pieces fit together into larger components. Each component needs to be tested to ensure it works as intended. The PBS spells out component relationships, making testing tasks straightforward. And it’s easier to assign testing tasks to team members. The visual nature of the PBS helps prevent overlooking test activities. Those test activities translate to tasks, tying the PBS to your Work Breakdown Structure. This helps ensure you have a complete picture of the product or service, and how it will be built and tested.

Have you ever used a product breakdown structure? Did you receive other benefits? Wondering how to implement one in a project? Share your tips and questions in the comments section.

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.

Have a big job? Use small projects!

/in /by

photo by Anders J on Unsplash

In today’s complex world, projects can become quite large. The problem is large projects are often fraught with issues due to the amount of change they create and the complexity that comes with those changes. Here’s why a series of small projects usually outperform a single large initiative.

  • They deliver value earlier. Small projects finish faster, which means the business realizes value sooner. Organizational change also occurs in smaller bites, so stakeholders can digest new ways of working more easily.  
  • Changes are easier to handle. A series of small projects provides agile-like results. Learning from one project helps the team improve on the next one. Stakeholders learn from using the project’s products, so they create better requirements. And better requirements improve the value the business realizes.
  • Key staff members aren’t as much of a bottleneck. Project assignments often take key operational staff away from their day-to-day tasks. Assigning a critical staff member to a two year project is a challenge. Rolling on and off a series of shorter projects is easier to juggle. That way, you can use internal staff instead of expensive contractors. (And contractors don’t know your environment as well, which can lead to poorer project solutions.)
  • Small projects are less complex and less risky. Smaller projects mean smaller scope. Less scope means fewer new functions, fewer stakeholders, and fewer team members. All these mean less risk to the business. However, a series of smaller projects does introduce a different risk. Changing business priorities might mean later projects in the series could be cancelled so some of the original scope is lost.

Have you divided a big project into several smaller ones? What worked well? What didn’t? Share your experiences in the comments section.

For more about small projects, check out my Project Management Foundations: Small Projects course.

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.