[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
There are many different systems planning methodologies; however, this relatively
simple approach is representative.
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,
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
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
This architecture phase can take six months or longer
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
· 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
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.
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
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
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
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