0
Picture this: one morning your boss, or your sponsor, or the CEO comes to you and says that you need to accelerate the delivery of your project! You no longer have until, say, 15th May, you now need to deliver by the end of April.  Or maybe the middle of April!!
Why? Because of “blah blah blah”! I say it like that because there is always a good reason; there are a million good reasons: new product launch from another part of the company, changed date for a big event at which your project’s deliverable will be showcased, some sort of executive horse-trading or just CEO whim (of course, that would never happen, right?).
So, as the PM, you need to look at what you can do. One option is to flat out say “No”, and present your own arguments as to why this is a bad idea. You could say “Yes, but…” and give the same arguments. Trust me, senior exec’s often hear “Yes, but” as a “No”. If you have an enormous amount of respect in the organization, this might be acceptable as it stands, but that’s pretty rare.  You also run the risk of being sandwiched between other parties who are either more aggressive or more foolhardy than you.
Some exec’s will be honest about seeking the acceleration option when they haven’t already committed you to that outcome. But you have to think that they wouldn’t have asked the question unless there was some potential upside for them, the division, or the whole company. So you have to think carefully about how you answer that one, too. You may as well think of such a request as a directive.
Regardless of when the request is made, there’s little or no difference in how you go about your next steps.
So now you have to think about if, and how, your project can be accelerated. You have to come back with a reasonable response, one that balances accuracy with effort. We all know that this kind of request can have immediate and often deleterious effects on a team. These effects can occur just because the question is asked at all! It introduces increased uncertainty into the project team, which can undermine current effort and engagement “So why am I busting a gut if there’s going to be a major change”.  It can allow some people to game the project: “But I thought we were going to change priorities, so I slowed down on xxx!”.
Now these reactions can occur whether you are going to accelerate, delay, or change scope.  But when you are trying to accelerate the last thing you want is to come out negative right from the first step.
In many ways, a PM is like a physician: “First, do no harm” is the primary directive for a PM. Everything you do needs to leave the project better off.  And starting to investigate a change of any kind can violate this directive, easily.
So, what can you do?  How do you determine viability of acceleration, without ending up in a nett loss of momentum or progress, even if the acceleration process doesn’t materialize?
And you have to keep in mind that it just might be possible, even without pulling the obvious levers such as scope reduction.  Who’s ever worked in a software development project that was running at peak efficiency?  This is the fallacy of the “Iron Triangle” at least for software: there are unknown and non-linear relationships between all factors in a project.  Sometimes great change only occurs under great pressure.  Maybe you can find the particular optimization that does produce significant acceleration.  How good would that be?
Over the next few posts I will look at the key aspects of this question, and provide recommendations on how this can be approached.
The next post will follow on from that last thought: “Never say Never”.
References:
  1. Project Action Principles #1: Achieve Outcomes, Rapidly
  2. Principle-Based Project Leadership (Beta Book)