Herding Cats

Quote of the Day

Better is the enemy of good enough

- Attributed to Sergey Gorshkov, Admiral of the Fleet of the Soviet Union, 1910 - 1988

Revisiting Risk Management

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)

• Subjective scoring methods
• Independent events that create dependencies
• The famous "black swans"
• Empirical risk management

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.

• The DoD 2006 Risk Management Guidebook, 6th Edition (Version 4.0) 4 August 2006. 

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.

• "An Approach to Technical Risk Management," Richardo Valeridi and Ron Kohl, MIT Systems Engineering Division.

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.

• The Software Engineering Institute has a Risk Management section.

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.

• Mitre Corporation's Systems Engineering Program Office is a good resource for risk and system architecture. Mitre has a Risk Management Toolkit, that can be directly applied to any program. It has an Excel risk management model and a handbook.

• Edmund Conrow's book Effective Risk Management: Some Keys to Success, 2nd Edition, AIAA Press is the corner stone of our risk management approach. If you're going to buy one risk management book, but this one. It's expensive, but it's got everything you'll ever need to be a credible risk manager. This is not a survey book, or a book written for those entering the field. This is a heavy duty technical textbook.

• Visit the government and commercial sites for some more background:
  

• 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.
• RiskWorld
• 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.

97 Things Every Project Manager Should Know

Josh Nankvel  of PM Student posted a link to a Web Cast

97 Things Every Project Manager Should Know

Agile Earned Value

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.

Quote of the Day

As long as the arrows are landing on my back, I know I'm still ahead of the pack

— Program Manager and Principal Investigator, large Algae CO₂ sequestration project

A Thought on Status Reports

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:

• Perform no work that is not in the plan (in some way). Then you can report what was accomplished from what was planned to be accomplished. If your doing work that's not in the plan - why? Who asked for it? Who's paying for it?
• If you address risks in the status report that are not in the risk registry, then put them there and report on them.
• If you spent more money or delivered late, you should report against the planned spend and deliverables.

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.

PM 2.0 - Another View

Pat Weaver provides more insight on the issues of Project Management 2. I had not seen Wikipedia article he references. In it Traditional Project Manage is described as:

• Centralization of control
• Top Down Planning
• Authoritarian environment
• Implied structure
• Limited/Restricted access to the plan
• Local access to information
• Limited communications within the team
• Separate projects
• Overly complex tools
• Rigidity of tools

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

Simplifying Earned Value?

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.

One of the best is Paul Solomon's book and site. The current post describes an assessment of several government agencies.

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:

• Maintaining the integrity of the baseline is critical - "rubber banding" the baseline is common practice in troubled programs or projects. When you overrun a work package, you've over run the work package. You're "off baseline." Report it and move one. Get a "get to green plan" for the remaining work.
• Maintaining the funding integrity is critical for government projects. This should also be critical for commercial project. This is not always the case. Without integrity of the funding sources future forecasting based on past decision is difficult.
• Performance management at the Work Package level for BCWS is as low as you want to go on a non-trivial project. Lower - at the task level - means change requests to the baseline occur all the time. The notion proffered by a few that managing at the task level for 5,000 tasks gives the program manager "control" is complete nonsense. It creates a nightmare for change control and traceability. Once change starts, the integrity of the baseline is lost and you're ability to forecast future performance with it.

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.

A Fool With a Tool, Is Still a Fool

I'm working a large ($100M) US Department of Energy Algae CO₂ reuse project through early next year and haven't had time this week to post another round of the PM 2.0 thread.

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...

• Having a PMP is a waste of time and adds no improvement to project success
• PMI is an evil empire, my empire (although small at the moment) is better
• People are not operators in Hilbert spaces (my personal favorite argument taking place on the pages of a physics journal I subscribe to)
• People have free will (I'll just this in for effect)
• People do or do not believe in Global Warming
• Full 748B Earned Value is bunk and my simpler algorithm is the replacement of choice for everyone on the planet - no matter the domain
• I'm a project guru and my numerous degrees and certifications prove it, just ask me

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.

Quote of the Day

What If is a fearful approach to life

If Then is the participants approach to life

Another Run At PM 2.0 Clarification

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.

With this stating point - it's a starting point, but I can't think of a simpler one for this post - what are the activities performed which managing a project in the Traditional, Agile, and PM 2.0 paradigms.

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 1.0, PM 2.0, How About Just Project Management?

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 Planning^sm 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.

Local Boy Rides the F-14

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.

"Two Bags."

People, Processes, and Technology

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.

Calling BS on PM 2.0

The notion of Project Management 2.0 has trigger several responses. I'm guided by Scott Berkun's Calling Bullshit on Social Media post.

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:

• What are we building?
• What budget to we have to build it?
• How much will it cost to build it?
• When is it needed?
• What resources do we have to build it?
• Who are the participants along the way?
• What are the impediments to our success?

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:

1. Integration
2. Scope
3. Time
4. Cost
5. Quality
6. Human Resources
7. Communications
8. Risk
9. Procurement

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:

1. Initiating
2. Planning
3. Executing
4. Monitoring and Controlling
5. Closing

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.

Project Management 2.0 - How Can It Be Described

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:

1. Stop labeling the processes as agile, traditional, waterfall, or what ever, without also stating tangible, measurable, and verifiable beneficial outcomes for each of the labels. Agilest who do so have unlikely ever worked a project where formal methods are successful. So it'd be hard for them to know what that what they are complaining about is actually bad management.
2. Stop confusing bad management with bad processes. This is the most often encountered mistake with agilest who are not actually project managers in the domain applicable for more formal methods. Instead they start with software development paradigm and extend their experiences to the role of the project management.
3. Understand that developing software with Scrum is not managing the project in which the Scrum developed software is a participant. No matter how hard the agilest want us to believe this, software is one part of the solution to the problem. Yes, many of the methods found in Scrum are applicable to managing the overall project. But it does not replace many other methods needed for success.
4. Start defining effective project management processes in units of measure meaningful to the participants. "If you do this, you will achieve a 10% reduction inf rework of technical specifications." Things like that. Remember Jerry McGuire - "show me the money."
5. Demonstrate these process are effective in specific, named, domains, and contexts. No more blather of "my buzz words are better than your buzz words."

To improve the profession and processes of project management we must ask and answer the following:

1. What processes - no matter what they are - increase the probability of success?
2. What are the mechanisms of this improvement, so we can understand how they scale, where their inherent weaknesses are, and where the latent risks reside?
3. What measures can be found that show these processes are effective in a statistically sound manner. With real, validated data, using credible sampling and measurement techniques?
4. And most importantly, how the lessons of the past can be used to improve the probability of a projects success in the absence of the traditional agilest approach - "old ways are bad, new ways are good." Alistair Cockburn's works are a good place to start. Domain and Context sensitive. Outcome Based. Theoretically sounds and buzz word free.

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.

Top Down / Bottom Up = Project Management 2.0? Not with this approach

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:

Top Down

• The description of this style of manage.There may be firms that operate projects in this way, but this is complete nonsense. No credible project management or business management method works this way. If it does, the firm is likely headed for the dust bin, now or soon.

Bottom Up

• These words are of course "god and motherhood" and not actionable in any way.
• Agility is a core process attribute of Product Development Kaizen used at one of the world largest defense contractors.
• Team driven processes are the core attribute of NASA Integrated Product Team (IPT) for the current manned space program. Same for large (multiple billions) of US Department of Energy construction and nuclear weapons programs.

Project Management 2.0

• Control and collaboration is the core process of the Integrated Master Plan / Integrated Master Schedule (IMP/IMS) mandated by US Department of Defense.
• Clarity of project goals is the core attribute of IMP/IMS and Performance Based Earned Value.
• Coordination and collective intelligence is established in the integrated Program Performance Management system - usually ranging from desk top tools to enterprise ERP and the DCMA certified work processes around them

So What's the Rub Here?

When all three boxes are put together, there is a major disconnect.

• First there are no actionable statements in the boxes. Nor are there any units of measure. By this I mean, how flexible is flexible? How rigorous is rigorous? When we same "agile" is that a noun or a verb? When we say control and collaboration, what are the units of measure.
• Some of these words are "content free." All projects,
• This approach is a non-starter in any non-trivial business environment. Any product or project leader would consider these words "whining" - no actionable outcomes on the Bottom Up side.
• The "agilest" message here is not only naive it is arrogant - based likely on poor past experience, not based on observing or even participating in credible project management environments.

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.

Friday Roundup

• "Charlie, I'm convinced that half of the cost of a program is socially determined." John Mather,  NASA's Nobel Laureate speaking to Charles J. Pellerin author of How NASA Builds Teams.
• I spoke at the Microsoft Project 2009 Conference in Phoenix this week on my favorite topic - Increasing the Probability of Project Success. Microsoft announced Project 2010. I didn't see any of the demo our hear any of the speakers because I was working in town setting up a Program Management Office for the management of government grants and ARRA funds flow down.

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

Quote of the Day

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.

Project Management Principles from the Department of Energy

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.

1. Mission need must be defined and approved by the appropriate management official
2. A range of alternatives to meet the mission need must be considered, developed and evaluated
3. Project objectives must be defined upfront and used to judge project success
4. Project performance risks (technical, financial, and otherwise) must be identified and mitigated in an implementation strategy
5. Projects must be managed by qualified individuals
6. Scope, schedule and budget must be established for each project and serve as the basis for project management
7. Projects must be managed and reported against the established scope, schedule and budget

Any project, no matter the domain or context, would be well served when using these principles as a starting point.