2.DON'T THROW IT OVER THE WALL: The Right People Should Define the Requirements

You want software requirements that help the development staff create an application that gives the user joy. To achieve that goal, you need to get the right people into the room. Many corporations depend on a business analyst to elicit information from the user, to document it in a company-approved way, and then to throw the paperwork over the cube wall to developers who rarely (if ever) interact with the people who will be using the software.

Instead, says developer Dave Nicolette, "CIOs should use business analysts in a role more in keeping with the job title: to analyze business processes and identify opportunities for improvement . . . On software development projects, business analysts should not get between the customers and the developers. When they do, they only cause confusion."

The most important person in the requirements-gathering process is the user. Daniel Corbit, senior software engineer at CONNX Solutions, says: "Software requirements are not dictated from the top; they are gathered from the bottom. If they do not model the real-life business process of how a company does its work, then they are doomed to fail in execution . . . The key part of the equation is to carefully interview everyone who uses the tool and everyone who will be impacted by the tool to find out what it needs to do."

Put the person who will use the software in the room with the person who will create the software — which you may note is also a foundation of agile software development. Find out what the user needs to accomplish. This doesn't necessarily mean that you need to define what each screen looks like. Carlton Nettleton, a software developer and agile coach, points out that "meeting a series of requirements is not the same thing as meeting our customer's goals. Tell me what the customer's goals are; even better, bring the customer in and he/she can tell me in person. We can then figure out what types of requirements are needed. Then, when we are ready to execute, let us plan around our customer's goals, not around the requirements."

However, this isn't a one-time visit. The stakeholders have to get and stay involved. According to Ellen Gottesdiener, principal consultant at EBG Consulting and author of The Software Requirements Memory Jogger and Requirements by Collaboration, it's important for the CIO to ensure that technical and business communities collaborate on requirements, early and often. The classic approach is to throw a Marketing Requirements Document over the wall. Instead, she says, "a bridge must be built, to collaborate between technical and IT stakeholders. Get personally involved in this effort. Find out what works in your organization to actively and productively engage customers in requirements development."

Gottesdiener offers a real-world example. A project started, ran and failed three times. The organization tried internally once; then it outsourced it; finally it tried again internally with another IT manager. From the start, Gottesdiener explained, the business sponsor was disengaged, and participation by the users and business experts was sparse. But the solution was necessary, for both business and political reasons, so the organization decided to try again. This time, however, it conducted a retrospective to examine the project in a deep and significant way; both product and process were explored. Gottesdiener says that this time around, "they see the role management has played in colluding, not sharing information, infighting, lack of transparency. They examine the frustrations of not getting users to participate in requirements development and validation. The whole story gets put, literally, on the wall in an open manner. They decide as a team what they would need to do to be successful. It involves starting with full-time customer resource for a fixed time frame, requirements workshops, reviews, prototypes and ongoing retrospectives for each milestone. And of course, management helping them make all this happen with the right people and money, at the right time." According to Gottesdiener, the fourth time was the charm: The group delivered on time, on budget — a first for the department.