A few weeks ago I had a medical procedure, after which oddly stimulated some thought on the parallels between delivering an IT project and conducting a medical procedure. Everything was a success without any real complications, and I’m a little healthier now because of it: all great outcomes! But there was some unexpectedness or moments where the doctor had to adapt to new information discovered during the procedure – or perhaps, these were refined requirements in IT project speak. What were some of these characteristics of their process that seemed to set the doctor and her team up for success that often might be lacking in an IT project delivery? Let me share one with you about the shutdown point.
It turned out I had an infection brewing inside me just below my shoulder on my back, which probably explains why for much of this summer I had felt quite run down physically and my concentration didn’t feel as sharp as usual. Somehow one of my oil glands had got clogged, backed up, and this caused an infection to develop. It’s nothing too serious, I don’t think, but the doctor said she would have to cut in to drain and clean the infected area, and would go ahead and perform the procedure in a few minutes. What a treat: some nice surprise Saturday afternoon surgery!
After planning what she needed and freezing the area to prep, she made an incision. This was probably quite a routine process for her, so I was mostly focused on just waiting for her to finish. Here’s where the weird part happened: suddenly she reports to me that she isn’t finding the affected area and is going to close it back up and stop the procedure. Wait, what?
There I was lying there, with a couple inch cut in my back; I felt pretty committed to completing the task obviously, and she was committed until all of the sudden it was time to stop. Then I hear her say she found it, that she had cut a little deeper while she was deciding to halt the procedure and had found the infection; it was just deeper than she had expected. This really stuck out for me: she was ready to shut it all down and take a step back when she got a look under the skin and saw it may be bigger or deeper than she originally assessed. Stopping the procedure wouldn’t be a failure; in fact she said it like it was always an acceptable option that was perfectly okay or not at all unexpected.
Now in contrast, I’ve been on many IT projects, and these types of projects are hardly ever halted, no matter what the outlook for success looks like. There seems to be a stigma and unrealistic expectation that it’s not acceptable to halt an IT project, that doing so would mean there was a failure. Everyone from the project sponsor on down to the delivery team are conditioned with some dysfunctional commitment to seeing the project through, no matter what. I’ve been on several projects where I’ve sensed a disaster, yet even after raising a flag everyone still opts to stay the course. In September’s Harvard Business Review Magazine, there is an article that discusses exactly this, and they indicate that 67% of managers won’t shut down an IT project for their group, even when they know it is not likely to succeed.
It baffles me why I’ve known so many customers who decide to continue rather than halt a project, even when they know they have the wrong team or the project is heading way off course or the consultants they’ve hired seem to be coming up short. I wonder, is there a stigma that would make it feel like a failure if the project is simply shut down, so it is better to continue in hopes that somehow, magically, it will get back on track and recover? Or is the root cause that the procurement process is too difficult and adds too much overhead that projects tend to get defined by large generic contracts rather than contracting well to break it down into modules or distinct phases with a well-defined vision and clear expectations set?
Is it the existence of a contract itself that creates an environment of opposing sides to some degree that each have to remain mindful of protecting each of their own interests? Why would it be so easy and acceptable for a surgeon to end even a simple surgery before it achieves its original objective when things don’t turn out exactly as expected once they get a look below the skin, yet not so for an IT project? Perhaps contracts need a shutdown clause that defines the shutdown point up front before the project even initiates. I had the sense my doctor had a shutdown point in mind before she began the procedure, and this was why she was so prepared to stop and back out if something wasn’t as expected.
A healthy functional IT project considers a shutdown point before the project even kicks-off, and then checks in on that shutdown point regularly during status meetings to honestly assess how the project is trending in relation to when it should be halted. No more “Don’t ask; don’t tell” where there’s this unspoken commitment to continue no matter what, where the project blindly marches on to inadequacy and disappointment. Instead: regular checks against a perfectly acceptable shutdown point.
a) Glad you’re ok and it wasn’t something more serious;
b) Good question – and I think you’ve touched on some of the answers.
I think there is something to your observation that there is a high cost in time, money and getting people together for a project that makes customers want to “clean their plates”, even if the end-result will be much more detrimental. As you note, it’s counter-productive, demoralizing and of course wasteful.
This is why I (and many others) advocate breaking projects down into short timeboxes (iterations) that are linked, with each prior requiring successful completion before the next is “unlocked”. If ROI is no longer being met, we cancel the project and charge 25% of the remaining balance of the forecasted budget (if we’re using external contractors).
In this way we try to provide the customer with tools to determine if they’re getting value for dollar – however, if they are unable to gauge this, or worse, if they have to vet everything through a politicized committee, this process can quickly become ungainly and bottlenecked. In which case the project is DOA.
What I try to do is hold a mirror up to them so they can objectively evaluate their circumstances /before/ starting the project. Is it feasible? Do we have the right people with the right skills assembled for the team? Are they participating in the estimates that are informing the release plan? Are they getting an opportunity to lead or are we running an expensive daycare?
Ultimately, if the project is of the command-and-control variety and governed by a defined process, I already know it’s a dead man walking. I try to get as far away from those as I can…
“Unlocking” phases, I like that! Expensive daycare – super awesome! I might actually use that line… “I think this project is turning into an expensive daycare.”
Re: Expensive Daycare; Glad you like it – it stands to reason, but a lot of customers and rigid PMs don’t seem realize (until you tell them) that when you micromanage people against an absurdly long-range plan that treats them as hot-swappable components, you’re effectively reducing them to children. It’s one factor of several that set an IT project up for failure.
Re: Phases – a small point: These are iterations – phases suggest a single pass over common ground. With iterations, we may come back to a feature in the future to refine it – in fact, we almost always do.
Good luck – let me know if you need back-up!
Good one, Steve. I hope your recovery will be quick. I had a similar post about projects in my blog a couple of months back:
http://fyano.wordpress.com/2011/06/05/sands-of-time-projects/
I was checking out if you’ve had experience on SP2010 records management and document sets.