Command and Control

Command and Control: Nuclear weapons, the Damascus Accident, and the illusion of safety.  Eric Schlosser.  The Penguin Press, NY.  2013.

Command and Control, by Eric Schlosser, is not a project management book.  Quoting the inside cover of the dust jacket, “Command and Control interweaves the minute-by-minute story of an accident at a nuclear missile silo in rural Arkansas with a historical narrative that spans more than fifty years.”

The anecdotes, stories, and discussions in the book are about systems and practices in operations, maintenance and support.  But projects culminate in systems and practices in operations, maintenance and support.  Command and Control is a case study – or a collection of case studies – on topics near and dear to project management:  risk, management and control, communications management, and lessons learned.  I can recommend the book as a fascinating read for any number of reasons, but this is a blog on project management best practices.  Let’s look at a few lessons for us:  the few, the proud, the PMs.

Excluding military veterans, few of us will have the opportunity (if you call it that) over the course of our careers to participate in a true life-or-death project.  But the servicemen depicted in Command and Control worked too close to a nuclear core sitting on top of an unstable mixture of liquid fuel and oxygen packaged in a paper-thin shell and buried in an underground containment vessel cum concentration chamber.  The book describes occasions when the fail safes intended to protect them (and us) worked and, in minute by minute detail, one specific occasion when they didn’t.

Much of the book is about the history of super-secret military nuclear arms development and deployment during the cold war.  It is worth reading this book to see how often it is one person, championing a cause against a tide of resistance, who is responsible for the implementation of a failsafe or risk-reducing feature that ultimately saved lives.  I think this is an apt metaphor for my experience getting owners and sponsors to responsibly address both project and product risk.

I was also fascinated by the account of the unintended, unplanned testing of the limits of the launch complex blast doors – and the conflicted confidence, by the various players, in the structural integrity of those doors under catastrophic load.  Not to mention the comical -- in other circumstances – decisions to override, bypass and ignore the available protective features.  In our projects, how often, in our urgency to get a system out the door, do we face similar choices and make similar decisions?  For what our project deploys to production, do we ever plan for operational systems management in a disaster under realistic, degraded conditions?

Another relevant theme is organizational decision making under stress.  The US military operates in an hierarchical, command and control structure.  But when she’s about to blow, that structure broke down because of both communication limits and independent agency.  The fog of uncertainty when radios don’t work, the most knowledgeable person can’t be reached, the tools don’t give the information needed, leadership is communicating conflicted priorities, and different experts give contradictory advice at high volume, means that wrong decisions will be made – at all levels up and down the line.  Further, the guy in the bunker, face-to-face with the devil, may decide that he knows better what to do than the general sitting safely under a far-away mountain.  Or he may decide to follow orders anyway, despite knowing it’s the wrong decision.  The book tells the tale of a real event, so there is no magical fairy tale ending.  We as PMs need to understand that, for all our expectations that the team will follow where we lead, those team members are each independent agents with their own motives, priorities, and interests that may – or not – coincide with ours.

Another theme we can learn from is the lessons learned result.  It’s disappointing that over 50 years later, we still haven’t learned to address the systemic root cause of a failure rather than blaming the grunt on the ground.  After all, fixing the root cause means addressing a capability that management and leadership is responsible for;  blaming the grunt deflects the attention away from the upper castes.  This is a topic I am preparing to take up at length in the near future.

We as project managers have two levels of learning from Command and Control.  One is that we can see how things really work when the fan is spinning – it isn’t clean, it isn’t pretty, and it’s not like they describe in the textbook.  Just as importantly, we should also pay attention that our projects, which end and we walk away from, produce these things that people have to live with and work in.  It was projects that built the Titan II missile, the launch complex, the operational processes, and all the complex and complicated pieces that came together and, well, blew up.  It was our professional ancestors that built these products and systems.  What will our progenitors a half century from now be reading about us?

© 2014 Chuck Morton.  All Rights Reserved.

The Project Status Report – The Bad News

"It not knowing what to do, it's doing what you know.”

                                                                                                - Tony Robbins

Over the last couple of posts, I’ve discussed the “what” of the project status report (i.e., the content).  In this post, the conclusion of this three part series, I discuss the “why” of the PSR, but focusing on some of the less obvious benefits.

Everyone understands the theoretical or conceptual need for the project status report.  The client expects it, it may be obligated by the contract, and it may be in the standard process.  But it’s a burden to put together every week, to come up with newly creative ways to say you’re still behind on the project and you don’t have any tangible accomplishments to report.  We want a reason to do this activity – week in and week out – some reason larger than obligation to process;  some reason that overcomes the urge to make anything else we can be doing a higher priority than the Project Status Report.  We want something that gives this activity purpose and meaning.

There are a few good reasons for producing the weekly Project Status Report.  For example, a well-written PSR – succinct, factual, comprehensive – launches good discussions in the client project meeting.  It documents the action items and effects of non-compliance and non-responsiveness from the stakeholders.  It is an archive of the project trail.  But, there’s more.

On the LinkedIn discussion boards for Project Management that I follow, the question “What’s the best way to deliver bad news?” appears regularly.  This is a question I struggle with answering because the question those LinkedIn questioners are asking is not really “How to deliver bad news” but rather “How to deliver surprising bad news.”

The bad news I deliver to my project stakeholders is rarely a surprise to them because I publish the project status report religiously every week and I pack it with factual information about the project – the good and the bad.  I document the issues we are experiencing and the risks that present threats and opportunities.  I show where we have variances.  Sure, this is hard.  But it is a professional and ethical responsibility.  And if you don’t do this (think good risk management here), you are going to be struggling with the question of how to deliver surprising bad news to your stakeholders.

I can’t think of a better reason or a higher purpose than this.

Producing the project status report every cycle is a Project Management Best Practice.  What problems have you experienced when you ignored this practice?  What problems have you avoided by publishing it even when it didn’t seem like a healthy choice?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report – Content That Matters

"Thinking is more interesting than knowing, but less interesting than looking.”

                                                                                                - Johann Wolfgang von Goethe

This is the second post in the series on The Project Status Report.  In this post, I get specific about the appropriate content of a PSR.  But first, while it is called a Project Status Report, it typically includes status (snapshot), trending, progress (accomplishments) and exception (variance) content.  Second, the PSR should not be confused with a person’s (individual) status report (ISR), which everyone on the team should be completing.  Further, the PSR is not a roll-up from the ISRs.  Finally, the PSR, when done properly, is aligned with and contributes to the overall Management by Objectives (MBO) approach.

This last point deserves emphasis.  The PSR does not and should not say what is going on.  I know this seems totally off base, but to ignore this point devalues the PM contribution.  Rather, the project has a plan and the PSR documents the consistency with or variance from the plan.  So rather than saying “what is going on,” the PSR should say what is going on relative to the plan, which is a key distinction.

I’ve found that the following sections are useful to have in the PSR:
·         Current snapshot
·         Dashboard
·         Performance to plan
·         Accomplishments
·         Planned for next period
·         Issues/ Variances
·         Acceptances
·         Change activity
·         Risk summary
·         Downtime

Not all organizations use all sections and not all sections are appropriate for all organizations.  Let me discuss each section.

Current snapshot

This optional section is status content and is the executive summary of the PSR.  It should be a very brief (no more than a few sentences) narrative.  Of particular significance is to use this section to emphasize areas where stakeholder intervention is required, such as resolving third-party bureaucratic or administrative interference, stakeholder non-compliance (failure to approve a deliverable or change request), failure of a risk or issue owner to act, or when intervention is needed to address a “red light.”

Dashboard

This optional section is status content (and is improved with trending indicators).  Despite their popularity, I’m not a big fan of “traffic lights,” those red-yellow-green circles to summarize status, primarily because there often is not a clear understanding by all stakeholders what the traffic lights mean.  Further, a single traffic light summarizes too much to be sufficiently actionable (for example, something I experience regularly is that we will start a project before all of the budget administrivia is complete, knowing that the executives have approved the project and it will go forward.  However, the project shows red because of the budget and, so, everyone ignores the traffic light.  But there may also be other factors that should be recognized that are concealed because of the attention to the budget.)

I’m OK with traffic lights when the following conditions are met:  1) all stakeholders understand what the lights mean (in particular, when their action or intervention is required);  2) that there are multiple lights providing sufficiently discrete information to the stakeholders (e. g., budget, schedule, scope, approvals, issues, risks).  Traffic light value is improved if there are trending indicators (for example, up/ down arrows) to communicate changes.

Performance to plan

This is required status content.  This should include a Gantt chart (showing variance from plan) or, even better, Earned Value (and Earned Schedule) graphs.  This is the meat of the status report.

Accomplishments

This is optional progress content, though it is universally included.  Equally universal is that the wrong information is presented.  This should report accomplishments, not activity.  Avoid muddy verbs, such as:  worked on, met, attended.  Instead, use only concrete verbs, such as completed, published, documented, tested, coded.  The activities associated with these verbs should be tasks or activities in the WBS (and thus on the project schedule).  Finally, include metrics whenever possible (e.g., completed 20 of 30 test cases).

To digress momentarily, be clear about what “completed” means.  I often have developers report they completed an assignment.  “Have you completed the unit testing,” I ask.  “No, I completed the coding.”  OK, but the task is not complete.  These types of grey areas compromise the accuracy and the credibility of your reporting.

Planned for next period

This is optional progress content.  The same rules as listed for Accomplishments apply.

Issues/ Variances

This is required exception content and is usually a table documenting current project issues, the issue owner, activity and plan for resolution.

Acceptances

This is required status and exception content.  This should be a table listing each deliverable that has been submitted but not approved and deliverables that will be submitted in the next few weeks.  Table columns should list the deliverable name, responsible approver, date (to be) submitted, date approval was (or will be) due, and status (Not submitted, Pending approval, Overdue, Approved).  Overdue approvals should be highlighted.  Once an approval is received, this is reported as complete on the next PSR, then it is removed from future PSRs.

Change activity

This is required exception content.  This, too, is a table listing each submitted, but not completed, project change request.  Columns should include PCR number, title, date submitted, date response due, and status (Submitted, Pending approval, Approved/ Denied, Project plan updated).  Once the PCR has been denied or after the project plan is updated following the approval, this is reported on the next PCR, then it is removed from the table.

Risk summary (key risks)

This is required exception content.  This section is formatted similar to the Issues section.  One thing important to add to the section heading is “Date last discussed.”  This should be the date that risks were most recently discussed in the Client Project Meeting with the stakeholders.  I find that these meetings rarely discuss risks because time runs out before we get to this agenda item.  Risks should be discussed at least monthly and, if they haven’t been, this discussion should be moved to the top part of the agenda.

Downtime

This is optional exception content and will rarely be seen except in the status reports of the top echelon consulting firms.  It really isn’t meaningful in a Product & Service Delivery environment, but may mean the difference between profit and loss for a Consultancy PM.  When the client is responsible for the infrastructure on which the project depends, any failure, downtime, or force majeure where they are billed for your services but no work is being performed because of their nonperfomance, should be reported in this section.  It should (hopefully) be rare to have content here, but it is important to report it when appropriate.  I have also seen this section used to report “thumb twiddling” time because a client has not given timely approval to a deliverable.

There are obvious direct benefits from issuing weekly project status reports.  In the next and final post on this series, some key indirect benefits that may not be obvious.

What benefits do you receive or would you expect from publishing a weekly status report with this content?  What project problems can be avoided?  Can you guess what points I’ll bring up?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Status Report

"Oft expectation fails, and most oft where most it promises; and oft it hits where hope is coldest; and despair most sits.”

                                                                               - William Shakespeare (All’s Well That Ends Well)

It has been a few weeks since I last posted.  Not because I don’t have ideas to share, but rather that I have a whole list of “next topics” and I struggle with where to go next.  I mentioned the Project Status Report in a post long ago during my series on The Project Manager’s Cycle, which I encourage you to review to properly understand the context for this expanded discussion on the Project Status Report (PSR).  With this post, I want to revisit the discussion about the PSR, going into depth on both the content (what goes in the PSR) and the rationale for the content.

The PSR is a key component of project communications.  There are the day-to-day communications by the project manager (the activities in the Project Manager’s Cycle where the PM meets with team members to get updates, to encourage, to motivate and meets with stakeholders for behind-the-scenes discussions).  But these build to the three central communication practices of the Project Manager’s Cycle:  the project team meeting, the PSR and the Client Project Meeting.

One of the essential decisions that must be made about the PSR – and this will be documented in the Communications Plan – is whether the PSR is a stand-alone document or whether it is a discussion aid to supplement the Client Project Meeting.  As a stand-alone document, I mean that it has to comprehensively explain information without the need for a discussion.  I don’t operate this way and, as a best practice, I recommend, instead, that the PSR is an aid to facilitate discussion in the Client Project Meeting (and I don’t mean either that the PSR substitutes for the Client Project Meeting agenda).   Thus, the Client Project Meeting – or rather, the minutes from that meeting – is the record of decisions made about the status.

The content of the PSR needs to answer a few basic, but essential questions:  how are we doing relative to the plan;  what is being (or will be) done to restore the project to plan, if necessary;  what threats jeopardize the project;  what actions are needed from the project owners or sponsors.

In the next post, I’ll address common sections of the PSR and the appropriate content for each;  and I’ll follow with a post on some of the tactical benefits of regular, proper status reporting.

What problems have you avoided that were attributable to good status reporting practices?  What problems have you encountered from deficiencies in status reporting?

© 2013 Chuck Morton.  All Rights Reserved.

Change Management – The Process (Part 2)

“If you do not change direction, you may end up where you are heading.”
                                                                                                                                - Lao Tzu

This post concludes the series on change management that started with a discussion about what’s so confusing and is a continuation of my previous post on the process of project change management.  That post described the conceptual activities in project change management and why there are not explicit change management processes in the PMBoK.  Now it is appropriate to review what is in PMBoK and how it aligns with the conceptual activities.

The following PMBoK processes relate to project change management:
·         Develop project management plan
·         Plan [Knowledge Area] management
·         Direct and manage project work
·         Monitor & Control project work
·         Perform integrated change control

“Develop project management plan” and “Plan [Knowledge Area] management go hand-in-hand.  The project management plan includes each of the knowledge area management plans.  Each knowledge area plan (scope, time, cost, etc.) needs to include how change to that component will be managed.  In addition, the project management plan should describe how change requests are submitted, processed, reviewed and decided.

One thing I haven’t yet discussed is the two types of change.  There are, for example, changes to the product or service that is produced in “Direct and manage project work” and variance and compliance changes that are recognized in “Monitor and Control project work.”  We encountered both of these in a previous post on the philosophical dilemma of project change.  The project plans should,, of course, address how this dilemma is recognized and resolved in the “direct and manage” and “monitor and control” processes.

“Perform integrated change control” is the key to having project change work effectively.  It is here that change requests are received and processed.  As I mentioned in the previous post, this process is like initiating a complete mini-project for each request.  That’s why I have a dissonant response to Table 3-1 on page 60 of the PMBoK every time I pay attention to the location of 4.5 Perform Integrated Change Control, in the Monitoring and Controlling Process Group column.  Realistically, this step spans all five columns, from Initiating to Closing.  Not only does this span all process groups, but because a change to one functional group will trigger cascading changes in other functional groups, this activity also spans all functions (scope, time, cost, etc.), which is why it is integrated change control.

As I now bring this series to a close, the most important point to emphasize is that change will occur on your project, it will happen, and it must be planned for, you must prepare to have change, and you must have the processes and practices in place to effectively include, manage and control change in your project.

So now that you know everything I know about project change, what tips do you have for other PMs?

© 2013 Chuck Morton.  All Rights Reserved.

Project Change Management – Process Overview

"Change is inevitable - except from a vending machine.”
                                                                                                - Robert C. Gallagher

Now that we have the confusions and dilemmas of change management behind us, it’s time to drill into the change management process. 

The one thing you can count on to stay the same when running a project is that there will be change.  Yet, the PMBoK (5^th ed, p60) identifies nine knowledge areas and change is not in the name of any.  And change is not in the name of the five process groups.  There is no process that says “Plan Change Management.”  If change is so prevalent, what is the process and where is it documented?

Some examples of change include:
·         We need to complete the project sooner.
·         We need to reduce the project budget.
·         We need to add this feature to the project scope.
·         This person has resigned, but we still need to complete the project.

In fact, there are eight broad areas where change can occur:  Scope, Time, Cost, Quality, HR, Communications, Risk, Procurement and Stakeholders.  This list, no coincidence, corresponds to eight of the PMI knowledge areas (PMBoK 5^th ed, p60).  But there is no “Deal with scope change” or “Handle HR disruption.”

As any practitioner of project management quickly learns, everything is connected to everything else and nothing happens in isolation.  It’s like there’s a seven dimensional pyramid (eight nodes), where there are 28 connections between the nodes.  (This concept also applies in communications management and communications planning related to the project team size.)  This means that if, for example, you need to complete the project sooner, that has a potential impact on all seven of the other knowledge areas that needs to be evaluated (and each impact to one of those has a potential impact on the other seven, etc.).  So, a “Deal with scope change” process cannot be done in isolation from time, cost, quality,….

Thus, we have, in the wisdom and experience of the PMI, the ninth knowledge area:  Project Integration Management with the process Perform Integrated Change Control.  This is the only practical technique for addressing project change – holistically across all areas.  But “perform” omits “plan” and “evaluate.”  It’s still not complete.

In the next installment of this series, I’ll drill deeper into the change process and how it works.

Has it occurred to you before that change management and communication management have this mathematical relationship?  What consequences can you foresee from this?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Publish the Project Status Report

“Project status this week, in a nutshell, is that we are continuing to stay on schedule, but this is despite your team’s contribution.”  After the initial chit-chat, Srini intentionally opened the status meeting with a statement to get everyone’s attention, especially the Sponsor and Owner Jack.  “Our project team has been working around the delays of returning document reviews and approvals.  We’ve pretty much exhausted the continuing work, though.  As you can see on the status report, there are several deliverables over due for approval and the draft requirements document is held up.  If you think these durations will continue, then I recommend that we extend the time your team is allocated for these activities and extend the time line.”

With this post, we conclude documenting the activities in The Project Manager’s Cycle, the Monitoring and Controlling activities that the project manager performs each reporting cycle for the life of the project.  All of these activities (with the exception of the Client Project Meeting) build each week to the Project Status Report (PSR).  The PSR encapsulates all of the information the Sponsor/Client/Owner and all Stakeholders need into a compact package.

The PSR should document both the current status of the project (in summary) and progress since the last report.  The essential elements of the PSR include an Executive Summary, Accomplishments, Planned Accomplishments (in the next reporting period), Deliverable/Approval Status, Change Request Status, and Issues.  Accomplishments and Planned Accomplishments are reported relative to the plan (project management is the classic example of Management by Objectives).

Note that traffic lights (  Red,  Yellow,  Green) are not in my list of essential elements of the PSR.  I am ambivalent about them.  When used properly they are often valuable, but they are even more often used improperly.  If you use traffic lights, the meaning of each color must be defined clearly and all of the stakeholders reading the PSR must know what each color means.  Further, a single light is really not meaningful.  After all, the ultimate purpose of the lights is to show where external action is needed and one broad status doesn’t provide the specificity needed.  Rather, what I’ve seen that works best are lights representing Schedule, Scope, Budget, Resources, and Closure/Acceptance repeated for each project phase or (preferably) each deliverable.

The PSR is probably the most important document the PM produces and I can’t cover all of the nuances in one post, so expect to see more on other elements of the PSR in the future.

Do you have a project status report best practice to share?  How about a PSR disaster?