Herding Cats

Quote of the Day

"The first objective of every captain in His Majesty's navy on his appointment to a ship must be to have those officers with him whose disposition he is acquainted with, and upon whose abilities and attention to to his character, comfort, and happiness are, in great measure dependent."

- A Captain in the Royal Navy, Observations and Instructions (1804) referenced in The Pursuit of Victory: The Life and Achievements of Horatio Nelson, Roger Knight, 2005

Any credible project manager could take this advice to hand during the chartering session and apply it during the life of the project.

Project success starts and ends with the project staff. Processes enable cohesion be maintained. Tools reduce the labor load.

Quote of the Day

If I had to sum up in a word what makes a good manager, I’d say decisiveness. You can use the fanciest computers to gather the numbers, but in the end you have to set a timetable and act.

—Lido Anthony (Lee) Iacocca

NASA Blogs

NASA now has a collection of its Blogs

What is Project Management?

I'm preparing for my annual seminar at Carnegie Mellon University. This year my topic is "The 5 Immutable Principles of Project Management."

I'll post the briefing once it's approved. But here's a sample to set the tone.

We get confused when we interchange project management with product development. I was confused at one time as well. Bill Duncan - of PMBOK(r) fame - set me straight many years ago.

Here's a sample:

Project

A project is a temporary endeavor undertaken to create a unique produce, service, or result. The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.

Management

Judicious use of means to accomplish an end. The act, art, or manner of managing, or handling, controlling, or directing. Organization and coordination of the activities of an enterprise in accordance with certain policies and in achievement of clearly defined objectives.

Project + Management

You can assemble the sentence.

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project management is accomplished through the appropriate application and integration of project management processes.

So if someone says they're doing "project management" then ask if they're doing something related to the words above? Start at the top of the concept:

Application and integration of project management processes

What Are the Tools Needed to Manage Projects?

Here's a short list of the project management tools we use on programs. When we talk about improving the project management processes and tools that support them, we need to address these as a minimum:

• Scheduling and Planning Systems
• Job Card & Detail Milestone Applications
• Earned Value Engines
• Cost Estimating Tools
• Quantitative and Qualitative Risk Applications
• ERP Systems
• Financial & Timesheet Applications
• Document Management & Requirements
• Analytical and Reporting Tools 

There are other tools of course, but these are the core tools that support the core processes in our program management domain and other enterprise class and large construction programs.

Now if the advocates of PM 2.0 have any approach that increases the Probability of Program Success (PoPS) want to address the problem, let's see if integrating these systems can be a common goal?

Deconstructing the PM 2.0 Description

In an interview on PM411, there is a description of the attributes of PM 2.0. Setting aside the product promotion, I feel compelled to review the notions on which PM 2.0 paradigm is built.

As a practicing program manager in a variety of industries, I'd like to take each sentence and address the misinformation being used as the basis of the "next new thing."

Traditional project management is focused on the project manager being the center of the team’s communication hub. It places the manager in the center of the project work, as they need to collect all the information from team members, process it, and then communicate to various project stakeholders, including upper management.

Let's start with what PMBOK^® 4th edition has to say.

• Chapter 10 - Project Communications Management makes it clear that "project communications" evolves everyone on the project.
• Starting with the identification of the stakeholders, the primary goal of external communications is to mange the expectation of these stakeholder.
• A critical issue in this chapter is the distribution of information inside and outside the project.  §10.3 describes how to assess the needs of the project for starting with the "sender-receiver" model.

No where in Chapter 10 does it say the Project Manager solely performs this role. This is the first example of starting with BAD project management practice and considering that reason for a new approach.

Project planning can especially be hard and time consuming since all the project information is concentrated only around a single person — the project manager.

This of course is complete nonsense. Any credible project management method involves all responsible parties in the planning process. This ranges from the full team in a Scrum project to the Control Account Managers and their Technical Leads in a large defense programs.

Where this notion that planning ... is concentrated only around a single person - the project manager, may come from missing information on how GOOD project management practices are applied. No doubt the author may have experienced BAD project management, but a simple read of PMBOK^® would provide the needed guidance to see the statement is without merit.

There are alternative "planning" processes, PRINCE2 for example. IMP/IMS is one we use in defense.All credible planning processes involve "everyone impacted" by the plan. To do otherwise would be blatant ignorance of the role of "project management."

This contributes significantly to what a project manager spends 90% of their time doing – communicating.

This of course is one of the unsubstituted claims so common in the "next new thing" approach. Because if you're trying sell a new concept, one of the first impulses is to claim the competition is flawed.

New-generation project management tools make it possible to create a collaborative team space, and everyone involved in the project is able to contribute to the project work in this space. Project planning and communication is distributed around the whole team, and each team member has the full information on the project. Project progress is visible to everyone on the team.

The project manager’s role is transformed from the traditional taskmaster to become a project visionary as they focus more on the right direction for the project development. The new-generation tools take away part of the typical traditional burden of project management and allows the project manager to focus more on leading the project team.

I guess the web based collaboration tools, ones that have been in place for a decade, are insufficient to meet the PM 2.0 paradigm.

Of course this is one of those unsubstituted claims again. My sense is it comes from not having been a project manager before 2001 when all those things described above were in place in many forms - not Web 2.0 forms of course. Many were implemented in crude ways - sticky notes on the wall, or the Big Visible Chart hanging in the hall of Building O6 at TRW. Yes it was printed out overnight - every night - and not interactive through a workstation. But the first Sun Workstations were used to "display" this information. Bill Joy, BTW, helped us debug the memory manager for our embedded version of Real Time BSD Unix.

This may be the basis of PM 2.0. All the GOOD PM processes that have been around for ever re-hosted on Web 2.0 tools and re-branded as PM 2.0. But of course that's not what the author is saying.

As a short story of the each team member has full information on the project or the supposed missing information in PM 1.0. When we came in through security process every morning, if you saw your name in the Big Visible Chart in RED, then you knew shortly the Control Account Manager would be dropping by.

With Project Management 2.0, the project management of a project is built around the work, rather than the work being forced to conform to a particular project management system.

This of course is more nonsense. The only reason for a project is to produce an outcome. This outcome comes from work being forced to conform.

So now it's clear. The project participants are predisposed to "follow the particular project management system." This is the very basis of projects and project management. Whether this "project management system," is XP, or Scrum, or Crystal, or all the way up to DoD 5000.02 IMP/IMS the success of a project depends on conforming to a particular project management system.

Now, New-generation technologies have brought collective intelligence into the project management process. and open the way to another successful practice, emergent structures, where the one-to-many approach of conventional Work Breakdown Structures (WBS) is replaced by a many-to-many approach of work package delivery.

This is a fundamental violation of one of the immutable principles of project management - describe what "done" looks like in units meaningful to both customers and suppliers. The many-to-many relationships violate the transitive closure problems in databases. Multiple - and likely inconsistent - descriptions of the same thing.

So the take away from the PM 2.0 description seems to be:

Use PM 2.0 to do your own thing, 'cause we sure don't want to be hemmed in by following a particular project management process do we?

So How Can PM 2.0 Actually Be Put To Work?

• Use tools to remove impediments to visibility by homogenizing the information. This means standard units of measure, predefined assessments of "done." Things like that. This of course is difficult in any enterprise because of missing Enterprise Architecture to gain access to the needed information.
• Use tools to build a seamless traceability up and down the "fidelity" chain. From Capabilities descriptions in the business case or Concept of Operations down to working product test scripts. This is a real challenge since these tools started as standalone domains.
• Significantly reduce the cost footprint on the desktop. With multiple applications on the desktop the cost of information access is prohibitive, forcing a small number of users being allowed to this information.
• Provide "work flows" that can adapt to the changing needs of the project. This means tailoring within a PM method at the project level.

This last piece from PM 1.0 is the real burden on the project. The suggested burdens above are simply BAD PM. Provide low cost access and this narrow access channel to project information is removed. And you get PM 2.0.

So do this and stop all the red herring blather, which is simply BAD PM'ing from day one. Read PMBOK or any BOK and learn how to do PM right.

Quote of the Day

No form of transportation ever really dies out. Every new form is an addition to, and not a substitution for, an old form of transportation. —Air Marshal Viscount Hugh M. Trenchard, RAF

Technical and Scientific Resources

There are many resources on the web for technical and scientific papers. Some are good some are politically motivated, some are just lame.

Here's my trusted list:

• Scirus - is a source of scientific information. But it also has many engineering resources and many project management topics as well
• Directory of Open Access Journals
• PEW Global Climate Center -with as much noise around this topic flying across the web, a trusted source of information is needed. Start here.
• Scribd - is a repository of articles and sometimes books on a variety of topics

The Toyota Way on PM Technology

It's a cold but sunny day here in northern Colorado. I've been giving some thought to the issues of PM 2.0 and the method of "push" of technology onto projects. Not as a replacement for PM 1.0 as I'm now hearing the proponents say. But as an alternative approach.

I'm looking at the Toyota Way on the bookshelf and the 14 principles developed at Toyota. One stands out in this context.

Use only reliable, thoroughly tested technology that serves your people and processes.

Now the key here is both the people and the processes. The people are complex adaptive systems and can pretty much make use of anything that isn't completely lame. And sometimes even lame things can be put to work.

But it's the process that is critical in the Toyota process. Not more critical than the people, but this purpose of this discussion it is more important. The leading voices of PM2.0 have for the most part skipped over the processes of project management. And replaced those processes with self-centered process. Personal communication, personal fulfillment, personal interest. As we mention to our young college students "It's not about you."

In fact it's about the project and the processes that enable the project to proceed on its planned course.

So next time you hear a statement about PM 2.0 or any technology for that matter. Ask yourself...

How does this technology serve the project's processes and the people that use that process? But it's the process first.

The Ideal PM Tool Set

Over on PMHut, there is a semi-commercial post by Andrew Filev titled What Would an Ideal Project Management Tool Look Like? What's interesting at first is Andrew doesn't mention anything about "managing projects." 

Here's what I want a tool set to do:

• Provide easy development of the Master Plan and Master Schedule. The Mind Jet tools does some of the heavy lifting during the brain storming sessions. But MindJet broke the MSFT Project interface that was so wonderful in X5. But still MM is our standard "data entry" tool. It defines the Integrated Master Plan, down to the Work Package level. Then we switch to MSFT Project for the next step.
• Have a repository for plans and schedules that integrates documents, spread sheets, and other sources. We're always surfing are the web, on "official" sites for information, going back and forth with the customer documents, making changes and revising everything. The solution of course is an Enterprise Content Management system. But those expensive, requires loads of effort to stand up, and run on a continuing basis. Sure MOSS and document management system can do this, but not in the way PMs work.
• Change management is a BIG deal in PM. I'd like a "real" change management system for the project content. There are a few tools out there. Some are expensive. I mean $2,500 a seat. Some a affordable. It's getting better, but not there yet.
• Integration of cost and schedule in the way a real cost management system works. There are cobbled up systems, but they require too much effort. The current MSFT Project (07) is still lame when is comes to cost management. It's a scheduling system. An OK one. Affordable at least compared to the competition. But even the 2007 version does not have an accounting calendar!!!!

OK, enough for now. My real list is dozens of pages long.

But let me make one point as a practicing Program and Project manager as well as a Program Planning and Controls lead.

Email is a bad idea when makes changes to the project baseline. Just an all around bad idea.

Every credible project management methodology requires a change control system to the baseline. Knowing who changed what, what the impact is to the work right of today, what the cost impact is on the allocated cost baseline. Thing like that are not allowed to be performed in the absence of approvals. Period.

In fact this may be the difference between the "professional amateur" and the "professional." That will annoy people I know. But "credible" change control is an immutable program management process.

Here's a real example.

7 work streams with interactions between hardware, software, firmware, simulations, human factors. All working in parallel as much as possible. Come in on Monday and discover a predecessor has been changed - moved to the right. Completely screws up your nice plan for completing on or before the planned date.

Who made the change. Why did the change get made. How can you undo the change. We've taken actuals against that baseline. Now we're "off baseline" so our performance is screwed up.

We're screwed. 

DO NOT UPDATE THE SCHEDULE WITH EMAIL FOR ANYTHING OTHER THAN A TRIVIAL PROJECT.

I say this from 26 years managing projects. It's true in every domain I've ever worked

The ideal project management system should bring HUMANS into the communication loop, not email. Just like the Agile Manifesto tells us to do. Even if the authors of the Manifesto would not dare come close to our $500M programs.

The principles are still true:

Individuals and interactions over processes and tools

A Sweet Spot for PM 2.0?

In some organizations project management is seen as an unnecessary overhead or a burden on the business. Looking at the best practices of organizations where project management is the raison d’être can guide our search for best practices in your domain.

Here’s one example of a successful project management approach. There are many others that might be appropriate for IT projects

From “Seven Key Practices of Program and Project Success – A Best Practices Survey,” Vincent J. Bilardo, NASA Glenn Research Center, NASA Project Management Challenge Conference, Galveston Texas, March 21–22, 2006, these practices are:

1. Establish a clear and compelling vision
2. Secure sustained support “from the top”
3. Exercise strong leadership and management
4. Facilitate wide open communication
5. Develop a strong organization
6. Manage risk
7. Implement an effective development and integration system

Number 4 appears to be the sweet spot for the PM 2.0, Web 2.0 based tools. The other 6 are left to the skills and experience of the project manager.

Why I'm a Cynic About PM Products

Being cynical is part of being a Program Manager and even more so for a good Program Planning and Controls manager.It simply comes with the territory.

When someone tells you something about the program, like "oh yea I've got all those Work Packages sequenced so we can meet the Critical Design Review (CDR) date," my first impulse is "sure, let me ask a few questions."

• Do you have sufficient schedule margin for the programmatic risk aspects of those work packages?
• How about those pesky technical performance measures? Got any idea how you're doing on staying inside the performance bands on your design parameters?
• How about those annoying upstream dependencies from systems engineering, got that covered in your subsystem spec in time for the draft release to the customer 60 prior to CDR?

Things like that are what we work every week.

So now comes along the project management software vendor, with a message of hope and prosperity for all us PMs. Now I am personal friends with many product managers for these products and even a President of a project management product firm. That's not the issue.

The issue is all but a few of these product firms actually manage projects or programs for a living prior to their role as a product supplier. My one shining example is a product and it's leader who was a PEO (Program Executive Officer) in the US Navy, who "managed" several aircraft upgrades to the fleet in his service career.

Others have long careers in Project Management software product sales. Some are experienced in the politics of this industry. Many are just "good salesman," for which I have the up most respect.

So Where's the Rub?

As Will says:

To sleep - perchance to dream: ay, there's the rub, For in that sleep of death what dreams may come When we have shuffled off this mortal coil, Must give us pause.

There's always a "rub." In these cases the "rub" is in many cases it's a "push" sale. "Here, look at my cleaver tool, see isn't it cleaver and how exactly is it you manage program?"

So one of my first questions - especially during trade shows - is "tell me about how your tool is used on a specific program to increase the probability of that program's success?" This notion of "probability of program success (PoPS)" is concept adopted by the US DoD and flowed down to the services.

Everyone in that domain knows that program success is a probabilistic process. Every variable in a status report, every variable in a planning document, a basis of estimate -everything is a random variable. Drawn from an underlying probability distribution, that may be known or unknown.

This is the rub

All work is probabilistic. So if your tool does not acknowledge that in some way, have the ability to deal with that, process those probabilistic values as part of its normal course of work - then the only strategy you left with for increasing the probability of success is HOPE. And Hope is not a Strategy.

So when you're at the trade show, or watching the pod cast of the vendors product, or reading the marketing literature ask yourself these questions:

1. Is what they're trying to sell me an answer to my real problem?
2. Does the vendor understand the real problems of project management?
3. Is their demonstrated evidence that this product increases the probability of success?
4. If so can I hear how this happened?
5. And most important can that success be applied to me domain and context?

We get very few positive answers - a few, but not many. That's the source of cynicism. Vendors don't manage programs. Their message is a sales message, cleverly wrapped around marketing hype.

So Here's Some Advice

The source of this advice came from a very crusty senior warrant officer circa 1970, South Vietnam. He was the maintenance officer for our fleet of aircraft. I was assigned for a short time to his shop to "learn" the problems of mission planning from the inside.

Mission availability was the unit of measure. "How many aircraft are ready for tomorrows mission?"

The answer had better be "enough to fly the mission and enough spares when they fail to depart on time." But we some times answered - as young naive officers - "well sir, we're working real hard to get ready for tomorrow."

His advice was:

BOYS, (and he meant boys not men) NEVER CONFUSE EFFORT WITH RESULTS, WHEN ARE THESE PIGS GONNA FLY?

My version of his advice is:

NEVER CONFUSE PROJECT MANAGEMENT TOOLS, WITH PROJECT MANAGEMENT,  WHEN ARE WE GOING TO ARRIVE AT "DONE"?

Project Management Processes

The discussion of PM 2.0 on Andrew Filev's site has started to turn toward reality and away from the hype of the "next big thing."

Tiberiu Ghioca, a software engineering manager, commented that PM 1.0 and PM 2.0 - and I'd add PM any version - has little to do with increasing the probability of success of a project. While not literally the not case, because of course with the "right" tools, actionable information needed to "manage" the project is not available, tools are a small part of a projects success. The work of managing a project can most certainty be done manually.

I started my career in "projects" as a software engineer on radar and sonar systems, writing digital filters. My boss had a master schedule on the wall of his office using the "statement of the art" tool of the day - a bulletin board style contraption, the pins and colored yarn, and small tags. This showed the sequence of work needed to replace the analog radar controller with a digital controller up and running - circa 1979.

Tools may increase productivity of the users. But sometime I wonder how much time we spend fiddling with SAP and Project Server actually contributes to progress.

The notion the "collaboration" has just be discovered by the product developers doesn't smell right to me. Knowing personally the product managers at several PM product vendors, it's never as clear as that.

The drive for collaboration has always been present since the Egyptians were managing projects. Collaboration is a fundamental aspects of all successful projects. One approach of the PM 2.0 proponents is the assume PM 1.0 is lacking certain attributes, starting with a "moral motivation." Which of course is complete nonsense. Poorly implemented PM methods are the source of poor PM performance. The research has shown this for many decades.

What PM 2.0 brings to the table is the integrated use of some of the Web 2.0 facilities on the desktop. But those Web 2.0 pieces are just the tip of the iceberg of all the critical success factors for a project. None and I mean none of the suggested PM 2.0 attributes address the core success factors of PM.

These are simple:

1. Do you know what "done" looks in terms of testable and verifiable outcomes? Is "done" traceable in anyway to the needed business or mission capabilities? Are the technical and operational requirements derived from these needed capabilities found in some description of "done?"
2. Do you know what this will cost in the end? In other words, can you tell the customer that you have some notion of the total end-to-end cost of getting to "done?"
3. Do you know on or about you'll be done with "done" for the cost? Do you have a planned budget and know something about how you're going to spend this budget? The "budget spreads" as we say in defense and space.
4. Can you tell me the impediments to getting done and what you're going to do about them along the way, and how much that will cost?

PM 2.0 does not answer these questions. No tool answers these questions. A tool may facilitate the communication to discover the answers.

The answer to these questions comes from the PM process and the PM participants.

The embracing of new technologies to implement proven PM methods, as Tiberiu suggests, does not change the fundamentals of those methods.

So let's look quickly at the 4 items to see where tools can help

1. Do You Know What Done Looks Like?

The elicitation of requirements, whether formally or casually, is a systems engineering process. Ranging from full up TeleLogic (now IBM) DOORS to 3x5 cards on the Scrum wall, requirements are what drive two of the three independent variables of a project - cost and schedule.

But requirements themselves need a home. This home is the needed business or mission capabilities.

"What do you want to do with the resulting system when it arrives?" "Fly to the space station?" "Process insurance claims?" This information is captured in the Concept of Operations (ConOps). Monetizing these capabilities in terms of a Basis of Estimate is the starting point.

2. Do You Know What This Will Cost?

If you're spending your own money, who cares. But if you're spending someone else's money, you had better care, or they'll find someone who does care. Having a "not to exceed" cost is one way to control spending. Producing a bottom up budget is hard work in many domains.

But in the end you've got to know how much money you've got know if the project's capabilities and requirement can be delivered?

3. Do You Know What You'll Be Done?

Some "on or before" date with a confidence level is the starting point. But the critical success factor is to understand in some way what are the drivers for this date. In agile it could a velocity measurement. In more formal domains it's Earned Value and all the modeling that goes with the Integrated Master Plan / Integrated Master Schedule.

4. Do You Know the Impediments to Progress?

"Risk Management is How Adults Manage Projects," - it's that simple

PM 2.0 Management Tools?

Is PM 2.0 really managing these four attributes in new and innovative way. Let's hope so.

Not Your Fathers Iron Triangle

The concept of an Iron Triangle has been around awhile. Cost, Schedule, Quality - in the iron triangle are related. This of course has been the brunt of the anti-PMBOK movement for awhile.

In the current defense and space domain and context, there are three variables that replace the Iron Triangle with a triangle that is connected:

• Cost - what is the budget allocated for the work to be performed?
• Schedule - what is the time allocated for this work. The Period of Performance for the Work Packages, Rolling Wave they make up and the Planning Packages for the remaining work?
• Technical Performance Measures - what is the target technical performance for the work product produced by the allocated cost (BCWS) applied to the Work Packages over the planned period of performance?

These three variables are immutable. If you change one the other two may or may not change. This depends on the coupling between them. They are not Iron.

The current PMBOK dropped this notion, but failed to replace it with an understanding of the coupling between Cost, Schedule, Technical Performance.

When you're thinking of the performance of a project, all three variables must be considered. This is the current assessment process for government programs. This is the core approach to Earned Value Management,

• Measure the physical percent complete against the planned cost to produce the Earned Value
• Assess the compliance of the delivered product

Since the units of measure of EV are Dollars, time and technical performance targets must be evaluated through some form of calculation. The time aspects is the Schedule Performance Index. But the TPM must be predefined before the work starts and assessed at the conclusion of the period of performance for the Work Package.

It's this predefined value that is commonly missing in projects. "What does done look like," needs to be defined BEFORE the work starts, so you can recognize it - or its absence - when you reach an assessment point.

How Did We Miss the Idea of Project Collaboration in PM 1.0?

A comment made on a PM 2.0 Blog states:

"suddenly people realized that the Old PM (PM 1.0) was missing this collaboration part"

The missing part was to add collaboration to the PM method.

I stumped. Project Management without collaboration. Chapter 10 of the 1996 (the original) PMBOK states:

Project Communications Management includes processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. It provides the critical links among people, ideas, and information that are necessary for success. Everyone involved in the project must be prepared to send and receive communications in the project "language" and must understand how the communications they are involved in as individuals affect the project.

Now how as PM's did we miss that, dang.

Beyond the Hype

My friend Jack is sometimes a bit forward, but he has a point when he posts a comment on Andrew Filev's PM 2.0 blog. 

Notional charts are just that notional. Not the basis of decision making.  Jack is a very seasoned project manager, and like me the suggestion that a technology (Web 2.0 and it's cousin PM 2.0) is the basis of something new in the project management space is, how can I say this, not credible. 

Having been in the technical and business software development, enterprise IT, and related technology business since the late 70's, I've seen a several dozen or so "next new things," ranging, from the first structured programming languages - Pascal and its father Algol-68 to the savior of the western world ADA, the Saviour of all things networked SNA and then of course TCP/IP, anyone remember XNS, much better than TCP/IP, but like all things Xerox too complex and proprietary. To the introduction of mini-computers - I wrote me first Fast Fourier Transform (FFT) algorithm in a PDP-8M with 4K of memory. Ran at a blazing 120KHz for 128 point "real" number sampling buffer. To the demise of COBOL. I actually tried to carry Grace Hoppers bag, when I picked her up at the Orange County airport for an ACM meeting. She sternly stated to me in her Navy Captain's uniform, "young man I am perfectly capable of carrying my own luggage." To time sharing - Boeing TCS were APL wa our language of course for radar signal processing simulation. To the Lisa - I acutully wrote code for that beast.

All of this is the lay the ground work for Jack and others, that we're skeptical of "revolutionary solutions" to what is essentially an ancient problem - managing projects. I draw my recent skepticism from a solid business book, introduce to me by Bill Duncan, of PMBOK 1996 fame - Beyond The Hype: Rediscovering the Essence of Management, Eccles and Nohria, Harvard Business School Press, 1992. 

Yes 1992, when the same approaches to "new idea" introduction were being written about then are reappearing now. The issue for Jack and those like him - including me - is that the term Project Management has been relabeled to mean the technology of a small portion of manging project management - the interpersonal communications and people collaboration part. 

Once that relabeling has been introduced the Essence of Project Management, like Eccles's "essence of management," is lost and the pitch becomes "look at my shinny new idea." Which is not a idea or process per se but a product that has been labeled as Project Management, PM 2.0.

So if we want to talk about the Real PM 2.0, how able a solution to the abysmal success rate of enterprise IT. Or the equal abysmal success rate of DoD projects. DOE seems to have some secret sauce. Or that $4B write down at the IRS. Or the $3B "gone missing" for the World Wide Command, Control, and Communications System back in the 80's. Or the in the news today where the video link on the Predator can be hacked. The Information Assuance (the new term of encryption) guys needs to be taken to the wood shed.

PM 2.0 needs to search for actionable improvements in the processes used to actually manage projects. Where management is a verb not a noun.

The selling of PM 2.0 is a product approach to what is essentially a people and process problem. It's a one legged stool in a four legged table world.

Power Laws and Project Management

Steve posted a comment on a previous post that spurred me to put on my physics and systems engineer hat for a moment.

The power law notion presented in the previous post by Andrew Filev is useful in many domains.

The Power Law is applicable IF, one quantity is dependent on another raised to a "power." What Andrew did was to assume this is the case then build an example. In the statistics world this is called a Post-Hoc argument. It goes like this, "Let's assume there is a power law relation between the number of small (no defined unit for small) and large (no defined unit of large) and possibly mega (again no defined unit) then the "power law could be tested - not assumed post-hoc.

Here in the space and defense business a "notional" concept is used all the time. But the little joke is "I see you're making a notional description of the problem at hand, nice power point presentation, where's the real numbers?" The classic is the Power Point pictures of flying to the moon, then to mars in the 500 page backgrounder called Constellation, were one of the programs we work derives the Orion manned vehicle avionics, which will go to the Space Station in 2014 (maybe), From there it's only a 1,000 times scaling to get to the moon and only a ½ million times scaling to get to Mars. No problem, we got a nice PPT picture of how to do it.

Now to the subject long tails in task durations

Steve asked about long tails for task durations. Great question.

The use of Mote Carlo simulations is mandated in our domain (DID 81650 is the source document). The tools we use (Risk+ and @Risk For Project) provide probability distributions that can be tuned for the specific task modeling. There is a principle in this practice that say "any longer than 35% or so to the right requires management intervention, don't use that in your model."The triangle distribution is usually the starting point. The boundaries of the Triangle in Risk+ are the 0 and 100 end points, in @Risk they are the 10% and 90% end points. This provides the ability to describe an asymmetric shape for the task durations.

But, and this is critical, the "long tails" don't exist in the planning process. Independent of their possible existence. This is the role of the Integrated Master Plan - to reduce the probability that there are "unknowns," in the plan. The real long tails - the unknown unknowns have been addressed in previous iteration of the program - during Milestone A and Milestone B. The work of system development - Milestone C - is working toward the low rate initial production.

The second rule - in our domain - is you plan and mange at the Work Package level, not the task level. Task management is the accountability of the Control Account Manager, or her designated Work Package Manager. Work Packages con only cross one accounting period. These means they are limited to 60 calendar days. Like Vegas, what happens inside the WP says inside the WP. It's the measure of physical percent complete we're after.

The reason for this is the WP is on baseline and if the tasks need to be rearranged for what ever reason - good or bad - we don't want to impact the baseline - 'cause there's too much paper work and we're essentially lazy. 

Power Laws Abound, But Make No Assumptions Without a Test

Power Laws describe relationships that are "scale independent." Physics is one place to start. Having grown up in the particle physics world, power laws are used in the Standard Model of particles. As well a REALLY good power law in classical physics (thermodynamics) is the cooking time of a turkey. It is a power law related to the surface area of the bird.

There are Power Laws in Economics, in biology related to ecological complexity, power laws everywhere.

So in the end- yes power laws are real IIF (if and only if) there is a exponential relation between one variable and another. Assuming there is first without a basis for that assumption and then making an argument (in the mathematical sense) about something is simply bad math.

The common approach in some domains - like this example - is to use a notional graph - Kent Beck did this - to make a point. But the point may not actually have a factual basis. It's a notional point. An interesting dinner conversation piece. But trying to make managerial decision from notional graphs is real sporty business where I work.

Your mileage may vary

DoD EVM Implementation

Paul Solomon has posted a link to the DoD Earned Value Management: Performance, Oversight, and Management Report to Congress. 

Anyone interested in the least just "favorite" Paul's site and subscribe to his posts. Paul's book Performance Based Earned Value, is heavily yellow highlighted and "tabbed" in my backpack everywhere I go. You can't really say you're an EV junkie unless you have his book.

Agile Notions Already Are At Work

The Projects@Work site has an editorial titled "Agile, by any other name." (Registration required). There is of course the original Agile Manifesto. Then 7 additions clarification points:

• Develop in short cycle times
• Plan short term (the next cycle)
• Develop only what is needed
• Close collaboration with the user
• High visibility and daily reporting
•  Empower the project team
• Test in parallel with development

These approaches are also found on large space and defense programs. There the Integrated Master Plan / Integrated Master Schedule (IMP/IMS) paradigm is mandated for programs greater than $20M. $20M sounds like a lot, but in that domain it's not. Most firms then push this paradigm down onto all programs. As well DID 81650 is mandated along with an Earned Value Management process.

Using the Agile Guidance for Managing Projects

While the 7 items above are usually applied to software development activities, they are generally applicable to any project domain and context. Here's how they are applied on 1/2 billion dollar manned spaceflight software programs, multi-billion dollar Army combat systems and many multi-billion dollar Air Force integrated world wide "everything over IP" program.

• Develop in short cycle times - the primary role of this behavior is to ask and answer the question. How long are we willing to wait before we find out we're late?

Short cycle times have different meanings to different domains. But all defense and space programs have monthly earned value assessment of physical percent complete. Nearly every Earned Value Management System - System Description (SD)

• Plan short term (the next cycle) - rolling waves are used for all non-trivial programs.

This means the current rolling wave is being executed from the Performance Measurement Baseline (PMB). The PMB is a time phased description of the cost, work, and deliverables. The current rolling wave consists of Work Packages, with a duration, resource "spreads" and a single deliverable.

Planning packages are used for "out year" (yes years) work. These Planning Packages has durations and cost spreads, since the the critical path must be identified from Contract Award to Contract Closeout.

• Develop only what is needed - the rolling wave work package process defines explicitly what is to be produced.

In the federal contracting world if you work on things that are not needed for the next Program Event - see Integrated Master Plan / Integrated Master Schedule Preparation and Use Guide - you wouldn't get paid.

It is critical for the program to work on only things that increase the maturity of the deliverables "as planned" in the Integrated Master Plan (IMP). Otherwise the program is decreasing the probability of success. There is an urban myth that programs like this have Big Design Up Front. That is simply a lie, er "red herring." Change is constant in Pre-Milestone C programs. These are System Development & Demonstration. The milestone after that (D) is Low Rate Initial Production (LRIP). SDD is emerging requirements driven.

• Close collaboration with the user - this is not as easy as in small team IT projects.

But Technical Interchange Meetings (TIM) occur frequently for all the obvious reasons - emerging requirements. As well there is daily if not hourly contact with the customer for SDD style programs for again all the obvious reasons. But requirements are flowed down from the customer to the supplier. There is more formality in the development and management of these requirements. This is driven by the production mature of the products. If you're building a one off is a test vehicle in a DARPA style program (a science project), the requirements management is much different than if you're upgrading all the F-18's in the fleet with new GPS navigation systems.

IT projects are almost always "one offs."

• High visibility and daily reporting - well maybe not daily, but certainty weekly.

Most programs we work, do weekly earned value. Monthly is mandated. NASA requires "mid month flash reports." So if you're going to do that, you might as well do weekly. What this means is a weekly "interview" with the Control Account Managers (CAM) to assess the physical percent complete of the planned deliverables. The critical concept is the "physical percent complete." You never confuse effort with results. So the passage of time and consumption of money is not a measure of progress. Physical, tangible evidentury materials are the only measure of progress. How do you assure that the deliverable meets the spec? Why test it silly. Yes Test Driven measures of physical percent complete are the way large defense programs work.

•  Empower the project team - teams work as "teams." usually with a lead and a collaborative staff.

This is how engineering works. For some reason the software world is just figuring this out. No credible engineering firm would work in a command and control manner for long. The product would not get out the door.

• Test in parallel with development - test driven development is the standard system engineering approach.

It can't really be anything but this and have th ability to hold the schedule and meet the cost target. Rework is unfunded in the DOD procurement processes. ANSI-748B does not record BCWP for rework. How do you avoid rework? Built it right the first time. How do you build it right the first time. Test the living !@#$ out of everything as you go.

The Basis of Project Success

The last several posts have been around PM 2.0 and what that means, if anything to the project management space. It's time to remind all those claiming to have the next big thing in project management of the core elements of a success project.

First let's look at the sources of project failure. There are many of course. My particular point is view is from the Program Planning and Controls paradigm. There are numerous, probably too many to count reasons on the "softer" side of projects. And likely as many Tools reasons. .While people are certainty the most important aspect of a project, the tools are a distant 3^rd for reasons mentioned in the past.

Let's look at the process needed to keep a project on track. Or another view, what things can derail a project.

Let me Count the Ways

• Inattention to budgetary responsibilities – if you're not watching the money, you'll run out and not know it. I've heard in the past that budget is not watched on many projects. I suspect this may be the case in immature organizations. But ask this. "do you watch your budget?" If you live pay check to pay check, you're implicitly watching your budget. Then why on God's Green Earth would you not watch the budget on a project. Especially if it was someone else's money?
• Work authorizations that are not always followed – as a project team do we work on anything we want to work on at any time we want to? Hopefully not. Working on the right things in the right order is part of project management.
• Issues with Budget and data reconciliation – when we're working on something, do we know how much we're spending? How much did we plan to spend? Do they match in any way?
• Lack of an integrated management system – an integrated management system could be 3x5 cards on the wall or a full blown SAP program management enterprise suite. Doesn't really matter in principle. But have something. Don't show up evey morning wondering "what should I work on today?" "What did I get done yesterday?"
• Baseline fluctuations and frequent replanning – are we bouncing all over the place when it comes to cost and schedule? "today it'll take 3 weeks to finish." "Nope, today it'll take 6 weeks." "Next week we discovered it'll take 12 weeks." Come on guys how ling is it going to take and how much is it going to cost. These number by the way estimates. They need variances and confidence intervals in order to be credible.
• Lack of predictive variance analysis – if I can't forecast future performance in some way, it'll be hard to tell when we'll be done. Agile uses velocity. Big programs use Earned Value. Use something. Don't just sit there and look stupid when asked "any guess about when we'll be done and how much it'll cost when get there?"
• Progress not monitored in a regular and consistent manner – "how we do'in?" "Oh I don't really know, we're taking this one day at a time." That's a possible answer for some situations, a death in the family, a recovery from illness, or a 100 mile loop on a road bike around the Colorado mountains. But probably not a good response for a project manager. Know how you're doing. Know that of you keep going at the rate you're going you'll arrive at some projected time. Just like looking at the speedometer on the road bike. "If I keep peddling at this rate, I'll arrive in Leadville in two hours."
• Lack of internal surveillance and controls – who's watching from the outside? Who agrees things are going according to plan. The notion that there is a plan is the first step. But let's assume there is a plan, who gets to say we're moving along according to plan?
• Managerial actions not demonstrated using performance measures – we discover we're late or over budget. Is there a management decision to do something about it? It doesn't have to be formal "management," but is there a decision by anyone to do something different. Or are we just containing blissfully down the road to the train wreck?

So now let's assume, and it might be a big assumption that we want to do something about this pending Train Wreck. What would we do?

Staying Out of the Ditch

Here's a set of answers taken for a large set of answers. The larger set is the 32 criteria of ANSI-748B Earned Value. Now Earned Value is not being recommended here. But most of what's in the EV standard is about "good project management." Not actually EV.

• Decompose the project into manageable units of work held in the Work Breakdown Structure (WBS) that states what DONE looks like.
• Assign responsibilities for the accomplishment of the each element of work at the appropriate management level using the Organizational Breakdown Structure (OBS). Join these two structures into a Responsibility Assignment Matrix (RAM).
• Create a schedule which identifies the work activities, milestones, and their dependencies for each intersection in the RAM connecting accountability with deliverables. Adhere to the schedule – last starts usually mean late finishes.
• Assign resources to the activities, determining the cost of these resources, producing the time phased budget for the project. The result is knowledge of who is accountable for the deliverables and what is their budget?
• Identify the objective measures (physical percent complete is preferred) for all the identified work – what does DONE look like and how are you going to measure progress toward DONE in units meaningful to the project?
• Establish a change control procedure for the Performance Measurement Baseline (PMB) – assuring changes don't unfavorably impact the plan.
• Formally release the work packages for execution by the assigned resources during the planned period performance – do the work in the right order.
• Record and accumulate the projects progress through cost and schedule performance measure – assure you're measuring physical percent complete.
• Use the cost and schedule variances to develop an Estimate At Completion (EAC) and Estimates to Complete (ET) for all future planned work – use data to "manage."
• Take managerial action to compensate for past deviations or correct the planned work to meet the approved Budget At Complete (BAC) on schedule – "manage the project"
• Track and manage all changes to PMB. Past performance is a good indicator of future performance – knowing how you got to where you are now, helps knowing where you'll be going to be the future if you don't make corrections to your course.

Project Distribution

Andrew Filev provided an interesting notion about the distribution of projects. This diagram was an anchor of the conversation.

Notionally is says the are more small projects than large projects. I use the term "notionally" for a reason. Here in the defense business\, a notional diagram is a nice Power Point picture. There is a notional picture of docking at the International Space Station (ISS) with the new Orion manned spacecraft. It will work eventually. But for now it's a nice picture of how it might work.

I did a bit of poking. There were $90.8 Billion in US Based firms for projects in the sectors (The 2009 Top US Design Firms, Engineering News-Record):

• General Building - General Building, Education, Commercial Offices, Retail, Government Offices, Health Care, Multi-Unit Residential, Correctional Facilities, Distribution and Warehouses, Hotels, Motels and Convention Centers, Religious and Cultural, Sports, Entertainment
• Transportation - Transportation, Highways, Bridges, Airports, Marine and Port Facilities, Mass Transit and Rail
• Manufacturing/Industrial Processes/Telecommunications - Industrial Process, Food Processing, Chemical Plants, Pharmaceuticals, Steel and Nonferrous Plants, Pulp and Paper Mills, Telecommunications, Transmission Lines and Cables, Data Centers and Web Houses, Towers and Antennae, Manufacturing, Electronic Assembly, Semiconductors, Auto Plants, Aerospace
• Petroleum - Petroleum, Refineries and Petrochemical Plants, Pipelines, Maintenance, Offshore and Underwater Facilities
• Power - Power, Nuclear Plants, Operations and Maintenance, Hydroplants, Cogeneration, Fossil Fuel
• Environmental - Sewerage and Solid Waste, Sanitary and Storm Sewers, Water Supply, Treatment and Desalination, Transmission Lines and Aqueducts, Dams and Reservoirs, Hazardous Waste, Chemical and Soil Remediation, Asbestos and Lead Abatement, Site Assessment and Compliance, Nuclear Waste, Clean-Air Compliance

That's Billion with a B. This is just for the "built environment," as those in that industry like to say. Another approach is to look at individual firms in our sweet spot - firms that are 100% or close project driven. For example Honeywell Aerospace is a $12.7B revenue in 2008. 90% of everything they do is a "project" or a "program."

The top 25 software providers in the world generated $160B in revenue. The Top 100 generate $202B in revenue in 2008.

Now let's take a pause. Out of this 202+90+some billions of revenue, how many projects do you think there are? I'd say lots. Now add the Federal, State, and Local "projects," from their published budgets. DoD is $513B, DOE $27, DHS $37B. So with all this it's around 202+90+513+27+37. Take away the operational aspects of the feds (down by half) and you get around 869 adjusted to say $500B. That's half a trillion dollars a year in projects. So what's the dollar of every small and personal project on the planet?

To move from a notional graph - which may or may not have any connection to reality - to something that is useful and possibly actionable, the dollar value of projects might be useful. As an aside, I'd think those in the PM 2.0 market place would want to know the total available market for their products.

But that comes from my limited experience of going through 2 start ups, one which made it to IPO, www.triconex.com.

So what does all mean in the end. Yes there are likely more small projects than large and many even medium. PM 2.0's sweet spot is in the small domain. But no one said what the size of a "medium" project is? $1,000? $10,000? $100,000? 

Then the graph makes that wonderful jump described in How To Lie With Statistics, Darrell Huff, 1954. And that is, show the number in a logarithmic scale. That jump from personal, to medium to Mega.

In the end this is a dimensionless, unit less, content free picture. Reminds me of the early Kent Beck concepts of the cost of change of XP versus conventional. Nice notional picture.

Worthless for making business decisions.