Stakeholder analysis is one of the most important tasks in project management. Stakeholders are the people who are affected, positively or negatively, by the project. You must make an effort to the identify the project stakeholders early in the planning process. Let’s look at an example of a small project and see how to identify the project stakeholders.
Stakeholder Analysis Example: Part One
The boss calls you into her office and tells you she is getting complaints from other managers about items out of stock (stock-outs) in the supply room. This situation is wasting people’s time and delaying their work because they can’t get their materials when they need. She goes on to tell you that she wants you to run a project to cut the number of stock-outs in the supply room. She will be the project sponsor. Stakeholder Management Process
You ask some probing questions to quantify the project scope and the acceptance criteria. She states that less than five stock-outs a month would make the project a success.
With the initial scope defined, you tell her the next step is to identify the project’s stakeholders. Then you must do stakeholder analysis. That includes speaking with them to understand their issues with the supply room and their requirements for improving it. The sponsor shakes her head and says, “Let’s not turn this into a never-ending circus by asking other people to give us their to do lists. We’ve got to make a plan and identify how we’re going to deliver the project scope I just set. Let’s keep the planning group small so we can move fast. I don’t want to involve a lot of people who have other ideas we’d have to consider.
You say, “Well if I don’t identify project stakeholders and get their ideas, it may come back to haunt us at the end of the project.”
The sponsor interrupts and says, “We know what we need to do in the supply room. We don’t have to let other people stick their noses into this project.”
You say, “I really think that is a mistake…”
“Then it’s my mistake,” the sponsor said. “I want you to get started making the detailed plan.”
Over the next few days the planning went rapidly and you were able to develop high-level deliverables and a work breakdown structure. You identified procedure deliverables, training deliverables and a new workflow for managing inventory levels. The sponsor approved them all and she assigned people from her department and one from the supply room to serve as your project team and authorized you to start work.
Stakeholder Analysis Example: Part Two
Things went very well for the first week and you and your small team knocked off one deliverable after another. But as you moved into the implementation phase you ran into a couple of problems. FiInfluencing Project Stakeholders
First, the project sponsor called you and said, “The purchasing people have their nighties in a knot about how you want to manage the supply inventory. You better get down there and talk with them about what you want to do and get their cooperation.”After spending the next two days meeting with the purchasing people and modifying the entire workflow and procedure you had developed to meet their requirements, you were behind schedule. You knew you would have to hustle to avoid any more slippage in the schedule.
Then the human resources trainer finally returned your call. She explained that the training you wanted on the new supply room procedure did not meet corporate standards for training classes and needed to be extensively revised. You explained that the supply room procedure was undergoing modification anyway and the trainer explained that you should have involved her in this process from the beginning.
You stopped the team members who were revising the supply room inventory procedures and told them they would have to wait until the end of the week for a meeting with the human resources department trainer.
Stakeholder Analysis Example: Part Three
To bring an awful week to an end, you met with the project sponsor to submit your status report and explained why the project was at least a week and possibly two weeks late compared to the original plan finish date.
The sponsor asked what the problem was and you said, “We did not identify our project stakeholders in the beginning. That would have let us gather their requirements before we started work. Now we are discovering those requirements and having to redo much of the work we have done over the last two weeks.”
The sponsor’s facial expression went from anger to embarrassment and she said, “Next time we’ll identify the project stakeholders early and do a better stakeholder analysis.”
Learn how to do stakeholder analysis and management in our online project management basics courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.
Here is How To Do Risk Analysis for your project. After you have identified the risks your project faces, you need to do a risk analysis to determine which ones call for a risk response and which do not. The purpose of risk analysis is to rank the list of identified risks in order of significance or importance. Your risk analysis focuses on qualitatively assessing the probability that the risk will occur and the magnitude of its impact if it does. You will use this qualitative risk analysis to decide which risks are important enough to warrant a risk response. Risk Management Main Page
How To Do Risk Analysis: Step 1 – Qualitative Analysis
Qualitative analysis assesses how much the risk could hurt the project but is doesn’t use any numbers. Qualitative analysis has the benefits of being cheap and fast but it lacks precision. You can easily do qualitative analysis by meeting with three or four team members and stakeholders in the cafeteria for coffee. You list the risks you have identified that can possibly affect the project. For each risk, you ask them to assess whether it is very likely to occur, moderately likely to occur or unlikely to occur. When you have that information from each attendee, you ask them about how much damage the risk will cause if it does occur. Will it cause just a little damage, a medium amount of damage or a lot of damage?
As you can see, this is not a very precise method but it does give you the opinions of your stakeholders and team members. If you have any risks that are very likely to occur and will cause significant damage, you will plan a risk response for those risks. The less significant risks you have identified are things you will watch out for but you won’t plan a formal risk response for them. On smaller projects, you will probably limit the risk analysis to these qualitative techniques and planning risk response(s) for the significant risks. Small Project Risk Management
You may also decide that one or two risks are so significant you should preform a quantitative risk analysis. The cost of the higher-level quantitative risk analysis probably requires the sponsor’s approval. Risk Responses
How To Do Risk Analysis: Step 2 – Quantitative Analysis
Quantitative risk analysis is both expensive and time-consuming. Usually, it is done only on very large projects which face very significant risks. Only in that situation could you justify the cost and weeks or months of effort which can go into a quantitative analysis. Regardless of which quantitative risk technique you utilize, the end result is the expected value of the risk. You calculate that by multiplying the probability of the risk occurring times the magnitude of the impact if it does occur.
Here’s an example. Let’s say your quantitative risk analysis determined there is a 0.001% chance that the company headquarters would be destroyed by a tornado during the coming four months. It also estimated that the magnitude of that risk (the damage that the tornado would cause) could be valued at $800,000. Now that risk probability is pretty small but the magnitude is pretty large. To combine them into a single number that lets you make a good decision, you would multiply that probability times the magnitude and come up with an expected value of the risk of $800. What that expected value means is that if you did this project 10,000 times with the same tornado risk, the average damage would be $800. So you can’t justify spending more than that amount ($800) to avoid the tornado risk. The quantitative risk analysis says you can have only a very limited risk response program if you must keep the cost under $800, the expected value of the tornado risk. Presenting Your Risk Plan
To learn more about how to manage project risks, consider one of our online project management courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.
The project lessons learned process is ineffective in most organizations. One project after another suffers from the same mistakes. What is even worse is that the bigger the project failure, the less likely they are to learn from it. The same issues that cause a project to fail also prevent the people involved from learning from the failure. Organizations need processes to make sure they don’t relive project failures. Let’s take a look at a typical project lessons learned session and then talk about the right way to do it.
Project Lessons Learned: Poking Through the Wreckage
You shuffled into your project lessons learned session, sick and tired of political games and finger-pointing. Twenty minutes later, you trudged out with the voices still echoing in your head:
“You’re responsible for us finishing late!”
“Me? You kept making changes. I’m surprised we ever finished!”
“You still aren’t finished; the garbage you gave us still doesn’t work!”
“What? We gave you what you asked for! But you didn’t train your people to use it”
“They need PhD’s to use what you built!”
You walked down the hall knowing this was your fault. Sure, there were a few jerks involved and it would be easy to blame them. But a good project manager should be able to structure things to make even the jerks productive team members.
Even though scenes like this repeat themselves after every project, many organizations don’t improve their processes for doing projects. The same problems wreck one project after another. But there is an alternative. What you need is a lessons learned process that gives the project managers an opportunity for continuous improvement. The time you invest in your lessons learned process can positively affect projects that are underway. It can also reinforce the use of a consistent project management methodology. You build the project lessons learned process in the following three stages. Lessons Learned Project Management
Our 4PM clients have increased their success by using peer reviews of projects that are nearing launch. That sounds fancier than it is. In this first stage of the project lessons learned process, project managers get feedback on a their plans from other PMs. They have a meeting (in-person or online) to discuss a recent plan. That gives PMs the chance to share ideas and renew their understanding of the methodology.
The pre-launch stage is a busy time for project managers but it’s also the point at which correcting mistakes is least expensive. The process is straightforward. The other project managers review the user’s or client’s business situation. Then they independently critique the project’s plan, scope, requirements, WBS, charter, accountability structure, team member assignments and the schedule. Reviewing several project plans doesn’t take the other PM’s very long if the organization’s project management methodology emphasizes thinking , not creating paperwork.
In the project lessons learned session itself, the other PM’s ask questions and offer ideas. The project manager whose work is under review may or may not take them but they get the benefit of the ideas and opinions of other people engaged in the same type of work. Every project manager suffers from tunnel vision as he or she works through the development of a detailed plan. The thinking of other project managers who are not buried in all the detail is very helpful. It’s easier for them to spot any disconnects between the user’s/client’s business problem and the project plan details. It’s important to keep this conversation focused on “Are we doing the right project for this business problem?” and “Does the planned control process make sense for the desired business result and resources involved?” The conversation should be at that high level and not sink into a technology debate.
Project lessons learned sessions are effective in building consistency in the use of a project management methodology. Compliance with project management standards tends to slip under the pressure of all the work to be done just prior to launch. But when project managers know their peers will be reviewing their work, they comply at a point in the lifecycle where comments from the project office or standards people might otherwise be brushed aside. These pre-launch peer reviews are ideal for reinforcing the organization’s project management methodology. You have the right people gathered and you’re dealing with real business situations and projects, not theoretical ideals. So these sessions are good opportunities to renew people’s skills in using the organization’s project management methodology.
The second stage in the project lessons learned process is regular (usually weekly) review of project variances. This can be at the end of the weekly status report or team meeting and after you have defined corrective action for the variances. You review the variances again and focus on how to avoid them in the future. You also identify other tasks or people who are likely to encounter the same issue so it can be avoided. The focus is on ways to avoid a repeat. It does not take long to identify the options.
To accomplish this project lessons learned review, the project methodology must give you a reliable method of identifying changes to the approved baseline schedule. You need a methodology that gives you objective measures of project progress plus the work and cost estimates to measure the variance.
Project Lessons Learned: Stage 3 – Project Team Culture and Leadership Style
The last stage of the project lessons learned is the periodic assessment of your leadership style and the culture of the project team. The work attitudes and effectiveness of the team members are strongly influenced by your leadership behavior. Even a professional team may suffer in silence about the project manager’s leadership and not take the risk of providing constructive feedback. Frank feedback is very useful so you have to make it safe for them to give it.
An effective technique is to ask the team to have lunch together once a quarter. You don’t attend but you ask them to a write a summary of their consensus of your strengths and weaknesses. You should digest the information but not ask questions about it. Most importantly you should not make them justify any of their negative findings. That makes you seem defensive. Good project managers act on negative feedback and make improvements. Bad PMs can’t handle the criticism so they dismiss it, learn nothing and never improve. Lessons Learned Questions
Project Lessons Learned: Summary
The three-stage project lessons learned process for project management improvement is an important element in moving the organization toward delivering consistently successful projects. It also can contribute to developing consistently effective project managers. We include this project lessons learned process in our project management methodology so organizations and their PMs get better over time and don’t repeatedly relive failures.
You can enhance your PM skills and master the project lessons learned process in our online project management courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.