A.Y.T.I.: Assignment 4

First, let us define what an Informations Systems Plan is. Because an organization's business strategic plan contains both organizational goals and a broad outline of steps required to reach them, the business strategic plan affects the type of system an organization needs. Deciding which new systems to build should be an essential component of the organizational planning process. Organizations need to develop an information systems plan that supports their overall business plan and in which strategic systems are incorporated into top-level planning. The information systems planning refers to the process of the translation of strategic and organizational goals into systems development plan and initiativesFor example, part of the information systems plan for a luxury car company might be to build a new product tracking system to meet the organizational goal of improving customer service. Proper information systems planning ensures that specific systems development objectives support organizational goals. One of the primary benefits of information systems planning is that it provides a long-range view of information technology use in the organization. The information systems plan provides guidance on how the information systems infrastructure of the organization should be developed over time. The plan serves as a road map indicating the direction and rationale of systems development. Another benefit of information systems planning is that it ensures better use of information systems resources, including funds, information systems personnel, and time for scheduling specific projects. Overall objectives of information systems are usually distilled from the relevant aspects of the organization's business strategic plan. Information systems projects can be identified either directly from the objectives determined in the first step or may be identified by others, such as managers within the various functional areas. Setting priorities and selecting projects typically requires the involvement and approval of senior management. Once specific projects have been selected within the overall context of a strategic plan for the business and the systems area, an information systems plan can be developed. The plan contains a statement of organizational goals, identifies the project objectives, and specifies how information technology supports the attainment of the organizational goals. When objectives are set, planners consider the resources necessary to complete the projects including equipment (computers, network servers, printers, and other equipment and devices), software, employees (systems analysts, programmers, users and others), expert advice (specialists and other consultants), and so on. The information systems plan lays out specific target dates and milestones that can be used later to monitor the plan’s progress in terms of how many objectives were actually attained in the time frame specified in the plan. The plan also includes the key management decisions concerning hardware acquisition; structure of authority, data, and hardware; telecommunications; and required organizational change. Organizational changes are usually described, including management and employee training requirements; recruiting efforts; changes in business processes; and changes in authority, structure, or management practice. As part of translating the corporate strategic plan into the information systems plan, many companies seek systems development project that will provide a competitive advantage. This usually requires creative and critical analysis. Creative analysis involves the investigation of new approaches to existing problems. By looking at problems in new or different ways and by introducing innovative methods to solve them, many firms have gained a competitive advantage. Typically, these new solutions are inspired by people and things not directly related to the problem. Critical analysis requires unbiased and careful questioning of whether system elements are related in the most effective or efficient ways. It involves considering the establishment of new or different relationships among system elements and perhaps introducing new elements into the system. The impact a particular system has on an organization's ability to meet its goals determines the true value of that system to the organization. While all systems should support business goals, some systems are more pivotal in continued operations and goal attainment than others. These systems are called mission-critical systems. An order processing TPS, for example, is usually considered mission-critical. Without it, few organizations could continue daily activities, and they clearly would not meet the goals. The goals defined for an organization will in turn define the objectives set for a system. A manufacturing plant, for example, might determine that minimizing the total cost of owning and operating its equipment is a critical success factor (CSF) in meeting a production volume and profit goals. This CSF would be converted into specific objectives for a proposed plant equipment maintenance system. One specific objective might be to alert maintenance planner when a piece of equipment is due for routine preventive maintenance (e.g., cleaning and lubrication). Another objective might be to alert the maintenance planners when the necessary cleaning materials, lubrication oils, or spare parts inventory levels are below specified limits. These objectives could be accomplished either through automatic stock replenishment via electronic data interchange or through the use of exception reports. Regardless of the particular system development effort, the development process should define a system with specific performance and cost objectives. The success or failure of the systems development effort will be measured against these objectives. Performance objectives measure the extent to which a system performs as desired. Is the system generating the right information for a value-added business process? Is the output generated in a form that is usable and easily understood? Is the system generating output in time to meet organizational goals and operational objectives? Cost objectives attempt to balance the benefits of achieving performance goals with all costs associated with the system. Balancing performance and cost objectives within the overall framework of organizational goals can be challenging. Systems development objectives are important, however, in that they allow an organization to effectively and efficiently allocate resources and measure the success of a systems development effort. In order to develop an effective information systems plan, the organization must have a clear understanding of both its long- and short-term information requirements. Two principal methodologies for establishing the essential information requirements of the organization as a whole are enterprise analysis and critical success factors. Enterprise analysis argues that the firm's information requirements can only be understood by looking at the entire organization in terms of organizational units, functions, processes, and data elements. Enterprise analysis can help identify the key entities and attributes of the organization's data. The central method used in the enterprise analysis approach is to take a large sample of managers and ask them how they use information, where they get the information, what their environments are like, what their objectives are, how they make decisions, and what their data needs are. The results of this large survey of managers are aggregated into subunits, functions, processes, and data matrices. Data elements are organized into logical application groups--groups of data elements that support related sets of organizational processes. The weakness of enterprise analysis is that it produces an enormous amount of data that is expensive to collect and difficult to analyze. Most of the interviews are conducted with senior or middle managers, but there is little effort to collect information from clerical workers and supervisory managers. Moreover, the questions frequently focus not on management's critical objectives and where information is needed but rather on what existing information is used. The result is a tendency to automate whatever exists. But in many instances, entirely new approaches to how business is conducted are needed, and these needs are not addressed. The strategic analysis or critical success factors approach argues that an organization's information requirements are determined by a small number of critical success factors (CSFs) of managers. If these goals can be attained, the firm's or organization's success is assured. CSFs are shaped by the industry, the firm, then manager, and the broader environment. An important premise of the strategic analysis approach is that there are a small number of objectives that managers can easily identify and on which information systems can focus. The strength of the CSF method is that it produces a smaller data set to analyze than does enterprise analysis. The CSF method takes into account the changing environment with which organizations and managers must deal. This method explicitly asks managers to look at the environment and consider how their analysis of it shapes their information needs. Unlike enterprise analysis, the CSF method focuses organizational attention on how information should be handled. The method's primary weakness is that the aggregation process and the analysis of the data are art forms. There is no particularly rigorous way in which individual CSFs can be aggregated into a clear company pattern. Second, there is often confusion among interviewees (and interviewers) between individual and organizational CSFs. They are not necessarily the same. What can be critical to a manager may not be important for the organization. Moreover, this method is clearly biased toward top managers because they are generally the only ones interviewed.

Strategic information systems planning is a disciplined, systematic approach to determining the most effective and efficient means of satisfying organizational information needs. It is a top-down, structured approach which, to be successful, must employ technical and managerial processes in a systems engineering context. Under this approach, the characteristics of the system’s hardware, software, facilities, data, and personnel are identified and defined through detailed design and analysis to achieve the most cost-effective system for satisfying the organization’s needs. The process must consider system life cycle management and the organization’s policy and budget as important integral factors, and include all organizational participants (e.g., managers, users, maintainers, operators, and designers) throughout the process. It is an iterative process in that changes identified during the process must be evaluated to determine their effect on completed analyses. Strategic information systems planning is not a one-time event-it should be revisited periodically to ensure a system’s continued viability in meeting information needs and achieving long-term missions.

For a long time relationship between information system functions and corporate strategy

was not of much interest to Top Management of firms. Information Systems were thought to be

synonymous with corporate data processing and treated as some back-room operation in support of

day-to-day mundane tasks. In the 80’s and 90’s, however, there has been a

growing realization of the need to make information systems of strategic importance to an

organization. Consequently, strategic information systems planning (SISP) is a critical issue. In

many industry surveys, improved SISP is often mentioned as the most serious challenge facing IS

managers

Planning for information systems, as for any other system, begins with the identification of

needs. In order to be effective, development of any type of computer-based system should be a

response to need--whether at the transaction processing level or at the more complex information and

support systems levels. Such planning for information systems is much like strategic planning in

management. Objectives, priorities, and authorization for information systems projects need to be

formalized. The systems development plan should identify specific projects slated for the future,

priorities for each project and for resources, general procedures, and constraints for each application

area. The plan must be specific enough to enable understanding of each application and to know

where it stands in the order of development. Also the plan should be flexible so that priorities can be

adjusted if necessary. King in his recent article has argued that a strategic capability

architecture - a flexible and continuously improving infrastructure of organizational capabilities - is

the primary basis for a company's sustainable competitive advantage. He has emphasized the need

for continuously updating and improving the strategic capabilities architecture.

SISP is the analysis of a corporation’s information and processes using business information

models together with the evaluation of risk, current needs and requirements. The result is an action

plan showing the desired course of events necessary to align information use and needs with the

strategic direction of the company The same article emphasizes the need to note

that SISP is a management function and not a technical one. This is consistent with the earlier

distinction between the older data processing views and the modern strategic importance view of

Information Systems. SISP thus is used to identify the best targets for purchasing and installing

new management information systems and help an organization maximize the return on its

information technology investment. A portfolio of computer-based applications is identified that will

assist an organization in executing its business plans and realize its business goals. There is a

growing realization that the application of information technology (IT) to a firm’s strategic activities

has been one of the most common and effective ways to improve business performance.

WHAT IS SISP METHODOLOGY?

Methodology is generally a guideline for solving a problem, with specific components such as

phases, tasks, methods, techniques and tools [17, 10]. Methodology benefits managers by

providing information to plan, review and control projects. Generally methodologies are

comprised of the following four elements: providing an opinion of what needs to be solved,

defining techniques on what has to be done and when to do it, advising on how to manage the

quality of deliverables or products, as well as providing a toolkit to facilitate the process [17].

An SISP methodology can be viewed as an abstract system design that functions to transform

organizational inputs (such as business strategy, assessment of current IS environment, and

organizational influence) into an IS Strategic Plan as an output. When executing the SISP

process, the abstract system design is applied in the context of multiple human activity systems

(HAS) involving the SISP stakeholders (developers and clients) [10].

SISP methodologies can be categorized into two categories; namely, general and specific-tocontext

methodologies. Three contexts were analyzed in the latter category; namely, business

context, government context and educational context (Table 1). While there are numerous SISP

methodologies, approaches and frameworks, the majority is oriented for commercial and

production-based organizations, and is not suitable to guide SISP formulation in service-oriented

industries and government [17]. The business strategy model and a university strategy model are

different in terms of time frame, consensus, value system, customers and context [12]. Thus,

business-context SISP methodologies are not suitable to guide SISP formulation in public

educational institutions and government agencies because they focus primarily on the alignment

of ICT strategies to the business objective of profits and competition. Government agencies and

PIHLs focus on the formulation of ICT strategies to improve service delivery to the citizen and

nation rather than profitability and competition [1,9,13].

Although many SISP methodologies provide an overview of how to develop an SISP, the

methods, techniques and tools to guide the SISP formulation process are not specified. The SISP

initiation approach, the SISP team, and the set of tasks, activities and tools are not suited to the

educational institution environment [9]. Thus, the primary objective of the ISP-IPTA

Methodology design was to document objectives and tasks in every phase, as well as the

methods and techniques that can be used to implement the tasks. The methods and techniques are

complimented by an automated toolkit that that can facilitate the SISP formulation process [16].

Information systems are important tools for effectively meeting organizational objectives. Readily available, complete, and accurate information is essential for making informed and timely decisions. Being unable to obtain needed data, wading through unneeded data, or inefficiently processing needed data wastes resources. The organization must identify its information needs on the basis of a systematic identification and analysis of its mission and functions to be performed, who is to perform them, the information and supporting data needed to perform the functions, and the processes needed to most usefully structure the information. Successful information system development and acquisition must include a rigorous and disciplined process of data gathering, evaluation, and analysis prior to committing significant financial and human resources to any information system development. While implementing such an approach may not preclude all information system acquisition problems, it should produce detailed knowledge of organizational missions and operations, user information needs and alternatives to address those needs, and an open and flexible architecture that is expandable or that can be upgraded to meet future needs.

The purpose and use of information system in the beginning was targeted towards reducing manual labor and increasing efficiency and thus reducing cost of doing business. Cost has thus been the ‘primal instinct’ justification for the usage of Information system in companies. Management seems to still use this justification even in today’s day and age because the IT salesman still thinks it’s the best and only way to get management buy-in. Moreover, as most other rationales used for IS have proved hard to sell, both the IT sales teams and their customers find a comfort zone in cost savings. This could also be because both sides (from all their previous experiences) are convinced of their failure before they even start out on a different track. The past experiences, in most cases were times they tried, half heartedly probably, without enough experience and failed. These failures have resulted in the baby being thrown out along with the dirty water.

Systems are usually laid out at different levels. The lowest rung in the ladder is taken by the TRANSACTIONAL information system. These are ones like ‘Pont Of Sales’ systems used in the store counters, or book keeping systems mentioned earlier. These are systems targeting cost reduction, capturing repetitive activities and assisting the human using it to become more efficient in handling larger volumes of transactions.

The OPERATIONAL or operation support systems are usually build combining several Transactional systems in a logical sequence so as to make the operation of any particular division/functional group more efficient. Classic example is the integration of Accounting, Payroll, HR, and Inventory, Production etc. to form a MRP or ERP system. Or POS, Customer Account Info, Accounting, etc. linked together to form a CRM system. A very critical component for operational systems is their reporting systems. They provide the reports that combine and merge the reports/information from several transactional systems to provide reports to help executives manage operations in a synchronized and optimized manner. Thus, they act as enablers and help managers to keep track of various parameters so as to keep the whole operation smooth and efficient.

STRATEGIC systems are little more complicated. They cross the regular operational boundaries and become tools that form the basis for senior management to plan, execute and monitor the organization. They help in keeping track of the Key Performance Indicators by combining and logically sorting information from various Operational and Transactional systems all across the company and at times combining it with external information from sources like the stock market, industry sources, partners and even competitors. Designing STRATEGIC information system requires a thought process of a ‘good’ CEO with an understanding of the business from the top, various information sources present in the company and outside in platforms that need to be collated, combined and extracted into a tool to help run the company in a more informed and responsive manner.

Characteristics of a Quality ISP

A quality ISP must exhibit five distinct characteristics before it is useful.

Timely- The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.

Useable- The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.

Maintainable- The ISP must be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.

Quality- While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.

Reproducible- The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.

The ISP Steps

The information systems plan project determines the sequence for implementing specific information systems. The goal of the strategy is to deliver the most valuable business information at the earliest time possible in the most cost-effective manner.

The end product of the information systems project is an information systems plan (ISP). Once deployed, the information systems department can implement the plan with confidence that they are doing the correct information systems project at the right time and in the right sequence. The focus of the ISP is not one information system but the entire suite of information systems for the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.

1. Create the mission model- The mission model, generally shorter than 30 pages presents end-result characterizations of the essential raison d=etre of the enterprise. Missions are strategic, long range, and a-political because they are stripped of the Awho and the Ahow.

2. Develop a high-level data model- The high-level data model is an Entity Relationship diagram created to meet the data needs of the mission descriptions. No attributes or keys are created.

3. Create the resource life cycles (RLC) and their nodes- Resources are drawn from both the mission descriptions and the high level data model. Resources and their life cycles are the names, descriptions and life cycles of the critical assets of the enterprise, which, when exercised achieve one or more aspect of the missions. Each enterprise resource Alives through its resource life cycle.

4. Allocate precedence vectors among RLC nodes- Tied together into a enablement network, the resulting resource life cycle network forms a framework of enterprise=s assets that represent an order and set of inter-resource relationships. The enterprise Alives through its resource life cycle network.

5. Allocate existing information systems and databases to the RLC nodes- The resource life cycle network presents a Alattice-work onto which the Aas is business information systems and databases can be Aattached. The Ato-be databases and information systems are similarly attached. ADifference projects@ between the Aas-is and the Ato-be are then formulated. Achievement of all the difference projects is the achievement of the Information Systems Plan.

6. Allocate standard work break down structures (WBS) to each RLC node- Detailed planning of the Adifference projects entails allocating the appropriate canned work breakdown structures and metrics. Employing WBS and metrics from a comprehensive methodology supports project management standardization, repeatability, and self-learning.

7. Load resources into each WBS node- Once the resources are determined, these are loaded into the project management meta entities of the meta data repository, that is, metrics, project, work plan and deliverables.

8. Schedule the RLC nodes through a project management package facilities- The entire suite of projects is then scheduled on an enterprise-wide basis. The PERT chart used by project management is the APERT@ chart represented by the Resource Life Cycle enablement network.

9. Produce and review of the ISP- The scheduled result is predicable: Too long, too costly, and too ambitious. At that point, the real work starts: paring down the suite of projects to a realistic set within time and budget. Because of the meta data environment, the integrated project management meta data, and because all projects are configured against fundamental business-rationale based designs, the results of the inevitable trade-offs can be set against business basics. Although the process is painful, the results can be justified and rationalized.

10. Execute and adjust the ISP through time- As the ISP is set into execution, technology changes occur that affect resource loadings. In this case, only steps 6-9 need to be repeated. As work progresses, the underlying meta data built or used in steps 1-5 will also change. Because a quality ISP is Aautomated at the recasting of the ISP should only take a week or less.

IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.

In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. Figure 3 illustrates the continuous flow process environment that supports releases. The continuous flow process environment is characterized by:

Multiple, concurrent, but differently scheduled projects against the same enterprise resource

Single projects that affect multiple enterprise resources

Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources

It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.

There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:

Need Identification
Need Assessment
Design
Deployment

Here are some steps on how to implement an Information System:

Preparation

Before you begin to implement the procedures described in this guide, you already should have prepared your institution for the analysis.1 As a result of your preparation, you should have clearly defined your goals and objectives for the new IS.

Goals

Goal-setting ideally involves establishing specific, measurable, attainable, realistic and time-targeted objectives. Work on the theory of goal-setting suggests that it can serve as an effective tool for making progress by ensuring that participants have a clear awareness of what they must do to achieve or help achieve an objective. On a personal level, the process of setting goals allows people to specify and then work towards their own objectives — most commonly financial or career-based goals. Goal-setting comprises a major component of Personal development.

Personal goals

Individuals can set personal goals. A student may set a goal of a high mark in an exam. An athlete might walk five miles a day. A traveler might try to reach a destination-city within three hours. Financial goals are a common example, to save for retirement or to save for a purchase.

Managing goals can give returns in all areas of personal life. Knowing precisely what one wants to achieve makes clear what to concentrate and improve on, and often subconsciously prioritizes that goal.
Goal setting and planning ("goalwork") promotes long-term vision and short-term motivation. It focuses intention, desire, acquisition of knowledge, and helps to organize resources.
Efficient goalwork includes recognizing and resolving any guilt, inner conflict or limiting belief that might cause one to sabotage one's efforts. By setting clearly-defined goals, one can subsequently measure and take pride in the achievement of those goals. One can see progress in what might have seemed a long, perhaps impossible, grind.

Goal management in organizations

Organizationally, goal management consists of the process of recognizing or inferring goals of individual team-members, abandoning no longer relevant goals, identifying and resolving conflicts among goals, and prioritizing goals consistently for optimal team-collaboration and effective operations.
For any successful commercial system, it means deriving profits by making the best quality of goods or the best quality of services available to the end-user (customer) at the best possible cost. Goal management includes:
• Assessment and dissolution of non-rational blocks to success
• Time management
• Frequent reconsideration (consistency checks)
• Feasibility checks
• Adjusting milestones and main-goal targets

Morten Lind and J.Rasmussen distinguish three fundamental categories of goals related to technological system management:

1. Production goal
2. Safety goal
3. Economy goal

An organizational goal-management solution ensures that individual employee goals and objectives align with the vision and strategic goals of the entire organization. Goal-management provides organizations with a mechanism to effectively communicate corporate goals and strategic objectives to each person across the entire organization. The key consists of having it all emanate from a pivotal source and providing each person with a clear, consistent organizational-goal message. With goal-management, every employee understands how their efforts contribute to an enterprise's success.

An example of goal types in business management:

• Consumer goals: this refers to supplying a product or service that the market/consumer wants
• Product goals: this refers to supplying a product outstanding compared to other products, perhaps due to the likes of quality, design, reliability and novelty
• Operational goals: this refers to running the organization in such a way as to make the best use of management skills, technology and resources
• Secondary goals: this refers to goals which an organization does not regard as priorities

Objectives

A goal or objective is a projected state of affairs that a person or a system plans or intends to achieve—a personal or organizational desired end-point in some sort of assumed development. Many people endeavor to reach goals within a finite time by setting deadlines.
A desire or an intention becomes a goal if and only if one activates an action for achieving it (see goal-oriented).
It is roughly similar to purpose or aim, the anticipated result which guides action, or an end, which is an object, either a physical object or an abstract object, that has intrinsic value.

You also should have the following elements in place (or concrete plans to establish them) before you select and install a new computerized system:

• Current business plan.
• Annual operating budget, including expenditures for IS.
• Preliminary cash flow analyses to determine the financial feasibility of the new system.
• Formalized policies and practices, updated as appropriate.
• Comprehensive system of internal controls, with plans to adapt it to the new information system.
• Complete and accurate historical records.
• Adequate infrastructure, or plans to upgrade the infrastructure.
• Computer-literate personnel, or plans to enhance staff capabilities.

The manner and extent to which you have implemented each element depends, in part, on the size of your institution and the resources that are available to you — but hopefully you have not ignored any of them. The work you do to enhance these aspects of your operations lays the vital groundwork for your needs analysis.

What is a need analysis?

Perhaps surprisingly, the right IS for your institution isn’t necessarily the one that offers the most features — or even the one that offers the most features at the lowest cost. Instead, it is the system that offers the features that you need and want — now and in the foreseeable future — at a justifiable cost.
Of course, this definition implies that you have a comprehensive and detailed understanding of your needs and wants, and the ability to distinguish between the two. (From the perspective of your institution, needs are essential attributes in any new system; wants are desired-but-not-absolutely-necessary features.) The process required to develop and document this understanding is referred to as a needs analysis. The needs analysis process generates a comprehensive list or report of your needs and wants, with a priority assigned to each item.

Inevitably, as with any other asset acquisition, you will have to make tradeoffs in designing your IS. Given unlimited time and funds, you could create an IS that matches all of your needs and wants exactly. But most institutions do not have unlimited resources. Instead, they must assemble and prioritize their requirements. Your needs analysis report assists you in making such tradeoffs by providing a framework for evaluating possible systems and for a cost-benefit analysis. A needs analysis also provides the software selection process with important transparency. Alternatively, if you decide to develop custom software, it is the basis for creating functional specifications.

Equally important, the needs analysis helps you to establish realistic expectations for your new system, and enhances your communications with potential consultants, service providers, software vendors and software developers.
The preparation of the needs analysis often gives managers important new insights into the dynamics of the institution’s operations. As an additional benefit, the process affords your IS implementation staff an opportunity to develop a positive working relationship with the new system’s users, thereby helping to cultivate a broad endorsement for the new system as well as a sense of common ownership.

Who conduct this needs analysis?

A needs analysis is a participatory process — one that functions best when it draws upon the knowledge and experience of key management and of staff throughout the institution.
By incorporating a broad range of perspectives into the process, you ensure that your analysis is comprehensive and accurate, thereby increasing the likelihood that you will achieve your information-management objectives. If your analysis is simply assigned to a consultant or a few staff members, the chance of achieving your goals for the new IS decreases dramatically.

Reflecting the participatory nature of the process, you should create a needs analysis team and appoint a team leader. Often, these same people also will participate in the selection and implementation of the new system (through a longer-term IS team or IS task force). In other cases, the composition of the team varies somewhat over time — for example, you might emphasize operations people during the needs analysis and include more technical people for selection and implementation. Such variations in team composition can reduce the workload for team members.
Ultimately, the role of the needs analysis team is advisory. The team provides critical information for the decision-making process and, generally, a final recommendation. It does not, however, make the final information-system decision. That decision is made (or ratified) by the institution’s top management and board of directors.

Selecting a team member

Before you begin to develop the project plan for your needs analysis, an initial team must be assembled from among your institution’s staff.Ideally, each member of your team should possess one or more of the following skills and capabilities.

Detailed understanding of your own organization’s specific practices at even the most hands-on levels, with each major function represented.
• Oral and written communications skills.
• Interpersonal and listening skills.
• Project management skills.

Taken together, the team should possess all of the above skill sets, which means it should consist of at least four or five members. If necessary, you can include consultants to supplement your in-house expertise — in computer hardware and software, for example. However, you generally should not include more than 10 or 12 members, as the size of the team becomes unwieldy and difficult to manage.

This needs analysis team develops the work plan, and then conducts the needs analysis after the plan is approved. Depending on the details of the plan you develop, you might find it necessary to supplement the team’s initial membership with additional members with specific skill sets or new skills.

Although team members can complete specific needs analysis tasks individually or in small groups — reflecting each member’s specific area of expertise — the entire team should hold regular meetings throughout the analysis process. These meetings might extend from weeks up to several months, if necessary, culminating in the production of a final needs analysis report.

To operate effectively, team members must be given access to the resources and key personnel necessary to complete their assignments. To accommodate the new workload borne by the team members, it is generally necessary to temporarily reduce their regular duties, change performance criteria, and/or delay deadliness.
Often, team members also are provided with positive incentives to complete their needs analysis responsibilities in a comprehensive and timely fashion.

Selecting a team leader

Selection of the right team leader — sometimes also referred to as a project champion — is critical. Change can be a frightening thing, but managing it well is necessary for the future of any institution.
Ultimately, the team leader manages change. She (or he) champions the IS project within and outside of the institution, provides guidance and encouragement, updates management and generates their buy-in, resolves conflicts, and creates consensus.

The leader also wields considerable power and authority to marshal resources and resolve administrative roadblocks.
The person assigned to this leadership role should be a creative thinker with good people skills and a vision for the future. The team leader also should possess basic management and project management skills, although many of the ongoing project management tasks can be assigned to other team members.

How do you plan your needs analysis?

At its core, your needs analysis is a project in the traditional sense of the word.2 Therefore, it can be conducted according to established best practices for project management. By adopting such an approach, you significantly increase your chances of achieving your objectives, while enhancing the efficiency and quality of your analysis process. In fact, research demonstrates that, for every hour you spend planning a project, you save at least 20 hours in its implementation.

Using a typical project management framework, you approach a project in terms of stages, or phases, similar to the following:

• The launch phase seeks authorization for the project, in part by creating feasibility and cost-benefit analyses.
• The planning phase establishes the project’s overall goals and objectives, scope, deliverables, and required resources, (e.g., team members, consultants, and anticipated expenditures), as well as the initial plan and schedule.
• The implementation/performance phase conducts the work necessary to create the desired product or service, including all defined deliverables
• The monitoring/controlling phase guides the work during the performance phase, and is generally implemented simultaneously with this phase
• The wrap-up phase verifies deliverables, pays final expenses and considers lessons learned

For the most part, this guide describes the needs analysis process in the context of these project management phases, with an emphasis on planning and implementation. It also describes and provides examples of basic project management tools and techniques.

Because your needs analysis is a relatively simple project by project management standards, the guide does not include an extensive discussion of project management activities that might be more appropriate for larger and more complex projects. You should not lose your focus on the needs analysis itself by overcomplicating the project management aspects.
As described in this guide, the planning process for your needs analysis includes the following steps:
• Establish the project’s goal and objectives.
• Define the scope by creating an outline of the main elements of the project — sometimes referred to as a work breakdown structure.
Create the project plan including:
• List of the major tasks required.
• Templates, or scripts, to guide the work for these tasks.
• Time and staffing budgets.
• Initial schedule or time line.
• Work packets for the team.
• Define the project deliverables.

If you lack experience in developing and managing project plans, even these basic project management activities can be a bit time-consuming. To minimize the time and effort required, this guide provides samples, optional templates and other tools that you can use or customize as you find appropriate.

Establishing Goals and Objectives

Your project goal is a relatively simple, brief mission statement that answers the question, What do you intend to accomplish by performing the needs analysis? It communicates your purpose. For example:
“To develop a comprehensive needs analysis that provides a framework for our transition from manual to computer-based information system.”
Your objectives supplement your stated goal, providing additional detail that is generally less abstract and often quantifiable. For example:
“Complete the needs analysis project for our accounting, lending and savings functions within three months, commencing 15 May.”
“Control expenditures for consultant fees, travel and other project-related expenditures based on the amount allocated for these purposes in the current annual budget.”
In addition to the project goals and objectives, you should have determined the goal and the objectives for your new IS.

Determining the Project’s Scope

The process for analyzing your IS needs is essentially a modular one. As described in this guide, it focuses on specific business-function modules.6 This modular approach helps you organize and manage your analysis, and to assign specific duties to individual team members.

Before you can develop a project plan and then proceed with your analysis, you must first establish the scope of your project. This requires you to think strategically, and then make an initial determination as to the business functions that you actually intend to automate — as well as whether your need for each is immediate or future.
Often, this scope decision already has been made as a result of an MFI’s business planning process. If not, make an initial determination for the purposes of the needs analysis — you can always refine your selections later.
The final decision regarding the business functions to be automated is usually made by top management and the board of directors, based at least in part on input from the needs analysis team. Budgetary constraints are also an important consideration. In conducting your needs analysis, you should only analyze the business functions that you intend to automate within a reasonable period of time, such as the next two or three years.

How do you conduct your needs analysis?

In conducting a needs analysis, you analyze and prioritize important aspects of your institution’s business operations — including information flows, internal controls, and detailed practices and procedures.
If you have adequately prepared your institution for this analysis, as described in Guide 1, you already have evaluated certain major aspects of your business practices and reengineered them as necessary. Your needs analysis takes that process a step further in terms of detail. As you analyze the detailed practices involved in your business processes, you also might find opportunities for small improvements or fairly minor reengineering.

Analyzing Your Requirements

Your project plan and WBS provide a road map for analyzing your current and anticipated IS requirements. For each task in the plan (i.e., each business function and activity that your institution intends to automate), you research and document a number of business practices that impact the design of your future IS.

Analysis Method

To conduct your analysis, you and the other members of the analysis team perform the tasks as outlined in each work template. The elements in the template represent potential IS requirements for your institution. Taken together, they describe the IS features necessary to automate your institution’s business operations.
Without a work template, you have no assurance that your needs analysis addresses the range of issues that are critical to successfully describing your IS requirements. In other words, a template reduces the risk of an incomplete analysis.

However, it should not restrict your ability to analyze and document additional requirements or business practices if you uncover them in the process of conducting the analysis. Consider the template a working document that can be adapted as necessary or appropriate.

As you conduct your analysis, explore each element as comprehensively or as minimally as appropriate for your unique situation, but give them all careful consideration. If you develop your own IS, the resulting needs analysis is the starting point for developing functional specifications. If you purchase an off-the-shelf IS, the analysis provides the framework for evaluating your available options and for specifying any necessary customizations.

You could employ any or all of the following techniques to gather required information:
Personal knowledge and expertise.

• Surveys and interviews with management and staff.
• A review of all existing policy and procedural manuals.
• A review of research and other materials generated by your business planning process.
• Flowcharts of business processes.14
• Business walkthroughs, where you follow a process through from start to finish.
• An analysis of your existing IS — whether manual or computerized — including any known limitations, inefficiencies or other serious problems relative to your current and future requirements.

Recordkeeping Options

While working through the needs analysis process, your team must maintain a written record of its findings as well as the work papers it generates. This creates institutional memory. To the extent that information is located only in the minds of team members, rather than on paper, your project risk increases. If a team member changes jobs or becomes ill, for example, you stand to lose critical information. In a worst-case scenario, you might have to repeat completed portions of the analysis.
While the work template guides your analysis, it might not provide a sufficiently comprehensive mechanism for recording all of your findings. You can supplement it using any of the approaches described below, or any other that you prefer.

Regardless of the approach you choose, your team members should save all of their rough notes and other working documents to support the analysis results.

Ten key principles to ensure that information management activities are effective and successful:
1. recognise (and manage) complexity
2. focus on adoption
3. deliver tangible & visible benefits
4. prioritise according to business needs
5. take a journey of a thousand steps
6. provide strong leadership
7. mitigate risks
8. communicate extensively
9. aim to deliver a seamless user experience
10. choose the first project very carefully

Principle 1: recognise (and manage) complexity

Organisations are very complex environments in which to deliver concrete solutions. As outlined above, there are many challenges that need to be overcome when planning and implementing information management projects.
When confronted with this complexity, project teams often fall back upon approaches such as:
• Focusing on deploying just one technology in isolation.
• Purchasing a very large suite of applications from a single vendor, in the hope that this can be used to solve all information management problems at once.
• Rolling out rigid, standardised solutions across a whole organisation, even though individual business areas may have different needs.
• Forcing the use of a single technology system in all cases, regardless of whether it is an appropriate solution.
• Purchasing a product ‘for life’, even though business requirements will change over time.
• Fully centralising information management activities, to ensure that every activity is tightly controlled.

All of these approaches will fail, as they are attempting to convert a complex set of needs and problems into simple (even simplistic) solutions. The hope is that the complexity can be limited or avoided when planning and deploying solutions.

In practice, however, there is no way of avoiding the inherent complexities within organisations. New approaches to information management must therefore be found that recognise (and manage) this complexity.
Organisations must stop looking for simple approaches, and must stop believing vendors when they offer ’silver bullet’ technology solutions.

Instead, successful information management is underpinned by strong leadership that defines a clear direction (principle 6). Many small activities should then be planned to address in parallel the many needs and issues (principle 5).
Risks must then be identified and mitigated throughout the project (principle 7), to ensure that organisational complexities do not prevent the delivery of effective solutions. Information systems are only successful if they are used

Principle 2: focus on adoption

Information management systems are only successful if they are actually used by staff, and it is not sufficient to simply focus on installing the software centrally.
In practice, most information management systems need the active participation of staff throughout the organisation.
For example:

• Staff must save all key files into the document/records management system.
• Decentralised authors must use the content management system to regularly update the intranet.
• Lecturers must use the learning content management system to deliver e-learning packages to their students.
• Front-line staff must capture call details in the customer relationship management system.

In all these cases, the challenge is to gain sufficient adoption to ensure that required information is captured in the system. Without a critical mass of usage, corporate repositories will not contain enough information to be useful.
This presents a considerable change management challenge for information management projects. In practice, it means that projects must be carefully designed from the outset to ensure that sufficient adoption is gained.
This may include:

• Identifying the ‘what’s in it for me’ factors for end users of the system.
• Communicating clearly to all staff the purpose and benefits of the project.
• Carefully targeting initial projects to build momentum for the project (see principle 10).
• Conducting extensive change management and cultural change activities throughout the project.
• Ensuring that the systems that are deployed are useful and usable for staff.
These are just a few of the possible approaches, and they demonstrate the wide implications of needing to gain adoption by staff. It is not enough to deliver ‘behind the scenes’ fixes

Principle 3: deliver tangible & visible benefits

It is not enough to simply improve the management of information ‘behind the scenes’. While this will deliver real benefits, it will not drive the required cultural changes, or assist with gaining adoption by staff (principle 2).
In many cases, information management projects initially focus on improving the productivity of publishers or information managers.

While these are valuable projects, they are invisible to the rest of the organisation. When challenged, it can be hard to demonstrate the return on investment of these projects, and they do little to assist project teams to gain further funding.

Instead, information management projects must always be designed so that they deliver tangible and visible benefits.
Delivering tangible benefits involves identifying concrete business needs that must be met (principle 4). This allows meaningful measurement of the impact of the projects on the operation of the organisation.

The projects should also target issues or needs that are very visible within the organisation. When solutions are delivered, the improvement should be obvious, and widely promoted throughout the organisation.
For example, improving the information available to call centre staff can have a very visible and tangible impact on customer service.
In contrast, creating a standard taxonomy for classifying information across systems is hard to quantify and rarely visible to general staff.

This is not to say that ‘behind the scenes’ improvements are not required, but rather that they should always be partnered with changes that deliver more visible benefits.

This also has a major impact on the choice of the initial activities conducted (principle 10).
Tackle the most urgent business needs first

Principle 4: prioritise according to business needs

It can be difficult to know where to start when planning information management projects.

While some organisations attempt to prioritise projects according to the ’simplicity’ of the technology to be deployed, this is not a meaningful approach. In particular, this often doesn’t deliver short-term benefits that are tangible and visible (principle 3).

Instead of this technology-driven approach, the planning process should be turned around entirely, to drive projects based on their ability to address business needs.
In this way, information management projects are targeted at the most urgent business needs or issues. These in turn are derived from the overall business strategy and direction for the organisation as a whole.

For example, the rate of errors in home loan applications might be identified as a strategic issue for the organisation. A new system might therefore be put in place (along with other activities) to better manage the information that supports the processing of these applications.

Alternatively, a new call centre might be in the process of being planned. Information management activities can be put in place to support the establishment of the new call centre, and the training of new staff.
Avoid ’silver bullet’ solutions that promise to fix everything

Principle 5: take a journey of a thousand steps

There is no single application or project that will address and resolve all the information management problems of an organisation.

Where organisations look for such solutions, large and costly strategic plans are developed. Assuming the results of this strategic planning are actually delivered (which they often aren’t), they usually describe a long-term vision but give few clear directions for immediate actions.

In practice, anyone looking to design the complete information management solution will be trapped by ‘analysis paralysis’: the inability to escape the planning process.

Organisations are simply too complex to consider all the factors when developing strategies or planning activities.
The answer is to let go of the desire for a perfectly planned approach. Instead, project teams should take a ‘journey of a thousand steps’.

This approach recognises that there are hundreds (or thousands) of often small changes that are needed to improve the information management practices across an organisation. These changes will often be implemented in parallel.
While some of these changes are organisation-wide, most are actually implemented at business unit (or even team) level. When added up over time, these numerous small changes have a major impact on the organisation.
This is a very different approach to that typically taken in organisations, and it replaces a single large (centralised) project with many individual initiatives conducted by multiple teams.

While this can be challenging to coordinate and manage, this ‘thousand steps’ approach recognises the inherent complexity of organisations (principle 1) and is a very effective way of mitigating risks (principle 7).

It also ensures that ‘quick wins’ can be delivered early on (principle 3), and allows solutions to be targeted to individual business needs (principle 4).
Successful projects require strong leadership

Principle 6: provide strong leadership

Successful information management is about organisational and cultural change, and this can only be achieved through strong leadership.

The starting point is to create a clear vision of the desired outcomes of the information management strategy. This will describe how the organisation will operate, more than just describing how the information systems themselves will work.

Effort must then be put into generating a sufficient sense of urgency to drive the deployment and adoption of new systems and processes.

Stakeholders must also be engaged and involved in the project, to ensure that there is support at all levels in the organisation.

This focus on leadership then underpins a range of communications activities (principle that ensure that the organisation has a clear understanding of the projects and the benefits they will deliver.
When projects are solely driven by the acquisition and deployment of new technology solutions, this leadership is often lacking. Without the engagement and support of key stakeholder outside the IT area, these projects often have little impact.
Apply good risk management to ensure success

Principle 7: mitigate risks

Due to the inherent complexity of the environment within organisations (principle 1), there are many risks in implementing information management solutions. These risks include:
• selecting an inappropriate technology solution
• time and budget overruns
• changing business requirements
• technical issues, particularly relating to integrating systems
• failure to gain adoption by staff

At the outset of planning an information management strategy, the risks should be clearly identified. An approach must then be identified for each risk, either avoiding or mitigating the risk.

Risk management approaches should then be used to plan all aspects of the project, including the activities conducted and the budget spent.

For example, a simple but effective way of mitigating risks is to spend less money. This might involve conducting pilot projects to identifying issues and potential solutions, rather than starting with enterprise-wide deployments.

Principle 8: communicate extensively

Extensive communication from the project team (and project sponsors) is critical for a successful information management initiative.

This communication ensures that staff have a clear understanding of the project, and the benefits it will deliver. This is a pre-requisite for achieving the required level of adoption.

With many projects happening simultaneously (principle 5), coordination becomes paramount. All project teams should devote time to work closely with each other, to ensure that activities and outcomes are aligned.
In a complex environment, it is not possible to enforce a strict command-and-control approach to management (principle 1).

Instead, a clear end point (’vision’) must be created for the information management project, and communicated widely. This allows each project team to align themselves to the eventual goal, and to make informed decisions about the best approaches.

For all these reasons, the first step in an information management project should be to develop a clear communications ‘message’. This should then be supported by a communications plan that describes target audiences, and methods of communication.
Project teams should also consider establishing a ‘project site’ on the intranet as the outset, to provide a location for planning documents, news releases, and other updates. Staff do not understand the distinction between systems

Principle 9: aim to deliver a seamless user experience

Users don’t understand systems. When presented with six different information systems, each containing one-sixth of what they want, they generally rely on a piece of paper instead (or ask the person next to them).
Educating staff in the purpose and use of a disparate set of information systems is difficult, and generally fruitless. The underlying goal should therefore be to deliver a seamless user experience, one that hides the systems that the information is coming from.

This is not to say that there should be one enterprise-wide system that contains all information.
There will always be a need to have multiple information systems, but the information contained within them should be presented in a human-friendly way.

In practice, this means:
• Delivering a single intranet (or equivalent) that gives access to all information and tools.
• Ensuring a consistent look-and-feel across all applications, including standard navigation and page layouts.
• Providing ’single sign-on’ to all applications.

Ultimately, it also means breaking down the distinctions between applications, and delivering tools and information along task and subject lines.

For example, many organisations store HR procedures on the intranet, but require staff to log a separate ‘HR self-service’ application that provides a completely different menu structure and appearance.
Improving on this, leave details should be located alongside the leave form itself. In this model, the HR application becomes a background system, invisible to the user.
Care should also be taken, however, when looking to a silver-bullet solution for providing a seamless user experience. Despite the promises, portal applications do not automatically deliver this.
Instead, a better approach may be to leverage the inherent benefits of the web platform. As long as the applications all look the same, the user will be unaware that they are accessing multiple systems and servers behind the scenes.
Of course, achieving a truly seamless user experience is not a short-term goal. Plan to incrementally move towards this goal, delivering one improvement at a time. The first project must build momentum for further work

Principle 10: choose the first project very carefully

The choice of the first project conducted as part of a broader information management strategy is critical. This project must be selected carefully, to ensure that it:
• demonstrates the value of the information management strategy
• builds momentum for future activities
• generates interest and enthusiasm from both end-users and stakeholders
• delivers tangible and visible benefits (principle 3)
• addresses an important or urgent business need (principle 4)
• can be clearly communicated to staff and stakeholders (principle
• assists the project team in gaining further resources and support

Actions speak louder than words. The first project is the single best (and perhaps only) opportunity to set the organisation on the right path towards better information management practices and technologies.
The first project must therefore be chosen according to its ability to act as a ‘catalyst’ for further organisational and cultural changes.

In practice, this often involves starting with one problem or one area of the business that the organisation as a whole would be interested in, and cares about.

For example, starting by restructuring the corporate policies and procedures will generate little interest or enthusiasm. In contrast, delivering a system that greatly assists salespeople in the field would be something that could be widely promoted throughout the organisation.