That is, of course, only one context where this discussion might apply.

http://webseitz.fluxent.com/wiki/ExtremeProgramming

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.

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

… 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

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 !

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.