I understand why teams resist using formal project management like task definition and planning for risks. Some project managers are more focused on paperwork than people, on meeting the project's objectives than pleasing the customer and team members. They resist major changes to the work requirements (the "scope") because of the impact on time and budget, even when there are good reasons for the changes. Some teams resist project management because they think "we don't know enough" about the final result for it to work.
Admitting my bias as a certified project manager, I believe this is "throw the baby out with the bathwater" thinking. The fact that some project managers (PMs) are inflexible does not counter the value of project management any more than poor software developers diminish the value of software development. Done right, project management remains the only way to obtain a defined deliverable at the best balance of quality, time, and price. Furthermore, two European business researchers argue in a recent article in California Management Review, there is no reason project management cannot have a role in tasks with many unknowns. Sylvain Lenfle and Christoph Loch say the discipline was born while creating innovation and developing strategy along with the atomic bomb in the Manhattan Project. Lenfle is with the University of Cergy-Pontoise and Ecole Polytechnique and Christoph Loch is at INSEAD.
As of 1942 when the project began, no one had a clue about the best way to build an atomic bomb. Lead scientist Robert Oppenheimer outlined no fewer than five different designs in a seminar that year, and the estimate for how much nuclear material was needed varied by a factor of ten. The PM, Gen. Leslie Groves, later wrote, "'My position could well be compared with that of a caterer who is told he must be prepared to serve anywhere between ten and a thousand guests,'" Lenfle and Loch report. The project's scientists weren't even sure which of two nuclear materials to use, or how best to refine them.
So the project tried everything. This became known as "concurrency," Lenfle and Loch say: "the simultaneous (or overlapped) performance of logically sequential tasks." This would be dismissed as a waste of time and money today, they write. But picking any one approach would likely have wasted far more. As these efforts reduced the uncertainty around the project, less viable options were abandoned. Suppose one of them had been the only one chosen. The project likely would have failed. The result of a concurrent approach was a project that went from vast uncertainty to two workable results in three years. (The bomb dropped on Hiroshima was of a different design and core material than the Nagasaki one.)
Two later missile projects were developed much the same way. One introduced the Program Evaluation and Review Technique that project managers will recognize as the PERT method for estimating project length. But Lenfle and Loch say this was more of a political maneuver than a real exercise in project control. As they quote from a book on the Polaris missile project, "'The image of managerial efficiency helped the project,'" or rather helped sell the project to Congress.
Things changed when former Ford Motor Company head Robert McNamara became U.S. Secretary of Defense in 1961. The department shifted to a more cost-focused business sense, tools such as phased project plans, and use of fixed-price contracts that pushed the risk of cost overruns onto contractors. Over time, strategic decisions (like which bomb design to pursue) were moved out of the realm of project management and into the hands of high-level planners. "Project management's role was henceforth to execute given missions…" Lenfle and Loch write. The development of the Project Management Institute (PMI, of which I am a member) in 1969 eventually codified this approach into what is known as the "project life cycle." Lenfle and Loch define the cycle as "phases that projects go through, each having an outcome and end-review that triggers a decision about whether to start the next one." It "takes the mission and goals as given" and works to meet the estimates for "scope, time, and cost."
They support this model when the targets and capabilities of the project are well known and the tasks fairly easy to define. But they say PMs have given up the role they once had in determining strategy and creating innovation when uncertainty is high. Parallel trial projects helped Japanese countries overtake U.S. counterparts in automobiles and electronics. They have been used successfully to choose the best application for a new metal surface-finishing process and to create an assembly line as efficient with older workers as another with younger ones, a response to an aging workforce. These projects chose solutions instead of merely implementing them. "When discussing such examples," the article says, "professional project managers view them as either 'special' (e.g., applying only to chaotic start-ups) or simply 'sloppy' ('Why did they not perform better risk planning beforehand?')."
But I think the profession is shifting back. The authors fail to mention Agile project management, borrowed from the software development world to deal with projects with high uncertainty. PMI recently added a certification in Agile. The authors themselves note a recent study of six manufacturing firms in which "projects addressed not only processes and methods, but also the product/market position."
Lenfle and Loch say the project management discipline is in a "self-imposed 'order taker niche'" due to historical accident rather than conscious decision. Perhaps a conscious decision to reintroduce trial-and-error and concurrent projects in circumstances where uncertainty is high, like those in which project management were born, will expand the value of the profession and make it an easier sell to those who resist its cost-effective charms.
Action Item: If you do not use team project management, consider whether running concurrent projects to test various solutions would be a more efficient way to solve a problem you are facing, in the long-term view.
Source: Lenfle, S, and C. Loch (2010), "Lost Roots: How Project Management Came to Emphasize Control Over Flexibility and Novelty," California Management Review 53(1):32.