Click the image above to go to the Capability Maturity Model.
The new Project Management Body of Knowledge Guide (released September 2017)
is the 'how to do it' checklist for Project Management Professionals.
The dashboard assists understanding of the PMBOK processes (+ "ittos")
to help you to pass the PMI exams and run projects better at Capability Maturity Level 2+.
The PMBOK processes (underpinned by the latest thinking found in the
PMI Agile Certified Practitioner (PMI-ACP) qualification and others)
incorporates Lean and Agile thinking.
Oh, also... do not forget that the PMBOK operates as a Standard!
Check out where it is situated in the greater scheme of things
as you "connect the dots" below.
A quick note to those "Traditional" is not "Agile" out
Find process 4.7 on the PMBOK dashboard (Close Project or Phase).
Did you know that "tailoring" these processes means you can run a project phase
as... wait for it...
"a two week sprint!"
Operating thus, as a Professional who understands Project Management Process,
(supported by your Executive [Executive Action Team (to EAT "the red beads,")])
using best selected project methodology,
there is less chance of dropping the ball.
Note above that the PMBOK is a Standard!
Click the image above.
Answer the questions about People, Process and Technology.
Slide #6 has more depth on the P-P-T triangle (triad).
Now answer the questions about Governance and Execution then click the buttons below.
Here is the game!
Can you see it?
Governance (derived from the Latin gubernēre) means "to steer."
As you would a car, a boat, a horse drawn carriage or a horse etc.
Execution (derived from the Latin executio which means "accomplishment" or "fulfillment") is all about professional ability and tight management to produce results!
Unlike Business As Usual (BAU) a
project is a temporary undertaking!
In essence, via the project, you are jumping a gap from one baseline to a new (improved) baseline (destination, goal etc.).
Planning and Monitoring and Control on either side of Execution ensures
delivery and ultimately accountability to Stakeholders.
Can you find the Planning, Execution and Monitoring and Control Process Groups
on the PMBOK dashboard?
If interested Slide #16 has more information about how PDCA fits into this picture.
Do you know that many formulated strategies (and projects) fail in Implementation.
Have you found using Balanced Scorecard (in itself) has not been that successful?
Can you see the PMP and CMMi lego brick (at the top right of the image above)?
(It is to the right of the Balanced Scorecard, enabling it for success.)
Click the image above (to open the PMP CMMi lego brick) to reveal the secret to successful strategy (and project) Implementation. Then make careful note of how to empower these bricks (all the bricks in the strategy) at CM Level 2+ per the image below!
Note that level 2 is all about pinning down the essential project management processes.
If you run traditional or agile projects these essential processes will still apply!
CM Level 4 and 5+: "Based on Production Stats and Focus on Continual Improvement."
CM Level 3+: Process, Project, Software Engineering
CM Level 2+: Mainly Project (but also some other) Processes are Understood,
Applied and Managed.
CM Level 1: Heroic
No Plan, Be Heroic and Just Do It is CM Level 1
Just for fun click here for the games @ CM
CM Level ZERO: No Ethics. Corruption.
Move your mouse over the image directly below.
Note: Look for ML on the table below.
This is the Capability Maturity Level.
Click the image to get the importance of this!
Bottom line: pull the P-P-T points of the triangle
in relation to each other; improving while maintaining balance.
Hover over the image below to get the importance of avoiding
the tar pit.
The tar pit is where badly run software engineering projects get bogged down and die!
Bidirectional Traceability of Requirements is at the heart of (Requirements
Management [REQM] & Configuration Management
Can you find REQM & CM on the CMMi Dev Dashboard?
What is the Capability Maturity Level of REQM & CM?
What about Verification (Ver) and Validation (Val)? Can you find these CM L3 processes?
Can you see that these are all about "Minding the Gap," "Step by Step" and "Start, Change, Stop?"
( Latest agile thinking here agrees with this approach)
Finally, can you see that this side of the Gap is where you (software developers / ITIL Service Designers) are now.
In a next project phase (iteration, sprint etc.) you will move forward with the project goal to safely release a new version of valuable software.
After UAT sign off Service Operations must take over, maintaining the working system
while Service Strategy and Service Design look at next versions of Working Software.
Can you see that SAFe is simply a bunch of consolidated
Agile (Scrum), as opposed to Traditional (using long range planning)
is a voyage of discovery and improvement!
(I.e. "Working Software Demo" to next "Working Software Demo" in product increments!)
Can your sprints actually deliver (release) new versions of
into production after a sprint (number of sprints)?
Based on agreed User Stories moved to the sprint from the groomed backlog,
does the Product Owner agree that working software has improved the specific system software baseline for "particular IT Infrastructure stack" and software can now be released (Dev=>QA=>UAT=>) into production?
Note: Segregation between Dev and Ops is there for a reason.
The "you build it you own it" mantra only works well with "Empowered Workgroups" at CMMi Dev and People Capability Maturity (PCMM) Level 4!
Per Gene Kim below the role of the Scrum Product Owner (as (or to empower) "Release Manager") is crucial for success!
I.e. PP (Project Planning) and PMC (Project Monitoring and Control)
(per the dashboard on the home page)
as fingers and thumb,
squeeze out Production (Project Execution).
This "pressure" to "release" on demand (like needing toothpaste from a tube) in the Scrum Method comes from dynamic tension as the Product Owner interacts with the Scrum Master and Scrum Team.
Can you see that the ITIL CSI register is also the Scrum Backlog?
Can you see that ITIL Service Strategy Slide #8 is where valuable improvements (Product Owner (Release Manager) Groomed and Risk Adjusted Scrum Backlog Items) are plugged in to be built?
Can you see that developers work in Service Design, Transitioning service improvements into Service Operations?
For more detail the ITIL and DevOps slides.
Scrums to be effective from an agile perspective must focus each, ONLY ON THEIR OWN GAMES. Consolidating scrums for "SAFe"ty as a program must be automated via others in program management using the Project Management Information System. Scrum of Scrums can be used (carefully so focus is not lost on game focus) if scrums share joint objectives
If your scrums are not releasing working software
(as with the problems [and chaos] associated with traditional project management
if badly run at CM level 1 or below)
can be just as unsafe!
In order to run projects (especially Agile) correctly your people need capabilities and maturity.
Agile postulates the cohesive empowered professional team
with all the skills required within the team!
These "empowered workgroups" are normally only found at CM Level 4.
Can you see the truth of this?
As a test of this (and where the Executive need to remove the red beads),
if you have a scrum team (as example),
find out how many on the team actually have the entry level foundation certificate of competency for the scrum method?
Executive support [Executive Action Team (to EAT "the red beads")] is the key to success!
Make sure your people are trained / certified!
Can you find BAI01 Manage Programs and Projects?
As with tailoring the PMBOK processes (and other method processes), Cobit needs to be implemented
systematically so that it leverages off installed, operational and stable CM Model processes.
Systematically installing the essence of the previous slides
(in bite sized and digestible chunks)
means Cobit is now also installed!
The image below explains why
"Just Do It" at CM L1 is really a bad idea!
Can you find PLAN, DO, CHECK (Monitor and Control) and ACT in the PMBOK
dashboard on the home page?
You can also find it in the last image at the bottom of this page!
How about looking for it in Agile (Scrum)
How about looking for it in (ITIL Slide #8)?
PDCA (plan do check act or plan do check adjust) is an iterative four-step management method used in business for the control and continuous improvement of processes and products. It is also known as the Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, or plandostudyact (PDSA). Another version of this PDCA cycle is OPDCA. The added "O" stands for observation or as some versions say "Grasp the current condition." This emphasis on observation and current condition has currency with Lean manufacturing/Toyota Production System literature.
Establish the objectives and processes necessary to deliver results in accordance with the expected output (the target or goals). By establishing output expectations, the completeness and accuracy of the spec is also a part of the targeted improvement. When possible start on a small scale to test possible effects.
Implement the plan, execute the process, make the product. Collect data for charting and analysis in the following "CHECK" and "ACT" steps.
Study the actual results (measured and collected in "DO" above) and compare against the expected results (targets or goals from the "PLAN") to ascertain any differences. Look for deviation in implementation from the plan and also look for the appropriateness and completeness of the plan to enable the execution, i.e., "Do". Charting data can make this much easier to see trends over several PDCA cycles and in order to convert the collected data into information. Information is what you need for the next step "ACT".
Request corrective actions on significant differences between actual and planned results. Analyze the differences to determine their root causes. Determine where to apply changes that will include improvement of the process or product. When a pass through these four steps does not result in the need to improve, the scope to which PDCA is applied may be refined to plan and improve with more detail in the next iteration of the cycle, or attention needs to be placed in a different stage of the process.
Note: Some modern trainers now also refer to the "A" as "Adjust". This helps trainees to understand that the 4th step is more about adjusting/correcting the difference between the current state and the planned state instead of thinking that the "A" is all about action and implementation (which actually happens in the second ("D") stage).
We all know that Plan-Do-Check-Act is the heart of Continuous Improvement, so why do so many business leaders fall down when it comes to Check-Act? And what should they do about it?
Directors and Senior Managers provided that they aren't completely stuck in
fire-fighting mode are usually quite happy
with the Plan part.
They've been trained to set SMART objectives, they appraise their direct reports regularly, and they regularly provide effective feedback. They understand effective Project Management and perhaps apply Hoshin Planning/Policy Deployment. Having worked out the Plan, they often develop their people by delegating the Doing. They know that for people to learn, grow and develop they need to be challenged and supported. So they expect the best but they also provide plenty of support. In other words they coach: they work with their people, they don't do it to them or do it for them.
Sounds great, doesn't it?
But experienced leaders know the reality coaching can be time-consuming, frustrating, and damned hard work! And often there just don't seem to be enough hours in the day.
That's one reason why many managers instead of delegating, coaching and empowering often let people just get on with it. And most operations folk are very good at getting on with it it's what they like, it's what they're good at, and traditionally it's often what they're rewarded for.
The problem is that most people are good at doing what they've always done, in the way that they've always done it. So they produce the same results that they've always produced not always consistently, and not always Right First Time. At an organisational level, that leads to inertia and complacency and that in turn hampers learning which ultimately leads to extinction.
Maybe it's human nature: we all want to improve we just don't want to change. Yet in our hearts we know that if we really want to improve then we have to change what we do or how we do it.
We have to stand back and review what we do, and what we get, and then we need to take action as appropriate. As leaders we have to make sure that reviews are properly conducted, that follow-up's actually happen and that actions are taken. In other words, we need to spend time on Check and Act. So how do we actually do this in practice?
The answer as with most improvement activities is: (1) Start Simple; and (2) Make it a Habit
Simple means diarising a review session, and making sure it takes place.
Make it a Habit means making sure that all leaders always build in a review to all improvement activities.
This is an ideal opportunity to lead by example show colleagues how quick and easy a review can be, and how useful it is. Once people begin to get the review habit, you can move on to formalise it, by including review and action steps in your key processes. To start with, focus on the areas of the business where this will have the biggest impact or where you most need to improve. Maybe it's after completion of each major project, job or contract. Get the team together formally with your supplier(s) and customer(s), if at all possible and ask honestly what went well, what didn't go to plan, and what you can learn from this.
How you handle these sessions goes to the heart of the organisation's culture always remember, when things go wrong: Never blame the people; always blame the process.
As W Edwards Deming taught us many years ago (his 14 observations for management), Continuous Improvement will only happen in an open, honest environment of trust and an absence of fear.
Critically, leaders then need to make sure that the right actions are taken.
If you've achieved the results you wanted, then the new ways of working need to be locked in with Standard Operating Procedures and training, and regularly monitored until the new One Best Way becomes embedded.
If you haven't sufficiently closed the gap between as is and should be then you need to go through the PDCA cycle again.
And remember the Act part isn't done until you've taken full advantage of any read-across opportunities, you've removed those initial quick fixes and you've embedded your new One Best Way until next time!
The message then for senior managers is if you want to keep on improving, complete the cycle!
Implementation is about planning and doing but improving is about checking and taking action. By all means delegate these tasks but ultimately it's your responsibility to ensure that improvements are identified, acted upon, followed up and sustained.
In other words, to borrow a great motto from the corporate governance arena, Trust and check: trust people to do what is required but also build in sufficient checks and balances. If you do then you will be sure to improve, and you'll also be sure that you're improving.
Article by Andrew Nicholson
PDCA was made popular by Dr W. Edwards Deming, who is considered by many to be the father of modern quality control; however, he always referred to it as the "Shewhart cycle". Later in Deming's career, he modified PDCA to "Plan, Do, Study, Act" (PDSA) because he felt that "check" emphasized inspection over analysis.
The concept of PDCA is based on the scientific method, as developed from the work of Francis Bacon (Novum Organum, 1620). The scientific method can be written as "hypothesis""experiment""evaluation" or plan, do and check. Shewhart described manufacture under "control"”under statistical control”as a three-step process of specification, production, and inspection. He also specifically related this to the scientific method of hypothesis, experiment, and evaluation. Shewhart says that the statistician "must help to change the demand [for goods] by showing how to close up the tolerance range and to improve the quality of goods." Clearly, Shewhart intended the analyst to take action based on the conclusions of the evaluation. According to Deming, during his lectures in Japan in the early 1950s, the Japanese participants shortened the steps to the now traditional plan, do, check, act. Deming preferred plan, do, study, act because "study" has connotations in English closer to Shewhart's intent than "check".
A fundamental principle of the scientific method and PDCA is iteration”once a hypothesis is confirmed (or negated), executing the cycle again will extend the knowledge further. Repeating the PDCA cycle can bring us closer to the goal, usually a perfect operation and output.
Another fundamental function of PDCA is the "hygienic" separation of each phase, for if not properly separated measurements of effects due to various simultaneous actions (causes) risk becoming confounded.
PDCA (and other forms of scientific problem solving) is also known as a system for developing critical thinking. At Toyota this is also known as "Building people before building cars." Toyota and other Lean companies propose that an engaged, problem-solving workforce using PDCA is better able to innovate and stay ahead of the competition through rigorous problem solving and the subsequent innovations. This also creates a culture of problem solvers using PDCA and creating a culture of critical thinkers.
In Six Sigma programs, the PDCA cycle is called "define, measure, analyze, improve, control" (DMAIC). The iterative nature of the cycle must be explicitly added to the DMAIC procedure.
Deming continually emphasized iterating towards an improved system, hence PDCA should be repeatedly implemented in spirals of increasing knowledge of the system that converge on the ultimate goal, each cycle closer than the previous. One can envision an open coil spring, with each loop being one cycle of the scientific method - PDCA, and each complete cycle indicating an increase in our knowledge of the system under study. This approach is based on the belief that our knowledge and skills are limited, but improving. Especially at the start of a project, key information may not be known; the PDCA”scientific method”provides feedback to justify our guesses (hypotheses) and increase our knowledge. Rather than enter "analysis paralysis" to get it perfect the first time, it is better to be approximately right than exactly wrong. With the improved knowledge, we may choose to refine or alter the goal (ideal state). Certainly, the PDCA approach can bring us closer to whatever goal we choose.
Rate of change, that is, rate of improvement, is a key competitive factor in today's world. PDCA allows for major "jumps" in performance ("breakthroughs" often desired in a Western approach), as well as Kaizen (frequent small improvements). In the United States a PDCA approach is usually associated with a sizable project involving numerous people's time, and thus managers want to see large "breakthrough" improvements to justify the effort expended. However, the scientific method and PDCA apply to all sorts of projects and improvement activities.