The world of business sometimes perpetrates a fraud on other unsuspecting areas of human pursuit. It happens when business people swagger into a realm beyond their expertise and profess to show the people there how to do some aspect of their jobs better. Measuring performance, say, or creating a strategy. The implication is that business people have this sort of thing all figured out--more so, anyway, than the people they're talking to.
The public sector is the front-running target of self-righteous management preachers; arts organizations probably come in second; and lately the sciences seem to have moved into the crosshairs. The sad fact in many of these areas, though, is that business people don't do as well as their brazenness suggests. Project management is a perfect example.
The basic things you are supposed to do are pretty well agreed throughout business and form the staple of almost every project management course: " ... develop the work breakdown structure, develop the schedule, analyze resources, optimize tradeoffs, develop risk management plans ..." This partial list happens to come from a Harvard Business School publication by H. Kent Bowen called the Project Management Manual. But, truth be known, there's little substantive difference between most such documents, regardless of who publishes or writes them. They all provide lists of tasks that divide projects into sequential phases, with high-level tasks subdivided in to lower level tasks. They all emphasize thorough planning to estimate the amount of people and time required by each task, to check for conflicts in demand for resources (or facilities), and to assign resources to tasks. They all propose methods for tracking progress against plans and suggest formulating contingency actions to take when there are deviations. Most also perpetrate the myth that you need merely to follow their advice carefully if you want everything to turn out all right.
If this were all true, a huge majority of business projects ought to go really well. The reality is quite different. Some business projects go well, but many go badly, and a surprising number become outright failures (more than 50% in areas such as information systems implementation, according to consensus estimates).
Some people are much better project managers than others; there's apparently a nontrivial skill to project management beyond the ability to execute planning methodologies. Failed projects often exhibit a perplexing pattern: They appear to be going fabulously according to tracking indicators right up until the moment when they explode into unmitigated disasters. Postmortems indicate that project management mechanisms, especially those for tracking against plans, actually interfere with effective handling of problems by making people reluctant to surface problems that might cause unplanned deviations. No one wants to be the bearer of bad project news, or, worse still, to get the blame for throwing a project off schedule or putting it over budget.
Even when project mechanisms don't have overtly dysfunctional effects, they still often don't operate as advertised; people I know who serve as expert witnesses in legal disputes over failed projects tell me that project management documents are often useless in litigation because they are essentially devoid of content--bland indicators that someone did indeed fill out a form and get a signature on a certain date.
Project management enthusiasts are inclined to attribute project management difficulties and differential skill sets among project managers to "not doing it right." By this they usually mean not following instructions, or not being thorough enough. I disagree, as do a growing number of management researchers in this area. The fundamental problem with many conventional project management frameworks is probably even more relevant to science than it is to business: They simply aren't adaptive enough.
Conventional project management methodologies work best when the chances are really good that the project will unfold as anticipated during its planning stages, when there is little that can happen during a project that planners can't see coming, when you can formulate responses to contingencies in advance. In other words: when there is not much genuine discovery going on.
In building construction, for example, usually the range of possible problems can be pretty well anticipated and solutions planned in advance. I've never been a scientist, but I'm guessing that this isn't true in a lot of science. If I'm right, project management in science needs to allow for the possibility that the investigation might veer in unexpected directions as a result of something discovered in progress. Some of the classical concerns of project managers, such as conflict for scarce resources, will still be important. But compliance with plans and adaptation must be balanced. Project management methods must be more dynamic than they have been historically. This is increasingly true of business too, by the way; in highly volatile and uncertain business environments, pretending you can preprogram your responses to all eventualities is a losing game.
Adaptive or iterative models seem to be the emerging response to the need to manage projects more dynamically. The figure below contrasts the general shapes of traditional and adaptive project approaches. Note that the adaptive approach contains the same activities (concept, planning, design, execution, evaluation) as the sequential approach; but the adaptive approach cycles through each rapidly, in more or less rough fashion.
An Adaptive Project Approach
Adaptive frameworks assume that the future grows hazy rather quickly the farther you look into it. They therefore concentrate efforts on a shorter horizon, after which they assume there will be an abandon-or-continue decision and a revision of plans. Planning takes on a different nature. Rather than a compliance yardstick, a plan becomes evidence of the thoroughness of your thinking about what might happen.
You might still work out detailed work-breakdown plans, task durations, and resource requirements for the project as a whole. But you shouldn't believe them very much or insist on compliance with them, except for the next increment of activities. Venture capitalists, who invest in new business ideas, allocate financing this way. As my colleague Bill Sahlman, writing in Harvard Business Review, puts it,
If a company believes it needs $10 million to develop and introduce a software product, they are likely to find that no investor will invest the full $10 million. Rather, the investor will stage the commitment of capital over time, preserving the right to invest more money and preserving the right to abandon the project. ... [T]he issue of how much money to invest ... is exceedingly difficult and the perspectives of the players often differs ... [I]nvestors want to stage the capital over time in order to "buy" information.
The idea is to move through a complete, top-to-bottom planning and decision cycle for each stage or increment of the project, each time forcing a conversation about the next steps to take and revising the plan from that point on. This is quite different from the more traditional approach of executing one long sequential plan prepared in advance (which is what often ends up happening, despite the protestations of traditionalists that their methods are dynamic too).
One implication that sometimes seems scandalous to traditionalists: In some cases adaptive frameworks encourage you just to go ahead and try something rather than devote a lot of time to detailed planning. You may learn more from the experience of trying than you could ever learn by thinking about it hard in planning.
This depends, of course, on how expensive it is just to go ahead and try something. If the trying something involves sending a probe to Mars, for example, you probably don't want to just go ahead and try it (unless you can do it in simulation).
Depending on the pervasiveness of swaggering business people in science funding these days--and with an MBA president, they could be pretty pervasive--you might sometimes be stuck with traditional methodologies. If granting agencies are following methods taught by traditionalists, you'll probably have to figure out a way to comply with a more traditional project management methodology. If it makes you feel any better, this silliness goes on in business, too. A lot of people who develop software, for example, find themselves forced to comply with cumbersome methodologies that pretty much just get in the way. Like many administrative mechanisms in business, these methodologies are influenced at least as much by sheer inertia as by great wisdom borne of market efficiencies. If you have some scope to propose more adaptive methodologies in grant proposals and the like, you might well find that you like them better.