Solving the right problem

For several years now, I’ve been describing my business as “Making Your Software Project Not Suck.” Here’s where that catchphrase came from, and how I actually go about doing that.

Where it came from

Maybe twelve years ago… yeah, okay, that would have been in the lull after the post-Y2K slowdown and just before 9/11… I was pretty much in between major projects. As was almost everyone else.

It was time to Work on Marketing! Which if you’re smart, is something you do all the time, but in some ways I’m just not that smart. Or more to the point, I do know what I have to do but there are always competing priorities that appear to be more urgent. You know how it goes. Fire-fighting often trumps planning.

Anyway, I was up for doing some really serious marketing leading to sales leading to actual development projects. Leading to money. The one I was currently contracted on had been going pretty slowly simply because the project manager had died (!) somewhat suddenly. And he was the only one who knew the old system we were trying to replace. There was a lot of spare (unbillable) time in my typical day.

Well, first thing you do in marketing, as I later learned specifically from Mark Silver, is to think through your “who, who, what”:

1. Whom do you work with in demographic terms? (i.e., how would an outside person label your ideal client?)
2. Whom do you work with in psychographic terms? (i.e., how would they describe their state and situation?)
3. What do you do for them?

Now at that time, in the summer of 2001, I was mainly considering that first question: what kind of people, in business terms, need the kind of thing that I do? And naturally, I thought in terms of business categories as opposed to actual people, because most of my major clients had been big organizations.

“Well, that’s easy to answer,” I thought, “financial firms are where it’s at.” This wasn’t crazy at the time. The cooling off project was for a boutique brokerage just around the corner from Wall Street, and overall it had been going really well. The client was happy with my work, albeit understandably concerned about losing the architect. We were doing some cool stuff, and I was learning some, and the checks were good. And I’d done somewhat similar projects with great success for banks and other financial institutions.

So yes. Let’s focus on financial organizations.

Guess what happened next? A major, huge project came in… from a Big Three auto manufacturer.

Fine. I work with finance organizations and manufacturers, right?

Next thing, unsolicited, was all about retail. Um, we can combine that with manufacturing and refer to it as “supply chain,” right? Because I’d also had some really good past projects with distribution-oriented companies. Pity I had to drop the financial thing.

You see where this is going. Slicing the great big market of software development and consulting by vertical industry simply wasn’t going to work for me. Or if I insisted on picking a vertical niche, it would mean turning away some really good, lucrative, interesting, and fun gigs. So that’s a bad plan.

Instead I thought about the past projects that had gone really well and left the client happy. Ones in which they were thrilled to pay my invoices and kept asking for more new things.

And it became pretty obvious: what those projects all had in common is that they sucked. They were running late, or not getting started at all; they were stressing out management and causing developers to quit; they were tiring to think about!

When initially interviewing an existing project manager to get briefed on what’s going on, I’d often ask what she did on Wednesdays after a burning twelve hours of work. And three times in a row, which I clearly recall, the project manager said some variation on: “I get drunk.” (Just to be clear, I mean this happened with three consecutive projects, not that I asked the same manager three times.) I would laugh and ask no, seriously, what do you do after three days into another crappy work week? And she (another interesting consistency there) would say no, seriously, I get hammered. This stuff is so out of control that I need to get away from it by any means necessary, chemical or liquid or whatever.

That is some serious pain. And it requires a healthier approach than emptying wine bottles.

What I’m best at is dealing with software projects that suck. I mean that in the colloquial sense of “to suck,” but also in the sense that these awful Death March projects suck money, time, and motivation away from everyone who touches them. I’m very good at making the project not suck.

So yeah, there it is: “I work with owners and managers of software projects that suck to make them not suck.”

How to deal with it

So how do you fix a project that sucks? First apply the Anna Karenina principle, which I learned from Leo Tolstoy:

Happy projects are all alike; every unhappy project is unhappy in its own way.

There are so many ways software projects can go wrong, it’s impossible to say ahead of time how to make them go right. I have however noticed  some commonalities, which I’ve condensed into a list of eight major causes. They are:

1. Persisting with a technical approach that doesn’t work.
2. Wrong developer on the task.
3. Technical Bankruptcy.
4. A single technical obstacle
5. Code Hoarding
6. Redoing the same work
7. Insufficient Time
8. Vagueness

Like diagnosing a disease, figuring out why the project sucks is the first step to resolving it. On the other hand, in an emergency it’s a good idea to do the things that can’t hurt and might help right away. A patient with severe bleeding should probably get some O-negative stat, even before blood typing is done. A patient stumbling into the ER with chest pain will be given a nitroglycerin pill before the EKG is run. And a software development project that’s in serious trouble should have at least a daily stand-up meeting to identify the tactical problems that are preventing progress.

So when you know your software project sucks badly enough for me to step in, we’ll first establish a rhythm of very short, low-stress standup meetings to keep everyone moving forward. That’s always a good thing and it can’t hurt. We’ll cut out all other standing meetings that involve developers, because nothing trumps Flow. And I can usually tell from the first few standup meetings which major causes are in play.

For example:

• When developers report that they checked in working code, but got it kicked back by QA because of missing features, that’s probably #8 Vagueness of specification leading to #6 Redoing the same work.
• When one developer talks at length and in great detail about what he (and it’s usually “he” in this case) did the previous day and the others have little to say, that’s most likely #5 Code Hoarding.
• If he’s spinning wheels, it’s probably also #4 A single technical obstacle that can be alleviated by pair programming. (Which you might easily circumvent by respecting #1 Persisting with a technical approach that doesn’t work.)

See what’s going on here? Your team will tell you what’s wrong, because they’re feeling the pain as much as you are and they want it to stop too. They just don’t have the language for it, and in some cases they don’t feel they have the permission to say it out loud.

I leave you with this:

• It’s pretty normal for software projects to suck. As Tolstoy says, there’s only one way to be happy and so so many ways to be unhappy.
• There’s no shame in being honest about what’s going wrong.
• Start by doing the quick things that might help and can’t hurt.
• Identify the major underlying problem and get on that rather than hacking at symptoms. Use my list of eight as a guide. Add your own.
• Don’t hate the players. Hate the game.

When have you had a Project That Sucked? Did it match my list, or did it suck in a surprising new way? How did you make it not suck?