TOPIC: How have you used crashing or fast tracking?

Crashing and fast tracking are the two schedule compression techniques that most of our students seem to have some difficulties in understanding as they are preparing for their PMP Exam. So I thought that it might be a good idea to use our forum here for a more general discussion about these two techniques in order to discuss the techniques with some input from actual projects.

Here are my three questions for everyone

1. How have you used crashing or fast tracking on your projects?
2. What lessons learned can you share with us?
3. And of course... How have you studied these two techniques for your PMP Exam?

I would appreciate your insights. Just a sentence or two will be helpful for our students.

My organization sets aside travel funds to fly team members from across the country to one location crash on a project. The lesson is establish a clearer goal statement so the team can project the right options more quickly. When I studied for the exam I simply associated crash with resorces and fast track with the word parallel.

My projects mostly revolve around training development, either as a PM on a training initiative or as a training consultant on a larger project. In the latter case, fast-tracking is very common, especially when we're talking about an IT project involving development of a new system or tool. Because the project sponsors often want the product delivered at the earliest possible date, we often can't wait for the product development to be completed before we start developing the training. This means we do a lot of our work based on the design requirements, not the actual product, and while that allows us to complete the training development in parallel with the technical development, we often find ourselves scrambling to retrofit our training materials to account for a late-stage design changes, bug workarounds, etc.

As for crashing projects, that happened quite a bit when I was managing a training team. Because we were an internal support team that didn't bill other departments for our services, time was our primary concern. We held regular team meetings to gauge everybody's status, and would regularly move people around to add extra resources to make sure we could make a deadline, but at an opportunity cost - every resource I put onto project A meant taking a resource away from project B, and while that didn't cost us actual money, it was definitely an opportunity cost that had to be accounted for.

With respect to software development (Software as a Service) we have projects but also operate in an Agile manner. We've used both fast tracking and crashing as a means of meeting deadlines. However, these techniques to meet the deadlines do come with their own costs/technical debt.

1. Even with continuous deployment of software to our Customers, we have projects that need to be delivered. Recently, we deployed a handful of software releases for a deadline and we needed to run tasks in parallel AND crash the schedule. The tasks we ran in parallel were design/coding/testing which created a lot of quality issues and re-work. We also added developers and worked extra hours to speed up the development. While the deadlines were met, we had to reduce scope, and lower the quality as a result. This work was effectively deferred to a later date and will be addressed in a future project.

2. While meeting a deadline may necessitate these methods, it should be done only after careful consideration. The costs are not only on paper (ie. scope, quality), but also tax the team members by way of morale, accruing technical debt (tough to measure), and likely multiple other factors that may tax the organization indirectly.

3. For studying these techniques for the Exam, I was fortunate enough to have employed the methods already in my experience as a PM so the concepts were easy to understand. My suggestion, if you haven't used or aren't familiar with the methods is to think of a real world scenario that would apply to each case. Perhaps think of a Kitchen that needs to meet dinner service demands a couple of hours early? As the Head Chef, would you call in people as an emergency to speed up the work? Or perhaps you choose to adjust the schedule by delaying tomorrow's prep work in favour of overlapping the day's tasks to meet the deadline. Maybe both?! Try to find a scenario that you've experienced or makes sense to you and you will remember it a lot better.

Jeremy

Dear PMP's students,

This topic is very easy to understand:

1. Normally I use this two techniques on my projects. You have to use it when your schedule fall behind, then it's time for decisions: crashing or fastracking. What you have to think is what is the most important for the key stakeholders (sponsor and client) related to time, cost and quality on the project:

Low budget - no contingencies: then you have to try fastracking. This option is to try to do activities in simultaneous in the critical path but risks can increase and then cause extra cost and low quality as a consequence, but if you succeed it's great a very detail planning it's needed.

Project Contingencies available or if main goal is time but not cost: then use crashing, this means to add more resources to critical path activities i.e. To work over time, to work on weekends, to work 2 hours more daily, to bring more equipment or tools.

2. Lesson learned, is to use this two schedule compression techniques always on the CRITICAL PATH activities, not on the activities with float, beacuse will not have any effect and as consequence you will have unneccesary risks and overcost.

3. For the exam and real world projects you have to analyze the situation and the priorities, if the priority it's time and customer satisfaction then use CRASHING, if the priority is cost then try with FAST TRACKING.

Wishing you success to all of you!!!

Hi Cornelius!

Q: How have you used crashing or fast tracking on your projects?
A: It seems that lately most of my projects have been put in a position to require fast tracking and/or crashing due to external environmental changes. Typically, I will always look to fast track a project before considering crashing. I look to see if there is any way that I can re-arrange a schedule to make it more efficient and meet the new project demands. This takes negotiation skills. My best success has been to call a team meeting with the cross functional partners to work on the schedule together. I find, people are more apt to give a little more when put in a group negotiation session. If the schedule can't be compressed to fit the new demands, I turn to crashing - if the budget allows. This only works when the resources are readily available.

Q: What lessons learned can you share with us?
A: Revisit your project plan often so that you are intimate with the details and dependencies in the event that you need to quickly re-arrange components of the project. Keep talking to your project team to understand areas of vulnerability and risk. Ensure the scope stays tight and that no time is spent on work that is not essential. In terms of crashing, I've learned that we often underestimate the true cost of crashing. Not only do the new resources cost money, there is significant impact to the entire project team which often isn't accounted for. Recruiting, extra team meetings, additional quality control iterations, on boarding time, additional risk reviews, etc...Make sure you take into account the impact of crashing to the overall project and not just the deliverable that you are currently working on. Those costs and demands need to be accounted for.

Q: How have you studied these two techniques for your PMP Exam?
A: Experience was my best teacher. My PMP training put a formal name and definition to what I had innately done.

Cheers!
Tracey

How have you used crashing or fast tracking on your projects?

My experience is in software development, we usually receive customer requests to release at earlier times to meet customer's business objectives. in most cases we do use both techniques in the same project:

1. Crashing: adding extra resources so that tasks can be finished earlier. normally I achieve this by the below options:
a. Adding extra resources. usually such resources are added to handle tasks in the critical path of the project.
b. Working extra hours (ex: 10 hours instead of 8 or on an extra weekend day). in such cases make sure to compensate the team for extra work they do and this can be tied to achieving results .

2. Fast Tracking: Perform tasks in parallel so you can finish faster. Examples as below:
a. Overlap testing activities with development activities. while this will add rework efforts, it will help finish earlier.
b. Handle UAT (user acceptance tests) parallel to documentation and training activities.
c. optimize the project plan and revisit the dependencies between tasks to confirm they are still valid and whether you can work around such dependency (ex: to develop a mobile app, you normally need the mobile portal and web services completed first. to fast track things, we remove such dependency by developing the app against web services mock-ups which will be replaced by real implementation later).

What lessons learned can you share with us?

1. both techniques comes with extra cost (crashing: with direct extra costs of the added resources, Fast tracking: with indirect costs of the risk of rework). so use them only if needed and ALWAYS analyze carefully and document the related risks and the mitigation plans.
2. always use fast tracking first, if it achieves the goal without crashing, it will be better.
3. ALWAYS validate the business need why you are requested to crash or fast track. sometime you can achieve the business need in other ways (ex: de-scope some scope, providing prototypes only may suffice, etc.
4. ALWAYS make sure to align the team members with the business objective and make sure they are aware why they are requested to exert extra efforts.

And of course... How have you studied these two techniques for your PMP Exam?

as for the study, experience helped me easily understand such topics. and generally relating crashing to extra reources and cost while fast tracking is related to parallel tasks and risk of rework was the geneal theme of the questions related to this topic.

I like the way you simplified the techniques especially for exam purposes.

Thanks.