Posts Tagged With: resource availability

The perils of percentage availability…

Through education or experience most of us learn early in our project management careers about the dangers of using percentage complete for any activity where the work completed cannot be reliably measured. This is unfortunately the case for most knowledge-based work. While a contractor can examine a wall being built and verify what percent of the work is complete based on how much of the wall has been finished, a development lead looking at the source code for a given function will be unable to come up with more than an educated guess as to what the true status of developing that function is. That is why we are encouraged to ask objective questions such as “How many hours of work is remaining?” or better yet, to utilize conservative reporting methods such as 0% and 100% or (for those in the agile delivery space) Not Done and Done Done.

So why wouldn’t this also apply to resource availability?

Unless you are benefiting from either a project-oriented or a long lived team, chances are your team members will not be dedicated to your project.

I’m not referring to the normally expected non-project activities that everyone incurs such as department meetings, HR activities and so on. While there is an ebb and flow to those, there is usually a combination of historical data (e.g. at least 20% of the month before fiscal year end has been proven to be spent on annual performance review activities) and personal plans such as team vacation calendars to provide confidence about those estimates.

What concerns me is when a people manager gives me a percentage availability. “I can’t provide Bob full-time, but I can give him to you for 50%”. This occurs so frequently that we rarely challenge it unless we are sure that a staffing shortfall will critically impact our project’s objectives.

But what does 50% of Bob really mean?

  • Is it 3.5-4 hours per day, every day for the duration of the project?
  • Is it Mondays, Tuesdays & half of Wednesdays for the duration of the project?
  • Is it Mondays, Tuesdays one week and Wednesdays, Thursdays & Fridays the next week?
  • Is it 75% time for half the duration of my project and 25% for the second half of the project?
  • Or (and this is the most likely case) is it that at the end of the project, if I divided Bob’s actual hours spent working on my project by the potential hours he might have worked if he had been allocated full time, it will be close to 50%?

And what will be the impact to your timelines and other project success criteria if you made the wrong assumption?

So the next time someone gives you a percentage availability commitment for a team member, ask a few questions to really understand how much time that person will be dedicating to your project and when.

If your body temperature is average but half of you is in a freezer and the other half is in an oven you aren’t likely to be too happy!

 

 

 

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

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

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

Create a free website or blog at WordPress.com.