By Douglas Havelka and Sooun Lee
The IS requirements-gathering process is a critical first step in the IS development or adoption process. However, IS requirements are too frequently incomplete, inconsistent, or incorrect. Often, the reasons for this failure have less to do with technologies than with people and management.
This article presents the results of a study of the critical success factors (CSFs) associated with information systems requirements gathering. The results are based on a survey given to IS development personnel and to IS users who have participated in a requirements-gathering effort.
Five CSFs for IS requirements gathering
1. Management commitment to the project
Management commitment to the project was described as the level of importance that upper-level management placed on the successful completion of the project. In general, management commitment refers to the emotional or psychological obligation that upper management demonstrates toward the project. It is not surprising that management commitment was selected as the most important factor when all the factors were considered.
Not only does management commitment drive individuals to perform because they wish to achieve recognition from their superiors, but management commitment is directly linked to whether adequate financial, human, and technology resources would be available.
Several things can be done to ensure that a project has adequate management commitment prior to the project’s launch. One is to require the presence of a champion for the project. A champion is a high-level manager within the organization who acts as sponsor and leader for the project. The champion should possess enough clout within the organization to gain necessary resources and exposure for the project to succeed.
The champion should also be held accountable for the success or failure of the project. In larger organizations, the champion should be required to hold an official high-level position. In smaller organizations, the champion for any IS project of significance should be the president or CEO. Few projects should proceed past a feasibility stage without a champion’s signature on a project proposal.
Another way to ensure management commitment to a project prior to IS requirements gathering is to have a formal project proposal process in place. This process should include the feasibility analysis (including economic, technical, and human resources aspects) and some type of capital budgeting or investment comparison that will clearly show the financial returns for the project.
For smaller firms, at least a cost/benefit analysis should be performed and the payback period and break-even point for the IT investment should be estimated and compared to other investment opportunities. The final step of this process is approval of the proposal by management that will be held accountable for the project’s success or failure.
One last approach to improve management commitment to a project is to clearly communicate the importance of the project to all the departments, divisions, work groups, etc., by having a kick-off event or information session sponsored by the manager whose span of control covers all of these areas. This will send the clear message to the managers, users, and IT personnel involved that the project has the backing of high-level management.
Alternatively, a letter or e-mail communication from the CEO or CIO may achieve the same result if it is specific in explaining the outcomes to be achieved and the importance of the project.
2. Interaction between users and IS personnel
Interaction between users and IS personnel was described as the quantity and quality of communication and the amount of group activities performed, including feedback from and to one another during the process. Interaction is distinguished from communication by the inclusion of other behaviors being performed jointly by the users and IS personnel.
Perhaps the most interesting aspect of this factor is that there is an inverse relationship between the quantity of interaction between users and IS personnel and the quality of this interaction. Apparently, when more time is needed for users and IS personnel to interact during a project, it is a symptom of other problems. That is, unusually greater amounts of interaction between users and IS personnel have a negative impact on the quality of the information obtained.
The rationale for this phenomenon is that when there are other “issues” not directly relevant to the IS requirements being addressed, a greater amount of time is spent communicating or interacting during the requirements-gathering process. Therefore, increased levels of communication (i.e., more meetings than is normally expected or a higher number of conference calls or personal visits among team members) may indicate other problems with the project (a lack of understanding of requirements, politics, etc.) that may impact the success of the project.
To improve the quality of interaction among users and IS personnel during IS requirements gathering, managers have several alternatives. One is to take advantage of joint application development (JAD) or other group meeting techniques that use a neutral facilitator to run structured meetings to gather requirements. A good facilitator should be able to keep the user and IS participants focused on the goal of specifying the IS requirements.
Another option to improve interaction is the careful assignment of members to the project team. The selection of users and IS personnel with personal interest in the new system improves the chances for success.
Related to this is the importance of selecting user representatives who have a superior knowledge and understanding of the business processes that are to be supported by the new system. One expert has suggested the rule of thumb is to assign the person that the department can least afford to miss for any period of time.
In addition, it has been suggested that assigning IS developers to the functional areas to perform the tasks to be supported by the new system also improves the quality of interaction between users and IS personnel. By performing the tasks in a functional area, IS personnel develop a deeper understanding of the business processes and gain an appreciation for the functions and features needed in the new system as well as the constraints that may impact a computer-based system.
3. Goal congruence among IS, users, and management
Defined as the agreement among management, user groups, and the IS department on the purpose of the project and the deliverables to be produced, goal congruence was rated the third most important factor to successful IS requirements gathering. This factor is directly affected by the existence and quality of a feasibility study and plan.
The feasibility study should include information regarding the scope of the system and the goals to be achieved. In general, both explicit and implicit goals are associated with every project, and to be successful, substantive agreement is needed on these goals.
This factor may also be affected by the interaction among users and IS personnel discussed above. It is expected that high-quality interaction would lead to a high level of goal congruence. However, goal congruence is clearly a distinct factor as the interaction may be high quality, but there still may be misunderstanding or conflict among the stakeholders with regard to the goals of the project.
Another aspect of goal congruence is the difficulty encountered when more than one user area is involved with the project. Today, almost every information system in an organization impacts more than one functional area (some touch on every area, e.g., ERP systems). Usually, these different functional groups can have different, if not competing, requirements for the system. This makes the achievement of goal congruence more difficult. This is not intended to mean that a system cannot meet multiple goals. However, all of the goals of the project should be made explicit, public, and as concrete as possible.
Finally, there may exist unseen or hidden goals. These hidden agendas could come from any area, such as management, IS, or user groups, and could be benign and legitimate or could be intended to sabotage or damage the project. In general, the best approach to achieve goal congruence is to explicitly recognize and describe the goals and to restrict the scope of the project to the fewest number of functional areas possible.
4. IS personnel’s understanding of the application
IS personnel’s understanding of the application is defined as how well the information systems personnel understand the purpose, the tasks, and the outputs of the work processes that the application is to support.
This is typically referred to as domain knowledge. The involvement of IS personnel—who have knowledge regarding the application domain for which requirements are being defined—greatly increases the ability of the team to correctly and quickly specify the requirements. Specifically, having IS personnel on the team who have had prior experience in the domain area (e.g., by developing similar applications or doing support work, or best of all, performing some of the users’ job functions) allows IS personnel to understand terminology and have a deeper understanding of the users’ needs.
The IS personnel’s level of domain knowledge would also be expected to positively impact the quality of the requirements-gathering process. By being familiar with the terms and business processes under study, semantic confusion should be avoided and communication improved.
However, there also may be negative effects of IS personnel experience and domain knowledge within a specific area. This may manifest in a form of bias. Bias has been defined as a willingness to change or to try new approaches or as the resistance to new ideas and change.
This second type of bias may be relevant because an IS developer may have been involved in earlier projects for the same system and be resistant to new ideas or technology or to doing things in ways different from before.
The planning factor was described as the amount of preparation performed for the IS requirements-gathering process and included the identification of specific tasks and the person responsible for performing them. Studies have shown that a work plan and schedule for completion are necessary for project success.
Reports of projects where an effort was nominally started without a specific plan or schedule, only to be forgotten in short order, are not unusual in most organizations. Also, stories abound where a project was begun with planned work activities and a schedule was laid out but no tasks were assigned to specific individuals, and everyone was surprised when the first set of milestones occurred and no work had been done.
The existence of a project champion and a formal project approval process, including a project plan, helps to ensure that planning activities take place. The presence of a project manager who is responsible for planning and tracking project activities and is accountable for the work being performed is highly recommended.
TechRepublic and Auerbach Publications
This information originally appeared in the Summer 2002 issue of Information Strategy: The Executive's Journal. It appears here under agreement with Auerbach Publications. This excerpt is from the Auerbach report "Critical Success Factors for Information Requirements Gathering." For information on subscribing to this journal or to see a list of previously published topics, click here . To find out about other Auerbach publications, click here.
Douglas Havelka, Ph.D., is an assistant professor in the Decision Sciences and Management Information Systems Department of the Richard T. Farmer School of Business at Miami University. His research interests focus on requirements engineering and systems development.
Sooun Lee, Ph.D., is a professor at MIS at the Richard T. Farmer School of Business at Miami University. His interests include Web-based project management, systems analysis and design, and data communication.