Print

Choosing the Right Projects

01 Oct, 2003

Dear clients and colleagues,

Since my last update, I've gotten married! On July 19th, I married a wonderful Canadian woman. To celebrate our wedding, we both changed our names. My name is no longer Jim Little: it's Jim Shore.

With the new name came new business cards, and with them, some time to think about my business. As you know, I specialize in coaching teams in agile development. But that's a mean to an ends, not my primary goal. What I'm really passionate about is helping teams deliver good work that does the right thing, for the right people, when it's needed.

I've talked a lot about "the right thing, for the right people, when it's needed." That's the core of agile development. What I haven't talked about as much is the "good work" part. But doing high quality work is essential to agile development. More importantly, it can reduce your costs. So when you see my new card, you'll see my new motto as well: "quality and agility."

When most people think about software quality, they think of the typical QA department, testing the product before it goes out the door. That's not the kind of quality I'm talking about. Testing will tell you if your software works, but it won't cut costs. I want your team to produce quality work from the beginning. If they do, they'll have fewer bugs and their design will be more malleable. They'll get done quicker, cheaper, and be better at responding to change.

The ways to improve software quality could fill several books... and in fact, it has. One of the authors of those books is Tim Lister, the co-author of Peopleware. I had the opportunity to hear him speak at the recent Pacific Northwest Software Quality Conference.

Tim Lister spoke about introducing quality before the beginning: when a project is chosen for funding. The biggest risk an organization faces, he said, is failure to choose the right projects. There are finite development resources in any organization, so a decision to do one project is a decision not to do another.

Have you been involved in a cost/benefit analysis in which the cost was precisely quantified but the benefit was barely mentioned? Quantifying benefits can be hard, so sometimes organizations focus on primarily on costs. That's unfortunate, because value is every bit as important as cost. If one project costs twice as much as another, but its benefit is three times as large, which project should you do?

Take a look at the projects that your organization is funding. Are they valuable? One way to find out is to look at their deadlines. If the deadline is real, it can be explained easily. ("We've got to be ready for the Widget Expo!") More often, though, deadlines are driven by cost containment. The more aggressive a project's schedule, the less likely it's valuable.

Take a look at the amount of slack in the schedule, too. If you're doing something really important, like catching a plane flight, you'll leave time for problems. I leave for the airport nearly two hours in advance of my flight. Similarly, the more important a project, the more slack the schedule should have for problems. The less slack, the less likely the project is valuable.

arbitrary deadline + aggressive schedule + no slack = questionable value

Unfortunately, aggressive schedules lead to low development quality as developers cut corners to meet the deadline. This sort of development has an ugly cost curve: initially low, then shooting up out of control at the last minute as the delivery date is postponed, and postponed, and postponed again.

All this leads to an unenviable situation: low value projects have aggressive schedules, resulting in low quality development, leading to spiraling costs and schedules. The cost of the projects could easily exceed their value.

Break out of this trap by starting with higher value projects. Choose projects whose benefit is sufficiently high that the schedule can include some slack. High value projects might be riskier. Use risk management strategies, like agile development, to enable you to sensibly take on those risks.

Sincerely,
Jim Shore