Wednesday, January 26, 2011

of checklists and project management...

Michele picked up a copy of Atul Gawande's recent book (The Checklist Manifesto) on our flight back from Nevada. I read it cover to cover on the second haul from Dallas to Boston. Also spotted the 2011 superbowl stadium from the plane, although you could probably also see it from space, but I digress...

Anyway long story short, I'm not a big fan of project management.

There I said it.

I know it is not a popular thing to say.

However, I have managed a whole bunch of "large" projects in my time, and continue to do so. The problem is, I often worry about the management piece of project management. In technical fields we hire folks who are technical at some level, who we then ask to go on to manage our projects. Not a bad thing, but in my experience this has caused quite a few issues when the brown stuff starts to hit the fan.

This is because the folks we hire to manage the project forget about the project and start to focus on the management. They are all ex-engineers after all, that was why we hired them right? Well, it turns out that's when things go exceptionally pear-shaped.

We actually want, and require them to mange the overall project, and not the specific individual tasks. However, because of their interest in the field and that they are helpful friendly folks, tasks end up being assigned and developed and engineered/designed by the PMs as they start to act as pseudo domain experts - they really oughtn't. Honest please - just don't do it.

It is not good for anyone involved, it always ends badly, often very badly!

Atul states this beautifully in his book: "checklists can't fly planes!".

Atul goes on to define three types of challenging problems that crop up in any project:

(1). Simple problems (analogy: cooking from a recipe)
They require basic skill, are reproducible, and have a high likelihood of success.

(2). Complicated problems (analogy: sending rockets to the moon)
Can sometimes be broken down in to a series of (1), but with no straight forward recipe. Success depends on multiple people, domain experts and problems are frequent.

(3). Complex problems (analogy: raising children)
Performing a (2) for a second time does not mean the outcome of a (3) will be the same as a (2). The (3)s need different approaches because any (3) is totally unique to any (2) that came before it.

Here's the "Atul Problem Law" applied to research computing according to James Cuff:

(1) Building a data center, installing the racks, HVAC and physical computer and storage systems, pipes, plumbing, raised floors, roof, doors, clearance and plugging in all the 1000's of wires.

(2) Configuring the cluster, networks (high and low speed) HVAC systems, operating systems, schedulers, authentication systems and storage arrays, configuring out of band management systems, and plugging in even more and different exotic wires and dongles.

(3) Working with researchers, PI's postdocs and faculty to actually run code and produce meaningful science and research with the (1) and the (2).

Turns out (2) and (1) always need a solid check list (with a decent plan or project). But what about those (3)s?. My team spends most of their time in the world of (1, 2 and 3), but a whole lot more time in (3). (3) problems are fun, and lucky for me, are no where near as frightening as an adrenalectomy next to the vena cava, but my sentiment still holds. (1) and (2) are often considered as rather dull, but if you screw them up, you are done, no dice, no science, no nobel for you professor...

So back to my project management fear - as with Atul's great checklist for "pre-flight/pre-surgery" - over in HPC we can easily construct checklists for (1)s and (2)s. Problems I battle with as a manager worryingly fall in to what I call zeroth order problems. Zeroth order I consider as answering the phone, email or instant messages, physically turning up to work, being nice and respectful to our clients and vendors, knowing which way is up etc. etc. Those are not problems per se - or least they really ought not be. If they are you are really stuffed.

However, it is the (3)s that will always need domain experts, and ought in my opinion to be managed directly by the domain experts, and will always involve a certain amount of "winging it", ad-hoc design and actual on-the-fly research.

Anyway - go grab a copy it is a real page turner - you may very well end up with different take on what Atul is getting at than me, but my two pence stands. I also now slightly understand the difficulties of being a high quality project manager!

(*) Remember I was physically sat on a plane at the time of reading - when you get to read the book you will understand why I tightened my seat belt a few notches...

[any opinions here are all mine, and have absolutely nothing to do with my employer]
(c) 2011 James Cuff