Six Sigma, meet software development.
While other industries strive for perfection, as expressed in
the set of practices (made famous by Motorola, GE and others) aimed
at achieving fewer than 3.4 defects per million, the motto for the
software development industry might be: "Finish something.
Anything."
The Standish Group, in its annual survey of software
development, has been tracking these depressing trends for more
than a decade. In 2004, Standish said, only 29% of projects
succeeded, while 18% failed and the rest were "challenged."
For the average project:
- The cost: 56% over budget
- The time: 84% over deadline
- The functionality: 61% under target
In other words: Expensive, late, and weak. This is a massive
indictment of our profession.
But there is a better way, I believe. In my experience, it
starts with approaching software development from a different point
of view.
Building software is like building a house
Let's say I've decided to build myself a new home. What's the
first thing I should do? Go round up a truckload of carpenters and
haul them out to the empty lot, right? Of course not. Yet I've seen
client after client do precisely that when it comes to software.
They start with developers.
Here's what I'd really do: I would start with an architect. He
would draw an artist's rendering so I can envision what my house
would look like when I move in. Then I'd take his renderings to an
engineer. He would draw up plumbing, wiring and mechanical plans.
Finally I would take my plans to a general contractor. He
would schedule the workers, order the lumber, and give me an exact
price and delivery date. If it's done right, the planning should
take as long as the actual construction.
At StoneHenge Partners, that's how we prefer to approach our
projects. On every project we run, there are three key roles: The
business analyst (like the architect in house-building), the
technical architect (like the engineer), and the project manager
(like the general contractor).
- Our business analyst answers the question:
Why? He helps the client define their goals for the software,
identifies their end-users, sees those goals through the end-user's
eyes, and sketches out a vision of the user's experience. The
deliverable is a User Experience Blueprint, which includes a
feature set, user personas, information architecture, and
interaction design at a wireframe level.
- Our technical architect answers the question:
How? He defines the platform and environment, sets assumptions and
constraints, and prepares a plan of attack. Using Function Point
Analysis, he breaks down the software into its most basic
components, then lines up those components into an assembly line.
The deliverable is a tech spec, which includes the logical design,
physical design, data model, and class diagrams.
- Our project manager answers the questions:
Who, What, and When? She accurately sizes the project, manages
scope and cost, time & resources, risk and quality, and
communication. The deliverable is a project plan, Function Point
count, ongoing meetings, status reports and communications.
Yes, it works
We've been tinkering with our methodology for almost a decade
now, and I'm convinced it works. We call it the Nimble
Method. Here are two quick examples, both from the same
client, Dollar Thrifty Automotive Group.
- The job: Build a web app to deliver real-time enrollment in a
loyalty program. The scope: 146 Function Points, requiring 2,044
man-hours, to be delivered in 9 weeks. The work: 3 iterative
sprints, 19 changes, 110% of promised functionality. The result:
Code-complete, tested and handed off on the day promised.
- The job: Enhance a web content management system to control up
to 800 microsites. The scope: 105 Function Points, requiring 1,448
man-hours, to be delivered in 8 weeks (in the Christmas holiday
season, no less). The work: 5 iterative sprints, 100% of promised
functionality. The result: Code-complete, tested, and implemented
on the day promised. A plus: 30 days post-launch, zero
defects.
Are these isolated cases? I don't think so. I'm convinced our
process is:
- Repeatable. Success does not depend on
"superstars" in the three critical roles. If competent
professionals are plugged into the roles, as long as we adhere to
the process, the results will follow.
- Flexible. On smaller projects, maybe one
person represents all three roles. On back-office projects, maybe
the business analyst role is less needed. As long as we consciously
examine the project from all three points of view, the results will
follow.
- Trainable. Our methodology is composed of
industry-accepted practices, like Function Point Analysis, Agile
development, and user-centric interaction design. That means we can
train new hires in the way we do things.
- Cost effective. So often a client will say
they don't have "the luxury" of such in-depth planning. But we've
found a well-planned project finishes faster with fewer defects
than one that is poorly planned. Like the old carpenter's motto:
measure twice, cut once.
Best of all, the process is enjoyable.
It's a pleasure to build something well. And, after all, when was
the last time you could say you enjoyed working on software?