Project Planning, Schedule & Control–Chapter 6: Headless-Chicken Projects and How to Prevent Them


This blog post is part of a series that summarizes the 5th edition of the classic project manager’s handbook Project Planning, Scheduling & Control by James L. Lewis, Ph.D., the founder of the Lewis Institute, Inc.    I wanted to go through the book and take notes for my own use, but also in the hope that my summary would be of interest to both those already in the project management field or those who want to enter that field.

Section One of the book covers Introduction to Project Management, and contains Chapters 1 through 5.

Section Two of the book covers Project Definition, and contains Chapter 6.  This post covers this one chapter that covers the Initiating Process Group.

1.  HEADLESS-CHICKEN PROJECTS

Dr. Lewis begins with a description of the behavior of a headless chicken which he encountered in his boyhood while living in the country.   After a chicken’s head is cut off, the body runs around spewing blood for a few seconds, and then it falls over and quivers a bit, at which point the chicken is officially dead.    In reality the chicken died when you cut off its head, but it takes some time for the message to reach the body.   His analogy with project management is that many projects actually die during the initiation process, but their death only becomes apparent in later stages.

A study done by the Standish Group in 1994 showed that 83% of all projects suffer serious problems, and only 17% of them succeed.    Of those projects that suffered serious problems, 50% ended up being revised, and 33% failed outright.

2.  THE CAUSES

Consider the launching of a project.    What is the problem with this series of steps?

  • Project sponsor conceives the need for the project
  • Project manager is recruited
  • Project manager assembles team, tells team members about the project
  • Team members say nothing
  • Project manager assumes all team members are in agreement, and all understand the mission

What is the problem?   The project manager had a failure of leadership.   It is not a failure to manage agreement, but a failure to manage disagreement that is the cause of future problems on this project.   Why?   The team members weren’t in agreement, and did not understand the mission.   However, they were afraid to do so in front of others for fear or appearing stupid.    Remember, silence does not equal consent.    This is referred to by Dr. Lewis as the Abilene Paradox, that everyone appears to agree to an outcome, mainly because no one is willing to disagree.

3.  OVERCOMING THE ABILENE PARADOX

The project manager did nothing to make the team members feel like they are a team.   The team members need to get actively involved in defining the project, which includes examining the problem to be solved and then developing a mission statement by the following process:

  • Each person prepares a statement of the team’s mission
  • These are compared, and differences are resolved
  • The group then combines individual views into a team statement reached by consensus
  • The group reviews and critiques the meeting, in order to improve future meetings
  • The mission statement is published and all members receive copies

Okay, what happens if there are discrepancies between the team members in terms of where the team is going?   For the sake of illustration, let’s say that one person is going in a different direction than the others on the team who are all going in the same direction.   There are three ways to resolve this:

a.  Convince the person to go in the same direction as the others

This is done through discussions in which the individual’s misunderstandings are corrected.   If the person understood the direction but disagreed with it, then he may need to be convinced of the proper direction.

b.  Change the direction of the entire team (paradigm shift)

It could be the “errant” person understood or thought of the mission in a way that everyone else missed.  In this case, the team agrees to change to the direction advocated by the individual in what is called a paradigm shift.

c.  Remove the person from the team

If a core team member disagrees with the mission as it is seen by the other members and that person refuses to change his direction, then the best decision is to remove the person from the team.   As it difficult as this decision may sound, the first objective for a project manager is to achieve a shared understanding of the team’s mission.   If that person does not agree with the direction of the team, then that person will resist throughout the entire project.    And that outcome is worse than having to remove the person from the team at the very beginning.

4.  MISSION VS. VISION

Here is the difference between a problem, mission and vision statement.

a.   Problem

The starting point is the problem.   It can be stated as a need or a lack that the project must fulfill.   For example, for a person looking for work, the problem is:   I need a new job.

b.  Vision statement

What are the features that the solution to the problem will have?   These must be prioritized in terms of i) must-have features, ii) features that you want, and iii) features that would be nice to have.     The vision is a definition of the characteristics of the final outcome.

c.   Mission statement (can also be called a goal, objective, or target)

The mission is to achieve a solution to the problem with all of the must-have features and as many of the others (want and nice features) as possible.  

5.   PROBLEM DEFINITION

Defining a problem is important, because the way a problem is defined determines how we attempt to solve it.   If you don’t spend enough time working out the actual definition of the problem, you might end up developing the right solution to the wrong problem.   Or to give it another metaphor, you can finally get to the top of the ladder, and realize that the ladder was up against the wrong wall.

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.

There are two kinds of problems, open- and closed-ended problems, which have the following differences.

Closed-Ended Problems Open-Ended Problems
Solutions Single Multiple
Best Solved Using … Left-brain analytical approach Right-brain synthesis approach
Oriented towards … The Past The Future

6.   DEFINING CLOSED-ENDED PROBLEMS

a.   Problem Statement

The steps for creating a solid problem statement are as follows:

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

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

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

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

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

b.   Problem Analysis

Since closed-ended problems have single solutions, you need to find out what is broken, and determine a remedy in order to repair it using problem analysis.   Here are the steps:

i.   Identification of the deviation

A system that previously performed properly suddenly ceases to do so, and you have a symptom of a problem.  The problem is a gap between a desired state and a present state, confronted by obstacles that prevent easy closure of the gap.    This gap is deviation from standard performance.   (In the case of a project, if the critical ratio or CR = SPI x CPI is outside of the range between 0.8 and 1.1, it is a signal that a potential problem exists with the task in question.)

A problem is recognized because of the effects produced are different from the normal outcomes expected from the system or process.

ii.  Description of what the problem IS and IS NOT

There are two ways to localize a problem by exposing underlying patterns:   stratification and is/is-not analysis.

Stratification

Examine the process to see what characteristics could lead to biases in the data.   Using brainstorming to make a list of the characteristics that could cause differences in results.  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 other factors, such as days of the week, shifts, operators, and so on.

Is/Is-Not Analysis

This is a structured form of stratification.   You identify the problem to be analyzed.   You use the matrix below to organize your knowledge and information.  The answers will assist you in pinpointing the occurrence of the problem and in verifying conclusions or suspicions.

IS/IS-NOT MATRIX

ISWhere, when, to what extent, or regarding whom does this situation occur? IS NOTWhere does this situation NOT occur, though it reasonable might have? THEREFOREWhat might explain the pattern of occurrence and nonoccurrence?
WHEREThe physical or geographical location of the event or situation.  Where it occurs or is noticed.
WHENThe hour/time of day/day of week, month/time of year of the event or situation. Its relationship (before, during, after) to other events.
WHAT KIND or HOW MUCHThe type or category of event or situation.  The extent, degree, dimensions, or duration of occurrence.
WHOWhat relationships do various individuals or groups have to the situation/event?  To whom, by whom, near whom, etc., does this occur?

iii.  Analysis of data

Here are the questions you should ask to help identify differences in the data (found in part ii) in order to formulate hypotheses concerning causes of the problem (to be done in part iv).

  • 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 and when it is not?

To find out what has changed about the process that is causing the problem, you need to find out what has changed about each of the differences listed above.

iv.  Hypotheses must be formulated about possible causes

One of the most commonly 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.

The four general categories of causes are:

  • Manpower
  • Machines
  • Methods
  • Materials

v.  Testing of hypotheses to determine root causes

Once the hypotheses for the causes have been identified, they have to be tested with the following question:

Can the cause explain both the is and the is-not effects?

If more than one cause is identified, the most likely cause will be the one that best explains the description of the problem or the one with the fewest assumptions.     To prove that the cause is the true root cause of the problem, you manipulate the factor that is supposedly causing the deviation.    If you can make the effects come and go by manipulating that factor, then you have probably found the true root cause.

If there are multiple causes that need to be tested, then your design of experiments must be able to determine which cause is primary.

vi.  Action which is corrective and (hopefully) solves the problem

There are three possible types of action that you can take to solve the problem once you have identified the root cause.

  • Interim action–you buy time while the root cause of the problem is sought
  • Adaptive action–you decide to live with the problem or adapt to it
  • Corrective action–aimed at the actual cause of a problem

The only action that will truly solve the problem is the corrective action.

7.   DEFINING OPEN-ENDED PROBLEMS

As mentioned above, solving an open-ended problem requires right-brain thinking and creative techniques.   Here are some suggestions for these techniques.

a.   Procedure

i.  Describe an open-ended problem that is important to you and for which you need answers that could lead to action.  Take as long as you wish for this.

ii.  Again taking your time, complete the following statements about the problem you have chosen.  If you cannot think of anything to write for a particular statement, move on to the next one.

PROBLEM DEFINITION

  1. There is usually more than one way of looking at problems.  You could also define this one as …
  2. …but the main point of the problem is …
  3. What I would really like to do is …
  4. If I could break all laws of reality (physical, social, etc.), I would try to solve it by …
  5. The problem, put another way, could be likened to …
  6. Another, even stranger, way of looking at it might be …

iii.  Now return to your original definition (step i).  Write down whether any of the redefinitions have helped you see the problem in a different way.

b.  Goal-Orientation Technique

Create a problem statement.   Try to recognize the desired end stage (“what I want”) and the obstacles to achieving it (“what’s stopping me from getting the result I want”).    For example, if you want to increase adult literacy, you can redefine this problem in the following ways:

  • Efficiently and effectively teach adults to read.
  • Keep kids from getting through school without being able to read.
  • Get parents to take an interest in their kids so that they will learn to read in school.
  • Eliminate the influences that cause kids to take no interest in school.

This technique is akin to step 3 in the Problem Definition procedure outlined above (“What I would really like to do is…”).

c.  Successive Abstractions Technique

A company that makes lawn mowers could take the problem of “develop new lawn mower” and create successive abstractions as follows:

  • Lower level–develop new lawn mower
  • Intermediate level–develop new grass-cutting machines
  • Highest level–get rid of unwanted grass

This technique might generate new business ideas for the company.    It is akin to step 5 in the Problem Definition procedure outlined above (“The problem, put another way, could be likened to …”).

d.  Analogy and Metaphor Procedures

Rather than defining a problem as a literal statement, try redefining it in terms of an analogy or a metaphor.   This is

  • “Improve the efficiency of a factory” is a literal statement.
  • “Make a factory run as smoothly as a well-oiled machine” is an analogical redefinition.
  • “Reduce organizational friction or viscosity” is a metaphoric definition.

This technique is akin to step 4 in the Problem Definition procedure outlined above (“If I could break all laws of reality, I would try to solve it by …”).

e.  Wishful Thinking

This is akin to step 3 in the Problem Definition procedure outlined above (“What I would really like to do is …”).

f.  Nonlogical stimuli

One good way of generating ideas is through forced comparisons, in order to develop ideas for solving a problem.   It is akin to step 6 in the Problem Definition procedure outlined above (“Another, even stranger, way of looking at it might be …).

g.  Design Tree

The design tree is another name for the Mind Map technique, which is a trademark of Tony Buzan.  You write 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.  Continue examining each new word in turn for the ideas it might trigger.   It is akin to step 1 in the Problem Definition procedure outlined above (“There is usually more than one way of looking at problems.  You could also define this one as …”).

8.  SHAREHOLDER EXPECTATIONS

The reason for creating a clear shared mission and vision for your project is so that you can clarify the stakeholder’s expectations.  If they have totally unrealistic expectations about the deliverables and results of a project, you need to adjust those expectations at the BEGINNING of a project.

9.  PROJECT MANAGEMENT ASSUMPTIONS

The big fallacy in project management is the assumption that the world will stand still while we execute our project plan.   In particular, software development projects have targets that are constantly moving, which is one reason why Agile management methods are being adopted by IT and software project managers.

If you are faced with a change to the project while it is being executed, you must decide if the change is needed to make the final result as functional as it must be in the final application.   Try thinking about the situation in the negative:   if the change is not made, can the resulting product be sold?  Will it be accepted by the customer?

In other words, project planning must be done with enough flexibility to respond to legitimate environmental forces.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: