Posts Tagged With: Risk management

In defense of Critical Chain

One of the more subtle changes in the Sixth Edition of the PMBOK Guide is the elimination of all references to Critical Chain Method (CCM).

The rationale for this excision was not provided in Appendix X1 of the Guide which provides details of most of the Sixth Edition changes so I can only speculate that this might have resulted from the desire of the volunteer standards committee to cover commonly used tools and techniques for schedule development, and with the addition of agile release planning perhaps CCM became an easy sacrificial lamb.

Many years ago, I worked in an organization where I attempted to introduce CCM as an approach to managing key resource availability challenges as well as shifting leadership focus from individual tasks to milestones.

Unfortunately, this failed miserably.

A fundamental tenet of the methodology is using optimistic activity durations by stripping out padding and by aggregating uncertainty into buffers at the end of activity sequences. I was unable to convince team members to provide such aggressive estimates given the organization’s prevailing culture. Given that a fair bit of padding remained in each activity duration estimate, the buffers ended up being bloated and milestone dates were later than would have been previously planned.

However, some of the key lessons remained with me which I was able to apply later.

  1. Eliminate multitasking of high demand, low supply resources. It’s really tempting to squeeze out every iota of working time from such team members, but the opportunity cost of context switching is much greater than for other team members. So while I encourage the elimination of multitasking for all core team members, if that is unrealistic, at least do it for your “drum” resources.
  2. Centralize uncertainty into contingency reserves and defend those reserves. Calling these buffers does not resonate well with senior management as the perception is that these will be consumed carelessly. Position them as contingency reserves and they can start to appreciate the necessity of having some shock absorbers to protect the timelines from known-unknowns.
  3. Obsess over milestones and not individual tasks. Estimates are probability distributions – some activities are bound to be late and some will be early. A good project manager keeps their eye on the key milestones and while they are aware of the give and take which results from variation in activity end dates, they won’t micro-manage the team to those. This not only reduces perceptions of micromanagement while empowering individual team members, but it also keeps everyone’s eye on hitting the milestone date. Scrum incorporates this principle by focusing team efforts on sprint goals and commitments and not just on individual tasks.

Use of CCM requires a level of scheduling discipline which is absent on many projects and it does lend itself well to deterministic or predictive projects. But just because you can’t use the method as a whole doesn’t mean it doesn’t contain some good practices which could be applied to your project.

 

Advertisements
Categories: Project Management | Tags: , , , , | 5 Comments

How do YOU define project failure?

An early project management lesson learned is that it is a good practice to start with the end in mind, especially when it comes to defining what done looks like. Without working through this at some level of detail, project teams risk experiencing a similar pain to reaching the finish line at the end of a marathon only to have the judges move that line back by a mile.

Beyond defining the criteria for project closure it is also a good idea to ensure there is a consistent understanding of what success will look like. This takes us from the “Why” to the “What”. If there is disagreement on how success is defined key stakeholders might disagree on whether the project was successful or not.

With risks it is recommended that we not focus solely on threats as we might miss the chance to benefit from opportunities. So why spend time only defining what project success is? By doing so we run the risk that stakeholders will assume that any outcome other than project success represents failure.

Don’t think this is an easy task!

At the beginning of a project unless key stakeholders are worried about some challenging schedule, cost or quality constraints, their moods are likely to be ebullient. Forcing them to think about and define the conditions which they feel represent project failure might not be a pleasant discussion but having this information will improve the quality of planning through the life of the project.

A minimal way to do this is to understand the relative priority of project constraints. With this knowledge, when the team encounters a critical issue they will assess recovery options using the context of failure criteria. This information also helps to focus risk analysis and response activity on those risks which will cause project failure.

Our project glass needs to be considered half-full and half-empty at the same time!

 

 

Categories: Project Management | Tags: , , | 1 Comment

Horseshoes and hand grenades? Don’t forget about projects!

It is a common practice in many organizations to do a thorough post-mortem once a major project issue has occurred to understand why it happened, how effectively the team responded to it, and what might be learned from it to avoid or reduce impacts from similar causes in the future.

But what about near misses?

Addressing those would require us to shift our thinking from a simplistic binary view of “no problem” and “issue” to the continuum where near misses might justify some response.

As with all project management activities, the level of effort consumed needs to be commensurate with the expected benefits. On low complexity or low value projects it might be of little benefit to have the team do a post-mortem on “almost issues” as the magnitude of their impact would likely have been accepted. But on more critical projects or those possessing a higher level of complexity, there might be some value while high severity risks are being analyzed to add the dimension of a threshold that should trigger some degree of investigation and corrective action.

But when should this investigation take place?

Let’s consider the analogy of a driver who narrowly misses losing control of their car on an icy road. The ideal time for this self-reflection is within a few minutes of the near miss. If the driver waits till the end of that day the close call will seem less compelling and two days later they would have entirely forgotten about it. This is a perfectly normal reaction of our brains as if we go through life having perfect recall of every dire situation which almost transpired we’d be paralyzed by fear.

This further supports the rationale for regular team reflection on what has been learned.

If a project manager asks team members to think back over the last week or two about what almost went wrong, valuable learnings won’t be lost and could be incorporated into the team’s standard practices. This requires that the team feels psychologically safe so that individuals are willing to share situations which they were responsible for.

We should learn something from the airline industry. There is tremendous effort expended after an airline disaster in identifying the root cause and building safeguards to prevent repeat occurrences but a reasonable amount of investigation occurs whenever an accident which might have occurred is narrowly avoided. Reporting and investigation of near misses is also a very common practice at construction sites. The rationale for this is clear as people’s lives are at stake. With most of our projects we don’t face such extreme situations but scaling such practices would seem reasonable.

Maybe we need to add projects to the old cliché “Close only counts in horseshoes and hand grenades“!

 

 

Categories: Project Management | Tags: , | 1 Comment

Create a free website or blog at WordPress.com.

%d bloggers like this: