Delusional Project Management

The Diagnostic and Statistical Manual of Mental Disorders defines Delusion as follows:

"A false belief or incorrect inference about external reality that is firmly sustained despite what almost everybody else believes and despite what constitutes incontrovertible and obvious proof or evidence to the contrary. The belief is not one ordinarily accepted by other members of the person's culture or subculture."

I have seen a number of examples of Delusions in Project Management. One example from a while ago was a client decided while they could not do Project X which had medium complexity and would take 12 months, but could do Project Z that included Project X but do it all in 6 months.


Clearly individuals who are not clinically delusional can gather together into a team and collectively be delusional. I am sure there are many examples of such behavior.


What I am wondering is are there good methodologies for doing organizational psychotherapy to help such organizations and teams perform better?

Is there such a thing as too much staffing?

Many of us learn early in our lives all things, even good things, must be taken in moderation. Staffing for projects is one such good thing. I am sure we have all experienced projects that are run with too little resources. We know the normal symptoms of a project that is resource starved -- delays, quality and morale issues and perhaps failure.

However what would happen with a project that has too many resources? Would Brooks's law, which says that adding manpower to a software project that is behind schedule will delay it further, apply? Lets further complicate the issue by asking what would happen if the project begins with too many people to begin with, i.e. people are not being added late.

There are two common explanations for Brooks's law (http://wen.wikipedia.org/wiki/Brooks%27s_law) :

1. New staff take time and resources to ramp-up and are therefore not immediately productive and distract the experienced resources.

2. Communication overhead increases as we add more people. The number of different communication channels go up a square of the number of people.

However when the project is new problem #1 (ramp up time) is not a large contributor. However problem #2 -- communication overhead is a killer.

There is a 3rd problem that arises in the most extreme cases over-staffing; when the number of resources available exceeds the amount of work that can be performed at that time. When this happens in a manufacturing process we have idle machines. Machines are not aware of being idle and do not react to their idleness. People tend to be very aware of being idle. Idle machines might be ignored or eventually redeployed, Idle people usually become unemployed. So people start manufacturing work to stop being idle.

Work manufacturing can happen in two broad categories: scope creep and process creep. Scope creep usually refers to uncontrolled changes to a project's scope, but I am using it to mean changes that are not necessary to deliver the business case for this project.

Process creep is like scope creep except the changes are not made in deliverables of the project but the steps used to create the deliverables and manage the project. Of the two process creep is the more insidious because it is much harder to detect and control.

Good project gone bad

So you have a project plan, you have contingency plans, you have a methodology, you have a PMO and your project still goes to hell in a hand basket. What do you do?

There are simple options that are not really the purview of Project Management but need to be acknowledged first. Option 1 is ignore it. There are a lot of variants of "ignore it" which include "assign blame", "I am a victim" and "this is the way all projects of this kind go" etc.

The other simple option is to disengage. Disengagement can occur in a number of different ways which can range from people leaving the team to people withdrawing ideas and effort short of leaving the team.

If you are the PM or responsible leader for this project and cannot personally follow a simple option, it will still be important to remember that others have simple options.

If you are responsible for a turn-around strategy for a project:

Step 1: Recognize the situation requires a turn-around
Step 2: Assess the current state
Step 3: Define the goal state and how the current state deviates from goal state.
Step 4: Define a turn-around plan. Check if the project is still worth saving.
Step 5: Get buy-in
Step 6: Start the new project.