Posts Tagged With: agile project 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.


Categories: Project Management | Tags: , , , , | 6 Comments

Minimal sufficiency applies to tooling just as much as it does to documentation!

“Working software over comprehensive documentation”

This value statement from the Manifesto for Agile Software Development is a reminder to remain vigilant that the by-products of our product or project processes don’t distract us from delighting our customers and stakeholders. For organizations which have onerous, document-based delivery standards, it serves as a guiding principle to lean out methodologies focusing on the minimal set of information required to meet delivery and control needs. This is usually accomplished through elimination, consolidation and streamlining of documents.

But what about those companies who have implemented tooling to support delivery in place of documentation? Just because we have moved from standalone documents to one or more supporting applications doesn’t mean we should not apply the same principle of minimal sufficiency.

Here are three ways I’ve witnessed this principle ignored:

  • Multiple point solutions with overlapping data elements, conflicting workflows, and differing nomenclature. This often occurs when delivery tooling is procured in a distributed manner. For example, a Business Analysis leader might select a requirements tool, a Quality Control manager has procured a test case and defect management tool and so on. Project teams get confused by how the different tools connect together and the likelihood of data accuracy, consistency and completeness defects increases. While detailed reporting can usually be managed easily, project/product-wide or portfolio-level reporting becomes extremely difficult.
  • Not disabling the fields and features which are not required. You might ask who would fill out a field or use a feature which they don’t need to, but you’d be surprised at the creativity of teams at using unused fields as a means of ferreting away some information they believe is valuable. Beyond the potential for field or feature abuse, a bigger concern is team members getting distracted or overwhelmed by the complexity of a solution.
  • Tooling which does not map to the information needs of team members. Its become a cliché, but one which continues to be ignored – don’t buy and implement a tool if you don’t understand the process it will be supporting! If the tooling does not help team members do delivery activities, then they will treat it as an afterthought and continue to use more useful, home-grown solutions.

I am not encouraging the development of delivery tooling in house or engaging in significant customizations to third-party applications as neither approach is appropriate for most organizations. It does mean you should be spending some effort up front to identify the key data elements which will be needed by different contributors to the delivery process, defining the minimal set of reporting and workflows required, involving an actual delivery team in the tools evaluation process, and working with vendors to safely disable or hide all non-essential features.

So before patting yourself on the back that you’ve migrated from delivery documentation to online information make sure that you haven’t just replaced one source of waste with another!


Categories: Agile, Project Management | Tags: , | 2 Comments

Improving portfolio management must be part of an agile transformation

When we think of an agile transformation, improving portfolio management might not be high on the organization’s list of priorities.

But what happens if your organization doesn’t have an effective and efficient portfolio management capability?

There is a greater likelihood of having too many active projects which increases the risk of resource shortages. Instead of having a dedicated team of primary roles for a project, most team members will be multitasking between multiple projects. This makes it impossible to accurately estimate capacity during iteration planning and usually contributes to a team missing their iteration commitments resulting in delivery delays. Multitasking also increases the effort to have a consistent understanding of the product and can impact quality as team members might be delivering based on stale knowledge.

If multitasking is not a concern, stealth or low value pet projects might be consuming resource capacity which is required to effective staff more strategic projects. This will cause delays to these projects.

Finally, for secondary non-dedicated roles which are needed to contribute to specific work items only, a lack of visibility into when they are becoming available will be a further source of delay.

If governance committees aren’t selecting the right projects which are in alignment with strategic objectives, and only kicking off as many projects as can be effectively staffed, it won’t matter how efficient, empowering or customer-centric the organization’s delivery practices are. In addition, if the existing portfolio governance practices are inefficient and onerous, by the time a team has finally received funding approval to get started with delivery, they might have insufficient time left to deliver even minimal value to exploit a market opportunity or to meet a regulatory deadline.

Portfolio plans are useless, portfolio planning is indispensable.

Rather than having business executives, finance analysts and PMO staff spending weeks coming up with the perfect roster of projects for the next year only to realize a month or two into the year that their plans have been disrupted by domino effect delays, new priorities or resource shortfalls, portfolio planning needs to be an ongoing activity. To enable this, a lean but effective resource capacity management capability also needs to be in place to ensure that portfolio decisions are being made based on a current and accurate understanding of resource availability.

Agile delivery is not a silver bullet.


Categories: Agile, Facilitating Organization Change, Project Portfolio Management | Tags: , , | 1 Comment

Blog at

%d bloggers like this: