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 Cleveland, Ohio. “You can go back later to clarify something on the requirements, but using fragmented, unprofessional communication techniques gives IT a black eye.”

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.

“That’s 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 Moscow. “If you don’t gather the non-functional requirements(such as performance and reliability, as opposed to the end-user functions of the software), you will wind up with a system that useless. Either it performs poorly or it simply can’t run in the existing environment.”

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 paper—or that it will be understood the same way by all parties.