Real collaboration happens when we agree to move money across borders.
Tuesday opened with a fun, story-filled keynote from Gregory Howell of the Lean Construction Institute. I think most of the audience could have listened to him for another hour.
He started out with an interesting claim: that standard project management creates a "commitment free zone." That got my attention. His claim is that the way we organize and plan for projects removes all responsibility for completing the project from the people doing the work within the project - people only agree to their piece of the work, rather than committing to do whatever it takes to complete the project. In this model the project is a web of tasks. The alternative is to come together and figure out what we should do, can do, and will do. The project becomes a network of commitments. This is a very interesting idea for me and has many connections to my work in project management. Requires a good think.
The money quote from this discussion was, "Real collaboration happens when we agree to move money across boundaries." This is in the context of transferring budgeted money from one bucket to another - a huge source of pain and pride in many organizations.
He gave an interesting train of a discussion along these lines:
Greg (to Jane): Can that three-week task get done any faster?
Jane: No, it's impossible.
Greg: Are you sure there is no padding in that estimate?
Jane: No, I never pad my estimates.
Greg (trying another tack): Oh okay then. Is there anything that John could do to help you complete your task faster?
Jane: Oh, absolutely. He could do X and Y, and the task would be done in half the time.
Greg: Great.
Jane: umm.
Greg: Go ask him!
John: Oh, right.
Later...
Greg (to Jane): It's great that we've gotten this commitment from John.
Jane: Yes.
So, what are you going to do differently in handing your work off to Dave?
Jane: Oh, the same as always.
[insert uncomfortable laughter here] It continues.
Many of the talks at LSSC referenced learning loops, and Howell's included something along these lines too. He talked about a loop that looks like Observe -> Actions -> Results. Looping back from results to new actions is one learning loop. And looping back to observations creates a bigger learning loop: what am I seeing? What is the model in which I am framing my actions?
A perfect example of this is the iteration loop. That's the whole point of these learning loops, particularly in the context of this conference. Howell gave some examples from construction where they were able to achieve collaboration and then began iterating on how they did the work. They progressively shortened the time to delivery, changed how they organized the work, and improved the bottom line for everyone.
Another loop that Howell used is from Hal Macomber, called The "Physics" of Coordination which is a large loop of Request-Promise cycles. A request is made and negotiation entered to achieve some kind of commitment. From there the work is done and we declare "complete." But it isn't really done until the customer agrees and declares their satisfaction. It It is embedded in the Macomber / Howell slideshare presentation Five Big Ideas Reshaping Project Delivery (slide 12).
Howell had an interesting discussion of contingency - the extra time that gets put into project tasks and into the project overall to protect from variation and other problems. There are at least two kinds. One is pure waste and is described in the dialog above. Padding added uniformly to all tasks that ends up creating impossible-to-achieve projects from the traditional view. It also generates the behavior of management assuming you have padded your numbers and arbitrarily cutting when the schedules and budgets come to them. This type of contingency is pure waste, and the discussion around commitment and collaboration strives to remove it.
The other type of contingency is needed to protect the overall project and should be managed in a much more strategic way. Howell argues that contingency needs to be strategically allocated to places where it matters most. In his examples, there are times where it is okay for idle time if it protects the overall project. In Critical Chain Project Management, that is the buffer at the end of the project and feeding buffers on feeding branches and use that to manage unknown variability throughout the course of the project. Howell suggests that is sometimes more helpful to explicitly put the contingency where it is most expected to be needed.
Howell's talk also started a day of reference to other written material that I will want to track down and peruse. The collaboration idea is one of Five Big Ideas Reshaping Project Delivery (slideshare) that he wrote with Hal Macomber. I suspect a bunch of the ideas about commitment are in an article he wrote with Lauri Koskela 10 years ago for the Project Management Institute entitled, The underlying theory of project management is obsolete (pdf). Howell also mentioned that there is some interesting data and ideas in Power to the Edge: Command and Control in the Information Age by Hayes and Alberts - and it's currently available for free on Kindle.