0% found this document useful (0 votes)
61 views11 pages

Project Initiation Guide

The document discusses project initiation and analysis for systems development projects. It covers reasons for initiating projects, sources of project requests both internally and externally, criteria for selecting projects, and the project proposal and selection process.

Uploaded by

bruce chileshe
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views11 pages

Project Initiation Guide

The document discusses project initiation and analysis for systems development projects. It covers reasons for initiating projects, sources of project requests both internally and externally, criteria for selecting projects, and the project proposal and selection process.

Uploaded by

bruce chileshe
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 11

Project Initiation and Analysis

COURSE: SYSTEMS ANALYSIS AND DESIGN

UNIT 2 (A): PROJECT INITIATION AND ANALYSIS

2.0 PROJECT INITIATION

Information systems applications originate from nearly all areas of an organization and pertain to vastly
different business problems.

2.1 WHY PROJECTS ARE INITIATED

Users request information systems projects for different reasons. Sometimes it is to solve a problem, for
example reducing the costs of doing certain tasks. Sometimes they might want to improve the efficiency
of the work done in their departments. In most cases users have several reasons for requesting information
help.

The following is a list of common for initiating information systems projects:

i. GREATER PROCESSING SPEED: you might want to use the computers inherent ability
to calculate, sort and retrieve data and information when greater speed than that people doing
the same task is required.
ii. BETTER ACCURACY AND IMPROVED CONSISTENCY: you might require carrying
out of computation including arithmetic, correctly and in the same way each time.
iii. FASTER INFORMATION BETRIEVAL: you might want to locate and retrieve
information from storage. You might also want to conduct complex searches this can be done
with the help of internet by accessing various databases.
iv. INTERGRATION OF BUSINESS AREAS: you might want to coordinate business
activities taking place in separate areas of an organization, through captures and distribution
of information e.g. management information systems.
v. REDUCED COSTS: you might wish to use computing capability to process data at a lower
cost than possible with other methods while maintaining accuracy and performance levels.
vi. BETTER SECURITY: you might want to safeguard sensitive and important data in a form
that is accessible only to those persons having authorization.

2.2 SOURCES OF PROJECT REQUESTS

There are altogether four primary sources of project requests. Inside the organization, there are three,
namely:

I. Department managers
II. Senior Executives (board chairman, president)
III. Systems Analyst
Project initiation and Analysis

Outside the organization, there is

IV. Outside groups such as Government agencies

Requests may seek completely new application or they may ask for changes in existing ones.

i. DEPARTMENT MANAGERS

The department managers request often focuses on a specific issue- only his department to solve his
problem. For example, the inventory department managers request for an inventory forecasting system
for ordering materials and forecasting demand may be looking primary at ways to eliminating out-of-
stock conditions. He may not consider the interaction between departments even though the potential for
such interaction can be high. His/her request may not discuss the implication in other areas, fewer
production problems due to material shortages, however carrying costs for materials stored, or better
prices through quantity purchasing.

ii. SENIOR EXECUTIVES

Senior executives, such as presidents, board chairpersons and vice presidents of a company, usually have
information about the organization that is not available to department managers. That information
together with the broader responsibilities they assume – they manage entire organization rather than
individual department, influences the systems project requests they make. Project requests submitted by
senior executives are therefore broader in scope than those prepared by department managers.

It should be noted that because of their scope multi-departmental projects are more difficult to manage
and control. Departmental projects, in contract, are more likely to be successful especially if the actual
users take an active role early in the project.

iii. SYSTEMS ANALYSTS

Sometimes systems analysts see areas where projects be developed and either write a systems proposal
themselves or encourage a manager to allow the writing of a proposal on their behalf.

Note that systems analysts and developers can also be users themselves. An example of an application
project that a system developer might request for is a project management systems e.g. engineering
project – building a road or bridge.

2.2.4 OUTSIDE GROUPS

Development outside the organization also lead to project requests for example, changes in the law,
environment protection (e.g. Zero emissions), bidding of tenders from government. (For example,
government contractors are required to use special cost accounting systems, having government
business).
The tax office requires organizations to keep careful payroll records, accounting for employee income
tax withheld. The tax office specifies the format for many of the tax documents that must be prepared;
the employer has no choice in the matter.

It should be noted that in some cases, such as when there are strict deadlines imposed by the outside
agency, projects from external groups take on a higher priority than the ones from, say department
managers.

2.3 CRITERIA FOR SELECTING SYSTEM PROJECTS

Selecting of systems projects, usually by one or more experiencing personnel in the systems department,
consists of only a very preliminary investigation into the following five key factors.

i. POTENTIAL RETURN IN INVESTMENT: this is the most important criterion for selecting
a project. Even a very broad estimate of the potential benefits and costs to the company can give
a strong guide to the desirability of implementing a system.
ii. CRITICAL COMPANY NEED: sometimes an organization finds itself in the position of
urgently needing an information system in a particular area, even though the financial
justification is unclear.
iii. TECHNICAL FEASIBILITY: a project may seem useful and desirable from a user point of
view, but there may be technical reasons, which preclude even a feasibility study. A decision not
to even examine a potential project, on technical grounds, will depends completely on the
experience available in the systems department.
iv. CONSISTENCY WITH SYSTEMS DEVELOPMENT STRATEGY: each systems
development project must fall within the organizations strategy for systems development as a
whole. This strategy is the basis for the overall systems planning which relates the different
projects to each other. It is sometimes not necessary to undertake a project simply because other
projects cannot start, or be completed, unless the project in question is accomplished.
v. CAPABILITY OF THE SYSTEMS DEPARTMENT TO DO THE PROJECT: many
apparently desirable projects are allocated to (or accepted by) the systems department without
sufficient consideration being given as to whether or not the systems department is in-fact
capable of doing the job required. Sometimes the difficult may be fitting a project into an
already overloaded workload and /or lack of technical know-how.
Project Initiation and Analysis

It should be noted that the option to the systems department that is fully aware of the technical
requirement that it cannot fulfill is to have the systems supplied by an external supplier.

2.4 THE PROJECT PROPOSAL

Users and analysts submit their requests in form of a PROJECT PROPOSAL. The project proposal is a
critical element in launching the systems study. The form of such a request varies from organization to
organization. However, there is a general agreement on the kind of information that should be provided.
The following are the sections In a project proposal:

 What is the project about? Clear definition of the problem


 Details of the problem
 What does the user feel is the solution?
 How information system will help?
 Who else knows about the problem; could they be contacted?

2.5 THE PROJECT SELECTION COMMITTEE

More requests for systems development are generated than most organizations want or are able to
pursue. Before any actual work is done on these requests, someone must decide which ones to pursue
and which to reject – or to be solved by other means. The decision to accept or reject a request can be
made in a number of different ways and by members of the organization. The systems analysts are not
the final arbiters.

One of the more common methods of receiving and selecting projects for development is by
committee. There are various kinds of committees that select projects. We shall consider three types.

o The steering committee


o Information systems committee
o User-group committee

A common feature of these committee formats is that membership often rotates membership changes
are staggered so that new members are added at different times the entire membership does not
change at one time. The chairperson of each committee should be someone who has previously
worked as a committee member. This ensures experience is reviewing systems proposals and making
decision about project requests.

i. STEERING COMMITTEES

In many organizations, steering committee (also called operating committees, operating councils or
project selection boards) supervises the views of project proposals.

COMPOSITION: typically the steering committee consists of key managers from various person
committee would comprise of the following types of persons.
Project initiation analysis

 UPPER MANAGEMENT MEMBERS: executive vice president, vice president for


manufacturing et cetera.

 DEPARTMENTAL MANAGEMENT: manager of retail marketing, credit manager.

 TECHNICAL MANAGERS: manager of research and development, quality control coordinator.

 INFORMATION SYSTEMS GROUP: data processing manager, senior systems analyst.

The committee receives proposals and evaluates them. The major responsibility of the committee is to
make a decision, but to do so, it often requires more information than the proposal provides. Therefore, a
preliminary investigation is often requested to gather those details.

ADVANTAGES

Because several levels of management are included on the committee, members can have informed
discussions on matters relating to day to day operations (treating patients, ordering materials or hiring
staff members) and long range plans (new facilities, new programs) that may have a bearing on the
project request.

 The managers have information and insight about each project because they are involved in the
work.

 Systems specialists on the committee provide technical and development information useful in
deciding about project management.

This approach is also favored because systems projects are business investments. Management selects
projects for development. The decisions therefore are made on the basis of the cost of the project, its
benefits to the organization and the feasibility of accomplishing the development within the limits of
information systems technology in the organization.

ii. INFORMATION SYSTEMS COMMITTEES

In some organization the responsibility for reviewing project requests is assigned to a committee of
managers and analysts in the information systems department. Under this arrangement all requests for
service and development are submitted directly to a review committee within the information systems
department. This committee approves or disapproves projects and sets priorities indicating which projects
are most important and should receive early attention. This method is ideal in cases where many requests
are for routine services or maintenance on existing application.
Project initiation Analysis

ADVANTAGES

Systems personnel have a good insight into project requirements. Through work with other projects (and
if the organization has a business planning committee that includes the information systems managers),
systems developers have access to information about where the organisation is going. This is important
for effective project selection.

DISADVANTAGES

When major equipment decision must be made or long-term development commitments are needed, the
decision authority is shared with senior executives. The executives determine whether a project should
proceed or not. Sharing project decision authority many confuse users who want to know the committee
will make the decision about a request. If top managers and systems committee members disagree about
the merit or priority of a request, the potential conflict is disruptive for handling future proposals.

Users may attempt to submit a request directly to senior executives, after the information systems
committee has disapproved it. If upper management approves the requests, it undermines the authority of
the information systems committee.

iii. USER GROUP COMMITTEE

In some organizations, the responsibility for project decision is distributed to the users themselves.
Individual departments or divisions hire their own analysts and designers who handle project selection
and carry out development. In effect, departments form their own selection committee, controlling what
is developed and when it is implemented.

ADVANTAGE

It takes some burden from the systems development group.

DISADVANTAGES

Is it possible for a small department to work independently towards the same goal and unknowingly
waste resources and miss the opportunity to coordinate their efforts to plan a shared and integrated
information system that could benefit the entire organisation. Some user groups may find themselves
with defective or poorly designed that will require time and effort to correct.

Poorly designed or defective systems may require time and effort to be undoing any damage caused by
the misinformation that such a system could generate.

It should be noted that the success rate of this method is not encouraging.

2.6 OTHER METHODS OF SELECTING PROJECTS

(A) having management planning committee that propose new projects, which are evaluate by the
system systems department
Project Initiation and Analysis

DISADVANTAGE

This method suffers from lack of user involvement as well as limited insight into technology.

(B) Having departed managers bypass the organization’s information systems department to contact
with independent systems companies, this will handle all analysis and design work for projects.

DISADVANTAGE

There is a possibility of having a department sponsor the development of a system without the
knowledge of the information systems group or upper management.

2.7 PRELIMINARY OR INITIAL INVESTIGATION

Proposals submitted to the selection committee are reviewed to identify those most beneficial to the
organization. The preliminary investigation is carried out by systems analysis working under the
direction of the selection committee.

i. SCOPE AND ACTIVITIES OF THE INITIAL INVESTIGATION

The purpose of the preliminary investigation is to evaluate project requests. It doesn’t include the
collection of details to describe completely the proposed system. Rather, the analysts collect information
that permits committee members to evaluate the merits of the project request and make an informed
judgment about the feasibility of the proposed project.

SCOPE: During preliminary investigation, analysts should,

 Clarify and understand the project request (what is being done? What is required? Why?)
 Determine the size of the project (i.e. is the system completely new or a modification of an
existing system? How much time will take? How many people will it involve?
 Assess costs and benefits of alternative approaches (e.g. will the proposed system reduce
operating costs?
 Determine the technical operational feasibility of alternative approaches.
 Report the findings to management with recommendation outlining the acceptance or rejection
of the proposal.
ii. INFORMATION GATHERING

Data collected by analysts during preliminary investigation is gathered through two methods.

a) Reviewing of organization documents.


b) Interviewing selected company personnel.
Project Initiation and Analysis

(A) REVIEWING DOCUMENTS

Analysis need to learn about the departments of the organization which is involved in or affected by the
project. They can do so by examining organization charts and studying written operating procedure.

(B) INTERVIEWING PERSONNEL

Written documents can tell the systems analyst how the system should operate, but they cannot provide
enough details for the analysts to decide about the merits of a system proposal. They also can’t present
user views about current operations. These details are provided through interviews. During interviews
analysts discuss system features to learn more facts about the nature of the project request and the reason
for submitting it. The aim is to collect details that further explain the nature of the project and show
whether or not; assistance is merited economically, operationally and technically.

 During this time no attempt is made to work out a solution to the situation.
Working out a solution comes during detailed investigation.
 Preliminary investigation interviews usually involve only management and supervisory
personnel.

2.8 PROJECT FEASIBILITY

Data collection during the initial investigation examines three types of feasibility (i.e. the likelihood that
the system will be beneficial to the organization.)

i. OPERATIONAL FEASIBILITY
 Is there sufficient support for the project from management? From users? (Resistance to change
may be encountered if the current system is well liked and used to the extent that persons will
not see reasons for a change).
 Are current methods acceptable to the users? If they are not, users may welcome a change that
will bring a more operational and useful system.
 Have the users been involved in the planning and development of the project? (Early
involvement reduces the chances of resistance to change in general and increases the likelihood
of successful projects.
 Will the proposed system cause harm?
o Will the system produce poorer results in any respect or area?
o Will loss of control result in any area?
o Will accessibility of information be lost?
o Will individual performance be poorer after implementation than before?
o Will customers be affected in any undesirable way?
o Will it show performance in any area?
Project Initiation and Analysis

xi. Prepare gross estimates of probable overall implementation and operations costs for each
practical alternative.

It must be decided which of the alternative is economically the most attractive.

xii. Documenting the feasibility study in a report for user and system management.

The findings are documented in a single report in a manner which will facilitate the decision to proceed
with the project or not, and if so, which of the design scenarios should be the preferred option during
the definition phase.

SUMMARY

The feasibility study is a microcosm of the complete systems development process and if unconstrained
could easily become the entire project. For most commercial applications feasibility studies take from
about 6 to 8 weeks to conduct.

2.11 SYSTEMS REQUIREMENTS DETERMINATION

Requirements determination includes studying the current business system (which may be manual) to
find out how it works and where improvements and /or enhancements should be made. Various kinds
of requirements arise depending on whether the system is transaction oriented or decision-oriented and
whether the system is inter-departmental.

In most organizations, authorized development projects are implemented by PROJECT TEAMS


established for each development.

2.12 THE PROJECT TEAM

When it has been decided to go ahead with a system, the immediate tasks are to form a PROJECT
TEAM and start PROJECT PLANNING. The activities which the team will be involved in will be
subject to project management and control. When setting up a project team, the following guidelines
are important:

(a) Clear allocation of RESPONSIBILITY for the team and in particular for its project manager,
especially with regard to:

 Budget
 Role of user departments and the systems department
 Reporting to senior management

(b) Informing all RELEVANT PARTIES, especially

 Other departments affected.


 Staff representatives
 Auditing department
Project Initiation and Analysis

Note: Informing all concerned parties is important to ensure cooperation during the development process
and subsequent acceptance of the system after development. If other concerned members are not
informed, the system will not be accepted. This is called the “Not Invented Here” syndrome.

c) Administrative support for the project team, particularly

 Budget spending procedures


 Hiring of external exports
 Office space and equipment

These and other aspects will need to be documented in a project file, which will develop into the
permanent record of the project. Typically its contents will be.

(1) Project specification


(2) Budget breakdown and expenditure analysis
(3) Correspondence file
(4) Name and address list of contacts
(5) Security rules for the project
(6) Contracts
(7) Work schedules and progress reports
(8) Minutes of committee meetings

Having established the procedure aspects of the work, the first main task for the team is the procedure
a PROJECT PLAN.

2.13 TYPES OF PROJECT TEAMS

Three variations of the project team concept are:

a) The chief-programmer teams


b) Specialist teams
c) The leaderless teams

d) CHIEF PROGRAMMER TEAMS

These consist of the chief programmer, a backup programmer and the programming librarian and
support personnel. The chief programmer formulates design tasks and writes code for all critical
modules on the system. He also performs integration and testing the teams, code. He serves as the
primary contact for users and other teams.

The backup programmer also participates in software design, program coding and test planning. He
performs such activities as researching design alternatives and development strategies.

The programming librarian is responsible for maintaining both the external program library and the
internal documentation library. The external program library consists of source code sets, object
modules, test data, etc. It is maintained in printed form usually a

You might also like