The Money Files

Crashing 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

You’ve got a great project with a ton of benefits coming your way. Everyone’s really happy. And then someone says: “Exactly how much are we going to get from this project?” Suddenly it’s no longer enough just to list benefits – you have to quantify them as well, and that means producing an accurate forecast. Ouch.

So what can you do to get that benefits forecast as accurate as possible? Here are some tips for building a more reliable outlook.

1. Strong leadership

This almost goes without saying. If you have your project sponsor encouraging you to be transparent and honest with the estimating process, challenging your assumptions and leading by example then you will get a better result.

2. Validate first

Don’t invent a way of measuring benefits (when they are realised) that you can’t test. Test your benefits capture mechanisms, and then change them when they don’t work the way you thought they would!

3. Account for them now

People are more inclined to produce accurate forecasts if they know they will be held to account. If you expect your project to deliver a certain financial benefit, put that in the right department’s budget today. If it’s a productivity benefit, build that into the team’s annual objectives or performance targets.

4. Be negative

Take the opposing view to challenge estimates. Think critically about the other side of the argument and what would happen if the benefits aren’t delivered as planned. This can help you avoid optimism bias and come up with a realistic range.

5. Get another opinion

Pick a trusted project management colleague or even someone in a different team to review your estimates. This independent challenge can give you another perspective and help you avoid getting sucked into a project team mentality in which you make unrealistic assumptions. An internal auditor could carry out this role for you, or someone from your PMO.

6. Don’t estimate alone

Use the Delphi technique or other group estimating tools – you’ll get a far better, more accurate result than if you came up with the benefits forecast by yourself.

7. Forecast a range

As with financial forecasts, predicting an amount in a range gives you more flexibility. Avoid single-point forecasts (“We’ll generate $689.52 extra revenue”) and opt for a spread of figures (“We’ll bring in between $550 and $700 in extra revenue”).

8. Review your estimates regularly

As your project progresses, go back to those estimate and make sure that they are still accurate. Your project will change and those changes could well have an impact – positive or negative – on the benefits forecast. Keep your forecast up to date and communicate any changes to the key stakeholders. A change too far in the wrong direction could mean your project is no longer viable. Linking back to the first point on this list, that’s the time when strong leadership comes into its own. It might mean cancelling the project or backing out some changes that have an adverse effect on the benefits profile.

Benefits are the reasons we do projects and programmes, so if the benefits aren’t there, you have to have a very good justification for continuing to work on the project. That’s why benefits realisation is important. More effective benefits realisation happens when estimates are good, people understand how they have been calculated and above all, they are realistic. It isn’t hard to do, but more often than not project teams and the organisations they work for don’t spend the time on the benefits planning stages to get good results at the end.

What does your company do? Let us know in the comments below.

Projects need lots of decisions and often it can take a long time to get a decision made, especially if there are numerous levels of bureaucracy to get through. Time is money on many projects, and while I don’t often come across project teams sitting around waiting for a decision before they can move it forward, I am aware of several projects where stalled decisions have impacted delivery dates and tasks on the critical path.

Speedy decision making relies on people actually thinking the problem through, gathering data and coming to the decision – and, of course, speedy decisions are not always the best decisions.

When the decision is under your control, you’ll have to make it. How can you be better at decision-making? Here are 5 tips to help.

1. Consider the long view

Think forward: what decision would you wish you had made next month? Next year? In five years? Approving overtime might feel like the right thing to do now but how will you feel about it on your next project when you’ve already set the precedent and the team are expecting to be paid for extra hours?

Think about the long view as it relates to your decision. This will also help you put the decision in perspective. Remember back to when you took your school exams. I expect the results meant a great deal to you then, but you probably don’t even put them on your resumé any longer. The significance of actions changes with the passing of time, so think about how you’ll feel about  this decision in 10 years – you’ll probably realise that it isn’t that big a deal after all.

2. Cut out data

What data do you really need to make this decision? Strip away everything else. It might be nice to know the resource allocations for the next month, but if that doesn’t have a bearing on whether you accept a schedule change or not then they shouldn’t be taken into account.

Make sure that you are using the right data, not any data to make your decisions, and go for the minimum possible. This will help cut the mental clutter and make it easier for you to see what needs to be done.

3. Understand the impact

What’s the impact of this decision? What will happen if you don’t make it? Sometimes understanding the ramifications of a quick/slow/positive/negative decision can help you tackle it effectively (or at least gather the right information to help).

I’ve often found that the larger the impact, the easier it is to make the decision. Sometimes small decisions seem the hardest because there tends to be less clarity about  the appropriate route forward.

4. Lose the emotion

We all get attached to our projects and teams but it is best to take the emotion out of decision-making. Think about what is best for the project and the company. For example, it might be an unpopular decision to reject a change from the Marketing department, but if it doesn’t help the project meet its objectives and it costs a lot of money, then it isn’t a smart thing to recommend to your sponsor. After all, your sponsor can choose to accept or reject it – you are just putting forward an emotion-free assessment of the change.

5. Intuition isn’t always right

Many project managers report ‘going with their gut’ when it comes to making decisions or working out how to resolve problems on projects. However, the application of some technique does have benefits. Your intuition isn’t always right – ever been caught out in the rain because you figured it would be dry all day so no need for an umbrella? You can’t rely  on your gut when project dollars are at stake.

Choose the right data to support your decision. By all means include some ‘gut’ in your decision-making process but be able to back it up in case anyone asks you why you’ve made that choice.