Category Archives for 2=Planning

Project Risks and Issues – What’s the Difference?

Do you find yourself working overtime, trying to deal with unexpected disruptions? Some negative events that you thought might happen has now occurred. And it's costing you more time and energy than you thought possible. Overwhelmed? Well, let's talk about project risks and issues, the differences, and why it's so important to manage risks.

What is Risk?

The Project Management Body of Knowledge (PMBOK) defines risk as, “An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.” 

Let's examine a risk statement and underscore some key attributes of risks. Here's a risk statement:

Because the project team failed to review the requirements with the users, the project team may not meet the user's needs, resulting in unsatisfied users.

  • Cause: Failure to review and validate the requirements
  • Risk: Project team may not meet the user's needs
  • Impact: Users will not be satisfied with the product

Notice the risk: project team may not meet the user's needs. Think of risk as events or conditions that might happen in the future.

What is an Issue?

So, how does an issue differ from a risk? Where a risk might happen, an issue has happened. When a threat occurs, it becomes an issue or problem. By the way, when an opportunity occurs, it becomes a benefit

Why Distinguish a Risk from an Issue?

Are we splitting hairs? The distinction between risks and issues matters for a few reasons.

  • Proactive Management Saves Time. “An ounce of prevention is worth a pound of cure.” Project managers should manage risks proactively. Project managers can save valuable time through prevention. As often noted, Project managers can eliminate up to 90% of threats through risk management.
  • Measure of Management Effectiveness. If a project manager is experiencing lots of issues, it may be a sign that the project manager has not been managing the project effectively. 
  • Different Type Response. Issues require a different response than threats. Project managers respond to threats with different strategies: avoid, mitigate, accept, or transfer. Issues require corrective action to bring the performance of the project in alignment with the project management plan. 

Risk vs. Issue Debate

Some project managers and risk managers are not convinced that the differentiation between risk and issue adds any value. Even though the risk has occurred (i.e. it is now an issue in terms of the differentiation) there is still uncertainty regarding the impact and the objectives that will be impacted. 

What about Assumptions and Constraints?

While we are on this topic, let's clarify two other terms—assumptions and constraints.

  • Assumptions. Assumptions are “a factor in the planning process that is considered to be true, real, or certain, without proof or demonstration” according to the Project Management Body of Knowledge. Assumptions may be a source of risks. Be sure to perform an assumption analysis periodically to validate assumptions.
  • Constraints. A constraint is “a limiting factor that affects the execution of a project, program, portfolio, or process.” Constraints such as a budget or schedule constraints are factual. The project manager must continually consider these defined limits when managing risks, particularly when planning risk responses.

How to Create a Project Affinity Map

Have you ever conducted a project brainstorming session and found yourself drowning in a cloud of ideas? Not a bad thing, but how can we make sense of the ideas? Well, let's see how to create a project affinity map to sort your ideas. As a bonus, we'll also look at Dot Voting, a simple and quick way to prioritize your ideas.

What is an Affinity Map?

An affinity map is a tool that can be used to organize ideas into groups based on their natural relationships. The ideas commonly come from a brainstorming session. So, how do project managers actually use this tool?

For instance, a project manager may ask a project team to identify reasons why a project is behind schedule. Imagine that the team identifies fifteen reasons. Next, the project manager asks the team to sort the ideas into groups. The team discovers that the reasons fall into the following groups: processes, people, product, and technology. This is a great way to create a Cause and Effect Diagram.

There are countless ways to use a project affinity map after brainstorming. Here are some examples. Identify and sort:

  • Project risks
  • Causes of risks
  • Responses to risks
  • Problem-solving ideas
  • Ideas for improving interpersonal relationships
  • Ways to improve communication

Step by Step Project Affinity Maps

So, what steps do we take to create an affinity diagram? Let's walk through the process.

  1. Define the issue or the question on a whiteboard or flip chart. For example: "What ideas do you have to expedite our project?" Or "What is causing the quality issues in our software project?"
  2. Ask participants for responses. Have the participants write their responses on sticky notes or index cards.
  3. Collect and post ideas.
  4. Sort the ideas into columns or clusters. Ask the participants to help you sort the ideas into common groups.
  5. Define categories. Ask the participants to define category names or headings.
  6. Discuss the Affinity Map. Ask participants for key observations. Ask probing questions to help everyone better understand the results.

When you complete the exercise, the team should have a deeper and more comprehensive understanding of the issues. Sometimes the team may need additional help to identify the most significant items. Let’s look at another simple tool to prioritize the items.

Cling On Sheets

Have you ever used Cling On Sheets? They work like a whiteboard, but the nice thing is that you can put them anywhere on a dry wall and then move them as needed. After my brainstorming sessions, I take them back to my desk so I can complete my documentation and minutes.

Prioritize Your Ideas with Dot Voting

Dot Voting - each participant cast their votes by placing sticky dots on their top choices.

  1. Determine what to vote on.
  2. Give the participants a number of votes. I give participants 5 sticky dots.
  3. Give guidelines for voting. For example, participants may cast one or more votes for any one idea. Participants may cast all of their votes for one idea if they feel strongly enough about the idea.
  4. Ask participants to cast votes. Participants cast their votes by putting their dots on the sticky notes.
  5. Total votes. Count the dots and declare the top items.
  6. Discuss the results. Are most of the votes in one category? What are the top 3-5 ideas?

The Affinity Map and Dot Voting provide a powerful one-two punch. You and your team will be able to sort and prioritize the ideas in a quick and organized manner. Give it a try!

How to Initiate a Project Steering Committee

Someone decided that it was a good idea to bring project management into your organization. Perhaps it was your CEO or operations manager or IT Director. But for some reason, it never took off. Project management has not been supported by your culture. Let's look at how to get things in flight with a project steering committee.

Project Steering Committee

What's the Current State?

Start with an evaluation. Here are some questions to aid you in discovering the deeper issues. Interview your stakeholders to get their feedback.

  • When your organization introduced to project management, what were the problems project management was to address? If the problems have not been addressed, what is it costing you right now?
  • What's working well?
  • What's not working?
  • How can we get more value from project management?

Initiate a Project Steering Committee

Sometimes, the person responsible for project management (e.g., PMO Director or Project Services Manager) fails to involve stakeholders in evaluating project management. This person makes changes in project management with little to no input from the people being impacted. A better approach is to get regular feedback through a Project Steering Committee.

The purpose of the committee is to improve process and results. The Steering Committee determines the required changes, how much change is needed, and how fast changes need to occur.

Who Should Comprise the Project Steering Committee?

It is best if an influential senior member of your organization sponsors the committee. The sponsor helps to establish the vision and ensures the commitment of resources. But this person doesn’t have to manage the committee.

The Steering Committee may be managed by the person responsible for project management, a person with the proper credentials and experience. The team should include representatives from different areas such as IT, project management, and business operations. Ideally, team members have had project management training and have project experience.

Team Size and Tenure

An optimal team size is six to eight people. Team members should serve no longer than a year. You may wish to implement a staggered rotation where you add a couple of new team members and drop a couple of team members periodically.

Meeting Frequency/Time

The Steering Committee may meet as often as desired—for example, monthly, quarterly, or twice per year.

Plan for Improvement

How should the team approach the evaluation and improvement? Determine the problems and define a plan for improvement.

  • Define the problem(s) to be addressed (e.g., requirements defects are being identified late in the projects or poor communication between projects).
  • Define the goals.
  • Describe how you will measure success (i.e., desired effects).
  • Define the scope of changes (e.g., risk management planning process).
  • Identify team members who will develop, implement, and test the changes.
  • Define the action plan and completion date.
  • Execute the plan.

Try executing the changes for one of your projects to test the improvements.

Reviewing the Results

Once the team has executed and tested the improvement plan, the team should report their findings to the Steering Committee. The team should recommend one of the following:

  • Make the change(s) for subsequent projects.
  • Do not make the change(s).
  • Test again with modifications.

Final Thoughts

Implementing project management in an organization is not an easy task. Why? Because people are resistant to change, particularly when individuals do not understand the reason for the changes. Be patient. Listen carefully. Evolve at a healthy pace, not too fast and not too slow. Your Steering Committee can provide the feedback necessary to guide your pace and maturation.  

 

Five Bad Communication Habits to Avoid

A common denominator in challenged projects is poor communication. What are the results? Stakeholders make bad assumptions. Team members don't trust one another. Work has to be redone. Let’s look at ways to improve our communication by overcoming five bad communication habits.

lady speaking through a megaphone to a computer
rocket

“The single biggest problem in communication is the illusion that it has taken place.” —George Bernard Shaw

1. Communicating only once.

Busy Billy reviews the project charter to his team and other stakeholders in the kick-off meeting. Then he moves on to other project management tasks and never mentions it again.

How to improve:  Things pop up in projects and people want to know if it's in scope. At moments like these, project managers should review the charter with the project team to ensure that the team is aligned with the original intent of the project.

2. Giving stakeholders irrelevant information.

Some project managers email the project documents to all stakeholders including the project schedule, budget, process improvement plans, weekly status reports, project risks, and stakeholder analysis, to name a few. What do you think the stakeholders do? Yes, most ignore the email and miss critical information.

How to improve: Tailor your communication to the needs of your stakeholders. When analyzing your stakeholders—particularly your high-power/high-interest stakeholders, ask about their communication preferences. What information would they like to receive? How would they like to receive it?

3. Communicating to everyone the same way.

We all develop habits, some good and some bad. Are you one of those people who largely communicates in only one or two ways such as email and phone.

How to improve: Use a wider variety of communication channels including but not limited to:

  • Email
  • Meetings
  • Instant messaging
  • Teleconferences / Videoconferences
  • Internal blogs
  • Newsletters

Also, have more face-to-face communication when possible. This allows you to improve communication. How? Body language and facial expressions can greatly enhance the understanding between you and your stakeholders.

4. Thinking that communication will just happen.

Jovial Julie thinks people should understand things through osmosis. She jokes, “Why should I have to be the one to carry the communication burden? We have professionals on my teams. I’ve got more important project management responsibilities to take care of.” Really?

How to improve: Be intentional about your communication. Develop and execute your communication plan. Periodically, review and update the plan. Ask for feedback from your stakeholders on how you can improve your communication.

5. Not planning your project meetings.

How often have you attended a project meeting and left mumbling—what’s was that all about? Many meetings are a complete waste of time. Why? Little thought in the planning.

How to improve: First, Develop and distribute your meeting agendas prior to your meetings. Ask the meeting participants if they have agenda items they would like to include. Attach materials that participants should read and bring to the meeting.


Second, invite subject matter experts who can communicate the needed information and help the team analyze things.


Third, determine how you will facilitate the discussion points. Are there items in which you wish to brainstorm? Should you present a prototype? Will you illustrate with an example?


Lastly, determine how decisions will be made. Will the project sponsor make the final decision? Does the project team have the authority to make the decision? Perhaps, you—the project manager—plans to get the team’s input and make the decision.

The Purpose Driven Project Manager. Got soft skills? Discover how to improve your communication, develop trust within your teams, enhance your decision making, and run productive meetings in my book—The Purpose Driven Project Manager.

How to Improve Your Project Communication

In my project management workshops, I ask this question, "What are the top causes of project failure?" Nine times out of ten, I hear the answer—poor communication. Hence, let's look at how to improve your project communication.

There are many ways in which project managers communicate — coaching, summarizing action items, influencing a stakeholder, educating team members, listening, facilitating decisions, creating a contract with a third party, escalating an issue, and meeting with a project sponsor, to name a few.

What happens when poor communication exists? Stakeholders get the wrong information. Others get the right information but at the wrong time. Consequently, individuals misunderstand and make bad assumptions.

rocket

"Take advantage of every opportunity to practice your communication skills so that when important occasions arise, you will have the gift, the style, the sharpness, the clarity, and the emotions to affect other people." -Jim Rohn

Here's the bottom line -- poor communication drives projects into an abysmal valley. Your reputation is marred. The cost of your project spirals out of control. Heck, your team may even abandon ship.

image

The Purpose Drive Project Manager

Looking for ways to improve your interpersonal skills? Kick it up a notch with my book—The Purpose Driven Project Manager. Discover how to use your interpersonal skills to build high-performing, unified project teams.

7 Attributes of Great Project Communicators

If you want to improve your communication, consider these powerful attributes of great communicators:

  1. Intentional. One of the best ways to improve project communication is through the development of a communication plan. Who do you need to communicate to? What should be communicated? When will the communication occur? How will you communicate (e.g., face-to-face, email, presentation, meetings)? Why is it important? Click here for a communication plan template.
  2. Clear. The best project managers are clear. Put yourself in the shoes of your stakeholders. What can you do to ensure clarity in your messages? Most noteworthy, lead by communicating in simple and clear terms.
  3. Relentless. Some project managers start out with a blast, communicating wonderfully. Somewhere along the way, they lose their steam. The project manager gets busy and fails to distribute minutes or fails to tell the developers about decisions to change the requirements. In contrast, the best project managers have a healthy habit of reviewing and updating their communication plan regularly and relentlessly executing the plan.
  4. Unforgettable. Your stakeholders are bombarded daily by information — advertising, emails, tweets, messaging, podcasts, and videos. What can you do to stand out? How can you communicate in a creative manner that catches your stakeholder's interest and keeps them coming back for more? For example, I once saw a quality assurance manager and her testing team dress up like bugs and invited team members to throw water balloons at them to celebrate a milestone in the number of bugs (i.e., software defects) that they found.
  5. Wise. One of the best things that a project manager can do is review the lessons learned from similar projects. What were the communication issues? What decisions were made? How were they made? What were the results of the decisions? There's no need to make the same mistakes of prior project managers.
  6. Honest. One of the most important attributes of a leader is honesty. People want to know that they are dealing with someone who is trustworthy and has their best interest in mind. Don't shade the truth or hide information intentionally. Furthermore, look for ways to be as transparent as possible.
  7. Harmonious. Finally, most of our communication comes through our body language such as facial expressions and gestures. Speech and tone of voice are also key. Want to enrich your communication? Make sure your words, body language, and speech are in alignment.

Secure a Communication Mentor

None of us are perfect communicators. We are blind to our bad habits. For years, I had a habit of looking up and away from the person to whom I was speaking. Why? I was thinking about how to solve the problem we were discussing. I was unaware of how this behavior was annoying others.

We don't know what we don't know. So, how can we discover our communication issues?

Ask a trusted mentor or friend to provide feedback on the communication strengths and weaknesses. What do you need to work on? Your writing skills. Your public speaking skills. Listening.

Build A PMO You Can Be Proud Of

Some Project Management Offices (PMOs) never get off the ground. I've seen others that are started and a year or so later die a slow painful death. So, how can you build a PMO you can be proud of, one that thrives?

Why Are There So Many Troubled PMOs?

No one intends to build an impotent PMO, but it happens. The PMO lacks power and effectiveness. Therefore, people see the PMO as a hindrance, not an enabler.

Click here to discover 40 reasons PMOs fail. Furthermore, I describe how to handle PMO threats—things that may hinder your ability to build a PMO—here.

Let's look at five ways we can improve vitality and provide value to our organization.

rocket

"There is only one way to avoid criticism: do nothing, say nothing, and be nothing." –Aristotle

Five Keys to Successful PMOs

1. PMO Sponsorship. Without a strong, influential sponsor, the PMO is doomed. Don’t have a sponsor? Then don’t create a PMO. Because you will be fighting an uphill battle, one that you will likely lose.

2. Clarity. Define specific, measurable goals. How will you measure the success of the PMO? What are the Key Performance Indicators?

The PMO leader should also be clear about the type of PMO being implemented. The Project Management Body of Knowledge (PMBOK) describes three types of PMOs:

  • Supportive – provide support to project managers in a consultative role. Provide templates, training, best practices, and lessons learned. Control is low.
  • Controlling – require project managers to follow a project management framework or methodology using specific tools and templates. Control is moderate.
  • Directive – projects are managed by project managers in the PMO. Control is high.

Since clarity is essential to success, you must continuously cast the vision of where you are going, how you get there, and why you are going there.

3. Alignment. Define a process to ensure projects align with the organization’s mission and goals. What criteria will be used to select projects?

For example, the project selection criterion might include:

  • Strategic importance: Does the project tightly link with the strategic plan?
  • Financial viability: Does the project contribute to the financial success of the organization? Is the project profitable?
  • Flexibility: Does the project provide business and technical flexibility to accommodate future changes?
  • Risk: How high is the risk? What is the project risk score?
  • Regulatory compliance: Is the organization required legally to comply with new regulations?

Kill non-value added projects. Transfer resources to value-added projects. Certainly, resource management across the project portfolio is a critical success factor.

Some organizations also use a gate review process. At certain stages of each project, the project is reviewed to ensure continuous alignment.

4. Execution. Teach project managers to use a scalable project management framework or methodology. Provide templates to aid project managers in their execution. Another tip, offer to mentor and support project managers during the execution of their projects.

5. Continuous Improvement. Evaluate the framework, tools, techniques, templates, as well as the projects. Develop and maintain lessons learned.

How to Jump-Start a PMO

Thinking about starting a PMO? I recommend that you develop a project charter with your project sponsor and key stakeholders. Define the problems you wish to overcome, goals, deliverables, assumptions, constraints, and top risks to a successful implementation. You can build a PMO that you are proud of through early collaboration with your stakeholders, persistent leadership, and staying focused on delivering value to your organization. Best wishes!

How To Manage Fixed Date Projects

Fixed date projects occur often these days. The project sponsor picks a date and hands you the project. So, what's a project manager to do? How can we manage fixed date projects?

First of all, don’t freak out. Some things are unrealistic, but others are not. Be positive and ask for some time to do some analysis. Let your sponsor know that you will come back in a week or two with the results.

Second, seek to understand why. Why is the deadline so critical? Be careful in how you ask this. You’re not challenging the sponsor. Rather, you simply want to see things from the perspective of the sponsor. Listen carefully.

Third, start defining the scope. What are the deliverables and the priorities of each deliverable? Can some of the deliverables be implemented later? 

Fourth, engage your stakeholders early. Ask them to help you with the analysis. Seek their expertise.

What to Share with Your Project Sponsor

So, what do you share with your sponsor when your analysis is complete? Think of the situation like a puzzle. Consequently, you may offer different options.

  • Respond with a date range such as, "The desired deadline was March 31st. Our analysis shows that the project can be completed between May 1st and June 30th."
  • See if additional resources can be added. "If we can add these two resources at a cost of $50,000, we can complete the project between April 15th and May 15th."
  • Can the scope can be modified? "Furthermore, if we can remove or postpone the lower priority deliverables, we can complete the project between March 31st and April 15th.

So, what do you say to a project sponsor when you've completed the analysis and you know that the deadline is unrealistic? Tell them the truth. Explain the process you went through, who was involved, the constraints, and the results.

10 Things to Do in Fixed Date Projects

When challenged with a fixed date project, think of it as an opportunity. Often times, you can deliver the project on time with the right approach. Here are some things to consider:

  1. Be positive. Establish a positive working relationship with your sponsor and stakeholders.
  2. Negotiate for the best resources. People, more than anything, will win the day.
  3. Select your project lifecycle. Will you use a traditional waterfall approach or an agile method? The answer to this question has significant implications in aiding or hindering your goals.
  4. Define the project charter. Include a problem statement, goals, deliverables, assumptions, constraints, exclusions, high-level risks, stakeholders, and team members.
  5. Define and prioritize requirements. In agile projects, work with your product owner to define and prioritize your user stories in the requirements backlog.
  6. Define the scope. Clarify what will be included in the product scope and determine your project scope—the work to be done to create and deliver the products, service, and results.
  7. Create the work breakdown structure (WBS). One of the best ways to engage your team members and define the scope is through the facilitation of a WBS exercise
  8. Develop your schedule. If your critical path extends beyond the fixed date, work with your sponsor and team to reduce the scope or postpone features for future stages or iterations (part of managing the triple threat constraint).
  9. Complete the initial risk identification and assessment. 
  10. Build a contingency reserve. This reserve is not an artificial buffer. The contingency reserve is based on known residual risks.

Keep in mind - good risk management often shortens the project. Risks are eliminated or decreased. However, there are always residual risks that should be recognized in your contingency reserve. For example, you may specify that the project requires an additional six weeks to accommodate risks on the project.

Two Ways to Deliver Faster

  • Add resources to critical path tasks. Be careful. Adding resources or stretching existing resources may cause more harm than help. Crashing also results in increased costs.
  • Fast track tasks. Look for ways to execute critical path tasks in parallel. Be careful—​fast-tracking tasks can result in rework and greater risks.

Your approach to a fixed date project will determine your success. The project manager must have the right attitude, ensure appropriate commitments by the sponsor and the team, and select the right processes, tools, and techniques.

3 Reasons IT Software Projects Fail

You've heard the war stories of companies that tried to implement commercial software solutions or build new systems. Maybe you've even participated in one or two? Many of these endeavors took longer and cost more than expected. Others were outright failures, adversely impacting the company's bottom line. Let's look at 3 reasons that IT software projects may be challenged or fail.

The Standish Group conducts an annual survey to see why some IT software projects are successful and others fail. Year in and year out, the survey shows approximately one-third of the projects are successful: come in on schedule, on budget, and delivers what was promised. Most projects miss the mark—they are completed late or over budget or lack quality, or some combination of these attributes.

But, it doesn't have to be that way. We can be successful! It starts with understanding the most common causes of software project problems.

3 Biggest Factors to Challenged & Failed Projects

1. Lack of User Input

Imagine a software project where the project team delivers the project on time and under budget. But the software does NOT meet the users' needs. Why does this happen?

Project teams have their pants on fire! Everyone wants the software yesterday.

So, how do most project teams respond? They skip the critical step of collaborating with the users. These teams make assumptions about the user needs without even asking.

Oh, you wanted to have data prefill? Didn't know that.

Want your customers to be able to access their policy information online? Why didn't you say so?

Users assume that the project teams already know their needs. That's not always the case. In fact, often, the teams don't know.

More times than not, users see the software for the first time during training, not earlier in the project when requirements are being elicited or when the software is being designed and configured. Not even when the testing is being performed. The avenues for user input is limited, resulting in less-than-stellar software.

rocket

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." —Frederick Brooks

2. Incomplete Requirements

No surprise. If the users are not engaged, the requirements—the users' needs—will not be understood. What happens in these projects whether taking a traditional or agile approach? The missed requirements are discovered later. And, the rework starts, resulting in adverse impacts to the project schedule and budget, as well as the team's morale.

3. Changing Requirements

Project teams complain that users don't know what they want and constantly change their minds. That may be true—sometimes. But, what would you expect when the users are not asked for their input earlier in the projects? Furthermore, we live in ever-changing industries that requires that we be able to handle changes.

Leading IT Software Projects

I know that you're smarter than the average Joe. You know that doing the same thing and expecting different results is insane. Let's take a powerful and decidedly different approach.

  1. Engage your users in the requirements process
  2. Progressively elaborate and refine your requirements with the users
  3. Expect (and even invite) change by using an agile, adaptive approach 

Are You Making These Risk Response Mistakes?

Some project managers make timely responses to risks, resulting in positive progress toward their project goals. Others act haphazardly, resulting in undesirable consequences. Let's look at some common risk response mistakes and how to overcome them.

So, what do I mean by risk response mistake? A mistake is an action that is misguided or wrong.

rocket

"If you treat risk management as a part-time job, you might soon find yourself looking for one." —Deloitte

Joe Cunningham once managed a project to implement a commercial-off-the-shelf (COTS) software solution for a bank. He and the team had identified the project risks, but they had failed to analyze the common causes of the most significant risks. Consequently, the team was responding to risks but missing the high-leverage responses.

Perhaps you are making mistakes like this one. But, you don't have to.

I've created a list of ten risk response mistakes. I'm sure that you aren't guilty of all. Read through them, thinking about one of your projects. Make notes where you might improve.

10 Risk Response Mistakes

  • 1
    Failure to identify risk owners. Once a risk has been identified, project managers should ask, "Who owns the risk?" A risk owner is a person responsible for developing and executing a risk response plan.
  • 2
    Failure to respond to several small, related risks. If we fail to analyze the relationships between risks, we may not understand how risks relate to one another. Individual small risks seem powerless. However, several small, related risks can have a powerful impact.
  • 3
    Failure to identify and plan for secondary risks. When risk owners are developing risk response plans, they may fail to consider secondary risks, risks that arise as a direct result of implementing a risk response. Wise project managers educate and ask their risk owners to identify and plan for significant secondary risks.
  • 4
    Failure to develop contingency plans. Some risk response plans are executed immediately; other risk response plans are contingent. That is to say; the plans will only be executed under certain predefined conditions.
  • 5
    Failure to develop fallback plans. What should a risk owner do if the contingency plan fails? Risk owners should develop and be prepared to execute a fallback plan for significant risks. The fallback plan may be used to mitigate further a threat or enhance an opportunity. A fallback plan may also be defined for cases where a risk may occur.
  • 6
    Failure to define risk triggers. Some risk owners do a great job of defining contingency plans but fail to define clearly the risk trigger such as missing a milestone. Triggers may be used to provide the warning that the risk is about to occur, providing time to implement the risk response plan.
  • 7
    Failure to respond to opportunities. Many project managers still struggle with the fact that risks include positive events or conditions, that if they occur, cause a positive impact on the project goals. Therefore, many project managers fail to identify these positive events and miss the opportunities that could save the project or enhance the project's value.
  • 8
    Failure to update project management plans including the schedule management plan, cost management plan, quality management plan, procurement management plan, human resource plan, scope baseline, schedule baseline, and cost baseline. As risk owners develop response plans, project managers should update the project management plans accordingly. For example, the project manager may add new activities to the schedule and further define how contingency reserves will be consumed.
  • 9
    Failure to update assumptions log. Project managers and team members make lots of assumptions, particularly in the early parts of a project, based on the information at hand. As the project team discovers new information, previously identified assumptions may need updating, or new assumptions may need to be added.
  • 10
    Failure to create contracts or agreements with third parties. Some risk owners may wish to leverage a third party to respond to risks. The project manager should ensure these decisions and contracts are outlined and approved as needed.

Taking Action on Risk Response Planning

Consider using this list as a checklist for one of your current projects. Keep your risk management as simple as possible while ensuring that the responses are economical and effective. Scale your response plans as needed; do more planning for larger complex projects and less for smaller projects.

It’s Easy to Miss Project Risks

It's easy to miss project risks. And, until a project manager has identified the threats and opportunities, the risks cannot be managed properly. Projects rise and fall with the project manager's ability to properly identify and manage their most significant risks.

Project managers don't want to spend an inordinate amount of time identifying risks—rightly so. 

Neither can project managers afford to miss the critical risks. Let's look at strategies to identify risks and save time when identifying project risks. You can choose and scale these strategies as needed.

Risk Identification Techniques

1. Use a risk list. A risk list is a list of potential risks for an industry, organization, or company. Ideally, the risks are listed by categories such as schedule, budget, quality, and scope. For example, you could identify schedule risks using a schedule risk list such as:

  • Schedule is missing key activities
  • Excessive schedule pressure
  • Schedule is optimistic, not realistic
  • The product or service cannot be developed to the size specified in the time allocated
  • Schedule was baselined without review by key stakeholders
  • Scope has increased with no change to the schedule
  • A delay in a critical path activity is causing cascading delays in the subsequent activities
  • A key resource has been reallocated half-time to another project, adversely impacting the work on this project
  • Estimates were created by the project manager, not the individuals doing the work
  • One activity may not provide the required information that a subsequent activity needs
  • Coordination issues are arising from the crashing of several critical path activities

2. Use risk categories. What can we do if we don't have a risk list? Try a prompt list, a generic list of categories used to "prompt" the identification of risks. Typical project risk categories include:

  • Schedule risk - schedule events or conditions, that if they occur, will cause a positive or negative impact to the project goals
  • Budget risk – budget events or conditions, that if they occur, will cause a positive or negative impact to the project goals
  • Quality risk – quality events or conditions, that if they occur, will cause a positive or negative impact to the project goals
  • Scope risk – scope events or conditions, that if they occur, will cause a positive or negative impact to the project goals

3. Identify internal and external risks. It’s obvious that we need to identify internal risks. However, project managers may fail to identify external risks. Out of sight, out of mind. For example, an organization may contract with a third party to provide products, services, and supplies. There is the temptation to forget about it.

Just because a contract exists does not mean that the project manager has washed her hands of these risks. The project manager is still responsible for overseeing the activities, making sure the contracted products and services fulfill the project’s needs and integrate properly into the project deliverables.

rocket

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.” —Mark Twain

4. Perform top-down and bottom-up risk identification. With a top-down approach to risk management, the project sponsor (and sometimes senior management) declares which threats and opportunities matter. The benefit is that it provides a high-level perspective. The project sponsor defines the project goals and determines the business strategies to make it happen.

However, the project sponsor will not likely understand the project planning and execution risks. A bottom-up approach provides the advantage of getting the views of the team members and key stakeholders. An excellent tool for the bottom-up risk identification is the work breakdown structure (WBS). The project manager can work with team members to discuss the lowest level WBS activities in order to identify risks.

5. Perform risk reviews periodically. Remember—risks change over time. Imagine never having your vehicles checked or never having a physical exam by a doctor. Project risk reviews should be performed regularly. In addition, reviews should be performed for the following events:

  • Significant change of project goals, deliverables, assumptions, of constraints
  • Change in team members
  • Significant change in requirements
  • New or changing external requirements such as regulatory requirements or contract requirements
  • High number of issues are occurring

Risk Identification Tips

Keep in mind, we are NOT trying to identify every possible risk. We are scanning the project environment to find the most significant risks. If done properly, these strategies can help us identify the critical risks quickly. Then we can take the next step—treat the risks.

Some project managers take a different approach - it's called wait and see. It works like this: Don't invest time (i.e., waste time) identifying and treating risks. When the uncertain event or condition occurs, the project manager would fix it—translate, the project manager and affected stakeholders would put out the fires!

Responding to issues almost always require more time and cost more money than identifying and treating risks ahead of time. Being disciplined and applying an appropriate amount of time and focus on risks can reduce project expenses, promote the project schedule, reduce stress, and help a project team achieve its mission.