Hello everyone. Last time, I introduced three representative approaches (PMBOK/PRINCE2/CMMI) and provided an overview of “project management” which is one of the soft skills that support problem solvers.
Among the above 3, PMBOK should be focused as a problem solver, right? This time, I would like to be a little more specific about the tasks that need to be added as “Project Management” by mapping PMBOK with the general problem solving (as-is ~ to-be) and Lean Six Sigma procedures that I have written so far.
1. Tasks that need to be added as Project Management
So, let me map first.
It’s a bit complicated (lol), but let me explain it in order.
First of all, the way of proceeding general problem solving (as-is ~ to-be) and Lean Six Sigma, and PMBOK’s “process (horizontal axis)” are generally covered each other, although there are some differences in the order. Please note that there are 2 possible steps for general problem solving (as-is ~ to-be) and Lean Six Sigma. First, the step of finding root causes of the problem and coming up with solutions (Step 1), and Second, the step of implementing the solutions (Step 2). Both can be executed as a so-called “project”, so in that case “project management” is necessary for both.
Next, let’s confirm the vertical axis “knowledge area” of the PMBOK table. PMBOK has a total of 10 knowledge areas, of which “Integration/Scope/Time/Stakeholders/Quality” management are already covered by the flow of general problem solving (as-is ~ to-be) and Lean Six Sigma.
And “Communication management” is covered by Change Management which I posted before, right?
Then, what needs to be covered as “Project Management” is the management of “Risk/Cost/Resources/Procurement”.
Here, I would like to explain “Project (simple version)” and “Project (full version)” in the PMBOK table above.
The definition of the word “project” is defined in PMBOK as “a temporary task that is carried out in order to create a unique product, service, or product”. Certainly, I think that everyone has a perception that it is work with a deadline that is different from so-called “routine work”, but it can be said that what is actually called a “project” varies considerably from company to company.
I think there would be some companies set up organization like a so-called “project investment committee”, and only projects that are approved here are allowed to acquire budgets and resources (mainly project members) and execute them. But I also think there would be some companies where they are not so strict, and execute projects “what came out from Gemba as they are” (lol).
And, regarding the above “project (simple version)” and “project (full version)”, “project (full version)” is the one that properly secures the budget and resources, and “project (simple version)” is the one that does not. I would like to call them as such here.
In case of the “full version”, it is important to complete the project within the budget, so “cost management” is required. In addition, “resource management” to identify and procure the necessary resources within the budget, and if the resources are outside the company, “procurement management” is required. This area is important work for consulting firms (especially those who are “managers” or above), so I think it is like a teaching fishes to swim (lol). Even if you are working for general business companies (non consulting firms), and if you are working for large companies that have something like “project investment committee”, I think that this area should be well implemented, so let me skip these in this blog.
Actually, the “problem solving” I have written in this blog has a strong image of the “simple version project”. In that case, “Risk Management” should be added as “Project Management”. The explanation of Fig1 became long (laughs).
2. “Risk Management” Overview
What is “risk”? The term “issue” is often confused. “Issues” are problems that have already become apparent, and “Risks” can be said to be “potential problems” that have not yet occurred but may occur in the future.
“Risk management” is to identify these potential problems at an early stage, analyze the causes and their degrees of impact, and consider risk mitigations (countermeasures). Please see here for details.
In PMBOK, it is called as “risk register”, but for example, you can use a format like this to manage it.
Since this is management, it is not enough to just write them down, but it should be reviewed regularly. If there is a steering committee, etc, I think it would be good to include it as one of its agendas.
That’s all for this time, and I would like to continue from the next time onwards. Thank you for reading until the end.