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

Sorry everyone. I'm not feeling well. I'll get back to this tomorrow or the next day.

A few faithful readers have offered some rigorous ways for looking at good and bad variation and uncertainty. (Check out the reader comments from the last two days.) For now, I'm skipping the rigor. Here's the secret:

We avoid breakdowns when we don't make commitments.

No commitment…no interruption…no breakdown. While it's 'easy', it's not at all practical.

Funny thing happened on the way to blogging. I spent some unplanned time searching for the title to my car. I'm selling the car on Tuesday. I didn't plan to search for the title (yes I did find it). That time cut into the time I intended to spend writing. Was it a breakdown? It sure was. For two reasons. First, I need the title to sell the car. I committed to do the sale tomorrow. It would cost me $90 to sell the car without it. Second, I know many readers expect me to write. Not writing would disappoint.

Could I avoid the first commitment? Not if I wanted to sell the car. Agreeing to sell includes presenting the title. What about the second commitment? When I started writing about variation as an enabler of project success I was just thinking I'd explore a topic that I had been confused about. Many people showed interest. Without intending a commitment one resulted.

So, it's not so easy to go about ones work (life) without making commitments. Making commitments allows us to take care of our own concerns. Committing is arises in the course on living responsibly with our interests. Breakdowns therefore are inevitable. Other people and external events interrupt us while we in the midst of going about fulfilling our commitments.

Events happen. While we can shield ourselves (somewhat) from externalities we can't shield ourselves completely. Our challenge then is to act in ways that we can tolerate interruptions without producing big breakdowns. The other issue is people. This is about choice. Some might say that we get the people we get on our projects. Maybe. I say we get what we deserve. When we take care of the people on our projects, they take care of us. This goes as far as when interruptions do occur the team does what is necessary so it doesn't impact the major commitments of the project AND the other commitments that matter (those to family, friends, financial, etc.).

So we can't avoid breakdowns. We can design environments that are breakdown-tolerant.

This topic has struck a chord. On top of the comments listed on the previous post I've received a handful of emails directing me to materials and people who are interested in the same topic. Before I go on, I need to comment about one aspect that has come up in the comments from others.

There's good variation and bad variation. Serendipity is all about the good variation or uncertainty. Joe bumps into Frank who is doing work for Steve on a matter that Joe knows Claude has done some research. In no time Frank and Claude are speculating on different approaches to addressing Steve's needs. (Y'all follow that?) Good variation includes: discovery, learning, innovation, and making new connections. Any other suggestions?

The bad variation is principally about breakdowns. I'm using the word breakdown in a particular way. We call an event or incident a breakdown when we are interrupted in the midst of going about fulfilling our commitment. If there's no commitment, then there's no breakdown. Here's two examples:

I promised someone on a project that I'd have a task done by a given time. That person relying on my promise goes about making a promise to another person. That might include getting ready to start work anticipating that I will finish as promised. If I don't finish on time, the other person cannot get started as planned putting the second promise in jeopardy. This is a breakdown for the other person.

My son is a new driver. He has a new truck. We live about 1 mile from school. On the way to school he gets a flat tire. I forgot to add him to my AAA plan so he has to change the tire himself. He will be late for his first class. My son has been looking for the opportunity to change a tire. It's a gorgeous autumn day. His truck is in a very safe location. He has no breakdown. He isn't committed to being at school on time.

Variation that interrupts us in the process of carrying out our commitments is bad. Our commitment might be to do the project for a given budget. Some of the usual sources of breakdown are delay, misunderstood conditions for completion, operating to different standards, working carelessly or unsafely, getting sick, and being unprepared for the task at hand. Any other suggestions?

Next up: avoiding breakdowns.

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

For all you readers by email:
You have missed many postings due to malfunctions with Bloglet. I was hoping that the service would improve, but it remains a hobby business for its owner. I encourage you to visit Reforming Project Management every once-in-awhile to see what you've missed.

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

I'm going to do these e-Tips on a more random basis, or should I say continue to do them on the random basis. I was expecting more people (readers) to jump in. At this moment I have a ton of projects underway that need my attention.

Speaking of that…someone asked me how I go about my projects. I do them one-at-a-time. It's a critical chain project management thing. I learned that multi-tasking delays results. So I try not to multi-task. Here are two more tips based on my project habits:

1. I invite my network of support (friends, colleagues, web acquaintances, and clients) to make comments, assessments, and suggestions on my works in progress.
2. I maintain a list of up-coming projects and a parking garage for the thoughts, references, resources, etc that begin to surface as I get close to starting the project.

While I could go on, I really need to get back to work! Anyone interested in sharing their practices for doing personal projects?

I love it when readers take me on…Particularly regular readers. Frank Winters commented on my Sept 3 posting titled Never on the Rails. Frank sees me as a pessimist:

Hal - hate to say it but you sound like you might fall into the second cultural category - you don't believe (project) success is possible.

Please read the comments. However, Frank raises a great point. I've come to expect that most projects will fall short of their intended outcomes. (There, I said it.) Projects take too long; they cost too much; clients are dissatisfied along the way; and project participants can't wait to get on to something else. I'm not saying that this is the case for all projects. I'm not even saying that all four conditions apply to disappointing projects. What I'm saying is we need to do something different.

I got involved in the project world out of the love of the one-of-a-kind situation. I met great people. I was challenged in ways I didn't expect. I learned a ton. If only projects were routinely successful. Not always successful, but more often than not.

While Frank implied I am a pessimist, I'd be equally concerned being called an optimist. Let's be prudent. Let's start tapping the great storehouse of talent, wisdom, experience, and good will that we find on each of our teams. Maybe then we will routinely succeed.

Here's that link to Business 2.0's The Books That Matter. I can't tell if my subscriber cookie is letting me view the list or if it is generally available so I've captured the list for you without all the commentary.

You might be able to email the whole article to yourself. Try visiting http://www.business2.com/articles/email/1,1681,51906,00.html. If you still can't get the article, then you'll have to buy the magazine or subscribe. It's a bargain at $7.49 annually.

John Reh, management guide at about.com described management as The Music Paradigm in his blog. He was curious what I thought. Also see What is the Music Paradigm created by Roger Nierenberg, Music Director of the Stamford Symphony Orchestra in Fairfield County, Connecticut. I read the referenced work. Here's my reply:

Dear John,

Many people have used the music paradigm for management (and leadership). There's something about it that strikes me as being off. First, there are no conductors in business. Sure, there are strong managers who impose their intentions or will on the organization, but in a moment-to-moment basis no ONE person is conducting. The other thing has to do with the score. Orchestras play to a score. Some might say that is like a game plan. But all experienced managers know that the plan is good for the first play (sometimes), then it's all about improvisation.

Let me contrast that with what I'm noticing about consistently high-performing companies. Management attends to the systems and practices for coordinating action. They set standards and protocols for how people work one with the other, what is expected of each other when in commitment conversations, and how people will provide assessments about how business is doing. Systems, processes, and practices are managed, not people. The second issue has to do with planning. Planning is never a script or a score. Planning can take many forms. Good planning like sailing anticipates that people will never be 'on course', they will be making adjustments (tacking) to return to course. That takes two things: knowing what is intended and sharing the responsibility for assessing and acting to make the adjustments.

While the music paradigm is seductive, like all metaphors much more is hidden about the nature of that being described than is revealed.

Hal

No sooner had I sent the message to John than I remembered reading a paper on project management as improvisational jazz. After rereading the paper, I'm thinking project management is like performing music, just not like orchestral music.

The people at Project Jazz, LLC offer a different view in their article Playing the Live Jazz of Project Management, by Kim Wikström and Alf Rehn, Åbo Akademi University, Turku, Finland. I am offering the following quotes not to present their case, but to give you a flavor of their writing. My elaborations are in parenthesis.

(P)lanning projects is at best an act of guidance, as all aspects of the actual project work never can be completely mapped.

Standards (music) can be played straight up, but the best performances always consist of improvisation on a head (lead melody). To play a standard straight would be pointless because it is non-productive. The structure that the sheet music embodies is not even thought of as something to be followed, but as something to act with.

The historicity (embodiment of prior work) is constantly present even in the freest, most radical of pieces. This shows that the unconventional use of structure has not created fragmented or ignorant upshots, but rather freed these upshots to create better things from the same structure.

(T)hat ability to improvise should not be treated as non-conformity, but as a way to utilize what has earlier been best practice. We are quick to assume that knowledge and skills are technological concepts, where being able to use the given tools or methods in the best possible manner are seen as constitutive (central to its nature).

What is a recurring theme in this text is the observation that a performance is not born at the moment the first note is played, but neither is it wholly unplanned. The unalterable intermingling of planned action with instinctive reaction that occurs in both improvisational jazz and project work is an important starting point to map the nature of project management.

Greg Howell offered these comments:

Jazz is even more mutual adjustment (than orchestral music) and often internally both very competitive and cooperative. There is something about how the performance matters more than the piece ends. On a project we attend to the end and find little value in the actual performance.

Kim Wikström and Alf Rehn offer these parallels between improvisational jazz and project management in the order they say is important. I'll not comment on these individually. Collectively, the five 'linkages' express the essence of agile and lean approaches to project delivery.

1. Plans are enabling, not constricting.
2. Aberrations are normal.
3. You work with what happens.
4. Order is emergent, not pre-defined.
5. Disorder is not chaotic.

(W)e argue…projects also are an imperfect art. They are not similar to regular industry in the sense that they should be optimized and that there would be a perfect way to implement one. While one cannot disregard that set goals should be attained, one must also recognize that new goals are created during the project, and a good project can have unexpected results that fall outside the master plan entirely.

The management of projects also seems to be a less straight forward activity than is usually assumed in the literature on projects. This management is less a following of a plan, and more the handling of continuous action, some ordered, some not.

I hope I haven't taken away the thunder of the authors' paper. Do read it. They have made an important contribution to the conversation of project management.