Descoping a project is a powerful tool only the PM has, but it’s like pushing pins into your eyes.

In particular, there’s no better way to bring a project back on-schedule or derisk it in some way. I joke (although maybe engineers don’t take it as a joke?) that I’m more than happy to wield the hammer of cutting, and have more than earned my reputation. But it shouldn’t be surprising that even with descoping’s benefits, it’s never easy. Teams are reticent to drop functionality into which they’ve invested significant effort and whose completion they’ve promised to various Important People. that means there really isn’t any descoping without disagreement, so my title is a bit redundant. Oh well.

Two things to remember

These hold true no matter how you go about the descope.

No one will help you, but some will thank you

It’s both frustrating and gratifying when, after a particularly difficult conversation, people who stayed silent the entire time ping you to say “thanks, that needed to happen”. And it does happen! In any group, there are people who see exactly what descoping needs to be done but for whatever reason – fear, career management, low confidence, not-my-job-ism, etc. – won’t say a word about it. I can’t begrudge them for it, either, since it’s a PM’s job to amplify the voices of those who can’t or won’t speak for themselves. It’s enough to know they’ll thank me after the fact.

There’s no avoiding conflict

Fundamentally, we’re paid to product products of value for the company and for our users. The compensation, well … compensates for the pain we all experience at the workplace. When descoping against disagreement, you have to walk in expecting pain, and consider the right amount of pain to be an indicator of success. (As I was taught, if you walk out of the school exam feeling great, it’s either because you aced it or because you understand the material so poorly you can’t even predict you failed.)

That means if there’s no conflict, you probably didn’t achieve your goal. What does that look like?

In competent teams, total wrongness is uncommon, so descoping conversations turn into nuanced debates about the meaning of “lower priority” and “reduced staffing” and “cut” with each person bringing their personal risk tolerance and evaluation to the table only implicitly. It’s easy to reach an “agreement” based on misinterpretations. This is when you bring all your PM skills to bear (coming from a place of curiosity, thinking out loud, clarifying, getting it in writing, dotting the i’s etc.), especially when you’re not experiencing enough pain.

What’s enough pain? It varies from team to team, but it’s enough to make your day unpleasant. Sometimes very unpleasant. Sometimes it destroys your entire week with conversation after conversation. This is what we’re paid to do.

Some techniques

You can use the techniques below alone, in sequence, or in parallel. But you have to use the same technique(s) on the entire team – you can’t give different people different justifications.

Sequencing

Take something that’s currently a P0, make it a P2, and tell the team they can’t work on it until the P0s are secure. You know they won’t ever fully secure the P0s, but the engineering team is still bullish. In the end, you’ve cut it without really cutting it.

It’s also easy to do this: as a matter of principle, priorities are good and stack ranks are better. As another principle, when everything’s a P0 nothing is. This means you can easily justify taking your requirements and spreading them fairly across P0 - P2. Anything else would be poor fundamentals. The team can collectively decide what’s a P2, but something has to be P2. And there’s your cut!

The trick here is ensuring that people really do stop working on the P2s immediately upon deprioritization.

Easy win

Take an intermediate, urgent milestone (or add one artificially!) and change the scope for that milestone rather than the complete project. Maybe it’s fine that everything is still P0 for launch, but the dogfood deadline is in 4 weeks instead of 4 months, so something has to go. You can use this to bring polish (to a “dogfood bar”) up on the priorities and push whatever else you want down (“just for dogfood, though”). Eventually those temporary cuts become permanent.

The beauty of this is the team gets an easy win: a visible accomplishment they can share with peers and leaders.

Dangling go/no-go

Tell people, in no uncertain terms, that part of (or all of) their feature is currently a no-go to ship until certain things are fixed. This is a bit threatening, so I don’t like using it – but my goodness is it effective late in the pipeline.

This one will spur people to rethink a project entirely from scratch if that’s what’s needed. It’ll instantly move people from whatever they were working on to the item you called out as if it’s an urgent fire.

This one can be painful for folks, so it’s best to avoid, only used when there’s a real fire, and paired with a shit sandwich or partial launch option. (And anyway, perhaps a partial launch is the outcome you wanted anyway!)

Find a trigger

I like to say if the inputs haven’t changed then neither should the decision, but if the inputs do change then we’ll change the decision as much as we need to. Work this to your advantage by finding a trigger – a recent new input – and then using that to change a decision.

There are dozens of possible triggers to choose from that might be happening on your team. As a PM, it’s your job to keep track of what’s changing and how that affects your project. If you go looking, you’ll probably find something! Here are some things that are effective triggers:

• We had a regression elsewhere that changed this feature’s budget.
• An upstream team is in an emergency and will likely cut our request.
• Press just wrote a negative article about something our feature might exacerbate.
• Execs just confirmed a new product theme related to only part of our project.
• Another item was just derisked and this is now the single latest / riskiest project in some domain.
• The requirements docs are due at the end of next month.
• Marketing brought deadlines in by a month relative to our expectations.

The beauty of this is there’s fewer hard feelings and less butting heads. People can blame the externality rather than you, and you can commiserate.

Appeal to authority

This is a great way to invent either a Trigger or Easy Win (above). If you know there’s no dogfood deadline for 2 months but you want to use the Easy Win, just find a VP who needs to try the feature – boom, now you have an Easy Win – or think of the last time a VP questioned the risk level on this project – boom, now you have a Trigger.

The beauty of these is that VPs aren’t fully external. VPs ask about risky projects because you communicate risk; they ask to try the feature because you tell them it’s almost ready to try. You can sometimes create the scenario you need by appealing to authority, with all the benefits of Find a Trigger and / or Easy Win.

Set an impossible bar

A good target is one that balances between the competitive bar, the user needs, and the team’s capabilities. A useful target for descoping is one you know the team can’t meet, but the team is too over-confident to figure it out. When they inevitably don’t meet the bar, you use it as a Trigger to make a change.

The goal here is not to force your team to fail – that’s sociopathic and serves no one.Instead, you set the bar so high that meeting it means you’ve achieved the desired derisk. If they do, you win. If they don’t, you have your trigger. The beauty is you win either way.

Imagine someone wants to contract you for a one-week job you don’t want to do. Instead of saying “no”, you say “sure, for $100k”. If they say “no”, then you win – you don’t do the job – and if they say “sure” – then you’re making so much money you do the job giggling all the way.