Why Software Development Projects Fail, Part II: Requirements
This series of five articles takes a closer look at software development, the reasons for failure and how to avoid them.
The simplest way to ensure a successful software development project is to clearly define the requirements. Easier said than done, of course. This demands not only an understanding of the individual processes being automated, but how these fit into the overall operation of the organization.
You have to have a shared conceptual mode of how you view and think about the business, said Brian Cook of Cook Enterprise Corp. If you don't have a consistent view of the business, or an entity within the business, you will miss all kinds of things.
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.
Rather than asking the customer to document requirements, we adopted more a interactive approach when we interview customers, document it and play it back, said Abid Ali Neemuchwala, VP and head of Global Process Excellence for Tata Consultancy Services (TCS). We have found this interactive approach to be more effective for getting the untold requirements right.
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.
Often, people don't put enough time into determining requirements, said Jon Hughes, VP of Robbins-Gioia's Technology Solutions Group. A week long session is not out of the question to develop a requirements document for a system of maybe a thousand users.
Facilitating the Discussion
The process starts with meeting the stakeholders in person to discuss the requirements and get agreement on them. Make sure your process is structured and efficient so you can get as much information out of them in the first meeting as possible, said Jeff Monteforte co-founder of Exential, and IT management consulting firm in
Generally, a project will have a particular person championing it, but you want to speak to more than just this individual. It is best to get a good sample of the end users together to agree on what they need. Ideally it would be best to assemble all users in one room: executives who will use the system for reporting and decision making along with those who will be using the software to do their jobs, said Hughes. It's also a good idea to have several people from the project team involved in the meeting.
We typically approach it in a consultative manner and have a minimum of two to three people facilitating the session: one taking notes, and another capturing the architecture and technical details behind the system, he said. The third one is a facilitator to keep the conversation going though often that is not a problem because the users are passionate about what they are trying to design, build and move forward.
In the meeting, it is important to explore areas that the customer might not think of. This includes any non-functional requirements such as scalability, integration, performance and future expansion plans. Be sure to use your experience and expertise to rein in competing visions of what they system should do so you don't wind up with a bloated, unusable system.
Thats when you get drop-down boxes with 4000 options and webpages taking forever to load, said Mikhail Bykov, CTO of Luxoft, an international IT services firm headquartered in
A Demo's Worth
While you should walk out of your meetings with a document, don't expect that you will be able to accurately capture everything about an interactive piece of software on a piece of paperor that it will be understood the same way by all parties.
How can all these things we are documenting and writing and calling 'requirements' actually be requirements when 45% of everything that is built, on average, never gets used? asked Cook. There is a fundamental flaw in the way industry is doing it.
The flaw, he said, 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, Cook 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.
It helps get rid of some of the bloat, says Cook. Now you have an application that is more elegant and better meets the business needs.