Herding Cats

The Future of Project Controls

Hal Macomber just submitted a post titled "The Future of Project Controls - Five Years Later." In this post Hal states.

"The future of project controls is to place the responsibility for gauging where we are and how we are doing at every moment with the people who are executing the project. No separation of execution and control. (for that matter, no separation with planning either) Control happens in recurrent practices of assessing the project. On Scrum projects team members do their assessing in the daily scrum and in their retrospective sessions. On Last Planner® projects the assessing happens in the weekly planning conversations with work group leaders. It takes acts of design by the leader and the team to establish and then conduct themselves in this manner."

I was befuddled to say the least. This is the antithesis of how the federal government (FAR and DFAR guidance, plus individual service PM Handbooks - NAVAIR, NASA, USAF, and US Army), CobiT, ITIL, OGC Project, Program, and Portfolio Management methods suggest projects be managed.
    If I read this right - and there is a possibility I am interpreting this completely wrong - those performing the work get to say what progress is being made. Hal notes.

Greg Howell had done some writing about it indicating that the usual practices he observed created a pressurized situation for the project participants.

Aw, poor babies. Pressure to tell the truth about physical percent complete? So let's let those under pressure be the ones to tell us the progress they have made? Probably a really bad idea.
   I'm hoping to hear back from Hal on my misunderstanding of the post. In the mean time, let's all be clear about the role of Project Controls in the defense and space business.

1. Maintain the integrity of the cost and schedule baseline
2. Manage changes to and retain records of scope, schedule, and cost
3. Report progress to plan
4. Analyze variances
5. Highlight trends and produce forecasts
6. Identify road blocks and propose mitigations
7. Record risk and track mitigations and retirements
8. Generate EAC/IEAC (Estimate to Complete / Independent Estimate to Complete) forecasts

using our firms marketing phrase

The Program Controls Staff develops and provides actionable information to the Program Manager

If this role is now replaced by those doing the work, those developing code, pouring concrete, welding pipe, assembling cars, where is the Independent assessment of progress to plan? From my several decades in the software development, systems management, and PP&C business, every project that I've seen in trouble had it start with the lack of credible assessments of progress to plan. The classic ERP story is:

We'll make it up in system test

in the system development business

We'll make it up after the Initial production run

in nuclear remediation (heavy construction)

We'll make it up using our schedule reserve and stay under budget, we promise

It's a fantasy tale of "magic beans" used to get the project back on track.

    A good colleague from Houston once told me while we were slaving away on a large pulp and paper plant turn around project (which BTW cost several million an hour when they don't start on time) in his best southern Louisiana accent

Glen ole buddy, when the weeds are hitting the windshield, you're in the ditch. Get out of the ditch and keep that dammed thing between the white lines.

When the "doers" are the ones doing the tellin, we're in the ditch

Uncertainties are Correlated

The NAVAIR (Naval Aviation) Earned Value Management handbook has an interesting table showing project success and failure modes. (This link will ask for a confirmation of the certificate).
    These modes are effective or ineffective:

• Planning
• Cost estimating
• Measurements
• Milestone tracking
• Quality control
• Change management
• Development processes
• Communications
• Project managers
• Technical personnel
• Specialist rather than generalist
• Reuse of technical materials

What happens in failed or failing projects is the unanticipated impact of correlated uncertainties. For example:

• Technical  uncertainties induce cost growth in other components of the system.
• Schedule slippages due to one WBS elements impact other WBS elements.
• Hardware problems discovered late in the project must be circumvented with expensive workarounds.

These correlations can be discovered through analysis. Tools like Design Structure Matrix (DSM) can show dependencies where it was not obvious. Other approaches of interdependency assessment can be used.
    In the end though, one concept is always in place for all projects, no matter the problem domain:

Knowing what "Done" looks like - to some credible degree of fidelity - before starting work, increases the probability of actually arriving at "Done", at the planned budget, on the planned date, and with the planned technical capabilities.
Without this knowledge of "Done," the notion of emergence becomes the operative concept.
What this really means is "we'll recognize done, when we run out of money and run out of time."
Otherwise there are no bounds on either, and the project becomes a Level of Effort exercise is spending other peoples money and time.

This is course is a restatement of the obvious, but so often overlooked in the search for lean, agile, and easy solutions to the management of complex projects.

Restating the Obvious

Through a series of posts I came across an interesting site. www.typealyzer.com which will tell you what Meyers Briggs type you are from reading your blog.
    Well guess what, I'm INTJ.

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it - often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be physically hesitant to try new things.
The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communicating their visions to other people and need to learn patience and use concrete examples. Since they are extremely good at concentrating they often have no trouble working alone.

    Not so sure about the theoretical part, since I earned my living in the science world as an experimentalist. Not too interested in new things these days. But at 61, I've had more then enough excitement to date.
    Pointed it at my home site www.niwotridge.com (ISTJ: The Duty Fulfillers) and or firms site www.lewisandfowler.com (ESTJ: Guardians). Another guardian is Lockheed Martin, one of our clients.

Another Confused Look at Earned Value Management

David Schmaltz provides a look at the application of Earned Value to projects. Several common mistakes are made in this post, possibly from lack of experience on programs subject to 748B or possibly just from not seeking out information from those who earn their living complying with DoD, NASA, and DOE DCMA regulations.
    For those seeking the background to the application of EV, there are nearly unlimited sources. But the starting point is quite simple:

• EIA/ANSI-748 describes the 32 areas for a compliant Earned Value Management System (EVMS)
• EVMSIG describes the intent of EVMS and its application to programs subject to EVM
• EVMS Surveillance Guide is the directive for evaluating an EVMS

One of the best overview for Earned Value is provided at a Department of Energy site by Booz Allen.

• Introduction
• Work Breakdown Structure
• Scheduling
• Budgeting
• Concepts and Methods
• Metrics, Performance Measures and Forecasting
• IBR and Change Control
• Reporting

Any one providing criticism of EV would be well served by first going through these course training materials to confirm they have a solid understanding of the principles. Once this is done, finding someone or someplace where EV is being practiced under the guidance of 748 would be a next step. This avoids the common mistake of assuming that one knows the practice of EV before starting down the path of criticism. By the way, there are many things to be critical of. But they are not the items you might think.

CMMI, Agile, and Managing Projects

The topic of CMMI and Agile has come up again with a Technical Note from SEI on how CMMI and Agile might be somehow connected. This is one of those "must read" papers. But not necessarily for the reasons the authors might expect.
    The abstract opens with:

Agile development methods and CMMI (Capability Maturity Model® Integration) best practices
are often perceived to be at odds with each other. This report clarifies why the discord need not exist and proposes that CMMI and Agile champions work toward deriving benefit from using
both and exploit synergy's that have the potential to dramatically improve business performance.

This is a common perception for many reasons. But the first sentence in the Problem Definition section is a bit puzzling at least so for a hypothesis statement:

If these perceptions or their causes are not resolved, we are likely to see more confusion
and conflict as the adoption of each approach increases. In addition, each approach includes principles of good software development often overlooked but needed by the other approach thus being knowledgeable in both is important to project success. In the long term, this discordant situation is not healthy for the software engineering profession.

It's not clear from my experience that CMMI shops in the space and defense business are seeking agile in the way the Agile proponents would like them too. Much of the software developed in A&D (aerospace and defense) using the CMMI Framework is also DO-178B and DO-248A driven. These specifications are probably unheard of outside the flight software world. In the Nuclear Power world NQA-1 is another software verification and validation specification. 21CFR in the pharma and medical equipment world, Oil & Gas process controls have another, turbines and off shore have SINTEF software guidelines, etc. etc.
    So the question is:

What's the motivation for deploying agile software development practices - as practiced in the agile world - into the CMMI framework - or any other "increasing maturity assessment" world?

This is an important question for several reasons:

• There may be competitive advantages from agile that need to be explored.
• The current development processes may need improving for all the right reasons, while maintaining the CMMI appraisal level. But I will say the red herring of Waterfall is rarely practiced in any mature defense software organization. In fact Spiral is mandated by DoD.
• There may be some advantages to agile development processes for adopting some the Process Areas of CMMI in areas where more rigor is needed for all the right reasons.

Earned Value is Necessary But Not Sufficient

    The use of Earned Value in construction, government, and defense programs is common practice. Some SOX IT organizations have discovered the benefits of EV. But using the EV variables - Cost Variance, Schedule Variance, Cost Performance Index, and Schedule Performance Index alone is necessary but not sufficient.
    The consumption of money, the passage of time, and the measures of Percent Complete must be combined with the assessment of the technical performance of the produced product or service. The units of measure in the Earned Value Standard ANSI/EAI-748B are Quantitative. They are also measured in Dollars. This is a problem in any work that is producing something new. Something that is not like laying bricks, painting airplanes, or pouring concrete. In the "development" world there are several other issues as well:

• The work is usually not repetitive, development programs are not like production or manufacturing.
• The baseline requirements may be changing over the period of performance of the project. Changing for all the right reasons. «If they are changing for the wrong reasons, that's another whole problem»

So, we need a Qualitative measure of performance for the project. Some notion of technical compliance or Technical Performance Measurement must be added to make Earned Value sufficient for project "management" work, not just project performance reporting. This is the difference between Driving in the Rear View Mirror and Driving out the front Windshield.
    Here's why:

When the end of the period of performance arrives, be it a week, a few weeks, but hopefully not more than a month or two, and the planned budget has been spent, and the planned duration has elapsed, was the produced produce or service "on specification?"

If not, then several things result:

• There is rework
• There is more money needed to complete the product or service
• The features need to be de-featured
• The customer needs to be convinced to take the product or service "as is"

In all cases more money and more time is needed (expect that last one) to get the product or service to the planned level of performance.
    So the Earned Value performance indicators are in fact not showing the actual state of the product or service. It is over budget (more money for rework, repair, or completion) and over schedule (more time needed to rework or repair). Or and this is a subtle outcome that comes home to bite you every time, the undelivered features get pushed into a future release, WITHOUT the associated budget or resources - since these have been spent on the current period of performance (iteration, release, workpackage, what ever).
    This is called mortgaging the future for the failures of today. It's called "we'll make it up in system test." NOT.

In the End Cost, Schedule and Technical Performance are Inseperable
    There are numerous posting, articles, "magic bean" purveyors claiming that the Iron Triangle is dead. Not True, Never was True, Can Not be True.
    If you spend the money, and spend the time, and the result is not 100% what was ordered (or at least within the tolerance of error), then it's going to take more money and or more time, probably both. And most probably this effort and money is unbudgeted and unplanned.
    So what to do?:

• Define what done looks like in units of cost, time, and technical performance
• Ask "how long a, I willing to wait before I find out we're late?"
• Never speak about effort, only speak about measurable results. Never speak about output, only speak about outcomes.

These outcomes and results, must have predefined units of measure for compliance with the planned result. These units must be meaningful to the customer as well.

One Last Comment
    There are some that equate agile burn down charts with Earned Value. This is not correct - unless the burn down charts include cost, schedule, and technical performance. Other than that, the two charts have two coordinates and lines that change shape with the passage of time, so that's the only way they are related.
    This is a popular myth in the agile community for some reason. And has been propagated by several "Thought Leaders," in error. It'd be wonderful if they were related, but they're not. So more work still remains to educate the both communities about the subtle behaviors of Earned Value in the presence of agile discussions.

Agile and Project Management - Again

Dennis Stevens made a recent comment that brings up the old topic of the term "agile" in the same sentence as Project Management - PMBOK still. The 4th Edition of PMBOK is on it way, so we'll have to see how they have approached "agile," inside the context of the 6 Process Groups and 9 Knowledge Areas. Dennis's comment has strong support in the IT community. But it's the other communities that are begining to look in from the outside, asking where their core approach is going?

    At one time I argued vigorously that project management and product development - software development - were inseparable. I've since learned that I was not only wrong, but I had failed to understand the core concept of PMBOK and its application. First though let me state I'm an OK fan of PMBOK 3rd edition. It has some serious missing elements. Risk is poorly developed and the notion of Earned Value too simple for actual use. But these are opinions from the Aerospace and Defense and heavy construction point of view.

    It is in those domains, that I returned to my pre-agile understanding. Having "grown up" in DoD projects in the 1980's, I had lost the connect between Project Controls, Program Management, and Technical Product Development.

    The notion that "agile" as practiced by software developers has a strong connection with the 6 and 9 (processes and knowledge) is flawed. Along with that of course is the flawed notions of the "Theory of PM is Obsolete" paradigm.

    So here's my current position:

1. Project Controls are not Project or Program Management
2. Product Development process, no ,matter how clever, wonderful, or effective, are not project or program management
3. When someone speaks of "agile" in the terms of the Agile Manifesto or the Agile Alliance, they are speaking about product development processes. The 6 and 9 are usually no present, or if they are, the agile processes are "implementations" of some of the 6 and 9.

    So when PMBOK 4th Edition appears here soon, it'll be interesting to see if they have "gone agile." For us here in the defense and government contracting (subcontractors actually), It'll be a dark day when we move away from the Project Controls point of view as the basis of success.

Making Credible Estimates

The art of estimating the cost and schedule aspects of a project a fraught with problems. The primary issue is the belief that estimates are either credible or completely worthless. Both extremes are wrong of course. But a reality check needs to be taken, before understanding how estimates can be put to use.

    Let's start with a simple estimating process. "What will the price of a carton of eggs be in 5 years with a standard error of 15%?" This error value is the difference between a 50% confidence and an 80% confidence. The 80% confidence means you'll have enough money to buy a dozen eggs five years from now, you'll need to put away 15% more than the expected price. 

    So now let's scale this up to a $100M ERP project or a $1B flight avionics system, or something even bigger. The cost growth in many of these programs usually results from optimistic assumptions.

Accept and Control These Variance, Don't Try to Escape from Them

    In most environments risk and uuncertainty are considered bad news. Bad news by the stakeholders. Bad news from the participants. If all the participants fail to acknowledge that things may not proceed as planned, the result is the core of project trouble.

    With the sources from the previous posts, risk and uncertainty must be embedded in the project management process.

$35B to build advanced manufacturing? Too Late!

See the video from the Detroit News on an advanced Ford Plant - in Brazil.

Troubled Projects

A report from the Center for Business Practices, "Troubled projects: project failure or project recovery (2006)," describes the reasons for projects getting into trouble.

• Expectations that are too high, unrealistic, not managed, or poorly communicated. The needed capabilities were not defined in any meaningful way. The missing element was a clear and concise description of the concept of operations. Even in the absence of this, some form of developing this description in an emerging environment was missing.
• Requirements that are unclear, contradictory, ambiguous, or imprecise; or there is a lack of agreement on these requirements. If you don't control the requirements, the project is lost. No matter what anyone says about emergence or what ever "magic beans," controlling the scope of the projects is a critical success factor.
• A lack of resources, resource conflicts, turnover of key resources, or poor resource planning. A resource plan is just a critical as a test plan.
• Planning that is based on insufficient data, missing items, insufficient details, or poor estimates. Bad data means bad decisions.

These are all common reasons described in the report, along with detection criteria, and other common symptoms. The report goes on to describe some methods for "recovering" the project.
    But what happened to get the project in the "troubled state" in the first place? The report suggested that Project Controls were missing, along with some other parts. But the lack of project controls is a common cause of most project failures.
    What does it mean to have "Controls" in place for a project? Controls that can keep the project out of Trouble in the first place?

• Financial performance is visible. This is done through Cost Management and Schedule Management controls. No one works on anything that doesn't have a budget, control account and some kind of cost tracking.
• Scope changes are managed, not just controlled. All cost, schedule, risk, and beneficial outcomes of the requested scope change are made through a "change control" process.
• The planned and actual work effort is visible. While work effort does not mean physical progress, in most project the labor costs account for the majority of the project cost.
• Physical Percent Complete is visible. This means defining the planned incremental progress of the project in some unit of measure meaningful to the participants. Then measuring the progress in ways that assure physical percent complete toward to the goal is being made.
• Quality of the products or services meets the planned levels for the specific phase of the project.
• Maintaining a satisfactory customer perception of the project. This means "keeping the project sold." It is the basis of Customer Satisfaction.

What's A Good Plan Look Like?

Adde parvum parvo magnus acervus erit
Add little to little and there will be a big pile
- Ovid 43 BCE - 17 CE

The notion of "well formed" is lost many times on a program. A well formed system architecture. A well formed Master Plan and Master Schedule. A well formed resource allocation strategy.
    So what are the attributes of "well formed?"

• Referential integrity of all the elements of the Plan. These means the "all in" work can be found and the interconnectivity of this work forms a logical sequence, traceable to the requirements, resource assignment, risk with its mitigation and retirement, and all other attributes of that work.
• Visible increasing maturity of the work products, in units of measure meaningful to the customer. When we speak in units of "done" the conversation is clear and concise. "I'm working real hard," "almost there, just a few more days,"  "I'll have it all organized by the time I get to the power point slides," are not actually measures of physical progress. They may be measures of consumed effort or resources. But not Physical Percent Complete.

So in the end "well formed" needs to be just that "well formed." This starts with the basic thought processes around the development of a "well formed" project, its plans, and its execution.
    There is a nice framework for this, from the professional writing aspects. When a written document is submitted to review, be it a plan, a specification, a Mind Map, or a hand waving white board drawing. It must posses the following three attributes:

1. It must be readable - a high level of "readability" means there are no impediments to understanding what is being described, asked, and required. The information is readily understood by the reader or consumer
2. It must be relevant - the information must be connected to the requested actions.
3. It must be reliable - the data associated with the project plan, execution, and analysis must be reliable if management actions are going to have credible outcomes. Reliability is not hard to recognize when the data is statistical or involves empirical outcomes. When these are not present, it is difficult to assess the reliability of the management suggestions. This is the primary reason for quantitative evaluations of project management processes and their outcomes. Otherwise it becomes anecdotal advice.

Theory is Obsolete and other touchy topics

    I've stepped on toes again with a too-long winded post to Hal's web site on the conjecture that the "Theory of Project Management" is obsolete. I apologize for being a bore.
    This topic hooks me for some reason. I know some of the reasons:

• It's a series of papers used by the agile community as evidence that PMBOK and by implication PMI has a flawed approach - "see this professor in another country even says so."
• It's an anecdotal report presented as a foundational principle. You can actually get a PhD these days by writing about anecdotal observations of human behavioral!

I failed to complete my PhD in physics - "All But Dissertation" is the subtitle of the Masters Degree I received. A real paying job was more important in the late 70's than being a 6 year starving grad student. Looking back, it was the right choice. Along the way I learned to code real time process control systems for the accelerator and learned about the difference between "theory" and "practice."
    Project Management is a practice NOT a profession. Even if PMI wants to call it a profession.  Law and Medicine are professions, with theory behind them. A Professional Structural Engineer or Professional Control Systems Engineer are professions. I was a PE Controls in California before moving to management, so I have some experience in the "Profession" of being a Professional.
    So where's the hook? The Howell, et. al. papers have problems from the eye of a "science guy"

• They describe poor project management practices and associate them with obsolete theory. This is called a Type II error. Bad measurement on the wrong variables that produces a false negative. In fact it is a Type III error, the right answer to the wrong question. The question should have been "why did applying the known to work practices produce an unreliable result?" They are known to work because there are samples of them working in statistically sufficient numbers around the world.
• The anecdotal observations are too small a sample. They also do not have a control group. Several things are missing:

• With a control group and observation you could ask things about the "why" the observed projects did not result in success using the standard processes?
• Was it the process itself or the application of the process
• Since there would be examples of the process working, the larger question would have been - "why does it work some places and not others?" "If the practices don't results in reliable results, what is the cause?" Stating the theory is obsolete is done ad hoc, without examining the underlying casual factors - and eliminating them, being left with only "the theory is obsolete." This is a serious flaw in a paper claiming  to be academically sound (orat least references by those adhering to the same thesis).
• What was the casual effect for it not working? That was never answered. Just skipping the conclusion.

• But reading the papers, I don't see that approach. I see a conjectured thesis and then some observations to support that thesis.

    But this is irrelevant, if it were not for the use of the papers but others to further their points - that PMI and PMBOK are obsolete.
    That's all. That's my heart burn about how Agile Project Management is portrayed. Agile is a proposed alternative to bad project management practices.

Deliverables Based Planningsm

    The notion of managing a project by managing the consumption of funding and resources is  fundamentally flawed. But it is surprisingly common in many business domains. We see it all the time, when asked for a schedule. The schedule shows work activities, connections between these activities. Things like

• Install Oracle database servers
• Develop business requirements
• Test integrated applications
• Conduct User Acceptance Testing

All good activities, but where are the "outcomes" that we can see, touch, compare to our expectations and measure in some tangible verifiable way?
Deliverables Based Planning^sm
This approach to project planning and execute is guided by 10 organizing principles:

Organizing Principle	Beneficial Outcome to the Project
Capabilities Drive System Requirements	Establishing capabilities starts with defining the fundamental ideas about the system through the operational behavior before the technical and process requirements are elicited.
Requirements Identify Technical And Process Deliverables	From each system capability a system requirement can be derived.
Work Packages Describe Production Of Deliverables	Work Packages contain executable tasks that produce deliverables. Work contained in the WP produces a single or small number of deliverables.
Master Schedule Sequences Deliverables, Accomplishments, Criteria, And Work Packages into a Logical Activity Network	Work Packages are arranged in an Activity Network. This network looks like a schedule, but it is a description of the flow of increasing maturity of the product or service resulting from the completion of each WP.
Work Package Progress Is Measured As Physical Percent Complete Against The Planned Progress During the Period of Assessment .	Measuring progress as Physical Percent Complete establishes a credible assessment of the increasing maturity of the product or service.
Work Authorization Assures The Sequence Of Work Packages Produces The Planned Progress	Executing the Work Packages in the agreed on sequence assures the program proceeds as planned.
Earned Value Describes Current Performance	Earned Value is cost based. Cost Variance and Schedule Variance have units of measure in dollars. The To Complete Performance Index (TCPI) and the Independent Estimate At Completion (IEAC) are two measures of progress derived from Earned Value, are also measured in dollars.
Conformance To Technical Performance Measures (TPM) Used to Adjust Earned Value Performance Values	Adjust the “Earned Value” forecast of future performance by the compliance with Technical Performance Measures (TPM). TPMs, when correlated to cost and schedule, provides the complete status of the program.
Performance Feedback From Work Package And Project Level Earned Value Used To Adjust Work Package Sequence, Resource Allocation	With the performance measures and adjustments from Technical Performance compliance, a new Work Packages (WP) sequence may be needed.
New Forecast Of Future Performance Based On TCPI, IEAC, And Adjusted Work Sequence	With the new sequence of Work Packages a new forecast of cost and schedule can be developed. This forecast must be based on the To Complete Performance Index and the Independent Estimate At Complete.

These principles replace the effort based planning styles common in IT projects. And replace them with measurable outcomes as the only evidence of progress.

Project Management Quotes

One of our Program Planning and Controls staff (supply chain management) went to a seminar and came back with lots of information. Three quotes struck a cord with me:

• Be creative. Focus on possibilities, not limitations - this one is for all the holders of "magic beans" trying to convince us they have a solution for all the identified problems in PMBOK
• You must be willing to take the 1^st step without knowing any of the others - define the next incremental deliverable, keep the project moving forward. Have an end vision, but focus on tangible outcomes.
• Knowing how to do a thing never accomplished anything. Knowing why causes it to happen - quoting chapter and verse the rules of the road, the reasons the rules of the road don't work, and all the reasons the fundamentals are obsolete, gets us no where fast.

And a resurrected quote from the long past:

Adde parvum parvo magnus acervus erit - Ovid (see I was paying attention in Latin class). "Add little to little and there will be a big pile" - Ovid 43 BCE - 17 CE

PMBOK, Agile and the need for Theory

    A popular starting point for the criticism of PMBOK and PMI is a series of papers by Koskela and Howell stating "the theory of project management is obsolete." These can be found on Google using Lauri Koskela, Greg Howell, and obsolete. While the ideas presented there are provocative, they are also useful for asking questions about project management from an external point of view. The thesis is well reasoned (except for some flawed assumptions). But these paper have been raised to near cult status by the agile community, in the absence of the construction context and the flaws of some of the assumptions.
    Sometimes quoted directly without having been read. Sometimes quoted out of context. But most times treated as gospel. One slight flaw in this approach is that the papers were not peer reviewed in the sense of a scientific journal, but are treated as such. I say this from the highly biased and narrow minded view of one trained as a physicist and having experience in the peer review process.
    All of this started today with Hal Macomber's site referencing a posting on Project Times. These triggered a response I've been meaning to make for some time now. And it goes like this.

===========================================================================

    Care must be taken with the Koskela papers. Not that they don't have value, because in the market place of ideas, they are certainly of value, well reasoned and somewhat well written - although the thread of the thesis gets lost in rhetoric at times. But it must be understood, at their heart they are  criticisms of PMBOK in the context of construction and as such are biased in ways not always understood by the causal reader. As well specific assumptions have been made that are incorrect in some instances. While PMI likely overstepped its capabilities when claiming Project Management is a profession, Koskela then amplified this to mean there must be a theoretical basis of project management as his thesis.
    This approach is likely flawed, since the conjecture of project management as a profession by PMI is itself flawed. All could have ended there, but Koskela continued on (as do several critics of PMI) to build on this “house of sand.” Too bad, since there are useful elements of PMBOK that have no need to be “tossed out with the bathwater.”
    One flawed Koskela approach is the rewriting of PMBOK's description of projects to a "production" point of view. Once that has occurred, Koskela argues that PMBOK is not appropriate. This is circular logic at best and a tautology at worse. While there are legitimate criticisms of PMBOK 3rd edition, the PMBOK for Construction and the PMI College of Scheduling Guidebook (heavy construction focus) address some issues Koskela brings up in what is now an "aging" paper.
    A second is Koskela’s use of the thermostatic control analogy for "feedback." This control loop algorithm is a simple but effective approach to controlling an “on/off” process. Koskela wants us to accept that PMBOK suggest a thermostatic approach is recommended. This is simply not the case, but Koskela continues to argue the failings of this non-recommended approach.
    In fact Chapter 6 of PMBOK 3^rd edition has four activities in Schedule Control: 1) Determining the current status of the project schedule, 2) Influencing the factors that create schedule changes, 3) Determining that the projects schedule has changed, and 4) Managing the actual changes as they occur. PMBOK 3^rd edition states (in the context of how the Process Groups interact) “The Monitoring and Controlling Process Group must provide feedback to implement corrective actions to bring the project into compliance with the project management plan or to appropriately modify the project management plan.” Feedback is required and stated as such in numerous locations in PMBOK 3^rd Edition.
    These, like all PMBOK elements, are activities that should to be performed during the management of a project. “How” they are performed is left to the execution side of project management.
    Koskela's conjecture that the sampling period for feedback is poorly defined in PMBOK is correct. This needs to be replaced with an understanding that PMBOK does not specify the sampling period for the feedback - just that "control" is needed. While the criticism may be appropriate, the term "obsolete" is likely overstated. A simple survey of any control system book reveals many algorithms for fine grained control appropriate for project management. Even feed forward algorithms like “earned schedule” and Monte Carlo Simulation based analysis tools. And since PMBOK does not specify the algorithm, substituting one of those solves the problem without using the term obsolete.
    As we all know Agile defines this feedback in 2 to 4 week intervals, and in some instances feedback is provided daily in XP shops for software development. Many large government contractors define the feedback period to not more than one accounting period (45 days). For alternative guidance beyond PMBOK in Defense, look to DID81650, DFAR, DOD PMBOK, Part 2.B.3 of DoD Acquisition Strategy, DFARS 252.242-7001 and other for specific “execution” instructions from DOD in the Acquisition Guide.
    Applying directly Koskela's paper to software development is a popular but sporty business. As well, care must be taken in applying PMBOK to the “production” phase of a project, especially in construction. Execution in construction is not execution in software or execution in operations of a manned space flight mission or even the avionics systems for the spacecraft. I am deeply familiar with all of these domains and it would be dangerous to apply PMBOK in the absence of experience or consideration of the actual activities on the project. PMBOK is “A” guide and even then an introductory guide. But obsolete? Koskela’s thesis is unsubstantiated at best and a thinly disguised sales tool for Last Planner at worse. Not a problem; everyone has to make a living  But using Koskela as a reference academic paper – as has become popular in the agile community – is troubling for those like me with a academic background.
    No one in Defense sees the role of PMBOK to state HOW to execute the project – although increased advice would be helpful at times. Nor do they see it as “obsolete,” – just a starting point – possibly naïve at times. Adding value to PMBOK is the result in DoD PMBOK.
    The sport of PMBOK and PMI bashing seems to be unique to Agile. It is time to mature Agile execution and ask how to increase the probability of success (P(s) is an official notion in defense program management), and build on the foundation of the Knowledge Areas and Process Groups – all of which should (must) be present in some form for project success.

What is Project Management?

The discussion of how PMBOK and Agile are related needs to go back to some fundamental principles before starting down the path of discussion.
    The first question is "what is project management?" Is Project Management the same as software development? A similar question would be "Is Project Management the same as Mechanical Design and Fabrication?" Bending metal into money? Probably not, would be a likely answer.
    So what is Project Management? Let's look at elements of project management. There are several collections of project management elements, some credible, some simply silly. How about starting with a list of the elements from an organization that claims to have something to say about managing projects. The Project Management Institute (PMI).
    PMI lists 6 Process Groups and 9 Knowledge Areas in it Guide to the Project Management Body of Knowledge. First look at the title, this is a "GUIDE" not a method. Also PMBOK is the sum of knowledge within the profession of project management. It is "A" Guide, not "THE" Guide. So anyone - and there are many - who confuse PMBOK with a method should take another look at Page 3 of PMBOK. You do have PMBOK on your bookshelf right?
    So with PMBOK here are the Knowledge Areas and Process Groups arranged in a logical relationship.

It might be held that these are the elements of Project Management. If so, then any project management method needs to have some relationship with these elements, in some way. This relationship may be minimal. Or it might be strong. If there is no relationship between the proposed project management "METHOD" and these Knowledge and Processes, one would hope to have a good reason for the missing or added method step.
    So this is the start and I hope not the end of the discussion of the differences between Process and Method.

    More to come ...

But First Some Test Questions

    If you had a "project management method," say "Agile Project Management," or "Magic Beans Project Management," woudl it have some relationship to the elements here?

    No? Why not?

PMBOK(r) and Agile - Round 2

PM Bistro has a new post on Agile and PMBOK(r), referencing a post I made last year. As I've mentioned more work is needed. This includes gaining, sharing and confirming an understanding that:

• PMBOK is a description of work processes, not a software development or project management methodology.
• The presence or absence of PMBOK processes is not an option in the beginning. All process are necessary in some form. I did not used to believe this, but now I do. The school of hard knocks is a good teacher.
• Agile is software development work processes. The notion of Agile Project Management in the absence of PMBOK process groups and knowledge areas is an oxymoron.
• Joining agile and PMBOK means just that: A matrix with PMBOK and Agile (rows and columns) and checks marks where they are "joined." Without this as a starting point, its just hand waving and rhetoric about how they can share the same space.

Mike Griffith's paper is interesting. Yes PMBOK promotes Planning, just as Scrum does. Planing is Project Management. A Tautology. But Mike misses the mark as well. The 9 Knowledge Areas - where the action takes place in project management are missing

Michele Slinger connects the wrong things. She connects Process Groups. What is needed is the Knowledge Areas. Process Groups are too vague. You can be washing machines, software or Joint Strike Fighter's without ever discovering any differences in the processes.

The next step is to recreate the work Mike Dwyer did a few years ago. It's somewhere on Sharepoint, I just have to find it.

Bechtel Project Management Videos

    Bechtel Corporation has a series of videos (via PMForum) on its site about its projects and their management.
The range of work under the title "project management" ranges for activities like these, to building and flying the 787 or the Orion Spacecraft (my connection) to self-actualizing interpersonal activities labeled "projects communities."
    I personally relate better to the Bechtel style projects, where something tangible, measurable, and quantitative results. If along the way people become aware of new concepts about themselves, all the better.

PMI Global Congress Books

At the PMI Global Congress, there is a book store. I love book stores, being the son of a University Librarian. I bought several books that I would not have normally bought:

• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hillson, Taylor and Francis, 2004.
• Pivot Table Data Crunching for Microsoft Office Excel 2007, Bill Jelen and Michael Alexander, Que, 2007.
• Earned Value Project Management, 3rd Edition, Quentin Fleming and Joel Koppelman

Effective Opportunity Management
Most risk books have risk in the title. David's book is about managing opportunity while managing risk. While this is still a controversial topic the conversation about opportunity and risk is starting to emerge. The Edmond Conrow article "Opportunity Management: Be Careful What You Wish For," is the primary source for not connecting risk and opportunity.

Pivot Table Data Crunching for Microsoft Office Excel 2007
Most of the data found in project management is multidimensional. In fact when I come across single dimensional (rows and columns) of data, it usually means the too much summarization has been done. An example of multidimensional would be:

• Named Resource, with hours for the period of performance
• Work Package for the period and the BCWS spreads
• Period of Performance
• Deliverables and their physical percent complete

Now build a report that shows the labor cost and associated hours for each deliverable by each work package. This is the job of a pivot table.

Earned Value Project Management
    The 3rd edition has switched to the "story telling" mode, which I don't like. In fact I find it not very useful. This is a personal issue, since in my heart of hearts I'm a quant. This is why I was an experimentalist in my very days, before I went to the real dark side, writing Kalman filters for missile guidance systems. Kalman filters are "target tracking" algorithms using position and velocity measures in realtime. But EV 3rd edition is a good starting point for those entering the EV domain. That's likely they changed the style. Since EV still has many detractors, many who misuse it, many who misstate its purpose, and many who are simply uninformed - this book is a great value.
    All three books are in use. I'm wading through Hillman's work and will write a review. It sits next to Conrow's Effective Risk Management, and is of equal obtuseness. But obtusness with deep content is usually call important in my domain.
    By the way, it's the obtuse without the deep and executable content that is common these days in the project management Impresario writings.

Top 10 Reasons not to do Project Management

Jim Chapman's site provides many resources for project managers. My favorite is the Top 10 Reasons Not to Use Project Management. There are many other principles there. Some are simple restatments of the obvious - but so often overlooked. Others are good rules of the road -  so often not followed. All good stuff, if only as a reminder that management projects is a profession

The Top 10 Reasons are restated here, with some slight edits with permission from Jim's site. (in David Letterman style)

10. Our customers really love us, so they don't care if our products are late and don't work.
9. Organizing to manage projects isn't compatible with our culture, and the last thing we need around this place is change.
8. All our projects are easy, and they don't have cost, schedule, and technical risks anyway.
7. We aren't smart enough to implement project management without stifling creativity and offending our technical geniuses.
6. We might have to understand our customers' requirements and document a lot of stuff, and that is such a bother.
5. Project management requires integrity and courage, so they would have to pay me extra.
4. Our bosses won't provide the support needed for project management; they want us to get better results through magic.
3. We'd have to apply project management blindly to all projects regardless of size and complexity, and that would be stupid.
2. I know there is a well-developed project management body of knowledge, but I can't find it under this mess on my desk.
1. We figure it's more profitable to have 50% overruns than to spend 10% on project management to fix them.

These may sound silly, but in fact they are all too common. Especially when the project Impresarios get into the act.

• We don't need Critical Path Analysis, because the Critical Path is changing all the time anyway
• PERT - never use it, it's for 1950's submarine projects. Besides I read a paper once that claimed PERT is wrong
• Risk Management - too much work. We'll deal with risks when they appear.
• Master Plan - planning is way overrated. Let's let the customer tell us what to do and we'll adapt to the emerging requirements as they emerge.
• Team Direction - naw, we're here for our our self actualization. Following the plan and provided measure able value from my actionable outcomes is way over rated.