PM Hut has a post on Managing By Exception. While the concepts posted there are good in "principle," in "practice" more needs to be in place to keep the project on track.

First there needs to be a set of clearly defined assessments of physical percent complete. Along with that some means of assessing the increasing maturity of the products or services produced by the project. And of course some type of "exit criteria" for each Unit of Work produced by the efforts of the project team. Finally, a means of identifying, handling, and reporting the risks to the progress of the project.

In the absence of this information, there is no raw material available to assess the exceptions. Only when the Plan, Schedule, Risks, and Measurement processes are in place, can the exceptions be determined. Having the Project Manager track and reviews but does not intervene only works if the "control boundaries" are defined in units of measure meaningful to the stakeholders.

As well the statement that "Management By Exception" is a relatively new concept is likely not correct, unless "new" means defined in the last 100 years. MBE is the basis of military command and control for small unit engagement. It was applied in the aerospace business in the late 70's.

There's a new definition of PM 2.0

Project Management 2.0 is an approach to managing projects that is brought to life by the use of Web-based, emergent, collaborative project management software and that focuses on collective intelligence, productivity and project leadership as the basic factors of project success.

Ignoring for the moment if you took out the Web 2.0 words, this would a good description of any modern PM method. So let's look at the product offerings of some mainstream players and test then against the PM 2.0 definition.

• Safran North America
• DelTek
• Oracle Primaveria
• SAP / Dassian
• Microsoft Enterprise Project Management
• A bunch of SharePoint MOSS add ons for Microsoft Project like EPM Solutions

With the new PM 2.0 definition and these tools we see they are for the most part web based - all of which I have hands on experience with in a variety of business domains. They have attributes in common with PM 2.0, if you look at the Wikipedia definition of Web 2.0

The term "Web 2.0" is commonly associated with web applications which facilitate interactive information sharing, interoperability, user-centered design[1] and collaboration on the World Wide Web. Examples of Web 2.0 include web-based communities, hosted services, web applications, social-networking sites, video-sharing sites, wikis, blogs, mashups and folksonomies. A Web 2.0 site allows its users to interact with other users or to change website content, in contrast to non-interactive websites where users are limited to the passive viewing of information that is provided to them.

Each of these firms in the list above would say they have Web 2.0 offerings,per the definition above - especially MSFT. Some actually have it more than others of course. But the PM 2.0 attributes like...

• Web based, yep all are web based for the simple reason that Fat Client are too expensive
• Emergent "something"
• Collaborative project management
• Focused on collective intelligence
• Productivity (who doesn't have that in 2009 offerings)
• Project leadership, what ever the units of measure that is

...are stated to be the basic factors of project success.

If it is true that the items above are the basics of the success  of a project, then is it likely everyone should toss out PMBOK, the DoD Probability of Project Success guidelines for each service, all the Earned Value Management Systems Descriptions, all the IMP/IMS guidance in the Federal government (DID 81650 for example), all the project management process handbooks developed from CMMI-DEV 1.2, NQA-1 (nukes), the DOE 413.3 series (DOE capital construction and operations), all the risk management guides, SOX, ITIL... OK, you get the point.

The items listed above as the basic of project success are NOT, I repeat NOT, the basic factors for project success. That is utter nonsense. Forget the "no moral motivation" argument. This conjecture follows Wolfgang Pauli's statement about a paper submitted to him for review by a physics student.

This is not only wrong, this is not even right

OK I'll give the PM 2.0 people the last one - leadership. Oh all right, collaborative behaviors in project management is critical. But behaviors don't need fancy tools, just collaborative people. Which by the way are explicitly called out in PMBOK and every government agencies PM handbook.

Here's a book chapter that "may" shed some light on the basics of project management in the context of "agile." Figure 1. is one of many taxonomies of the elements of project activities required for project success. Figure 2. is a recent survey of the primary sources of failure in software projects. And Figure 4. is Capers Jones' software taxonomy. So what is the PM 2.0 sweet stop?

Just to round this off, here's a survey from Marios Alexandrou on project management methods. Some should be considered software development methods, but for sake of argument, let's consider than all PM methods for the moment:

• Adaptive Project Framework
• Agile Software Development
  
• Crystal Methods
• Dynamic Systems Development Model (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Information Technology Infrastructure Library (ITIL)
• Joint Application Development (JAD)
• Lean Development (LD)
• PRINCE2
• Rapid Application Development (RAD)
• Rational Unified Process (RUP)
• Scrum
• Spiral
• Systems Development Life Cycle (SDLC)
• TenStep Project Management Process
• Waterfall (a.k.a. Traditional)

So now if we connect the project management methods, the Knowledge Areas and Process Groups from PMBOK, with the project management tools, we get a nice dense matrix. In this constructed matrix I'm hard pressed to see how the attributes listed above for PM 2.0 have much to say about "increasing the probability of project success." Which by the way has a specific definition in the context of large projects.

If anyone can connect the dots for me, I am my PM 1.0 colleagues will be humbled to learn what we're missing out on in the PM 2.0 paradigm.

PM Hut has a post about "lazy management." The idea that the PM reads the morning paper, chats at the coffee machine and generally "hangs around" watching people work is likely VERY domain and context sensitive.

I would be dumb struck to see the project manager for the recent I-25 rebuild by Kiewet Construction. Or the project manager for Building 777 at Rocky Flats, or the project manager for a $170M ERP integration at a health insurance company. Or the best example of the Program Manager for the major manned space flight program.

On those programs, the PM is not "running around with her hair on fire," but it is unlikely there is a spare minute in the day. As well the alternative is not to micromanage the work of others. Instead all project participates "execute the plan," in a manner appropriate for the scope and critically of the project. The more critical the project, flying to the moon, the more likely everyone is running at 110%.

If the project is a casual endeavor, then "lazy management," may be the norm. The notion of "managing" the project at the people level by the direct contact is also unlikely in critical projects. The work management is done through "work packages," with defined deliverables, measures of performance, and risk adjusted costs and schedule.

So where is "lazy project management" appropriate? Good question?

When two opposite points of view are expressed with equal intensity, the truth does not necessarily lie exactly halfway between them. It is possible for one side to be simply wrong.

— Richard Dawkins, evolutionary biologist

Josh Nankivel is interviewed by a student from Help University College in Malaysia. One of Josh's statements rang a bell for me.

"What is the greatest challenge for you as a Project Manager?"

Josh said,

"The specifics depend on individual projects and their environment. In general, the greatest challenge is ensuring clarity of “what, when, who, why, and how” for everyone, including the customer, project sponsor, team members, and all external and internal stakeholders. Most project failures in my experience stem from a failure to do this."

This list of "questions" is from the Kipling Poem, The Elephants Child.

The answers to these questions must come from processes executed during the project. Here's my take on what those processes must be, taken from our process handbook.

There are 5 process areas used to answer the questions. 

Identify Needed Capabilities

Define the set of capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. The ConOps (Concept of Operations) is a description of how the resulting product, system, or service will be used from the Point of View of the "customer." 

Establish the Requiremnets Baseline

Define the technical and operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology.

Establish the Performance Measurement Baseline

Build a time–phased network of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan.

Execute the Performance Measurement Baseline

Execute work packages, while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements.

Perform Continuous Risk Management

Perform the 6 process areas of Continuous Risk Management for each Deliverables Based Planningsm process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.

At the highest level, these are the immutable processes needed to answer the Six Questions. This is a list of the "one true method" for managing projects, in the same way the Six Honest Serving Men, were Kipling's "one true method" for gathering the news while employed as a reporter in India.

There is more to managing projects than this of course. Along with the 9 Knowledge Areas and 6 Process Groups of PMBOK, any proposed project management method must address in some way, these items. In the same way as being a reporter is more than asking and answering Kipling's question.

In the end if you are not guided by these questions, the results will be disappointing to everyone, you, the customer, the stakeholders, and most importantly your ability to grow as a project manager.

A graceful taunt is worth a thousand insults
Louis Nizer, 20^th century trial lawyer

Andrew Filev asked on his Blog awhile back, "what Project Management books should you read?" This is a good question for all project managers. But I have difficulty with the books he listed. Which may be my same difficulty with grasping the notion of PM 2.0 paradigm. 

His first "book" PMBOK^® is not a "book" about project management in the sense of the books listed below. The PMBOK^® speaks its name. It is a Guide to the Project Management Body of Knowledge. The Knowledge Areas (Integration, Scope, Time, Cost, Quality, HR, Communications, Risk, and Procurement) and Process Groups (Initiating, Planning, Executing, Monitoring and Controlling, and Closing) in PMBOK^® provide a framework for managing projects. Which by the way, if you're not doing these knowledge areas and process groups in some way, you're not doing project management. You might be doing something else, developing code, collecting "to do lists" in your email, chatting with colleagues on IM and Twitter. 

So first of all, please do not use PMBOK^® as a starting place for learning about project management. PMBOK^® is a framework assessment book. 

Here's what's on my self that I use for our practice of Program and Project Management and Program Planning and Controls.

• The Management of Projects, Peter W. G. Morris, Thomas Telford, London, 1997. You can get this book from Amazon UK or sometimes from Amazon US
• AntiPatterns in Project Management, William Brown, Skip McCormick, and Scott Thomas, John Wiley and Sons, 2000. They have other AntiPattern books as well. Although Patterns and AntiPatterns have good out of favor in the ADD world of WEB 2.0, knowing these AntiPatterns will allow you to resist the siren song of IM, Twitter, and email as a replacement for good project management processes defined in PMBOK^®.
• Modelling Complex Projects, Terry Williams, John Wiley & Sons, 2002. All nontrivial projects are complex in some way. All attempts to simplify complex projects usually fail in some spectacular way. Dr. Williams book explains how this happens and how to avoid it.
• Software Project Management, Walker Royce, Addison Wesley, 1998. This book is getting a bit long in the tooth, but still has lots of good advice for enterprise class software development projects. This Royce is the son of Winston Royce of TRW, who's paper on Water Fall is the mots misinterpreted piece of writing in all of software development. I worked in the same build as Royce and Boehm (O6, TRW, One Space Park, Redondo Beach, CA) in the hey days of software development methodologies. 
• Managing Agile Projects, Edited by Kevin Aguanno, Multi-Media Publications, 2004. This is a good survey of how to manage "agile" projects. It is not an agile "project management" book. There is a dramatic difference between the two. Without knowing the difference you fall victim to the belief that agile software development is the same as project management.
• Catastrophic Disentanglement: Getting Software Projects Back On Track, E. M. Bennatan, Addison Wesley, 2006. This is one of the paradigm changing books. Bennatan provides a step-by-step process for rescuing software projects from the brink. Again a software project management book, not a book about software development.
• Agile Project Management, Jim Highsmith, Addison Wesley, 2004. I run hot and cold on Highsmith. I'm back, now that the hype around "agile project management" has died down. 
• Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation: Aaron Shenhar and Dov Dvir, Harvard Business School Press, 2007. This is one of the best books for corporate IT project management. I share writing duties with Dr. Shenhar in the newsletter PM Weekly Insights.
• IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne Ross, Harvard Business School Press, 2004. The concept of "decision rights" is completely lost on many in the project management world. Who gets to decide is a governance question. When "all" get to decide and anyone gets to decide, the results is usually chaos at the enterprise IT level.

There are books you need that don't have Project Management in the title. These books are about the processes underlying the management of projects.

• Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund Conrow, AIAA Press, 2003. Ed worked on the proposal for the Crew Exploration Vehicle (now called Orion). Ed and this book changed completely my view of programmatic and technical risk management.
• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hilson, Taylor Francis, 2004. While the notion of "positive risk" is counter intuitive and cautioned against by Ed Conrow, this book is a good survey of the concept of exploiting opportunities in projects. This is applicable during the early stages of development where change has less cost.
• Performance Based Earned Value^®, Paul Solomon and Ralph Young, John Wiley & Sons, 2007. If you want to learn how to do Earned Value right, this is the book. The "iron triangle" for modern projects is Cost, Schedule, and Technical Performance. Paul's book shows you why and how to put this concept to work. Paul is retired from Northrup Grumman where he lead the EV activities for the B-2.
• The Art of Systems Architecting, 2nd Edition, Mark Maier and Eberhardt Rechtin, CRC Press. Rechtin, is the retired president Emeritus of Aerospace Corporation, an arctitect-engineering firm specializing in space systems for the US Government. Aerospace Corporate "invented" GPS.
• The Requirements Engieering Handbook, Ralph Young, Artech House, 2004. You can't have project management without requirements management.

Yes I have the Collins book as well. It's getting less interest these days as the data from book is not holding up in practice. But sill good core ideas.

One final book The Story of Managing Project: An Interdisciplinary Approach, Elias Carayannis, Young Hoon Kwak, and Frank Anbari, Praeger, 2005. This is a survey of a broad range of project management practices in a variety of industries. My chapter "Agile Project Management Methods for IT Projects," starts on page 324.

This isn't right. It's not even wrong!
Das ist nicht nur nicht richtig, es ist nicht einmal falsch!
— Wolfgang Pauli, called Pauli's proverb, in a comment about a student's paper

The use of well meaning principles, based on current understanding of the problem at hand can still result in falsehoods and fallacies. For example, Earned Value is only good for government contracts, or emergent requirements reduce risk, or maybe "we don't need to or even want to know the cost of the project because we have unlimited budget."

"When people thought the earth was flat, they were wrong. When people thought the earth was spherical, they were wrong. But if you think that thinking the earth is spherical is just as wrong as thinking the earth is flat, then your view is wronger than both of them put together."— Asimov's axiom, well stated in his book The Relativity of Wrong (Doubleday, 1988).

This is a common problem when the discussion turns the new or replacements for the principles of project management. A recent post asked is there one true way for managing projects? I answered "yes there is."

• What capabilities are needed to fulfill the business goals or mission?
• What are the technical and operational requirements needed to produce these capabilities?
• What work activities, the order of these activities, the risks that impede these activities, and the mitigations and retirements to remove these impediments?
• What are measures of physical percent complete that show we are making progress toward done, by producing the technical and operational requirements that continue to fulfill the capabilities?

If you have a proposed project management approach, a tool that supports project management, any theory about project management and it does not answer, contribute to the answer of these questions.

This isn't right, it's not even wrong

I've been invited to join an esteemed group on Weekly PM Insights hosted by Raymond Posch to speak about programmatic risk. 

The authors include:

• Hal Macomber
• Michael Greer
• Elizabeth Harrin 
• Bob Hartman 
• Lee Lambert 
• Aaron Shenhar 
• Bill Stewart 
• Martin VanDerSchouw

I know Hal personally and have corresponded with Elizabeth.  I look forward to meeting the other authors as the newsletter and web site grows.

My contribution is focused on programmatic risk and the process of managing this risk, guided by the DoD, DOE, and Software Engineering Institute's frameworks. This material will be practical in nature, based on the principles of the three guiding organization, but practiced on actual aerospace, defense, and Energy Department programs.

So just a reminder of the starting point for all risk management is the framework from the US Department of Defense.

There are other frameworks, even one from PMI. But all miss one or more aspects of the risk management processes needed to establish a credible Risk Management Plan (RMP).

OK, a diversion from the heavy lifting of managing programs.

There are two rides, spring and fall, in Moab Utah for the Lance Armstrong foundation. Most years there are celebrity riders. I never get to ride with them, because our over 50 and over 60 group gets dropped on the first big climb to the "Big Nasty." The Big Nasty is 3,000 feet gain in 7 miles. Now that doesn't sound too bad for a seasoned Colorado road rider. But there are two along flat sections in there before reaching the summit. Take those out and its something like 3,000 feet in 5 miles and that makes it 9% to 11% grade while climbing. The route got it's name on the first year, when an organize asked some of the first riders up "how was that?" The answer was "that was nasty!"

Here's an outtake of an award ceremony from the Moab Century. Bob Roll was a pro rider in Europe and commentator for VS Tour de France.

The current edition of Aviation Week & Space Technology has an article titled "Help Wanted: Good program management starts at the top, which could be the  industry's problem."

The crux of the article is we've lost the leadership focus on the programmatic aspects of programs for a variety of reasons.

The question (of program success) does not come down to technology or even money, but the ability by industry and its government customer to lead and deliver on their promise. 

This problem is not unique to aerospace and defense. It is common in the commercial side of projects as well. 

According to a yearlong industry review, hosted by AW&ST and culminating in a conference here this month (Phoenix), industry leader believe they have made real progress in implementing best practices - but getting people and programs to follow them thoroughly and consistently remains the greatest shortfall.

One of the key challenges in our industry of PROGRAM MANAGEMENT (my emphasis).

The group, lead by Price Waterhouse Coppers (PwC) says the first step in improving performance is by building "objective and honest" assessment of the current state of industry's program management. The ... good planning, discipline, and communication within the projects...

To create the proper management structure to support program execution...with facets of strategy, risk, cost, budgets, planning, task schedules and technical milestones are integrated. Program managers are ... proactive in managing change...

The A&D partner at PwC said...

We believe that the aerospace and defense industry must be proactive in elevating its program management effectiveness, adopting balanced framework to mitigate or control risks and to cushion the impact when the customer requirements change.

Now let's ask some hard questions about project management

• Do the projects you work as a project manager have a disciplined approach to cost, budget, planning, task schedules and technical milestones?
• Do the projects you work elevate the project management effectiveness, adopting a balanced frameworks to mitigate or control risk and soften the blow when requirements change?

Why do do many projects not have control controls or even the rudimentary notion of budgeting? From some of the comments here lately, it seems many projects operate in the dark ages and are happy to continue to do so because, "it will frighten the developers."

Failure is a self-fulling prophecy, an unavoidable consequence of the tolerance - or even encouragement of the idea that full management engagement in cost, schedule, and technical performance measurement is simply too much work, too much "management," too much governance.

The concept is interesting and well formed, but in order to earn better than a "C," the idea must be feasible

— a professor of management at Yale University, commenting on a term paper by Fred Smith that outlined a plan for a reliable overnight delivery service — FedEx

One of the five process areas of our program management method is "Capabilities Planning." Here's a small picture of a moderately complex topic. In the same style of asking the Five Questions, these question need answers if you want to have any hope of being successful.
I get questions (outside the defense business) about "what do you mean when you say capabilities." Most everyone in commercial and defense gets the idea of requirements, the need for a master cost and schedule to fulfill those requirements, the actual running of that plan during execution, and of course the continuous risk management needed to keep everyone and everything moving in the right direction.

Well OK, not most everyone, otherwise we wouldn't have all those projects in the ditch upside down with their wheels spinning would we.

But capabilities is not always obvious. This week the Defense A&R Journal arrived while I was on the road.

Joint Acquisition Command Doctrine: A Success Story is a good example of Capabilities thinking. There was a comment from "Chart" (who never uses his - or her - real name and has a gmail address) about managing global integration projects. The concepts in this article can be applied to very large programs. Those project where the processes used for smaller project always seem to fail - those seemingly impossible ERP projects that every talks about.

1. Treat global ERP projects like a military campaign - planning in depth is the watch word for military processes. Have a Plan B and a Plan C. Have a plan for everything that can go wrong. Have a plan for this you don;t even know about, that can go wrong. This is he definition of "planning in depth." This is called "managing in the presence of uncertainty." It is the opposite of "trying to manage uncertainty," which is the common red herring of the uninformed project manager who rails against having a plan and a schedule - oh yea and knowing the cost  of things - just couldn't resist.
2. Defined the needed capabilities first. Only then ask what requirements are needed at what time during the program to produce those capabilities. If you start with requirements you'll simply create a huge mess, follow every bunny down the rabbit hole, have no way to tie requirements with benefits and ask that dreaded question that's been floating around from the last couple of posts - "how can I connect the cost of this project with the value delivered by the outcomes. If anyone here still has any doubts about why you absolutely must have some understanding of a projects (program) cost no matter what you're doing this is the reason.
3. Build full traceability between capabilities, requirements, and the work packages that deliver those requirements. Then establish a Performance Management Baseline and actually "manage" the project.
4. Manage everything as a Risk Manager. Use Tim Lister's quote - Risk Management is How Adults Manage Projects. Along with the related quote - "what's the difference between this place and the boy scouts?" "The boy scouts have adult supervision."

Brian Kennemer has extensively commented on the PM 2.0 post of his experience of including cost in number in projects he is familiar with. This trigger my thinking on what the real problem is with many IT projects.

It comes down to a fundamental principle of any business, from running IT maintenance to flying to low earth orbit with 3 astronauts on board.

This is fundamental to every activity of every business process, including IT. It is also a fundamental failure mode of many IT departments.

When a CIO is asked "why are you here and why should I keep you here?" The answer better be, "because I provide X$'s of value contribution to this organization."

Andrew Filev and Dave Nicolette both have a nice posts on the motivation - or lack - for Enterprise 2.0 and agile in the case of Dave. Slide 7 of Andrew's presentation asks an important question:

If E 2.0 is user driven by users, then why is there so much fuss about adoption problem?

The answer is corporate and IT governance. When there is non formal governance process, then adoption is a self regulated process. In the presence of corporate and IT Governance, self adaptation is unlikely and in fact undesirable.

Self adoption is "all about me or us." Governance based adoption is all about the corporation and its business governance process - not about the well being of individuals and their desires to have the latest tools. This is cold and crass.

Put your self in the seat of a major stock holder.

"The programmers have run amuck again and are adopting this crazy thing called agile. Minimumal documentation, emergent features, little or no management or the associated direct accountability, and my favorite from a recent commenter - 'Budgets, we don't need no stink'in budgets.'"

The corporate guy says, "We can't let this happen we need Governance policies."

This is an exaggeration of course, but I know it's what many developers "feel" even if they don't say it. In fact governance protects the organization from the incompetent. Now each of you may not feel you're incompetent. But there are many incompetent people out there making process and technology decisions. Our firm makes it's living in some part by cleaning up the mess from those people.

So when Andrew conjectures people are reluctant because of fear. It ain't fear - it's governance. When Andrew and then Seth Gordon (it's always good to quote a celebrity in support your point) speak about "people," they don't say which people. Keep all pronouns vague it helps avoid definitive fact based conversations - good marketing approach for products as well. GM does this with there Escalade hybrid comparison to the Mini.

It's People who run projects, it's people who run companies. The people who run companies are in fact different than the people who run projects - or write code - inside those companies.

It is a complete myth that you and I are just like Jack Welch, Steve Jobs, Rex Tillerson (CEO and Chairman of Exxon Mobil, or even Bill Gates. We're not. We may think we are. We're not.

So back to the point - yes there is one

Adoption of ANY process and technology - new or old - needs to pass through a governance process (notice the small "g").

If there is a group of individuals, then the governance can be self-governing. If the governance process sits inside GE, Lockheed-Martin, large electric utilities with nukes, AmTrak, Frontier Airlines (to name a few where I have inside experience) or any of the 10's of 1,000's of large publicly traded firms:

Governance trumps local optimizations

You may not agree. You may not like it. You may think it's silly from your personal point of view. But in those firms it's not about you. In any large firm, it's not about you. Even at places like Starbucks - voted the best place to work, or a firm I worked for that always won a "best place to work" from Fortune Magazine. Wasn't true on the ground. It's not about you. It's about the greater good of the company and that means the greater good for the shareholders.

Think that's stupid? Start your own company and fix it. I've done that once. OK, twice only once successfully.

And I'm here to tell you all was wonderful when we had 10 people all fearlessly dedicated to building our product. When we reached 50 things started to be different. When we reached 150 they were much different. When we reach 300 we went public and things were a whole lot different - welcome to Governance our CEO explained, you can stop doing all then self-governing stuff now, we have real customers and real stock holders.