If Disney Ran Your Hospital: 9 1/2 Things you Would Do Differently (Fred Lee, 2004, Second River Healthcare) is not even an IT book. As the title suggests, it is about hospital administration. But no book has influenced my thinking about project management more than this book. I will probably write several few posts about this topic but I will discuss the biggest idea here today.
In the interest of full disclosure, this is my translation of the book into IT terms. I make no claims that the author would endorse or even agree with my interpretation.
“You can’t have more than one primary goal.”
If you try to guess the number one core value of a Disney park, most people will say something like “the happiest place on earth” (their marketing slogan) or “extract as much money as possible from each person” (the cynical approach). Few people will guess that the true number one core value is “safety”. Of course, if you think about it, it makes perfect sense. If a kid is about to get run over by the Matterhorn Bobsleds, you can shove over an old lady to jump on the tracks and save the kid. Nothing else matters at that moment.
The author makes the point that you can’t have lots of objectives in your head and have a coherent strategy at the same time. He ridicules hospital administration strategies with multiple competing strategies such as “revenue”, “quality patient care”, “minimizing legal liability”, “staff satisfaction”, etc..
This got me thinking. What is Dulcian’s core value? What are we really about? Historically, I know the answer to this question. Our core value was “to build great software and build systems that were exactly what the customer wanted/needed.”
However, SHOULD this be our core value? All this time, I think that I was wrong. Building great software was not the right core value. See if you can guess the right core value for a project-centric software consulting firm.
What got me thinking was something that we had done almost accidentally which provided much more positive feedback than any software we ever built. The best example involved our handling of some users encountering a failed web service being called by our application. Users would try to call the web service, but the service provider would be down. The users would try again every few minutes. We eventually put up a message that the service was down and that we would notify them when the service was back up. They still kept hitting the button to call the service every few minutes. Nothing we did stopped the users from hitting the button. We could have disabled the button, but that would have really made the users very unhappy.
The technical staff (including me) received emails every time there was a failed call to the service. (We really wanted to know when it was down) Therefore, looking at my email in the evening, I could easily see that some user was hitting the button over and over again. (I could imagine their frustration just by looking at the email). We placed all of the user’s contact information in the email so we could talk to users if needed about why the service was failing. So, I just picked up the phone and called the user. I told them that the web service was down and that there was nothing I could do about it until the morning. The user was very pleased and surprised that they got a call from the development staff at 10PM just because they had been unable to get through to a web service. We smiled about it as we imagined a user working with an application and then getting a phone call out of the blue to help them with their problem. This seemed to be a cool thing to do for the users and it cost us next to nothing. Therefore, we made it a policy that if we saw someone repeatedly trying to access a down service, we would telephone them.
You have no idea how much impact this little policy had. At a conference where all of the application users were gathered, these phone calls were probably discussed more than any aspect of the software itself.
As a result of this experience, we developed a new core vision: “Make our customers happy.” We are not a software company; we are a service company. We do whatever it takes to make our customers happy. This shift in thinking allowed us to see mistakes that we made in the past which may have resulted in the software being built cheaper, faster, and better, but made the client less happy.
Hi Paul,
I have read this book a long time ago – but personally I failed to see the hidden project management wisdom within. Thanks for revealing them….
PS: If you have several goals on your project, then either the plan wasn’t correct or you are managing a program, not a project.