One of the main concerns for project managers is delivering the project on time. More often than we would love to admit, this can be hard, and a variety of reasons explain why it can be a challenge (events, client expectations, business need, etc.).

Either while we’re planning the initial schedule, or as the project evolves, there are many different ways to help shortened a schedule so you can deliver your project on time.

In the past, I’ve written an article that listed a few tips to help you out, here is complementary information and more alternatives:

The two typical tools that can applied to all projects are the following:

Fast tracking

Fast Tracking consists of starting a phase of a project sooner, overlapping with the previous phase.

For example:

○        If design is only partly approve, development could start earlier with what is approved;

○        If only parts of the projects are developed, QA can start for those pieces instead of waiting for the very end of development. This could be considered more of an agile approach.

Pros:

○        The duration that the 2 phases overlap is the duration removed from your overall schedule.

Cons:

○        The more you fast track, the more risk you add to the project. For example, unapproved design parts that are being finished might have an impact on what was approved, and if development was started, there is a risk of rework. If you decide to fast track even more and develop before any design is approved, you add risk of rework if the client approves only parts of it (or none of it!).

Crashing

Crashing is adding more resources to tasks so their duration is reduced. If you are working with external resources, it could also mean paying more to have a deliverable done faster.

For example:

○        If a website requires 240h of back-end development, and was planned with 2 resources for 3 weeks; you could add a third developer;

○        Overtime.

○        Third-party is developing the website you designed, they will deliver 2 weeks sooner, but at a cost.

Pros:

○        Tasks will get done faster, meaning the project’s duration can be reduced.

Cons:

○        Adding more resources can be costly, meaning the budget will take a hit. In our example above, separating 200h of work between 2 developers does not necessarily mean 100h each, just like you will not get your website done in 1 hour with 240 developers. There is added management time to communicate information to more people, there is also overhead between these people so they can communicate who does what, and if whatever they are working on is linked to one another, one’s code affect the other’s;

○        Too much overtime will tire the team, and if abused, might have worst consequences like team members leaving or left unmotivated to go on.

There are also several other ideas that can be applied to some types of projects:

Separate project into different phases

Applicable for many types of projects, its scope can be separated into more than one delivery until the project’s completion.

●        For example:

○        If a software is due in 2 months since a conference is being held shortly after, only part of the software might be realistic to be delivered. You can decide to include fewer features for example, planning to roll-out updates in the subsequent weeks;

○        If a massive social campaign is starting on a certain date and you have an absurd quantity of posts to create, they do not need to be all created for the launch of the campaign. A first batch could be ready for the launch, and while those are being shared with the community, a second batch can be done, and so on.

●        Pros:

○        Allows the on time delivery of what is realistic. This can give an enormous amount of flexibility with a project that has an unrealistic deadline, or a typical client expectation to get a project out the door as soon as possible.

●        Cons:

○        This can add costs to your project. If a website is going live with half its pages, and you plan updates every week to add more pages, this creates the need for more deployments, which adds costs;

○        This may not fully satisfy your stakeholder(s), so it is important to manage this expectation as early as possible, ideally at the very beginning.

Reduce scope

A scope might be defined by stakeholders’ requests, or might be defined by what the team thinks is ideal for the project’s success. However, sometimes, there is just not enough time to do everything, and splitting the project might just not work. In these cases, reducing the scope might be your best bet.

●        For example:

○        A client asks a contest in time for summer, and they have enough budget to do something “cool” where users play a mini game to enter the contest. Unfortunately, they have decided to go forward with this last-minute, leaving very little time before the deadline. This might be a case where even if budget permits it, the idea of the contest might need to be reduced to something simpler like a simple contest where users fill a form.

●        Pros:

○        Less work means the project can be done faster.

●        Cons:

○        The client might not be fully satisfied with the reduced scope;

○        The grade of the project is diminished since it wasn’t built as it originally should and might not satisfy objectives as much as it could have been.