0

In the last post on Project Acceleration, we looked at whether you had the foundation for making a major change, i.e. a solid understanding of the status of your project, in all dimensions.

Now we look at another fundamental aspect of Project Acceleration: the objective or purpose of the need to deliver earlier.  Unless this is both clear and valid to the team, it is going to be hard to achieve.   Note, this post covers scenarios where the project team is asked to meet a specific new timeline with a new defined delivery date.

If the purpose of the acceleration is just to “speed up the delivery process” without changing the delivery date, then a process that focuses on the operating tempo of the team is more applicable.

Why Accelerate?

There are many typical reasons for wanting to accelerate the project and deliver the project outcomes early.

  1. Recapture Already Lost Time: you are speeding up to either hit the original schedule, or at least to reduce the slippage from an earlier commitment.  This is a common use-case in the project delivery world.  Often as not, this commitment is made in return for getting additional time for an earlier milestone – a self-defeating trade-off of future gain in exchange for current permission.
  2. Respond to a Senior Management directive: e.g. “I don’t care what the reasons are, I want this delivered by 1st April”, plus, maybe, some sort of weak or moralistic rationale to explain. The subtext, easily detected, is a lack of credulity on the part of senior management about estimates and forecasts that the team provided. The intent is to use management authority as a forcing function to drive out sneaky hollow-logs and budget overrun hedges that may be built into the plan.  Let’s face it, everyone pads, don’t they?
  3. Recalibrate the business case: a marginal business case can be improved by advancing the date at which the benefits are delivered, in which case the financial NPV goes up.  Sometimes it’s pure artifice, sometimes there’s been a legitimate calculation or assumption error, or other components of the business case have increased (e.g. cost) so the delivery date needs to adjust in order to maintain the project within corporate financial parameters.

The Worst Reasons

Unfortunately, none of these reasons are compelling and none of them is going to engage the team in a way that is likely to achieve the desired outcome.

  1. Bad Reason #1 is often based on a misplaced confidence in the team’s ability or a misunderstanding of the problems that caused the delay.  Because unless they’ve clearly identified the reasons that they were late in the first place, and have resolved these issues before embarking on the next phase, how or why do they believe that they will be on-time in the next milestone?  Or is it just a “code phrase” that allows both the team and the governance process to slide over a problem without solving it.
  2. Bad Reason #2, the management directive, can be translated to: “we don’t really believe what you are telling us”, and is intended to “make it easier for you to tell us (management) the truth”.  This clearly and emphatically sows the seeds of distrust and destroys engagement.  Teams will just become more protective and conservative, not less so.
  3. Bad Reason #3, the business benefit tweak, is just smoke and mirrors; nothing fundamentally has changed, just the numbers.  We all know that if a team is forced to agree to set of budget numbers, then they will silently (or vocally) disavow themselves of any real commitment. “Ok, these are your numbers, not mine.  You’ll get it when you get it”.

So, fundamentally, if you decide to accelerate based on any of these three reasons or anything similar, it is likely that it will not end well.  Get ready to go through it all again at the next review.

These reasons are superficially important but fundamentally pointless.  More often than not the attempt to accelerate for these reasons is doomed, and will result in the opposite effect: a delayed schedule.

So What’s the Secret?

The secret sauce to any project acceleration is to have a meaningful reason to accelerate and to engage the team deeply in the narrative that surrounds it. This means you cannot accelerate to meet a goal for any arbitrary reason, such as those given above.    This fact should be a mandatory filter on any acceleration rationale.  Having said that, care should be exercised to ensure that there is not some compelling reason hidden inside a proposal that looks like one of the “bad idea” reasons.

The best way to get a team actively working on a faster pace of delivery to engage the team in the narrative of what’s behind the change: in other words you need a good story.  People naturally gravitate to a good story if it has a point. listeners become engaged and entertained.

Building engagement with the narrative behind the acceleration approach gives the team members the WIIFM that they need to engage and invest in the outcome.  Some examples:

  1. Major deals in market: (Almost) every company has a sales function, and major deals have a dynamic all their own.  The deals may come out of left field, or you may go to market to identify a launch partner, and completely luck out with a major deal.  If you don’t deliver according to expectations, the delay *may* create a scenario where the deal can be lost, or at the very least cause serious disruption to other companies when it occurs. In this case I recommend getting access to the sales teams and maybe even the customer to get the story right from them, and a little bit of a back story on why this is actually needed.
  2. Material Change in your company’s environment or context:  you may need to align the project to an earlier date because a new acquisition has a product that is complementary to your project’s deliverables, and a market opportunity can be leveraged.  Or perhaps your company is starting to experience revenue issues, and needs the benefits to accrue earlier.  Or there may be a regulatory change, with a new or revised legislatively mandated start date.  This situation is much easier to sell to your team because it relates to an unforseen problem or change and therefore removes the “why didn’t they think of this earlier” objection, and similar emotions.
  3. Immovable Delivery Date: And last, but often the most common, is a real and compelling version of the first acceleration reason: you have to recapture lost time because you are delivering to a fixed and major milestone, say the beginning of a sports season. In other words you have no choice but to comply.  Alternatively, you may have an exposure to major penalties or reputational issues if you are delayed.  This presupposes that any slippage reason has been identified and the cause corrected, before the acceleration is attempted.  I didn’t put the regulatory change in here because the reason #2 above hasn’t been predicted

There are plenty of other reasons that you and your team(s) will find more compelling than the first 3 disasters.  The most important aspect of handling these situations is early communications in a managed way, and to bring the change process to a conclusion as quickly as possible.

Conclusion

As we can see, there are many reasons why a project sponsors, customers or participants may wish for a project to be accelerated.  As PM you need to filter out the invalid reasons for accelleration.  Bottom line: for anything to be accelerated in a material way, there must be a good story behind it.

References:

  1. Project Action Principles #1: Achieve Outcomes, Rapidly
  2. Principle-Based Project Leadership (Beta Book)