[Analysis | Design | Implementation | Support | Cross-Life]

[Introduction | PDF | Links | Questions | Senior Project | Home]




Not all organizations Include systems planning in their SDLC. Even today, many or most development projects are initiated only in response to management and user requests. Those managers and users who "scream the loudest" (or have the most money to spend) dictate which projects are begun, regardless of the overall impact on the business. But systems planning is becoming Increasingly common as businesses learn that information systems should not randomly evolve - they should be planned.

The systems planning function of the life cycle seeks to identify and prioritize those technologies and applications that will return the most value to the business. Synonyms include strategic systems planning and Information resource management.

Systems planning Is driven by the cooperation of systems owners. Hence, in the pyramid model, it addresses PEOPLE, DATA, ACTIVITIES, and NETWORKS from the system owners' perspectives. Information systems participants do, however, usually exploit the opportunity to educate system owners about TECHNOLOGY directions and potential.
Before we begin, we should point out that systems planning is an ongoing process. It must be repeated regularly in order to ensure (1) that information systems are developing according to the plan, and (2) that management decisions or external factors have not changed the plan.
What triggers systems planning phases? Generally, systems planning is triggered by an agreement between Information systems management and top business executives that information systems and the use of technology should be carefully planned.
There are many different systems planning methodologies; however, this relatively simple approach is representative.

Study the Business Mission

Although many businesses haven't formally documented their mission, they all have one. If information systems are to truly return value to the business, they need to directly address that mission. Thus, the first phase of systems planning is to study the business mission.
Ideally, the scope of the phase should be the entire business. For some companies, that is much too large. consequently, the scope might be reduced to a more manageable level-a division, a plant, or some other significant operating unit. For other companies, the scope of the phase is limited by the level of top management support received. Top executives of the organization must be willing to participate in the development of any strategic plan. Otherwise, the phase is useless.
Members of the planning team include information systems managers and the key business executives (system owners). The key facilitator of this phase is a planning analyst.
Planning analysts are specially trained information systems planning professionals. Their job is similar to that of systems analysts; however, they must be even more business-oriented that? the average systems analyst. Planning analysts must be familiar with the planning methodology to be used and the deliverables to be produced. They require a unique blend of skills and experiences, including business management, systems analysis and design, data management, and networking.
Many IS shops have difficulty finding the correct mix of these skills. Particularly, IS professionals tend to be either too applications-oriented, too database-oriented, or too network-oriented. In this case, the business usually hires management consultants to serve as the planning analysts. These consultants are widely available through IS consulting firms (e.g., Ernst & Young, James Martin & Associates, or IBM)
The input to this phase is the business mission, as "discovered" through interviews and group sessions with system owners. The business mission Is usually defined in terms of customers, products and services, material resources, human resources, geographic operating locations, management structures and philosophy, corporate goals and objectives, unavoidable business constraints, critical business success factors, and other management-oriented criteria.
The key deliverable is business plans. Hopefully, those plans already exist; this phase merely translates them into terms or formats that are useful to the system owners and planning analysts in subsequent planning phases. (All too often, that plan does not exist!)
Based on the findings of this phase, the planning effort could be canceled due to a lack of management commitment or funding. It Is more likely, however, that the project will continue to the next phase-possibly with a reduced business scope.

Define an Information Architecture

Given an understanding of the business mission, you can now develop a plan for information systems that truly mirrors and supports that business mission. The next phase of systems planning is to define an information architecture for information systems.

An Information architecture is a plan for selecting information technology and developing information systems needed to support the business mission. Synonyms include information systems plan and master computing plan.

This architecture phase can take six months or longer to complete.
Once again, this phase Is facilitated by planning analysts. The team also includes the same IS managers and business executives included in the previous planning phase. Additionally, the team should normally include at least one database, networks, and applications management representative -the reason will become apparent in a moment.
The key input to this phase is the business plans from the last phase. Other inputs include existing system details and limitations (from the documentation maintained during the Systems Support phase), facts and opinions (from appropriate system owners and system users), and technology forecasts and opinions (from Information systems management and/or consultants).
These inputs are used to build the information architecture. The key components in an information architecture are:

· A DATA architecture that identifies and prioritizes the databases that need to be developed. These databases should be highly flexible so that they can support several areas of the business. (Note: A data or database manager usually helps define the data architecture.)
· A NETWORK architecture that identifies and prioritizes computer networks that need to be developed. These networks must optimize information systems support at all appropriate business operating locations. (Note: A networks manager usually helps define the network architecture.)
· An ACTIVITIES architecture (more appropriately called an applications architecture) that identifies and prioritizes business areas for which business processes and/or information systems applications must be redesigned. (Note: One or more applications development managers usually help define the applications architecture.)
· A PEOPLE architecture (actually, an IS organization structure) necessary to develop and support the databases, networks, and applications.
· A TECHNOLOGY architecture that identifies the information technologies that should be used for applications, and possibly for applications development. (Note: Information systems management, along with the applications, database, and network managers, usually provides the technology forecast and opinions needed to develop the technology architecture,)

The Information architecture is packaged in the deliverable, information systems plans. These plans will ultimately influence the development and support for all future Information systems. Thus, they must be made available to information systems management, any contracted consultants, and all current and future information systems owners.
Some planning methodologies call for another deliverable, distinct business areas (to be passed on to the next planning phase).

Business areas are groups of logically related business functions and activities, independent of organization structure. The term was Invented as part a planning methodology called information engineering.

This definition requires some clarification. Business areas define major functions of the business, for example, PROCESS AND FILL ORDERS. Several organization units may play a role in any given business area. For example, the processing and filling of orders normally requires activity in at least the following organization units: Sales, Order Processing, Accounts Receivable, Warehousing, and Shipping. Ideally, information systems should be built around the integration of these units' activities as they relate to the common business function-in this case, processing and filling orders.
Business areas are usually prioritized according to their perceived importance and value to the business- The next planning phase deals with one business area at a time (in order of priority).
The planning project could be terminated due to a lack of either funds or management commitment. Even if this happens, you still have the information architecture to guide future systems development. Alternatively, the project can continue to the next phase, business area analysis.

Business Area Analysis

The information architecture is a good high-level IS plan. But some IS shops seek to further refine that plan to define specific systems development projects. Thus, the next phase of systems planning is to evaluate business area(s) to identify and prioritize specific development projects. A project may trigger development of any of the following:

1. A network-subsequent projects would build databases and/or applications around that network.
2. A database-subsequent projects would build applications around that database.
3. An information systems application-which may include building an applications-oriented database or network if a network or database Is not completed first.

Business area analysis (BAA) can be a time-consuming phase that takes six months or longer (per business area) to complete. But many companies are willing to spend that time to ultimately develop highly integrated information systems around their business areas. Because BAA takes so long, most businesses analyze only one or two areas at a time, preferably those identified as most crucial in the strategic information architecture.

Note One challenge facing those organizations that analyze business areas is simply keeping up with application demand. For any given business area, the planing analysts may identify several applications development projects. While Systems analysts and applications programmers tackle those projects, the planning analysts generally move on to another business area, defining still more projects, and so forth. The growth in planned projects can easily exceed resources for those developing the applications. Fortunately, modern systems development technology offers some hope for keeping up with this demand.

Once again, this phase is facilitated by the same planning analysts who facilitated development of the information architecture. Systems analysts who will ultimately develop the applications are also frequently added to the team. Although most executive managers are excused from the phase, all managers in the specific business area must be involved in order to identify the applications
needed and prioritize the projects to develop those applications. Some system users may also become involved.
The key inputs are the Information systems plans and business area(s) from the previous phase. Additionally, the analyst collects facts and opinions from appropriate system owners and system users.
The key deliverable of the phase is planned applications development projects that will eventually be passed onto systems analysis. This deliverable will normally include documentation that can serve as a useful first draft for many systems analysis deliverables. The plan often calls for rather dramatic changes to how the business area will conduct business (fewer people, less bureaucracy, etc.).
There is no feasibility/scope checkpoint at the end of the phase. Why? The planning process has defined and prioritized projects. Only one question re mains: When do we (can we) commit resources to the development of those planned applications?
This completes our survey of the systems planning phases. As a closing note, detailed coverage of systems planning is not generally included in the first systems analysis and design course. At some point it will probably become mandatory.