CHAPTER 6

Headless-Chicken Projects and How to Prevent Them

When I was a boy, we lived in the country for a few years, and my parents kept some chickens around. In those days, if you wanted fried chicken for lunch on Sunday, you didn’t go to a grocery store and buy a processed chicken. Instead, you caught one in the backyard and whacked its head off—that was your lunch (after cooking it, of course).

When you cut off a chicken’s head, the body runs around spewing blood for a few seconds, then it falls over and quivers a bit, and the chicken is “officially” dead. It is actually dead when you cut off its head, but it takes some time for the message to reach the rest of the body.

Projects can be like that.

We whack off the project’s “head” during initiation, and it runs around for a while spewing blood. Then it finally falls over, quivers a bit, and becomes still.

Someone says, “I think that project is dead.”

It is. It was dead from the very beginning, but like the chicken, it takes a while for the message to reach the body.

I call these “headless-chicken” projects.

No doubt you have seen one yourself. They’re all around us: projects that are doomed before they get started because we whack off their heads at the beginning.

THE COLD, HARD FACTS

Every year, the Standish Group (www.standishgroup.com) surveys software development projects in the United States. How many succeeded, failed, or were changed dramatically? Results from a survey that was done in 1994 by the Standish Group are shown in Figure 6.1. As you can see, 83 percent of all projects suffered serious problems in 1994, with nearly a third of them being bad enough to be canceled. That means that of the $250 billion spent on software development in 1994, about $80 billion was wasted.

Since this data was collected almost 30 years ago, you would expect that the situation must be greatly improved now, but in the most recent report, this figure is more or less unchanged from 1994—less than 20 percent of IT projects succeed.

How can that be? Microsoft has sold millions of copies of Microsoft Project, and thousands of people have been trained in project management. I know of six companies with collective revenues of well over $100 million a year in project management training. So with all that progress, surely the success rate must be higher. Not so. What does seem to have changed is that companies cancel losing projects sooner than they did in 1994.

Figure 6.1 Standish Group Survey Results

This is a sad situation, to be sure, and it corresponds to what I reported in Chapter 4, namely, that training does not transfer back to the job. This means that hundreds of millions of dollars a year are being wasted on training that does not result in better job performance! It’s a scary thought—if I got paid for results, I would have starved long ago, or had to find a new profession.

I have already discussed the reasons why training doesn’t transfer (in Chapter 4). So let’s focus on the reasons for headless-chicken projects.

THE CAUSES

What causes headless-chicken projects?

First, consider how projects are launched. In many cases, the project sponsor conceives the need for the project. A project manager is recruited to do the job. She is told about the sponsor’s concept, which both find very exciting. Of course, the sponsor has only a half-baked idea, but he is certain that the project manager can turn it into a fully baked cake that everyone will admire. The project manager is equally certain that she can do this.

She assembles a team and with breathless enthusiasm tells the team members all about the project. She also congratulates them on being selected for membership on this team, for they are truly the chosen ones; because the project sponsor is a high-ranking manager in the company, they are sure to have high visibility. She is certain that success will be handsomely rewarded.

Members of the team sit in rapt attention, nodding their agreement with the project manager’s words of anticipation. She is overjoyed that they have so readily “bought in” to the general concept of the job, and she sends them forth to do the work, fully confident that they are bound for glory.

They leave the room, walking side by side down the hall, going back to their desks. Unknown to the project manager, one of the chosen team members, Matthew, asks Karen, “Did you understand what Heather was talking about?”

“I don’t have a clue,” Karen says, shaking her head.

“Boy, I was hoping you understood her,” Matthew says. “Because I didn’t get it at all. Maybe Susan got it,” he says, as he notices Susan walking ahead of them.

“Hey, Susan, can we ask you a question?” Matthew asks.

“Sure.” Susan pauses to wait for them.

“We were wondering if you understood what Heather wants us to do,” Karen tells her. “Neither Matthew nor I have a clue.”

Susan shakes her head, an obvious expression of dismay on her face. “I don’t either,” she admits. “But I was sure I was the only one in the group who was confused, so that’s why I didn’t say anything.”

“I thought the same thing,” Matthew confesses. “I guess none of us really understood, but we were all afraid to say so.”

The Abilene Paradox

This is an example of what Jerry Harvey (1988) calls the Abilene Paradox. Harvey made up a story about a family that lives in Texas. One hot Sunday morning, the family members are sitting around, bored to death because they have nothing to do.

Someone asks, “What do you want to do today?”

Another member of the family suggests, “How about if we go to Abilene and have lunch at the cafeteria?”

Next thing you know, they all pile into an old car with no air conditioning. It’s 110 degrees in the shade, but driving 75 miles an hour with the windows down creates enough of a breeze to make the 90-mile drive bearable.

They have lunch. Not a very good lunch. A cafeteria lunch.

Following the mediocre meal, they go out onto the streets of Abilene, only to find that there is nothing to do.

Now they are bored in Abilene.

There’s nothing to do at this point but go home, so they make the 90-mile blast-furnace trek back home.

They park the car, and as they walk back to the house, someone says, “Boy, that was a waste of time!”

“I thought you wanted to go,” another person protests.

“No, I just went because the rest of you wanted to go,” replies the first person.

They look at each other sheepishly and take a poll.

It turns out that nobody really wanted to go to Abilene—not even the person who first suggested it. She was only thinking out loud.

They have all made a 180-mile round trip to Abilene for a mediocre meal, when nobody really wanted to go at all! A paradox, to say the least.

Harvey makes a highly significant point about this. He says it appears to be a failure to manage agreement.

It is not. It is a failure to manage disagreement!

The reason? They never knew that there was any disagreement, because no one said anything. They have fallen into the trap called, “Silence means consent.” This is the nature of the Abilene Paradox.

Notice that the same thing happened to our project team. Because no one said anything, the project manager assumed that they were all in agreement and all understood the mission.

They didn’t. But they were afraid to say so.

Why?

Probably because they did not individually want to appear stupid to other members of the group. After all, they could tell from the smiling faces of their peers on the team that they all understood. “Surely,” each of them was thinking, “I must be the only team member who doesn’t understand.”

Overcoming the Abilene Paradox

Notice that the way a project team falls into the Abilene Paradox trap is that the message is delivered in a way that allows the team members to remain passive. Furthermore, they are not yet a true team. They have been brought together to be told about the project, and in most cases the project manager does nothing to make them feel that they are a team. She is so excited about the project that she wants to dive right in and get them started. She is completely task focused.

This is a pervasive problem. We forget that there are two aspects to all projects—the what and the how. The what is called the task to be performed. How it is to be performed is called process. But process also applies to how the team functions in total—how their members communicate, interact, solve problems, deal with conflict, make decisions, make work assignments, run meetings, and every other aspect of team performance.

And the lesson that many managers have not learned is that process will always affect task performance! We have understood this in manufacturing for many years. We have applied statistical process control (SPC) to manufacturing to detect process problems. We have worked to improve processes, to eliminate non-value-added steps, and to reduce scrap and rework, and we have even begun to recognize that nonmanufacturing processes should be improved. But we haven’t gone far enough. We need to pay as much attention to project processes as we do to task outcomes. If the process is broken or defective, it can’t get a positive task outcome.

For that reason, we must employ a process that will avoid the Abilene Paradox. The best approach that I know of is to get the team members actively involved in defining the project, which includes examining the problem to be solved and then developing a mission statement that tells where the team is going and a vision for the end result that the members wish to achieve. I have found that the steps in Figure 6.2 meet this requirement.

Figure 6.2 The Steps in Developing a Mission Statement

In this procedure, the team members are told the mission, but are then asked to put it into their own words. Each member writes out what he or she believes the mission to be. They then try to consolidate their individual statements into one that they can all support. This statement is then polished and published. From that point on, every time a question about the team’s performance comes up, you ask how to answer the question, take the step, make a decision, or solve a problem in such a way that you support the attainment of the team’s mission.

Notice that this procedure makes team members active participants in drafting the statement. Furthermore, once the statement is written, it is used to keep the team on track and to guide them on how to address various issues as they arise. This makes the mission statement an operational, living document.

This is in sharp contrast to what is usually done. In many cases, the mission statement is drafted and then forgotten, leaving everyone wondering what all the fuss was about. In fact, more often than not, the mission is handed to the team and no one ever questions whether it is valid—until the project fails to solve the problem that it is supposed to solve.

Furthermore, I have found that almost every team will have at least one member who is initially going the wrong way, compared to where the team is going. This is shown in Figure 6.3. Ideally, when the team members write out their individual statements and compare them, they will all be going in the same direction—the one represented by the big arrow. This means that they are aligned with the direction to be taken by the project. However, you usually find that someone has a different idea about what the team is supposed to be doing, and unless this discrepancy is resolved, the team will fail.

Figure 6.3 Misalignment of One Team Member with the Others

There are only three things that can be done to resolve the disconnect. The first response is to convince the person to go in the same direction as the others. This may be done through discussions in which any of the individual’s misunderstandings are corrected. Or he may need to be convinced of the proper direction.

The second response is to change the direction of the entire team. It may well be that the “errant” person has thought of the mission in a way that everyone else missed. In this case, the team agrees to go in the direction advocated by the individual. This can happen when a paradigm shift occurs. You may recall that the Swiss invented the digital watch. However, they weren’t impressed with it—in the eyes of “real” watchmakers, it was just a toy. So they didn’t even patent it. When Seiko and Texas Instruments learned about it, they began producing digital watches, and over the next several years the Swiss lost thousands of watchmakers.

Now imagine a team getting ready to design a new watch. One lone member thinks that the team should design a digital watch. The others think he is crazy—a nonteam player who should be thrown off the project. But this is the one person who has it right, and unless they realize this and go in his direction, they will produce another product that is not wanted by the market.

If neither of these responses is possible, the only remaining step is to remove the person from the team. You simply cannot have a successful project when a core team member disagrees with the mission as it is seen by the other members. This may be the most difficult step you will be called upon to take, since you often do not get to choose core team members, but it really is necessary. And you can’t kid yourself by thinking that it isn’t important. Ensuring that you have a shared understanding of the mission, vision, and problem is the most important action you can take as a project manager. Otherwise, you are certain to have a headless-chicken project.

But beyond the process offered to avoid the Abilene Paradox, just how do you integrate the problem, mission, and vision statements for a project?

MISSION AND VISION

I have found that there is considerable confusion between the terms mission and vision. The reason seems to be that we use the terms almost interchangeably. So before we go much further, we should clarify the difference.

Let’s begin with something simple. Suppose you have decided to change jobs and are moving to another city, far enough away that you don’t plan to commute from where you presently live. So you will have to find a new home, apartment, or condominium. You turn in your resignation, and soon everyone knows that you are leaving. One of your friends passes you in the hallway and says, “Charlie, I hear you’re leaving.” You acknowledge that this is true.

“You look a bit distracted,” says your friend.

“Yes, I have to find a new place to live,” you say.

Your friend has apparently been to a project management seminar, because she says, “What is your mission?”

“To find a place to live,” you say.

“And how about your vision?” she persists.

“To have a place to live,” you reply, somewhat confused.

“Well, those sound the same,” she says. She pulls you over to a nearby desk and begins to draw on a sheet of paper. “Suppose we think of it this way. Your problem is that you don’t have a place to live in your new town, right?”

You agree. She then sketches the diagram shown in Figure 6.4.

Figure 6.4 The Empty Chevron

“Let’s put your problem statement here,” she continues. “And let’s state it as a negative. I’ll explain why in a moment.” She fills in the problem statement as I have no place to live (Figure 6.5).

Figure 6.5 Chevron with Problem Statement Entered

That done, she asks, “Now, do you have an idea in mind for what kind of place you’re looking for?”

“Yes, I plan to buy a house,” you say.

“Okay. Let’s fill in the chevron. What are the characteristics of the house that are nonnegotiable? In other words, what are your must-have features?”

You name several features, and she fills in the must-have section of the chevron (Figure 6.6).

Figure 6.6 Chevron with Must-Have Features Entered

“Now, how about some things that you want, but you would be willing to give up if you had to?” she continues.

You name a few such features, and she enters them into the wants section. Then she asks about things that would simply be nice to have and enters these into that part of the diagram. The final result is shown in Figure 6.7

Figure 6.7 Chevron with Wants and Nice-to-Have Features Added

She says, “These features constitute your vision for the kind of home you want to buy. And your mission is to find such a place, thereby achieving your vision.” She pauses for you to think and then adds, “If you do these two things, then your problem is solved, agreed?”

You do agree. And the result is as shown in Figure 6.8.

Figure 6.8 Chevron with Everything Filled In

This is a simple way to understand the difference between the problem, mission, and vision for a project. It isn’t always so easy to fill in all the parts, but if you can do this with your sponsor and your team, the battle is half won.

I do have one suggestion. Once you have filled in the nice-to-have features for your project, you should burn that list. Unfortunately, these things become tempting distractions for a project team, and the team members will often spend too much time on them and neglect the musts and wants. Do be careful. What is a nice feature for one stakeholder may be a must feature for another. So you may have to spend some time getting consensus on your final list. Let’s summarize what we have learned.

You must have a statement that tells everyone where they are going, and if you don’t like the word mission, then call it a goal, objective, or target. I’m going to stay with the mission because it is the correct term. And the mission is always to achieve the vision for the project outcome.

And the vision, quite simply, is a definition of the characteristics of that outcome. It may be truly visual for tangible things like houses or hardware. But it may be simply a concept for something like software. In fact, the vision for software has more to do with how it functions than it does with actual visual effects. For example, a photo- editing software program would allow you to crop a photo just by dragging a rectangle around the part of the overall photo that you want to retain and clicking your mouse button; the unwanted part disappears. Can you “visualize” this functionality? If you have used PhotoShop^® or other editing programs with this feature, you know what I’m talking about. But if you have not, I would expect my description to still allow you to “see” it in your mind, and that is what we are talking about.

So a vision depicts the final result of the team’s efforts. It’s that simple. If you know what the result is supposed to be, you will know when you’re finished with the job. Otherwise, you may not be certain that the job is done.

Writing problem, mission, and vision statements is not a popular exercise. People often see it as a waste of time. When you have one member of a team who thinks that you should be going in one direction and others who have their own ideas of the right direction, you can’t expect to have a cohesive result. People will take you where they think you are going, not where you want to go.

Now that we have seen the difference between problem, mission, and vision, let’s take a closer look at problems and how they are defined, because this is where many headless-chicken projects are created.

PROBLEMS, PROBLEMS

Dr. Juran defined a project as a problem scheduled for solution. That is, we are solving a problem on a large scale when we do a project. Building a bridge solves the problem of not being able to get across a river or gorge easily. Developing an automobile solves the problem of not being able to transport people from one place to another easily.

Developing an insurance package provides protection against financial ruin for people. Financial ruin would be a major problem—a problem that is solved by the insurance package.

In the same way, every project solves a problem for the organization, but we often make the mistake of assuming that we understand the problem when in fact we do not. As an example, let us suppose that you have a headache. You assume that the cause is stress, so you take some capsules for pain, and the headache goes away. The next day it returns, so you again take some pain pills. It retreats.

This is repeated for an extended period until you finally become concerned and go to the doctor. After some exhaustive tests, the doctor reports that you have a brain tumor that can be removed only by surgery.

You have been treating the symptom—not the cause—of the problem. The symptom is the headache itself. The cause is the tumor.

This is typical of many attempts to solve problems. The way we define the problem always determines how we try to solve it. If the definition is incorrect, the solution won’t work.

This is the major cause of headless-chicken projects.

We don’t spend enough time working out the actual definition, and so we may very well develop the right solution to the wrong problem, leaving the organization with the original problem that the project was intended to solve.

If we are to ensure that our projects don’t solve the wrong problem, clearly, we must spend more time on the definition stage. Furthermore, we need to have a clear understanding of what is meant by a problem, because the word is used so loosely that it means many things. We say that the headache is a problem when it is actually a symptom of the underlying cause. We claim that the problem is slow sales, when this again is but a symptom of some larger cause. So there is a tendency to equate symptoms with problems, guess at the cause, and go off on a happy hunt for the witch that we think caused the symptom.

Every project is conducted to solve a problem for someone. Usually, the sponsor has an idea in mind of what things will be like when the problem is solved. This is his or her vision for the final project outcome. The mission of the project team is to achieve that vision, which will presumably solve the problem.

However, you seldom receive a statement of the problem when you are assigned a project to manage. Rather, you are given a description of the outcome you are supposed to achieve. Perhaps it is to develop software or a product. Maybe it is to build an office building. It may be a fund-raising campaign. Whatever the nature of the job, you will be told that you are expected to make it happen—whatever “it” is.

In many cases, this is fine. If you do what you have been told to do, it will solve whatever problem your sponsor has. However, if the sponsor has misdefined the problem to be solved, then you may do what you are told to do, but the organization will still have the original problem. For that reason, when you are assigned a project, you should examine the problem to be solved and determine whether doing the project as assigned will achieve the desired result. If it won’t, then you need to discuss this with the project sponsor, being careful to express your concerns diplomatically, of course. If the sponsor insists that you do the job assigned, even though you are convinced that it won’t solve the intended problem, then you may have to acquiesce, but in that case, I suggest that you have an up-to-date résumé handy.

A problem is defined as a gap between where you are and where you want to be, confronted with obstacles that make closing the gap difficult. It is actually the obstacles that make the gap a problem. As an example, if you are at one end of a long hallway and you want to go to the other end, that is a simple goal. However, if someone puts a large alligator in the hall, and you know that the alligator will bite off your leg if you try to pass, then you truly have a problem. The essence of all problems is dealing with alligators! You must remove them, get around them, or momentarily neutralize them if you want to reach the other end of the hall.

There is another alternative. It may be that you want to reach a room just off the end of the hallway, so instead of going down the hallway that contains the alligator, you detour to another path to get to the desired destination. You have avoided the alligator altogether. This is the essence of creative thinking—finding another route to the solution that can be easily navigated.

Open- and Closed-Ended Problems

There are two categories of problems—those that have single solutions and those that have multiple solutions. Those with single solutions are called closed-ended problems. Those with multiple solutions are called open-ended problems.

Solving problems in each category requires a different approach. Closed-ended problems are best solved using a left-brain analytical approach, whereas open-ended problems are best solved by applying a right-brain synthesis approach. In terms of the Herrmann brain dominance model, we would expect quadrant-A thinking to be required for solving closed-ended problems and quadrant-D thinking to be required for solving open-ended ones. Remember, of course, that a preference for thinking in a certain quadrant does not indicate ability. We all have a whole brain. However, if your preference is very strong for the A quadrant and very weak for the D quadrant, you will probably be drawn to analytical problems, and vice versa.

Interestingly, American education is largely focused on solving closed-ended problems. Very little attention is given to solving open-ended ones, yet there are far more open-ended problems in the world than there are closed-ended ones. The result is that we leave school with a mindset that all problems are closed-ended, and we have limited skills for solving open-ended problems. Of course, projects demand that we deal with both kinds of problems.

As an example, an environmental cleanup project is closed ended. So is a project to overhaul a piece of equipment, repair a car, or discover the cause of a disease. On the other hand, a project to develop new software or hardware is open ended, as are projects to build a house, improve a process, sell a product, or develop a project-based organization. One way to think of these is that closed-ended problems are oriented to the past, while open-ended ones are oriented to the future.

Repairing a car is an attempt to return it to a condition that existed previously. Math problems are closed ended; the solution exists already. We are simply trying to discover it.

Building a house, however, is open ended. The house does not yet exist. There are several ways to build it. You may say that one approach is better than another, but that does not negate the fact that there is more than one way to go about it. The same is true for developing a new product; it does not yet exist, and there are several approaches to designing it.

DEFINING CLOSED-ENDED PROBLEMS

For closed-ended problems, the best approach to defining the problem is to use what is commonly called the scientific method, which consists of the following steps:

   Ask questions.

   Develop a plan of inquiry.

   Formulate hypotheses.

   Gather data to test those hypotheses.

   Draw conclusions from hypothesis testing.

   Test the conclusions.

Constructing a Good Problem Statement

Also, at this point, it is essential to develop a solid problem statement. The guidelines for doing this are as follows:

1.   The problem statement should reflect shared values and a clear purpose.

2.   The problem statement should not mention either causes or remedies.

3.   The problem statement should define problems and processes of manageable size.

4.   The problem statement should, if possible, mention measurable characteristics.

5.   The problem statement should be refined (if appropriate) as knowledge is gained.

Defining Closed-Ended Problems with Problem Analysis

As was previously stated, closed-ended problems have single solutions. Something that used to work is now broken. The remedy is to determine what has broken and repair it—a single solution. To solve closed-ended problems, we use a general approach called problem analysis.

The diagram in Figure 6.9 shows the steps in the problem analysis process.

Figure 6.9 Problem Analysis Steps

Identification

The first step in the problem analysis process is identification. “How do I know I have a problem?” In general, you know that you have a problem because a system that previously performed properly suddenly ceases to do so. Symptoms of this misperformance will tell you that something is amiss. In the case of mechanical systems, strange noises may be coming from within the machine. Or the level of performance changes—an automobile quits running, for example, or a tire on your bicycle goes flat.

In biological systems (people, plants, and animals), illness occurs. You have a severe headache. That is a symptom that something is wrong with your body. It is not performing as it usually does.

As previously stated, a problem is a gap between a desired state and a present state, confronted by obstacles that prevent easy closure of the gap. As just described, when a process is involved, that gap is a deviation from standard performance. In monitoring progress in a project, there is an index called a critical ratio, which should have a value between 0.8 and 1.1. When the critical ratio falls outside these limits, it’s a signal that a potential problem exists with the task in question. This is where problem analysis begins in that situation. (The critical ratio, which is part of earned value analysis, is covered in depth in Chapter 12.)

What Is the Normal Performance?

When dealing with deviations, we must know the performance norm. How is the system supposed to behave? The human body is supposed to perform pain-free. Your automobile is supposed to accelerate from 0 to 60 mph in a certain time. It should get so many miles per gallon on the highway. Of course, this will vary somewhat depending on road conditions and the driver’s style. All systems exhibit variation around normal performance. Some systems will have very small levels of variation, and some will have large levels of variation.

In the same way, some project work will have much more variability than other project work. For that reason, the critical ratio limits might be set tighter for some tasks than for others. Once the normal variability is known, we can determine if the deviation is significant, and whether it is positive (performance better than the norm) or negative (performance worse than the norm).

To summarize: A problem is recognized because the effects produced are different from the normal outcomes expected from the system or process. Those effects might be a change in scrap level, higher or lower production, or a drop in customer purchases.

Determining the Cause

To correct for the deviation, we need to find its cause. For a desirable deviation, we must know the cause so that we can replicate it. For an undesirable deviation, the cause must be remedied. To determine the cause of the deviation, we employ a process called description of the problem.

Description Using Is/Is-Not Analysis and Stratification

Stratification and is/is-not analysis are ways to localize a problem by exposing underlying patterns. This analysis is done both before collecting data (so that the team will know what kind of differences to look for) as well as after it (so that the team can determine which factors represent the root cause).

To stratify data, examine the process to see what characteristics could lead to biases in the data. For example, could different shifts account for differences in results? Are mistakes made by new employees very different from those made by experienced individuals? Does output from one machine have fewer defects than that from another?

Begin by making a list of the characteristics that could cause differences in results (use brainstorming here). Make data collection forms that incorporate those factors and collect the data. Look for patterns related to time or sequence. Then check for systematic differences between days of the week, shifts, operators, and so on.

The is/is-not matrix in Figure 6.10 is a structured form of stratification, based on the ideas of Charles Kepner and Benjamin Tregoe (1965).

Figure 6.10 The Is/Is-Not Matrix

Analysis

Once stratified data has been collected, the differences can be analyzed so that hypotheses concerning causes of the problem can be formulated. The following questions are designed to help identify differences:

What is different, distinctive, or unique between what the problem is and what it is not?

What is different, distinctive, or unique between where the problem is and where it is not?

What is different, distinctive, or unique between when the problem is seen and when it is not?

The focus of these questions is to help us determine what has changed about the process. If nothing had changed, there would be no problem. Our search should be limited to focusing on the following question: What has changed about each of these differences?

Noting the date of each change may also help us relate the start of the problem to some specific change that was made to the process. Perhaps a different person was doing the job when the change in performance occurred. Maybe there was an electrical storm. Perhaps a new shipment of raw materials came in.

Hypotheses

A hypothesis is simply a conjecture or guess about the possible cause of a problem. We form hypotheses based on our data collection and analysis. Then we test them to determine if we have guessed correctly. At this point, all reasonable hypotheses should be listed. Nothing should be excluded because it seems improbable or because it was suggested by someone who is not deemed credible as an expert on the subject.

One of my favorite stories about solving problems came from a Japanese semiconductor plant. The plant was experiencing low-yield problems in making a new chip. The engineers were working frantically to determine the cause of the problem, but they were making no progress. One morning an 18-year-old woman who had only recently taken a job at the plant was on her way to work. She rode a bicycle, and as she approached the plant, a train passed by. She had to wait until the crossing was clear before she could proceed.

As she stood watching the train, she noticed that the ground was shaking. She had heard about the yield problem and wondered if the vibration from the train might be a factor. She posed this question to her supervisor, who passed it on to the engineering group. A member of the group decided to test the hypothesis. He rented a ditching machine, dug a large trench between the building and the railroad track, and filled it with water to absorb some of the vibration, and the yield problem was solved! (Subsequently the firm shock-mounted their equipment—the ditch was a temporary fix.)

An important point about this story is that in many cultures, this young woman’s idea would have been totally dismissed because she was not an expert in engineering. In Japan, however, contributions from anyone tend to be welcomed.

Cause-Effect Diagrams

One of the most used tools for formulating hypotheses is the Ishikawa, or cause-effect, diagram, also called the fishbone diagram because it resembles the skeleton of a fish. An example is shown in Figure 6.11. It can be used separately or in conjunction with is/is-not analysis to help formulate hypotheses. As shown in the diagram, four general categories of causes are standard. Here we use manpower, machines, methods, and materials (there are other possibilities, but these four are common). For each category, we ask whether some change has occurred that might explain the problem. Has a person who is not properly trained been assigned to the job? Was someone sick on the day the problem began? Are people not following standard operating procedures? Is a machine out of adjustment? Is an improper method being used to do something? Are materials defective or incorrect?

Figure 6.11 An Ishikawa Diagram

Using brainstorming by a group to generate ideas, all possible causes are listed on the branches. Again, it must be emphasized that censoring ideas is not allowed.

Test Hypotheses

Once ideas have been generated, they must be tested. To test hypotheses, we first ask if the suspected cause can explain both sides of the description. That is, the cause must explain both the is and the is-not effects. If it cannot explain both, it is unlikely to be a real cause.

To save time, the group will usually try to determine which of many causes is the most likely one. This may be done simply through intuition. Headaches are most frequently caused by stress; thus, a doctor might ask a patient if she has been under a lot of stress recently. If this is not the case, then other possible causes would be examined, possibly by having the person undergo a number of tests, such as brain scans, blood tests, and so on.

The testing method follows:

   Test each possible cause through the description, especially the sharp contrast areas.

   Note all “only-if” assumptions.

The most likely cause will be the one that best explains the description or the one with the fewest assumptions. To be certain, you must now verify the hypothesis quickly and cheaply.

One test is whether you can make the effects come and go by manipulating the factor that is supposedly causing the deviation. If you can, you have probably found the true root cause. If a doctor believed that you were having headaches because of an allergy, tests would be run to determine if the allergy existed. If it did, you would be advised to avoid that allergen. If the headaches ceased, then the allergen was the most likely cause. Note that we could test this by deliberately exposing you to the allergen, but most people are happy to have the headaches go away and are unwilling to submit to this second part of the test. In testing hypotheses in general, however, this is a valid method of confirming that a cause is the one we are looking for.

Action

While we are testing hypotheses, or trying to determine the root cause, there are three possible types of action that we might take:

Interim action. You buy time while the root cause of the problem is sought. This action is only a “patch” for correcting symptoms. You may, for example, take painkillers while doctors try to determine the cause of your headaches.

Adaptive action. You decide to live with the problem or adapt to it. There are people who learn that they are allergic to certain foods and should give them up, but they love these foods so much that they decide to live with the symptoms instead.

Corrective action. This is the only action that will truly solve the problem. It is aimed at the actual cause of the problem, rather than simply alleviating symptoms.

Design of Experiments

There are times when single causes do not account for problems. As an example, a biotech product may have many ingredients, each of which must have a concentration that falls within a certain range or the final product won’t perform correctly. I know of one such case in which the cause of product misperformance was believed to be an enzyme, but it turned out to be the concentration of a buffer that was incorrect. This was determined by running an experiment in which various factors could be changed simultaneously and observing the outcome. This approach allows testing of both first-order and second-order (interaction) effects. Second-order effects are particularly difficult to identify unless such an approach is used. For example, it may be that both the temperature and the concentration of a buffer must be off for the defect in performance to occur.

It is outside the scope of this book to explain the design of experiments. The interested reader should consult a good book on the subject, such as Walpole (1974).

DEFINING OPEN-ENDED PROBLEMS

There are generally more open-ended problems than closed-ended ones. This is especially true of projects. The problem being solved by a project is likely to require different methods from those presented previously for solving closed-ended problems. Even the approach used to define the problem is different. For closed-ended problems, the scientific approach to analyzing data can be used. A closed-ended problem has a cause. There is no cause of an open-ended problem, so we need different methods for defining it. The techniques that follow are intended to help you develop good definitions for open-ended problems.

Remember also that open-ended problems do not have single solutions. When there is a cause of a problem, the solution is to remove the cause. For open-ended problems, no such action is possible. We often refer to these as creative problems, and they are characterized by the question, “How do I make something happen?” As examples:

   How do we design a product to perform in a certain way?

   How can I pay for my child’s college education?

   How do we send someone to the moon and bring him back safely?

   How do we penetrate a certain market?

I should mention here that Dr. Edward de Bono is considered by many people to be one of the leading experts on creative problem solving, and his book Serious Creativity (2015) covers the subject in more detail than this chapter can possibly do. I heartily recommend that you consult Dr. de Bono’s works.

The procedure outlined in Table 6.1 is designed to help you develop a good definition for an open-ended problem. However, it is only one approach, and others are presented following the table. Note that you are not trying to solve the problem with this approach, even though there are questions that begin “If I could solve the problem . . .” You are simply trying to understand what the problem is. You are really trying to understand the nature of your desired outcome. That is, when the problem is solved, where will you be, or what condition will exist?

TABLE 6.1 An Exercise to Develop a Good Problem Definition

I have had people do this exercise many times, and through this process, they often find that the problem they thought they were solving was, in fact, not the correct problem. For example, a person might begin by stating the problem as needing to buy a new car and wondering how to afford it. On closer examination, she finds that what she really wants is reliable transportation to work every day; a car is only one way of accomplishing this goal.

The Goal-Orientation Technique

Unless you are clear about your goal, you are certainly not likely to achieve it. Most important, there is little value in achieving the wrong goal—as would be true if a person bought a car, only to realize that the real goal was getting to work, and that this could have been achieved with less expense.

Goal orientation is an attitude, first. Second, it is a technique to encourage that attitude. Open-ended problems are situations in which the boundaries are unclear, but in which there may be well-defined needs and obstacles to progress.

The goal-oriented person tries to recognize the desired end state (“what I want”) and obstacles (“what’s stopping me from getting the result I want”).

To illustrate the goal-orientation technique, consider the problem outlined in Table 6.2.

TABLE 6.2 Use of the Goal-Orientation Technique

The Successive Abstractions Technique

Suppose a company that makes lawn mowers is looking for new business ideas. Their first definition of the problem is to “develop a new lawn mower.” A higher level of abstraction would be to define the problem as “develop new grass-cutting machines.” An even higher level of abstraction yields “get rid of unwanted grass” (see Table 6.3).

TABLE 6.3 Successive Abstractions

Another definition of the problem, of course, might be to “develop grass that grows to a height of only ‘x’ inches above the ground.”

Analogy and Metaphor Procedures

One interesting way of describing problems is through the use of analogy or metaphor. Such definitions help increase the chances of finding creative solutions to problems and are especially useful in group techniques, such as brainstorming. In fact, they are preferable to literal statements, since they tend to be extremely effective in stimulating creative thinking. For example:

“How to improve the efficiency of a factory” is a down-to-earth statement.

“How to make a factory run as smoothly as a well-oiled machine” is an analogical redefinition.

“How to reduce organizational friction or viscosity” is a metaphoric definition.

Wishful Thinking

Many left-brained, rational people do not appreciate the value of wishful thinking. However, wishful thinking can provide a rich source of new ideas. Dr. Edward de Bono, in his work on creative thinking, talks about an “intermediate impossible”—a concept that can be used as a stepping-stone between conventional thinking and realistic new insights. Wishful thinking is a great device for producing such intermediate impossibles.

Rickards (1975) cites the example of a food technologist working on new methods of preparing artificial protein. As a fantasy, she considers the problem to be “how to build an artificial cow.” Although the metaphor is wishful, it suggests that she might look closely at biological systems and perhaps look for a way of converting cellulose into protein, which is what takes place in nature.

Remember the statement from Table 6.1: “What I would really like to do is . . .” Or try this approach: “If I could break all constraints, I would . . .”

Nonlogical Stimuli

One good way of generating ideas is through forced comparisons. This method can be used for developing ideas for solving a problem, or as an aid to redefinition. Table 6.4 is an example of the procedure, used in conjunction with a dictionary.

TABLE 6.4 An Exercise in Nonlogical Stimuli

Design Tree

Another phrase for a design tree is “Mind Map^®,” which is a trademark of Tony Buzan. The design tree has been used by many people to illustrate associations of ideas. For example, you can use the design tree to outline a book. You begin by writing a single word—representing the issue you want to deal with—and then draw a circle around it. Next list all the ideas that come to you, connect them to the first word with lines, and continue by examining each new word in turn for the ideas it might trigger. I used the word transportation to illustrate the approach (see Figure 6.12).

Figure 6.12 Design Tree for Transportation

Expectations, Deliverables, and Results

It would be nice if all we had to worry about was meeting PCTS targets in a project, but this is not the case. We also must deal with the expectations of stakeholders, as I explained in Chapter 1. Clarifying stakeholder expectations is as much a part of project definition as anything else, and meeting those expectations is necessary for the project to be judged a success.

In addition, you must ask, what results is this project intended to get, and what must we deliver to achieve those results? The answers to these questions should help you in developing a crisp, shared mission and vision for your project.

Be aware that if a stakeholder changes midway through the project, you will have to go through the process of clarifying the new stakeholder’s expectations. You can’t just assume that if you meet the expectations of the former stakeholder, everything will be okay. The new person will see the job differently from his or her predecessor, and you will have to negotiate those things that can be accommodated and those that cannot. The new stakeholder may have totally unrealistic expectations about deliverables and results, and you must bring the new stakeholder in line with reality.

You may think of this as one of the political aspects of the project management job, and it is. Ignore it at your own risk!

THE FALLACY OF PROJECT MANAGEMENT ASSUMPTIONS

Everything I have written about managing projects would be ideal—if the process could be made to work the way I have suggested. However, there is a huge fallacy in the assumptions we make about managing projects, and that is that the world will stand still while we execute our carefully constructed project plan. This simply isn’t true, and we know it.

As I discussed earlier, stakeholders change, and with new stakeholders come new expectations, requiring us to adapt our project to meet those expectations or be judged negatively when the project ends. Furthermore, as projects evolve, we learn things that we didn’t know at the beginning. If we are developing software or hardware, we have new ideas about how the final product should function. For that reason, many products are adaptive in nature and cannot be planned deterministically.

I believe this is a major reason why software development projects have such high percentages of missed targets. Remember the Standish Group study that shows that only 17 percent of software projects meet the original PCTS targets? It’s no wonder. The targets are constantly moving. (This is one reason why Agile and eXtreme management methods are being adopted by IT and software project managers.)

I speak from experience. I once developed an online training program for my website. I began by defining what I wanted it to do. As I neared completion of the project and started testing the program on a temporary dummy site, I began to realize that I could make the program far more effective by making some changes. I also thought of functions that had never occurred to me a year before. So the job took nearly twice as many programming hours as originally estimated, but I wound up with a significantly better product as a result.

Could I have used the product in the form originally defined? Yes, but it would not have had the utility of the present version.

You must exercise caution, of course. If you continually make changes to a product in response to new ideas, you will never release it. This is the trap into which perfectionists fall. They can never finish a design because they can always make it better.

You must decide if a change is needed to make the result as functional as it must be in the final application. If the change is not made, can the resulting product be sold? Will it be accepted by the customer? If the change is made, will it delay product introduction to the marketplace so much that competitors will seize the market share and cost you all of your profits? These are not easy questions to answer, and they should never be answered unilaterally by technologists. Many technologists have very little grasp of market dynamics and will opt for technical improvements even if the product never sells.

The message here is that project planning must be done with the understanding that there must be flexibility enough to respond to legitimate environmental forces, without going so far as to become aimless. On construction projects and other well-defined jobs, this is not such a big issue. Software, hardware, and scientific work (such as drug development), however, are more likely to require an adaptive, rather than a deterministic, management approach.

IN SUMMARY