Working backwards

Working backwards from a fixed deadline is something that happens in many projects, but it is something that has never happened to me.  My programme manager came to me yesterday and asked for my project to be finished on a certain date.  He needed to know how this would affect my project and wanted to report to his management team that "it could be done" !

I set about the task, knowing that I need to shave off approximately three months from the plan that I put in front of him, just the day before.  I knew a considerable amount would be swallowed up by adding additional resource, as my plan was only draft and only included man days, without any resource leveling.  I also knew that a few of the tasks could be performed in parallel, as long as there was additional resource, which results in increased cost.

My first task was to understand the deadline.  When he said that the project had to be completed within a particular month, I needed to understand if this was a specific date, or could I make it the last working day.

The second item running around my head was to gain an understanding of the project scope.  Could we cut some scope, would other project dependencies be ready earlier and could we introduce a phased implementation, completing the basic scope for the tight deadline and then having a second development and implementation phase for the remaining scope.

The next piece of the jigsaw to deal with was the resources.  At the moment, as in most companies - I am sure - there are many projects fighting for the same resources to build, develop and implement new projects.  To overcome this, I was told I had carte-blanche over resources and could basically specify the task and then speak with the individual team leaders to understand their resource requirements.  This requirement would then be reported to senior management and we would either recruit, or the schedule would have to change.

Remember the golden triangle... Time, Scope, Cost.  You cannot change one, without affecting the other two.  If I was to cut time, it would potentially increase cost or reduce the scope - or both.

Reducing the time is a usual request for a PM and this can come with some considerable increased risk.  It is up to the PM to understand and report these risks up the management chain and to mitigate as much as possible, without increasing the costs too significantly.

This was an interesting project approach, one that I was very comfortable with, but one that I would prefer not to repeat too often.  I agree all consideration should go into producing an accurate project plan and to ensure the scope covers the business requirements.  The PM must then deliver the scope and keep a tight reign on the budget and time.  By all means, throw resource at project tasks, but be careful of your budget.