Requirements are almost always the single largest reason for the success (or the lack thereof) of Notes Domino projects. From being bare-bones when a project is in a pre-sales mode, requirements get naturally meatier as the timeline progresses to a point where development can begin. While a wordy/elaborate set of requirements is most certainly welcomed by developers and architect alike, the quality of these requirements solely depend on the source with the client organization.
Most early requirements that come from IT stakeholders are in plain English with adequate stress on conveying the information accurately. It is natural that different stakeholders have different interpretations of what a system should do. Sometimes there is a single strong voice that drives the project and it is this voice that gets heard the most during the requirements gathering phase. And therein is the risk.
When the right stakeholder fails to be heard, the requirements that we get are not consistent with user needs. Regardless of the how high in the hierarchy it comes from, the requirement set needs to be validated by every stakeholder that would use the system.
Even as iterative and agile development methodologies are becoming just as common place as traditional SDLC, the emphasis on requirements and their definition has remained unchanged. But as traditional Domino shops go social, the process of project requirement definition has to move toward an active collaborative model where minds of users from every strata of customer’s hierarchy are tapped by IT managers and CIOs. In fact a Gartner survey from 2008 found that active collaboration is essential for successful information system and service projects.
During a recent XPages enablement project that I was involved in, post beta release, several important use cases (as elaborated by the IT head, who was also one of the company’s founders) were only partially accurate when early adopters among the business users complained about. While some of this may be chalked to user resistance, there is a lesson right here.
Regardless of the level of functional knowledge exhibited by the IT stakeholders, active collaboration with business users needs to be a key component in the requirement gathering process. Requirements’ gathering with active collaboration entails the collection of an initial set of high level requirements and then getting end users collaborate to correct any discrepancies and fine tune them. This collaboration helps validate initial requirements that may have been provided by business sponsors who may or may not have a complete idea about end user experiences. This process ensures that requirements received are logical and consistent with the end user’s needs. This process also ensures that different approaches to problem solving are discussed and evaluated.
While the key is to ensure collaboration, the modes of collaboration are diverse and may include one or more modes including brainstorming sessions, one on one interview with end users, story boarding work flows, end user surveys, workshops, facilitated role-play and hands on work in the environment. Each of these modes (there are much more) may be chosen based on the nature of the problem at hand. All these techniques will help understand user experience better and in prioritizing solutions. They may also help understand any work-around that users may have come up and identify unintended ways in which the system is used.
Regardless of the modes of collaborate requirement gathering, the process involving the end users should help to focus attention on the what and not on the how and develop SMART (Specific Measurable Achievable Realistic Timely) requirements. Collaborating with other stakeholders and users helps to identify and understand problems that have been left unsolved by previous solutions. But for maximum effect, it is obvious that users should be encouraged to contribute their opinion about possible pain points that may exist in the current solution.
Developing or upgrading a Domino based solution to solve user problems is a fulfilling exercise. But the key component of this exercise, like any other IT project, is the requirements. In the old days, when hierarchies weren’t flat, it was enough for requirement gathering to be focused on a few versatile stakeholders who gave the process its direction. However as hierarchies become flatter and flatter, spread geographically and companies go social, it has become necessary for project managers and leaders to adopt measures that facilitate active collaboration during the requirements gathering process. Thus a solid foundation for design and development is provided which goes a long way to ensure that we solve the right problem.