Project Management

7 Reasons to crash your schedule

From the The Money Files Blog
by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from RebelsGuideToPM.com.

About this Blog

RSS

Recent Posts

How to learn AI the sensible way

Making sense of project cost reports

How real PM mentoring actually works

The Accidental Product Manager: What project managers need to know

How healthy are your project finances?

Categories

accounting, agile, ai, appraisals, Artificial Intelligence, audit, Backlog, Benchmarking, benefits, Benefits Management, Benefits Realization, Bias, books, budget, Business Case, business case, business case, Career Development, Career Development, carnival, case study, Change Management, checklist, collaboration tools, communication, Communications Management, competition, complex projects, Conferences, config management, consultancy, contingency, contracts, corporate finance, corporate finance, cost, Cost Management, cost management, credit crunch, CRM, data, data security, debate, Decision Making, delegating, digite, earned value, Education, Energy and Utilities, Estimating, events, FAQ, financial management, financial management, forecasting, future, GDPR, general, Goals, Governance, green, Information Technology, Innovation, insurance, interviews, it, Knowledge Management, Leadership, Lessons Learned, measuring performance, Mentoring, merger, methods, metrics, multiple projects, negotiating, Networking, news, Olympics, organization, Organizational Culture, outsourcing, personal finance, Planning, pmi, PMO, PMO, Portfolio Management, portfolio management, presentations, privacy policy, process, procurement, product management, productivity, Program Management, project closure, project data, project delivery, Project Success, project testing, prototyping, qualifications, Quality, quality, Quarterly Review, records, recruitment, reports, requirements, research, resilience, Resource Management, resources, risk, Risk Management, ROI, salaries, Schedule Management, Scheduling, scope, Scope Management, security, small projects, Social Impact, social impact, social media, software, software, software, Stakeholder Management, stakeholders, Strategy, success factors, supplier management, team, Teams, testing, testing, timesheets, tips, training, transparency, trends, value management, vendors, video, virtual teams, workflow

Date

linkedin twitter facebook Request to reuse this  

Categories: Scheduling


Too lateCrashing your schedule is hard work and not something that is advisable in many cases. So why would you do it? Here are 7 reasons why schedule crashing might be the right thing to do.

1. To get the greatest schedule compression

The main reason for crashing your schedule is to get the project done faster. If you need to bring your project’s end date forward then crashing gives you the most schedule compression for the least impact and the smallest cost.

2. When part of the project jeopardises progress

You could also look at crashing when you are facing one part of the project putting the rest of the project at risk. If a particular workstream isn’t going well it could suddenly become the route of the critical path. That might be OK, but equally you might feel that this difficult strand of work is going to hold the rest of the project to ransom. Crashing the schedule around those tricky tasks is one way to get yourself out of difficulty.

3. When meeting a fixed deadline

Projects require change and changes (however formal and appropriate your change control processes) have a habit of adding more time into the plan. When you are dealing with fixed date projects that’s not a good thing. So what happens when your necessary and obligatory changes start adding more time to your fixed date project? You have two choices: tell the project sponsor that you can’t do it and that your end date has to change or try crashing and see if you can claw back some time.

Whether you choose to crash or not will largely depend on your relationship with your project sponsor and how ‘fixed’ your fixed date project really is. I know that many project managers are given a fixed date to deliver by but with this often has some flexibility (especially if the compulsory changes that add more time are requested by the project sponsor).

4. When you are delayed

Delays early in the project necessarily have an impact on later work. You might consider crashing your schedule as a way to make up for some of the lost time.

5. When the team is needed on other work

And now we reach the reasons that are to do with resources. Your project simply might not be the most important thing happening in the business right now. Your team might be needed on other projects – or at least a particular subject matter expert might be.

Crashing your schedule is one way to free up certain resources more quickly. You could look at crashing a workstream so that your critical resources are available for other tasks or projects. The alternative to this is that you let them go (or are asked to let them go and can’t say no) and then find someone else to do the work. That’s a valid route too but depending on how far you are through the project you might find it easier to simply crash and deliver what you can with the original resources earlier.

6. When another resource is free

Sometimes the opposite happens – more resources suddenly become available. Ooo, more people for your project. The impact this can have on your schedule can go one of two ways:

  • You add an additional resource, refocus the resource allocation and deliver on certain tasks faster

Or

  • You add an additional resource and it takes them ages to get up to speed so actually you don’t make any time saving at all.

Only you will know which of these scenarios is most likely on your project, and who the extra resource is matters hugely. A junior programmer who has no experience on your project is not likely to gain you much time. But an experienced technical architect who has always kept half an eye on the project and now is available to complete some solution design work alongside your existing resources should speed things up for you dramatically.

7. When another resource needs training

Finally, you may face a situation where you have a resource who is not contributing effectively to the project because they simply don’t have the skills. This hopefully doesn’t happen to you too often – ideally as project managers we would select people for the project team who have the skills we need to get the job done. However, I’m sure you are aware of situations where either ‘the skills we need to get the job done’ were not defined or changed halfway through the project or we couldn’t get a resource with the appropriate experience allocated to the project.

If you have to let someone go on training they obviously won’t be working on the project during that time. If they aren’t working on the project, then their tasks won’t get done. If you don’t have someone else to pick up their work, this will push their overall delivery milestones out.

You may find that crashing the schedule gives you some more slack around their work – either for them to get work done before they go on training (probably not if they don’t have the skills to do their work in the first place) or to speed things up when they get back.

Would you agree with these? What other reasons have you found in the past to crash your schedule? Let us know in the comments.


Posted on: August 19, 2014 11:43 AM | Permalink

Comments (11)

Please login or join to subscribe to this item
thanks for the valid sharing. Based on my experience, we've crashed the schedule due to pulled-in deadline in view of Biz needs.

--Vijay

avatar
Elizabeth Harrin Director| RebelsGuideToPM.com London, England, United Kingdom
Business needs is one of the main reasons for having to deliver projects more quickly, so that makes a lot of sense to me. Thanks for your comment.

avatar
Joseph Fernandes Project Manager| ADP Canada Toronto, Ontario, Canada
Great points, thanks. Where I work, we have a habit to do some analysis first and I find that we crash only when fast-tracking will not accelerate the schedule enough (or we deem that it will not). For example, I analyse a critical activity involving a supplier dropping off a trailer on a venue at the same time as cabling is placed/contained to just outside the area the trailer is set. Then the trailer supplier can connect the wire inside the trailer to the cable right away to enable electrical power. In this case, ensuring the activities happen simultaneously is not enough, because inspection and testing is required to order power, so crashing occurs to bring in those resources when required.

avatar
Elizabeth Harrin Director| RebelsGuideToPM.com London, England, United Kingdom
Joseph, thanks for that example - very helpful to see how it works in practice!

avatar
Yaman Bdaiwi Projects Control Manager| Al Geemi & Partners Contracting Co. LLC United Arab Emirates
Good Article indeed.

avatar
Atique Khan Project IT Consultant| Tata Consultancy Services Pune, Maharashtra, India
Nice article to refer upon :)

avatar
SHADAV MOHAMMAD ANSARI PMO| ITC INFOTECH INDIA PVT. Ltd. New Delhi, Delhi, India
Thanks for sharing good article. in my cases , generally we go for crashing the projects " team is required on another work".

avatar
Mohd Faizal Ismail Head PMO| Multimedia University Cyberjaya, Selangot, Malaysia
Thanks for sharing.

avatar
Patrick Joseph Dabi Moncton, Canada
Good read. Thanks, Elizabeth!

avatar
YEN-WEN LIN Director| TJ & Associates Consultancy Taipei, Taiwan
Thanks for sharing.

avatar
Mohamed Baiumy Dar Al-Handsah New Cairo, C, Egypt
Good Article, Thanks.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"All progress is based upon a universal innate desire on the part of every organism to live beyond its income."

- Samuel Butler

ADVERTISEMENT

Sponsors