Requirements without Users

Conventional wisdom and best practices tell us that end users and other stakeholders must be involved in IT application and other product requirements definition. In traditional mode, the involvement is before design and development. With an Agile approach the users must be an integral part of the project team.

What Do You Do When Users are Not Available?

But, what do you do if users are not available because they are fully engaged in their operational duties and can’t spare the time, are resistant to change, or just not interested enough?

You can wait for them to get on board the development train. That might take a long while and delay a project that can provide significant benefits to the organization.

You can force them to get on. That might get you started, but, as soon as they can or must they’ll jump off and your project will be delayed. Sometimes they will even derail the train.

What if you just start without them? Radical and risky you might say, though it might be the best way to get moving and deliver a useful product in the shortest amount of time. Think of a requirements-without-users approach that is like prototyping. A prototype can be developed based on minimal requirements and then refined until the product is ready for production use.

This approach requires that the following conditions are met, 1) you have a window of opportunity to make use of development staff that might not be available later, 2) your users and sponsors are open to getting engaged later in the process (ultimately they must get involved) 3) your sponsors and senior user management are realistic enough to accept that there will be a lengthy acceptance testing and refinement process that requires involvement by users and stakeholders. once the initial version of the product is delivered and 4) you have alternate means for determining the requirements.

Condition 1: Resource availability

Condition one means that there are programmers and analysts who are waiting for something to do and who have the capacity and knowledge to do the job. In another month, some other project will be ready to start and the resources will be grabbed up. If you don’t get started now, you may never get started.

Condition 2: Buy in

Condition two says that you must ultimately get buy in from users and their management. Buy in to the process of letting the development team has to be earned. It requires that the sponsors trust the development group to work in a way that best supports the needs of the business and that the sponsors are eager to get the project moving. It requires that the user group or groups agree to letting others “read their mind” and postpone their involvement until a prototype is delivered. Buy in to the product will come because business requirements, including efficient and effective operational procedures, are met. In other words, the product must deliver expected benefits and do so in a way that makes good business sense.

Condition 3: Realism

Condition three is realism – a management team that is able to accept a lengthy post delivery change process and who will make make the users and other relevant stakeholders available for the acceptance process. This condition implies that whatever the result of the initial round of development there will be a process to make the result acceptable to its users. It is more than likely, perhaps inevitable, that no matter how product requirements are defined and no matter who defines them, there will be changes that are discovered once the product is delivered. This is the underlying reason for acceptance testing and ongoing enhancement process planning. Taking a requirements-without-users approach generally means that there will probably be more changes than if the users were integrally involved in the requirements definition and in the development itself (as in an agile team). Consider the initial deliverable as a prototype. The acceptance process refines the prototype. The duration of this process depends on the number and type of the changes required and the availability of resources, including the users who will test the product and make requests for change.

In effect, the Requirements-without-Users approach is really a change in the placement of user involvement in requirements definition in the development cycle. in addition to change where in the cycle users are involved, it also changes the nature of the elicitation process. Users must still accept the product and that means they have to make their requirements known. Elicitation is usually done by asking the stakeholders what they want. In this approach stakeholders are asked to verify that their requirements are met by the delivered product.

Condition 4: Alternate Source of Requirements

Condition four is also about realism. In keeping with the reality that nothing spontaneously arises without causes and conditions, requirements have to come from someplace. Where do they come from when the users don’t provide them? There are a number of sources: research into products such as commercial packages for a similar application, the existing application and/or business process and its strengths and weaknesses, change requests and complaints about the existing application and process, research into the needs of the recipients of the output and services provided by the current system, the knowledge of technical staff and business analysts who have been working with the user community for years, and from expert consultants with deep knowledge in the application area.

In most application development projects an existing system is to be replaced. The system, whether automated or entirely manual, has in it many of the requirements for the new system. In effect the new system’s requirements can be inferred from the combination of the existing system’s features and functions and any complaints, change requests and/or project justifications that may be available. Manual procedures can be assessed by shadowing the users or researching standard operating procedures, if they exist.

Every system has people or other systems that provide and receive data or services from the target system. It is possible to infer the requirements of the target system from the needs of related systems. For example, if an application is supporting a service to customers, the definition of the service itself, chronic complaints and problems and knowledge of the existing system’s features and functions, new features and functions may be used to identify the requirements that will enable improved customer service.

Often IT staff and business analysts have significant knowledge of the business areas they serve. Sometimes they are more knowledgeable than the users themselves. In addition, they are structured in their thinking. They can be excellent sources of requirements, though their perspective may be too computer centric to be relied on as a sole source of requirements.

Conclusion

While it is necessary to engage the users of an application in the acceptance of their system, it may not be necessary to engage them in an intensive up front requirements analysis process. The need to take a Requirements-without-users approach to application development arises when users are not available or when they are resistant to change. When the right conditions are met, requirements can be derived from existing systems, the needs of the ultimate recipients of data and services, from knowledgeable IT and BA staff and/or from expert consultants. Based on these requirements a prototype can be created and used to validate that the product meets the users’ needs.

Don’t forget to leave your comments below.