Archive for the 'theory' Category

I last wrote about Designing Breakdown-Tolerant Project Environments in a four-part series: [1] [2] [3] [4]. It's not complete — my thinking that is!

I keep thinking about uncertainty and variation. One of my clients says we are preoccupied with making our futures certain. Wondering, I think we just don't have enough trust in the strength of our relatedness. The more related we are, the greater chance we have of a future that is perfect. Yes, I know this is philosophical. So am I. However, I see this like luck. There is no luck. There is only preparation meeting opportunity. (Anyone know where that came from?) The best preparation we can make is in getting connected with others. By doing so, they will take care of us as we take care of them.

So…I have more to write, particularly a summary of what I started. That'll have to wait 'til tomorrow!

Life happens. It just does. If we wake up in the morning we are bound to be surprised at some moment during the day. I bought a Jeep Wrangler to share with my about-to-be 17 year-old son. The vehicle had 71,200 miles on it when I purchased it. I was naturally concerned about the condition of a Jeep with that many miles. So I asked many questions of the salesman. Each answer was intended to reassure me. I asked, "When I drove it at 65 MPH, there was a rumble." He said, "I noticed that too. It's a shimmy. I'll have them balance the front tires. That'll take care of it." "What condition are the brakes in?" I asked. "Don't worry. We do a 152-point check on all vehicles that go through this place," he said, matter-of-fact. "What if I find something driving it around next week?" "We offer a 90-day or 3,000 mile warranty to cover just those cases." "What about after that?" "The business manager will offer to sell you an extension on that warranty. I'd go with the 'plus' version." "One last thing," I say. "I noticed a strong smell of cigarette smoke. Is there something that can be done about it?" "I'll have them recondition the interior for you." He adds, "I think that should take care of you."

So I do the deal. I have to come back the following day to pick up my vehicle. I'm feeling good about it. With a 152-point check-up, a reconditioned interior, and a 90-day warranty I feel comfortable sharing this car with my son. So I show up the next day. They tell me the car is ready. I go through the whole process with the business manager. I put off buying the additional warranty because she whispered to me she can offer me a better deal at the end of the month.

Driving the car away I notice that new vehicle smell instead of the stale cigarette odor. I get up on the highway. I get to 65 MPH, no shimmy. I'm thinking that everything is just fine. But it's not. There are coffee stains in the cup holders. The ashtray is dirty. There are milk shake drippings on the dashboard. I start wondering what it means to recondition the interior? The following morning I drive to a state inspection station. After waiting 70 minutes the mechanic starts checking the Jeep out. I find out I have no brake lights. I let my son drive the Jeep the previous night. How could they miss brake lights on a 152-point check-up? Working brakes are part of a state inspection. I later find that the windshield washer fluid is not working. How do you miss that? Wouldn't you expect that anything that can be operated by the driver would be checked on a list of 152 items? So, I went back to the dealer. And this is what I learned.

They don't do a 152-point check up. They do a 125-point check on 'certified' used vehicles. My Jeep has too many miles to qualify for certification. Why was I told that? The sales manager couldn't explain. How did they miss the brakes? It seems the previous owner installed a switch that cut out the brake lights for towing behind an RV. I asked about the switch. The salesman assured me that the switch didn't work. "They always disable after market gadgets." Except this time they didn't. This was one breakdown after another for me. My commitment is to have road worthy vehicles for my family to drive. I had no idea of the real condition of my vehicle. What looked like a good sales process actually depended on knowledge and individual follow-through. There was no process to make it resilient. And this is at the number one Jeep dealer in New England. And when I brought this to the attention of the sales manager he didn't apologize.

With that as background, there are two key actions to take to create resilience to the breakdowns on projects.

1. Expand the group of people who can assess and declare breakdowns.
2. Empower those people to take compensating action.

Taking an assignment doesn't have the same effect on a person as negotiating and making commitments.

The usual practice on projects is for someone with power and authority to both declare and respond to breakdowns. That person is usually the project manager. The person in authority is usually not present to the circumstances of the breakdown. More likely, a team member reports a problem up the chain of command.

There are many shortcomings of current practice. If you buy my contention that we only declare breakdowns if we have commitments that are in jeopardy, then we won't get performers who take assignments declaring breakdowns. Taking an assignment doesn't have the same effect on a person as negotiating and making commitments. The person handing out assignments is the one who made the commitment…maybe. As Greg Howell says, the more likely scenario is "the project is a commitment-free zone." No commitments, no breakdowns.

Designing the project environment for breakdown-tolerance requires distributing accountability for the outcome of the project. The wonderful thing about sharing accountability with performers is they are closer to the action and circumstances of the project. That proximity allows them to make commitments grounded in their reality of the project. Having made commitments, they will be attuned to those circumstances that put the commitment at risk. When performers are authorized to declare breakdowns and then respond, the project gets a practice of in-the-moment control (steering) of the project rather than after-the-fact control (correcting).

I am having fun driving the Wrangler. I've had my mechanic do a thorough check. All systems are working fine.

Please offer your comments and questions. I'll put a wrap on this tomorrow or the next day.

Previous in series Next in series

In the first part of this series I explored the circumstances for breakdowns and the action to take to minimize the general situation for breakdowns:

Make commitments at the last responsible moment by engaging in recurrent conversations exploring, "Is it time to act?"

Step Two: Making commitments with confidence that they can be fulfilled as promised

No commitment no breakdown. But how about making commitments that will be fulfilled? Eventually, we must commit. It's what is done on projects. Someone says, "I need this." Someone else agrees (promises) to provide it by a given time. But a promise is not a promise is not a promise. When Someone says, "I hope to have it for by the end of the week," that person is announcing that it might not get done by the end of the week. When someone says, "You'll get it when I get something else," they are saying they don't know what they can do. This is the usual way of speaking on projects. AND we suffer for it.

Many of you know my writings on reliable promising. I'll skip that here. What each of us wants when we make a commitment is the confidence that barring extraordinary circumstances we are in the position to fulfill the commitments we make. From where do we get that confidence? First, we are confident when we do those things that we've done (successfully) before. When asked to do the familiar task we know how to respond with confidence in our commitment. Projects are full of familiar tasks. The trick is to find out for whom the task is familiar. People new to the project team and inexperienced people will not commit with a grounded confidence.

Projects are also full of novelty. (That's one of the aspects that make projects so exciting.) By definition we don't have experience in that which is new to us. So how do we have confidence when we commit? The same way we place confidence when we select a surgeon or any specialist service provider whose specialty is outside our area of competence. We make assessments about the quality of the other's assessments.

The doctor says, "The weakness you feel is associated with your heart. We must do surgery immediately." What do you do? You probably ask the doctor to explain the situation to you. You might also go on to explore why the recommendation is surgery and why immediately. But we don't stop there. We go get a 2nd (or 3rd) opinion. Why? Because we want confidence in the commitment we make. As we listen to the additional opinions we try to gauge two things. First, does the doctor appear to know the subject? Second, does the doctor care for me? We build confidence while exploring those questions.

The process of committing on projects is the same. We prepare ourselves and others to make commitments considering the range of opinions available along with the interest the performer shows in satisfying the project team, the leader, and the customer. Through conversations we build confidence.

To recap, we design our project environment to be breakdown tolerant by having just the commitments open that we must have open. We make commitments one at a time and at the last responsible moment. We also look to make our commitments with confidence that we have what we need to fulfill the promise. These actions go a long way to making the situation more breakdown-tolerant. And life still happens. Breakdowns will still occur. Tomorrow I'll begin exploring the actions for making the environment more robust to the breakdowns that find their way to our projects.

Previous in series Next in series

I left off looking at the question, "Do we make commitments at the last responsible moment or at the most responsible moment?" I looked at the consequences of acting later than the 'last responsible moment' concluding that a breakdown was likely. So the trick is to make it just before the last moment. Which we can never know. What might we pay attention to so that we can anticipate the 'last responsible moment'?

The question is one of prudence. At any moment in the life of the project does delaying a commitment bring advantage to the project? and at what cost? This is known as options. The notion of 'last responsible moment' means we are approaching the point where the gain in waiting is about equal to the cost in waiting. And we can't really know ahead of time what the gains or costs will be. Aargh! Are you as frustrated with this as I am?

Expand the capacity for making the assessment that it is the time to act.

We can pay attention to our collective assessments of risk and opportunity. You're not making public assessments of risks and opportunities? It would seem that if you want to operate to the rule of making commitments at the last responsible moment, then you must make those assessments in public and not just be open to others influencing your assessments but encourage team members to propose more powerful assessments than the ones that you can make.

Let's look at making commitments at the 'most responsible moment'. What optimum is "most responsible" and how would we know it? Perhaps "most responsible moment" is that time when the gain in acting is at its greatest when compared to the remaining gains in waiting. And we can't know. The world is uncertain and unknowable. So what do we do?

Engage in recurrent conversations exploring, "Is it time to act?"

Is it that simple? Yes. Since no one can know for a fact that it is the 'last responsible moment', then the prudent action to take is to expand the capacity for making the assessment that it is the time to act. While I can imagine numerous ways to conduct these conversations, two aspects are paramount. The group must include:

1. the people who have been 'in the field' (doing tasks) to provide a grounded basis for assessing, and
2. the performers who you anticipate will make the commitments.

The principal skill for the conversations is making assessments. Piece of cake.

Tomorrow, I'll start writing about step two in designing breakdown-tolerant project environments: making commitments with confidence that they can be fulfilled as promised. Since I'm making this all up as I go, PLEASE keep writing and commenting. And please know that just because I haven't incorporated your specific comments doesn't mean you aren't having a big affect on me. My mind is racing into the wee hours!

Previous in series Next in series

My exploration of variation started with a chapter title The Corrupting Influence of Variability in Factory Physics (2nd Ed.), by Hopp and Spearman. This book had a huge influence on the development of the Last Planner System of Production Control™ and Lean Construction. (I've skimmed the book a few times.) A 2nd huge influence on Last Planner and Lean Construction was Goldratt's dice game. The game shows the compounding negative effects of dependence and variability in process environments. One more influence on me was my visits to Japan and on-going study of quality.

The generally accepted wisdom is variability is bad. But that accepted wisdom was developed in the production world not the project world. So I decided to start over and look at variability in the project world to see if I would reach any different conclusions. Already I have some new questions. And I suspect those questions will keep me occupied for some time.

I am also clear that the process perspective promoted by the PMIers is not serving us. Projects are not processes. (Someone remind me to come back to this.)

I'll keep going on my current writing path 'til my readers tell me to stop. I can see the breakdown-tolerant project environment continuing while I develop some thoughts around two more steps:

• making commitments with confidence and
• being robust to remaining breakdowns.

I'll then return to 'good variation'. I'm unsettled about where that will take me. There are two issues that I've been writing about since this blog began:

• projects are people-centered and
• effective controls are for people in action.

I also intend to examine the role of leadership as it pertains to all of these issues and project success as I go.

One last comment, I'm not really a leanie, agilista, TOC guy, nor am I a motivationist. I can find usefulness in the worlds of agile software development and CCPM (agile, lean, and CCPM project approaches are all more successful than usual project approaches), but I'm unsatisfied with the (theoretical) foundations of the approaches. I have a yearning for taxonomies and a language for designing projects and the organizations that carry them out. And this blog is where I will continue writing about my search.

I love the title of this posting. If only I really knew how to do it! So let's see what we can uncover and innovate together. (A little rest produces ambition for me.) This is the first in a series of postings on "Designing Breakdown-Tolerant Project Environments".

I received a few comments something like "…breakdowns don't have to be bad." "Good things can come from breakdowns." Sure. We can find or create a silver lining. I'm all for silver linings. But let's avoid, if we can, suffering with or in breakdowns that keep us from delivering on the promises of our projects.

Before I go further I need to comment on the distinction between breakdowns and problems. My definition of a breakdown is an interruption while in the midst of fulfilling ones commitment jeopardizing the completion of the commitment. Our common sense understanding of problems seems to match my definition. For instance, when the car breaks down we often refer to it as a problem. What do we mean? It is a reference to an object that is not performing, is broken, or a situation that we don't know how to take action. I'm not saying there aren't problems. An unsolved math equation is a problem. Not that it is inherently difficult. (And it might be difficult for some.) It's just that we use the term math problem for something that is unsolved. So solving is what we do with problems. The car that breaks down is not just about the car. Breakdowns are personal. An individual declares a breakdown arising out of the prediction that some commitment is now in jeopardy. Breakdowns are always about ones commitments rather than some object. Enough of that. If you are interested in a more philosophical description of breakdowns and problems, read Michael Hamman's Humans and Computing posting Breakdown, Not a Problem. (Write me with your comments or questions.)

The first step in designing for breakdown-tolerance is to reduce what has to be tolerated.

The more commitments we have open at a given time the more likely it is that one will become in jeopardy.

To start the design of a project environment that is breakdown-tolerant let's consider how we make commitments. Remember, no commitments — no breakdowns. So let's make just those commitments we need to make to keep the promises of the project. One way to do that is to delay making commitments. I haven't said delay making the promises to the client. We must do that to get the contract. We need to say what value the client will receive by when for some agreeable price. We don't have to commit to what we will do 17 weeks from now. We might not even have to say what the product or service will be that provides the value. Only that the client will get the value intended. In this scenario we need a process or practice that allows us to navigate the promises to the client. (Sorry for the metaphor.)

By navigate I mean a practice of assessing our progress towards fulfilling our promises coupled to an ongoing practice of planning conversations where project participants make commitments.

(This is getting dense for me. I'll take another stab at it.)

We only declare breakdowns when our commitments are in jeopardy. The more commitments we have open at a given time the more likely it is that one will become in jeopardy. Delaying making commitments reduces the overall probability of a breakdown. Having reduced the overall probability of a breakdown we are now in a condition to be more responsive to the breakdowns we declare. (That's better.) Taking this to the extreme, if we only make one commitment at a time, then we only have one possibility of a breakdown. Voila! Oh, you don't think that's possible or practical? Maybe not. But making 100s of commitments before we need to make them is creating the situation for disaster. Our conclusion then is to follow the rule:

Make commitments at the last responsible moment.

This is an adaptation of a heuristic in The Last Planner System of Production Control™, "to make decisions at the last responsible moment." While it might look the same, there are two important differences. First, the only person that can make a commitment for an individual is that individual. While some people have granted limited authority to make commitments for them — a crew leader has the authority granted by the members of the crew to make promises on behalf of the crew — no one has the authority on projects to determine for all what commitments they will fulfill. Second, commitments aren't decisions. To decide is to choose among alternatives. For instance, this is better for me than that. Now that we have decided, we must answer, "Who will do what by when?" That takes a commitment.

We have to define 'last responsible moment'. The problem (don't you like how that word just crops up?) is the 'last responsible moment' is an assessment. It's not a calculation. There's not a right answer. However, making the commitment late may lead to a breakdown. A late commitment implies a task that won't be completed in time. So we have a dilemma. We can't know we are responsible AND the consequences of being late is another breakdown. What do we do? With apologies to site superintendents everywhere, one thing I know not to do is make commitments at the first opportunity. Telling the crane rental company today that I'll take delivery in 5 months when the usual lead time for a crane is only 6 weeks would be foolhardy. Too much can happen on a jobsite during that time. (Supers never make that mistake.) But how about making commitments at the 'first responsible moment'? What would that entail? What does 'responsible' mean? If 'last' carries the risk of bringing about breakdowns, might there be a 'most responsible moment'?

I'll explore all that to describe an ongoing practice for navigating the promises to the clients. Here are some more of my questions:

• Can we create a protocol? What are the elements?
• What roles need to be played?
• How do we think about the frequency of the practice?

Any additions to the list?

Then we can go on to develop some thinking about being robust to the breakdowns that remain.

Next in series

It seems I'm writing about the same topic over and over. I sense there's a new way of saying something about projects, but it is just beyond my reach.

Greg Howell and I were discussing the various types of uncertainty on projects. There's always the uncertainty of the future. While we can take actions that shape our possibilities, the future is by nature uncertain and unknowable. It is this uncertainty we should stop fighting…embrace it.

On the opposite end is the uncertainty of whether an individual who has a task to perform will get the task done to the satisfaction of the customer and at the time expected. This variation we can do something about. Through engaging in serious commitment conversations the performer can reach agreement with the customer or project manager when the task will be completed. Completing as promised allows others to start their work as they plan to start it. In fact, a reliable promissor creates the situation for others to plan and mobilize for action rather than waiting to see what gets finished.

The two scenarios don't describe all the cases of uncertainty, but it is good enough to examine the kinds of actions we can take on projects. I can put those coping actions in the following four categories:

1. Reducing the likelihood of variation
2. Mitigating the consequences of uncertainty
3. Discovering conditions
4. Adjusting to the situation

(I think I am missing some categories.)

I'll go into more detail later. For now, consider what I am proposing and please help me with my thinking by offering either your comments to this post or send me email. Here's a metaphor for you to consider:

Sailboats (under sail) are rarely on course. Sailors set their sails to capture the most wind. They 'tack' at an angle to their course. This requires zigging and zagging rather than a dead-on course. I've heard that rockets are also somewhat off-course. The 'guidance system' makes very frequent minor adjustments returning the craft to course.

Previous in series Next in series

Consider this a starting point in a series of postings. At this moment I'm just rambling. I'll use following postings to develop my thinking.

My basic claim about the environment of projects has not changed. Projects are conducted in an uncertain and unknowable future. In addition, project participants learn, collaborate, innovate, and cope with each other and the circumstances as presented. These attributes are what make projects so exciting.

Project work has a progressive or cumulative nature to it. One thing builds on another. One person's work waits on the completion of other work. While some conditions for project tasks are made explicit, there is often plenty of room for alternative courses of action and variety of finished characteristics.

Projects are manifestations of the people who make up the project team. Team members bring their skills, talents, worries, prejudices, ambitions, distractions, moods, intentions, and on and on. This completely unpredictable medley also changes throughout the project. And it doesn't stop there. The friends and families of project team members influence the project circumstances in even less visible ways.

How could anyone, let alone I, say that variation is an enemy of project success? As I described the setting of projects the only thing that one can be confident about is variation and uncertainty. Our usual interpretation is variation = risk. Risk is to be removed.

In prior postings I urged people to reduce the variability in the linkages of one person's work to others' work by engaging in commitment conversations (requests and promises) that increase the reliability that work will start as re-planned. Notice the 're' in re-planned. I am placing an emphasis on an ongoing practice of planning among a broad group of project participants. Still the distinction is not quite right. Planning as action — as a particular kind of conversation — is understood to be separate from the actions of execution. And that is not what I mean. In the course of completing tasks there continues to be an opportunity for planning and adjusting.

So I sit here stuck. The essence of the situation of projects is the unforeseeable possibilities and challenges. So if project settings are foresee ably unforeseen, then let's start managing projects taking advantage of serendipity rather than forcing an outcome. How? Good question!

Next in series

So claims David Schmaltz in his book The Blind Men and the Elephant, Mastering Project Work. Those are words only a self-described heretic could utter. The key word is "thing". While we speak of projects as nouns, the experience of a project is much more like a verb.

I won't make this a book review. Instead, I'll just share a few moving passages. Perhaps that will get you to buy this book. Get extra copies to share with you boss and your project team mates.

He identifies six characteristics of project communities who become coherent:

1. They are composed of acknowledged blind men.
2. They share an indescribable elephant.
3. They also share (or have shared) a frustrating experience.
4. They show some patience in the face of their frustration — they stick with it.
5. They make generous interpretations of others' perspectives.
6. Some, although by no means all, also adopt a coherent organization structure; they circle up and focus upon a common point.

We could discuss each point as a posting. Instead, take a look at how he wraps this essay.

People create a common rhythm together, not unmanageable chaos. Project an alluring future, and people cohere. They might battle endlessly over differing theories about how to get there, like our blind men around their elephant, but it's there theologies that are in dispute, not their objectives. Their individual passion binds them to their commonality.

David Schmaltz goes on to claim that we know all we need to know to be good project team members. "We are each expert at being human." Let's bring that human-ness back to the center of our project work. Maybe then we will experience the thing…that wonder of projects.

Model Project Managers, Dr. O.P. Kharbanda writing for Gantthead.com. Dr Kharbanda points to Mahatma Ghandi, Henry Ford, and Benjamin Franklin as models of project managers. One thing that made all three models for project managers is their outlooks on life:

One step is enough for me! and The customer is king!
Mahatma Ghandi

Whether you think you can or think you can't — you are right, and The highest use of capital is not to make more money, but to make money do more for the betterment of life.
Henry Ford

Little strokes, fell great oaks, and Keep thy shop, and thy shop will keep thee.
Benjamin Franklin, source The Quotable Franklin

All three can be characterized having a lifelong perseverance accompanied by an everyday patience. Dr Kharbanda promises more references to these three great men in his upcoming series on project management.

Today I complete my comments of the paper The Theory of Project Management: Explanation of Novel Methods
by Lauri Koskela and Greg Howell. The authors are careful to use the phrase underlying theory to denote that project management theory is not explicit. The authors make their inferences of theory from the practices and behaviors of prescribed project management.

Making inferences is tricky business. We can never be sure that what we say is right or wrong. So, we make our case. Later, all we can do is assess the relative usefulness of the inferences when we set out to act in accordance with them.

K&H use the word obsolete as their summary characterization of the effectiveness of current theory in use.

Obsolete: Outmoded in design, style, or construction. Superseded.

To call underlying theory obsolete is only to say that there is indication that it falls short in producing what is desired and something better is available. K&H are out to uncover better theory.

The authors place high value on theory. Not higher than being effective in action…explicit theory provides the opportunity for examination, measurement, learning, innovation, and resulting effectiveness of action. Like many others, the authors have been dissatisfied with the results of projects conducted along the lines of traditional or conventional practice.

>Their investigation of theory took them to the PMI PMBoK® as the obvious repository of theory. Reading their first paper I see their disappointment in the absence of explicit theory in the PMBoK® for guiding practice.

I know the authors. They would like nothing more than to engage in serious inquiry with project management theorists. So I Googled 'project management theorist' to see what I'd find. Max Wideman came out at the top of the list. Coincidentally, K&H have recently engaged in conversations with Max. Perhaps we'll see Max write about those dialogs. Max too calls for a need for explicit theory in a series of papers on First Principles. Redo the Google search to investigate others.

The authors chose an unfortunate point to break their text to insert Table 2: The underlying theories and assumptions of project management. Without carefully reading one might be left with the impression the contents of the table are the intended evidence to support their claims. In fact, the authors only name their sources of evidence without offering it in this paper. Those sources are:

1. the plausibility and consistency of the theory in itself;
2. empirical validity;
3. competing theories; and
4. alternative methods based on competing theories

The authors never claim their inferences of theory and assumptions represent evidence.

Why write about all this? Some say it's just pickin' a fight. I say why not write about it? Projects routinely take too long, cost too much, and fail in often significant ways to satisfy the customer. Scrum is one response to that dissatisfaction. Lean project delivery using Last Planner® is another response. Both approaches are producing good results. So…what's the fuss? Let new theory emerge.

Lauri Koskela and Greg Howell (K&H) argue successfully that current theory is obsolete in their paper The Underlying Theory of Project Management is Obsolete. However the authors may be limited in producing a new theory by exactly the same background paradigm that makes current theory obsolete. K&H seemingly accept the machine metaphor as appropriate for projects. Machines can be perfected; machines can by optimized; machines persist in spite of changes to the environment.

The machine metaphor conceals the nature of a project.

In accepting the metaphor they make three mistakes.

1. They accept "project management is a special instance of production" discussing inadequacies of theory in the production terms of "flow" and "value generation".
2. They continue to see planning, execution, and control as separate processes as proposed in their Exhibit 2. Ingredients for a new theoretical foundation of project management.
3. Their "Discussion" (section) misses the presence of people and all that is entailed by having the everyday influence of learning, innovation, relationships, and complex ever-changing behaviors on a project.

The machine metaphor conceals the nature of a project. Current theory is activity-centric as are machines. The usual practices of optimizing machines is by understanding it by component..breaking it down into smaller and smaller elements. This is the same practice employed in producing project work break-down structures. We've learned enough about reducing the waste of the materiel processes. We need to put our attention on a more significant waste…the under-employment of people on projects. We need practices that are systems-oriented and people-centric to produce project organizations that can respond to and enable learning, innovation, relationships, and effective action.

Where can we look for guidance? I am encouraged by the work in other fields (not projects or production) on autonomic systems, complex adaptive systems, and biomimicry. I also see the relevance of living systems thinking (Margaret Wheatley, A Simpler Way and Turning to One Another), community (Derek M. Powazek, Design for Community), and sustainability (William McDonough and Michael Braungart, Cradle to Cradle). I doubt current operations theory will provide a unifying theory for projects. Instead, I suspect we will see a convergence of thinking that will lead to new theory.

Consider this my leaping off point. Where this will go who knows!

Previous in series Next in series

Lauri Koskela and Greg Howell (K&H) do a marvelous job of capturing the experience of projects on page 11 of The Underlying Theory of Project Management is Obsolete:

"The deficiencies of the theory of the project and of the theory of management reinforce each other and their detrimental effects propagate through the life cycle of a project. Typically, customer requirements are poorly investigated at the outset, and the process of requirement clarification and change leads disruption in the progress of the project. The actual progress starts to drift from the plan, the updating of which is too cumbersome to be done regularly. Without an up-to-date plan, the work authorization system transforms to an approach of informal management. Increasingly, tasks are commenced without all inputs and prerequisites at hand, leading to low efficiency or task interruption and increased variability downstream. Correspondingly, controlling by means of a performance baseline that is not based on the actual status becomes ineffective or simply counterproductive. All in all, systematic project management is transformed to a facade, behind which the job actually gets done, even if with reduced efficiency and lessened value to the customer."

The first step in reform is talking about theory. What is a project?

Most projects do eventually complete. We can thank project participants for their "in spite of it all" approach. We see project participants acting contrary to the stated practices and standards of the organization and in so doing they deal with the problems of the project.

K&H show us the problems are not:

• incompetent management (and we could use more competence)
• low productivity from unmotivated workers (and interest in improving would help)
• customers who can't or won't make up their minds (and knowledgeable customers are easier to work with)
• poor practices of project scheduling (and it's not a computer issue)
• poor practices maintaining schedules (and we could use more staying in touch with what is happening)
• risk management (does anyone know what I'm even talking about?)
• scope creep (and we certainly can help our customers better understand what they could be asking for)
• add your favorite reason here (or two or three)

The problem with projects is the insufficiency or obsolescence of the underlying theory. There's plenty of work for us all to do to reform project theory and practice. The first step in doing that is talking about theory. What better place to start than at the beginning…what is a project?

Let's bring down the facade and the misery and waste that go along with it. Thank you Lauri and thank you Greg for getting us talking.

Previous in series Next in series

In Koskela's and Howell's (K&H) paper The Underlying Theory of Project Management is Obsolete they describe thermostatic control is the principal espoused (or inferred) theory of control on projects. Examples:

Thermostatic control locks us into a naive plan…uninformed by the world that has unfolded.

• Cool above 72° and heat below 68°.
• Returning from the South Pole navigating between sets of markers.

Thermostatic control is based on some decision/choice of what is right, or best, and then invokes corrective action when conditions vary from that stated norm.

What's wrong with this theory? You just can't set it and forget it. Unlike temperature or path, there is no one correct path on the project. The path to completion shifts throughout the project. Sure, we have a good idea of what must be done to finish, but the sequence can change and some of the tasks will fall off while other required actions will be discovered. Thermostatic control at best locks us into a naive plan…uninformed by the world that has unfolded.

Execution and control combine as performers rely on their intuition and experience.

The good news is we find the theory-in-use doesn't conform to the espoused theory. In response to out-of-date plans and execution that fails to consider the readiness of performers, controlling activities function as negotiation between the directors and the performers. Referring to this breakdown of control, people disparage the team by saying they are out of control rather than acknowledging they are likely better off than operating to an obsolete plan.

Where is this headed? The six σ advocates might suggest we must identify the variables and bring them under control (as if we can). But perhaps the machine metaphor has served its useful life; project control is more like navigating a boat. The crew with their hands on the wheel and the lines rely on visceral signals — a fluttering in the sheet, tension in the line, a slight list to starboard — to make their adjustments. Execution and control combine as performers rely on their intuition and experience. The destination is reached even though the boat may never be on course.

Previous in series Next in series