PMBOK
|
Standards
|
Strategy
|
CMmodel
|
CMMiDev
PPTtriad
|
Vmodel |
ITIL
|
DevOps
|
Prince2A
|
DSDM
Scrum |
SAFe
|
PCMM
|
Cobit
|
PDCA
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, you, 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.
However, as projects improve business profitibility, PDCA
(a plan and its cost and its success) are essentially steps into the unknown
( that mind the gap).
If you run Traditional Project Management (TPM) or Agile Project Management
(APM) these essential processes will still apply!
I.e. for TPM its about
managing the Plan and tying this back to the IRON TRIANGLE
and for APM its about delivering value incrementally via the sprint(s).
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.
CMMi 3.1 More Detailed Overview
The first step on your CMMi journey:
Find PP and PMC above.
Then find these core processes on the
PMBOK 6 dashboard!
And just for fun also find them on the Scrum Dashboard
below.
More detail on the Scrum
dashboard is found here.
Deming's Plan, Do, Check, Act (PDCA) cycle is the secret of
Continual Service Improvement to achieve quality
improvements.
This is tied to the concept of (kaizen).
Can you see how the image below ties back to the PMBOK 6 dashboard?
Click the image to get the importance of this!
Bottom line: pull the P-P-T points of the triangle
outward
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
your latest baselined software or as ITIL calls it: The
DML
.
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.
Note above that the first 3 stages occur before sprints start
DevOps is ITIL, just empowered
for speed!
Scrum team sprints (as an example) must be able to release
working
software faster.
DevOps/ITIL/Agile/Scrum etc., Goal: Release Working Software faster!
Notice that for the pilots telemetry is either nominal or not!
If you can't do the above in Scrum you may become Un-Done!
Click the image above for a short video on SAFe.
Click here for Scrum SAFely pdf
Scrum is the engine of SAFe! If your scrums are not releasing valuable working
software
regularly;
then SAFe
(as with the problems [and chaos] associated with traditional
project management)
if badly run at CM level 1
can
be just as unsafe!
Product Owner should officially approve the demo deck at the end of each sprint, produced as an official artifact ready for the auditors.
Scrum method is taken from Rugby. PMWay suggests that American
Football is a far better game to base professional Scrum on.
(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.
Looking at the COBIT dashboard above, can you find BAI01 Manage Programs and Projects?
Thinking back to the Strategy
Wall Slide #3 on the dashboard above can you find
APO02?
What about the ITIL Slide
#8 and finding these on the dashboard above: APO03,
BAI04, BAI06 etc?
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, and especially the EPMS,
(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 organizational 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 diarizing 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 formalize 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 organization'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.