Posts Tagged With: Project performance

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!

 

 

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

Help your team to fire it up!

Summer time in Canada gives us the opportunity to enjoy the great outdoors without having to worry about frostbite! One of my favorite weekend pastimes is to light up some logs in my backyard fire pit, pull up a Muskoka chair and listen to the crackling sounds, smell the pleasant aroma of the burning wood and gaze at the stars. But starting and sustaining a wood fire outdoors does take some effort, not unlike nurturing a team.

Enjoying a good fire normally requires starting with some type of accelerant or fire starter, then some kindling and finally the logs. Just using fire starter or kindling doesn’t work well as you won’t get a long lasting burn. On the other hand, trying to start a fire with just a log is amusing to witness but not much fun to experience. If you have the benefit of picking your team members it might be tempting to only pick people who get along with you, but you are likely to lose out on the many benefits of diversity including a reduction in the likelihood of experiencing groupthink.

Beginners often have a tendency to constantly fuss with a fire. They get worried that it will either extinguish itself or that burning embers might land on nearby flammable materials. Whether it’s incessantly blowing on the fire, smothering it with excessive logs, waterboarding it with fire starter fluid or poking and prodding it frequently with a poker, their micro-management spoils the fire and irritates those of us around them who might be trying to enjoy it. Other people are too hands off as they don’t see the warning signs of a starving fire and end up having to restart the blaze multiple times in an evening due to neglect. Teams work much the same way. Micro-management is one of the quickest way to suck the life out of your team but neglecting them is also a recipe for disaster. As with Goldilocks, our job is to discover what’s “just right” for a particular team.

It’s easier to keep a healthy fire going than it is to start one from scratch. With a long running fire, just when you think the embers have died out, the addition of some kindling and some encouraging puffs of air can bring it roaring back to life. Nurturing a high performing team takes work, but it’s a lot less than the effort required to guide a new team through forming, storming and norming.

Once your fire is going strong, there’s not much to worry about from outside elements. A good fire can withstand light rain showers and will deter most insects from bothering those sitting around it. Strong teams usually possess higher levels of psychological safety which can help team members to face challenges knowing they will be supported by the rest of the team.

It’s getting cold in here so somebody fire it up – Thousand Foot Krutch

Categories: Project Management | Tags: , | 1 Comment

What stories do your charts tell?

Organizing the delivery of project scope into sprints provides stakeholders with an opportunity to objectively assess progress at regular intervals. Comparing what was delivered against what remains in the overall release or project backlog helps us understand when we might be done. Looking at what the team was able to complete in relation to what they committed to complete at the beginning of the sprint can help us assess their self-discipline and delivery maturity.

Tools such as sprint burn-down, velocity and release burn-up charts can provide stakeholders with the power to interpret how a team is doing, but as usual, with great power comes greater responsibility.

Let’s look at two examples which illustrate the danger of drawing conclusions from such charts.

At first glance, the sprint burn-down chart above might be a sign that a team is not delivering in an agile manner and are batching work items till the very end of their sprints which would seem to indicate immaturity.

But before jumping to conclusions, what else might cause a similar sprint burn-down pattern?

  • Work items have actually been completed but the supporting work item tracking tool has not been updated yet. This would be an indicator of poor discipline but not necessarily immaturity.
  • The pod’s Definition of Done includes a task which can only be completed at the very end of sprints – for example, testing within a shared environment, or the completion of independent testing by a team outside of the pod. This should not be a cause for concern if such a constraint cannot be avoided.

How about the following velocity chart which illustrates what a pod has completed compared with what they committed to complete for three sprints?

One conclusion could be that this is an immature pod as they are chronically over-committing and under-delivering. But another interpretation is that the sponsor or some other senior stakeholder is the one demonstrating poor behavior by ignoring the better judgment of the pod and mandating the number of work items which have to be completed each sprint. Addressing that issue will be very different than if the former interpretation is the accurate one.

You can use all the quantitative data you can get, but you still have to distrust it and use your own intelligence and judgment – Alvin Toffler

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

Blog at WordPress.com.

%d bloggers like this: