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.

Estimates, Schedules, Assumptions and Risks

"Though life is made up of mere bubbles, 'Tis better than many aver, For while we've a whole lot of troubles, The most of them never occur.”
                                                                                                - Nixon Waterman

With this post I conclude the series on scheduling and estimating that started with the basics of scheduling.  I hope that this series has successfully drilled into you that offering an informal estimate, without including all of the elements for success and properly qualifying the estimate with assumptions or risks, is an eventual path to damaging your credibility and the credibility of the PM profession.  Estimates should almost universally be presented as ranges with statistical probabilities.  (It’s a real disgrace that our tools generally don’t provide this capability.)

Estimates should always include estimating assumptions.  This is not a CYA point, but rather the estimating assumptions further clarify the scope and scope boundaries, establishing basis for (project) change control.  Change Management is a topic that I haven’t developed yet and is a good one for a future series.  Stay tuned for that one.

A well-formed schedule takes work to produce.   When done well it has a rational basis and a foundation in science.  And despite all that, it is still subject to failure.  That is no excuse, though, for us not to do the work that our profession calls for.  In fact, it is the reason that we should be as rigorous as possible in our duties.

Starting with my next post, I’m going to cover a few miscellaneous topics for a few posts before starting a new series.

What estimating and scheduling issues do you experience that I have not addressed in this series?

© 2013 Chuck Morton.  All Rights Reserved.

Estimate Confidence Buffers, Risk Buffers and Management Reserve

"If confusion is the first step to knowledge, I must be a genius.”
                                                                                                - Larry Leissner

We’re nearing the conclusion of this series that started with the basics of scheduling.  I want to tie up a few loose ends, maybe clarify some inaccuracies and address some confusion I may have introduced.

As I developed this series on scheduling, leading up to the previous post on estimate buffers, I hopefully offered convincing arguments for including appropriate buffers.  In this post, I want to compare and contrast various types of buffers that are common.

I think the discussion I offered on risk buffers is consistent with other authors and industry practices, so I won’t belabor that discussion.  I will point out that risk buffers are included in the project (time and cost) budget and are managed by the Project Manager.

Literature and practices for improving estimate confidence are much rarer.  Therefore, there may be some stakeholder pushback for including these buffers in the schedule.  However, you can demonstrate through logic, reason, science and ethics that, in order to have a realistic schedule, these buffers, like the risk buffers, must be included in the schedule.  Like risk buffers, these confidence buffers are included in the project budget and are managed by the Project Manager.

However, you don’t want to “double count” your risks.  Let’s say you do a lot of similar projects.  For these, there will probably be a common pool of risks that are included.  However, if your estimates are based on historical results and sometimes these risks occur, then there is the potential that your Pessimistic estimates will already account for those risks.  You will need to adjust either the estimates or the risk buffers so they are in the schedule only once.

In contrast to the confidence and risk buffers, some PMs Pad their estimates.  Some project managers, after over-running the project schedule a few times, learn that their estimates are never sufficient and start adding arbitrary amounts.  “We go over by 20% every time, so I’ll just start adding 20% to the schedule.”  This may sound logical on the surface, but is actually bad for their credibility and for the PM profession.  (Look for more discussion on this topic in a future discussion of The Toyota Way.)  Stakeholders learn that the PM is padding and, in response, start cutting the budget or otherwise compensating.  Pad is Bad.

In contrast, neither confidence buffers nor risk buffers are arbitrary.  Hopefully, if you’ve followed the discussion this far, the reasonable, logical and scientific justification for including these in the project are thoroughly explained and documented.

One last buffer that is sometimes seen in large, third-party project contracts is Management Reserve.  Management Reserve is separate from and distinctly different than estimate confidence buffers, risk buffers or pad.  Management Reserve is contingency funds allocated for use by the contract owner (sponsor).  These funds are not part of the project budget and are not available to the Project Manager except after approved project change control to authorize allocation to the project.

I hope this series has been interesting and informative for you.  One last remaining post and then we can move on to new topics.

Was this discussion scheduling and estimating clear and thorough?  Is there anything I missed that you would like me to address or anything that is still not clear that I should expand on?

© 2013 Chuck Morton.  All Rights Reserved.

Estimates & Buffers

“A clever person turns great troubles into little ones and little ones into none at all.”

- Chinese Proverb

If you’ve been following the series on the well-formed schedule and the subsequent series of posts, you are aware that from the WBS you create estimates and iteratively refine those estimates by, for example, improving the probability of success and compensating for risk.  One of the PM challenges is how to balance motivating task owners, setting appropriate stakeholder expectations, reporting honestly and doing all of this in a forthright and ethical manner.

To demonstrate, let’s use our example task from Risk Buffers – An Example.  You might estimate that your Most Likely time for the commute is 30 minutes and the Optimistic time is 20 minutes.  However, the Expected (Mean) time might be calculated as 35 minutes (this is the 50% probability of success, where you’re as likely be early as late).  If you toss in one standard deviation to get to a 65% probability of success or two standard deviations to get to a 95% probability of success, the estimate could balloon to 45 or 55 minutes.  On top of this, then, you add those risk buffers, which might add 10-15 more minutes to the estimate.

Let’s take a look at this from your perspective with several of the stakeholders to examine the conflicts.  First, with the task owner:  Physics and Theory X management say that if you put that high estimate on the task, the task owner will take all of it.  In order to motivate the task owner, it is necessary to use, for example, either Most Likely or Expected.  In fact, I’ve managed projects in organizations that insisted that I use the Optimistic estimate and “stay on those team members” or they would just slack off.

Now looking at this from the perspective of your relationship with the project owner or sponsor, if you fill the schedule with fully bloated tasks (“What do you mean it’ll take 65 minutes to drive to the office!  I know full well it only takes 30 minutes.), you’ll lose all credibility.  However, if you use only Optimistic (!) or even Most Likely or Expected estimates, the end (date or cost) is not realistic and you’ve set yourself up for failure (as documented in The Schedule – Probability of Success). 

Some stakeholders want to know when it will really be done and how much it will really cost.  And they want to have realistic progress updates on these realistic completion values.  If you are not using fully weighted estimates, your reporting to these stakeholders will not be accurate.

Finally, another stakeholder that you have to true to is yourself (and the PM community).  How you address these conflicts must be ethical.

The conflict then is how to have individual task estimates that are under-weighted, but have the overall project estimate include the probability of success and risk adjustments.  The solution, of course, is to have “tasks” in the schedule that represent these estimating and risk buffers.  So let’s say you create these buffers and put them all at the end of the schedule.  This also creates reporting problems because there will be the appearance, at the start of the project, of a large gap between the end of the last deliverable and the end of the project.  It will appear as you progress and report completion of deliverables that you are (most likely) late on all of the deliverables.

At a minimum then, you need to distribute these buffers into each deliverable, spreading them over the life of the project.  You, as project manager, own these buffers and you have to deplete them as you go, continually reassessing much has been consumed by actual task overage and underage.

Since these buffers are included in the project (cost and time) budget, they cannot be arbitrarily reduced, eliminated, increased or created except through formal project change control.  They can (depending on the rigor of project change control) be moved between deliverables, but this should be documented.

Before closing I want to mention that the book Critical Chain by Elihayu M. Goldratt describes a formulaic approach to determine the appropriate amount and placement of the buffers.  This approach has been successfully used in many organizations and should be considered as an alternative to the custom and complex approach to buffers I’ve presented.  Further, he goes in to much more detail on the operational practices.

In my next post I’ll conclude this series on buffers and then we can move on to some new topics.

What challenges have you had convincing stakeholders to use realistic schedules?  Do you get pushback that you are just padding your estimates?  How do you handle it?

© 2013 Chuck Morton.  All Rights Reserved.

Risk Buffers – An Example

“President Bush has said that the economy is growing, that there are jobs out there. But you know, it's a long commute to China to get those jobs.”
                                                                                                - Tom Daschle

In The Schedule – Risk Buffers, the concluding post of a series on developing the well-formed schedule, I glossed over the complexity and details of planning project risk buffers.  I’d like to revisit the topic in more depth over the next few posts.

However, before I go into the complexities, I would like to present a very simple example, one I hope everyone can relate to, to demonstrate the concepts.  You are probably quite familiar with your commute:  you’ve driven it many times and you know what time you have to leave to generally get to work on time.  Even so, most commuters are occasionally surprised by unexpected traffic conditions – weather, wrecks, and road work, for example.  To demonstrate how to determine risk buffers, this exercise will touch on four of the six PMBoK Project Risk Management processes:  Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, and Plan Risk Responses.

For this example “project” we’ll only have one task:  Drive to work.  My next post will focus on identifying risks, so I won’t dwell on that step here.  For this exercise, let’s say you have these risks:

1.       There could be rain
2.       There could be snow or ice
3.       Ice could be so bad that your office closes for the day
4.       You are low on gas and need to refill before you can make it all the way to work
5.       There could be a wreck that causes a slow down
6.       There could be road work that causes a slow down
7.       There could be road work that causes a detour

(Do you see anything noteworthy about “risks” three and four?  I’ll have more to say about these in my next post.)

Something that is often missed or glossed over is dealing with Opportunities (the opposite of risk threats).  If your task is estimated to a 50% probability, there is as equal a chance of it coming in early as there is it coming in late, so you need to factor in and exploit (or enhance, share or accept) the opportunities.  For example:

8.       Traffic could be very light
9.       There could be a wreck in a location that causes your commute to be lighter than normal
10.   All the traffic lights could hit perfect for you today

The next step is to qualitatively assess the risks.  The objective of this step is to determine those risks you are going to seriously pay attention to – those that you will quantify, determine the risk response, and monitor.  It is generally done by assigning subjective Low, Medium and High values to probability (the likelihood that the risk event will occur) and impact (how the project is affected if the risk event occurs).  For example, if it’s August, the likelihood of snow or ice (risk #2) is Low.  From this analysis you generally then disregard the Low-Low risks (though note that these values can change over time, so you must periodically re-asses your risks).

The list is now winnowed down to the select risks that will receive attention.  Determine a specific (time, money or both) cost to the project for each remaining risk (including opportunities) if it occurs.

Most of what I read at this point talks about mitigating the risks, but there’s a lot more to risk response than just mitigation.  For example, add tasks to the project (such as check the weather or turn on the radio to get a traffic update).  In addition, risk responses can be transfer (ask a colleague to be there for you in case you can’t get there in time), avoid (reschedule to another day when it won’t rain) or accept (add the time and cost to the schedule).

Finally, and where this has all been leading up to, is to add a risk buffer to the project as part of the risk response.  For example, if there is a 25% chance that a risk will occur that will add twenty minutes to the commute, then you would add a five minute risk buffer to the project (in our example, you would plan to leave five minutes earlier).  You would sum the values for each appropriate risk and opportunity and add a buffer for the total amount.

With this step, you have again increased the probability of getting to the office on time – er, that is, of completing your project on schedule.

I’ll be delving deeper into risks over the next few posts using this example to demonstrate the concepts.  What about risks – threats and opportunities – would you like to understand better?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Review Risks & Mitigation Actions

“Jack, we’ve allocated five days in the plan for you to review each of the major deliverables,” Alice, the Sr Project Manager, explained to the Executive VP (HR), during the schedule review.  “If you can complete those reviews and provide signoff within three days, we have the opportunity to knock two weeks off the schedule.  However, if you take longer, that will push out the Go Live date.”

With this post, we reach the midpoint of The Project Manager’s Cycle where this action and the next few actions are deceptively easy to describe, but are considerably more complex to practice.  As a reminder, this series describes the Monitor and Control activities that the project manager repeats each project reporting cycle.

Project Risk Management is, of course, a process documented in A Guide to the Project Management Body of Knowledge (PMBoK) and includes the Monitor and Control Risks activity.  The activity I’m describing in this post is similar to the PMBoK equivalent.  At its simplest, this activity assumes risk identific-ation, quantific-ation, prioritize-ation, and mitigatin-ation have been done and all you do is “process” the risk mitigations assigned to you on the risk register and follow up with others to make sure they are “processing” the risk mitigations assigned to them.

But as someone I admire would say, that’s not “the way of the project manager.”  It’s certainly not all that is required for a best practice.  For example, as you review the risk mitigation actions assigned to you and you get others to review the actions assigned to them, you naturally reassess the risk itself and the risk response;  if anything has changed (assumptions, probability, or impact, for example), then you transition into risk analysis or risk response planning.  Further, processing the risk response actions works best as a team exercise, and a superior project manager will involve all appropriate stakeholders in the activity.

If risk response is required, take appropriate action.  For a seasoned project manager, this means delegating any product work.  Also follow up with everyone else who has a risk response action assigned to them.  Verify their action plan, determine status and issues affecting their risk response, and gently nudge them if necessary.

 If there is an effect on the project, then consider use of contingency reserves (risk buffers), escalation, or project change management.

Have I left anything out?  What else is in your cycle of weekly activities for reviewing risks and risk responses?

The Project Manager’s Cycle – Validate Task Status

“Carilyn, your status report says that you completed testing, but the task has four more hours on it?”  “Yes, I ran one more test case this morning,” replied Carilyn.  “But, as of Friday, when you did the status and the time entry, the task was still open?  It’ll finish today, right?”  “Yes, but it was just one more test case.”

Validating the task status within The Project Manager’s Cycle is done concurrently with Validate the Metrics.  For this activity, though, you are reviewing each project team member’s status report (MSR) rather than the metrics that have been reported through tools.  While this series will touch on status reporting in several entries, status reporting itself is a much bigger topic that I’ll eventually address in a future blog series.

The assumption for this PM cycle activity is that team members are submitting status reports.  However, a “status report” can be tailored based on the project context.  I’ve led small efforts – projectlets that are just a few weeks and have 2-3 team members – where I just drop by periodically and get a verbal update.  The point is not the format, but rather the content you need and what you do with it.

First, the content of the MSR and the reported metrics are a “check and balance” against each other.  The reports between them should be consistent;  deviations should be noted and investigated.  For example, if the team member reports on the MSR that they’ve completed a task, but the metrics show forty hours remaining, which is correct?

From the MSR Accomplishments section, note specifically task completions and mark these tasks completed in the schedule.  In the Planned section, note tasks that the team member plans to start and make sure these are assigned to the resource, open, and available for time entry, including that the start date aligns for a near-term start.  These should also be noted for review in the project team meeting (see future post in this series).

Finally, review the schedule the other way.  That is, review open/active tasks for that team member and confirm the MSR documents task accomplishments (e.g., 12 of 15 test cases run successfully).  Also look at tasks in the schedule that are scheduled to start and verify that the team members list them as planned in the MSR.

Any discrepancies need to be investigated, either with a discussion with the team member or during the project team meeting.

Other items to look for in the MSRs include issues (anything that is preventing appropriate progress on a task), risks (anything that may affect a future task), blocked time (environmental problems that prevented the team member from working on any project task), change management (changes to scope, quality, or cost), and deliverable status (is approval tracking appropriately) or milestone status.

Having completed these first two activities of the cycle, you have begun your list of To Dos for the week.  Unexplained variances in the schedule and anything that raises a question or concern from the MSRs goes onto one of your lists:  Issue Log, Risk Log, Commitment Log, Project Team Meeting Agenda, new change request, or your personal checklist of things to follow up on and people to talk to.

Getting good status reports from team members is always a challenge.  Do you have effective techniques for getting them to provide the info?  I’ve listed some content that should be in the MSR.  Do you have additional sections that are useful?

The Task

“Is the PaRC Coding task complete?” asked Evelyn, the PM.  “Yes,” responded Jeff, one of the best programmers, who then continued “I completed all of the coding yesterday.”  “But what about the unit
testing?” Evelyn followed up.  “No, I’ll get to that tomorrow,” replied Jeff.  “But the task includes coding and unit testing,” Evelyn noted exasperatedly.  “It isn’t done until both are done and it’s ready for turnover to the test group.  You know that.  Why do you tell me it’s done?”

I’m trying to build some of the context for presenting best practices, but PM best practices are difficult to document, in this case, because everything is so integrated.  You can’t really discuss one thing being a “best practice” until you have a context for that practice to be best in.  For example, you can’t comprehensively discuss estimating without also including risk management.  You can’t discuss reporting best practices without addressing stakeholder management.  You can’t address acceptance management without addressing scope management, which also has to involve change management.

So I’m going to start with a fundamental and see if I can build a base sufficient to start expanding into more complex topics.  The Work Breakdown Structure (WBS) is a core project management document and the task is the atomic element of the WBS.

Typically a task should be a single component of work delivered by one person.  This would generally be a best practice.  I have frequently made exceptions to this practice, but that doesn’t prevent this from being a best practice.  And knowing when to make exceptions is part of the pragmatic, flexible responsibility of the good PM.

The task should have clear transitions.  The inputs, outputs, and hand-offs (in- and out-bound) should be clearly understood.  This is one of the main areas where I frequently experience problems, when I assume that team members clearly understand their tasks, including Done.

I’ve developed some techniques to address this problem.  PMBoK v4 references the WBS Dictionary, what used to be called the task dictionary.  The WBS dictionary is without question the appropriate reference for this situation.  But who has the time and budget to include one in the project?  What I’ve found that I can do for key project tasks is sit down with the task owner (Owner A) and the owner of the next (successor) task (Owner B).  In this facilitated discussion with Owner A and Owner B, we discuss what is included in the task, what is expected as inputs and outputs, and what constitutes done.  This often identifies differences in expectations by the owners which, without the conversation, would’ve left  some ball dropped.

The key point I make sure to include in the discussion:  Owner B has to accept the results before the task can be closed for Owner A.  Universally the task owners know more about their jobs than I do, so I don’t have to impose the general task scope, all I have to do is make sure each successive owner is clear about the task boundaries.  It’s amazing how many problems this little discussion has prevented.

Call it a dynamic WBS Dictionary, maybe.

Do you have any experience with a WBS Dictionary, or problems with not having one?