 Reforming Project Management |
||
|
|
||
|
Saturday, September 20, 2003
Unsettled About Variation
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:
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. Friday, September 19, 2003
Designing Breakdown-Tolerant Project Environments [1]
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.) 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.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:
Then we can go on to develop some thinking about being robust to the breakdowns that remain. Tuesday, September 16, 2003
Under the weather
Sorry everyone. I'm not feeling well. I'll get back to this tomorrow or the next day.
Monday, September 15, 2003
Avoiding Breakdowns
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. Sunday, September 14, 2003
Good and Bad Variation
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. Visit the Archives for more postings |
 Reference Papers
|
|
| ||
