Project Feasibility Studies – Do’s and Don’ts

/in /by

Feasibility studies help to show the potential viability of a proposed project. A feasibility study should recommend initiating a project if business conditions are right. If conditions aren’t right, the study should help management understand the risk they’re taking if they approve the project anyway. Here are do’s and don’ts when you run a project feasibility study.

+ Do focus on risks. The purpose of a project feasibility study is to identify and understand project risks. Provide management with a detailed description of the risks you identify along with mitigation activities that could be used to reduce them.  Also be sure to include opportunities (positive risks) that the project provides.

x Don’t skip risks that you consider insignificant. A feasibility study should identify circumstances the project might encounter. That means you need to include all risks, even the ones of lesser concern. With these less significant risks, explain why you believe they aren’t important. This shows you’ve been thorough in the feasibility study.

+ Do share the likely path the project will take. Telling a story is the best way to do this. When management sees how the project might run through a believable story, you can ease their concerns and help a reasonable project move forward.

+ Do include an executive summary. Storytelling doesn’t typically start by giving away the ending. But, it’s a good idea in a project feasibility study. Executives appreciate high-level overviews.

+ Do build a milestone plan. A milestone plan enhances your project story and highlights the approach you think makes the project feasible.

x Don’t create anything deeper than the milestone plan. You still don’t have enough information to do that. One thing a feasibility study does is determine whether you should undertake a deeper planning exercise.

+ Do understand what the person who will approve the project cares about most. Think about the triple constraints of time, scope, and cost. Talk with project approver(s) to determine which of those constraints is the most critical. Make sure everyone understands how those constraints will affect project viability.

x Don’t neglect the less important project constraints. Of course, you want to emphasize what is most important. But finish the job. Describe how all the triple constraints might affect the project quality.

+ Do focus on external factors that might affect the project. It isn’t only the conditions within your organization that can affect a project. Evaluate and describe external factors, like market conditions, as well.

x Don’t skip things like environmental and community concerns. These can be make-or-break items when it comes to project delivery.

+ Do make assumptions during your feasibility analysis if necessary. There are too many variables to research to cover everything. Do a thorough feasibility study. If a “deep dive” is needed to validate a point, make an assumption and be sure to mention in the documentation that you made an assumption. (You can also provide detail how you could validate the assumption.)

Do you have any other tips – or questions – about feasibility studies? Other results that help feasible projects get approved and weed out the rest? Share with us in the comments! 

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.