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.

The Process of Identifying and Selecting Information Systems Development Projects-Identifying and Selecting 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

The Process of Identifying and Selecting Information Systems Development Projects-Identifying and Selecting Projects

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

The Process of Identifying and Selecting Information Systems Development Projects-Identifying and Selecting Projects

 FIGURE 4-3 Numerous factors must be considered when selecting a project. Decisions can result in one of seven outcomes.

The Process of Identifying and Selecting Information Systems Development Projects-Identifying and Selecting Projects

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.

The Process of Identifying and Selecting Information Systems Development Projects-Identifying and Selecting Projects

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.

 

 



Frequently Asked Questions

+
Ans: A wide variety of automated project management tools are available to help you manage a development project. view more..
+
Ans: Defining the general project information includes obtaining the name of the project and project manager and the starting or ending date of the project. view more..
+
Ans: A wide variety of automated project management tools are available to help you manage a development project. view more..
+
Ans: 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. view more..
+
Ans: Many activities performed during initiation and planning could also be completed during the next phase of the SDLC—systems analysis. view more..
+
Ans: Most information systems projects have budgets and deadlines. view more..
+
Ans: All the information collected during project initiation and planning is collected and organized into a document called the baseline project plan. view more..
+
Ans: Most businesses have discovered the power of Internet-based electronic commerce as a means to communicate efficiently with customers and to extend their marketing reach. view more..
+
Ans: As stated earlier and shown in Figure 5-1, the two parts to systems analysis are determining requirements and structuring requirements. view more..
+
Ans: Even though we called interviews, questionnaires, observation, and document analysis traditional methods for determining a system’s requirements, all of these methods are still used by analysts to collect important information. view more..
+
Ans: Whether traditional or modern, the methods for determining system requirements that you have read about in this chapter apply to any requirements determination effort, regardless of its motivation. view more..
+
Ans: In the last chapter, you read how Pine Valley Furniture’s management began the WebStore project—to sell furniture products over the Internet. view more..
+
Ans: Collection of information is at the core of systems analysis. view more..
+
Ans: Even though we called interviews, questionnaires, observation, and document analysis traditional methods for determining a system’s requirements, all of these methods are still used by analysts to collect important information. view more..
+
Ans: Whether traditional or modern, the methods for determining system requirements that you have read about in this chapter apply to any requirements determination effort, regardless of its motivation. view more..
+
Ans: Process modeling involves graphically representing the processes, or actions, that capture, manipulate, store, and distribute data between a system and its environment and among components within a system. view more..
+
Ans: Data-flow diagrams are versatile diagramming tools. view more..
+
Ans: Sofware engineering syllabus The course of the program is designed in an exceedingly manner that it covers all the aspects of software system engineering needed for higher understanding of the scholars. The delivery methodology of the program is usually schoolroom lectures Associate in Nursing sensible laboratory sessions beside seminars and internships being an integral a part of the course. BE/B.Tech software system Engineering give students data of evaluating the correct codes and software system for specific tasks. view more..



Recommended Posts:


Rating - 3/5
525 views

Advertisements