In the previous article, we established that true alignment requires more than just common goals. This one is about what happens when project priorities change. It requires understanding the criteria and priorities of everyone involved. That’s crucial to get any project off to a good start. Inevitably, outside events will change priorities, which can knock the project off the path to success. New information surfaces, budgets shrink, feature requirements shift, or a new person joins the project. The goalposts have moved.

What’s scary is that it often goes unnoticed. You make a small change here, an adjustment there, and it all seems insignificant. The changes add up but the results go unnoticed. Everyone did such a good job of alignment in the beginning that it feels like everyone is still on the same page. Almost nobody rereads it once the project starts.

Writing it down was necessary, but it’s not enough

In the example I gave last time about planning a vacation, we all started with very clear priorities. Some of those priorities changed during the process, before we had come to a decision. We hadn’t been hiding them. We had just never thought of them until we started talking things through. Multiple priorities shifted in a one hour meeting. Imagine what can happen over the course of a multi-year project.

The project leader often has no authority over any of the stakeholders, but is responsible for a successful project, however that is defined. Without being able to force people to do certain things, the project leader needs to use influence. Influence only works when you know what the individual stakeholders want. Project managers need to catch it when priorities shift. The most common trigger is a new stakeholder joining the project.

When new stakeholders are added

When stakeholders aren’t invited at the start, requirements slip through. Surprisingly, it’s often the end user who isn’t invited. When implementing a new software system, executives, managers, and IT are always involved, but the project often leaves out the person who’s actually going to use the software. The project either hands them a program that’s difficult to use, or pulls them in at the eleventh hour and they wreak havoc on the project.

The Denver International Airport baggage system is a well documented case of this exact pattern. According to a case study by Calleam Consulting, the airport’s project team built its plans for a fully automated system without fully involving the airlines who would actually use it every day. Once the team finally brought airline operators into the conversation, they surfaced a list of priorities the original design hadn’t accounted for. Things like racks for ski equipment, different handling for oversized bags, and separate maintenance tracks. None of this was a change anyone had hidden on purpose. Nobody had asked about it early enough, and by the time it surfaced, it meant significant redesign, added cost, and a launch delayed by over a year.  Link: Case Study

How to stay on track

The project team needs to thoroughly review the project charter or scope statement anytime a new stakeholder is identified. A common trap is that the team asks the new stakeholder for their priorities and adds them to the project without addressing how it will affect the other, existing ones. Denver is a warning of what happens when that review doesn’t happen. The team absorbed each newly surfaced priority into the plan on its own, without anyone stepping back to weigh it against what was already committed.

PMI calls the ability to reign in those changes in a collaborative way a “power skill.” Organizations that prioritize power skills see scope creep on 28% of projects, compared to 40% for those that don’t. They also hit their business goals more often, 72% versus a lower rate for everyone else. The four skills PMI points to are:

• Communication
• Problem-solving
• Collaborative leadership
• Strategic thinking

What’s notable is that this advantage holds regardless of years of experience or certification status. It’s not about how long you’ve been doing this. It’s about whether you’re actually practicing these skills.

Three habits put that into practice:

1. The default answer is no. Any requested addition gets a “not yet” until it goes through a formal review. Not a rejection, just a pause. The point is to stop small changes from sliding in on momentum alone.
2. Retest the original questions, without notes. Periodically ask stakeholders to answer the same three questions from the start, from memory, not from what they wrote down at kickoff. What sticks in someone’s head tells you what’s actually driving their decisions now, not what they said mattered eight months ago.
3. Redo the weighting exercise. Go back to the same criteria and weights everyone agreed on at the start, whether that came from a formal charter or a whiteboard exercise like the one from our vacation story. Score it again with any new priorities included, and be honest about what has to move to make room.

If the team had weighed ski racks and oversized bag handling against Denver’s existing priorities instead of bolting them on, they would have known the redesign was coming, instead of finding out a year late.

Think about the projects you’ve been part of. Some probably went smoothly. Others hit friction nobody saw coming until it was expensive to fix. If you’re seeing a new stakeholder join a project, or you’re heading into a kickoff or a mid-project review, I’d love to talk about speaking to your team or your association. Getting everyone in the room on the same page early dramatically increases your chances of success and reduces the likelihood of expensive overruns.  Reach out here.