Where does it hurt?

When taking on a new Project That Sucks, the most important thing for me to do first is to find out, in a big-picture sense, what has gone wrong. Why It Sucks comes before Making It Not Suck.

Sometimes it really is as simple as needing another bright software developer. Other times, the client can throw people at the problem but the problem is really structural: it’s set up to fail, and they should consider just dropping it. And still other times there’s a team or management dynamic that could use a push in the right direction.Unsurprisingly, I often get a lot of pushback when the client just wants it all fixed, now. The defect list might be at a hundred items and growing, with exhausted developers patching like crazy; nobody at that point wants to be told (for example) that it’s not supposed to get done at all, or maybe they actually need fewer people. Call me crazy, I’ve seen it many times. But the client, or prospective client, is rather likely to reject the solution plan and maintain business as usual.

911 for software projects

So the direct approach isn’t always the right approach. If I ask, point-blank, “Why is this going so badly and how do you need help?” it’s sort of like a paramedic asking a patient “What bone did you break?” or “Do you have food poisoning?” If you’ve ever been there, you know a paramedic is more likely to ask one or more of these:

• Where does it hurt?
• Can you see this object?
• Can you feel this?
• Can you lift your hand over your head now?
• Do you feel a weight on your chest?

In short, paramedics ask for symptoms rather than a diagnosis. That makes sense: they’re the experts on cause and effect, while the patient is the expert on what the patient is experiencing.

Often the first question I ask is something like “Where does it hurt?”–sometimes even literally. A great variation is “How do you know this project sucks?” or “What made you decide to call me?” Or, similarly to lifting your hand over your head, “If I went directly to version control, could I build your project right now?” (That’s a classic.)

Don’t just do something! Stand there!

“Why is this project important to your business?” is frequently useful. If I get an unclear answer, or none at all, that’s why the project sucks. People don’t tend to finish things that they know are unimportant or counterproductive.

“How many people are required to make a decision?” is sort of my “John McCain” test. The answer isn’t as important as whether or not anyone knows the answer. Remember that big kerfuffle last August? I don’t think owning eight houses made McCain look bad. Not knowing he owned eight houses made him look really out of touch with ordinary people though. Likewise, if it takes a big committee to make a project decision, that’s one thing. But if you actually don’t know how decisions get made, or if the answer is really complicated? That’s bad.

So if you’re struggling with a Project That Sucks, and your urge is to add resources, don’t do that right away. First, check in with yourself, de-scope a little bit, hit a couple dozen golf balls, do some yoga if that works for you. After that ask yourself, or let me ask you, “Where does it hurt? Why does this project matter? What is holding it up?”

Then you’re a long way towards making it Not Suck.