Thursday, March 02, 2006

Software Development Success Reference Model - Background

What does it take to run a successful software development project? Success does not come easy, but it can be done. The industry has many success stories, and software development thought leaders have identified the key principles that lead to success. But what are the critical success factors, and what principles find common ground among the experts?

About 6 months ago, I started trying to create a set of success factors that were synthesized from the experts. I have since completely revamped my thoughts. What I ultimately want, for my own purposes, is a "Reference Model" (e.g. the OSI 7-Layer Model) that provides some structure with which I can I can think and talk about the various factors that lead to success--independent of any specific methodologies. I hope to be able to say things like "Reflection Workshops in Crystal are one technique to Continuously Learn and Optimize," or "XP provides a system for Iterative Development and Proven Practices, focused on smaller Project Teams."

I have now spent some more time thinking, and included some more popular, respected sources. The following slide is my Reference Model, a 30,000 ft. view of software success.

In future posts, I will provide more details on the individual success factors and how they relate to the work of industry luminaries. So, how did I arrive at this model? I started by taking the most important, highest-level principles and factors from the following excellent resources:
  • The Standish Group's CHAOS study [CH1..9]
  • The Unified Process or RUP [RUP-1..6]
  • The SCRUM meta-process (web, book) [SC-1..4]
  • Alistair Cockburn and Crystal methods (web, book, book) [AC-1..7]
  • eXtreme Programming (web, web, book) [XP-1..5]
  • My own experience on dozens of successful projects [JT-1..6]

There were several steps between extracting the critical success factors from these sources and defining my "nutshell" view, but the following slide captures the start of my reasoning. This is an "affinity diagram" that attempts to consolidate all the factors into logical groupings.

Comments are most welcome.


Anonymous said...

Hi John,

Looks interesting, but the images are small and hard to read. Could you post, or email me, them in a larger size so I could print them out?

Also, I'd be interested in your thoughts on how to balance the trade-offs between the apparent contradictions of "Manage for Agility" and "Build Rich Specs."

--Mike Rutter

John said...

Thanks Mike. I have updated the post in response to your comments.

I'll try to post more on this soon. For now, my concept of "Manage for Agility" means that Management (external to the Team) really buys in to Iterative Development--They recognize that requirements are dynamic and don't demand Big UP Front Analysis or Design. I'm not saying that this is easy or common, just that it is often key to success.
"Use More Realistic Specification" is about defining the system with something, anything, more "real" than paragraphs of text. Wireframes, mockups, UML models, or best of all, working code. 37 Signals' "Getting Real" approach, for example, argues for very aggressive prototyping in lieu of documentation.

Anonymous said...


I have been asked to develop a reference model for an application which is under development. So far, I have done SRS, Design document (LLD & HLD) only. I have no clues on this Reference Model.

Any help would be appreciated.