I noted earlier that I would write a series of posts on risk management. That series will largely be based on the Project Management Body of Knowledge (PMBOK), Fourth Edition. But I thought it best to first discuss and frame the issue of risk management. Why would we do it? And what are the impediments in an organization to doing it effectively?
In the last session, I gave an overview of what risk is and why it might be important, if not mandatory, to do risk management in your project. Today I want to talk about the first level of risk planning, which is to create a risk management plan. Now these management plans that we often see in the Project Management Body of Knowledge (PMBOK)
Now that we’ve done our risk management planning, the very next step is to identify risks. This is exactly what it sounds like – brainstorming to figure out what possible bad things might crop up to bite you during the project. How do you do this? Well, quite simply, get the team in a room. With stickies. First thing you should have them do
Now that you’ve identified all the risks on the project, you have to figure out which ones have priority over others, either by imminence or, most likely, by greatest probability and impact. They can’t all be priority number one no matter how much easier that may seem for us. PMI calls this process Qualitative Risk Analysis. They say that,
If you were following the PMBOK religiously, the next thing you would do is quantify risk which “is the process of numerically analyzing the effect of identified risks on overall project objectives.” 1 Choices here are: ·Sensitivity analysis – looking at the impact of an individual risk on a project objective ·Expected Monetary Value –
So now that we’ve looked at avoid and transfer, let’s look at accept and mitigate: Accept. There are two kinds of acceptance: passive and active. Passive means exactly what it sounds like – I recognize the risk but don’t do anything about it. This is typically for a risk that is so low in impact and probability that you don’t need to
Today begins a new series of posts on rescuing a troubled project. It is written entirely by our friend and colleague, Bob Louton. Enjoy. The mindset for rescuing a project At some point in a project-management career, we can find ourselves assigned to rescue someone else’s project. More often, we need to rescue our own project. This article
We continue our series on rescuing troubled projects by Bob Louton, PMP. This post discusses the most urgent part of a project to stabilize, stakeholder management. It has served me well always to start here. This means that you should concentrate your time on finding and fixing the big problems with stakeholder management ahead of all other
We continue our series on rescuing troubled projects by Bob Louton, PMP. This article discusses the second most urgent of the project items to have working well, configuration management. After you have addressed the big problems with configuration management (CM), you can turn your focus to the next on the list. I will cover that in my next
We continue our series on rescuing troubled projects by Bob Louton, PMP. This article discusses the 3rd-most urgent of all process areas, the project plan. After you have addressed the big problems with the plan, you can turn your focus to the next on the list which we’ll discuss in the next post. Now I can already anticipate how some
We continue our series on rescuing troubled projects by Bob Louton, PMP. This article discusses the 4th-most urgent of all process areas, requirements management. After you have addressed the big problems with the plan, you can turn your focus to the next on the list. For every project I’ve ever been on, the project team had a love-hate