Every project involves trade-offs. Analysis early on will help you understand the relative importance of all the factors you're considering.
AND I NEED THIS... WHY?
The three most common metrics are time, scope, and cost – often referred to as the "project management iron triangle". And as much as we'd love to deliver projects broadly scoped, ahead of time, and with cash reserves in the budget, we typically get to choose (at most) two out of those three.
So how do you know where to focus your energy if everything is considered equally important? Short answer: you don't. You schedule meetings to discuss minor decisions. You second-guess. You spend a few days (or weeks!) going in one direction, only to back-track later. In short, you waste heaps of time and energy.
Instead of spinning your wheels, take a few minutes to agree on which metrics reign supreme and which you have some wiggle room on. You'll be able to operate more autonomously as the project moves along, and avoid headaches later on when questions about effort and focus (inevitably) arise.
WHO SHOULD BE INVOLVED?
The project's full-time owner, members of the core project team, and anyone outside the team accountable for the project's results.
3 - 6
Running the play
Make sure your team understands that most sliders are inter-dependent: if one goes up, at least one other probably has to go down.
- Sticky notes
- Rubber chicken
battles metrics (5 min)
The basic vectors for trade-off analysis are usually timing, scope, and budget. But you should also consider other metrics important to the project. They may include things like:
- Security – what's your tolerance for risk?
- Resilience – how resilient does a new software capability need to be?
- Extensibility – how important is it to make something that others can contribute to, customize, or extend easily?
- Usability – how easy to use should your final deliverable be?
- Quality – considering your customer experience, how high do you set the quality bar?
- Delight – a bit different from "quality"... is it important that your deliverable put a smile on people's faces?
- Scalability – should you design for fast growth and/or large scale adoption?
Prepare your whiteboard or butcher's paper with one bar for each metric, labeled with a name. These are your scales. Label the ends of each scale with a value: "most negotiable" on one end, "least negotiable" on the other.
Cut your sticky notes in half or thirds to create sets of sliders for each participant to place on the bars. Prepare an additional set of stickies (preferably in a different color) that you'll use as the final agreed-upon slider on each scale.
Set the stage (5 min)
Explain that your team's goal for the session is to reach consensus on what are the most and least critical aspects of the project.
INTRODUCE THE SLIDERS
Review the metrics you've decided to weigh, and ask if there are additional metrics you should create scales for.
Explain what "most" and "least" negotiable means for each metric. For example, if the project is estimated to take 6 weeks and you have a large marketing campaign scheduled, "least negotiable" would be time as it's paramount you deliver within 6 weeks, while "most negotiable" may be scope, as you drop the nice to haves in order to meet your deadline.
Discuss briefly which sliders have dependent relationships, and which are independent. Speed, scope, and cost are typically inter-dependent, while usability and scope may not be.
Silent voting (5 min)
So as not to be biased by the group, have each person write down where they intend to place their sliders on each of the scale.
Once it looks like everyone has made up their minds, have them place their sliders on the bars.
Slide the sliders around (20 min)
Review the scales one by one, and invite the group to discuss why they placed their sliders where they did and get consensus. You'll probably have to revisit some of the scales and slide the sliders around as your team decides how to balance the relative priorities.
When you've reached consensus on all scales, lock in each sliding scale with the "final" sliders you prepared (preferably a different color than the sliders each team member placed).
If using a whiteboard, snap a photo of your scales before cleaning up the room.
You finish in like five minutes.
Reaching consensus very quickly may be a sign that you haven't thought through many edge cases. Throw "what if" scenarios at your team to provoke some deeper discussion. (Or it may be a sign your team is just super-duper in sync. But toss in some "what ifs" anyway 😉)
Be sure to run a full Health Monitor session or checkpoint with your team to see if you're improving.Find your Health Monitor
Take it up a level when you choose the metrics to discuss. Which strategic bets are on or off the table? What are your key areas of investment? What operational metrics are critical to the business? What's the priority of lagging indicators against forecasts and leading indicators?
The pre-work will take a bit more time since each team member probably considers different metrics to be critical.
Instead of wrestling with the "iron triangle", your challenge is to figure out how much time you spend working through your queue, versus how much time you spend optimizing your service offering in off queue time. In other words, how much energy do you spend fighting fires, and how much energy do you spend preventing them?
You'll be thinking about metrics like:
Customer satisfaction – do people feel they received a quality response and resolution?
Time to resolution – how quickly can/should you resolve a request?
Provider satisfaction – you might provide excellent service, but is that sucking the life out of your team and causing burnout?
Customer engagement – how much support should you provide via knowledge bases and FAQs vs. through direct customer contact?
If you drew your scales on butcher's paper, hang them up in your teams area for the duration of the project.
If you used a whiteboard, share a picture of your scales around to your team, as well as your stakeholders. Then print it out and hang it in your team's area. It's fine to capture your scales as a Confluence page, but don't just stash it away there – keep it physically visible if at all possible.
Vous voulez vous tenir informé sur le Playbook ?
Laissez-nous votre adresse e-mail ci-dessous pour être informé de l'ajout de nouveaux scénarios et contrôles de santé.
Vous avez reçu du feedback ?
Posez une question ou laissez un commentaire sur le site de la communauté Atlassian.