Specifying very unpredictable timelines

Question

I'm working on an R&D project that is quite complex and has a lot of interconnected parts. A lot of my work is changing or substituting hardware, software, libraries, etc.

My boss likes me to keep an up to date timeline of how long each item will take, and when I expect things to be done. The problem is that a lot of the tasks I perform, while appearing quite simple (just substitute in this new hardware, or change some formula in the code) almost never go as expected and often end up taking days or weeks to perform (if they are actually possible within the scope of the project at all).

This puts me in a tough position when specifying how long I expect an item of work to take.

When I first joined the company I (rather naively) just put down the expected time if there are no problems. This, of course, lead to consistently going over estimate.

Next I tried giving a rough average taking into account problems I think might come up. But when I do this, I end up having the same conversation with my boss for every item of work. My boss says, "This should be simple, right? Shouldn't it only take a few hours?" And I reply, "Yeah, in a perfect world I would just X the Y and it would be done. But there are always complications that make it take longer." I've had this conversation more times than I can count.

I would like to just put on my reports "This will take at minimum 1 day, most likely Y days, and if it takes more than Z days we should have a meeting about trying another approach". But this makes it almost impossible to figure out a longer term timeline when chaining multiple items together.

Does anyone have a good system for organising R&D (or similarly unpredictable) work like this?

Answer 1

Your approach wasn't bad at all. In a company I worked at we had to give 3 timelines for each task:

• minimum estimated time if everything goes well
• realisticly expected time, considering some things always go wrong. Usually 20-30% time added to the minimum estimate.
• worst case estimation. This includes buffer times for unexpected problems and research for possible solutions.

Back then, we listed all tasks and their 3 estimates in a table. That way is was easy to sum up all the estimates and get a feeling for the timeline of the whole project. The numbers will cover a wide range (like minimum = 40 hours, ralistic 70 hours, worst case 150 hours), but generally the real times came very close to the realistic estimate.

If you use a software to visialize your project plan as a Gantt diagram, I propose taking the realistic expectation as input and adding small gaps of buffer time in between (most likely before milestones).

Split your tasks into multiple sub tasks. "substitute hardware" sounds very simple, so it should be done in an hour or two. But if you split the task into "research for suitable hardware", "find supplier", "assemble" and "add to documentation" it is instantly clear that this cannot all be done in a mere hour. Don't forget to plan time for documentation!

Again, project planning software can help you visualize these sub tasks as items belonging to one major task.

Answer 2

Your intuition is correct: you won't have (internally) one but two timelines.

Externally (or officially) you want to be safe and use the worst case (eventually picking up more tasks from backlog when you're faster than expected) but your job is to provide a sensible range, how to use it is up to your boss.

Note that this will be evident ESPECIALLY in the long term. I'd not go too far (best, probable, and worst cases) because I found that too many numbers will only complicate things: unless there is a really compelling reason I'd keep it as simple as possible (and your boss is perfectly able to extrapolate an educated guess from numbers you gave him). Why? Because, regardless what The black art of Software Estimation suggested if you give three numbers then people will pick the two they prefer to calculate an average (and usually it includes the best case...) Feel free to include a 3rd number (educated guess) after you have more practice with this approach and everyone in the line has gained enough experience and understanding about the process.

I've had this conversation more times than I can count.

Communication is, as usual, the key. Obviously you have to involve your boss to:

• Explain: he has to understand why a best case estimation rarely happen to be correct (and to do it you have to first understand it by yourself). See also last paragraph of this answer. Snow's answer has some very insightful tips about this.
• Discuss: you have to find the best way that works for your team. There is not a perfect procedure and details about environment are extremely important: in some cultures and domains a small delay is acceptable while in others it's completely inappropriate (imagine you have to put a satellite in the space, the launch window cannot - usually - be delayed.)
• Agree: when everything is clear you won't need to repeat this discussion in future (if not to improve the process.)

Don't forget that estimation for big tasks is even more unreliable, be sure to estimate the smallest unit of work you can.

But this makes it almost impossible to figure out a longer term timeline when chaining multiple items together.

On the contrary, it will make your timeline reliable. An optimistic timeline is useless and misleading. A pessimistic one may be harmful but, unless you have very short term goals, in average - on the long term - your estimation will be 80% correct.

Be sure to communicate with your boss, it's useless to have a reliable estimation - based on your experience and past issues - if your boss always thinks you're cheating or just incredibly slow.

Are there alternatives? You should allocate some time to investigate possible issues BEFORE you give your estimation. Your boss won't ask you why task XYZ takes so long because you already explained the reasons in your report, it's not a blind but an educated guess supported by evidence (and R&D adds enough uncertainity even to this.) Honestly, I'd start to do this (instead of simply inflating your gut estimation) even if you provide a range (because it will make the range reliable and it will help to prioritize tasks.)

Answer 3

One way to do this without inflating your estimates hugely is to do critical-chain style planning (of which I'm a fan if you have to give estimates).

You still give your best case estimates but the understanding is that in 50% of cases you go over time. You fix this by adding very generous buffers (up to 50% of total time) both on critical paths and on the project as a whole. That way your plans are tight but the project as a whole is geared for the worst possible case so anything you deliver under time is a bonus.

In your case you could consider every week a kind of critical chain of its own and continuously reschedule your buffers depending on what was achieved (or not) in a given week. But all of this is a no-go of course if your boss is not on board with it.

We did an intuitive way of this approach for R&D projects ourselves and the way we managed to deliver was by planning based on 2-3 days a week so that if necessary we could suspend studio operations and other business functions to add more gas to a project. Similar high slack approaches to project management and product development are detailed in the Principles of Product Development Flow by Reinertsen.

Answer 4

There are two lines of attack to suggest here.

1) Look at your previous estimates/actuals when taking on new work tasks and use those to guide your estimates this time around.

2) Examine the times that you went over estimate and work out why that happened. What caused you to spend significantly longer doing something than you thought you would take?

Work out ways to streamline or avoid blocking challenges that cause you to blow your estimates. If you can't avoid those blocks, build them into future estimates for the same work type.

If something is unknown, then take a stab at it, but declare it upfront as a "stab in the dark" estimate and prioritise your work accordingly.