One More Key for Successful Software Projects

May 8, 2009

Several of us recently went through a couple of days of presentation skills training. Our final presentation needed to be in the five minute range, and believe me, five minutes makes for an extremely short presentation! I needed a topic that was very focused, yet rich enough to fill in five minutes.

Since I have a software development background, I elected to discuss one key that I feel is essential in software project success:

Smaller is Better

Why do I believe this to be true?

The classic definition of success – as customers perceive it – is determined on four dimensions:
  • On Time
  • On Budget
  • Of High Quality
  • Delivered with the Expected Features
My premise is simple; the larger the project size, the greater the likelihood that the project will fail on at least one of these dimensions.

Why is this so?

Large projects mean that there are many features involved. Features by themselves are not a bad thing, but a large project – particularly one that has a high feature count relative to the size of the project team dealing with that feature count – is where trouble begins to creep in.

As the team begins to deal with all of the individual features, there will be less time spent on each feature. Sure, the team might get out of the gate vetting every feature in great detail, but as time goes on, people will get distracted, temporarily lose focus, and gloss over at least some of those features. There will be a loss in precision and explicit detail. People are human, after all.

When this loss of precision and explicit detail occurs, assumptions or ambiguities will exist. And they will show up at unexpected times, and in unanticipated ways.

Sooner or later, a programmer will be translating a written specification into working code. An incomplete feature specification means that dangerous assumptions could find their way into the code. And if the programmer does the right thing and raises a flag to resolve an ambiguity, this will be occurring at unplanned-for points in the project, slowing down progress.

This leads to another problem. There will likely be impacts to related features. Resolving ambiguities with one feature “on the fly” may cause teams to overlook how one change will impact other features. It takes experience and discipline to evaluate the full impact of changes made to one feature on other features.

Finally, large projects require more people. This increases the lines of communication – along with the greater potential for miscommunication – as well as requiring more overhead in terms of keeping everything and everyone coordinated.

Smaller projects that have a smaller, well-prioritized feature set will have shorter time frames and the ability for all involved to have their heads wrapped around the effort in a collaborative, participative manner that is increasingly difficult to achieve with larger projects.

Smaller truly is better!