A Story About Project Schedule Compression

Introduction

I always thought that project management would become easier over the years. I’ve been working on project management for twenty years and it turns out that it′s harder than ever as the market becomes more competitive.

I’m sharing a scenario in project schedule compression and a particular mislead situation I’ve faced more than once in different companies.

To simplify things I’m writing a fictitious story illustrating the problematic situation, then I’ll give a brief analysis at the root cause and finally share a few suggestions to handle the issue.

A Schedule Compression Pitfall

Our story begins at the project initiation phase when a high-level scope and a high-level schedule are ready to get a first feedback from sponsors and other executives. As a good project manager any possible compressions were already made by fast tracking activities. In this story schedule crashing was not acceptable by the business (fixed costs).

As the meeting with key stakeholders begins in order to get an initial validatation about the project schedule we have the following dialog:

Sponsor or a C-level executive: - We need to cut the delivery date by half! Why do we need all these phases or activities?

Project Manager: - All activities were deemed as required by technical teams.

Sponsor or a C-level executive: - Why are we taking that long?

Project Manager: - Duration of those activities and phases were estimated by our experts based on their past experience and lead times for internal and external services we are rely on.

The sponsor and other key executives take a look at the schedule, they notice some longer activities, they see the critical path.

Sponsor or a C-level executive: - Who is the manager accountable for activities at the critical path? Please call them in to explain why is it taking that long!

Even though the project is in agile mode and even though we have partial deliveries planned along the way the business is still staring fixed at the final outcome for obvious reasons.

Key IT managers are called in; they enter the meeting room!

Sponsor or a C-level executive: We need a smarter implementation that can speed up activities at the critical path!

IT managers and other involved managers seriously try to properly respond to executive challenges proposing a few adaptations.

Purchasing manager: - I can guarantee approval for procurement immediately. The project manager just needs to text me when the request is placed.

The project manager agrees and reduces the duration of procurement approval workflow.

Lead buyer analyst: - I can ask our supplier to prioritize delivery. I can negotiate that, I’ve done this before.

And the project manager cuts the duration for hardware shipment.

Software Development manager: - I can combine our new component that is almost ready and replace it at the initial design to speed up development.

Done, development time is now reduced!

Quality Assurance director: - I can assign our lead tester for this project and he can do the same work on half of the time.

Great! Now testing activities will get done much faster!

DevOps Coordinator: - I can prioritize deployments! We will hold-off anything that is not flagship, except for hot-fixes or other emergency patches. Please reduce software release to just 3 days!

We are now almost getting the pace that we need for this plan to work.

BISO: - I can approve security evaluation as long as they comply with rules A, B and C exactly as designed at this initial diagram.

Now we are done! With this last contribution we should be able to bypass all those architecture committees and security meetings. The schedule is now compressed and the final date is acceptable by the business!

Please note that those propositions have not changed the business scope nor its costs. Those propositions have changed the way the project is executed but kept the same business scope and avoided extra costs, which is great!

So now we are all committed to this new compressed schedule but holding our guts and crossing our fingers that everything goes as well as stated during this meeting. A meeting, by the way, that nobody will remember when the time comes due.

So if this schedule compression is unquestionably logical and possible (there were plausible and/or undeniable arguments) why do we feel so insecure about it?

Schedule Compression Analysis

There is just one thing in this story that makes it dangerous: propositions that made the schedule compression possible were either external conditions or alternative tasks that are uncommon for team members but had success on prior exceptional occasions. And why is this relevant?

A few concepts or terminology to review in this analysis:

• Possibility: feasibility to achieve something.
• Probability: likelihood of a possible event to happen (changes of success). An event that is impossible has a zero probability. An event that is possible to happen may have a probability ranging from 0% to 100% chances of happening.
• Conditional Probability: from statistics; it’s the probability of two or more independent events happening together. What we need to know here is that the more events we want to happen together the less likely they are to occur together.

And there is the trap, right there:

1. All those propositions are truthfully making the schedule compression possible.
2. But all those propositions are also creating conditional events associated with time reduction or replacing normal events by unusual events that makes the compressed schedule less probable in theory.

The new compressed schedule is unquestionably possible, but theoretically less probable to be accomplished!

That is one big reason why we might feel more insecure about a new compressed project schedule!

Schedule Compression Recommendation

I recommend a few additional steps before making a commitment to a new compressed schedule:

1. Assess the probability of the schedule before and after the compression. Take support from the technical team and other managers involved to support estimations.
2. Share optimistic, most likely and pessimistic scenarios to the same executive audience. Explain where and when certain conditions are making a delivery date less likely and why.
3. A new review may take place, if so, do the adjustments and come back again to share the new adjustments or multiple scenarios if needed.
4. Let the sponsors make the bet at the scenario with the probability they can accept. You may find out as I did that sometimes the business is willing to accept small variance on delivery date if they only knew that probability of success could be higher.

Conclusion

Project schedule is still a key asset in project management and most often a sole responsibility for project managers to coordinate. Schedule compression is a common business demand and there are common techniques to accomplish that (crashing, fast tracking, or others). Still, there is a pitfall and a dilemma if we try to compress the schedule by making it less likely or reducing its probability of success. Paying attention to schedule probability and schedule risk is crucial to avoid misleads for the business decision making.

If you would like to talk more about this feel free to leave a comment or contact me!