Breakdown-Tolerance: Just the Right Number of Commitments
September 22nd, 2003 by HalArticle Series - Designing Breakdown-Tolerant Project Environments
- Designing Breakdown-Tolerant Project Environments
- Breakdown-Tolerance: Is it Time to Act?
- Breakdown-Tolerance: Just the Right Number of Commitments
- Designing the Project Environment for Resilience to Remaining Breakdowns
- No Commitment, No Breakdown, No Problem!
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.
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...
- 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 to...
- 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 25th, 2003 at 1:26 pm
As someone ‘conditioned’ over years of product development projects, to try to make decisions (commitments) as early as possible so as to give form and direction to downstream activities, I feel some discomfort with the approach of delaying till ‘the last responsible moment’.
The two thoughts I have are:
1. Making a system more breakdown tolerant by delaying commitments kind of feels like abdicating responsibility. Almost like ‘if I keep all my options open then I can’t be proved wrong’. It seems to me that in some circumstances it is better to make a decision, albeit a wrong one, than to leave things open. For example, we could then find any potential breakdown sooner rather than later.
2. This leads me on to the thought of whether we can find some way of describing ‘conditional’ commitment. For example - option A is our preferred route pending X, Y or Z. If we later find that X, Y or Z are not satisfied, is the failure of Option A really a breakdown - or a tangible data point / boundary in our project?
Sorry, I don’t have any answers, just feelings and thoughts, but I like the way this thread is going.
September 26th, 2003 at 10:47 pm
1. The rule of thumb is not to delay. The rule is commit at the last responsible moment. There may not be an inconsistency with making decisions early. To decide I want things one way vs another informs the people on the project. But avoid acting early on the decision. Keep the options open to take advantage of learning and variability throughout the project.
2. Conditional commitments — I’ll do ‘this’ when I get ‘that’ from someone else — is part of the everyday world of projects. We may not have a breakdown if another doesn’t deliver for us. We certainly don’t have a commitment to deliver on if it was made conditionally. However, the project can be impacted by any one task that is not completed as promised.
When I promise X, many people on the project make plans based on me doing as I said, not just the person who has a direct dependency on fulfillment. For instance, I say at a project review meeting that I’ll have a specification complete for the project manager for Monday. Others hear me say that and plan their work anticipating they will access the spec on Tuesday morning. While I didn’t promise to the others, they can still have a breakdown when I don’t deliver. How? Because they committed based on hearing what I said I would do.
This whole subject is rich with possibilities for iomproving the way we do our projects. Thanks for joining in the fray.