In a perfect world people would tell you everything you want to know, and then some... but you cannot simply hang around the water cooler to get the lowdown on what each end-user of the future system personally wants to get out of the deal. That is too bad, because missing a real user need means one user that is less than satisfied. Think of what might happen if we do not make an effort to satisfy most users. In short, we need an effective technique for eliciting requirements that draws people into the discussions to contribute their list of things they would like to see incorporated. So the challenge is to establish a forum where people are just as relaxed to contribute their opinion without having to hang around the water cooler, and to do it in a way where people can bounce ideas off one another.

The preferred strategy of PM4HIRE is to establish a requirements workshop to draws people from all levels of the organization into top-down requirements discussions based on specific directions on where the company is heading. We use the 8 steps listed below to get people prepared for a workshop and then to conduct the workshop so as to maximize the contributions by each of the participants. It is important to make sure that everyone understands that they have an equal contribution to make in this process, because if people operate on the basis of rank then there is little merit in having people from all levels participate in that process. Running a workshop is not easy, to keep people focused on the job at hand, to minimize the disruptive effect of jokesters, to draw out the more timid participants, and to make everyone feel satisfied with having contributed to a result that is more thorough than what any individual could have produced by themselves.

To achieve any kind of results from a requirements elicitation workshop it has to be arranged so that people are prepared to put in the kind of effort that is productive. It is important that people can concentrate on what this is about. You cannot accomplish much in a series of disjointed 1-hour sessions across many weeks, but when you take people out of their daily routine for a week of concentrated brainstorming it is amazing what can be accomplished. However, if you plan to sequester people for a week of requirements elicitation you had better put a good plan together to justify all the activities that you will be engaged in. PM4HIRE.COM have a basic workshop plan as summarized on this web page, beginning with securing the buy-in for an intensive 1-week focus of all participants on nothing but the requirements for a new system. It is important to get a formal buy-in for this, because if people spend half their time attending to other issues then that is very disruptive to others who are trying to get the most out of this workshop. Participation should be voluntary, and people must have a belief in themselves that they can make a contribution.

To prepare people for a workshop it is useful to produce and distribute general information about the nature of what will be considered in scope for the future product development. Typically this kind of forum is not used to generate strategic objectives: it is the exclusive domain of Senior Management to determine where they want to take the company, while the employees can help to determine how it may be possible to get there. So let's say that there is an Executive decision to provide a new loans application service that uses the Internet to provide a 7/24 access capability. The challenges from an operations perspective include how you can implement rapid response processes without increasing the loan loss provision risks to the company. It is useful to create some sort of brief outlining the goals and objectives, as well as the perceived challenges (there may be more of these once operating staff start to think about the challenges) for which solutions must be found. Perhaps you may not want to share all those details that are deemed to give the company a competitive edge, but there are plenty of aspects that can help to start people thinking about the possible bottlenecks in loan application processing. It is likely that this kind of information will be shared (perhaps around the water cooler) so it is important that any up front background information is approved by the sponsoring Executive as fit for general distribution.

To give people a sense of comfort with what will be on the agenda PM4HIRE.COM normally conduct a short 2-hour seminar on all aspects of the requirements elicitation workshop. In this seminar we explain what requirements are, and how the participants will make their mark on the future applications implemented by their company. We stress that it is also the intention for people to enjoy their contribution efforts, and to relax in order to let creative ideas form. Just knowing what will be expected and how they will make a difference can put many people at ease, certainly people who feared they would be put on the spot to come up with requirements on their own. The approach used by PM4HIRE.COM is to provide participants with a workbook that they can refer back to as the sessions progress, so they can see how the pieces of the puzzle start to fit together, and we also provide a Certificate Of Achievement for having completed the seminar and for participating in the workshop sessions pertaining to a specific project or business program.

To provide an outlet for people who have come to the workshop with a host of ideas about what improvements they would like to see in their area we often hold an opportunities for improvement assessment session first. It provides many points that can be summarized, transferred to a large Post-IT, and put in a "parking lot" until the right context is found to apply each idea. This way people get their focus off their personal agenda items and they become more receptive to participate in the bigger picture thinking. You have to make sure that you never confuse a "parking lot" for a "trash can" because people will quickly sense the true feelings you have for their pet ideas. It is not just being polite, it is also smart to think that new ideas can come from anywhere and that there is a lot of value cultivating creative thinking and problem solving at all levels of the company. You must suppress any judgements from any source and stress that all these opportunities for improvement are rooted in personal needs that should at least be considered, if not implemented. A free flow of ideas is what makes the workshop so useful for making sure that every last aspect of the various requirements will be fleshed out. The role of PM4HIRE.COM is to facilitate the participation of every attendee to make sure that they get their points across.

To establish the foundation for a new product or service the first step is to define the business requirements that need to be satisfied. Based on the original background information the participants must figure out what the true business requirements are, as the strategic goals may be too broadly defined to themselves qualify as proper requirements. This can be the most difficult part of the workshop. Most people know what they are expected to do, but often they do not understand the business reasons for doing things. You will find that some actions are most likely to be unproductive, but still people continue to do things because they live up to expectations. When you ask them to think of reasons why that can become very unsettling, but it is important knowledge before you start to change things. Executives do not ask for information to give them something to read that makes them fall asleep at night: they have to have specific information to make business decisions. If you want to improve the process that produces such information you need to understand what the information is used for, which is the basis for a business requirement. It is difficult to get Executives to participate in workshop sessions, but there may be opportunities for them to attend briefly to address the participants on the business requirements that they feel are important reasons for improving the business processes.

To satisfy the business requirements there are specific things that different user departments must do in order that the right results are produced. Therefore the second step is to identify those specific things in terms of the processes within each user department. This is often referred to as the Use Case Analysis, although we prefer to use more generic terminology. Here is where it can be crucial to have people representing all levels of users because there is nothing like first-hand experience to tell the developer what is really needed in the software to make it useful. This is much easier to collect material, because most participants know what they do even if they have no idea of why. The essence of this process is to go through the different user roles and responsibilities, to itemize those that relate to the specific business requirements or to requirements that ought to be considered as a part of the workshop focus. It is also important to understand what this user process scope is, such as how much of the total workload is related to the current workshop focus. For people who are predominantly engaged in this kind of work it will be an important opportunity to contribute, but for people involved only in a peripheral fashion it can be difficult to spend as much time as they should to make sure their needs are accounted for. Yet, these are still users of the new system that may have important requirements that need to be considered. Your challenge is to get these requirements identified and incorporated into the project.

To provide the users with the functionality they need to perform their assigned duties we need to determine what functional requirements exist. Some of these requirements will be unique to one user class, whereas other requirements may be useful across the board. Basically you need to break down the use case information into the specific functions that the software must provide to make life easier for the user. Each function then breaks down into a number of requirements that must be incorporated into the software to make it support specific user activities. Although there can be many functions required to support invividual use cases, experience has shown that it becomes easier to identify these functions because of the more narrow focus on what users need to be more productive. As customers become more sophisticated the business users will become more demanding as well, and so the standard for what is expected of each function is constantly being raised as well.

At all times we need to keep specific users in mind, as well as how these functions help the users to be more responsive in terms of the business requirements. Sometimes user requirements are not as easily tied to business requirements so that it is necessary to consider if (a) the user requirements are out of line or (b) the business requirements are incomplete. Functional requirements may provide the clues as to how the users actually contribute to the business bottom line. When you catalog all the functions performed in the process of running a business it may be that a pattern emerges, especially with respect to common procedures. This may identify incidental users that may impact on the overall process in support of the business requirements. For example, a critical transmittal report that drives the process in one user department may only be an incidental checklist in another user department where the report is considered an overhead. If you write systems from a narrow perspective then in one case the report becomes a major part of the work input, while in the other case it may be recommended for elimination because the value is not recognized in that department. We have seen amazing examples in some of our workshops where cross-functional teams suddenly realized the true value of reports and how changes in priority could have a significant impact on the effectiveness of the organization

To summarize the above effort we need to convert the requirements into functional specifications that provide an unambiguous guide to how the software should be implemented. This requires a formal process for capturing the requirements first, to make sure that nothing gets lost in the translation, and then to add the non-functional requirements that make sure that a program adhere to site standards. Not everything can be completed in the workshop, some of the functional specifications may take multiple weeks to complete depending on the scope of the project. However, once you have reached this point it becomes a matter of maintaining the requirements and then to identify any new process issues that may affect previously implemented requirements. These new issues may then be incorporated as change requests. This is not a matter of requirements overlooked, it is the result of business requirements that cannot be static when competitive pressures demand ever greater levels of sophistication of business support applications. Through it all the documentation must be kept current so that the relationships between the business requirements, user requirements, and functional requirements will be solid and traceable at all times.