Don’t short-change this process! The business must provide input on the true goals for the software – and what will provide the biggest bang for the buck. For those of us who work in the commercial software industry, this is a must. We need to consider what our unique value proposition is relative to our competition, but my position is that this should hold true for in-house software development efforts as well.
After all, why would anyone want to spend time and effort duplicating what is readily available in the marketplace? Thinking more deeply about what you need and why something that is commercially available does not work may lead you to a much more achievable and proper solution. You could find yourself in a situation where the commercial package provides 80% what the business needs, and the real value-add is to augment that solution in some way. And augmenting something is one heck of a lot easier than building everything from scratch!
And for those who are thinking that you can develop a quality application that equals what is commercially available, I’d re-check your estimates. Odds are, you are being overly optimistic somewhere. Think twice before building something that is already available!
Key #2: Customer Involvement is a related and vital component. Yes, if the business is setting the priorities appropriately they are indeed involved, but what I’m talking about here is getting involved at another level. After you’ve decided what the right thing is to do, you need to get it right.
And getting the requirements right is so essential that I would like to reiterate the points I cited from Steve McConnell and Karl Wiegers:
- Requirements defects in software projects account for approximately 50% of product defects.
- The percentage of the re-work on software projects due to requirements defects is greater than 50%.
One problem is that business users – the ones who have the expertise and knowledge needed to make a project a success – already have jobs, and it isn’t to sit with development teams for long periods of time to talk about their business and the features that they need. Another problem is that it is very difficult for business users (or anyone) to evaluate – on pieces of paper – what has been described to the development team as being complete and accurate.
On the flip side, the development team needs to know what to build, and computers happen to be the dumbest, most literal devices on the planet. (For those who have raised kids, teenagers run a close second here, but I give the edge to computers; there are plenty of smart teenagers, they just use their intelligence for evil by frustrating adults with their word games.) Computers need to be told – in excruciating detail – what to do, when to do it, and how to do it. And they will only do what they’ve been told to do, no more and no less.
This is why I’m not a proponent of large-scale software projects. The larger the project, the greater the likelihood of failure, or at least significant cost overruns. (A cost overrun alone can push a project into the failure category, particularly if it is significant.)
There are two major problems with large projects:
- There are more features. The result is that there is less attention paid to each individual feature. In my experience, the smaller projects devoted much more time to defining, designing, reviewing, and iterating back through requirements than the larger projects. The larger projects simply taxed people too much.
- There are more people involved, and this increases lines of communication, requires more effort to coordinate work, adds more complexity because a greater number of components need interoperate, and there is less time available to scrutinize every aspect in the same way that a smaller project can operate.
If you have a complex project mapped out with one little circle that contains the phrase “and then a miracle happens,” your project will not succeed. As crazy as this sounds, there are projects where people intuitively understand that this point exists and even joke about it, but no one will publicly admit it or push back. The project rolls on until it eventually reaches the breakdown point – where the miracle was supposed to happen, but didn’t. And another project failure is added to the record books.
One great resolution (in my mind) to everything that I’ve discussed in this post is addressed with Agile development. One important aspect of Agile is that it focuses on delivering working software in small increments of time so that the software can be routinely inspected. This solves one major problem that many users have: they can’t envision how the software will work for them by reading specifications documents! They actually get to see working software to provide feedback on it.
At my company, we’ve adopted Agile development and had greater success with our projects overall. Adopting Agile also focused our attention on our priorities to a much greater extent. While the switch to Agile had its bumps in the road, all in all, it has been a great move for us.