Lessons from Greg House, MD

Most people have probably seen an episode of House on Fox. The show is successful because the title character lets his id run wild. He says things that you would never expect to hear, let alone from a doctor. One of the things he frequently says is that patients can't be trusted because they always lie. As a result he sends his minions to break into their houses and search for the truth.

That's great for TV, but that couldn't happen in the real world. Yeah, that's what I thought too, until it happened to me.

Let me be clear, I'm not a doctor and I don't even play one on TV. Nobody is entering anyone's house to snoop around. And maybe lying is a little bit strong, but let's say that the truth was not as forthcoming.

Background, I have been managing a project, not big in terms of $$ but it is big in terms of impact. The objective of the project is to introduce a new correspondence management system. This is an interesting project because, from a technical perspective it is simple. But from a deployment perspective this is the most difficult project ever. Think about it, I am swimming against the tide, and the wind in my face and a boat trying to pull me the other direction. We have 30+ years in which people have been generating correspondence packages. You have your yellow (canary) copies, your blue copies, your white copies, your letter-head copies, the buck-slip, the blue folder, the red folder, the green folder the clear plastic thing, etc. I swear, an entire industry exists around the act of getting correspondence from one person to the next.

I hate to sound formulaic in my approach to the project, but it has served me well. I identified the stakeholders (s/h). In this case the s/h included a bunch of Administrative Assistants, Branch Chiefs, Division Directors, and the front office. We held a bunch of Requirements Gathering Sessions (RGS). We held a bunch of Design and QA Sessions (QAS). The developer built in iterations (3) and we tested after each build to apply course corrections. We held User Acceptance Testing and gathered feedback to prepare for the release of the product. We released the product and held the first big training session. At the end of the big office-wide training session one of the Administrative Assistants asked if I could host a hands-on session just for them.

I begin their hands-on session a few days later. It was going well but about two-thirds of the way through the business process there was a problem. The business process they described was different than the business process that was described during the RGS and QAS. It wasn't radically different, but clearly a couple of important benchmarks of the business process were not articulated. I can say that they were not articulated because I attended the RGS and QAS and I know that we had achieved consensus with a depiction of the business process and what the secretaries were saying was that their steps in the process were not represented in the final system.

I don't want to make it sound trivial, but once we had the newly enhanced understanding of the business process it is relatively easy to adjust the application to reflect those new benchmarks. But for me, the problem I am struggling with is; how could we have spent all that time on the business process and end up with a flawed understanding?

I think I know why, s/h lie. I'm just kidding. Nobody lied, but I was definitely not sensitive to the organizational dynamics that will still exist among the s/h. In retrospect, I should not have been surprised to learn that when the secretaries are mixed in with the Division Directors and the Branch Chiefs they nodded their heads and agreed to the vision of the process identified by management. It wasn't until there was a meeting that didn't include management that I got a more practical understanding of the business process.

My problem was that I saw all s/h as equal. Rank or grade doesn't matter to me, I just want to have an accurate understanding of the business process. However it did and does matter to them. They didn't chime in to correct their boss' understanding of the process during the RGS and QAS. That would be overstepping their boundaries and it's not their place (their reasoning, not mine).

So, no, all s/h aren't liars, but as a PM, you need to create an environment in which they can tell the truth. They want to tell the truth, but they don't want to look like they are going against their supervisors. I didn't create a safe environment for them this time, and I need to do a little re-work to correct it, but I'm more sensitive to this issue now.