Tapering management's expectations on a research project

Question

How does one set realistic milestones in R&D activities? Management wants to include milestones in research projects in the R&D arm of a company. I see the value of tracking progress in research, but I’m not convinced milestones are the right way, at least not the way we define them. My past experience is I’ve often found others working towards the milestones rather than being upfront about issues at stake as discoveries are made, since this is the standard management evaluates them to.

For example:

Month 1: solidify a strategy to solve problem A

Month 2: have program done to solve problem A

However, the problem A is more complex than originally thought, and you need to invent a strategy to solve the problem for delivering a quality product to customers. This will take more than one month.

Answer 1

I provide the different flavors of estimates. Here are two extremes:

R/d (mostly research, just a little development)

This is blue-sky work. I point management at the biggest possibilities assuming the best resources possible with no guarantees of success. We fantasize about what is possible and strive to define the problem more than solve it completely.

r/D (this is development with the illusion of being research)

The reality of most projects are that they are really targeted towards integration into products. For these efforts, I strive for the most practical solutions with realistic timelines with realistic budgets and realistic resources. I often provide a sliding scale of outcomes and probabilities

• We'll get this done with 90% chance success and 90% on-time/on-budget
• We'll get this done with 50% chance of success and 90% on-time/on-budget).

In product development in small / mid-sized companies, there is rarely real R/D like graduate school, the government, or large companies. All R/D in industry is applied and has limited time and budget. Therefore, the only thing left to play around with is the performance.

Answer 2

A research schedule is a best estimate. Any schedule is a best estimate.

Handle it the same way you would a dev schedule: Here is where we expected to be at this point, here's what we've learned, if our original estimate was overoptimistic here is a revised best estimate based on what we have learned.

If management objects, have an estimate ready for what it would take to make you confident you could meet the original target date: more manpower (beware mythical-MSN-month effects), more investment in tools, purchasing something commercially rather than developing it in house, etc. Deciding whether they can afford that investment is their problem, as is deciding whether to accept revised schedule, out to cancel the effort entirely.

Odds of that last are unlikely, though they may reduce the scope. Ideally, this will be in a way that produces something useful by the original date, then adds the rest on a continuing basis which can be published/patented/rolled out as a subsequent version/addition. That's often a better although in any case. Quoting researcher Steve Boies: "Make it work, make it good, make it great." Implicitly: in that order.

If they flat-out refuse to accept your new estimates, which are bbased on the same expertise that cause them to ask you to lead this effort, all you can do is say "well, I'll do my best, but I've told you my current expectations."

Don't panic. Management appreciates estimates that they know how to plan around, even if it isn't what they would have preferred to hear. And they understand that estimating is an imperfect skill that t takes time to learn.

If dealing with someone who really can't be flexible about this, the lesson learned is the one everyone has to learn: when resonating schedules, allow time for the unexpected. After 30 years in my profession I'm still learning how much pad to add.