Click here 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.
Click the image directly below for the PMBOK game, in a nutshell.
If you understand the PMBOK you know this game is the same
for both Traditional and Agile Project Management!
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 there.
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.
While (when) BEST PRACTICE is understood,
BEST PRACTICAL (from an agile and lean perspective) can be better!
Answer the questions about People, Process and Technology
from the image above.
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 and gubernator | gubernum) which means "to steer" and also "a or the helmsman."
Essentially to steer could be that of a boat, a horse drawn carriage, a horse or project etc.
Other words derived from the above: governor, navigator, pilot, administrator rudder, helm (and figuratively) a leader, leadership.
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.
Click the image
above (to open the PMP CMMi lego brick)
and reveal the secret to successful strategy (and project) Implementation.
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?
Did 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.
Make careful note of how to empower these bricks (all the bricks in the strategy) at CM Level 2+ per the image below!
I.e. If Strategy Plan Formulation and Implementation is attempted under Capability Maturity Level 2 it will surely be a failure.
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!
Just for fun click here for the games @ CM Level 1.
If interested click OOPS! above for the 15 reasons why projects fail at CM Level 1.
And Traditional Project Management process often is blamed for the chaos!?
Agile methods touted as the solution but operated at CM Level 1 will simply add to, and bring about increased chaos!
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.
On the image above
find Configuration (Configuration Management (CM)), Verification (VER), Validation (VAL) and Bidirectional traceability of requirements (part of REQM process). Now click here. Can you find CM, VER, VAL and REQM on the CMMi Dev table? What are their CM Levels?
Hover over the image below to get the importance
of safety while navigating
the tar pit.
The tar pit is where badly run software engineering projects can get bogged down and die!
Bidirectional Traceability of Requirements is at the heart of (Requirements Management [REQM] & Configuration Management [CM]).
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.
Click the Elephant for DevOps essence!
The release management team has been made partially redundant by machines. It is not absolute because of two reasons.
The person who manages the entire release from end to end is the release manager and is still necessary. However, the release management role went from being a full-time position to a part-time one (statistically speaking), mainly because of the diminished work (thanks to automation). Capable release managers are
The person who could do all this in the past was the product owner (PO), and thus that person is a favorite choice for a part-time release manager. POs are an adequate choice mainly because of their closeness to the business and to the development and operations teams. The person was like a bridge between the two entities and was expected to keep the boat going in the most turbulent conditions.
Thanks Abhinav (page 294)
PS I am reminded by the above of the importance of the Board Executive to produce products in PRINCE2 Agile
Note below how value is produced in agile's Scrum method.
DevOps/ITIL/Agile/Scrum etc., Goal: Release Working Software faster!
(Click the link
directly above to understand why PMWay sees American Football as CM Level 2+ in action)
These "highly professional and frikken cooler than cool cats"
all understand EXACTLY the rules of how to win with their game!
PMWay suggests Just Doing It with the attitude below will not win the Super bowl!
Now click the Shepherd below to see this from a Scrum Master's perspective.
Click here to pin down the problem and obvious solution.
In order to run projects (especially Agile) correctly your people need capabilities and maturity.
Agile postulates the "cohesive empowered professional team,"
with all the necessary skills required for the project existing within the team!
These "adequately empowered workgroups" are normally only found at CM Level 4.
Can you see the truth of this?
Executive support [Executive Action Team (to EAT "the red beads")] is the key to success!
As a test of this (and where the Executive need to remove the red beads) [of which a lack of training in the team on what, when, why and how with regard to project processes to be followed will definitely create 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?
Bottom Line: If you want to do Scrum (or any project method correctly) that starting point is to ensure your people are adequately trained / certified!
It is quite a challenge to install COBIT.
Guess what. Its easier to install that you realize.
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)?
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 Plan Do Study Act (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.