The Regenerate Web

    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.

    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 Planningsm
This approach to project planning and execute is guided by 10 organizing principles:

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

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 1st 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:

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

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?

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.

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)

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.

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.

    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.

    I'm not a PMP. I'd like to, but I'm not motivated. Besides, I'd have to unlearn several things in order to pass the PMP.
    BUT, there is a PMI-RMP that I've signed up for. And there is the PMI-SP, the Scheduling Professional. Both I could get into. But the Risk Management Certification will be the first. Chapter 11 of PMBOK is about risk management. There are a few flaws in Chapter 11. Multiplying probability of occurrence with outcome to get a risk rank is one problem. The two variables are probability distributions and multiplication is not an operator on an integral equation representing the probability distributon function.
    The second issue is the Department of Defense has a Risk Management Work Flow. PMI has process areas. These areas have a linear relationship and a single feed back loop. The DoD PMBOK version has all the same chapters, but much correct guidanmce in many areas. It's also FREE. DOD PMBOK Chapter 11 has a diagram showing the process flow and has words around how to develop a "risk value" that does not involve doing un-allowed mathematics.
    So I've bought the study guide, reading the PMBOK Chapter 11 again and this time making notes and filled out my application. Maybe by the end of the year I'll be a Certified Risk Manager.

    I've been watching (and even helping out with advice) on several projects close up in the past weeks. They have "issues" as all projects do. But one thing that strikes me in these cases as well as a side bar discussion with a project management impresario is there is a lot of professional amateurs out there. Those claiming to have "magic beans," when in fact the beans are just beans.
    There are some simple questions a project manager should be asking everyday:

1. When will this project be done? And what's the confidence interval on that date?
2. How much will it cost? And what's the confidence interval on that value?
3. Do we all agree on what "done" looks like when we get there? And what are the units of measure of "done?"
4. What are the risks to getting done on time and on schedule?
5. How will we mitigate or retire these risks so we can get "done?" And do these activities have budget and schedule?

Now when that project management impresario starts talking psycho-babble about the theory of how projects "should" work in his "best selling" book - self actualized staff, acknowledging your blindness and topics best reserved for the marriage therapist office, there never seems to be a discussion about the 5 items above as prerequisites to a project's success?

1. We're self actualized - but late and over budget
2. We acknowledge the things we don't know about - but are late and over budget
3. We have great trust in each other and our vendors - but are late and over budget

    Not being late and over budget is necessary but not sufficient for project success. But the inverse makes no sense.  It's not a reciprocal relationship.
    Project Management is not Business Management.
    Project Management is not Personnel Management.
    Project Management is not ...

    Project Management is about managing projects. Yes there are people involved and people must be considered. But this focus on "people" cannot add value if we're late and over budget.
    Both are needed, but which one is more important? I have my choice. Others have theirs. The customer - from all my limited experience in the past 30 years - has been asking the 5 questions above before they ask about self-actualization and self-fulfillment. Just a data point, that's all.