PMBok Cafe had a nice post about the jargon of PM 2.0

As well the PM 2.0 advocates have either failed to make or lost their connection with the core principles of project management. They've confused the tools of project management - be they 1.0, 2.0 or any X.0 - with the practices of project management. Managing projects means knowing:

• What will it cost?
• When will it be done?
• Do we know what "done" looks like?
• What are the impediments to getting to "done"?
• Who do we need to get all this work "done"?

Without clear and concise answers to these questions, the tools have no purpose. With the answers to these questions, the tools might be useful, but usually only for the tools vendors.

Tools are a convenience for storing information, communicating that information, and analyzing the information around the MANAGEMENT of projects. The tools are not a replacement for project management.

I finally figured out why I have such a visceral response to many of the PM 2.0 proponents.

The light came on when a poster said PM 2.0 is just common sense. One of my favorite quotes around this approach to most things is

"Common Sense is neither common nor sensical. Much of what passes for common sense is not based on any underlying principle it’s just anecdotes that have worked for the current situation."

Benjamin Franklin

Ben had it right. What passes for common sense is not based on any underlying principle. The principles of Project Management are independent of any tools - nor matter what version. In the absence of these principles, the project management tools have not purpose. Failing to understand this puts the proponents of these tools in the untennable position of not connectinig their value prosition with the market need to increase the Probability of Project Success (PoPS).

"Even though it was complicated, they still had problems"
— From Rogue Project Leader

This Blog has good articles and references for government and military topics. Dan Ward (LtCol) is the host of this and several other Blogs. Dan is a frequent contributor to the Defense University's Journal, Defense Acquisition, Technology, and Logistics  (AT&L).

Dan's book The Simplicity Cycle is available for free download. Worth a read.

November 11^th is a Federal holiday  — Veterans Day — here in the United States. President Wilson proclaimed Armistice Day for November 11, 1919. Seven years later, Congress passed a concurrent resolution seven years later on June 4, 1926, requesting the President issue another proclamation to observe November 11 with appropriate ceremonies.

As a Vietnam Veteran (1969-1970), the ceremonies in our small Colorado town have special meaning. Our college daughter has a high school friend serving his second tour in Afghanistan as a Marine. I work with several Veterans. Marines, Air Force, Army, Navy. Some young, some my age.

We all share a special bond not found in normal personal or business relationships. I work in the defense industry where many colleagues are Veterans - recent and long past. Some single tours some career senior officers. When we enter an office for the first time, it is not uncommon to see a folded flag in a case on the top of a book shelf, a service badge framed on the wall - the Marines do this most often. Or a lapel pin tacked to a backpack or possibly in a suit coat lapel of a former rank

These are all symbols of a shared experience, ranging from stateside service in a clerical position to 12 months or more of walking the bush (or desert) every day.

We need to ask ourselves before just appreciating yet another federal holiday, would you be willing to do what they have done?

For those readers who have served our country in any way - civilian or military - honor the fallen, remember your service, remember the service of others.

For those who flew B-52's, A-6's, CH-47's, lead the finance and account section of a Battalion, repaired the F-4's returning from the "Red River Valley" making them ready for another return to hell, flew the CH-46 state side rescuing sailors and fisherman from harm, humped the Củ Chi trail in search of the illusive enemy, stood 3rd watch plane guard on Yankee Station, ordered the sodas and beer for the PX at Monkey Mountain in Danang, currently fly the C-17 into and out of South West Asia, launched the first cruise missile from the Med to Baghdad, repaired the MRLS in Afghanistan with a high school degree, led the logistics coordination for Schwarzkopf as the only woman O6 in theater with combat experience, or did your simple drudge duty day in and day out, so others were safe, security, fed, fueled, and ready for duty.

A Story from a Colleague

A staff member working a large avionics program for NASA sent an email responding to another vet in our firm today. Matt is a Marine (no former Marines) stationed in central Europe during the Kosovo war.

Yesterday was the Marines Corps birthday, November 10, 1775, a date all Marines carry as long as they live. I had to run an errand yesterday at Wal-Mart. Coming out of the store with my purchase I noticed from afar a big white piece of paper on the back of my Tahoe.

My heart sunk. I thought for sure someone had hit me and had left a note with their insurance information on it. But as I reached the truck I was struck by the note's kindness and attention. It simply said "Happy Birthday, Marine". Nothing more, nothing less.

They had seen the Marine emblem on my truck and cared enough to get out of their vehicle, get pen and paper, write a note. Clearly, they had gone out of their way to remember. I have no idea who this person was, if they were themselves a Marine, or a descendant of one, or what their political affiliation was.

They just cared enough to say "thank you" and it really made my day. It depresses me a little bit sometimes, you know. It seems we are generations now removed from this simple gesture of gratitude and sincerity, that we live in a land filled more with the notion of immediate gratification than we have investing time to earn it. I'm glad you (Matt was speaking to another colleague who was a special ops officer in Vietnam and retired USAF space command) walked the parade and I would have gladly stood next to you.

Thanks to the Vets

Josh at PMStudent asked a question if there is "One True Way" to manage projects?

The answer of course is a resounding

Yes, there is only one TRUE way to manage projects

The project manager must be capable of managing the project with a method that "informs" all interested parties about:

1. When is the project forecast to be complete and what is the confidence on this date.
2. What will project cost in the end and what is the confidence on this value.
3. What the impediments are there to reaching the end of the project on or near the planned date, and on or near the planned cost, and more or less with the capabilities needed by the “customer.”
4. What resources do we needed to get to all three of those “ends.”
5. What are the units of measure that can be used to describe the progress to plan that is being made and if that progress will result in “happiness” on or near the end of the project.

None of the PM 2.0 “sellers” speak about projects and project management in these terms, they only speak about the features and functions of their products and what wonderful outcomes will result. No units of measure for those outcomes BTW. You know, things like  confidence intervals on cost and schedule improvements, increasing probability of success, estimates at completion. Boring project management metrics.

All TRUE project management methods from XP to Scrum to Crystal for software development – to full DoD 5000.02 IMP/IMS with workpackage level weekly earned value – all speak in these 5 (and more) terms.

Successful project management has very little to do with the tools. If those 5 (and possibly more)  processes are not there, no PM X.0 process is gonna save your butt.

So in the end there is only one TRUE way – it's called Project Management, not PM 1.0, 2.0, X.Y.

The Greeks knew how to manage projects this way, the Egyptians did too, all the way to our manned space flight program.

The tools have changed over time, the principles of successful project management have not.

The notion that Project Management 2.0, based on Web 2.0, is one of those marketing hype approaches to selling a product, where you start with an unsubstantiated statement about PM 1.0. The book Beyond the Hype: Rediscovering the Essesence of Management, should be read by anyone serious about deciphering this approach to solving the project management problem

Those who participate in PM 1.0 process have no moral motivation is my favorite.

Ignoring the fact that such a statement is utter bullshit, let's look at a larger problem with any 2.X approach.

People’s tendency to become more extreme after speaking with like-minded others has become known as “group polarization,” and it has been documented in dozens of other experiments. In one, feminists who spoke with other feminists became more adamant in their feminism. In a second, opponents of same-sex marriage became even more opposed to the idea, while proponents shifted further in favor. In a third, doves who were grouped with other doves became more dovish still.

Is a comment from Elizabeth Kolbert in her review of Cass Sunstein's book, On Rumors': How Falsehoods Spread. The falsehood I'll start with are the statements about PM 1.0. The conjecture of this approach is PM 1.0 is:

• Inflexible
• Bureaucratic
• Over controlled
• An Imposed process
• Possess no moral motivation

Of course the PM 2.0 proponents fail to mention that their experiences that resulted in these observations usually come from BAD Project Management. No credible project manager or project management method would in inflexible, bureaucratic, over controlling, imposed from the top down. And most certainty any credible project management method would possess the motivations needed to successfully complete the project on time, on budget and on specification. To do otherwise would mean project failure.

This does not mean it doesn't happen. But the familiar phrase "doctor, doctor, it hurts when I do this..." is the best starting point for the nonsensical approach to fixing bad management with more bad management

Core PM Processes

The notion that PM 2.0 is "project management" ignores the core understanding of what project managers do when they are managing projects. Brian Kennemer makes the comment here:

Tools and processes are great things and they can *help* bring order to some of the chaos of data and problems but in the end it is about the people. A crappy PM can use the best tools and the greatest\latest incarnation of Agile and still turn out a crappy project.

There were good PMs getting good results from "PM 1.0" and there were crappy PMs getting crappy results. "PM 2.0" or Agile or whatever, has some cool new ways to look at things and it has some cool stuff to offer so that it might enable a good PM to do their good work better or more easily.

But it is not going to make crappy PMs into good ones. They will continue to do crappy work with the new tools. They will just do it with the 'shine' of newness.

Project Managers manage projects through the efforts of people executing a credible and effective process. Yes, these people use the tools to provide consistent execution of those process.But these tools must work directly with the process. 

The Project Management Tool Kit

These process can range from simple "list making" and task sequencing, resource assigning. What's interesting is several of "task management" tools show Waterfall time lines, the very "boggy man" the agile, PM 2.0 proponents rail against - go figure.

The intermediate solutions start with traditional project management tools, including Microsoft and all the competitors (if there are actually any).

But each of these tool sets, independent of their features and functions fails miserably to address the fundamentals of managing projects:

How can I recognize we are building the right thing for the customer, that the work efforts are moving the product or service forward in its technical or operational maturity at a rate that matches the planned rate needed to complete on time and on budget

Along with these performance measures, what are the recognized and addressed impediments to reaching the end on time, on budget? 

From a April 2009, Defense Acquisition University (people who know some things about project management) "Insight Days" conference, there are 5 core "tools" needed for program success

1. Earned Value performance measurement used to measure physical percent complete
   
2. Risk Management and the Risk Matrices for each deliverables
3. A work Breakdown Structure to describe what products or services are to be delivered
4. A network schedule with the dependencies. Not the toy dependencies shown in the PM 2.0 list making tools, but real dependencies found in industrial strength scheduling tools
5. Technical Performance Measures for each deliverable
   

PM Is About Assuring Progress is Being Made in Units of Measure Meaningful to the Stakeholders

This means we must know what those units of measure are, our capacity to deliver against those measures, the rate at which those measures will move the project forward, and most importantly the path through the work activities that supports the PLAN for the increasing maturity of the project or service.

When you start with the tool (PM 2.0) in the absence of the credible processes needed to answer these question, you've started on the wrong end of the proble

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.
— Sun Tzu

The Plan is the Strategy for the successful completion of the project. The Plan shows the points in the project where assessment of product or service maturity should take. The Plan describes the Significant Accomplishments and the Accomplishment Criteria needed for assessing the maturity.

The Schedule describes the sequence of work needed to produce the Accomplishment Criteria - Exit Criteria from the Work Packages containing the tasks.

Both the Plan and the Schedule are needed.

I love deadlines; I especially like the SWOOSHING sound they make as they fly past
— Douglas Adams

Deadlines are made after the work needed to meet the deadline is defined and the appropriate schedule, cost, and resource utilization margins have been discovered. These values must be worked from right to left if the deadline has already been fixed.

This will tell you when you should have started the project. The process of defining he needed schedule margin is provided by a Monte Carlo Simulator tool. My favorite is Risk+. This tool prouces confidence levels for completing "on or before" a specified date. With a "zero slack" schedule, Risk+ can tell the probabilistic completion date to a level of confidence. 80% confidence of completing "on or before" is a good number. The gap between your "zero slack" date and the 80% is the needed margin for the "zero slack" schedule.

The next issue is where to put that schedule margin. That's another topic.

Ron Rosenhead provides a great post about the organizational sources of project failure.

There are of course other sources of organizational failure modes, but Ron's list is a great starting point.

Bill Mathis on LinkedIn Earned Value Management and Paul Solomon both posted news of the GAO released a report on the need to improve the application of Earned Value to manage major acquisitions. Defense was the only agency with "all black," except for training.

From the introduction:

Given the size and significance of the government’s investment in IT, it is important that projects be managed effectively to ensure that public resources are wisely invested. Effectively managing projects entails, among other things, pulling together essential cost, schedule, and technical information in a meaningful, coherent fashion so that managers have an accurate view of the program’s development status. Without meaningful and coherent cost and schedule information, program managers can have a distorted view of a program’s status and risks.

Note that any solution to the "problem" of project management needs to "pull together cost, schedule, and technical (performance) information"

Try that with your email based, IM, twitter, Face Book, social networking PM 2.0 project management system on anything other than a toy project and see how fast you can get into the ditch.

Pretending for the moment that we are over the issue that 2.0 processes do not start with 2.0 tools, Kailash Awati has a good post on on Post Bureaucratic Organizations.

The discussion here is how to manage projects in the absence of full command and control. This new paradigm is present in the Integrated Product Team (IPT) environment. An IPT project is a multidisciplinary group of people who are collectively responsible for delivering a defined product or process.

In these environments collaboration and "flattened" organizations are comment. IPT are mandated by DoD and DOE contracts. We're working a $100M DOE CO2 sequestration project where 3 major players are sharing the preliminary design and validation of the power plant. The Project Management Plan (PMP) describes the interaction between all the IPT's and how they will collaborate at the top level to assure the project reaches its "done" state.

Here's a possible repositioning of the PM 2.0 topic.Not favorable to the PM 2.0 tools vendors, but focused on the project management processes first.

Project Managers need to know a few core items:

1. How much will this cost and is that cost inside the budget?
2. When are the deliverables due and is the current forecast on or before that date?
3. What are the impediments t2o meeting the deliverable date and the forecast cost, and what are the activities to retire, reduce, or mitigate those impediments?
4. What resources are needed to produce the deliverables of the project?

Without the answers to these questions in the affirmative every period of measurement (weekly is best), no amount of 2.0-anything is going to help the project stay on schedule, on cost, on specification. PM 2.0 at best is a mechanism to improve the operational processes once these questions have been answered.

Inverting the approach of having PM 2.0 and Web 2.0 be the starting point is a formula for failure on all but the most trivial of projects. By trivial I mean if the project fails no one loses their job.

it ain't the tools...it's the process and people executing the processes.
Tools are a distant 3^rd

The discussion on a semi-commercial blog (a blog hosted by a product based company) presents the notion that PM 2.0 enabled by Web 2.0. While a pretty good start at a marketing campaign for the product, the critical missing element is "what does a project manager do when she is doing project management?"

Here's a sample of previous advice.

• What Activities Take Place During the Management of a Project?
• Essence of Project Management Part 2
• Three Core Processes of Project Management 
• Project Management v. Systems Engineering

Now the thread here is that the processes of project management are pretty much independent of the tools used to implement those process. Oh yes, Web 2.0 tools can improve the visibility, possibly increase the cohesion between the team members.

I'd say from personal experience and the experience of our staff, the answer is a resounding NO. We have clients that have invested 10's of millions of dollars in tools and still are OTB (Over Target Baseline). They're in the ditch despite the investment in tools - many time in the current collaborative tools.

Even the supposed "agile" project management practices, follow the core processes of project management

• Define what "done" looks like
• Define what work is needed to get to "done"
• Identify the needed resources, risks, and their mitigation and retirement
• measure progress in units of physical percent complete in periods small enough to take managerial actions to stay on track
• Produce an estimate to complete and estimate at completion for cost, schedule and technical performance every reporting period
• Answer the question - how long am I willing to wait before I find out I'm late?

Pick what every tool works for you.

DO NOT start with the tool. Start with the working process, back into the tool. Ignore all the sales pitches that tools solve the problem. They do not.

An Example of Project Management

Just to close out notion of project management, here's a sample job description from a local Denver company. This is typical of the types of project management roles, where tools are secondary to the project processes.

Minimum 15 years Project Manager or related project experience managing large VA hospital programs in excess of $500 million. A Bachelors degree in Engineering, Architecture, or Construction Management is required, with an advanced degree and professional license preferred. Must be proficient with Microsoft Office applications to include Word and Excel, as well as knowledge of construction scheduling software. Excellent written and verbal communication skills necessary.

Craig Brown pointed out the Harvard MBA Oath

Josh had a question awhile back about the usefulness of an MBA. This oath would be a good starting point for defining the "value of an MBA." One of  Josh's Blog contributors stated how abhorrent it is to have MBA's running projects. This is one of the typical nonsense statements made out of context and divorced of any domain.

As a holder of an MBA - not from Harvard, USC - go Trojans - I can say with unabashed enthusiasm, that going through an MBA program having started from a graduate degree in physics. Learning where your pay check comes from, how the place the pays you makes money, and all other financial, marketing, and accounting processes cause this money to appear.

As a project manager, this knowledge is critical to a project's success. Possessing this knowledge allows the PM to be directly connected with business and the business case for the project - at least in the commercial world.

The US Department of Energy has project management resources that are generally applicable to a variety of domains and contexts.

The DOE Office of Project Assessment is the entry point for many things "project."

The DOE Series O 413 is an overarching set of guidelines for project management including IT projects.

Craig Brown posted this video, as other will certainty do in the agile community

From the Cognitive Edge.

The point of emergence (for social activities) is very important. Our firm is "emerging" to the next level of revenue and processes that support that revenue.

However, is this paradigm appropriate for projects and the management of projects:

• Would the owner of a newly commissioned SAP project for the Fortune 500 firm like the "emergent" approach defined here?
• How about the leaders of the current manned space flight program - Orion?
• Or maybe the PM for the construction of a large BioFuels and Coal Gasification plant we're current working?
• Our that 30 story high rise going up across the street from our office. The one with the "project management company" trailer in the parking lot. The guys managing the construction of the High Rise.
• Or the ARRA funded bridge replacement I see on CO-36 everyday when I commute to the office, where the High Rise is being built, and the Hospital I pass on I-25 as well?

Let's ask the question of this paradigm?

What class of projects in the commercial or government world (projects using someone elses money) would be appropriate for the emergent process described in the 3rd of the 3 options?

This video has hit a home run with me. The answer to the question above need to be in place before the word emergent can be used with the word project.

Several Blog posts this week speak to the softer side of project management, leadership of projects, and guiding the staff of a project. Eugion's PM Workshop Blog has several good posts around this topic. His blog has been improving with every post since I discovered it earlier this year.

I'd like to speak a bit about the flip side of the "softer side." First the principles of project management in our domain. This domain - at least the domain I'm accountable for in our form - includes aerospace and defense program planning and controls and civil and commercial government projects. Commercial government projects are executed by recipients of government money - usually federal and state funds.

In this domain we apply our Deliverables Based Planning^sm method in its full glory. This means:

• A Plan of the Week for the physical deliverables
• Measures of physical percent complete for these deliverables
• Risk adjusted cost and schedule baselines

In simple terms - tell me what you're going to do, do it, and tell me what you did on a weekly basis. This weekly Plan of the Week (PoW), is guided by the Plan of the Month (PoM). This Plan is of course guided by the Statement of Work (SOW). The result of all this "planning" is that everyone - the client, the stakeholders, the participants, and especially the project manager and the subject matter experts from our firm know what DONE looks like at the end of every week. On some projects or programs we also have a Plan of the Day. Just like eXtreme Programming - what a concept.

So now comes the "softer side" of managing projects. There is a minimal set of human behaviors on our projects. Professionalism of course. Recognition of subject matter expertise. We don't have any junior position. We're too small to hire people who need training. 10 to 15 years PM, PMP, core business skills.

But what drives all this is a critical success factor for all the project and programs we work.

Define what done looks like, then deliver to that description

What happens when that doesn't happen?

What happens when the deliverables don't show up on time? The first thing is that "not showing up on time" is crystal clear on the Monday after the Close of Business (COB) of Friday. The status for those deliverables is now YELLOW at least and possibly RED.

You didn't do what you said you were going to do. Hal Macomber's Securing Reliable Promises is a good example of how to apply Deliverables Based Planning^sm.

When the deliverables for the week don't show there are several steps that must be taken:

1. Determine the root cause. There can be good reasons or bad reasons. Good reasons need a Plan B to get back to GREEN. Bad reasons need intervention to get back to GREEN.
2. In all cases a plan to "get to GREEN" must be the next step. "You missed your deliverable for Friday, how will you provide that deliverable this week, without impacting the deliverable also due this week?" Otherwise your LATE.
3. The major root cause of being late is starting late. This is a fundamental law of "the physics of project" - LATE START = LATE FINISH

Now what happens if the "late" behavior repeats? Is it the person, the process, the environment, the client, the technology. This is now where Eugino's conversations start. But in a way possibly different than he intended.

The Project Manager or the Site Manager must rapidly determine what the root cause of "lateness" is. And make a change to "keep the project GREEN." If not the project will head for the ditch. The softer side of project manager has limited benefit in the presence of a Late project. Especially when the project staff is senior. Junior members need more "softer side" management. Senior members are on the job because they are senior - they know better. Or at least they should know better.

In The End Its the Deliverables That Matter

All the softer side process are needed for success - less so for senior members. But in the end the client did not buy self actualization and staff development for external projects. They bough a solution. This is a critical different between internal and external projects.

This BTW is why construction project managers are continually cranky. They're usually late and over budget all the time. And if not, they've spent huge amounts of time and energy keeping the project on schedule and on budget - and they're tired and cranky from just doing their job.

I've never met a Aerospace or Defense program manager that had a smile.

Progress can be made by

• Defining what done looks like on a monthly, weekly, and possibly daily basis
• Defining the work to get to done
• Measuring progress as physical percent complete - 0% /100% is a good indicator of progress
• Start on time, and you'll have a chance of finishing on time
• Don't let anyone get away with being YELLOW for more than 2 reporting periods
• Replace anyone who can't figure this out

Ares I-X Flew Today

The flight avionics of the manned spacecraft portion is one of the programs our firm works as Program Planning and Controls personnel.

The commitments needed to meet a launch date, is a culture embedded in the manned space flight and launch vehicle business. These commitments start with a clear and concise description of what "done" looks like, the accomplishments needed to produce "done," and the criteria by which these accomplishments will be judged.

Add to this the continuous risk managPublishement process for every step, every week, every deliverable.

“Opinion is the medium between knowledge and ignorance.” — Plato