The Process of Identifying and Selecting Information Systems Development Projects-Identifying and Selecting Projects
The Process of Identifying and Selecting Information Systems Development Projects
Project identification and selection consists of three primary activities: identifying potential development projects, classifying and ranking projects, and selecting projects for development. Each of these activities is described next.
FIGURE 4-2 Three key sources for information systems projects.
1. Identifying potential development projects. Organizations vary as to how they identify projects. This process can be performed by:
- A key member of top management, either the CEO of a small or medium-size organization or a senior executive in a larger organization
- A steering committee, composed of a cross section of managers with an interest in systems
- User departments, in which either the head of the requesting unit or a committee from the requesting department decides which projects to submit (as a systems analyst, you will help users prepare such requests)
- The development group or a senior IS manager
Each identification method has strengths and weaknesses. For example, projects identified by top management have a strategic organizational focus. Alternatively, projects identified by steering committees reflect the diversity of the committee and therefore have a cross-functional focus. Projects identified by individual departments or business units have a narrow, tactical focus. The development group identifies projects based on the ease with which existing hardware and systems will integrate with the proposed project. Other factors, such as project cost, duration, complexity, and risk, also influence the people who identify a project. Table 4-1 summarizes the characteristics of each selection method. Of all the possible project sources, those identified by top management and steering committees most often reflect the broader needs of the organization. These groups have a better understanding of overall business objectives and constraints. Projects identified by top management or by a diverse steering committee are therefore referred to as coming from a top-down source.
Projects identified by a functional manager, a business unit, or the information systems development group are often designed for a particular business need within a given business unit and may not reflect the overall objectives of the organization. It’s not that projects identified by individual managers, business units, or the IS development group are deficient, but rather that they may not consider broader organizational issues. Project initiatives stemming from managers, business units, or the development group are referred to as coming from a bottom-up source. As a systems analyst, you provide ongoing support for users of these types of projects and are involved early in the life cycle. You help managers describe their information needs and the reasons for doing the project. These descriptions are evaluated in selecting which projects will be approved to move into the project initiation and planning activities. In sum, projects are identified by both top-down and bottom-up initiatives. The formality of identifying and selecting projects can vary substantially across organizations. Because limited resources preclude the
TABLE 4-1: Common Characteristics of Alternative Methods for Making Information Systems Identification and Selection Decisions
development of all proposed systems, most organizations have some process of classifying and ranking each project’s merit. Those projects deemed to be inconsistent with overall organizational objectives, redundant in functionality to some existing system, or unnecessary will not be considered.
2. Classifying and ranking IS development projects. Assessing the merit of potential projects is the second major activity in the project identification and selection phase. As with project identification, classifying and ranking projects can be performed by top managers, a steering committee, business units, or the IS development group. The criteria used to assign the merit of a given project can vary based on the size of the organization. Table 4-2 summarizes the criteria commonly used to evaluate projects. In any given organization, one or several criteria might be used during the classifying and ranking process
As with project identification, the criteria used to evaluate projects will vary by organization. If, for example, an organization uses a steering committee, it may choose to meet monthly or quarterly to review projects and use a wide variety of evaluation criteria. At these meetings, new project requests are reviewed relative to projects already identified, and ongoing projects are monitored. The relative ratings of projects are used to guide the final activity of this identification process—project selection.
3. Selecting IS development projects. The selection of projects is the final activity in the project identification and selection phase. The short- and long-term projects most likely to achieve business objectives are considered. As business conditions change over time, the relative importance of any single project may substantially change. Thus, the identification and selection of projects is an important and ongoing activity.
Numerous factors must be considered when selecting a project, as illustrated in Figure 4-3. These factors include:
- Perceived needs of the organization
- Existing systems and ongoing projects
- Resource availability
- Evaluation criteria
- Current business conditions
- Perspectives of the decision makers
TABLE 4-2: Possible Evaluation Criteria When Classifying and Ranking Projects
FIGURE 4-3 Numerous factors must be considered when selecting a project. Decisions can result in one of seven outcomes.
This decision-making process can lead to numerous outcomes. Of course, projects can be accepted or rejected. Acceptance of a project usually means that funding to conduct the next SDLC activity has been approved. Rejection means that the project will no longer be considered for development. However, projects may also be conditionally accepted; projects may be accepted pending the approval or availability of needed resources or the demonstration that a particularly difficult aspect of the system can be developed. Projects may also be returned to the original requesters who are told to develop or purchase the requested system themselves. Finally, the requesters of a project may be asked to modify and resubmit their request after making suggested changes or clarifications.
Deliverables and Outcomes
The primary deliverable, or end product, from the project identification and selection phase is a schedule of specific IS development projects. These projects come from both top-down and bottom-up sources, and once selected they move into the second activity within this SDLC phase—project initiation and planning. This sequence of events is illustrated in Figure 4-4. An outcome of this activity is the assurance that people in the organization gave careful
FIGURE 4-4 Information systems development projects come from both top-down and bottom-up initiatives.
consideration to project selection and clearly understood how each project could help the organization reach its objectives. Because of the principle of incremental commitment, a selected project does not necessarily result in a working system. Incremental commitment means that after each subsequent SDLC activity, you, other members of the project team, and organization officials will reassess your project. This reassessment will determine whether the business conditions have changed or whether a more detailed understanding of a system’s costs, benefits, and risks would suggest that the project is not as worthy as previously thought. In the next section, we discuss several techniques for gaining a thorough understanding of your development project.