Saturday, October 22, 2005

Scott Berkun on Train Wrecks

A week or so ago, I went with a couple colleagues to hear Scott Berkun talk on software project train wrecks. It was entertaining, albeit rather painful, for people who have been victims or occasionally contributors to such disasters.

Like any UI guy worth his paycheck, Scott notes that the crux of the software design matter is often team management and project management. I find it not the least surprising that he and Joel Spolsky, also noted for his UI and design observations, are both so sensible on the topic of project management. Scott's new book, The Art of Project Management, is getting raves on Amazon, and I'm cheering as I read it. (I'm not sure you'll recognize the insights for what they're worth if you haven't lived through the kinds of process issues he describes, but I find him right on.)

Scott's slides are here. His diagnostics for train wreck projects are these:

  • We know we won’t meet goals
  • No one is happy / Everyone is frustrated
  • Things keep changing, but there is little progress
  • We don’t know if we’ll be able to solve them
  • We don’t agree on the existence of problems
  • We don’t know whose job it is to solve them
Sound familiar? For some people, this might describe entire companies! He has more specific criteria for design disasters, which may be even more familiar, since design is so hard to do well (depending as it does on more factors than simple project management):
  • Disconnect between the “design” and what’s being built
  • No one knows what the “design” is
  • No one knows what the goals are
  • There are competing designs being built simultaneously, and unintentionally, by different people
  • The design has no possibility of satisfying goals: Customer / Technology / Business;
  • Note: People with different goals will define disasters differently.
And finally, he hit my favorite subject, good teamwork. Good teams:
  • Avoid many problems and rat holes
  • Are good at recognizing/communicating issues
  • Are good at using each other to help solve its problems
  • Teach each other how to find and resolve problems
  • Make mistakes, but are encouraged to learn (not hide)
  • NOTE: One team’s train wreck is another team’s good day.
I was surprised not to find my favorite study of effective teamwork (Teamwork: What Must Go Right, What Can Go Wrong) in his bibliography.

Update: Here's another good review of Scott's book.

No comments :