FasTraCra--when too much schedule compression leads to explosion
Time is one of the most precious organizational resources, a unique characteristics of time that it can't be compensated if it is lost, this nature pushing everyone -whatever his position is- to make time works for his interest; Team member over estimate his task duration to not work under pressure, project manager sometimes compress it and other times add much reserve the aim always is to save his job, business owner shorten it to get revenue faster, client squeezes it to get benefits early.
Compressing time is important for all stakeholders, fast track and crashing are usually used for this purpose, actually some people think of these two techniques as magic words, once applied schedule magically will be cut to the half or third.
This paper discuss why too much usage for these techniques may lead to explosion and what each party should do avoid this explosion.
I was asked to propose a schedule for a crucial high security project. “This project should be finished quickly; the budget is open, requirements are very clear, and it is easy-like moving boxes. That is it.” My manager kept repeating that whenever he saw me developing the schedule.
After studying the clear requirements, I proposed my schedule to be as short as possible. In that first schedule I moved some sequenced tasks to be parallel (known as fast tracking). I also allocated different resources on the same task (known as crashing). So the total project duration was six months.
Once my manager saw the schedule, he asked me to compress it. I answered, “I already did,” and started to explain. But suddenly something glowed in his eyes when he said “Okay! Now do some fast track and crash.” It did not matter how long I discussed the meaning and applicability of doing that. After a few days when the client saw the schedule, the same glow shined in his eyes and he said the same thing. “Do some fast track and crash.”
At that moment, I remembered my son at home repeating the magic word, abracadabra while hoping to make himself fly or turn his brother into a frog. I gathered the two compression techniques and imitated my son's magic word to come up with, FasTraCra.
Over time, and after observation and discussion with schedulers and project managers, I have become 100 percent sure that, “Too much compression explodes the schedule.” Most projects I have seen with a FasTraCra schedule (compressed too much using fast tracking and crashing), when implemented, finish at least three times over the first proposed schedule. My project was one of them.
This problem is essentially black and white, the plan provides an estimate based on realistic assessments of the work and then you are asked to compress it. Look for:
- Dissatisfaction over the estimates that you provide
- Suggestions that you have padded the estimates to buy yourself more time
- Stakeholders wanting to know how much time can be saved with working harder or a little overtime
What will happen if I do nothing?
If you don't resist pressure to compress your project then you will be faced with a project plan that doesn't provide enough time to complete the work—the amount of work hasn't been reduced just because you have reduced the allotted time for it. You'll try and compensate by having your team work longer hours and look for ways to shortcut the process, or otherwise increase project risk in an attempt to save time. As you start to fall behind schedule, you will get ever more desperate and you'll create an environment where at least some, and possibly all, of the following will occur:
- You will lose confidence in your ability to develop the right project schedule
- Your team will lose faith in you as a leader, and as someone who cares about their welfare
- Your manager will lose all confidence in your ability to schedule and plan effectively
- Your client will lose confidence in you and your company
- Your deliverables will suffer
- You will limit your future in this company and others
Success depends on the ability to consider the positions of the stakeholders, prepare an appropriate response, and communicate effectively with all parties. To develop an effective solution, you need to understand why you are being pressured to compress your schedule, and what is it that is driving stakeholders to ask for the compression (the consider part).
Next, you need to be able to develop solutions that will assist the stakeholders in achieving their goals without compromising the integrity of the project schedule (the prepare part). Finally, you need to be able to communicate effectively with stakeholders about the importance of a realistic schedule, and of the flexibility that you do have to be able to help them meet their goals.
Remembering the concepts of consideration, preparation, and communication, you can build a structured process for dealing with this issue:
1. Build trust
Unless there is mutual trust, top managers will consistently think the project manager/scheduler is adding contingency reserve to the schedule. Clients think the same of any vendor or subcontractor. This problem can be solved through building trust between the different parties.
But how do you build trust effectively? Remember the two key requirements needed for there to be trust: character and competency. They need to see your character; that you are working hard to manage an effective project, bring quality deliverables, and balance the best interests of the company and the client. They want to see that when there is a problem, your first concern is the project objectives, not your own interests. When they can trust you to act in their best interests they will believe you. But in addition to character, a company and its clients need to see competency, that you can do the job.
You need to master the project, understand those compression scenarios, and demonstrate that you have the skills needed to find unique solutions to scheduling and resource problems. Be the one who is the most competent, explain your scenarios and reasoning and show that it is the best for reaching the project objectives. Remember to consider the needs of the stakeholders and explicitly address those. When you demonstrate character and competence, trust develops. With trust your communication is effective—then they will trust your judgment when you object to compressing a schedule.
2. Communicate understanding
First, internally communicate to your manager that what you are delivering is a reviewed and examined schedule, not a haphazard one. There is good reasoning and planning underlying all your scheduling decisions, so explain it. If there is new information or constraints, that is one thing, and a reason to change, or maybe compress, a schedule. But you cannot just compress the schedule for the sake of compression. You know your job and have the best interests of the company and client in mind, and that was one of the considerations used when you planned the project.
Second, communicate to the client when they want to FasTraCra that the schedule you set up is the best schedule for the project objectives. You are open to scheduling changes, but the client needs to understand the consequences of the various compression scenarios they want. Remember, consider their perspective, prepare for their needs and pressures, communicate with character and competence, and seek compromises all stakeholders can be satisfied with.
3. Educate stakeholders
Imagine presenting the schedule with a tip about scheduling, it is an indirect teaching way. Every time you present a schedule, mention the real aim behind the compression, and the consequences of each technique. Share your knowledge and demonstrate your competency. They will view you with more respect and you will have more influence in the scheduling process.
4. Implement peer review
Asking for more compression for a schedule developed by two is harder than by a schedule developed by one. Through the PMO or a senior project management colleague, ask for a review of your schedule. This will have the double benefit of identifying any areas of the project where there may be errors, and will also reassure your stakeholders that the schedule has been reviewed and confirmed as realistic.
5. Use the FasTraCra law
Explain to them that a FasTraCra schedule is against the project's goals at the end. Explain to them that you are trying to protect their best interests by resisting compression. It is not your schedule you are protecting; it is the project objectives and their deliverables. Protect your clients from themselves. The amount of time needed to do the work doesn't change because the time allocated has changed.
Wherever possible use historical information from previous projects, show the client statistics illustrating how projects were behind schedule because of over compression. Carefully explain how over compression can explode a schedule.
6. Say, “No,” the right way
Agreeing to ill-considered schedule compression is never the right step. You have to push back. However, after going through this series of steps you cannot simply say “no.” There are other things that you can do that may be able to assist with delivering an earlier delivery date, such as increased funding or reduced scope.
Tools and techniques remain tools and techniques it has no brain to judge or magic effects to fix things. As one of the project stakeholders it is a must for you to utilize tools and techniques according to a lot of factors, knowing fast track and crashing as schedule compression techniques doesn't mean we have to keep using it repeatedly and blindly regardless of expected execution team performance, unknown risks, critical relationships between tasks, and what project managers and schedulers have been repeated that too much schedule compression leads to explosion (FasTraCra Law).
Garrett, D. 2012, Project Pain Reliever. USA; J. Ross
Senge, Peter M. The Fifth Discipline Field Book: Strategies and Tools for Building a Learning Organization. New York: Crown Business, 1994.
White, J. Chris. 2010. “The Dynamic Process Method.” Dynamic Process Method. http://www.DynamicProgressMethod.com/
© 2011, Imad Alsadeq, and Mahmoud Akel.
Originally published as a part of 2012 PMI Global Congress Papers – Marseille, France.