Q: When you have a 12 month deadline?

One of the points I made in “Its always time for tea” was why it makes sense to leave things late – until the last responsible moment. I also pointed out there research shows that when you have more time work expands. But, while humans are very good at working to deadlines we are atrocious at estimating time. Later I argued for thinking small – Kelly’s (second) Law of Projects: “Inside every large project is a small project struggling to get out.”

So, it was perhaps unsurprising when someone came to me later and asked:

Q: “What do you do when you have a far out deadline but one you must meet? e.g. you need to change vehicle software to stay compliant when the law changes in 12 months.”

It would seem that waiting until a month before the deadline to do the work is not the most responsible thing to do. But starting now would risk the work expanding in size.

I see several options for this.

First: just try and do the work. I’m assuming this is non-trivial so allow yourself, or your team, a few weeks to try and do the work. This is what we used to call a “spike”, the idea is not to do the work but to learn what you need to do to learn to do the work.

At the end of the time period you can throw anyway your work but you will have learned a lot. You should have an idea of the order of magnitude of the work: month or weeks, a small team (say 4) or many teams.

Having done that, even if you fall back on classic project management to design and plan the work but having done the spike you would be working with superior knowledge.

While you could set yourself an early deadline and try and do the work immediately there is a danger that, knowing it was safe to be late, the team would let the work expand. So, while this approach might not be the most cost-effective it would probably deliver on schedule.

If, from the spike, you are confident the work could be completed in a few weeks you might decide to delay starting on the work. After all, the payback for this work is a year away so work on something which has more immediate value.

One of the problems any early start approach will face is knowing when to stop. It is quite possible that the team will complete the original work but knowing there is time (and funding) to do more they do more. One way to combat this would be to specify the tests right at the start.

Specify the tests and conduct them before you do any more work. See how close you are, and, when you are doing the work execute those tests regularly. When you pass the tests you know you are done.

Having these tests should help you be ruthless with the work the team is going. The problem with many big projects is they accumulate tangental “nice to have” work. Having tests should allow you to sideline any work which is not going to support passing the tests.

Now, it is possible that your spike leads you to believe that getting the work done is a challenge, you might not make it.

One option here is to use this information to ask for more people and other resources in the hope that a bigger team will get the work done faster. Yes, I know that goes against my original advice, and I know that Brook’s Law and pregnancies suggests it won’t help but put it down as an option.

Now we are into spending big money more options open up.

Do the best you can but in parallel launch a lobbying campaign to change the rules or have them delayed. This might sound repulsive, and it is not an engineering solution, but actually big companies do far more often than most people realise.

Another option is set based engineering as practices by Toyota. Form up two teams, give say 90% of the budget to one and 10% to the other. While the big team takes the rational approach the other team work on a lightweight solution. If the 10% team succeed you are on safe ground and potentially save money by cancelling the other work.

Finally, I’m speaking from an abstract perspective. I expect a company which faces this sort of situation has probably done so before, more than once. So in addition to doing a spike and writing some tests I’d want to look at past performance. That might offer some more options or tell you what not to do.

Verified by MonsterInsights