Prototype to Development Success

Why do so many IT projects fail? Well, one of the reasons, according to CIO Update is the requirements process.

You know requirements: When you write down everything you want, might think you want, and might think you might think you want in excruciating detail? And then you turn over the document to the developers only to find that the software or website doesn't do what you expected? Or, from the developer point of view, the client didn't know what he wanted, kept changing the scope and then complained that it doesn't work?

Dot-gov exists on software. Software that can be complex. The challenge is 

While it may seem simple to just have the customers or end users write up a requirements document, those often include unnecessary features or have a tendency to omit key elements.

Skimping on gathering the requirements leads to problems down the road when users start adding to the project scope, or get upset about features that were never mentioned, but, they assumed, would be included. Getting it right takes time, so don't underestimate what it takes to actually determine what it needed or shortcut the process.--More on CIO Update

How about a suggestion to get this closer to right?

The flaw...is building a prototype to the requirements, rather than using the prototype to determine them.

“We're asking (developers) to define dynamic systems that configure themselves, based on previous answers and state changes and applying business rules,” [Brian Cook of Cook Enterprise Corp] said. “There is all this complexity and we expect people to describe in words what it will do? No wonder such dismal record in terms of the results; it is the wrong medium, the wrong way to approach requirements.”

The correct approach is to build a visual prototype and then engage with the stakeholders about how the system should work. Users can then work with the initial model and give their feedback. That feedback then gets incorporated into the final design. And since it is based on actual user experience, it eliminates trying to add in lots of additional features which may not be needed. He said that doing it this way gets more people engaged in the requirements process, instead of one expert dominating the discussion of what should be built.  --More on CIO Update

This method requires a clear set of goals, the right people building, reviewing and working on the prototype and significant time and engagement from the business owner. Just as Amazon has incrementally evolved over the years based on user feedback and goals to be the biggest online retailer, and  just as Google brings projects out in large, ongoing betas, so can complex projects be brought online using prototyping and a multi-phased approach.

Today's e-gov projects are never "done," but continue to be developed as part of a feedback loop between users, business owners and developers. This also means the development costs are an ongoing budget item--like subscriptions or building and vehicle maintenance. Let's look at updating what it means to develop and deploy software.