Herding Cats

Clever versus Wise

While reading Bill Miller's Blog, which is one of favorite sources of great ideas, wonderful pictures that go with the story, and most of all truly honest approaches to managing software projects, I went do a site that had a great Eisenstein quote

A Clever person solves a problem
A Wise person avoids it

This got me thinking, why all this cleverness about project management, software development? All these alternative and sometimes even feral approaches to doing projects for money. It's the Wise project manager that...

• Figures out what done looks like at some level of granularity that you're willing to commit to starting the project - even our mega (1000 mega actually) projects have "emerging requirements. You gotta start someplace, but don't let the notion of emergence drive you into the ditch. Keep to the vision
• Measures progress through some sort of physical percent units - don't tell me that you're working hard, tell what you actually produced that you want credit for in a physically tangible way. If you can't tell me where you are along the path in "done" in some meaningful units of measure - a unit of measure that can be converted directly into dollars and days - then "hope is your strategy." How many times have you asked the developers - "when will you guys be done?" No answer? Then when will you know when you'll know? So sort of Estimate to Complete needs to be in place all the time. Every day, every week, every month. Updating this "estimate" - and it is an estimate, a probabilistic estimate with a confidence interval - is what project management is all about.
• Holds people accountable for their actions - can't tell you how many times some agile guru has shown up at - what is now our client - and sold them a bill of goods. Extreme Programming consultants were quite common, now it's Scrum consultants. They're not neary as bad. But Agile Project Management is the current rage. Ask them "how many actual projects have you personally managed to a successful conclusion using this method? In the A&D space, we call this past performance. My favorite was a well known XP-derivative supplier. Came to our then client with a clever tool, a bag of slides showing how to save gobs of money on a port of a legacy system to some clever Java platform. Recommended we embark on a project and "let the requirements emerge." When the CIO looked across the table to our team, we had our head in our hands. Did happen. We recommended they scrap the company that used the legacy system and buy one that had the right system for processing their transactions. It wasn't really the XP-derivative guys fault. His method just didn't scale to $50M worth of development effort.
• Is adaptive is everything. There is no magic bullet - or magic beans, as one feral project likes to say. But what ever you move away from, ask the critical question - did we violate the principles of the past or did those principles not work? Those are two different questions.

So be wise, before being clever.

Progress Means Measuring Physical Percent Complete

The measure of progress in a project must be done through some form of Physical Percent Complete. If not, then all you're measuring is effort and the consumption of time and money. The use of Earned Value is one way to make visible Physical Percent Complete. One overview of EV comes from The Department of the Navy, which has many resources on the application of EV to projects

Earned Value Management is an effective management control tool, and it is important that Program Managers understand EVM as a disciplined planning and management system, and use EVM data in day-to-day program management. When used properly, EVM allows both Government and contractor program managers (PM) visibility into technical, cost, and schedule planning, performance, and progress on their contracts. This visibility provides not only insight to contract performance, but also provides data points to statistically estimate probable completion costs. The implementation of an effective EVMS is a required function of program management. It ensures that cost, schedule, and technical aspects of the contract are truly integrated.

Earned Value is not the only way. Scrum's measurements of velocity - if the units are calibrated in dollars and time rather than some cockamamie units popular by the extremist - can be equivalent to EV's Cost Performance Index (SPI) and Schedule Performance Index (SPI).
    This BTW is the source of many failure modes in projects

Failure to provide  units of measure meaningful to the customer

By meaningful I mean dollars and time. That's a meaningful unit of measure to a business manager.

Progress To Plan is How PM's Speak to Customers
    Trying to complete on time, working real hard, describing all the issues that have arisen since we last talked is not making progress to plan. Speaking about Physical Percent Complete is how good project managers talk to their customers. Without this basis of conversation, all other conversation are not about projects. They may be about something else, but it's not about managing projects.
    This doesn't mean there aren't many more aspects to successfully managing projects. The previous post list some of them. Others include all the softer sides of a projects, the political sides, the technology of the products, services, and tools and of course the general nature of business processes.
    But as a project manager if you can't speak in clear and concise terms, in units meaningful to the customer and the team about where you along the plan to successfully deliver the product, service and the business benefits - the other aspects of project management are moot.

A Simple Way to Put PMBOK to Work

While some in the alternative project management community have found credible issues with PMBOK (risk management for one. The explicit lack of agile in another), there is a simple approach to get value from this 387 page document. Starting with the knowledge areas in the 3rd Edition, assess how each area could, should, or would be used to benefit your project

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

1. Integration Management

• What are all the activities that are performed in the project?
• Does everyone on the project know about them, their role in them, their accountabilities for them?
• How is this information communicated to the project members?
• How are changes to these processes managed? How gets to approve the changes. In the current IT Governance paradigm, these are called decision rights?

2. Scope Management

• What does "done" look like?
• What are the units of measure of "done?"
• How are changes to "done" managed?
• Who gets to say we're "done?"
• How much does done cost? How long will it take to "done?"

3. Time Management

• What is the duration of all the activities we're doing on the project?
• What order - if any - should these activities be performed?
• What resources will be needed to perform these activities?
• Are there any special arrangements needed for these resources?
• How will we control changes to the schedule of activities and assignment of resources?

4. Cost Management

• What's the estimated cost of this project?
• What budget is available to cover these cost?
• How will this budget be spent as a function of time?
• How will we control the costs so as to stay within our budget?

5. Quality Management

• What's our plan for producing the needed quality from our activities?
• How can we be assured that we're producing the planned quality?
• How can our activities be controlled to assure that our efforts produce quality results?

6. Human Resource Management

• What skills will we need for this project?
• Where will we find them?
• Once we've got the right people, how can they be put to work in the best way?
• What additional training is needed?

7. Communications Management

• Who has to know things about the project?
• How do we communicate with them?
• What kinds of information do they want to have?
• How is this communication made? On what intervals?

8. Risk Management

• What are the risks to the success of the project?
• What's the plan to mitigate them?
• Who's accountable for these mitigations?
• How can we tell these mitigations are working?
• How much will these mitigations cost and how long will they take?
• What resources will we need to perform these mitigations?

9. Procurement Management

• If we have to buy things for the project, how is this done?
• What contract vehicles will be used for these procurements?
• How do we receive the materials, pay the vendors, and close out the contracts?

These are "sample" questions that need to be answered by what ever project management process is used. No matter what process - extreme, radical, agile, feral, structured, or what ever. It's not project management if you're not doing these processes in some way or another.

The Mis-Misinterpretations of PMBOK

Most of the ragging about PMBOK starts with the misinterpretation of the purpose and content of A Guide to the Project Management Body of Knowledge. First it is not "The" Body of Knowledge, but "A" Body of Knowledge. Second it is not "The" Body of Knowledge, but a "Guide" to "A" Body of Knowledge. See the trend here. Most authors ragging on PMBOK appear to have trouble reading the title of the book.
 
Next comes the concept that PMBOK is a project management methodology. That is tells you how to manage a project. This not true. PMBOK is a guide to some good practices that shoudl be found in your project management method.

One simple approach to the application of PMBOK is to ask:

What process groups and knowledge areas would you NOT want to be found in your method of managing projects?

Would you NOT want to know how to do during your project (Knowledge Areas)?

1. Integrate the activities found in projects. Things like: chartering, preliminary scoping, developing a manage plan, directing and some how managing the project, monitoring and control the project in some way, managing the changes that occur during the project, or closing out the project once its over?
2. Or how about knowing the ways to: manage scope, manage the time aspects of a project, or the costs of doing the work, or the quality of the products or services produced by the project?
3. How about the human resource aspects of project work?
4. Maybe the communications issues associated with projects and the people working on projects?
5. When risk appears in project work, how about some methods of managing it?
6. When external materials are needed, wouldn't some good procurement processes be useful?

These are the knowledge areas of PMBOK. The current PMBOK uses a Plan, Do, Check, Act cycle. This provides the framework for managing the project using feedback and corrective action. It has been suggested that the thermostatic approach to project management is obsolete, without of course providing alternative. But more critically those making this suggestion have failed to understand the rudimentary aspects of the theory of control systems:

• The system under control has the ability to be controlled in some way
• Feedback from the current state of the system is available in some unit of measure useful to the controller. (The controller can be human or machine)
• When "commanded" to do so the system can make changes in its behavior in response to the "command." (This command is not a military like command, but an input to the system that alters the output).

Now is when the confusion starts. ALL system under control have these (and some other subtle) attributes. What needs to  be answered in order to determine to appropriateness of the control system includes:

1. What is the necessary sample rate needed to properly control the system?
2. Is the system linear or nonlinear in its response to requests to change?
3. What is the level of "noise" in the sampled state data, the command data, and the sampling intervals?

There are others, but they're beyond the scope of this post.
Here's Where the Critics Go in the Ditch
One popular criticism of PMBOK is the conjecture - and it is pure conjecture, since PMBOK makes no statement to this effect - that project management control systems are thermostatic in nature. This criticism of course is meaningless unless you can answer the following questions:

• Is the sample rate correct?
• Is the response function set right?
• Can the system respond in the appropriate manner in the appropriate time frame?
• Is the feedback gain set right?
• Is the feedback being used in the proper manner?

In the absence of this information and the proper setting of the attributes and variables, any control loop would fail to work properly. This ranges from your simple $10 furnace control to the multi-million $ control loop that landed Phoenix on Mars last night.
The ability to write criticism about a topic is nearly boundless. The ability to understand how the fundamental of something works - say a thermostat - may not be as boundless. When the notion that project management is obsolete because it uses the thermostatic model for control is made, statements fall into a class defined by Wolfgang Pauli: 

A scientific argument is said to be not even wrong if it is based on assumptions that are known to be incorrect, or alternatively theories which cannot be possibly falsified of used to predict anything. Pauli's comment on a paper he was shown by a colleague. "That's not right, It's not even wrong."

That's the starting point for the argument that project management process groups and knowledge areas of PMBOK are obsolete. The authors (which can be found by searching the phrase "project theory management is obsolete" have many other "not even wrong" notions. But the thermostatic is my favorite, having grown up in the software world as a control system programmer for missiles and paper mills.

Milestones Don't Mean Progress to Plan

 Milestones are considered a useful means of measuring progress to plan. This is a common myth in the project management business. Johanna Rothman mentions milestones and completion criteria in a recent post.
There are several issues with milestones to start and completion criteria in the end

• Milestones are simply rocks on the side of the road. You see them when you drive past. They have no units of measures, other than you are approaching them, at them, or have passed them on the road to nowhere.
• Exit criteria are usually defined for the current work effort in the absence of an overall assessment of the progress of the project. Again the units of measure for the Exit Criteria are lacking in some meaningful way.

One solution for these issues is to measure the progress of the project by the increasing maturity of the deliverables. This is the basis of the Integrated Master Plan / Integrated Master Schedule approach used in aerospace and defense. (This link may require a login, and will give you a certificate error. But work through those. This is the current guidance on developing and using IMP/IMS).
The IMP asks and answers the following questions:

• What is the pre-planned level of maturity needed at any specific time in the project
• What significant accomplishments must be performed in order to reach the pre-planned level of maturity of the project at this time?
• What is the Criteria for assessing the pre-planning level of maturity?

The IMS describes the work needed to reach the pre-planned level of maturity. All this seems complex, but it doesn't have to be.

• In the schedule speak about the level of maturity in past tense terms using the deliverable, it's maturity and the state of the deliverable - preliminary test of database conversation process complete
• Speak about the accomplishments needed to assess the level of maturity - Installation of Oracle service processes Complete
• Speak about the Criteria needed to assure that the Accomplishment is performance - Test of Oracle service processes Complete

Speaking in the Past Tense of the Criteria. These are the Exit Criteria for the Tasks performing the work. The Accomplishments then describe what level of maturity has resulted from these efforts. When all the planned Accomplishments have been "accomplished" the deliverable(s) of the project are assessable as to their level of maturity - Preliminary, Initial, Final, Operational, Tested, Integrated, etc.
Milestones Are Illusions of Progress
While milestones and stage gates are common approaches to measuring progress they have all the problems mentioned in the beginning plus one more.

You only know about them when you pass them

The IMP/IMS approach - and the adaptation of IMP/IMS to commercial environments provides an assessment of progress at the end of every lump of work effort. In Scrum for example this can be the end of the iteration.

Customer Service

    I rarely write about personal experiences, but this morning is an exception. We're getting a laptop for our daughter's graduation gift. No Apple because they're too expensive, sorry. I misplaced the order confirmation and couldn't track down the purchase through other means. All I wanted to know was - did the order go through and what day will it arrive.
    Go on the Dell site, click on the "call me back" page. Phone rings in 2 seconds, live person comes on in 10 seconds. I explain my situation. I didn't purchase this through my normal Dell account. First phone number didn't bring up the order. Second number did. He confirmed the address, the build is in process and the delivery date. Reconfirmed the email and while we were on the phone the new confirmation email arrived. All is well for a nice "Sea Green" laptop loaded with college girl software to arrive by the graduation party.
    Contrast that with United Airlines and a butt simple request to change a flight from the evening to the morning. 10 minute holds, endless walking through the voice response system, finally reach on off shore customer service person. It's not their fault they have to work for United, but it's my fault for flying United to maintain my 1K status.
    The total Dell transaction took less than 2 minutes. You can't change a flight in less than 15. United should hire Dell to run customer service.

The Next MUST Read Book

After Reinventing Project Management, the next book that is a "Must Read" is IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne W. Ross, Harvard Business School.
    Much of the confusion around project management in the IT business starts when the concept of Governance is skipped.

• Who gets to decide what to do?
• Who gets to decide what done looks like?
• How can these decisions be connected with the business strategy?
• How can we tell we're making the right decisions?

    Coupling IT Governance and Reinventing Project Management into a three stage process lays the foundation for project success

1. Governance - what are the rules for managing the IT department in its quest to provide value to the organization?
2. Request to Project - what projects shoudl be done for the business? Who gets to participate in these decisions? How can we "Guard the Front Door of IT," so the resources and capabilities in place today can deliver value for tomorrow?
3. Project to Delivery - once the portfolio of projects is defined (project selection using some form of portfolio management), how can they be assured to complete on-time, on-budget, and deliver the promised business value?

    This is the role of the Program Management and Project Management professionals in IT. All the smoke mirrors, and magic beans of project management must address these questions first before any credible discussion can take place about the specifics of managing any one project to its successful conclusion.

Galileo Galilei was probably not a good project manager

    When it is mentioned that the Newtonian aspects of our world, or how Galileo established the basis of our modern thinking about how the worlds works, there are several missing pieces. The notion that determinism is the basis of project management, several gaps are present - both in the project management paradigm and the current (as of the early 20th century) paradigm of physics. Let's start with the project management paradigm
    The first is the current DID-81650 guidance to include Statistical Risk Analysis of cost and schedule in all procurements greater than $20M. Now $20M is a lot of money in some quarters. In other places it's hardly worth bending over to pick up the change.
    In all cases probabilistic risk analysis of cost, schedule, and technical performance is just good project management. A recent post on the Five Easy Pieces of Risk Management, presented at the recent Denver PMI Symposium and the upcoming PMI College of Scheduling conference with "Establishing the Performance Measurement Baseline," both speak to the mandatory process is not using point estimates, understanding the statistical nature of all estimates, and the probabilities of completing on or before a date and at or under a cost in all projects, no matter the size.
    In the end of course the Galilean spell (as some have referred to this) was broken in 1950's when Murry Gell-man shared a hall way with Richard Feynman, who together developed Quantum Electrodynamics and the initial foundations of Quark theory that is the basis of the current Standard Model. When Gell-Man speaks to regularities, he is not speaking about determinism, but rather predictable outcomes of a theory - the Standard Model, QED, Quantum Chromodynamics, and now some remaining parts of String Theory. All of which are based in indeterminism at the quantum level and reflected in deterministic behaviors at the macro level.
     The four forces of nature (electromagnetic, weak, strong, and gravitational) are spoken to in part in the Standard Model (EM, Weak, Strong). Gravity is the remaining force to be unified in the quest for the Theory of Everything.

The Theory of Project Management
    No matter your stripes regarding the validity or obsolescence of the conventional approaches to project management, the US Department of Defense and all others subject to DID-81650 mandate a Monte Carlo Simulation of the probabilistic nature of cost, schedule, and technical performance.
    Galileo would be proud of  PM's with the experience necessary to recognize these underlying variabilities, driven by natural variance, known, unknown, and unknowable statistical process who have moved far beyond his "clockwork" approach of nature.