I totally feel you. Most of my blogging, however infrequent, has been discussing books I have read.

I always enjoy these posts. In this one, I am a little worried about the problems listed for "agile" projects (and I agree that many projects suffer from similar problems). Specifically, the problems are all missing solutions. "they don't have X". Clearly the answer to these problems is to force them to have X. But what _do_ they have? Or maybe why are these missing solutions a problem for these projects?

Congratulations, Mike. I know you will enjoy it. Does this mean the blog moves over to Gartner, or will it stay here? p.s. Typepad wouldn't let me leave a not-signed-in comment.

Good stuff, Glen. One thing I often do with this discussion is to talk about how these uncertainties impact a project in execution. Depending on the structure of the project, the impacts are felt in different places...

Don Norman had an interesting comment along these lines in his latest book (Living with Complexity). His starting point is the real world: if I make a mistake in the physical world, there is often not a graceful failure. I push the wrong button and nothing happens, or I break things and learn not to do that again. He makes a connection back to design in general: incorrect actions should become more obvious, rather than trying to account for every possible mistake and coding around them. That said, your examples are more mistakes made on the backend (by the designer) than by the user. It shouldn't be the user's fault for using IE6 or an old computer that doesn't render your graphics beautifully.

Happy New Year! Keep up the good stuff. I think we've had versions of this conversation before, but there is more to the "Late starts" statement than is written. Is a "late finish" necessarily a bad thing? If you change the system, one could create situations where a "late finish" isn't necessarily a terrible thing.

I made it for about two months without a car in Austin back in 1992. Maybe you don't really need the cars that Texas tells you that you need. :-)

I don't know about the first one, but you have to do a simple search for ASCII art. Even a google on that term gives you some impressive items. Here are some cows: http://www.chris.com/ascii/index.php?art=animals/cows

I see what you mean. In the CCPM execution, the plan describes time estimates and any integration points (where non-linearities multiply) are protected by feeding buffers. When the reality of the project diverges from the plan, then you get buffer consumption / buffer recovery as a natural effect of striving to move the tasks along as quickly as possible.

Thanks. You've remembered that my take on the world is colored by TOC, and your blog has been helping my education beyond that. I think the other key difference with TOC planning / execution methodology is that "how much have you done" is somewhat unimportant to finishing the project. For that, you need to know how much more time is left. That's calculated from what's remaining on current work plus the existing estimates from the original plan.

Why not a simpler measure: how much more time is needed (as a percent of the original project duration) vs. the buffer consumption for the entire project.

The reason I asked "how they are used" to help run projects is that buffers are a key element of Critical Chain Project Management (coming out of the Theory of Constraints world). Buffers are located similar to the way you describe, and there are a number of sizing schemes. But it is the _use_ of these buffers that is most important: Essentially, when you consume the buffer faster than you are completing the project, it is an early warning that something is going awry and you need to do something about it. How are they used in DoD (and other areas where they are recommended)?

I have to admit this (the article on margin) is the first time I've seen the explicit recommendation to use margin / buffer in projects. This is an excellent way to help deal with natural variability of project work. Beyond the question of "how big" is that buffer, the key question is how is the buffer used to help manage the project - or the collection of projects in the portfolio. So, how do the buffers help manage the projects?

While creating a Must-Finish-On date is not helpful, why not ask for a "when would you like to be done" at the beginning. Then in the process of constructing and validating the network, you can see whether you have any hope of actually reaching that end date. If not, then you have to accept a later date - or revise your network. Also, do you really recommend ASAP on the tasks within the network, once the project has been released? Doesn't that have the danger of putting too much work into process? What if one chain of the network is two years, and another chain is only three months? (Of course ALAP is dangerous too - you don't want those integration points to slide.)

Clarke- It just leads (eventually) to an email subscription page. They don't need another copy of my email - does it actually get to Efrat's notes or not?

That's odd. Commenting seems to be working okay now. Maybe I clicked on a different button.

I like this. It connects to ideas I have learned from the Theory of Constraints community, where they talk about key questions to ask of "the shiny new gadget." * What is the power of "the gadget" (what does it give you)? * What problem does it purport to solve? What limitation in the current world does it resolve? Simple questions, even that second one is completely missed in many discussions. But these aren't the only questions, because the shiny new gadget will come into a business situation that has grown accustomed to the problem/limitation. So * What rules / policies exist due to that problem? * What new rules / policies need to be created now that the limitation is gone and the shiny new gadget is being used?

Happy Birthday, Clarke. 40 isn't so bad.

Yes, Twitter cannibalizes blogging. That's pretty well established. But as Laurent suggests above, that's because they maybe should have been there all along. Same for me. The problem that you are worried about is long-term memory of said tweets. That's a problem for everyone. There is no ONE place to collect everything I do online. For a time, the blog was close. But even that doesn't work in the face of Twitter, Facebook, commenting, Delicious (still use it from time to time)... I called this a "me collector" and I've heard other terms "self aggregator" etc.

Role models are role models, right? There are some models you don't want to imitate, of course.

Excellent, Clarke. I will be waiting to hear more stories, based on your new work.

I've had the TOC ICO certification for Suppply Chain management, but I haven't kept up my membership or the official certification. Thus far, my clients haven't questioned my qualifications or those of my clients. Ski - It's interesting that you don't see the the point of TOCICO, but then refuse to work with anyone who isn't a Jonah. Is that a contradiction, or am I missing something in your larger thinking?

Ross' photo appears to be private.