OT: Advice managing R&D

[Pat]

Sorry of this is off-topic, although I do use MS project and know a lot of
experienced PMs use this newsgroup and may be able to offer some advice.
I'm a research engineer, but have been thrust into the role of project
manager, one which I have been really struggling with. We do mostly R&D
projects, which by nature involve a lot of unknowns and new areas of
investigation. As a result, people often have a poor (or no) idea of how
long it will them to do certain tasks. How do you manage a project where,
say, someone is trying to derive a solution to problem that may not be
solvable (at least with the approach they're using) and therefore may need
to be redone; or where someone is debugging an unexpected (and therefore,
unplanned for) problem in a computer code that takes a week to track down.
I've tried adding "slack" to the schedule but still find projects over
running. I sure some of this is due to the inexperience of the people
involved, myself especially, and I'm looking for some references that might
help me with this.

Most of the PM literature I've looked at use overly simplistic (well
defined) examples (i.e it takes Joe 2 hours to paint a room...) relative to
my situation. So I was wondering if anyone knew of some good PM references
(books, articles, websites) relevant to managing R&D projects or, for that
matter, any project involving a lot of unknowns. Also, any advice in
general would be welcomed and greatly appreciated.

Thanks,

Pat

 

[Tommy Lovelace]

Go here: http://pubs.acs.org/hotartcl/chemtech/97/oct/struct.htm

If you need further assistance, feel free to email me.

Tommy Lovelac
The Project Grou
Houston, Texa
(e-mail address removed)

 

[Bertie G]

Pat

Other than constantly re-evaluating your programme objectives, there is little that can be done when working with a host of unknowns. It is all just a "best guess", hopefully based on some form of previous experience. We design & build unique, heavy engineering cranes, and the "design" process is constantly evolving the programme....bearing in mind that every last nut & bolt and electrical terminal must be specified to the Nth degree. As soon as something unexpected crops-up, insert it into the project. Segregate your tasks into the smallest manageable sub-tasks (no more than a week or two, if possible) and have the discipline to hold regular programme reviews/updates. Programmes frequently over-run and, unless specifically shown as a task, no-one will ever remember why things took so long

In principle, you cannot overrun on something whose objective has not been specified. This is why short-term tasks are important. At least you can see where times has been spent. It's more effort to manage the programme, but you'll be in much more control

Bertie.

 

[Pat]

Thanks Tommy and Bertie for the feedback.

One aspect of this that has made it especially difficult is that most of our
projects are funded under fixed price grants. So if you overrun it really
reeks havoc with the budget.

The suggestion of refining tasks so durations are no longer than two weeks
makes sense in this situation, and I will definitely give it a try. Other
than that, the only other think I can think to do is to look at how long it
has actually taken different people to do different types of tasks (compared
to what they estimated) and try to develop some guidlines (or fudge factors)
that may help me adjust later tasks and provide better estimates in future
planning.

Thanks again for the help. -Pat

Pat,

Other than constantly re-evaluating your programme objectives, there is

little that can be done when working with a host of unknowns. It is all just
a "best guess", hopefully based on some form of previous experience. We
design & build unique, heavy engineering cranes, and the "design" process is
constantly evolving the programme....bearing in mind that every last nut &
bolt and electrical terminal must be specified to the Nth degree. As soon as
something unexpected crops-up, insert it into the project. Segregate your
tasks into the smallest manageable sub-tasks (no more than a week or two, if
possible) and have the discipline to hold regular programme reviews/updates.
Programmes frequently over-run and, unless specifically shown as a task,
no-one will ever remember why things took so long.

In principle, you cannot overrun on something whose objective has not been

specified. This is why short-term tasks are important. At least you can see
where times has been spent. It's more effort to manage the programme, but
you'll be in much more control.

 

[Steve House]

Yours is an example of where the PERT approach can be of value. The CPM
method, which is the basic MSP strategy, are deterministic and is based on
well defined tasks with durations that can be estimated reasonably well.
PERT, on the other hand, is probablistic, with the schedule based on a
weighted average duration. You may not have done this exact task before but
other projects have had similar tasks. You can look at the historical data
and come up with an average and sdev of the actual duration for similar
tasks in similar projects. Plug the average and +/- 3sd values into MSPs
PERT calculator to come with a best case, worst case, and most likely set of
durations, essentially 3 project plans instead of just one. Or take the
average of previous projects and then consult with the subject matter
experts doing the work to come up with a best case and worst case estimate
for the tasks in this one and apply the PERT formula (D(b)+4*D(a)+D(w)) / 6
to come with the duration estimate for the task in this project. (That
formula is what the built-in PERT tool uses in MSP).

 

[Pat]

Thanks James and Steve for the feedback.

Part of the solution (perhaps a large part) is to get the researchers to
take more time initially to better think through the work involved - how are
they going to approach the problem and contingencies if/when their approach
fails. Even at that it can still be a tough call as to how to plan . If
you include all contingencies, the scope of work gets reduced (quite
dramatically) to keep it within budget. If it's part of a proposal, then it
can make it look like not much is being accomplished for the funding, and
reduces the chances of winning it.

What I'm really looking for are some good references on this. Most of the
books I've looked at on managing R&D deal with it from a higher, "strategy"
level (deciding which projects to pursue to enhance the firms "portfolio,"
etc.). I could not find any which specifically dealt with the project
management challenges involved. Hence my post.

Thanks again. -Pat

Hmmm...an interesting one, Steve.

The PERT will, of course, only tell you of the potential duration of the

tasks that you have input. It won't tell you that you're going the wrong
way, or what the unknown or additional tasks might be. You're quite right,
however, in that acquiring any form of historical information or practical
experience is better than starting with absolutely nothing.

Pat,

You have an intersting situation here, in that you've already defined the

primary constraint....the budget. Therefore, you have a known budget to
achieve a, perhaps, poorly defined objective via a somewhat unknown route.
This is where you MOST DEFINITELY must determine on which tasks you've been
spending the money....thus including the short duration, easily managed
tasks. At least you'll be able to tell your boss where the money has been
spent. Bear in mind that the longest journey is merely the sum of the
individual steps. The milestones are the sums of the accumulated
inch-pebbles. A well composed and administered project will act as a
story-book and route-map, enabling you to re-trace your steps...and
undertake a similar journey later on, whilst avoiding the pitfalls
encountered previously. If you don't write it down, the wheel will have to
be re-invented again and again.