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:
- 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?"
- 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?"
- 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.
- 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.
