As a project manager, you go with your project schedule to the stakeholders, to the sponsors, and you tell them that this is going to take, say, seven months. What answer can you expect? They will say, 'Can you shrink it? Can you do something about it so this can be compressed in five months rather than seven?' Now, this is a usual problem, or I would say, a usual challenge a project manager will face where they need to figure out how can we compress the project schedule. And in many situations, the need might be really valid. There are business reasons for shrinking that project schedule, and you may also want to do things faster for your own project life, for your own things.
Now, if something can be done faster, then why would we not be doing it in the first place? The answer is that there may not be an ideal way of finishing the work faster, but there could be some risky way or an expensive way to get this work in a shorter duration. If, without taking risk and without spending money, if you can do it in a shorter duration, you should be doing it. You don't have to apply the compression technique there. This is just a normal project schedule. But when you take some chances, when you pay for your schedule compression, we get into a scheduled compression technique.
We are discussing two simple schedule compression techniques: one is called fast tracking, and another is called crashing. So let's take a simple example. You may come up with a project schedule. You may have a three days work of an activity A, so this activity A works for three days. Then you have another activity which works for four days, and then you have another activity which works for three days. So activity B, activity C. So, one, two, three, four, five, six, seven, eight, nine, ten. So, the project is finishing on day ten. Now, you may want to figure it out, can I do it in, say, eight days? Now, you look at the schedule and say, if these two things can be done in parallel, we can do it in eight days' time, assuming the activity A and B is performed by different people. Now, if they would have been done in parallel, then why we have shown this particular dependency, which is a finish to start dependency?
Now, you get into the details of these dependencies. Are they mandatory dependencies or they are optional dependencies? They are recommended dependencies, they are good practice dependencies. So, if you figure it out there is no technical dependency, there is no hard logic, there is a soft logic, we prefer to do after A, B, since there are some uncertainties which we may discover when we are working on A, and if we do them in parallel, there could be some risk of rework, and that's why it is told to do them in a serial sequence. So, when you find these discretionary dependencies, if they exist in your project schedule, you can think of doing something like, can I bring this little forward till here? Can I start this activity B somewhere here itself? And if it may take four days, then this duration gets evaporated and my project may get finished by day eight because you are bringing everything on the top forward. So, the essence of doing fast tracking is we bring previously serial activities in parallel. So, in your first schedule, there were some serial activities, and you are bringing them in parallel, and you are doing fast tracking. We are assuming that there were resources, like you could do it, there are resources available to work on this. So, they were anyway waiting for activity A. The another thing we are assuming is that only the discretionary dependencies can be worked in this particular way.
Benefits of Schedule Compression
Improved timelines: By compressing the schedule, project managers can complete the work faster, and avoid negative impacts on stakeholders.
Costs: By shortening the project timeline, project managers can reduce costs associated with staffing, materials, and other resources.
Project quality: With a compressed schedule, project managers can focus on delivering high-quality work and meeting project objectives, without sacrificing quality.
Drawbacks of Schedule Compression
So, what could be the downside? The downside is those dependencies which were recommended, were recommended based on some reasons, they were good practices. And when you are making these things parallel, there is a high risk of going off rework because by the time you finish this, you realize that the people who are working on activity B, who has taken some information from activity A, may have to rework on it, and that can impact the project duration. So, this is fast tracking. Now, what is crashing? Crashing is relatively simple. We are not changing the project schedule; we are just adding people or resources to it. So, somebody saying that I take 10 days to do activity A. I say, what if I allocate three people to it? Can I make it four days? Simple. So, can I just crash the schedule without changing any dependencies of it?
In general, crashing increases the cost because we are assuming these people are pulled up for crashing particular activities. In some context, you may have people idle, and you may just put them on extra things. So, when you look at a PMP question, it's difficult to see what was the overall project schedule is, but in the general belief in a normal circumstances, we believe that crashing will increase the cost because we are adding more people to it. Fast tracking will increase the risk because we are avoiding some of the recommended dependencies. Another problem which can come with the crashing is that it can increase the communication cost. Many times adding people makes the work slow rather than fast. So, there is a risk associated with that as well. But as far as the PMP exam is concerned, you can just fairly say, yes, crashing means putting more gas to it, putting more people to it, and trying to do things faster than expected. And by putting these two techniques, you can shrink or compress the project.
See also: