Project Management

Articles related to doing projects right

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!

 

 

 

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

Responding to change shouldn’t mean teams face continuous change!

The fourth and final statement in the Manifesto for Agile Software Development states that we should value responding to change over following a plan.

The purpose behind this preference is to ensure that while a plan might be created to guide team efforts, there should be openness from the team, product owner and key stakeholders to encourage and incorporate changes which will deliver greater business value for our customers.

But as with everything, moderation is key as on more than one occasion I have seen team members experiencing virtual whiplash from a high frequency of significant requirement changes.

Teams will become more change resilient as they mature but there is a natural limit to the volume of changes that any team can absorb.

Think of Morpheus fighting Agent Smith in The Matrix. Morpheus is an accomplished martial artist and has full confidence in his abilities to hold his own, but at a particular point in their fight the frequency of Agent Smith’s punches is simply too fast for Morpheus to block.

The team remains busy completing work items but it feels like a random walk to nowhere and morale will suffer as they see that they are regularly taking one step forward and two or more steps back.

Even though the eleventh principle in the Manifesto states that the best architectures, requirements, and designs emerge from self-organizing teams, it is impossible to create a quality architecture or design which is capable of incorporating frequent, major shifts in direction. Frequent major changes will also encourage short term thinking by the team which could cause an increase in the level of technical debt.

This is why it is crucial to create genuine shared understanding and buy-in to a product or project vision upfront and then to translate that vision into a product road map or, better still, a story map. Significant changes to these artifacts should be managed through a lean but disciplined review process which might include temporarily halting the team’s efforts until the impacts of such changes can be properly assessed and incorporated.

The Greek philosopher Heraclitus might have said that “The only thing that is constant is change” but that doesn’t mean we should expect constant change!

 

 

 

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

Does knowledge transfer change with agile?

We have all experienced this: a key contributor announces their departure and a mad scramble ensues to transition their knowledge to the rest of the team.

But does this change when the team is using an agile lifecycle?

On the surface, it might appear that there wouldn’t be any significant differences in how it is done regardless of the nature of the work or how it is performed. After all, knowledge transfer is usually a case of a subject matter expert educating others through either a live session or through some sort of persistent record such as a wiki, a video or an audio recording.

While this is true, there are characteristics and specific practices in agile delivery which can impact knowledge transfer.

Traditional delivery usually relies on individual specialists who remain focused on their role and area of expertise. On the other hand, agile delivery encourages the development of generalizing specialists who will develop a broader set of skills and knowledge. Higher levels of collaboration are also expected in such contexts which increases the amount of exposure that individual team members have to each other’s knowledge.

While this won’t translate into full fungibility across a team, there is less likelihood of only one team member possessing critical information. This won’t happen over night. It will take many weeks of working together as well as explicit encouragement by supporting stakeholders such as functional managers for generalizing specialists to develop.

Another enabler is non-solo work – pair programming, hackathons, mob programming and model storming are all practices using this principle. While the primary purpose of these practices is not knowledge transfer but rather quality and speed, it is a valuable side benefit. Rather than having experts share knowledge in an academic manner, demonstrating how their knowledge can be applied towards completing work items is more effective.

Whereas traditional delivery tended to emphasize documentation as the medium for passing work between roles, agile approaches focus on minimal sufficiency. While a newly formed team might require more documentation to facilitate shared understanding, a long lived team might successfully deliver with much less. The challenge becomes when a new or junior team member joins as there may be insufficient reference material to enable self-learning. But this should not cause any major issues if someone on the team volunteers to pair up with the newcomer to help fill in the blanks.

While the need for shared knowledge is there in all contexts, effective agile delivery can reduce the critical of explicit knowledge transfer.

 

 

 

 

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

Create a free website or blog at WordPress.com.

%d bloggers like this: