I went to a talk by Scott Berkum (ex-Microsoft employee) who recently wrote The Art of Project Management. The talk was entitled “What To Do When Things Go Wrong: Saving Design Train Wrecks” It was a bit of a trick because it wasn’t really focused on design train wrecks but was more focused on dealing with general project train wrecks (which I suppose you could apply to design).

It is amazing to me people can still write about Project Management given the massive body of knowledge that already exists. Yet despite all of this material people still find ways to talk about the same things in a different way. His way of describing the classic Time/Quality/Cost triangle was in the form of a train wreck. So when it is clear you are headed for a train wreck you have a couple of options:

1. Stop the train
2. Slow down the train and agree it will be late
3. Crash the train and learn from the crash
4. Crash the train and pretend it was what you meant to do

The last one he used to disparage managers who never accept responsibility.

While it was repetitive it was nice to walk through the basics with new analogies — same plot, different characters (good refresher). I liked his approach to risk management — simple and basic. A lot of the material I have read on risk management over complicates the process to the point of uselessness.

Scott was also a huge fan of detectors — things that you put in place to watch for problems. He is a big believer in identifying detectors and checking on them regularly. He also outlined his strategies to handling disaster based on the phase of the project (beginning, mid, and late). So for example some of his late stage coping strategies were to “pick a single battle to fight and make a stand” or “cut your losses.” I liked his no-nonsense approach to dealing with major issues:

1. Calm down
2. Evaluate (this will probably freak you out)
3. Calm down again
4. Get the right people in the room
5. Explore alternatives
6. Make the simplest plan
7. Execute
8. Debrief

I feel like the book would be a good read for project managers early in their development. Unlike many books it doesn’t get bogged down in theory but presents straight forward concepts that would be easy to follow.

My favorite part ended up being the fact that he mentioned Satir change models which I remember reading about a couple years ago. I came back home and reviewed the concept. I forgot how much I really liked the way Virginia Satir characterized change and how you have to be really careful that you don’t stop the change just because of some chaos.