In my previous blogs, I describe the framework around which you manage a project, the process groups, and we started with the first knowledge area ‘Scope’. I now continue with the second knowledge area - Schedule.
'Schedule Management...It’s not about that multi-page Gantt chart that only you understand, took you a week to create and is wrong before you even mailed it to your boss....'
Everybody knows what a schedule is, right? It’s one of the first questions your boss is going to ask you – ‘when are you going to get this project done by?’ It’s also a knowledge area that affects all the others to a high degree. A late running project is going to cost more, increase procurement, de-motivate teams and make your key stakeholders want to interfere. In my industry - the semiconductor sector - this cost can run into millions of dollars. As such it’s one that you need to get right and yet, when I completed my PMP certification I was not presented with the anticipated crystal ball!
This is because running schedule management is not about predicting the future. It’s not about that multi-page Gantt chart that only you understand, took you a week to create and is wrong before you even mailed it to your boss. It’s instead about knowing what you have to do on the project, knowing, based on current understanding, how much resources a task is going to take and knowing when the right people are around to do that task. Once you have a grip on this knowledge, you begin to have a bit more control of future events and can react when that inevitable curve-ball comes your way.
So let us look at a few ways of controlling your destiny:
Rolling Wave Planning
Remember that multi-page Gantt chart where you had planned the last day of the project 6 months in advance? How accurate do you think that is going to be? I don’t think many would put any money on it. So why have you planned that far out in such detail? The truth is that it is not necessary to plan in detail such distant periods of the future. At that distance a high level picture is going to be more realistic and useful. Reserve the detail for the immediate future. As a general rule of thumb:
- up to 2 weeks in the future, plan to the day
- 2 weeks to 3 months, plan to the week
- greater than 3 months, plan to the month
You are then focussing your energy and time more efficiently.
I often require the ic design engineers on my team to estimate their task durations for me. There is more chance of them committing to a task if the duration of that task is estimated by them instead of being dictated to them by me. But often there are blank faces staring back at me when I ask that question, so I have to give some prompting:
- Have you done this before? (Analogous) If yes, how long did it take then, if not…..
- Have you done this before but more simpler/more complex? (Parametric) If yes, scale the time i.e. a 1M instance block took 6 weeks then a 2M block might take 12 week, if not….
- Give me your optimistic, pessimistic and most likely durations? (PERT) Duration = (O + P + 4M) / 6. Still no idea, the task is too complicated….
- Let’s decompose it into sub-tasks and try again on each (Bottom Up)
Critical Path Planning
A good project manager will know the critical path of the project. That is the chain of tasks and dependencies where there is no room for something to go wrong. Any task that gets delayed will delay the project unless something is done to rectify it. You can use a Gantt chart, a spreadsheet or any other tool of your preference to work it out, just as long as you have considered the question. I also find being able to tell your manager what the critical path of a project is on a moment’s notice will stop them asking to see the useless multi-page Gantt chart which you haven’t created because you are using Rolling Wave Planning!
Now we know our critical path but what do we do when a task on that path slips? From experience, the “please work harder to catch up” request rarely fixes the problem. So unless your team really are taking it easy there are only two things you can do to avoid slipping the project:
- Crashing – We can add extra resources on to the task but it must be a task that can be divided up and can be multiple assigned. Also, be aware of Brooks’ Law: adding extra resources onto a late project makes it later. The extra resources rarely hit the road running and will require training, taking time away from the existing team. If you are too close to the end you may not make up on that loss.
- Fast Tracking – We can start a task before its predecessor has finished at the risk of rework. For example, if we are building a house we would normally wait for the foundation to be completed before building the walls but we could fast track the wall building in certain completed areas of the foundation. Risk is if we discover a problem we’ll have to knock down those walls and start again but if not we’ve managed to save time by parallelising the activities.
This is a brief insight into some of the key concepts of managing Schedule but with just these you should be able to clear a bit the fog that obscures the future. In the next blog, I will continue our examination of the knowledge areas with the Cost knowledge area.
Andrew Miles PMP
Andrew Miles is a physical implementation engineer turned project manager. He is PMP certified and has led many projects for a number of tier one companies. He helps to run the Sondrel Project Management Office (PMO). If you'd like to know how Sondrel's project managers can help your project then please contact firstname.lastname@example.org.
You can find additional information on Sondrel's Project Management and other consultancy services on the Sondrel Solutions website pages.