Designing Breakdown-Tolerant Project Environments
September 19th, 2003 by HalArticle Series - Designing Breakdown-Tolerant Project Environments
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.
Related Posts
- Back to Designing Breakdown-Tolerant Project Environments I last wrote about Designing Breakdown-Tolerant Project Environments in a four-part series: [1] [2] [3] [4]. It's not c...
- Breakdown-Tolerance: Is it Time to Act? I left off looking at the question, "Do we make commitments at the last responsible moment or at the most responsible mo...
- From Breakdown to Breakthrough There is a community of lean construction leaders in Northern California who get together each month at a dinner meeti...
- Breakdown-Tolerance: Just the Right Number of Commitments In the first part of this series I explored the circumstances for breakdowns and the action to take to minimize the gene...
- No Commitment, No Breakdown, No Problem! Let's start with my definition of a breakdown: An interruption while in the midst of fulfilling ones commitment jeo...
September 19th, 2003 at 1:45 pm
By the way, I’ve expanded a bit on the above comments here.
September 19th, 2003 at 7:13 pm
Inspired by my own request, I outlined the different scales of activity on my ExtremeProgramming page, from Project to EngineeringTask.
That is, of course, only one context where this discussion might apply.
http://webseitz.fluxent.com/wiki/ExtremeProgramming
September 19th, 2003 at 9:14 pm
A well structured set of project phases that uses the principle of step-wise refinement will have quite a bit of delayed commitment built in.
For example, committing to the delivery of a new system before details about specific requirements are known is foolish. However, committing to the completion of the requirements definition phase is usually doable.
September 20th, 2003 at 2:52 pm
I just wake up Hal and just had a look at your last entry; thus could not resist to chip in, foggy mind or not (it’s my excuse if what I say afterwards does not make sense to you
).
Your stuff is simply getting brilliant. And getting Bill to link it to eXtreme programming stuff is just heading to the right direction–i.e to develop breakdown-tolerant projects can be done through applying two principles of Agile Management (or Lean):
a)get the client on board and
b)deliver functionalities not at the end of the project but along the way (timeboxing or incremental planning/delivery).
«Timeboxing» is just making one promise at a time and delivering it(or not delivering it) and then adjusting the target based on obtained results. But not meeting a promise along the way DOES NOT signify automatically that this «breakdown» is bad for the project, the trick being that a client on-board is a happier client.
To support this last argument, I refer you to an article by Scott Ambler, in the online «S/W Development Magazine», titled ‘Agility for Executives’ at http://www.sdmagazine.com/documents/s=8860/sdm0309h/sdm0309h.html .In the last part of this article, the author refers to hyperlinks to two graphs: the «familiar way» and the «new way» ; those explain the effect of having the customer closely involved (on board) on risk (possible breakdown) and quality (breakdown affects quality, OR SO WE BELIEVE). (note: if you have problems accessing those graphs, I made a mirror of them at http://www.qualiscope.ca/Familiar_vs_New_way.pdf .).
I discussed these graphs with a dozen of project managers from the Life Insurance industry (they sure do not like breakdowns, these folks)to whom I gave a seminar on project risk management last week. The highlight of this discussion was when it was concluded that Quality is really based on perception, not on fact or physical/tangible functionality only: you can have the best product in the world - so you think — but if you enraged/insulted/ignored/etc.. your client during its development, your product is a complete mess from which he gets no satisfaction, because he hates you and your project team. And how do we measure overall quality beside measuring customer satisfaction?
As you argue, short term promises (timeboxing) are a good way to control breakdown in a project as long as we «navigate» correctly those promises to the client through proper(frequent?) conversations. Scott Ambler’s graph on the «new way» says a lot about the protocol and frequencies to use. The protocol is to get the client onboard (on your project team) on a permanent basis to ensure he understands the promises you will and CAN make.The client has also to be close to your team to get you to clearly understand his needs/expectations and how these will evolve along the way, based on the promises you meet and those you do not meet because of uncontrolable events (the unknown unknowns). In projects under uncertainty (should cover all
September 20th, 2003 at 2:54 pm
(PART 2 - (I guess my comment is again too long)
… In projects under uncertainty (should cover all projects, don’t you think?), at least two promises do ALSO come from the client:
a)the promise to make his needs and THEIR EVOLUTION clear and
b)the promise to adapt his expectations to your ever-changing/unpredictible project environment.
To conclude, my proposal is that the protocol/best frequency to «navigate» promises (both ways: from you to your client and from your client to you)is to get the client directly involved on the project team, thus in CONTINUOUS conversations. This way, not only we are putting together a very breakdown-tolerant project environment (we won’t have conversation/communication breakdown, for one), we are even cancelling the effect of these breakdowns on the final quality delivered, because these don’t mattered that much for a knowledgeable client, involved in HIS project in an adaptive mode (looking forwards to «satificing» outcomes and managing by results, not by objectives). And, this is true for all types of projects.
Long life to short-term promises and long-term continuous conversations.
Cheers
September 20th, 2003 at 4:00 pm
I googled your last entry just to see. Could not find a link other than to your entry. So I fiddled around with the words and ended up reading an article titled �The 5 myths of project breakdown (and what you can do about it)� by Barry Flicker, the author of ‘Working at Warp Speed’ at http://tinyurl.com/c339m .
There is some traditional (familiar way) stuff in there but some agile (new way) stuff as weel. And the remedy to myth No 2 is converging with my last comments above (client inclusion); the remedy to No 3 is in line with some of the stuff you advocate (take the time for conversations).
Voila !
September 20th, 2003 at 5:51 pm
Well…
I so appreciate all the comments and interest in this current exploration. (I’ll share some of the background of the exploration in one of my coming posts.) My ambling from ‘good and bad variation’ to ‘breakdown-tolerance’ has been aided by your comments.
Bill wonders about my use of the terms promises and commitments, I am not reserving promises for customers and commitments elsewhere. I am going out of my way to distinguish the preeminece of the promises made to customers over other commitments on the project. Frank Patrick and the CCPM folks stress keeping these different commitments separate. I couldn’t agree more. And I’m trying to show why that is so.
Some might be wondering where I stand on CCPM. I see tremendous value. As Frank points out one similarity to my exploration after another, the agilistas and leanies will also be able to see how their approach also fits. While I didn’t start the exploration with this intention, I want to get to root issues. Here’s why: the vast majority of porjects are undertaken by fewer that 5 people. Those foks don’t need CCPM, Last Planner, or SCRUM. And they do need an orientation to their projects that will guide them in their success.