Better is the enemy of good enough
- Attributed to Sergey Gorshkov, Admiral of the Fleet of the Soviet Union, 1910 - 1988
Principles, Practices, and Processes to Increase Probability of Project Success
Andrew Sparks Blog on Oracle's site mentioned a book he just read, The Failure of Risk Management. I have not read this book, but the publisher's jacket description and the Amazon reviewers like the book. What struck me as interesting was a comment from a reviewer about the issues with how risk management is performed (as described by the author)
The appears to be a good description of the failings of risk management. My thought was the author and possibly the reviewers have not read other works on risk management. Works used by those accountable for managing engineering and programmatic risks.
Here's a few we use on the programs we work. These guide the "management of risk" in ways that are the source of failure described in the book.
This site will prompt you to accept a certificate. Go ahead and accept it, it's the US Department of Defense. This is the guidebook for program managers on US DoD programs. Managing Cost, Schedule, and Technical risks is the critical activity for producing a credible Performance Measurement Baseline.
The MIT Systems Engineering Division is a source of guidance for many aspects of systems development. Risk management is a Systems Engineering discipline. This paper is just a sample of the materials available at MIT.
New Directions in Risk: A Success Oriented Approach, Audrey Dorofee and Christopher Alberts, is a good starting point for the framework of how SEI views risk management.
- NASA's Risk Management
- The archive of risk management papers at NASA
- Bayesian Inference for NASA Probabilistic Risk and Reliability Analysis. This is the background material needed to avoid the errors in estimating the risk so commonly found in IT and general environment projects. This is how the "big boys" think about risk.
- Department of Energy Risk Management and the O 413.3-7 Risk Management Guide
- As an example here's guidance for "accelerated path to closure" and the Programmatic Risk processes. I was a participant in the programmatic risk planning for a small section of a Department of Energy Nuclear Weapons plant closure project.
- Aerospace Corporations Risk Management Quick Reference Guide
- "Understanding the Roots of Process Performance Failure," Laura Dwinnel, CrossTalk, April 2004. CrossTalk is a good source of software management information. The items mentioned here need risk mitigation plans.
- Probabilistic Risk Assessment, this is a core manual for anybody working in the technical risk management world.
- Risk Doctor
- The Genesis Project Case Study. This is a program I'm familiar with. I was in a briefing room, when the spacecraft crashed in the Utah desert. The colored chart at the end of the presentation is a unique approach to describing the "risk retirement" processes that must be present in any credible project management process.
This is just the tip of the iceberg regarding risk management.
The reviewed book is probably a good starting point for the uninitiated project manager. But there are valuable resources on the web for managing programmatic and technical risks as well.
Paul Solomon has an article "Agile Earned Value and the Technical Baseline," in this months SoftwareTech, a publication of The Data & Analysis Center for Software. DACS is a US Department of Defense Information Analysis Center (IAC). This site and the journal is a source of software development news and processes application to a variety of domains and contexts. DoD is one of the world's largest consumers of software - COTS and purpose built.
DCAS is the holder of the Gold Practices content. These documents are a good starting point for anyone looking for guidance on processes for developing and managing mission critical software systems.
This article, like all of Paul's articles provides insight into the subtle and sometimes complex world of Earned Value. In this case in the presence of Earned Value.
A core problem in commercial projects is "feature deferral." This means "we'll not be able to give you this feature in the current iteration (if you're using Agile), but will get to it in the next iteration." The question becomes:
How is this deferral reflected in the reporting of Physical Percent Complete?
Paul has a suggestion. Even in the absence of the discipline of Earned Value, this is always an issue. So if you're in the enterprise software development business, subscribe to SoftwareTech and read how software intensive systems are built in the presence of government contracting. Then see if some of the methods to increase the probability of success can be applied to your non-EVM project controls method.
On our software intensive programs (flight avionics), Work Package performance and Rolling Waves are a nice fit for Scrum. Maintaining the PMB (Performance Measurement Baseline) can be done with Planning Packages for out year rolling waves - IF the level of detail needed to define the content of the Planning Packages is carefully considered before placing them on baseline.
This is a constant "tuning" effort and the role of our staff as Program Planning and Controls.
As well there is an article of "Dispelling Myths about Earned Value Management," that must be read by everyone claiming to have a simpler or alternative approach.
Dmitri Ivanenko has some good things to say about status reports in "Are You Ready for your Next Status Report?"
One critical missing piece in this post the raw materials for the status report come from the plan. You plan the work and work the plan, you have the materials for the status report in your plan. This "plan the work and work the plan," is independent of any product development method. Agile has plans. They're called planning sessions. Agile works the plan, it's called an iteration. DoD has a plan, it's called an Integrated Master Plan / Integrated Master Schedule (IMP/IMS). DoD works the plan, with weekly Work Package assignments and Earned Value reporting. So no credible project can not - not plan the work and work the plan.
But the status report still needs to report status of the planned work:
What a status report does is
Report the status of the planned activities. So have a credible plan and report progress against it using Dmitri's guidance.
Wow. I didn't know traditional project management operated in this way! Now of course the number one author in the references list at the bottom of the Wikipedia page is selling a PM 2.0 tool based on this premise.
This list, repeated in other blogs and web sights about PM 1.0 attributes is actually a description of incompetent business management, ignorant personnel management, and malicious use of position. You know businesses that are going out of business.
Pat goes on in his post about the reasonableness of the PM 2.0 content of the Wikipedia article. Pat has restated many of the same points I've made and Quant.M.Leap made. My sense is the authors of the PM 2.0 approach defined in the Wikipedia track have somehow concluded all the world are fools and only they have the answer. Yes, ERP projects fail in many ways at an alarming rate in the press.
Of course these PM 2.0 advocates probably haven't actually managed ERP projects or seen successful ones to know the difference between the attributes of success and failure. Nor is it likely they can know the difference between the Boston Big Dig failure and the successful I-25 corridor here in Denver.
It's actually irrelevant in the end
Thank the stars above, no pubic institution or credible private enterprise is going to buy their message "as is" for a simple reason - governance.
Business and project governance. Governance of course does not assure project success. But governance assures that the nonsensical descriptions provided in the Wikipedia Traditional Project Management attributes do not exist in principle. Governance makes every attempt to also assure they do not exist in practice.
So Here's My Simple Minded Conclusion
PM 2.0 will go the way of the first round of "wanna be" extreme programming advocates. Note I did not use eXterme Programming, because Ron had and still has one of the viable alternatives to the "design, code, test" approach of the past - along with Scrum, Crystal, and DSDM. What the extreme programming advocates - those who read the book, but never did the work - wanted was to eliminate all the prep work needed to get in a position where eXterme Programming could work.
The great thing about approach taken my the misinformed, ill trained and inexperienced extreme advocates was they never got hired by any outside firms to practice their voodoo. Same will happen here.
As pat suggests
Beware zealots bearing gifts
There are many discussions floating around about how and why to simplify the application of Earned Value. Some are credible some are not.
There are several places to look for the discussion of Earned Value. LinkedIn has a forum for EV.
Earned Value as a principle is applicable to any project. The 32 criteria of ANSI-748B need not be applied in their entirety outside a federal government program. But there are a minimal set of criteria needed for the success of EV. Here's a previous suggestion on those minimum criteria.
There are subtleties in reducing the EV processes. So when you "simplify" you must also maintain the discipline needed to produce Value from Earned Value:
Change to task sequencing should be a work package issue, not an EV baseline issue. Many fail to realize EV is a "time phased" measurement. If you don't start the work on the time you said you were, then you "off baseline." Move that up to the next level. Keep the natural variances inside the Work Package. Don't let them leak.Buy Paul's book, read it, mark it up. Read all the materials on Paul's site. Use EV on software projects. Increase your probability of success.
Shim Marom could not have said it better regarding PM 2.0.
What strikes me about the PM 2.0 discussion is it is really a great example of "argument by logical fallacy."
But I digress. The logical fallacy approach is also known as "appeal to belief." Which goes like this...
Most people believe X is true. So X must be true
These beliefs in the project or technical world are typically around some current issue...
You see the trend here?
So Shim states the details of the logical fallacy in his post, but I'll repeat my summary
PM 2.0 is all about Web 2.0 tools. It's the tools that make PM 2.0 like Web 2.0. Ignoring completely the fact that the management of projects has little or nothing to do with tools in the absence of a credible plan, credible requirements to be implemented by that credible plan, and credible business needs or credible mission capabilities from which to derive those credible requirements.
See the trend here. With a PM 2.0 tool, crappy capabilities, crappy requirements, and a completely crapping plan produce a project that is crap.
Tools in the hands of a foolish project manager, simply make the project manager behave like the fool he is - but with a better tool.
Here's another attempt to put some structure into what some authors are calling PM 2.0
I'll start with a simple list of what activities take place during a project. PMI calls these Knowledge Areas. This means knowledge of "what" to do is needed to increase the probability of success of the project.I'm not the biggest fan of PMI, but I am a member and the Knowledge Areas are a good starting point for shared vocabulary.
I've learned that without a shared vocabulary the conversation is hard to have. So here's PMI's simple vocabulary about what happens during a project. These are not product development verbs, they are project management verbs.
By activities I mean, what does the project manager and the technical teams do while working the project that is independent of the engineering processes - writing code, welding metal, pouring concrete.
Several colleagues and I have tried to make a run at this. The topic of "what is project management" outside of the PMI paradigm has been talked about before. Here's my rough cut for the traditional processes.
PM 2.0? What is PM 2.0? I'm not sure. Possibly the mechanisms used to manage the project. Tools based on Web 2.0 might be the "operational" definition of PM 2.0
But what are the core processes these WEB 2.0 tools implement? Remember when the term PM 2.0 is used, look for the "tools sale."
Here's my suggestion when the question is ...
What are the core processes needed to successfully deliver a project - on-time, on-budget, on-specification?
Even if all three are "emerging" in a rational manner.
Irrational emergence has little chance of succeeding, no matter the current buzz word tool or process
These are the processes of the Deliverables Based Planningsm that our firm uses in a variety of project domains and contexts within these domains.
These processes are applicable to a wide variety of project types. I'd conjecture, we have not found a project in any of our business domains where each process area and the detailed processes, with their outcomes cannot be put to direct use.
These are copyrighted materials of Lewis&Fowler, Denver Colorado 2009. So if you use any ideas here, please give us credit. Thanks in advance.
Rick Reilly is a Boulder son, who writes for Sports Illustrated. Here's an email/post going around attributed to him. I've re-posted for a simple reason. We work in and around aircraft and spacecraft is this class. There are simply no words to describe the experience of these machines. Rick's words start to convey some of that experience.
Someday you may be invited to fly in the back-seat of one of your country's most powerful fighter jets. Many of you already have . John Elway, John Stockton, Tiger Woods to name a few. If you get this opportunity, let me urge you, with the greatest sincerity ... >
Move to Guam
Change your name.
Fake your own death!
Whatever you do .
Do Not Go!!! I know.
The U.S. Navy invited me to try it. I was thrilled. I was pumped. I was toast! I should've known when they told me my pilot would be Chip (Biff) King of Fighter Squadron 213 at Naval Air Station Oceana in Virginia Beach.
Whatever you're thinking a Top Gun named Chip (Biff) King looks like, triple it. He's about six-foot, tan, ice-blue eyes, wavy surfer hair, finger-crippling handshake -- the kind of man who wrestles dyspeptic alligators in his leisure time. If you see this man, run the other way. Fast.
Biff King was born to fly. His father, Jack King, was for years the voice of NASA missions. ("T-minus 15 seconds and counting ..." Remember?) Chip would charge neighborhood kids a quarter each to hear his dad. Jack would wake up from naps surrounded by nine-year-olds waiting for him to say, "We have a liftoff."
Biff was to fly me in an F-14D Tomcat, a ridiculously powerful $60 million weapon with nearly as much thrust as weight, not unlike Colin Montgomerie. I was worried about getting airsick, so the night before the flight I asked Biff if there was something I should eat the next morning.
"Bananas," he said.
"For the potassium?" I asked.
"No," Biff said, "because they taste about the same coming up as they do going down."
The next morning, out on the tarmac, I had on my flight suit with my name sewn over the left breast. (No call sign -- like Crash or Sticky or Leadfoot, but still, very cool.) I carried my helmet in the crook of my arm, as Biff had instructed. If ever in my life I had a chance to nail Nicole Kidman, this was it.
A fighter pilot named Psycho gave me a safety briefing and then fastened me into my ejection seat, which, when employed, would "egress" me out of the plane at such a velocity that I would be immediately knocked unconscious.
Just as I was thinking about aborting the flight, the canopy closed over me, and Biff gave the ground crew a thumbs-up. In minutes we were firing nose up at 600 mph. We leveled out and then canopy-rolled over another F-14.
Those 20 minutes were the rush of my life. Unfortunately, the ride lasted 80. It was like being on the roller coaster at Six Flags Over Hell. Only without rails. We did barrel rolls, snap rolls, loops, yanks and banks. We dived, rose and dived again, sometimes with a vertical velocity of 10,000 feet per minute. We chased another F-14, and it chased us.
We broke the speed of sound. Sea was sky and sky was sea. Flying at 200 feet we did 90-degree turns at 550 mph, creating a G force of 6.5, which is to say I felt as if 6.5 times my body weight was smashing against me, thereby approximating life as Mrs. Colin Montgomerie.
And I egressed the bananas.
And I egressed the pizza from the night before.
And the lunch before that.
I egressed a box of Milk Duds from the sixth grade.
I made Linda Blair look polite. Because of the G's, I was egressing stuff that I never thought would be egressed.
I went through not one airsick bag, but two.
Biff said I passed out. Twice. I was coated in sweat. At one point, as we were coming in upside down in a banked curve on a mock bombing target and the G's were flattening me like a tortilla and I was in and out of consciousness, I realized I was the first person in history to throw down.
I used to know 'cool'. Cool was Elway throwing a touchdown pass, or Norman making a five-iron bite. But now I really know 'cool'. Cool is guys like Biff, men with cast-iron stomachs and Freon nerves. I wouldn't go up there again for Derek Jeter's black book, but I'm glad Biff does every day, and for less a year than a rookie reliever makes in a home stand.
A week later, when the spins finally stopped, Biff called. He said he and the fighters had the perfect call sign for me and said he'd send it on a patch for my flight suit.
“What is it?” I asked.
People, Process, and Technology is a common management consultant set of "pitches."
I'm here to say it's in that order. And the order steps done in logarithmic. Meaning Processes is e (2.71821) less than People. And Technology is 2.71821 less than Process.
This put process 7.29 less than the people.
Want to find the way to increase the probability of a project's success - It's not the tools it's the people.
For starters: Project Management 2.0 is a term without a context. 2.0 is borrowed from Web 2.0, SOA 2.0, GIG 2.0.
Reading the initial descriptions of PM 2.0 reminds me of watching the infomercials shown on late night cable. The pitch is unabashedly biased, making remarkable claims and with conclusions that are unlikely to hold up under scrutiny.
Project Management in the Context of Projects
All project management processes have a context and a domain. They don't age. They don't wear out. They don't get replaced.They are immutable.
The immutable core processes of project management are, irregardless of what anyone wants us to believe, the management of projects consists of answering these questions:
But the real starting question, independent of any project management method is:
What does done look like?
No matter what you want to call the project management method. Agile, Traditional, 2.0 it must continuous answer this question and all the associated questions that come with it?
The PMBOK Questions
Most agile approaches start by trying to counter the Project Management Institutes Guide to the Project Management Body of Knowledge (PMBOK). PMBOK has 9 Knowledge Areas that are appliacble of every project:
So if there is such a thing as Project Management 2.0, we'll need to discover how PM 2.0 covers these knowledge areas. Now you might say, PM 2.0 is not the same as PM 1.0 and the PMI knowledge areas. OK, that's simple. We're done. But if PM 2.0 wants to continue being called "project management," it needs to some how address these areas and several other "models" of project management.
PMBOK also has 5 Process Groups. These are not phases, but these processes can be found in any phase description of a project management method:
PM 2.0 and PM 1.0
If PM 2.0 is going to have any traction, it'll need to address how its processes are an improvement over something in the past. Start with PMBOK, start with Prince 2, start with anything and show how those processes - when implemented correctly, with competent management, in the proper domain and context - are lacking in beneficial outcomes.
There are certainty improvements to be made. Agile software development has shown that. It's time for PM 2.0 to show in tangible evidence how it's proposed processes and the method based on those processes can improve the probability of success for a project.
Frank Patrick commented on my quick post on what the OP called Top Down compared with Bottom Up project management. I had not meant to be so blunt as Frank made me out to be. But on second thought he's right.
Starting the discussion of PM 2.0 in the way the OP started, is a non starter. There is no actionable outcome. Just buzz words, poor comparisons, and no path to increasing the probability of success.
First, the comparison between Top Down and Bottom Up is not the comparison between tradition and agile. Top and Bottom are topological terms not verbs describing the functions of project management.
Second, is the use of the words in the Top Down. Inflexibility, Bureaucracy, Overall Control, Imposed Processes, and my favorite No Moral Motivation. I won't use Frank term. My term is Nonsense.
Nonsense, first in there is no context, no examples, not domain of applicability for that presentation.
Nonsense, in the comparison of the agile terms flexibility, agility, collaboration, and high motivation.
Who says formal CMMI ML5, full NASA verification and validation software development projects have no moral motivation. Wanna see grown men cry like babies. Attend a launch of a Mars Oribtor. Be in the control room when that orbitor is captured at Mars. Or better yet be in the control room when a sample return vehicle crashes in the Utah desert after 3 years flying around the sun. No moral motivation my ass.
If the role of project management is ever to improve, we must do the following:
To improve the profession and processes of project management we must ask and answer the following:
That's the basis of Project Management 2.0
Let's get started and stop the nonsense of confusing buzz words with actionable outcomes that beneficially impact the success of the project.
Bas de Baar posted a re-post of a concept about Project Management 2.0.
Here's the picture that started my post.
If we look at the three boxes individually, here's some observations:
Project Management 2.0
So What's the Rub Here?When all three boxes are put together, there is a major disconnect.
In the end this approach is a bad example of what Project Management 2.0 should be. A another missed opportunity.
Because Project Management 2.0 needs to be pushed outside of the domains that currently use the Top Down and Bottom Up approach - the discussion needs to be how to combine the best of both worlds, not whine about how bad project management was used, then replace that with platitudes of the non-actionable buzz words.
If Project Management 2.0 is going to succeed, it must provide unassailable beneficial outcomes, in units of measure meaningful to the buyer. This approach to improving the process of managing projects is DOA.
One colleague did give me a quick overview. Lot's a updates to the user interface. But I didn't hear about any accounting calendars and it looks like the ability to change anything, any time you want will be an underwhelming hit for us here in the DCMA driven world of defense program controls
The notion of multitasking as a "bad idea" is common sense. But little actual evidence. This is a common affliction. Here's a paper with field data. Impact of Multitasking and Merge Bias on Procurement of Complex Equipment
There are three kinds of people, those who can count and those who can't
This is posted on a sandwich board outside a coffee shop in Phoenix during the Microsoft Project 2009 Conference. It was attributed to Einstein. But I think it was really said by an presented at the Fields Medal Awards. I remember reading it in a book about the Fields Medal. But like most things more than a few years old, it has since left my brain.
The US Department of Energy has $1.2B allocated for clean energy initiatives. Our firm is working a program that captures carbon from coal fired power plants and uses it to feed an algae farm that in turn makes a refineable "oil" (lipid) that can be burned in vehicles or turbines.
Along the way, we are building a Project Management Plan. The DOE has some useful guidelines for what makes a credible project plan.