Business Redefined

What can we learn from how doctors diagnose and treat their patients? Should analysts and project managers dump their business casual wardrobe in favor of scrubs and lab coats?

Forget that we’re talking technology for a few minutes. No matter what type of project you’re working on, whether it’s painting a house, fixing a car, or shipping the final build of your product, things will go wrong. For instance:

• When was the last time you dropped something in the bathroom? Where did it land?
• When was your last home improvement project? How far over budget did you go?
• When does your printer run out of ink? When you have time to get more, or right before a deadline?

The first question probably sold you. Chances are, it landed in the sink or the toilet – exactly where you didn’t want it to land. You could argue probability and say that you are usually hovering over one of those two drains, or you could concede to the more enjoyable reality that the world is against you and you have no choice but to deal with it. Either way you’re fishing something out of the toilet, so does it really matter?

Didn’t think so.

So congratulations. No matter how hard you try, you’re going to run into problems. This inevitability forces us to have a solid approach to resolving issues if we are to be effective in our various project roles. And when it comes to solving problems, there’s one guy you want in your corner: Dr. House.

For those of us who don’t know Dr. House, he’s a Vicodin-popping medical genius that stuns us every Tuesday night with his brilliant solutions to medical mysteries. The hour-long show begins with an ill patient whose symptoms defy run-of-the-mill diagnoses. The case is then assigned to House and his team of physicians who work through the intricacies of the problem in efforts to cure the patient.

On the surface, House seems ruthlessly opinionated, showing no respect towards the viewpoints of others. By watching a few episodes, you would label House as a maverick who sees no value in diverse ways of thinking and approaches to patient care. It’s his way or the highway.

Watch more, however, and you will learn that your perception is wrong. Instead, his powers of deductive reasoning and medical smarts position him to see things invisible to his staff and peers. Being that it’s TV, he can be that much better than everyone else. All of that said, make no mistake – he is still a supreme ass and takes every opportunity to rub his team’s face in their failed hypotheses and treatments.

Jerk or not, you want House on your project – especially when you run into problems. Let’s take a look at how House would approach a sick project:

Take the History and Examine the Situation

David Shore, the show’s creator, has said that House’s character is based upon Sherlock Holmes. They are both the top guns in their field, have limited social circles, require canes, and make use of every tidbit of information to solve a case. When presented with a patient, House’s magic begins with his ability to see every piece of the problem. For instance, take the following diagnosis House makes after just observing the patient for a few minutes:

Dr. House: You think it’s going to come out on its own? Are we talking bigger than a breadbasket? ‘Cause actually, it will come out on its own, which for small stuff is no problem: it’s wrapped up in a nice soft package and plop. Big stuff? You’re gonna rip something, which, speaking medically, is when the fun stops.

Young Man: How did you…

Dr. House: We’ve been here for half an hour and you haven’t sat down; that tells me its location. You haven’t told me what it is; that tells me it’s humiliating. You have a little birdie carved under your arm that tells me you have a high tolerance for humiliation, so I figure it’s not hemorrhoids. I’ve been a doctor twenty years, you’re not going to surprise me.

Young Man: It’s an MP3 player.

Dr. House: Is it… is it because of the size, the shape, or is it the pounding bass line?

House can see things going on with your project team that you cannot. And it’s not by getting people to admit what the real story is – he hates mining diagnoses from patients. For one reason, he helps himself stay sane by removing the human element from his work. More importantly, however, he knows that everyone lies. If he were to follow the practices of a traditional physician and interview the patient, he would have a potentially false, or at least skewed, representation of the situation. Instead, he relies on an understanding of the symptoms and how they are interrelated. We must do the same with the projects we manage.

Remember, House does not make use of traditional tools. He’s going to laugh at you as you fine-tune your gantt chart. He’ll mock you as you try to escalate risks and issues to your management. He might even trip you with his cane if he notices you making decisions based upon the wrong information.

House’s secret to getting at the facts is digging under the surface. For example, let’s look at a problem that has probably plagued everyone at some point in time: quality. The official project management certified, supremo MBA, diplomatically sound response to quality problems is that our people must not understand what the quality standard is. We must slow down the project and communicate our quality standards to the group. Once everyone is back on the same page, we’ll ramp up the schedule and try to make our dates.

Let’s assume you did just that. You should be proud of yourself. House could have never solved this one as quickly and efficiently as you did. In a very short time, you evaluated the situation, made a diagnosis, and set a course of treatment. You’ll sit back, happy that your acute decision making skills have trumped Dr. House’s medical nonsense – until you get the call that your diagnosis was flawed and your project is dead.

Thankfully the call wasn’t real – it was a prank from House himself. He’s toying with us to prove a point. We didn’t get under the surface. We didn’t evaluate the problem in terms of its underlying symptoms. We judged the situation based on the problem – not on its underlying symptoms:

Now we have a much deeper understanding of the symptoms behind the problem. House’s observations have identified several items of concern, some of which may not be cured with slowing down the project and communicating quality standards. In fact, as in medicine, such wrong treatment may actually worsen the project’s vitals.

So what’s the next step?

Make the Diagnosis

We have come to the conclusion with the above example that seemingly simple problems can have a host of underlying symptoms that add complexity to the diagnosis. Our planned course of treatment to the quality problem was to educate the project team on quality standards. How many of the symptoms can be explained by lack of defined and understood quality standards?

When put this way, our original diagnosis of unclear quality standards isn’t too impressive – it only explains half of the symptoms. This exercise also helps us refine the symptoms. For instance, we understand from House’s observations that the alpha builds do not meet the customer’s expectations. We need more details on this item to figure out what is wrong. Is it that the business intent is being met but the functionality is buggy? Or are we delivering different functionality than what was originally requested?

This is when a diagnostician goes to work with batteries of tests, including imaging, biopsies, and blood tests. Projects aren’t as easy to poke and prod for answers. We don’t have the luxury of controlled experiments. The answers have to come from people. This is when we bring trusted project participants into the diagnosis process. The group need not be huge – take a thin slice of the project team, making sure all roles affected by the problem are represented. Then challenge the group to make sense of the observed symptoms.

Dr. House makes use of the Socratic Method when guiding his team through the diagnosis process. He challenges his team with deeper questions, forcing them to think through their responses. He begins with guiding his team down each of the symptoms individually, dissecting them, understanding them. He then works to tie the symptoms together in efforts of reaching a diagnosis.

The process ends with a differential diagnosis. You will hear House ask for the differential diagnosis often, usually followed by the symptoms. The process of building a differential is as follows:

1. List the symptoms
2. List the diseases that include the symptoms
3. Prioritize the list of diseases based upon probability
4. Test for symptoms not yet presented, but should be present, based upon each disease
5. Confirm the diagnosis

For common diagnoses, physicians use decision trees to reach a definitive diagnosis. For example, at right is the differential diagnosis process for determining what type of lung disease a patient has. In a project context, the work is very much similar to building a differential for a medical ailment. The difficulty comes in with the fact that our industry has not documented symptom-to-disease relationships as vigorously as the medical profession has (and understandably so). We have no standard “diseases” we can use to diagnose projects. That said, it doesn’t take much common sense to know what to look for.Let’s go back to our quality problem. We’ve rounded up some really smart people who helped us come up with some possible conclusions to the problem. They’ve analyzed the symptoms, came up with possible root causes, and grouped them. In the medical world, these root causes (shown below in blue) would be the underlying condition or disease.

It looks as if the team has reached the conclusion that the specs are wrong, which is in turn causing a reduced quality in our software development effort. We’ve done a good job narrowing down the list of possible conditions to a manageable few based upon apparent symptoms. But our work towards a diagnosis is not yet complete. Remember, small screw-ups at this stage can lead to big problems. Imagine if we misdiagnosed our project, claiming that the project’s specifications were flawed from the beginning. What if the real problem was that our development team is just stupid? If this was the case, we just made the problem worse by guessing at a diagnosis and then botching the treatment.

To offset the risk of a wrong diagnosis, we must do further studying of each possible condition. Think of a common medical ailment. At any given point in time, all of the condition’s symptoms may not be present. New symptoms may present as old symptoms disappear with the worsening of the situation. This is why we have to brainstorm other symptoms we could look for to validate our diagnosis is accurate:

Now we are armed to objectively evaluate the situation and come to a diagnosis we feel comfortable about. Let’s review the steps we have done so far:

1. Identified the impact of the project’s illness (poor quality deliverables)
2. Identified symptoms by observation and analysis – not asking what the problem is and how it can be fixed
3. Solicited the help of trusted partners to map the observed symptoms to potential root causes
4. Identified additional symptoms for each potential root cause based on past experience, not current observations

From here, our next and final step in the diagnosis process is to use the additional symptoms to confirm our original diagnosis of inaccurate specifications leading to poor quality software deliverables. Remember, not all symptoms have to be present for a solid diagnosis. Perhaps you work in an organization where developers are above blaming analysts when they receive inaccurate specifications. Remember, while it’s similar, this isn’t medicine. Diagnoses matching the observed conditions, plus a handful of potential symptoms, is usually enough to confidently move to the treatment phase.

But what if you can’t select a diagnosis because symptoms are spread across two or more possible root causes? There are only two answers:

1. You and the team have to go back to the drawing board and refine your list of root causes, this time being more granular and specific.
2. You are dealing with multiple project problems.

Work to isolate the problems, positioning you to treat them independently. Make special note of shared symptoms – these will be important when we look to measure the progress of treatment.

Treat the Condition, Not its Symptoms

Always a hot topic between House and his staff is if a particular ailment is a symptom or the root cause of the patient’s troubles. For example, many times the show’s hotshot group of doctors come up with a seemingly brilliant diagnosis. All of the symptoms fit – it is the slam dunk differential. Pause for a commercial break, however, and we find that the patient has presented with new symptoms – ones that no longer fit the original diagnosis. Three things are possible:

1. The original diagnosis is plain wrong.
2. The original diagnosis is right, but the condition is actually a symptom of a deeper rooted cause.
3. The original diagnosis is right and there is another, unrelated problem affecting the patient’s health.

If we are to truly get the project back on track, we need to make sure we’re spending time on identifying and fixing root causes and not just symptoms. Physicians know that the wrong treatment could reek havoc on the patient’s stability – projects are no different. Symptom-oriented treatment, not taking into account the root cause, can miss the bigger picture and actually make things worse.

The work we have done towards the diagnosis positions us to treat the root cause. When identifying an approach towards correcting the situation, take into account both the observed and brainstormed symptoms. Your treatment should include an integrated approach to resolving each of the symptoms. Additionally, you may be able to identify relationships between the symptoms themselves. For instance, the symptom of frustration is usually directly tied to the onset of another, usually more severe symptom (we’ll call this ‘Symptom A’). By tracing back the relationships between the symptoms, the required corrective action will be more evident.

Treat the condition based upon the catalyst conditions – but remain cognizant of the triggered symptoms. In our example above, our treatment would be focused on Symptom A, however, we must be aware that our team is in a state of frustration. Knowing this positions us to better package our treatment in a way that will be accepted by the group. If we were to ignore their frustrations and not sympathize with their current situation, our treatment may be less effective.

Treatment must take into account all symptoms. Reiterating the above, your course of action must be tied back to your project’s symptoms. We worked on two lists of symptoms: those that we observed and those that we developed on our own based on knowledge of the situation and historical events. Make sure your course of action addresses each one, even if the symptom has not shown its ugly face.

Measure Progress and Make Adjustments

Project management is about baselining expectations, measuring progress against those expectations, and making adjustments when things are going wrong. Once you begin rolling out your treatment plan, only three things can happen:

1. Things can get better.
2. Things can get worse.
3. Things can stay the same.

The above list is prioritized from my perspective of good to bad. If the situation is getting better, you have a clear answer that your treatment is working. Conversely, things getting worse is a solid indication that either the treatment or original diagnosis is flawed. However, what do you do when things stay the same?

Physicians have the same problem, and Dr. House is no different. Many times, he and his team will experiment with treatments solely to rule out certain conditions. There have been episodes where the plan is to treat the patient and hope that they get worse from it, helping them to confirm their diagnosis. Try not to do this with your project team, but the point is clearly illustrated: if your treatment doesn’t work the first time, know when to stop and shift gears.

Conclusion

Medicine is as much science as it is art. Our work is no different. When dealing with complicated project problems, we must make sure to understand as much of the current situation as possible before prescribing a course of action. Sometimes this is difficult, especially when dealing with project teams that would rather base corrective action on gut instinct or initial observations rather than invest the time and energy into analysis. And the reasons for such an atmosphere could make problem solving even harder, for sometimes, the group doesn’t want to address the root cause of the situation – because it’s too painful.

Our mentor Dr. House deals with these issues everyday. His colleagues question his judgement, usually frustrated that he’s seemingly never wrong. His boss becomes nervous when hearing that radical, risky treatment options are the only way to a happy, healthy outcome. Even House’s own patients sometimes don’t value his work. After all, they’ve done their homework on WebMD and know exactly what the issue and solution is, right?

So next time you’re between a rock and a hard place, close your eyes, and call House for a consult. Here is what you will hear, most likely in a very derogatory fashion:

1. Trust your observations and not what people say. Everyone lies
2. When you do talk to people, figure out why they’re saying what they’re saying. What are they covering up? What is their motive for doing so? How does it relate to the problem you’ve observed?
3. Get a group of really smart people – people even smarter than yourself – to help you work with the diagnosis. Spend time on this. Get it right the first time. Don’t make things worse by guessing.
4. Treat the root causes, always being aware of the underlying symptoms. Your goal is to fix the problem, not resolve a few issues here and there.
5. Know when to back off on your treatment and change approaches. You’d rather have people upset with you for changing tactics versus a toe tag on your project.

Technorati Tags: conflict resolution, diagnosis, differential diagnosis, dr. house, medicine, metrics, murphy’s law, occam’s razor, problem solving, project management, project manager, risk management, symptoms