Archive for the 'leadership' Category

When I asked for proposals for project e-Tips I never expected an author to send one along. David Schmaltz, author of The Blind Men and the Elephant, Mastering Project Work, urged me to address coherence. In all fairness to David, he provided the quotation: I provided the rest. Enjoy!

The Project Reformer's e-Tip of the Week

017: Produce Coherence Among Project Participants

Projects are uniquely human endeavors. As such, we have the likelihood that the interests of the team members will be in conflict with one another, at one time or another in the life of a project. Those differences can lead to significant breakdowns on your project. Webster defines coherence as "becoming united in principles, relationships, or interests." Project leaders are responsible for producing that coherence. Leadership in this blind-men-and-elephant world requires integrating disparate perspectives, not enforcing a dominant one. Our projects are poorly served by the belief, religiously defended, that leaders create meaning for their team, because they can at best only encourage some preconditions that might provoke an emerging coherence of shared meaning; acknowledging their own, personal blindness is the most prominent [precondition] among these. Producing coherence is an everyday action. The project is always on the verge on shifting to incoherence. Each person's perspective can shift on a day-to-day basis as s/he engages with family, friends, co-workers, and the world. Vigilance is required to bring disparate perspectives and interests together in a synthesis. And, that synthesis undoubtedly changes as the project and peoples' lives unfold. Quotation suggested by David A. Schmaltz, The Blind Men and the Elephant, Mastering Project Work. No book for him!

©2003 Hal Macomber | RPM | e-Tip Archive | PDF | Submit Tip

I still have one last autographed 'Blind Men' left. I'm negotiating for a few copies of another book. Any offers? In the meantime, make your proposals.

Let's start with my definition of a breakdown:

An interruption while in the midst of fulfilling ones commitment jeopardizing the completion of the commitment.

In the previous five postings I described three actions for preparing for breakdowns:

1. Make commitments at the last responsible moment by engaging in recurrent conversations exploring, "Is it time to act?"
2. Make our commitments with confidence that we have what we need to fulfill the promise.
3. Distribute accountability for the outcome of the project by
• Expand the group of people who can assess and declare breakdowns.
• Empower those people to take compensating action.

Those are the summary points. Here's my summary commentary:

The failure to take our own promising seriously is the principal source of breakdowns and therefore project delays, dissatisfactions, and budget busts.

Breakdowns are inevitable…in life. We've seen that as humans we must make commitments to just get through the day's events. We tell our children we'll meet them at the soccer field. We tell our spouse we'll deposit a check. We tell our mechanic we'll drop the car off before 5:00 PM. We promise throughout our day accumulating like charges on our credit card. At some moment we must make good on each commitment. Others are depending on us to do so.

Projects are exactly the same. We are continuously making and re-making or re-negotiating our commitments to complete some aspect of the project by a given time. We do this so others on the project can plan and perform their work. When anyone of us on a project fails to manage the commitments we make, or worse, when we fail to make commitments, then we bring about the situation for one breakdown after another. The failure to take our own promising seriously is the principal source of breakdowns and therefore project delays, dissatisfactions, and budget busts.

Designing our projects to be tolerant to breakdowns is simple. Deciding to take that action is another matter all together. I've laid out the steps. Now step up and make it happen.

Previous in series

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!

I just finished reading a new book The Trusted Leader by Robert Galford and Anne Seibold Drapeau. A few weeks ago I attended one of those networking breakfasts. You know the type…muffins, croissants, and bananas with OJ and bad coffee. This was the first breakfast of this type that I attended in over five years. I chose to attend to listen to the speaker, author Robert Galford. I got a free copy of his book. (Free that is, if you value the breakfast at $50.) Enough cynicism.

The session was quite good. Galford touched on the high points of the book, took questions, and did a fine job working the crowd. I left with the intention to read the book. The road trip with my son to Colorado offered the perfect opportunity.

First, take the trust test. It's free. I've had 2 doz people take the test and all are reporting they learned from it. Having said that, I expected more from the test. The authors could have done a better job with the descriptors.

The book offered numerous useful distinctions. One is a formula for trustworthiness:

Where:

T = trust

C = credibility

R = reliability

I = intimacy

S = self-orientation

Of course trust is not a formula. However, the authors have done a good job of showing the complex nature of trust. Try assessing your trustworthiness. Assign a value of 1-10 for each of the above variables where 1 is low and 10 is high. Make a note of where you are today. Then come back and do the rating again in a few months after you've given your attention to becoming more trustworthy.

Overall I think there are better books on trust. Robert Solomon's and Fernando Flores' Building Trust in Business, Politics, Relationships, and Life is my standard for comparing all other works. Against this standard, The Trusted Leader gets 4 out of 5 stars.

I love reading the columnists at Industry Week. I subscribe to the IW newsletters so not to miss them. This one just in: Continuous Improvement — Harness The Passion, by David Drickhamer.

Drickhamer wrote about what he discovered while looking at the service industry.

Insight: People care and they are frustrated.

How has manufacturing addressed this? According to Drickhamer, "as frequently happens," they change management.

(N)ew blood with a "passion for excellence," a keep-it-simple strategy, as well as a willingness to find and adopt best practices. The new managers recognized the obvious truth that someone somewhere in the manufacturing universe had already solved every problem that they would ever encounter, and that they in fact had a lot to learn.

I suggest we can't afford that approach, particularly our project managers. For the most part, companies already have the talent they need to do their projects successfully. It's the practices, measurements, and focus that must change. PMs can learn a new role and the few new skills to play that role. Then project team members will do as Drickhamer says they already know is needed from them:

(E)veryone in this organization shares an understanding that they need to improve every day if the company's going to be successful in its markets

We will break the pattern of inertia when PMs play the role of project leader.

p.s. Arrived safely in Colorado after just two days of driving. Got to Gary Indiana on Wed nite. Arrived in Greeley, Colorado late last nite. My son is now off to the mountains. Have a successful competitive season Mike!

I have a busy week or two coming up. I start the 2nd group in the Project Leader Studio on Tuesday. Greg Howell and I have created a leadership program for project managers. We did this in response to requests from our clients. We have been working with executives on leadership for quite some time. We kept hearing the same thing from them, something like…"Wish I knew this when I was running projects." Or, "Too bad you can't teach this to our project managers."

So eventually we got the message. We designed a program that acknowledges the circumstances of project managers. They are interrupted constantly. We do our work with them primarily over the phone. Really! Take a look at the Project Leader Studio program description.

There's a good chance we are delaying the start by one week to accommodate 5 people from one company. That creates an opportunity for others. We still have room for a few more people. If you write Greg Howell he will send you a link to a document describing why he and I are doing this program.

In the meantime, I'm taking a road trip with my oldest son. (Why not? It's been 5 months since the road trip with my youngest son.) He's headed to Steamboat Springs, CO for the winter. If you want to speak with me about our project leader development program, Greg will know how to reach me.

Thought you would enjoy You Can't Be Serious?! by William Knight.

The perfect situation is for the project to fail, for nobody to be able to pinpoint why and for you to be certain of a long-term position without changing projects too often or climbing the management hierarchy too quickly.

Knight offers his top ten list of how to bring a project to failure without getting the blame. This tongue-in-cheek advice is really a commentary on the trivialization of project management. Be careful…you just might find one of your tried and true antics practices portrayed.

BTW, if you've been wondering what I've been doing and why I haven't been writing,
then take a look at my latest project leader.halmacomber.com.

David Schmaltz and Amy Schwab happened to be in Chicago at the same time Greg Howell and I were there to conduct our Project Leader Studio™ Intensive. We had planned to join them for dinner, but President Bush decided to visit Chicago delaying David's and Amy's arrival at O'Hare. Greg and I had planned an evening bonus session for the program participants. Instead, we asked David and Amy if they would like to speak with our group.

You might remember David Schmaltz's name. He is the author of The Blind Men and the Elephant: Mastering Project Work. I wrote about the book in my postings For PMs Who Might Someday Have to Deal with Human Beings and then again There Can Be No Such Thing as a Project. David takes a provocative stance in his book. He claims a major source of problems on our projects is directly related to the quality of the conversations we have among project participants. Specifically, he calls on the leaders of projects to produce a convergence of interests among all participants throughout the duration of the project.

It was 8:00 PM when David and Amy joined the group, way too late for a lecture. Instead, they did one of their simulations. They call it Back to the Future. The simulation involved walking backwards on a mission to recover an object. The exercise was designed to interrupt our acceptance of planning as looking into the future. The simulation was a success and the conversation that continued late into the night was quite the bonus.

David and Amy do their own workshops on project management. Visit them at Project Community. And for the really curious (or brave) among you, spend some time with David's and Amy's Deep Thoughts.

Thank you David and thank you Amy for spending that time with us!

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 e