Project planning is all about figuring out when we are going to finish our project and how much is it going to cost. We typically start with a fixed start date and then figure out what the end date and associated cost may be.Why then, when planning our day to day lives do the very opposite and reverse engineer the plan in order to achieve our goals? For example, “if I need to be at work by 9am , I probably need to leave the house by say 7.30am” or “in order to get my Christmas cards delivered on time, I should make sure they are in the mail no later than say the 10th December”. In other words, we adjust our start time in order to give us a high enough confidence in achieving our desired finish time. So perhaps, it’s time to re-visit our philosophy when using project scheduling software to plan our projects?

The premise of CPM (critical path method) scheduling hasn’t changed in decades: you define work as tasks; you define how long each task will take; you link the tasks together with logic and then you calculate start and finish dates using the CPM methodology. This can be as simple as into running what is known as a forward pass to calculate what are known as early dates (the earliest dates we can adopt); then run a backward pass to determine what are known as ‘late dates’ (the latest dates we can adopt) and the difference between the two is then what we call float. However, this all assumes a FIXED start date and a VARIABLE finish date. Dare I suggest, there may be a better approach…

Most projects are created from project stakeholder objectives – “we want to build a new widget” or “we see an opportunity to take market share by developing a new solution”. These objectives invariably are tied to some type of time requirement e.g. ‘we need to launch before the holiday period’ or ‘we are contracted to be ready by the first of the year’. What I am suggesting here is that most projects do actually have a pre-determined expectation with regards to completion date. So with that in mind, I would like to suggest that the way we plan these projects should also be in context of these finish dates rather than the emphasis being ‘when do we think we can finish based on our project plan?’.

After spending my entire career to date working on CPM-related software solutions, I am not suggesting for one minute that we ditch CPM and start afresh. Instead, I am suggesting we can take the traditional look-forward approach of CPM and re-purpose it to look backwards as to when do we need to achieve certain milestones in order to successfully achieve our defined finish date.

Why not start with a fixed finish date and base our CPM date calculations on this fixed finish date? When running our forward and backward pass, why not just run our CPM analysis backwards – i.e. run the forward pass backwards from the fixed finish and then the backward pass forwards from the calculated start date to give us the required schedule dates that would enable us to achieve the fixed finish date? But what if the resultant start date isn’t possible e.g. ‘we need to start last week in order to achieve our desired completion date’. Well, I actually think that is OK as what it does is then force us to re-plan; accelerate specific tasks and add more resources etc in order to come up with a realistic start date.

For those of you working in an agile planning environment, in many ways, you are already adopting this approach: you are working to a fixed (set of) finish date(s) and you complete when these dates occur rather than when the total scope is achieved. i.e. You are fixed finish date focused rather than working to a variable finish date. Traditional CPM scheduling tools such as MS Project, Primavera or Deltek Open Plan typically adopt a fixed start/variable finish approach and as such, in many ways, go against the grain when it comes to agile planning. However, if we just tweak our CPM philosophy to do the forwards pass backwards against the desired fixed finish date and backwards pass forwards (we’ll need to work on this terminology!) then I truly believe we will be taking CPM to CPM V2.0 and will broaden our value as an industry to the rapidly growing trend towards agile planning.

Sometimes, it takes a step back in order to step forward. Stepping back from the desired finish date so as to determine when we actually need to step forward with the start of the project seems to make total sense to me.