Defining Success

Lately, I've been thinking about my definition of project success. A lot of people would say that a project is successful when it:

  • Delivers what the client specified.
  • Delivers when the schedule says.
  • Delivers according to budget.

I think a truly successful project has to do better than that. I say software is successful when it:

  • Delivers what the client needs, and what they need now, not what they needed when the project started.
  • Delivers working software early, before every last feature is finished, so that the client can start achieving ROI.
  • Allows development to end when value creation stops without sacrificing existing investment.

(I also think a successful project preserves quality of life for everyone involved, but that isn't part of the point I'm trying to make today.)

The two definitions are similar if you define good requirements up front, work according to plan, and nothing unexpected happens. But expecting so much seems unreasonable to me. I've been on a lot of software projects, and the one thing I can always count on is that the situation will change in unexpected ways. The second definition takes this into account. It requires me to pay attention to my client's business needs and work with them as their needs change. Rather than hiding behind a thick project plan (and change control board), I expect my clients to get real value out of the projects my teams deliver. If I deliver to plan but the client doesn't get anything valuable, that's not a success, it's a failure.

My definition of project success is a hard one to meet. It requires a flexible approach to programming and a willingness to look for and respond to opportunities for improvement. That's where Extreme Programming (XP) comes in. Extreme Programming delivers very high quality software that is responsive to change. It does so not by creating complicated "extensible designs," but by creating simple designs that don't take a lot of work to understand or adapt. Every few weeks, the team takes stock of the situation and steers the project towards the updated business needs.

If this sounds interesting to you, my business is focused on helping companies learn how to consistently achieve success by that second definition. There are also many books on XP and agile development. I recommend starting with Software by Numbers and Lean Software Development for theory, then continuing with Planning Extreme Programming, Extreme Programming Installed, and Extreme Programming Pocket Guide to put theory into practice.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.