"First, Define the Problem" - Why Do Experienced Project Managers Not Follow This Rule?

By Alex Laufer and Jeff Russell

The rationale for setting project objectives is obvious: without proper objectives (translated into technical requirements) the project team might try to do the task right without doing the right task. The example from Alice in Wonderland articulates it succinctly: “If you don’t know where you’re going, any road will get you there.”

Indeed, the negative implications of poorly defined requirements have been discussed in the literature. To avoid these negatives, the common recommendation is to develop the complete set of requirements prior to embarking on the means for accomplishing them. However, the following story, told by Dr. Michelle Collins from NASA, suggests that some project managers do not accept this recommendation.

At a meeting of NASA Project Managers, the group was involved in an exercise on requirements. She narrates:

“You are given a project to develop the software for an Automatic Teller Machine (ATM). Write four requirements… The group was a mix of senior and junior Project Managers (PMs). We broke into pairs to come up with the four requirements for the ATM, and then we regrouped to discuss our findings. Several of the pairs consisted of one senior PM and one junior PM…All three senior PMs gave requirements that were extremely brief and general; the junior PMs offered lengthy and fairly explicit requirements.”

            An example of a pair of responses follows.

Senior Project Managers	Junior Project Managers
Functionality	Provide money in the form of $20s with no fee and warn Home Office of empty condition at least one hour in advance of becoming empty.
Reliability	With minimal annual maintenance, the ATM does not break down.
Security	The ATM communicates with the Home Office continuously including a video feed.
User-friendly	The ATM accepts at least 10 major credit cards and operates in 6 major languages with complete instructions provided where a withdrawal transaction, including printing the receipt, occurs in less than 60 seconds.

Prior to discussing the intriguing question of why the veteran project managers exhibited caution and refused to elaborate the requirements, we will share results of three relevant studies. In the first study, 39 experienced project managers at 11 large US corporations (e.g., AT&T, DuPont, Exxon, General Motors, IBM, and Procter & Gamble), were interviewed by the first author. Each interview lasted about a half-day, and it focused only on one project which was studied in great detail. The results showed that these project managers did not adhere to the rule “Define the problem, then solve it,” or, “Objectives first, means second.” Rather, in almost all the 39 projects the requirements specification process was not an isolated activity, and it was not completed before searching for alternatives began.

In the second study, of 211 R&D projects, it was found that the extent to which the project’s business and technical goals were well-defined at the time of initiation was not significantly related to the project’s eventual success or failure. However, late in the life of the project the relationship was statistically significant. Business and technical goals for successful projects became better defined over the life of the project than did the goals for unsuccessful projects.

The third study, of 308 decision processes in West Germany, also demonstrated that the goal formation process was not completed before the beginning of the problem-solving activity. This study provided the rationale behind this behavior:  namely, the insight into possible solutions influences the decision-makers’ ideas of what they really wanted.

Indeed, a similar rationale was provided by Professor James March of Stanford University, a well-known authority on organizations and decision-making who concluded that: “The argument that goal development and choice are independent behaviorally seems clearly false. It seems to me perfectly obvious that a description that assumes that goals come first and action comes later is frequently radically wrong. Human choice behavior is as much a process for discovering goals as for acting on them.”

Now we are better equipped to reflect on the opening story regarding the level of detail in the requirements given for an ATM machine by the two groups of project managers. It seems that the experienced project managers knew that because the scenario was posed early, at the beginning of the conceptual phase of their task, it was advisable to first quickly examine the means rather than immediately attempt to formulate the requirements in great detail. Specifically, they wanted to examine the means to learn better what they really want and if they can afford it. To use the terminology presented in our first blog post, they realized that they are still in the living order phase. The inexperienced project managers, on the other hand, wrongly assumed that they are already in the geometric order phase.

In future blog posts we will present specific practices used by successful project managers to identify and facilitate the appropriate pace of moving from living order to geometric order, so that they can finalize the formulation of stable project requirements, as early as possible, but not too early.

SOURCES:

• Collins’ story: “Lessons from NASA Project Managers,” Michelle Collins. 2001.  Ask Magazine 3 (June): 26-9.
• First study: “Letting Go of Once and for All,” Alexander Laufer. 2003. Ask Magazine 13 (August): 40.
• Second study: N.R. Baker, S.G. Green, and A.S. Bean. 1986. Why R&D Projects Succeed or Fail. Research Management 29, 6 (November-December): 29-34.
• Third study: J. Hauschildt. 1986. Goals and Problem-Solving in Innovative Decisions. In Empirical Research on Organizational Decision-Making, eds. E. Witte and H.J. Zimmermann, 3-19. North-Holland: Elsevier.
• J.G. March. 1976. The Technology of Foolishness. In Ambiguity and Choice in Organizations, eds. J.G. March and J.P.Olsen,69-81. Bergen: Universitetsforlaget.