COURSE

GUIDE

MBA 815
MANAGEMENT INFORMATION SYSTEM

Course Team Gerald Okeke (Course Developer/Writer) – Eco

Communications Inc. Ikeja, Lagos
Mrs. Abimbola E. Adegbola(Course Editor) –
NOUN
Dr. O. J. Onwe (Programme Leader) –NOUN
Mrs. Abimbola .E. Adegbola (Course
Coordinator) – NOUN

UNEDITED VERSION

NATIONAL OPEN UNIVERSITY OF NIGERIA

MBA 815 COURSE GUIDE

National Open University of Nigeria

Headquarters
University Village
Plot 91, Cadastral Zone,
Nnamdi Azikiwe Express way
Jabi, Abuja

Lagos Office
14/16 Ahmadu Bello Way
Victoria Island, Lagos

e-mail: [email protected]
website: www.nouedu.net

Published by
National Open University of Nigeria

Printed 2009

ISBN: 978-058-235-5

All Rights Reserved

ii
MBA 815 COURSE GUIDE

CONTENTS PAGE

Introduction …………………………………………….. iv
Course Aims ……………………………………….…… iv
Course Objectives ……………………………………… iv
Working through this Course ………………………….. v
Study Units……………………………………………… v
Assessment …..……………………………………….… vi

iii
MBA 815 COURSE GUIDE

INTRODUCTION

MBA 815, Management Information System is a semester course work

of two credit units, for post-graduate students of the School of Business
and Human Resources Management.

The course material consist of 15 units that will enable

learners understand the design and development of MIS.

COURSE AIMS

This course is designed for the student to have an understanding of how

to design and develop an information management
system within organizations. To further give the students the
details of all the major process and phases embarked upon in
systems development. It also exposes the students to specific
method of systems development, and in details. Summarily, the
aim of the course is for the learners to comfortably
design and develop information systems in whatever
organization they find themselves.

COURSE OBJECTIVES

The Comprehensive objectives of this course include to:

• teach the concept of systems development.

• trace the evolution of systems development.
• identify the purposes and the key principles of systems
development.
• have a knowledge of the basic phases in a typical systems
lifecycle.
• identify some of the drawbacks in the application
of developedmethods.
• be able to know the steps that has to be taken
in developing a strategic information system plan for an
organization.
• answer the question of factors that influence the output of a
strategic information system plan.
• understand the factors that trigger the initiation of
information
• system design.
• explain what constitutes concept development in
designing and
• developing information system.
• understand what constitutes the requirement analysis in

iv
MBA 815 COURSE GUIDE

designing and developing information system.

• identify some issues that need to be considered in deign phase
of a
• system.
• be able to know what are the deliverables from
development,
• integration and testing to be used for subsequent phases.
• explain the relationship between cost of maintenance
phase
• compared to other phases of systems development.
• be able to identify and discuss the success
factors behind the
• operations of dynamic system development method.
• have an understanding of what project management is and how it
has
• developed over the years.
• identify the components of a project planning based on structure
put
• in place.
• understand risk assessment and management in the
context of
• management information system as a project.
• specifically, understand the process of developing a
geographic
• information system.

WORKING THROUGH THIS COURSE

The complete this course, learners are expected to have read all the units
contained in this course material. Learners are advised to read textbooks
recommended under the column for further reading and related materials
you can possibly lay your hands on. Attempt all exercises in each unit.
Answers to TMA are to be submitted for assessment purpose. At the end
of the course, there will be a final examination to test your master of the
course.

STUDY UNITS

Module 1

Unit 1 Overview of Systems Development Life Cycle (SDLC)

Unit 2 Overview of Information System Development Methods
Unit 3 Strategic Planning for Design of Information Systems
Unit 4 Initiation of System Design and Development
Unit 5 Concept Development and Planning of System Design

v
MBA 815 COURSE GUIDE

Module 2

Unit 1 Requirements Analysis of System Design

Unit 2 Design of System
Unit 3 Development, Integration and Testing of
Information System
Unit 4 Implementation and Disposition of System
Unit 5 Operations and Maintenance of System Design

Module 3

Unit 1 Dynamic Systems Development Method

Unit 2 Project Management
Unit 3 Project Planning
Unit 4 Risk Assessments and Management
Unit 5 Design and Planning for GIS

ASSESSMENT

• The assignments represents 30% of the marks obtainable

• Examination constitutes 70% of the marks obtainable.

vi
 MAIN
COURSE

CONTENTS PAGE

Module 1 ……………………………………………….. 1

Unit 1 Overview of Systems Development Life

Cycle (SDLC) ……………………………… 1

Unit 2 Overview of Information System

Development Methods …………………… 14
Unit 3 Strategic Planning for Design of Information
Systems ……………………………………… 28
Unit 4 Initiation of System Design and Development 42
Unit 5 Concept Development and Planning of
System Design ……………………………… 54

Module 2 ……………………………………………….. 56

Unit 1 Requirements Analysis of System Design 56

Unit 2 Design of System …………………………… 75
Unit 3 Development, Integration and Testing
of Information System ……………………… 85
Unit 4 Implementation and Disposition of System 96
Unit 5 Operations and Maintenance of System
Design ………………………………………. 107

Module 3 ……………………………………………….. 118

Unit 1 Dynamic Systems Development Method 118

Unit 2 Project Management………………………… 132
Unit 3 Project Planning …………………………….. 146
Unit 4 Risk Assessments and Management ……….. 161
Unit 5 Design and Planning for GIS ……………….. 175
MBA 815 MODULE 1

MODULE 1

Unit 1 Overview of Systems Development Life Cycle (SDLC)

Unit 2 Overview of Information System Development Methods
Unit 3 Strategic Planning for Design of Information Systems
Unit 4 Initiation of System Design and Development
Unit 5 Concept Development and Planning of System Design

UNIT 1 OVERVIEW OF SYSTEMS

DEVELOPMENT LIFE CYCLE (SDLC)

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 SDLC Objectives
3.2 Purpose, Scope, and Applicability
3.2.1 Purpose
3.2.2 Scope
3.2.3 Applicability
3.3 Key Principles
3.4 SDLC Phases
3.5 Documentation
3.6 Systems Development Life Cycle Models include
3.6.1 The Waterfall Model
3.6.2 Rapid Application Development (RAD)
3.6.3 Joint Application Development (JAD)
3.6.4 The Prototyping Model
3.6.5 Synchronize-and-Stabilize
3.6.6 The Spiral Model
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

Many organizations spend millions of dollars each year

on the acquisition, design, development, implementation, and
maintenance of information systems vital to mission programs
and administrativefunctions. The need for safe, secure, and
reliablesystem solutions is heightened bytheincreasing
dependenceon computer systems and technologyto provide services

1
MBA 815 MANAGEMENT INFORMATION SYSTEM

and develop products, administer daily activities, and perform

short- and long-term management functions.
There is also a need to ensure privacy and security when
developing management information systems, to establish
uniform privacy and protection practices, and to develop
acceptable implementation strategies for these practices.

Organizations need a systematic and uniform methodology

for information systems development. Using SDLC will ensure that
systems developed by the Department meet IT mission objectives; are
compliant with standards and are easy to maintain and cost-effective to
enhance. Sound life cycle management practices include planning and
evaluation in each phase of the information system life cycle. The
appropriate level of planning and evaluation is commensurate with the
cost of the system, the stability and maturity of the technology
under consideration, how well defined the user requirements are, the
level of stability of program and user requirements and security
considerations.

Systems Development Life Cycle (SDLC) emphasizes decision

processes that influence system cost and usefulness. These
decisions must be based on full consideration of business
processes, functional requirements, and economic and technical
feasibility in order to produce an effective system. The primary
objectives of any SDLC are to deliver quality systems that: 1)meet
or exceed customer expectationsromised and within cost
estimates, 2) work effectively and efficientlywithin the current
and planned information technology infrastructure,and 3) are
inexpensive to maintain and cost-effective to enhance. ThisSDLC
establishes a logical order ofeventsfor conducting development that
is controlled, measured, documented, and ultimatelyimproved.

This does notprescribe a single method applicable without change

toevery system. Because there is wide variance in the methods,
techniques and tools used tosupporttheevolutionofmanagementsystems,
and project scopes vary greatly, the SDLC presents guidance for
selecting appropriate methods, techniques, and tools based
on specific factors. One methodology does not fit all sizes
and types of system development efforts.

2.0 OBJECTIVES

At the end of this unit, you should be able to:

• understand the concept of systems development

• trace the evolution of systems development

2
MBA 815 MODULE 1

• identify the purposes and the key principles of systems

development
• have a knowledge of the basic phases in a typical systems
lifecycle.

3.0 MAIN CONTENT

3.1 SDLC Objectives

Key to SDLC

An SDLC isdevelopedtodisseminateprovenpracticesto system

developers,projectmanagers, program/accountanalysts andsystem
owners/users throughoutanyorganization. The specific objectives
expected include the following:

• To reduce the risk of project failure

• To consider system and data requirements throughout the entire
life of the system
• To identify technical and management issues early
• To disclose all life cycle costs to guide business decisions
• To foster realistic expectations of what the systems will and will
not provide
• To provide information to better balance programmatic,
technical, management, and cost aspects of proposed
systemdevelopment or modification
• To encourage periodic evaluations to identify systems that
are no longer effective
• To measure progress and status for effective corrective action
• To support effective resource management and budget planning
• To consider meeting current and future business requirements.

3.2 Purpose, Scope, and Applicability

3.2.1 Purpose

This SDLC methodologyestablishes procedures, practices,and

guidelines governing the initiation, concept development, planning,
requirements analysis, design, development, integration and test,
implementation, and operations, maintenance and disposition of
management informationsystems (MIS) within the organization. It
should be used in conjunction withexisting policy and guidelines for
acquisition and procurement.

3
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.2.2 Scope

This methodology should be used for all organizational

information systems and applications. It is applicable
across all information technology (IT) environments (e.g., mainframe,
client, and server) and applies to contractually developed as
well as in-house developed applications. The specific participants
in the life cycle process, and the necessary reviews and approvals,
vary from project to project. The SDLC should be
tailored to the individual project based on complexity,
and criticality to the agency’s mission.

3.2.3 Applicability

The SDLC methodology can be applied across

organizational units; Offices, Boards, Divisions and Bureaus
(OBDB) who are responsible for information systems
development. All Project Managers and development teams
involved in system development projects represent the primary
audience for the SDLC. The SDLC serves as the mechanism to assure
that systems under development meet the established
requirements and support an organization’s mission
functions. It provides a structured approach to managing information
technology (IT) projects beginning with establishing the
justification for initiating systems development or maintenance
effort and concluding with system disposition.

The primary audience for SDLC is the systems developers, IT

project managers, program/account analysts and system
owners/users responsible for defining and delivering
organizational systems, their staff, and their support contractors.
Specific roles and responsibilities are described throughout each life
cycle phase.

3.3 Key Principles

The SDLC defines traditional information system life cycle management

approaches to reflect the principles outlined in the
following subsections. These are the foundations for life cycle
management.

Life Cycle Management Should be used to Ensure a

approach to Information Systems Development, Maintenance,
andOperationThis SDLC describes anoverallstructured
approachtomanagement. Primary emphasis is placed
on the information and systems decisions to be made and the

4
MBA 815 MODULE 1

proper timing of decisions. The SDLC provides a flexible

framework for approaching a variety systems projects.
The framework enables system developers, project managers,
program/account analysts, and system owners/users to
combine activities, processes, and products, as appropriate, and to select
the tools and methodologies best suited to the unique
needs of project.

Support the use of an Integrated Product Team

The establishment of an Integrated Product Team (IPT) can aid in the
success of a project. An IPT is a multidisciplinary group of people who
support the Project Manager in the planning, execution,
delivery and implementation of life cycle decisions for
the project. The IPT is composed of qualified empowered
individuals from all appropriate functional disciplines that
have a stake in the success of the project. Working together
in a proactive, open communication, team oriented
environment can aid in building a successful project
and providing decision makers with the necessary
information to make the right decisions at the right time.

Each System Project must have a Program Sponsor

To help ensure effective planning, management, and
commitment to management information systems, each
project must have a clearly identified program sponsor. The
program sponsor serves in a leadership role, providing guidance to the
project team and securing, from senior management, the required
reviews and approvals at specific points in the life cycle. An approval
from senior management is required after the completion of
the first seven of the SDLC phases, annually during
Operations and Maintenance Phase and six-months after the Disposition
Phase. Senior management approval authority may be varied based
on dollar value, visibility level, congressional interests or a combination
of these. The program sponsor is responsible for identifying who
will be responsible for formally accepting the delivered system at the
end of the Implementation Phase.

A Single Project Manager must be Selected for Each System Project

The Project Manager has responsibility for the success of the project and
works through a project team and other supporting
organization structures, such as working groups or user groups,
to accomplish the objectives of the project. Regardless of
organizational affiliation, the Project Manager is accountable and
responsible for ensuring that project activities and decisions consider the
needs of all organizations that will be affected by the system.
The Project Manager develops a project charter to define

5
MBA 815 MANAGEMENT INFORMATION SYSTEM

and clearly identify the lines of authority between and within the
agency’s executive management, program sponsor,
(user/customer),and developer forpurposes of management and
oversight.

A Comprehensive Project Management Plan is Required for Each

System Project

The project management plan is a pivotal element in the

soulcucteisosnful of an information management requirement. The
project management plan must describe how each life cycle phase will
be accomplished to suit the specific characteristics of the project. The
Project management plan is a vehicle for documenting the project scope,
tasks, schedule, allocated resources, and interrelationships with other
projects. The plan is used to provide direction to the many activities of
the life cycle and must be refined and expanded throughout the life
cycle.

Specific Individuals Must be Assigned to Perform

Key Roles throughout the Life Cycle
Certain roles are considered vital to a successful system project and at
least one individual must be designated as responsible for each key role.
Assignments may be made on a full- or part-time basis as appropriate.
Key roles include program/functional management, quality
assurance, security, telecommunications management, data
administration, database administration, logistics, financial,
systems engineering, test and evaluation, contracts management, and
configuration management. For most projects, more than one individual
should represent the actual or potential users of the system (that is,
program staff) and should be designated by the Program Manager of the
program and organization.

Obtaining the Participation of Skilled Individuals is Vital to

tShueccess of the System Project
The skills of the individuals participating in a system project are
thesingle most significant factor for ensuring the success of the
project. The SDLC is not intended as a substitute for information
management skills or experience. While many of the skills required
for a system project are discussed in later sections, the required skill
combination will vary according to the project. All individuals
participating in a system development project are encouraged to
obtain assistance from
experienced information management professionals.

6
MBA 815 MODULE 1

Documentation of Activity Results and Decisions for Each Phase

ofthe Life Cycle are Essential

Effective communication and coordination of activities throughout

thelife cycle depend on the complete and accurate documentation of
decisions and the events leading up to them. Undocumented or poorly
documented events and decisions can cause significant
confusionowrasted efforts and can intensify the effect of turnover
ofpmraonjeacgtement staff. Activities should not be considered
complete, nordecisions made, until there is tangible documentation of
the activity ordecision. For some large projects, advancement to the
next phase cannotcommence until the required reviews are completed
and approved bysenior management.

Data Management is Required throughout the Life Cycle

An organisation considers the data processed by systems
to be an extremely valuable resource. Accurate data is
critical to support organizational missions. The large, medium and
small volumes of data handled by organisation’s systems, as
well as the increasing trend toward interfacing and
sharing data across systems and programs, underscore the
importance of data quality. Systems life cycle activities
stress the need for clear definition of data, the
design and implementation of automated and manual processes that
ensure effective data management.

Each System Project Must Undergo Formal Acceptance

The program sponsor identifies the representative who
will be responsible for formally accepting the delivered system at the
end of the Implementation Phase. The system is formally accepted by
the programsponsor by signing an Implementation Phase
Review and Approval Certification along with the developer.

Consultation with Oversight Organizations Aids in the Success of a

System Project A number of oversight bodies, as well as external
organizations, have responsibility for ensuring that
information systems activities are performed in accordance with
standards and available resources are used effectively. Each project team
should work with these organizations, asappropriate, and encourage
their participation and support as early as possible in the life
cycleto identify and resolve potential issues or sensitivities
and thereby avoid major disruptions to the project. Assume
all documentation is subject to review by oversight activities.

A System Project may not Proceed until Resource

7
MBA 815 MANAGEMENT INFORMATION SYSTEM

Availability is Assured Beginning with the approval of the project, the

continuation of a system is contingent on a clear commitment from
the program sponsor. This commitment is embodied in the
assurance that the necessary resources will be available, not only for
the next activity, but as required for the remainder of the life cycle.

3.4 SDLC Phases

The SDLC includes phases, for example ten phases in this model; during
which defined IT work products are created or
modified. The Phase occurs when the system is disposed of and the
task performed is either eliminated or transferred to other
systems. The tasks and workproducts for each phase are described
in subsequent chapters. Not every project will require that the phases be
sequentially executed. However, the phases are interdependent.
Depending upon the size and complexity of the project, phases may be
combined or may overlap. See Figure 1-1.

The initiation of a system (or project) begins when a business need or

opportunity is identified. A Project Manager should be

8
MBA 815 MODULE 1

appointed to manage the project. This business need is

documented in a Concept Proposal. After the Concept Proposal
is approved, the System Concept Development Phase begins.

System Concept Development Phase

Once a business need is approved, the approaches for accomplishing the
concept are reviewed for feasibility and appropriateness. The
SystemsBoundary Document identifies the scope of the
system and requires Senior Official approval and funding
before beginning the Planning Phase.

Planning Phase
The concept is further developed to describe how the
business will operate once the approved system is implemented, and
to assess how the system will impact employee and customer
privacy. To ensure the products and /or services provide the
required capability on-time and within budget, project resources,
activities, schedules, tools, and reviews are defined. Additionally,
security certification and accreditation activities begin with the
identification of system security requirements and the completion of a
high level vulnerability assessment.

Requirements Analysis Phase

Functional user requirements are formally defined and
delineate the requirements in terms of data, system
performance, security, and maintainability requirements for
the system. All requirements are defined to a level of detail
sufficient for systems design to proceed. All requirements need to
be measurable and testable and relate to the business need
or opportunity identified in the Initiation Phase.

Design Phase
The physical characteristics of the system are designed
during this phase. The operating environment is established, major
subsystems and their inputs and outputs are defined, and
processes are allocated to resources. Everything requiring
user input or approval must be documented and reviewed
by the user. The physical characteristics of the system are
specified and a detailed design is prepared. Subsystems
identified during design are used to create a detailed
structure of the system. Each subsystem is partitioned into one or
more design units or modules. Detailed logic specifications are
prepared for each software module.

Development Phase
The detailed specifications produced during the design

9
MBA 815 MANAGEMENT INFORMATION SYSTEM

phase are translated into hardware, communications, and

executable software. Software shall be unit tested, integrated,
and retested in a systematic manner. Hardware is assembled and
tested.

Integration and Test Phase

The various components of the system are integrated and systematically
tested. The user tests the system to ensure that the
functional requirements, as defined in the functional requirements
document, are satisfied by the developed or modified system.
Prior to installing and operating the system in a
production environment, the system ndergo certification and
accreditation activities.

Implementation Phase
The system or system modifications are installed and made operational
in a production environment. The phase is initiated after the system has
been tested and accepted by the user. This phase continues
until thesystem is operating in production in accordance with the
defined user requirements.

Systems development life cycle model:

There are a lot of SDLC models. Some relevant
models are disculssed within the content of this course material.

Operations and Maintenance Phase

The system operation is ongoing. The system is monitored for continued
performance in accordance with user requirements, and needed system
modifications are incorporated. The operational system is
periodically assessed through In-Process Reviews to determine how the
system can be made more efficient and effective. Operations continue as
long as the system can be effectively adapted to respond to an
organization’s needs. When modifications or changes are identified as
necessary, the system may reenter the planning phase.

Disposition Phase

The disposition activities ensure the orderly termination of the

system and preserve the vital information about the system so that
some or all of the information may be reactivated in the
future if necessary. Particular emphasis is given to proper
preservation of the data processed by the system, so that the data is
effectively migrated to another system or archived in accordance
with applicable records management regulations and policies, for
potential future access.

10
MBA 815 MODULE 1

3.5 Documentation

This life cycle methodology specifies which documentation

shall be generated during each phase. Some documentation remains
unchanged throughout the systems life cycle while others
evolve continuously during the life cycle. Other documents are
revised to reflect the results of analyses performed in later phases. Each
of the documents produced are collected and stored in a project file.
Care should be taken, however, when processes are automated.
Specifically, components are encouraged to incorporate a long-
term retention and access policy for electronic processes. Be
aware of legal concerns that implicate effectiveness of or
impose restrictions on electronic data or records. Contact your Records
Management Office for specific retention requirements and procedures.

3.6 Systems Development Life Cycle Models include

3.6.1 The Waterfall Model

This is the classic SDLC model, with a linear and sequential method that
has goals for each development phase. The waterfall model
simplifies task scheduling, because there are no iterative or overlapping
steps. One drawback of the waterfall is that it does not allow for much
revision.

3.6.2 Rapid Application Development (RAD)

This model is based on the concept that better

products can be developed more quickly by: using workshops or
focus groups to gather system requirements; prototyping and reiterative
testing of designs; rigid adherence to schedule; and less formality of team
communications such as reviews.

3.6.3 Joint Application Development (JAD)

This model involves the client or end user in

the design development of an application, through a
series of collaborative workshops called JAD sessions.

3.6.4 The Prototyping Model

In this model, a prototype (an early approximation of a final system

or product) is built, tested, and then reworked as
necessary until acceptable prototype is finally achieved
from which the complete system or product can now be
11
MBA 815 MANAGEMENT INFORMATION SYSTEM

developed.
3.6.5 Synchronize-and-Stabilize

This model involves teams working in parallel on individual application

modules, frequently synchronizing their code with that of other
teams and stabilizing code frequently throughout the development
process.

3.6.6 The Spiral Model

This model of development combines the features of the

prototyping model and the waterfall model. The spiral model is
favored for large, expensive, and complicated projects.

4.0 CONCLUSION

Systems development life cycle is a system by which analysts, software

engineers, programmers and end users build information systems
and computer applications has brought about a disciplined
approach to systems development. This has resulted in the reduction of
project time and cost. It has also brought about consistency and
continuity in systems design and development.

5.0 SUMMARY

• Many organizations spend millions of dollars each

year on the acquisition, design, development,
implementation, and maintenanceof information systems vital to
mission programs and administrative functions.

• An SDLC is developed to disseminate proven practices

to system developers, project managers, program/account
analysts and system owners/users throughout any organization.

• This SDLC methodology establishes procedures,

practices, and guidelines governing the initiation, concept
development, planning, requirements analysis, design,
development, integration and test, implementation, and
operations, maintenance and disposition of management
information systems (MIS) within the organization

• This SDLC describes an overall structured approach to

information management. Primary emphasis is
placed on the information systems decisions to be made
and the proper timing of decisions.

12
MBA 815 MODULE 1

• The skills of the individuals participating in a system project are

the single most significant factor for ensuring the success of the
project.
• The SDLC includes phases, for example ten phases in this
model; during which defined IT work products are created or
modified.
• The initiation of a system (or project) begins when a business
need or opportunity is identified.
• This life cycle methodology specifies which documentation shall
be generated during each phase. Some documentation
remains unchanged throughout the systems life cycle
while others evolve continuously during the life cycle.

In the next study unit, you will be exposed to overview of

information system development methods.

6.0 TUTOR-MARKED ASSIGNMENT

1. Discuss the key principles to adopt in the development of SDLC.

2. Briefly differentiate the models of SDLC.

7.0 REFERENCES/FURTHER READINGS

Information Resources Management (2003).The Department of Justice

Systems Development Lifecycle Guidance Document.

Norton, P (1995). Introduction to Computers.Macmillan/McGraw-Hill.

13
MBA 815 MANAGEMENT INFORMATION SYSTEM

UNIT 2 OVERVIEW OF INFORMATION SYSTEM

DEVELOPMENT METHODS

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Concept of Information System Development
3.1.1 Tacit method knowledge
3.1.2 Method use is a learning process
3.1.3 Evolution of Methods
3.2 Historical Perspective of ISD
3.3 Paradox to the Use of Methods
3.3.1 Low Acceptance and Use of Methods
3.3.2 Popularity of Local Method Development
3.4 Re-Evaluation of Method Use
3.5 Degree of Modifications
3.6 Frequency of Method Modifications
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

This unit introduces you to historical perspectives and

concepts information system development. It also exposes you to Re-
evaluation and use of methods in JSD. Finally, it
examines the degree modification and frequency of method
modifications in ISD

2.0 OBJECTIVES

This unit of the course is designed for you to:

• understand the concepts and the evolution of

information systems development
• identify some of the drawbacks in the application
of developed methods
• answer the question of how popular are locally developed
methods
• be able to identify the degree to which methods are modified.

14
MBA 815 MODULE 1

3.0 MAIN CONTENT

3.1 Concept of Information System Development

In designing and developing management information systems

despite the efforts poured into method development and research, there
seems to be no universal agreement whether methods are useful
in ISD at all. Several fundamental questions on ISD methods are
largely unanswered. Of these questions two are especially important:
“are methods actually used in practice?” and“why are local
methods developed?” The importance of these questions is
further emphasized because of the contradiction between
the great efforts made to promote text-book methods and
their surprisingly low use in practice. In short, there are
thousands of methods available and new ones are continually developed,
but at the same time empirical research reveals that many companies do
not use them, and if they do then they have developed their own variants
As a result, it seems that method development is relatively easy since so
many of them exist, but methods developed by others
do not meet method users’ requirements. We can find
reports and studies aboutorganizations which have found their
local methods applicable or even reported success stories of method
use. These observations lead us to analyze two paradoxes of
methods in more detail, namely the low acceptance of
methods and the popularity of local methods.

3.1.1 Tacit Method Knowledge

The underlying paradigm behind many ISD methods is

scientific reductionism. This rests on the assumption that
the solution can be achieved through a sequence of steps,
decisions, and deliverables pre-defined in the method knowledge
(Fitzgerald 1996). The expectation of a complete and explicit set of
methodical knowledge is, however, too narrow.

The dominant approach underpinning many methods can

be characterized as “technical rationality”: situations in
practice can be scientifically categorized, problems are firmly
bounded, and they can be solved by using standardized principles. This
view of development and use of methods is by no means wrong or
“bad”: it has produced a great deal of knowledge about ISD and
led to the development of useful routine procedures which
are generally known and used. In fact, the main principle of
method development can be said to be to provide
knowledge about ISD which is explicit and applicable for
future ISD efforts. However, not all tasks of ISD fit

15
MBA 815 MANAGEMENT INFORMATION SYSTEM

the view of scientific reductionism. In other words, it is not

possible to have full knowledge about the problem (and thus the
applicable method) beforehand, nor can pre-defined method knowledge
cover all possible situations. Moreover,part of theknowledge
related to ISD in general and toknowledge in
particular is tacit and thus can not be expressed.
Therefore, we claim that the technical rationality is
too narrow address and explain the use of methods as it takes place in
practice. As a result, it is our belief that system development can
not be completely carried out by following pre-defined methods.

A liberating perspective to support method development is what Schön

(1983) calls “reflection-in-action”. Here, the fundamental
assumptions are uniqueness of situations and tacit, intuitive
knowledge. Part of our knowledge of ISD is based on our reflection on
the situations in which we find ourselves, rather than being found
solely by using predefined methods. Thus, methods need
tobemaintainedbasedonpractice, transforming tacit
knowledge into explicit knowledge. The importance of tacit
knowledge partly explains the low acceptance and use of methods,
and why successful ISD efforts can be carried out a-methodically
(Baskerville et al. 1992) without the use of any “explicit”method. Hence,
method is not everything. On the other hand, all ISD efforts cannot
be carried out based on pure intuition andknowledge
(Jaaksi 1997). Therefore, we see the views of reflection-in-
action and technical-rationality as complementary views of
method development and use: both explicit and tacit knowledge are
necessary
and useful for successful ISD. Accordingly, a good method should take
both aspects into account, on the one hand, providing knowledge which
can be rigidlyfollowed as
hulm

3.1.2 Method Use is a Learning Process

The other assumption behind scientific reductionism (Fitzgerald 1996)

isthatthedeveloper canobtaindetailedknowledge about the situation
and about applicable methods. This view expects
thatnecessary knowledge about the method, whether it is tacit or explicit,
is available beforehand. In addition to this expectation of
complete and explicit methodical knowledge the introduction of
methods as readily available “routines” is seen as being
easy, and the use of assumed to lead to solutions which are
repeatable. For example, one of the goals of ISD (Cameron 1989) is to
eliminate personal differences and even creativity from the
development process. According to this view the key

16
MBA 815 MODULE 1

problem for IS developers would be to select the right

method rather than to use it.

We question this by emphasizing that method use is a learning

process in which the current level of expertise is
crucial to successful (C urtis 1992, Hughes and Reviron 1996). The
learning process occurs at two levels; in the domain of IS, and in the
domain of ISD. The former means learning about successful (or
unsuccessful) ISs. The latter means that any organization that builds
ISs, not only delivers systems - they also learn how to carry out
ISD, and use methods. This learning about methods means that
they gain experience about the applicability of methods.
This experience can complement the method knowledge they
already possess.

Another factor explaining the low use of methods is

organizations’surprisingly shallow knowledge and experience of
methods (see Aaen et al. 1992), and their poor capability to manage ISD
(see Humprey 1988). For example, a survey by Aaen et al. (1992)
observed that more than half of the organizations considered their
knowledge and experience of methods small. Similar results have
been found in other surveys (cf. Smolander et al. 1990).
Research on software process maturity (Humprey 1988) has
shown that understanding of one’s own work must precede any further
steps in method definition and improvement.

3.1.3 Evolution of Methods

Instead of viewing methods as finished articles, a view

which few method promoters take, methods must be viewed from an
evolutionary perspective. Shifts in method knowledge are
known (Joosten and Schipper 1996) and an examination of current
developments in the field of object-oriented methods, workflow
sroblem
methods or business process re-
engineering methods gives no reason to expect that this would change in
the near future. An indication of method evolution is that organizations
must deal with different method versions, introduce new method types,
such as object-oriented methods, and abandon old methods which have
been foundinapplicable fornewtechnologiesandapplications
(Bubenko and Wangler 1992).

Basically, two different types of evolution exist: those reflecting general

requirements of technical evolution and business needs,
andthose relevant to the ISD situation at hand. The former deals with the
general historical perspective and the latter with how these general
requirements are adapted into local situations and how

17
MBA 815 MANAGEMENT INFORMATION SYSTEM

they affect the method evolution.

3.2 Historical Perspective of ISD

The method literature includes several reviews of the development

and use of ISD methods (e.g. Welke and Konsynski 1980,
Bubenko1986,Norman and Chen 1992, Moynihan and Taylor1996).
Most of theseexplain method evolution though an
interaction with available or emerging technologies which are
used either in the developed systems or in the ISD tools.

Bubenko (1986) analyzed methods from a historical

perspective: the need for methods has grown while the complexity
and size of ISs has increased. The earliest methods were developed in
the 1960’s when the first large scale batch and transaction-
processing systems were developed. Furthermore, the emergence of
databases in the 1970’s led to the introduction of data modeling
techniques. At the same time structured design and
analysis methods derived their origins from structured
approaches and from the evolution in programming
languages. Similarly, Welke and Konsynski(1980) characterize
advances in technologies, such as database management systems, which
were reflected in ISD methods. Likewise, today these surveys could be
extended to object-oriented technologies, mobile phones,
business process changes, and multimedia. As a result, Welke
and Konsynski emphasize that method developers should be
aware of technological developments, as they form one
key factor in improving and maintaining methods.

Likewise, Norman and Chen(1992) explain method evolution in

termsofan evolutionofapplicationsdeveloped.Theyalsorelatevolution to
CASE tools. Although they primarily discuss the evolution
of CASE, a close connection to parallel advances in
methods rec ognized. For them new applications drive the
creation of methods and later lead to the development
of CASE tools. Thus, developers should follow advances in
technologies which could support new forms of ISD methods. For
example, the emergence of graphical user interfaces and CASE
tools supported the introduction and use of methods (Chikofsky
and Rubenstein 1988).

Another indication of a method’s historical evolution can be found

by studying different versions of commercial methods such
as SDM (Turner et al. 1988), and SSADM (CCTA 1995). These were
developed over long periods of time. For example, SDM
(System Development Method), has been developed and updated
since 1974 because of the changes in software tools, organizational

18
MBA 815 MODULE 1

impact of ISs, and the need to support system maintenance (Turner et al.
1988).

3.3 Paradox to the Use of Methods

3.3.1 Low Acceptance and Use of Methods

Although the capability of methods to improve the

productivity and quality of ISD has commonly been
acknowledged, systematic use of methods is still surprisingly low
.Thus, there is a paradox here between the claimed advantages of
methods, which should indicate high use, and the empirical
observations revealing low acceptance of methods. This paradox is
further emphasized when we consider the amount of work both
industry and academics put into the development and study
of methods.

The low acceptance of methods is reported by many

professionals, confirmed by empirical research and
recognized in many studies focusing on the use of tools. For
example, Yourdon has estimated that only 10% of software
professionals have actively used structuredmethods in their
daily practice, and 50% of organizations have triedthem at
some time. Nevertheless, 90% of developers are familiar with
structured methods, emphasizing the low acceptance of methods.

In addition, several empirical studies on the use of methods

or tools confirm the estimations on the low use of
methods. A study by Fitzgerald (1995) into 162 organizations
observes that only 40% of them apply methods. Another study
by Necco et al. (1987) into 97 organizations shows that 62% of
companies used a structured approach. A study by Hardy et al. (1995)
indicates that method use can be as high as 82%. As can be seen, these
studies have different or even conflicting results. One reason for the
variety lies in the selection of the sample and in the definition of
‘method use’. First, samples are not homogeneous. For example,
Fitzgerald (1995) included small companies which did not
have large ISD projects, companies which applied packaged
software, and companies which had outsourced ISD. These companies
were also found to be less favorable to the use of methods,
which explains the lower use rate found. On the other
hand, studies concentrating on method use normally show
higher rates of method use, e.g. 82% in Hardy et al. (1995).
Nevertheless, a study by Russo et al. (1995) which focused on
organizations using methods still found that 7% of
organizations which had claimed in an earlier survey to have a method

19
MBA 815 MANAGEMENT INFORMATION SYSTEM

did not use it. Hence, even if the sample organizations would
be the same, respondents can have a different understanding of what
methods and method use mean.

Second, distinctions between levels of method use is

important, especially the borders between systematic, ad-
hoc, and no use of methods. What does it actually mean when
ISD professionals say thatthey follow some method? For example,
how fully should method use be defined and documented, how
completely should they be followed, and how widely spread
and obligatory method use should be in an organization
before we can make a judgment that methods are actually
used. For example, although in the survey by Hardy et al. (1995) 82% of
organizations claim to use methods, it does not mean that they always
follow them. In a partial solution to this problem,
Fitzgerald (1995) suggests a distinction between formalized and non-
formalized methods: a formalized method denotes a commercial or a
documented method, and a non-formalized a non-commercial or
an undefined method. An organization’s own methods could
fall into both categories. By considering only the use of
formalized methods the rate of method use drops considerably: from
40% to 26% (Fitzgerald 1995). A field study
by Smolander et al. (1990) partly confirms these findings by showing
that the methods applied were mostly a collection of loosely
coupled informal techniques. Moreover, Russo et al. (1996)
characterizes method use based on frequency — used always, seldom
or occasionally — to find out the adherence to methods. This
categorization shows that most organizations having a method actually
apply them (66%).

Thus, the diversity of the meaning of method use

and theknowledge regarding how methods are actually
used explains differences in survey results. It seems that the use
of surveys to study method use and commitment to methods.

Empirical studies, however, reveal the major benefits and drawbacks of

method use. Major benefits include enhanced
documentation, systematized ISD process, meeting requirements
better, and increased user involvement (Smolander et
al.1990, Hardy et al. 1995).

Organizations which do not use methods consider the

improvements caused by methods to be modest: methods
are considered labor-intensive, difficult to use and learn, and as
having poorly defined and ambiguous concepts (McClure 1989,
Brinkkemper 1990). Methods are also seen as limiting and slowing

20
MBA 815 MODULE 1

down development, generating more bureaucracy and being

unsuitable (Smolander et al. 1990). Hence, introduction of a
method changes the prevailing practices of ISD to such
an extent that the method is abandoned or at least
its use voluntary to summarize, method developers have
partly failed in introducing methods which would be
acceptable by the ISD community at large. There is some
empirical evidence which explains which aspects methods
and their use situations influence their
success(or(Wilyne)koop and Russo 1993).

3.3.2 Popularity of Local Method Development

A paradox that arises is the use of local methods in contrast to applying

third-party methods (i.e. commercial or text-book methods).
Surveys investigating method use in organizations as well as case
studies and descriptions of organization specific methods reveal
that organizations tend to develop their own local “variants” of methods,
or adapt them to their specific needs. Hence, there is a paradox
here between method developers proposing situation-independent
methods and method users who have developed situation-bound
methods.

Surveys indicate that local methods are more popular

than their commercial counterparts. This partly explains the
low acceptance of CASE tools which normally necessitate
the use of a fixed method. Among the surveys, both Russo et
al. (1995) and Fitzgerald (1995) show that 65% of the organizations
which use methods have developed them in-house: their own method
is preferred over a third-party one. Other studies obtain similar
figures: 62,5% (Flynn and Goleniewska 1993),42% (Russo et
al. 1996), 36% (CASE Research Corporation cited
inYourdon1992), and 38% (Hardy et al. 1995) of
organizations have
developed their own methods. Hardy’s study, furthermore, claims
that 88% of the organizations adapted the methods in-
house; the same percentage was found in the study by
Russo et al. (1995). Thus, although organizations develop their own
methods, methods need to be adapted to different use situations in the
same way as with third-party methods. This means that
organizations’ own methods do not completely fit with the
use situations in their projects. Some studies (Hardy et al.
1995), however, have found that organizations which have
developed their own methods are more satisfied with them than users of
third-party methods. This is quite obvious, since otherwise
the local method would hardly have been developed and maintained. On

21
MBA 815 MANAGEMENT INFORMATION SYSTEM

the other hand, few would announce that they have

developed abadmethod. Thus, it seems natural that methods
developed locally are considered better than third-party methods.

Unlike surveys of method use, surveys of local method development get

surprisingly similar results, although it would be
expected that the distinction between local and external methods as
well as between levels of adaptation would be more difficult to make.
However, since surveys do not go into details, they do not
provide answers about what local method development
actually means, or what aspects of method knowledge are
modified.

To sum up, many of the organizations or projects which apply methods

do not use the methods proposed by others. Commercial methods
are modified for example by simplifying or by combining them with
other methods (e.g. Jaaksi 1997), or then organizations
develop their own methods. This is noteworthy since commercial
methods claim to have a well-thought out conceptual structure together
with process models and guidance which have worked successfully in
other ISD efforts. These methods are furthermore backed by
manuals, training programs, tutorials, and tools, necessary when
introducing methods. The reason for local method development can not
be simply a negative attitude towards something developed outside the
organization (i.e. ‘not invented here’attitude). Development of a
local method requires significant expenditure of resources
which would not be needed if commercial methods were
applied. The relatively high costs, need for resources and recognized
ad-hoc method development practices (Smolander at al.
1990) would also discourage local method development efforts. Thus, it
seems that the need for more applicable methods is so great that it leads
organizations to develop their own methods, either organization specific
or project specific.

3.4 Re-Evaluation of Method Use

The two paradoxes above raise several questions about the

acceptance and applicability of methods in general and
commercial text-book methods in particular. For example, why
develop commercial methods or yet another modeling approach if
hardly anyone is going to use it? Based on the paradoxes we take a
different starting point and re-evaluate the prevailing view of
method use. Instead of viewing methods universal, fixed,
and readily applicable mechanisms for instrumental problem
solving we view methods more as being situation-bound and
describing only part of the knowledge necessary for ISD. Methods are

22
MBA 815 MODULE 1

related to an organization’s current level of expertise, and they are under

constant evolution in organizations which apply them.
Thus, the evaluation of method use describes a new understanding of
methods and seeks to explain the popularity of local methods.

The re-evaluation does not mean that methods should

not be standardized or situation-independent, or that
commercial text-book methods should not be developed. At least 14%
of organizations are still using text-book or commercial methods as
specified and without adaptation (Fitzgerald 1995).
Thesemethodsalsoprovideapoint for development of local
methods. In this unit we are, however, concerned with the rest of the
organizations: those which develop their own methods, those
which adapt available methods, and those organizations
which could benefit from methodical support once methods
have been defined and constructed to meet their contingencies.

3.5 Degree of Modifications

The degree of modifications defines how large the changes are that are
made to the local method to improve its applicability.
These modifications can be (cf. Harmsen et al. 1994):

This classification allows us to distinguish how much a method used in

an organization differs from other methods. The degree of modifications
could also compare two changes at different times in the
same method by analyzing the number of method components
changed at each time. This alternative dimension is
excluded here because ases are not reported in such detail that
categories could be formed.

Hence, in the following, each degree of method

modifications is discussed by analyzing the current method in use
(instead of the current changes).

1. Selection Paths within a Method describe one extreme of ME.

Here the only possible modification alternatives are those
provided by the method (i.e. built-in flexibility), and
thus are limited to a few contingency factors. Examples
of these contingencies include development of small versus large
systems, the use of prototyping, and the use of application packages. It is,
however, unrealistic to expect that methods should
include a much larger set of contingencies and condense
them into modification guidelines (Hardy et al. 1995).

2. A Combination of Methods for internal use

23
MBA 815 MANAGEMENT INFORMATION SYSTEM

occurs when a chosen method, and its possible selection

paths, does not meet the situational contingencies. In a
combination the local method is based on the constructs
offered by several commercial methods, and partly based on
modified or totally new constructs. A study by Russo et al.
(1996) shows that 37% of the methods used in
organizations is combinations of commercial and in-
house methods. Accordingly, the adaptation can be carried out
either by combining available methods or by modifying a
single method for internal use (e.g. Bennetts and Wood-Harper
1996, Nuseibah et al. 1996).

3. An Organization or a Project which develops its

Own Methods faces situations which are outside the set of
situations to which known methods are suited. Minor
modifications into known methods are no longer sufficient, and
thus the developed method does not have any close “relative”
among other methods.

Ryan et al. (1996) characterizes this category as an effort

to develop new conceptual. An example of a company which has
developed its own methods is USU, a consulting
company (reported in Nissen et al. 1996). The method
developed, called PFR, focused on rapid requirements capture in
team workshops and individual interviews.

Locally developed methods are often considered propriety

andinformation about them is difficult to obtain. Many of
the methodswhich can today be characterized as commercial have a
background inan organization’s internal needs. For example,
Business SystemsPlanning(IBM1984) was originally developed to
solve the problemswhich IBM noticed in the management of its own
ISs. Similar historiesare shared by Objectory (Jacobson1992)
and Octopus(Awad et al.1996).

3.6 Frequency of Method Modifications

The frequency of method modifications, explains how often a method is

changed. More specifically, it measures how often
changes in situationsare reflected in methods. From the available
cases four basic categories can be found:

1. Method Modifications Based on Advances in

External Method Knowledge are typical in organizations where
methods follow a national or industry standard or a
method-dependent CASE tool. Thus, new

24
MBA 815 MODULE 1

versionsare the result ofdecided modifications. Because

of the slow standardization process such modifications are
carried out infrequently, and do not necessarily relate to
organization specific situations.

Similarly, if the method is supported by a method-

dependent CASE tool, the vendor can dictate the frequency of
new versions. Method changes in this category do not
normally occur more often than once a year.

2. Method Modifications Based on Changes in an

Organization’s ISD Situations deal with local method
development in which contingencies related to the
whole organization change and are reflected in methods.
Examples ofsuch changes are outsourcing ISD, introducing new
technologies (e.g. Bennetts and Wood-Harper1996),or
starting to develop new type of IS. Hence, the relevant
contingencies here are the same for the whole organization).
This type of organization-wide method change can occur many
times a year.

3. Method Modifications on a Project-by-Project Basis

areconsidered inures which need to be mapped to
methods. Modifications are not made during the method use but
only at the beginning of every project. Because each
project is dealt with individually this approach is relevant to
project-based ME. The changes in methods are always
based on the schedules of the projects (i.e. a timeframe of
months in general).
4. Continuous Method Refinement happens when ISD
contingencies are uncertain or change rapidly, e.g. when a
new method or methods are used in a new area. Although
methods are typically introduced as a whole, the ME efforts
analyzed show that method adaptations occur frequently during
an ISD project.

These modifications do not occur only at the individual level, but also in
ISD projects, and in the longer run in the
rganization.

4.0 CONCLUSION

Based on the IS research literature, there appear to be at

least three possible ways to research method use. The first is to
continue the widely followed research approach to develop new
situation-independent and universal methods, compare them

25
MBA 815 MANAGEMENT INFORMATION SYSTEM

conceptually (e.g. frameworks), and use them in cases. However, this

approach, despite its use in multiple studies, has proven to be
inadequate for resolving problems related to the wider acceptance
of methods. The second option is to pursue
comprehensive empirical studies on methods in realistic environments.
Although this proposition is basically correct, it is not
a realistic approach for today’s organizations. The third
option is method engineering: to focus on mechanisms
that support local method development and use.

5.0 SUMMARY

• In designing and developing management information

systems despite the efforts poured into method
development and research, there seems to be no universal
agreement whether methods are useful in ISD at all.
• The other assumption behind scientific reductionism
(Fitzgerald 1996) is that the developer can obtain detailed
knowledge about the problem situation and about applicable
methods.
• In addition, several empirical studies on the use of methods or
tools confirm the estimations on the low use of methods.
• The low acceptance of methods is reported by many
professionals, confirmed by empirical research and
recognized in many studies focusing on the use of tools.
• The underlying paradigm behind many ISD methods
is scientific reductionism. This rests on the assumption that
the solution can be achieved through a sequence of
steps, decisions, and deliverables pre-defined in the method
knowledge.
• Method developers have partly failed in introducing methods
which would be acceptable by the ISD community at large.
• Methods are related to an organization’s current level of
expertise, and they are under constant evolution in
organizations which apply them. Thus, the re-evaluation
of method use describes a new understanding of
methods and seeks to explain the popularity of local
methods.
• Many of the organizations or projects which apply methods do
not use the methods proposed by others. Commercial
methods are modified for example by simplifying or
by combining them with other methods (e.g. Jaaksi 1997), or
then organizations develop their own methods.
• Method developers have partly failed in introducing methods
which would be acceptable by the ISD community at large.
There is some empirical evidence which explains which

26
MBA 815 MODULE 1

aspects of methods and their use situations influence

their success (or failure) (Wynekoop and Russo 1993).
• An organization or a project which develops its own methods
faces situations which are outside the set of situations to
which known methods are suited.

In the next study unit, you will be taken through strategic planning
for design of information systems.

6.0 TUTOR-MARKED ASSIGNMENT

1. Identify and compare the paradox to the use of

Information Systems Design methods.
2. Discuss the concepts behind the development of
information system methods.

7.0 REFERENCES/FURTHER READING

Information Resources Management (2003).The Department of Justice

Systems Development Lifecycle Guidance Document.

Norton, P (1995). Introduction to Computers.Macmillan/McGraw-Hill.

27
MBA 815 MANAGEMENT INFORMATION SYSTEM

UNIT 3 STRATEGIC PLANNING FOR DESIGN

OF INFORMATION SYSTEMS

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Definition
3.1.1 What is Strategic Information Systems Planning?
3.2 Factors that Initiate Strategic Information System Planning
3.2.1 Major Corporate Changes
3.2.2 External Competitive Opportunities or Threats
3.2.3 Evolution Changes
3.3 Major Contents of Information System Strategic Plan
3.3.1 Business Information Strategy
3.3.2 Information System Functional Strategy
3.3.3 InformationSystem/InformationTechnology
Strategy
3.4 Hierarchy of Company Strategies
3.5 Benefits and Importance of Strategic Information Systems
Planning
3.6 Factors for Failure of Information System Strategy
3.7 How to Develop an Information System Strategy
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

This unit introduces you to strategic information systems

planning, factors that initiate strategy information system planning,
major contents of information system strategic plan and
hierarchy of company’s strategies.

It also exposes you to the importance’s and benefits

of strategic information systems planning, factors
responsible for the failure of information system strategy and
how to develop an information system strategy.

28
MBA 815 MODULE 1

2.0 OBJECTIVES

The objectives of this unit among others are for you to:

• understand what is strategic information system planning

and how the concept associates with the general principle of
strategic planning
• identify the factors that initiates strategic information
system planning
• be able to know the major components of
atypicalinfsystem planning
• beabletoknowthestepsthathastobe takenindestrategic
information system plan for an organization
• answer the question of factors that influence the output of a
strategic information system plan.

3.0 MAIN CONTENT

3.1 Definition

Strategic planning is the process by which an organization identifies its

businessobjectives; selects the acceptable means to achieve them;
initiates the necessary causes of action and allocation of resources
Neither general strategic planning nor information systems planning are
simple activities but most managers will say that they
perform more effectively if they plan and stick to the objectives of the
plan.

Despite ahistoryofneglected planning,information system and

development need effectivestrategic planning asmuch andmore
than other functional areas. Just as other functional areas
information system consumes a portion of organization’s
finiteresources. Without a clear view of value (the aim
is(planning),allocation of resources is unlikely to match that value.

Information system must accommodate rapid technological changes, its

projects are often very high cost, and increasingly
competitive, organizational well-being depends on information
system delivering those systems that enable the business to function
effectively. Planning and implementing an appropriate information
system strategy produces the organizational confidence that
information system will cost-effectively deliver those
strategic systems. Systems without planning will mean for most
organizations not only financial loss, but additional burden and
often greater cost such as lowered staff morale,
opportunities, continuous management fore-fighting and

29
MBA 815 MANAGEMENT INFORMATION SYSTEM

customer dissatisfaction. Planning helps an organization to identify it

information need and find new opportunities for using that information
and it defines the activities needed to implement the chosen strategy.

While management information system produces information

that assists managerial decision-making, information systems
strategy is a plan for information system and their supporting
infrastructures which maximizes the ability of management to
achieve organizational objectives.

Underlying all management activities in government and

organizations is information, made useful and available through
information systems.

Many organizations have invested in information technology to improve

their information system but done so in bad adhoc manner, dealing with
each new system on its own merits. Some overarching mechanism
is therefore needed to guide and coordinate the use of the
information technology. Information system strategy is such a
mechanism.

Information system strategic planning consists of a series of steps from

identifying organizational objectives to auditing information
system resources, to prioritizing future information system
developments to detailing an implementation plan. As a strategic
exercise affecting the whole organization, it must involve senior
management

An organization’s information strategy and the plan that documents

it must be consistent with:

• Its corporate plan

• Its management review of the role of information
system in the organization, and
• Its stage of maturity of use and management information system.

3.1.1 What Is Strategic Information Systems Planning?

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

30
MBA 815 MODULE 1

achieve the most cost-effective system for satisfying the

organization’s needs. The process must consider system’s
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 system’s 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.

3.2 Factors that Initiate Strategic Information

SystemPlanning

Information system planning like any planning, is not a one-off activity,

ideally it would be a continuous cycle synchronized with or better yet,
embedded into the cycle of general business
planning. Given o rganizations may address information
system’s planning different ways, there is still a potentially
common circumstance that requires reassessment of the
information system’s strategic planning. Short-term
plan elements of the plan will naturally require frequent
revision reflect technological changes. The reassessment
referred here is long -term element that provides the sense of
direction; the what of the plan (the short-term element providing the
how of the plan).

Three common circumstances that initiate and alter the objective of an

information system’s plan are:

• Major Corporate Changes

• External Competitive Opportunities or Threats
• Evolutionary Changes in information System Maturity

3.2.1 Major Corporate Changes

When there is a major corporate change the symptoms are usually plain
to see. The collective result of new owners, management, rationalization
programmes, restructuring exercises or other corporate
changes is analteration in the real or perceived role of information
system in matching the needs of the new business. There is now a
different business that needs things from information system. If
these obvious symptoms are present, then the information system’s
strategy is likely to have as its objective, the definition of new role

31
MBA 815 MANAGEMENT INFORMATION SYSTEM

for information system. Its scope will be uncertain, but the emphasis is
to build upon senior management to the changing role of information
system within the new organization.

3.2.2 External Competitive Opportunities or Threats

The likely symptoms of this type of change are the emergence of new
markets and/or products that may be created by information system
or the competitive need for major cost factor
changesandperformance. Again this need may be generated by
information system
itself, or the awareness of new challenges and advantages emerging, and
yet again opportunities/threats may be driven by information
system.

This set of circumstances is likely to produce a plan where objectives is

to move information system’s resources in the widest sense of the term,
into the new but long-term commitment to high
benefits or threat protection. The scope of the plan
created to respond to these circumstances is likely to be
much more limited than the strategies produced in other
situations. This plan focuses efforts and resources upon those
areas where the most good can be achieved. The emphasis of
the plan is to exploit information system strengths and weaknesses
of the competitors by being entrepreneurial and developing new
attitudes, skills and uses of information system in these new
commitments.

3.3.3 Evolutionary Changes

Probably a more frequent reason for reassessing the

information system’s strategy is that information system
itself experiences an evolutionary change. The most
noticeable symptoms of this are changing view on the required
level of control over information system or its budget allocations, and/or
the degree of dissatisfaction expressed by everyone. Growing is
always painful since moving from one state to another generates
fears and anxieties. Under these circumstances theplan’s
objective is to get and keep the senior management commitment,
if not already present, and to demonstrate managed
evolution. The emphasis is upon setting and resetting resource
levels and styles and releasing and controlling information system in
the appropriate way for the stage of growth.

32
MBA 815 MODULE 1

3.3 Major Contents of Information System’s Strategic Plan

The content of a given organization’s strategic planning

may vary widely depending on its particular emphasis,
and it should not be forgotten that the process would
tend not to be captured in the plan document but are
nonetheless real. However once created, the plan is a
conception of the future and therefore aims to achieve two things:

• Clearly identify where information system intends

to go, and to avoid the danger of getting lost i.e. taking
courses of action that do not contribute to the overall mission.
• Provide a fundamental set of benchmarks so that
progress in this journey can be monitored.

Despite the possible variety of formats, it is possible to

identify the necessary core elements to the information system plan,
which are:

1. A clear statement of the information system objectives, that gives

a clear sense of direction i.e. where the organization wishes to be.
2. An inventory and assessment of both the current
organizational capabilities and problems resulting from current
practices i.e. where the organization is now.
3. A concrete implementation plan that translates the sense of
direction and knowledge of the start point into a navigable route
map, i.e. how to get from point’1’ to ‘2’. The plan must
identify both long-term and short-term actions and
resources allocations. Additionally, theinformation
system’s strategic plan must acknowledge that
organizational change is an almost inevitable
corollary to the planning process.

Ward, in his model of a planning process, suggests that the information

system’s strategic planning should contain three major elements:

3.3.1 Business Information Strategy

This indicates how information will be used to support the

business. Priorities that the organization has for systems development
are defined in general, perhaps by suggesting a portfolio of
current and required systems. It may outline information
requirements via blueprints, a pplication development of the future
are defined.

33
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.3.2 Information System Functional Strategy

This indicates what features and performance the organization will need
for the system. It demonstrates how the resources will
be used, provide policy guidelines for the information resource
management and perhaps policies for communication networks,
hardware architecture, software infrastructures and management
issues such as security, development approaches, organizations and
allocation of resources.

3.3.4 Information System/Information Technology Strategy

These define policies for software and hardware; for

example, standards to be used and any stand on preferred
suppliers. These alsodefine the organizations stand on the information
system organized. For example, whether it is to be centralized or
distributed, what are to be the investment, vendor and human impact
policies, and information systems techniques.

34
MBA 815 MODULE 1

35
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.5 Benefits andImportance of Strategic Information

Systems Planning

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 informationneeds
on the basis of aidentification 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
moststructure 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.

A successful strategy brings the following benefits:

• Information System opportunities and needs are
identified and prioritized according to the organization’s
fundamental objectives rather than to technical criteria

• Top management develops commitment to a strategic

vision for information system
• Methods for future information system’s development,
management and investment decision are specified

• Compatibility between information systems is ensured, thus

avoiding wasted investments.

3.6 Factors for Failure of Information System’s is Strategy

Information system is planning may falter when:

• There is little demand for information and little

experience of the problems caused by an adhoc approach to
information system
• There are insufficient in-house skills in strategic
planning; IS analysis, design and managing; management

36
MBA 815 MODULE 1

services; and project management

• Organizational sub-unit resists this top-down approach
• The required participation, openness and feedback are not present
• Departments are unwilling to share their information with others
• The external environment is too unstable to permit
long-term planning.

3.7 How to Develop an Information System Strategy

Overall, the strategic planning exercise answers three questions:

1. Where are we now?

2. Where do we want to be?
3. How do we get there?

Information System strategic planning is presented as a

complete, objective, depersonalized, step-by-step process. Of course, in
reality, no process is like this. The steps recommended must therefore
be taken as approximate parameters within which fallible,
political process of argument, negotiation and iteration will take
place.

First, create a strategic decision-making- the IS Steering

Committee. This will consist of departmental heads and IT manager
with the clout to push through change. They set the scope by deciding
which of the steps presented is relevant. They set the resources for
strategic planning, make decisions on the options suggested, and ensure
plans are implemented. Teams to produce strategy report and to
implement the action plan are also required.

Therefore the following are required in developing an

information system strategy:

1. Understand Organizational Objectives

Information systems help the organization achieve its
objectives. If objectives are not known, use short-term plans instead
even though this makes it difficult to prioritize and
review IT’s contribution toorganization.Undertake a
survey to outline and prioritize both organization’s
information related opportunities presented bytechnological
developments.

2. Establish Organizational Information Requirements

Identify the informationrequiredtosupporttheorganization’s key
activities. Information may be generic and shared across
the organization or specific to a particular sub-unit. Performance

37
MBA 815 MANAGEMENT INFORMATION SYSTEM

indicators, information flows and timeliness of data are identified.

3. Outline Generic Systems and Technology to Meet

Organizational Information Requirements
Provide a generic description of information system required
and the technologies on which to base them. For
example, there might overlap in the informationneeds
of organizational units. Afinancial information
system could be proposed, based on a computer network. Present
alternative solutions with their costs and implications.

4. Conduct Information System Audit

5. Survey the organization’s existing information-related

resources
This audit includes organizational structure and staffing; paper-based
records; computer application with their hardware, software
and networks; IS undergoing or awaiting development; and sources of
training and support. The gap between existing and required
Information System is identified.

6. Determine Major Issues Affecting Information System

• Finance and skill constraints
• Socio-cultural constraints including political pressures, the
relatively slow rate at which organizations can
assimilate new information system, and difficulties of ensuring
staff participation in information system implementation
• Short-term need to improve paper-based records versus
long-term need to computerize them
• Conflicting forces of centralization, standardization and
decentralization, if information and staff are to move freely
within the organization, then standards for data items,
software, hardware and networking must be imposed.
The spread of open standards, independent of any
individual vendor, is helping but organizational
units are to build their own microcomputer-based information
system
• Technical issues such as down-sizing, that is, the move away
from information system based on single, large mainframe
computers to cheaper, easier information system based
on networks of microcomputers
• Access to and attitude of information system
vendors and developers.

7. Decide Information System Priorities and Strategies

38
MBA 815 MODULE 1

Consider the finding so far with the information

systems Steering Committee; provide a broad indication of system
priorities, and choose between alternatives such as different types
of technology. Full costs and benefits are impossible to
estimate with any real accuracy. Cost-benefit analysis should
therefore be treated as an informed guess, assisting a
prioritization process decided more on gut feelings and
organizational, political factors.

8. Estimate Alternatives and Decide about

• Implementation by existing computer center, by
delegation to individual units, by creating a new information
system organization, or by contracting out. This includes:
- System Development, that is, creating new
system in-house (providing a better fit to needs) or by
buying a package fromoutside (providing a quicker cheaper
solution).
- Training, using in-house technical staff, or in-
house users, or vendors or external users
- System Operation that is, running and
supporting computer systems with in-house staff
or contracting to a facility management firm.
• Procedure for tendering and selecting externally purchased
services.
• Standard methodologies to use for information system
development.

9. Determine Role of Financial and Human Resources

Provide core specific details on funding, its source and time-scale; on
any new organizational structures; on management of new information
system and related organizational changes; on new skills needed and old
skills no longer needed, and implication for training and job.

10. Detailed Action Plan for Strategy Implementation

11. Manage, Review and Evolve Information System Strategy

Strategic planning is a continuous process. Completely review the plan at
the end of the strategic framework period or earlier if circumstances
change or if objectives are not attained.

Information system strategic planning takes six months to a

year to complete, and usually provides a strategic framework
for a five-year period. It produces a strategy report
containing evidence, analysis, arguments, and proposals on the
steps outlined above. This is circulated in shortened form as a
strategy statement. Once implemented, strategy will often

39
MBA 815 MANAGEMENT INFORMATION SYSTEM

produce cross-organizational information system.

4.0 CONCLUSION

The purpose of strategic planning for information system is to identify

the most appropriate targets for technological support, and to
schedule that technological adoption. Also, it is desirable to plan
ahead for the information system function and that planning should be
at a strategic, organizational level; it should not be at the project
planning level, that is where decision has already been taken
about which project is to implemented. Orderly planning
allows information system to focus on higher levels than simply
completing projects.

5.0 SUMMARY

• Strategic planning is the process by which an organisation

identifies its business objectives; selects the acceptable means to
achieve them; initiates the necessary causes of action and
allocation of resources.
• Systems without planning will mean for most organizations not
only financial loss, but additional burden and often, greater cost
such as lowered staff morale, missed opportunities, continuous
management fore-fighting and customer dissatisfaction.
• While management information systemproduces information
that assists managerial decision-making, information systems
strategy is a plan for information system and their
supporting infrastructures which maximizes the ability
of management toachieve organizational objectives.
• Strategic information system’s 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.
• Probably a more frequent reason for reassessing the
information system strategy is that information
system itself experiences an evolutionary change.
• Information system planning like any planning is
not a one-off activity; ideally it would be a continuous cycle
synchronized with or better yet, embedded into the cycle of
general business planning.
• Despite the possible variety of formats, it is possible to identify
the necessary core elements to the information system plan.
• Provide a generic description of information system required and
the technologies on which to base them.
• Full costs and benefits are impossible to estimate
with any real accuracy. Cost-benefit analysis should

40
MBA 815 MODULE 1

therefore be treated as an informed guess, assisting a

prioritization process decided more on gut, feelings, and
organizational, political factors.

The next study takes you through initiation of system

design and development

6.0 TUTOR-MARKED ASSIGNMENT

1. Discuss with examples some of the factors responsible

for the failure of information System strategies.
2. Under what conditions do we observe the development of
strategic plans within an organization?

7.0 REFERENCES/FURTHER READINGS

Information Infrastructure Service (1994).Information

TechnologyStrategic Plan.

Ward, J, (1987). Integrating Information System into

Business Strategies.Long Range Planning, Vol. 20 no 3.

Ward, J. Griffiths, P, Whitmore, P (1990). Strategic Planning

for Information Systems.

Windey R. (1997). Strategic Management and Information Systems, FT

Prentice Hall.

41
MBA 815 MANAGEMENT INFORMATION SYSTEM

UNIT 4 INITIATION OF SYSTEM DESIGN AND

DEVELOPMENT

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Definition
3.1.1 Purpose of Initiation
3.2 Tasks and Activities
3.3 Approach to System Design Initiation
3.3.1 The Statement of Requirement
3.3.2 The Project Plan
3.3.3 The Quality Plan
3.3.4 Project Control and Reporting
3.3.5 Project Control Log
3.3.6 Project Completion
3.3.7 Project Initiation Checklist of Requirements
3.4 Roles and Responsibilities
3.5 Deliverables
3.6 Issues for Consideration
3.7 Phase Review Activity
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Reading

1.0 INTRODUCTION

From the previous study unit, you have learnt about

the strategic planning for design of information systems.
This unit focuses on approach to systems design initiation, related
tasks and activities, phase review activities, deliverables, roles
and responsibilities related to system design and development.

2.0 OBJECTIVES

The objectives of this unit of the course are for you to:

• understand what is, and how to initiate a information system

design and development project
• explain the factors that trigger the initiation of information
system isdesign
• identify the activities that constitutes the initiation process
• have a checklist to guide in the process of design initiation.

42
MBA 815 MODULE 1

3.0 MAIN CONTENT

3.1 Definition

Design project initiation may be defined as the

process of panned deliverables and anticipation of those actions
needed in order to complete a design project. It will involve the
identification of activities, tasks and a sequence in a project
schedule, including both milestones and deadlines. In addition, it
involves estimating those resources that will be needed in the project
together with projected costs.

This is when the individual project is initiated. The project is scoped; the
project objectives and benefits are established; the end users identified,
the project SWOT is identified; risk analysis is
performed; sponsor is identified; project funding is obtained; and a
project plan is approved.

3.1.1 Purpose of Initiation

The Initiation Phase begins when management

determines that it necessaryto enhance a business process
through the application information technology. The purposes of
the Initiation Phase are to:

• Identify and validate an opportunity to improve

business accomplishments of the organization or a
deficiency related to business need,
• Identify significant assumptions and constraints on solutions to
that need, and
• Recommend the exploration of alternative concepts and
methods to satisfy the need.

MIS projects may be initiated as a result of business

process, improvement activities, changes in business
functions, advances in information technology, or may arise
from external sources, such public law, the
generalpublicorstate/local agencies.TheSponsor articulates this
need within the organization to initiateproject life cycle.
During this phase, a Project Manager is appointed who
prepares a Statement of Need or Concept Proposal.
When opportunity to improve business/mission accomplishments or to
address
a deficiency is identified, the Project Manager documents
these opportunities in the Concept Proposal.

43
MBA 815 MANAGEMENT INFORMATION SYSTEM

Figure 4.1: Design Project Initiation Diagram

3.2 Tasks and Activities

The following activities are performed as part of the Initiation

Phase. The results of these activities are captured in the Concept
Proposal. For every MIS project, the agency should
designate a responsible organization and assign that organisation
sufficient resources to execute the project.

Identify the Opportunity to Improve Business Functions

Identify why a business process is necessary and what business benefits
can be expected by implementing this improvement. A business scenario
and context must be established in which a business problem is clearly
expressed in purely business terms. Provide background information at a
level of detail sufficient to familiarize senior managers to the
history, issues and customer service opportunities that can be
realized through improvements to business processes with the
potential support of IT. This background information must
not offer or predetermine any specific automated solution, tool,
or product.

Identify a Project Sponsor

The Project Sponsor is the principal authority on matters regarding the
expression of business needs, the interpretation of
functional requirements language, and the mediation of
issues regarding the priority, scope and domain of business

44
MBA 815 MODULE 1

requirement.

Form (or Appoint) a Project Organization

This activity involves the appointment of a project manager who carries
both theresponsibilityand accountabilityforexecution.Small efforts,
this may only involve assigning a project to a manager
withinan existingorganizationthatalreadyhas aninherent
structure.Fornew,majorprojects,acompletelynewelement may be formed
- requiring the hiring and reassignment of manytechnical and business
specialists.

Each project shall have an individual designated to lead the effort. The
individual selected will have appropriate skills, experience,
credibility, and availability to lead the project. Clearly
defined authority and responsibility must be provided to the Project
Manager.

The Project Manager will work with Stakeholders to identify the scope
of the proposed program, participation of the key
organizations,potential individuals who can participate in the
formal reviews of the project. This decision addresses both
programmatic and information management-oriented participation as
well as technical interests in the project that may be known at this time.
In view of the nature and scope of the proposed program, the key
individuals and oversight committee members who will become the
approval authorities for the project will be identified.

Document the Phase Efforts

The results of the phase efforts are documented in the Concept Proposal.

Review an Approval to Proceed

The approval of the Concept Proposal identifies the end of the Initiation
Phase. Approval should be annotated on the Concept Proposal by
theProgram Sponsor and the Chief Information Officer (CIO),
or Chief Executive Officer (CEO) and the management.

Other forms of tasks include the following

• Set initial project objectives and scope.
• Define project scope.
• Define project's benefits.
• Identify sources of business knowledge.
• Prepare preliminary project timeline.
• Determine preliminary project costs.
• Establish business user participation.
• Identify source of project funding/resources.
• Decide whether to continue with project.

45
MBA 815 MANAGEMENT INFORMATION SYSTEM

• Prepare project plan.

• Create formal project plan document.
• Set analysis stage standards.

3.3 Approaches to System Design Initiation

When a consultant is assigned in order to advise on project

initiation, there will be a very structured approach as to how advice
will be given.

One of the first actions on a project, once the client has confirmed
the appointment of the consultant, will be to confirm the appointment of
the project manager. The organizational structure and hierarchy must be
put in place as a necessary first step. This will include the defining
of the roles and responsibilities associated with this
structure. Figure 4.2 defines a typical organisation structure for a
project start-up situation.

Figure 4. 2

Establishing Structure
The success and profitability of a project is normally determined at the
time a design project plan is established. Where the plans are properly
completed, easy to understand and well defined, then the
project will normally succeed. The approach to follow assumes that a
contract is not yet in place and will be one of the
activities completed during project initiation stage.

46
MBA 815 MODULE 1

3.3.1 The Statement of Requirement

The project manager (or the advising consultant adopting this role) must
ensure that the project sponsor has produced a written
Statement Rfequirements (SOR). This must be a thorough document
which is:

• Unambiguous
• fully defined or complete
• verifiable deliverables
• no conflicts
• consistent
• auditable

The SOR will be the document against which change control

will be exercised. The SOR should be closely matched to the contract
and there should be no conflict of interests between the two. Where
consultantsare involved, the client or sponsor, SOR, will normally form
the basis of the proposal. All of these documents must
carefully align and there should be no scope for
misinterpretation, confusion, or lack of understanding. This
will be the cornerstone of the project.

3.3.2 The Project Plan

The Project Plan is a vital part of the project initiation stage. The plan
should normally contain the following information:

• Introduction and status of the plan

• The authorization procedures
• Statement of project objectives
• Statement of requirements
• Deliverables in the project
• A Work Breakdown Structure
• The project milestones
• The resource requirements
• Interdependencies of work
• The timetable of events
• Staffing, organization, and responsibilities
• Development methods and toolsets to be used
• Source documentation
• Resource and financial summary

This information creates the generation of a Project Book (log). The log
should be in a loose-leaf binder with clearly identified
sections version control exercised over the documentation sets.

47
MBA 815 MANAGEMENT INFORMATION SYSTEM

These logs are now often retained as computer file, which enables
a greater level of security to be maintained over them
and version control to be established as an automatic feature.

3.3.3 The Quality Plan

Every project must have a quality plan. The quality

plan will be presented as a section in the project plan. It is drawn up
by the project manager at the start of the project and should be agreed
with the project sponsor. You would expect the quality plan
to contain the following elements:

• Statement of the quality control organization

• Identification of specific standards and methods that will be used
• Definition of the quality control procedures; this is
aligned to the Work
• Breakdown structure
• Specification of quality milestones
• Detail of unusual features
• Change, control, and configuration management
• Detail of acceptance procedures
• Specification of quality assurance procedures

3.3.4 Project Control and Reporting

Project control may be considered to be one of the continuous objectives

for the project manager. As such he is responsible for taking
remedialactions, within the defined terms of reference, to
correct potential problems or taking risk avoidance measures. The
prime objective is to protect the integrity of the project at all times.

Formal methods assist in control procedures by having project steering

committees that meet at regular intervals and at project milestones.

The frequency of project reporting is agreed at the outset of the project. It

is normal for status reports to be produced at weekly intervals. These are
then consolidated at monthly intervals to show:

• Project Status Report

• Financial Status Report
• The Client Report

Reports should describe any deviations from plan and

highlight any problems on the project. They should clearly state any
corrective action taken, person responsible, date to be
achieved and anticipated result. Reports should also indicate

48
MBA 815 MODULE 1

progress against milestone achievement.

3.3.5 Project Control Log

It was mentioned earlier that a Project Control Log

should be maintained by the project manager. It is useful to note what
information should be contained in the log and maintained:

• Copy of contract
• Project terms of reference
• Statement of Requirement
• The Project Plan (including Quality Plan)
• Project status reports
• Financial status reports and cost estimates
• Resource Plans
• Client Reports
• Milestone Reports
• Exception Conditions
• Change Control documents
• Deliverable Reports
• Summary completion reports
• Quality control records
• Resource resumes (CVs)
• Cost Ledgers
• Expense Reports

3.3.6 Project Completion

At theend of projects the project manager has

certain actions.aandatory
It is important that these actions are fully understood at
project initiation time. The following checklist is offered to assist this
process:

• Produce a project debriefing report raising any important issues

that may assist future projects.
• Report on the actions taken to address any QA issues raised.
• Obtain written acceptance documents from the Acceptor.
• Get a written approval from the project sponsor in order to say
that contractual conditions have been met.
• Raise a final completion report on the projectindicatingbe
achieved.
• Archive a complete version of the project log including
electronic (soft copy) backups.
• Lodge any specific standards with QA office.
• Conduct external project compliance audit and comply with
findings for close-off procedures.

49
MBA 815 MANAGEMENT INFORMATION SYSTEM

• Report to the programme manager where the project forms part of

a large programme.
• The programme manager must also sign off as complete.

3.3.7 Project Initiation Checklist of Requirements

As an aid to help in considering depth of coverage at project initiation, I

have provided a brief checklist for compliance checking:

• Every project must have a project manager appointed.

• No individual shall QA his or her own work.
• The client must provide a written Terms of Reference statement.
• There must be an agreed contract.
• Each project must have a plan.
• There must be a quality plan.
• There must be plans to cover (a) a detailed work
breakdownstructure, (b) costs, (c) resource estimates.
• Reporting frequency and structure must be defined.
• Methods and toolsets to be used are to be defined.
• A project log must be set up.
• Documentation standards are to be complied with.
• Milestone reporting — a must!
• Deliverable reporting — a must!
• Project benefits must be assessed and quantified at the
end of the project.
• Control documents must be maintained.
• Configuration control andversions mustbemaintained for
audit trail.
• Individual roles and responsibilities must be clearly defined.
• Maintain record over all internal/external communications.
• The project log must be kept up to date at all times and
when the project is complete it should be properly archived.
Upon completion of project initiation in the management
process, we should have achieved:
• A clear definition of the deliverables in the project.
• clear understanding of the relationships between individuals in
the project organisation structure, including roles and
responsibilities.
• Personal commitments for the deliverables.
• The levels of personal commitments are achieved by
establishing explicit goals for individuals. It is necessary to
ensure that there is a clear understanding of the
deliverables. With responsibilities and goals clearly
understood, there should never be any ambiguity about
the project.
• Top of Form.

50
MBA 815 MODULE 1

3.4 Roles and Responsibilities

1. Sponsor: The Sponsor is the senior spokesperson for the project,

andis responsible for ensuring that the needs and
accomplishmentswithin the business area are widely
known and understood.Sponsor is also responsible for
ensuring that adequate resources toaddress their
businessarea needs are made available in amanner.
2. Project Manager: The appointed project manager is charged
with leading the efforts to ensure that all business aspects of the
process improvement effort are identified in the
Concept Proposal. This includes establishing detailed project
plans and schedules.

3.5 Deliverables

The following deliverables shall be initiated during the Initiation Phase:

Concept Proposal - This is the need or opportunity to improve business

functions. It identifies where strategic goals are not being met or mission
performance needs to be improved. .

3.6 Issues for Consideration

Inthisphase,itisimportanttostatetheneedsorbusiness terms. Avoid

identifying a specific product or vendor as thesolution. The
Concept Proposal should not be more than2-5 pages inlength.

3.7 Phase Review Activity

At the end of this phase, the Concept Proposal is

approved proceeding to the next phase. The Concept Proposal should
convey that this project is a good investment and identify any potential
impact on the infrastructure/architecture.

The phase output should bring approval to launch a project of defined

mission and scope. It should include the following:

• Information System Preliminary Requirements

• Project Scope Document
• Preliminary Project Plan
• Next Stage Project Plans
• Needs Analysis Report
• Decision As To Whether To Proceed With Project As Defined.

51
MBA 815 MANAGEMENT INFORMATION SYSTEM

4.0 CONCLUSION

The cause of many project failures can be traced back to the early days
of the project. What eventually causes it to come tumbling down is often
visible from the start. The fault is that everyone hoped it would go away.
It is the responsibility of the Project Manager to identify these problems,
and either solve them, or escalate them to the Sponsor.

The Sponsor has a responsibility to the project. Part of

that responsibility is, at any point in time, to decide if the
project should continue. If there is a major success-threatening
issue that the Project Manager cannot resolve, and the Sponsor
cannot resolve, the Sponsor has the obligation to stop the project.
On the other hand, if the Project Manager cannot solve the problem,
and the Sponsor can, the Sponsor has an obligation to fix the problem.

Project initiation is about scouting around to find out if there are

any problems that will impede progress and addressing them on
day one.

The further the project goes, the harder they are to fix. It also means that
planning can be more effective because, the project
manager better understands the context of the project.

Project initiation and interviewing stakeholders is not about

gathering requirements. It is about understanding if we
have a project, does everyone see it as the same project and can it
be a successful project.

5.0 SUMMARY

• Design project initiation may be defined as the process of

defining planned deliverables and anticipation of those
actions needed in order to complete a design project.
• The Initiation Phase begins when management determines that
it is necessary to enhance a business process through the
application of information technology.
• MIS projects may be initiated as a result of
business process improvement activities, changes in
business functions, advances in information technology, or may
arise from external sources, such as public law, the general public
or state/local agencies.
• The approval of the Concept Proposal identifies
the end of the Initiation Phase.
• The success and profitability of a project is normally determined
at the time a design project plan is established.

52
MBA 815 MODULE 1

• The Project Plan is a vital part of the project initiation stage.

• Every project must have a quality plan. The quality
plan will be presented as a section in the project plan.
• At the end of projects the project manager has certain
mandatory actions.
• The levels of personal commitments are achieved by
establishingexplicit goals for individuals.
• When a consultant is assigned in order to advise on project
initiation, there will be a very structured approach as to
how advice will be given.
• The Sponsor is the senior spokesperson for the
project, and is responsible for ensuring that the needs and
accomplishments within the business area are widely known and
understood.
• At the end of phase review activities, the
Concept Proposal is approved before proceeding to the next
phase.

In the next unit, you will be exposed to concept

developmentplanning of system design.

6.0 TUTOR-MARKED ASSIGNMENT

1. Discuss thefactors thatcanbringabouttheinitiationof

management information system design.
2. Enumerate 5 project design tasks and activities.

7.0 REFERENCES/FURTHER READING

Glenn Strange; Project Initiation- a Consultancy Approach. Neville

Turbit (2006). Project Perfect.

University of California, (1997).Davis; Application Development

Methodology.

53
MBA 815 MANAGEMENT INFORMATION SYSTEM

UNIT 5 CONCEPT DEVELOPMENT AND PLANNING

OF SYSTEM DESIGN

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Tasks and Activities
3.1.1 Concept Development
3.1.1.1 Concept Development
3.1.1.2 Planning
3.2 Roles and Responsibilities
3.2.1 Concept Development
3.2.2 Planning
3.3 Deliverables
3.3.1 Concept Development
3.3.2 Planning
3.4 Issues for Consideration
3.4.1 Concept Development
3.4.2 Planning
3.5 Phase Review Activity
3.5.1 Concept Development
3.5.2 Planning
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Reading

1.0 INTRODUCTION

This unit dwells on planning of system design and the development

of their concepts. It further examines issues on task and activities, roles
and responsibilities, deliverables and finally, activities on phase review.

2.0 OBJECTIVES

This unit is designed in such a way that you will be able to:

• understand what constitutes concept development in

designing and developing information system
• explain what constitutes planning in designing and
developing information system
• identify the tasks you need to embark on during
the concept development phase of system’s development
• identify the tasks you need to embark on during the planning

54
MBA 815 MODULE 1

phase of system’s development

• comfortably answer the question of responsibilities
and roles in executing the conception and planning of a
project.

3.0 MAIN CONTENT

3.1 Tasks and Activities

3.1.1 Concept Development

System Concept Development begins when the Concept Proposal

has been formally approved and requires study and analysis that may
lead to system development activities.

The review and approvaloftheConceptProposal begins

thestudies and analysis of the need in the System Concept
Development Phase and begins the life cycle of an identifiable project.

Planning
Many of the plans essential to the success of the
entire project created in this phase; the created plans are then
reviewed and updated throughout the remaining SDLC
phases. In the Planning Phase, concept is further developed to
describe how the business will operate once the approved system is
implemented and to assess how the system will impact employee and
customer privacy. To ensure the products and/ or services provide the
required capability on-time and within budget, project resources,
activities, schedules, tools, and reviews are defined. Additionally,
security, certification and accreditation activities begin with
identification of system security requirements and the completion
of a high-level vulnerability assessment.

3.1.1.1 Concept Development

The following activities are performed as part of the System

Concept Development Phase. The results of these activities are
captured in the four phase documents and their underlying
institutional processes and procedures (See Figure 4-1).

55
MBA 815 MANAGEMENT INFORMATION SYSTEM

MBA 815 MANAGEMENT INFORMATION

SYSTEM

Study and Analyze the Business Need

The project team, supplemented by enterprise architecture
or other technical experts, if needed, should analyze all
feasible technical, business process, and commercial alternatives to
meeting the business need. These alternatives should then be
analyzed from a life cycle cost perspective. The results of these studies
should show a range of feasible alternatives based on life cycle cost,
technical capability, and scheduled availability. Typically, these studies
should narrow the system technical approaches to only a few
potential, desirable solutions that should proceed into the
subsequent life cycle phases.

Plan the Project

The project team should develop high-level (baseline) schedule,
cost, and performance measures which are summarized in
the System Boundary Document (SBD). These high-level
estimates are further refined in subsequent phases.

Form the Project Acquisition Strategy

The acquisition strategy should be included in the SBD. The
project team should determine the strategies to be used during the
remainder of the project concurrently with the development
of the CBA and Feasibility Study. Will the work be accomplished
with available staff or do contractors need to be hired? Discuss
available and projected technologies, such as reuse or Commercial
Off-the-Shelf and potential contract types.

56
MBA 815 MODULE 1

Study and Analyze the Risks

Identify any programmatic or technical risks. The risks associated with
further development should also be studied. The results
of these assessments should be summarized in the SBD and
documented in the Risk Management Plan and CBA.

Obtain Project Funding, Staff and Resources

Estimate, justify, submit requests for, and obtain resources to
execute the project in the format of the Capital Asset Plan and
Justification

Document the Phase Efforts

The results of the phase efforts are documented in the System Boundary
Document, Cost Benefit Analysis, Feasibility Study, and
Risk Management Plan.

Review and Approval to Proceed

The results of the phase efforts are presented to project stakeholders and
decision makers together with a recommendation to (1) proceed into the
next life-cycle phase, (2) continue additional conceptual phase activities,
or (3) terminate the project. The emphasis of the review should be on (1)
the successful accomplishment of the phase objectives, (2) the plans for
the next life cycle phase, and (3) the risks associated with moving
into the next life-cycle phase. The review also addresses the
availability of resources to execute the subsequent life-cycle phases. The
results of the review should be documented reflecting the
decision on the recommended action.

3.1.1.2 Planning

The following tasks are performed as part of the Planning Phase.

Theresultsof theseactivitiesarecaptured
invariousprojectplanssolicitation documents.

Define Acquisition Strategy in System Boundary Document

Define the role of system development contractors
during the subsequent phases. For example,
onestrategy option wouldactive participation of system
contractors in the Requirements Analysis Phase. In this case, the
Planning Phase must include complete planning,solicitation,
preparation, and source selection of the participating
contractors (awarding the actual contract may be the first activity of
thenext phase). If contractors will be used to complete
the required documents, up-front acquisition planning is essential.

57
MBA 815 MANAGEMENT INFORMATION SYSTEM

Analyze Project Schedule

Analyze and refine the project schedule, taking into account risks and
resource availability. Develop a detailed schedule for the
RequirementsAnalysis Phase and subsequent phases.

Create Internal Processes

Create, gather, adapt, and/or adopt the internal
management, engineering, business management, and contract
managementinternal processes that will be used by the project office for
all subsequent life-cycle phases. This could result in the establishment of
teams or working groups for specific tasks, (e.g., quality
assurance, configuration management, changes control). Plan,
articulate, and gain approval for the resulting processes.

Staff Project Office

Further, staff the project office with needed skills across the broad range
of technical and business disciplines. Select Technical Review
Board members and document roles and responsibilities. If needed,
solicit and award support contracts to provide needed non-personal
services that are not available through agency resources.

Establish Agreements with Stakeholders

Establish relationships and agreements with internal and
external organizations that will be involved with the project. These
organizations may include agency and oversight offices,
agency personnel offices, agency finance offices, internal
and external audit organizations, and agency resource
providers (people, space, office equipment, communications, etc).

Develop the Project Management Plan

Plan, articulate and gain approval of the strategy to
execute the management aspects of the project (Project Management
Plan). Develop a detailed project work breakdown structure.

Develop the Systems Engineering Management Plan (SEMP)

Plan, articulate, and gain approval of the strategy to
executetechnical management aspects of the project(SEMP).
Develop adetailed system work breakdown structure.

Review Feasibility of System Alternatives

Review and validate the feasibility of the system alternatives developed
during the previous phase (CBA, Feasibility Study).
Confirm the continued validity of the need (SBD).

58
MBA 815 MODULE 1

Study and Analyze Security Implications

Study and analyze the security implications of the technical alternatives
and ensure the alternatives, address all aspects or constraints imposed by
security requirements (System Security Plan).
Plan the Solicitation, Selection and Award

During this phase or subsequent phases, as required

by the Acquisition Regulation (FAR), plan the solicitation, selection
and award of contracted efforts based on the selected strategies in the
SBD. Obtain approvals to contract from appropriate authorities
(Acquisition Plan). As appropriate, execute the solicitation and selection
of support and system contractors for the subsequent phases.

Develop the CONOPS

Based on the system alternatives and with inputs from the
end-user community, develop the concepts of how the
system will be operated, and maintained. This is the Concept of
Operations. (CONOPS)

Revise Previous Documentation

Review previous phase documents and update if necessary.

3.2 Roles and Responsibilities

3.2.1 Concept Development

• Sponsor: The sponsor should provide direction and sufficient

study resources to commence the System Concept Development
Phase.
• Project Manager: The appointed project manager is charged
with leading the efforts to accomplish the System Concept
Development Phase tasks discussed above. The
Project Manager is alsoresponsible for reviewing the
deliverables for accuracy, approvingdeliverables and providing
status reports to management.
• Component Chief Information Officer (CIO) and
ExecutiveReview Board (ERB): The CIO/ERB approves
the System’sBoundary Document. Approval allows
the project to enter the Planning Phase.

3.2.2 Planning

• Project Manager: The project manager is responsible

and accountable for the successful execution of the Planning
Phase. The project manager is responsible for leading
59
MBA 815 MANAGEMENT INFORMATION SYSTEM

the team that accomplishes the tasks shown above. The

project manager is also responsible for reviewing
deliverables for accuracy, approving deliverables; and
providing status reports to management.
• Project Team: The project team members (regardless
of the organization of permanent assignment) are
responsible for accomplishing assigned tasks as directed by the
project manager.
• Contracting Officer: The contracting officer is
responsible and accountable for the procurement activities and
signs contract awards.
• Oversight Activities: Agency oversight activities,
including the IRM office, provide advice and counsel to
the project manager on the conduct and requirements of
the planning effort. Additionally, oversight activities
provide information, judgments, and recommendations
to the agency decision makers during project reviews
and in support of project decision milestones.

Chief Information Officer/Executive Review Board: At an

appropriate level within the organization, an individual
should be designated as the project decision authority (may or may not
be the same individual designated as the sponsor in the
previous phase). This individual should be charged with assessing:

(1) the completeness of the planning phase activities,

(2) the robustness of the plans for the next life-cycle phase,
(3) the availability of resources to execute the next phase, and
(4) the acceptability of the acquisition risk of entering the next phase.

For applicable projects, this assessment also includes the readiness

to award any major contracting efforts needed to execute the next
phase.

During the end of phase review process, the decision maker

may (1) direct the project to move forward into the
next life-cycle phase (including awarding contracts), (2) direct
the project to remain in the Planning Phase pending completion
of delayed activities or additional risk reduction efforts, or (3)
terminate the project.

60
MBA 815 MODULE 1

3.3 Deliverables

3.3.1 Concept Development

The following deliverables shall be initiated during the System Concept

Development Phase:

System Boundary Document (SBD) - Identifies the scope of a system

(or cap ability). It should contain the high level requirements, benefits,
business assumptions, and program costs and schedules.
It records management decisions on the envisioned system
early in its development and provides guidance on its achievement.

Cost-Benefit Analysis - Provides cost or benefit

information for analyzing and evaluating alternative
solutions to a problem and making decisions about
initiating, as well as continuing, the development of
information technology systems. The analysis should
clearly indicate the cost to conform to the architectural standards in the
Technical Reference Model (TRM).

Feasibility Study - Provides an overview of a business requirement or

opportunity, and determines if feasible solutions exist before full
lifecycle resources are committed.

Risk Management Plan - Identifies project risks and specifies the plans
to reduce or mitigate the risks.

3.3.2 Planning

Acquisition Plan
This document shows how all human resources,
contractor support services, hardware, software and
telecommunications capabilities are acquired during the life of
the project. The plan is developed to help ensure that needed
resources can be obtained and are available when needed.

Configuration Management Plan

The CM Plan describes the process that will be used to identify,
manage,control, and audit the project’s configuration.The
plan shouldalsodefine the configuration, management
structure, roles, and responsibilities to be used in executing these
processes.

61
MBA 815 MANAGEMENT INFORMATION SYSTEM

Quality Assurance Plan

The QA Plan documents that the delivered products satisfy contractual
agreements, meet or exceed quality standards, and comply
with the approved SDLC processes.

Concept of Operations
The CONOPS is a high-level requirements document that
provides a mechanism for users to describe their expectations from the
system

System Security Plan

A formal plan detailing the types of computer security is required for the
new system based on the type of information being processed
and the degree of sensitivity. Usually, those systems that
contain personal information will be more closely safeguarded than
most.

Project Management Plan

This plan should be prepared for all projects, regardless of size or scope.
It documents the project scope, tasks, schedule, allocated resources, and
interrelationships with other projects.

The plan provides details on the functional units involved, required job
tasks, cost and schedule performance measurement,
milestone and review scheduling. A revision to the Project
Management Plan occurs at the end of each phase and as information
becomes available. The Project Management Plan should address the
management oversight activities of the project.

Validation and Verification Plan

The Validation and Verification Plan describes the testing strategies that
will be used throughout the life-cycle phases. This plan should include
descriptions of contractor, government, and appropriate
independent assessments required by the project. Appendix C-12
provides a template for the Validation and Verification Plan.

System’s Engineering Management Plan

The SEMP describes the system is engineering process to be applied to
the project; assigns specific organizational responsibilities
for the technical effort, and references technical processes to be
applied to the effort

62
MBA 815 MODULE 1

3.4 Issues for Consideration

3.4.1 Concept Development

After the SBD is approved and the program and/or

executive management accept a recommendation, the system is
project planning begins. The Project Manager takes a number of project
continuation and project approach decisions.

ADP Position Sensitivity Analysis

All projects must ensure that all personnel are cleared to the appropriate
level before performing work on sensitive systems.
Automated processing (ADP) position designation analysis,
applies to allorganizational personnel, including contract support
personnel who arenominated to fill an ADP position. ADP positions are
those that require access to ADP systems or require work
on management, design, development, operation, or
maintenance of organizational automated information systems.
The sensitivity analysis should be conducted only
to determine an individual’s eligibility or continued eligibility for access
to ADP systems, or to unclassified sensitive
information. Such analysis is not to be construed as the sole
determination of eligibility.

Identification of Sensitive Systems

Public Law100-235, the Computer security Act
of1987ofequires Federal agencies to identify systems that
contain sensitiveinformation. In general, a sensitive system is
a computer system thatprocesses, stores, or transmits
sensitive-but-unclassified(SBU) data.SBU data
areanyinformationthat the loss,misuse, oracess to, or
modification of, could adversely affect the national interest,the
conduct of organizational programs, or the privacy to
which individuals are entitled under the Privacy Act. These
procedures will help determine the type of sensitivity
level to the data that processed, stored, and transmitted by the
new or changed system.

Project Continuation Decisions

The feasibility study and CBA confirm that the defined
information management concept is significant enough to warrant an IT
project with life-cycle management activities.

The feasibility study should confirm that the information

management need or opportunity is beyond the capabilities of
existing systems and that developing a new system is a promising

63
MBA 815 MANAGEMENT INFORMATION SYSTEM

approach.

The CBA confirms that the projected benefits of the proposed approach
justify the projected resources required. The funding,
personnel, andother resources shall be made available to
proceed with the Planning Phase.

3.4.2 Planning

Audit Trails
Audit trails, capable of detecting security violations,
performance problems and flaws in applications, should be specified.
This includes the ability to track activity from the time
of logon, by user IDocation of the equipment, until logoff.
Identify any events that are to be maintained regarding the operating
system, application and user activity.

Access Based on “Need to Know”

Prior to an individual being granted access to the system, the
program manager’s office should determine each individual’s
“Need to Know”and should permit access to only those
areas necessary to allow the individual to adequately perform
her/her job.

3.5 Phase Review Activity

3.5.1 Concept Development

The System Concept Development Review shall be performed at the end

of this phase. The review ensures that the goals and objectives of
the system are identified and that the feasibility of the system is
established.

Products of the System Concept Development Phase are

reviewed including the budget, risk, and user
requirements. This review is organized, planned, and led
by the Program Manager and/or representative.

3.5.2 Planning

Upon completion of all Planning Phase tasks and receipt of

resources forthe next phase, the Project Manager, together
with the projectshould prepare and present a project
statusreview for themaker and project stakeholders. The review
should address:

64
MBA 815 MODULE 1

(1) Planning Phase activities status,

(2) planning status for all subsequent life-cycle phasesth
significant detail on the next phase, to include
the status pen ding contract actions),
(3) resource availability status, and
(4) acquisition risk assessments of subsequent life cycle phases given
the planned acquisition strategy.

4.0 CONCLUSION

Concept development plays strategic role in defining the outcome of

a systems development. If the concept is wrong, for sure the outcome
will also be wrong. It is concept development that actually initiates the
whole idea of developing a system. Planning on the other hand ensures
that all the necessary steps to bringing to pass
conceptualized ideas are followed. Without adequate
planning, no matter the potentials of the concept, the designed
system will equally fail.

5.0 SUMMARY

• System Concept Development begins when the

Concept Proposal has been formally approved and requires
study and analysis that may lead to system development activities.
• The project team, supplemented by enterprise architecture
or other technical experts, if needed, should
analyze all feasiblebusiness process, and
commercial alternatives to meeting thebusiness need.
• The project team should develop high-level (baseline) schedule,
cost, and performance measures which are summarized
in the System Boundary Document (SBD).
• At an appropriate level within the organization, an individual
should be designated as the project decision authority (may or
may not be the same individual designated as the sponsor in the
previous phase).
• Establish relationships and agreements with internal
and external organizations that will be involved with the project.
• After the SBD is approved and the program
and/or executive management accept a recommendation, the
system project planning begins.
• Audit trails, capable of detecting security violations,
performance problems and flaws in applications should be
specified.
• Upon completion of all Planning Phase tasks and receipt of
resources for the next phase, the Project Manager,
together with the project team should prepare and

65
MBA 815 MANAGEMENT INFORMATION SYSTEM

present a project status review for the decision

maker and project stakeholders.

In the next study unit, you will be taken through requirements

analysis of system design.

6.0 TUTOR-MARKED ASSIGNMENT

Compare and contract concept development and planning

in term of tasks activities and roles in the design and development
of information system.

7.0 REFERENCES/FURTHER READING

Information Resources Management (2003).The Department of Justice

Systems Development Lifecycle Guidance Document.

Norton, P (1995). Introduction to Computers.Macmillan/McGraw-Hill.

66
MBA 815 MANAGEMENT INFORMATION SYSTEM

MODULE 2

Unit 1 Requirements Analysis of System Design

Unit 2 Design of System
Unit 3 Development, Integration and Testing of
Information System
Unit 4 Implementation and Disposition of System
Unit 5 Operations and Maintenance of System Design

UNIT 1 REQUIREMENTS ANALYSIS OF SYSTEM

DESIGN

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Requirement Analysis Phase
3.2 Tasks and Activities
3.3 Roles and Responsibilities
3.4 Deliverables
3.5 Issues for Consideration
3.6 Phase Review Activity
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

Requirements analysis of system design begins with

Documentation phase which precedes the requirement analysis phase.

In this unit, you will be made to understand the requirements analysis of

system deign.

2.0 OBJECTIVES

This unit is designed for you to:

• understand what constitutes requirement analysis in

designing and developing information system
• identify the tasks you need to embark on during
the requirement analysis phase of systems development
• comfortably answer the question of responsibilities

66
MBA 815 MODULE 2

and roles in executing the requirement analysis of a systems

design project
• identify some issues that need to be considered
in requirement analysis.

3.0 MAIN CONTENT

3.1 Requirements Analysis Phase

The Requirements Analysis Phase will begin when the previous

phase documentation has been approved, or by management
direction.

Documentation related to user requirements from the Planning

Phase shall be used as the basis for further user
needs analysis and development of detailed user requirements.
The analysis may reveal new insights into the overall information
systems requirements, and, in such instances, all deliverables should be
revised to reflect this analysis.

During the Requirements Analysis Phase, the system shall be defined in

more detail with regard to system inputs, processes,
outputs, and interfaces. This definition process occurs at the
functional level. The system shall be described in terms of the
functions to be performed, not in terms of computer programs, files, and
data streams. The emphasis in this phase is on determining what
functions must be performed rather than how to perform those
functions.

3.2 Tasks and Activities

The following tasks are performed during the Requirements

Analysis Phase. The tasks and activities actually performed depend on
the nature of the project.

Analyse and Document Requirements

First, consolidate and affirm the business needs. Analyze the intended
use of the system, and specify the functional and data
requirements. Connect the functional requirements to the data
requirements. Define functional and system is requirements that are
not easily expressed in data and process models. Define the high
level architecture and logical design to support the system and functional
requirements.

A logical model is constructed that describes the fundamental processes

and data needed to support the desired business

67
MBA 815 MANAGEMENT INFORMATION SYSTEM

functionality. This logical model will show how processes

interact, and how processes create and use data. These
processes will be derived from the activity
descriptions provided in the System Boundary Document.

Functions and entity types contained in the logical model are extended
and refined from those provided in the Concept
Development Phase. End-users and business area experts
will evaluate all identified processes and data structures to
ensure accuracy, logical consistency, and completeness. An analysis
of business activities and data structures is performed to produce entity-
relationship diagrams, process hierarchydiagrams, process dependency
diagrams, and associated documentation.

An interaction analysis is performed to define the interaction

between the business activities and business data. This analysis produces
process logic and action diagrams, definitions of the business
algorithms, entity life-cycle diagrams, and entity state change matrices.
A detailed analysis of the current technical architecture,
application software, and data is conducted to ensure that
limitations or unique requirements have not been overlooked.

Include all possible requirements including those for:

• functional and capability specifications, including

performance, physical characteristics, and environmental
conditions under which the software item is to perform;
• interfaces external to the software item;
• qualification requirements;
• safety specifications, including those related to methods of
operation and maintenance, environmental influences, and
personnel injury;
• security specifications, including those related to
compromise of sensitive information;
• human-factors engineering (ergonomics), including those
related to manual operations, human-equipment interactions,
constraints on personnel, and areas needed
concentrated human attention, that are sensitive to human
errors and training;
• data definition and database requirements;
• installation and acceptance requirements of the delivered
software product at the operation and maintenance site(s);
• user documentation;
• user operation and execution requirements;
• user maintenance requirements.

68
MBA 815 MODULE 2

Develop Test Criteria and Plans

Establish the test criteria and begin test planning. Include all areas where
testing will take place and who is responsible for the testing. Identify the
testing environment, what tests will be performed, test procedures; and
traceability back to the requirements.

Describe what will be tested in terms of the data or

information. If individual modules are being tested separately, this
needs to be stated in the Master Plan. Smaller plans may be needed
for specialized testing, but they should all be referenced in the Master
Plan.

Develop an Interface Control Document

The project team responsible for the development of this system, needs
to articulate the other systems (if any) this system will interface with.

Identify any interfaces and the exchange of data or

functionality that occurs. All areas that connect need to be
documented for security as well as information flow purposes.

Review and Assess FOIA/PA Requirements

The FOIA/PA describes the process and procedures for compliance with
personal identifier information. A Records Management
representative will determine if what you plan constitutes a system
as a Privacy Act System of Records. A system of records notice must
be published for each new system of records that is established
or existing system of records that is revised. If needed, a Privacy
Act Notice for the Federal Register will be prepared.

The collection, use, maintenance, and dissemination of information on

individuals by any Department component require a thorough
analysis of both legal and privacy policy issues. Whether a system is
automated or manual, privacy protections should be
integrated into the development of the system. To ensure
that the Department properly addresses the privacy concerns of
individuals as systems are developed, Departmental policy mandates
that components develop and utilize the Privacy Impact Assessment
(PIA) processes.

Federal regulations require that all records no longer

needed for the conduct of the regular business of the agency be
disposed of, retired, or preserved in a manner consistent with
official Records Disposition Schedules. The decisions
concerning the disposition criteria, including when and how records are
to be disposed, and the coordination with the Records Management
representatives to prepare the Records Disposition Schedule for the

69
MBA 815 MANAGEMENT INFORMATION SYSTEM

proposed system, shall be the responsibilities of the Project

Manager.

Conduct Functional Review

The Functional and Data Requirements Review is

conducted in Rhequirements Analysis Phase by the
technical review board. This wish ere the functional requirements
identified in the FRD are reviewed to see if they are sufficiently detailed
and are testable. It also provides the Project Manager with the
opportunity to ensure a complete understanding of the
requirements and that the documented requirements can support
a detailed design of the proposed system.

Revise Previous Documentation

Review and update previous phase documentation if necessary
before moving to the next phase.

3.3 Roles and Responsibilities

• Project Manager: The project manager is responsible

and accountable for the successful execution of the
Requirements Analysis Phase. The project manager is
responsible for leading the team that accomplishes the tasks
shown above. The Project Manager is also responsible for
reviewing deliverables for accuracy, approving deliverables
and providing status reports to managers.
• Technical Review Board: Formally established board that
examines the functional requirements documented in the
FRD for accuracy, completeness, clarity, attainability, and
traceability to the high-level requirements identified in the
Concept of Operations.
• Project Team: The project team members (regardless
of the organization of permanent assignment) are
responsible for accomplishing assigned tasks as directed by the
project manager.
• Contracting Officer: The contracting officer is
responsible and accountable for the procurement activities and
signs contract awards.
• CIO/ERB: Agency oversight activities, including the
Executive Review Board office, provide advice
and counsel to the manager on the conduct
and requirements of the Requirements
Analysis Phase effort. Additionally, oversight activities
provide information, judgments, and recommendations
to the agency decision makers during project reviews

70
MBA 815 MODULE 2

and in support of project decision milestones.

3.4 Deliverables

Functional Requirements Document

Serves as the foundation for system design and development; captures
user requirements to be implemented in a new or enhanced system; the
systems subject matter experts document these requirements
into the requirements traceability matrix, which shows mapping of each
detailed functional requirement to its source. This is a complete,
user oriented functional and data requirements for the system which
must be defined, analyzed, and documented to ensure that
user and system is requirements have been collected and
documented.

All requirements must include considerations for capacity and growth.

Where feasible, I-CASE tools should be used to assist in the
analysis, definition, and documentation. The requirements
document should include, but is not limited to records and privacy act,
electronic record management, record disposition schedule, and
components’ unique requirements. Consideration must also be given
to persons with disabilities as required by the Rehabilitation Act, 20
U.S.C., Sec 794d (West Supp. 1999)

Test and Evaluation Master Plan

Ensures that all aspects of the system are adequately tested and can be
implemented; documents the scope, content, methodology,
sequence, management of, and responsibilities for test activities. Unit,
integration, and independence acceptance testing activities are performed
during the development phase. Unit and integration tests are performed
under the direction of the project manager. Independence
acceptance testing is performed independently from the developing
team, and is coordinated with the Quality Assurance (QA)
office. Acceptance tests will be performed in a test
environment that duplicates the production environment as
much as possible. They will ensure that the requirements
are defined in a manner that is verifiable. They will
support thetraceability of the requirements; form the source
documentation, to the design documentation, to the test
documentation. They will also verify the proper implementation of the
functional requirements.

The types of test activities discussed in the subsequent

sections are identified more specifically in the Integration and Test
Phase of the life cycle and are included in the test plan and test analysis
report, viz:

71
MBA 815 MANAGEMENT INFORMATION SYSTEM

• Unit/Module Testing;
• Subsystem Integration Testing;
• Independent Security Testing;
• Functional Qualification Testing;
• User Acceptance Testing; and
• Beta Testing.

Interface Control Document

The Interface Control Document (ICD) provides an outline for use in the
specification of requirements imposed on one or more
systems, subsystems configuration items, or other system components to
achieve one or more interfaces among these entities. Overall, an ICD can
cover requirements for any number of interfaces between
any number sfystems.

Privacy Act Notice/Privacy Impact Assessment

For any system that has been determined to be an official
System of Records (in terms of the criteria established by the Privacy
Act (PA)), a special System ofRecordsNoticeshallbepublished
intheRegister. This Notice identifies the purpose of the system;
describes its routine use and what types of information and data are
contained in its records; describes where and how the records are
located; and identifies who the System Manager is. While
the Records Management Representatives are responsible
for determining if a system is a System of Records, it is the
Project Manager’s responsibility to prepare the actual Notice for
publication in the Federal Register. As with the
Records Disposition Schedule, however, it is the Project
Manager’s responsibility to coordinate with and assist the
System Proponent preparing the PA Notice.

The System of Records Notice shall be a required deliverable for

the Requirements Analysis Phase of system development.
The Privacy Impact Assessment is also a deliverable in this Phase.
This is a written evaluation of the impact that the implementation of the
proposed system would have on privacy.

3.5 Issues for Consideration

IntheRequirementsAnalysisPhase,itisimportanttoget involved with the

project to discuss and document their requirements. A
baseline is important in order to begin the next phase. The requirements
from the FRD may become part of a solicitation in the Acquisition Plan.

72
MBA 815 MODULE 2

3.6 Phase Review Activity

Upon completion of all Requirements Analysis Phase tasks, and receipt

of resources for the next phase, the Project Manager, together with the
project team, should prepare and present a project status review for the
decision maker and project stakeholders. The review should address:

(1) Requirements Analysis Phase activities status,

(2) planning status for all subsequent life cycle phases
(with significant detail on the next phase, to
include the status of pending contract actions),
(3) resource availability status, and
(4) acquisition risk assessments of subsequent life cycle phases given
the planned acquisition strategy.

4.0 CONCLUSION

Requirements analysis allows for further analysis to know if more items

and details should be added, therefore serves to define system’s design
and development. In some system’s development lifecycle, this phase is
not identified but is considered as part of the general analysis phase.

5.0 SUMMARY

• During the Requirements Analysis Phase, the system shall be

defined in more detail with regard to system inputs, processes,
outputs, and interfaces.
• End-users and business area experts will evaluate
all identified processes and data structures to ensure accuracy,
logical consistency, and completeness.
• The project manager is responsible and accountable
for the successful execution of the Requirements Analysis
Phase.
• The collection, use, maintenance, and dissemination of
information on individuals by any Department
component require a thorough analysis of both legal and
privacy policy issues.
• The Functional and Data Requirements Review is conducted in
the Requirements Analysis Phase by the technical review board.
This is where the functional requirements identified in
the FRD are reviewed to see if they are sufficiently detailed
and are testable.
• All requirements must include considerations for
capacity and growth.
• The Interface Control Document (ICD) provides an outline for
use in the specification of requirements imposed on one or

73
MBA 815 MANAGEMENT INFORMATION SYSTEM

more systems, subsystems’ configuration items, or other

system components, to achieve one or more interfaces among
these entities.
• Upon completion of all Requirements Analysis
Phase tasks and receipt of resources for the next phase, the
Project Manager, together with the project team should
prepare and present a project re view for the decision
maker and project stakeholders.

You are going to learn design of system in the next study unit.

6.0 TUTOR-MARKED ASSIGNMENT

Discussthetypesofrequirementsthatneedtoanalyzedindevelopment.

7.0 REFERENCES/FURTHER READING

Information Resources Management (2003). The Department of Justice

Systems Development Lifecycle Guidance Document.

Norton, P (1995). Introduction to Computers. Macmillan/McGraw-Hill.

74
MBA 815 MODULE 2

UNIT 2 DESIGN OF SYSTEM

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Design of System
3.2 Tasks and Activities
3.3 Roles and Responsibilities
3.4 Deliverables
3.5 Issues for Consideration
3.6 Phase Review Activity
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

This unit dwells on transformation of the Design phase which in

turn services as a guide for the Development phase. It also examines
tasks and activities, Roles and responsibilities anddeliverables
as they concern design of system.

2.0 OBJECTIVES

This unit is designed for you to:

• understand what constitutes design phase in

designing and developing information system
• identify the tasks you need to embark on during the design phase
of system’s development
• comfortably answer the question of responsibilities
and roles in executing the design phase of a system’s
development project
• be able to know what are the deliverables from design to be used
for subsequent phases
• identify some issues that need to be considered in deign phase
of asystem.

75
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.0 MAIN CONTENT

3.1 Design of System

The objective of the Design Phase is to transform the detailed,

defined requirements into complete, detailed specifications for
the system to guide the work of the Development Phase. The
decisions made in this phase, address, in detail, how the
system will meet the defined functional, physical,
interface, and data requirements. Design Phase activities may
be conducted in an iterative fashion, producing first, a
general system design that emphasizes the functional features
of the system, and then a more detailed system design that expands the
general design by providing all the technical detail.

System design is also the evaluation of alternative problem solution, and

the detailed specification of the final system. The specification produced
in the analysis phaseis usedtoconstructa design for the
sytem. The emphasis of system design is to develop a new system that
helps to achieve the goals and objectives of the
organization overcomes some of the shortcomings and
limitations of the existing system. If the problems are minor only
small modifications are required. On the other hand major changes may
be suggested by system analysis. Regardless of the complexity and scope
of any system, it is the purpose of system design to develop the best
possible system.

The purpose of the system’s design stage is also to architect and design
a technical solution that is able to meet all the
requirements customer, as defined in the business requirements
document.

The recommended technical solution will comprise of various elements:

a specification of the technical architecture to be
employed and required configuration; programme structure and
flow; a definition of any interfaces between systems; and screen
design (if required).

The TAD and SDS should be circulated within MIS first for review. If
necessary an internal meeting should be held to discuss and resolve any
issues. The documents should then be presented to the
project stakeholder for sign off and the PPDR template
used to record distribution, lists and actions.

This stage completes when all the key tasks have been performed and
the exit criteria met.

76
MBA 815 MODULE 2

3.2 Tasks and Activities

The following tasks are performed during the Design Phase. The tasks
and activities actually performed depend on the nature of the project.

Establish the Application Environment

Identify/specify the target, the development and the design and
testing environment. How and where will the application reside?
Describe the architecture where this application will be
developed and tested, and who is responsible for this activity.

Design the Application

In the system design, first the general system characteristics are defined.
The data storage and access for the database layer need to be designed.
The user interface at the desktop layer needs to be
designed. The business rules layer or the application logic needs to be
designed.

Establish a top-level architecture of the system and document

it. The architecture shall identify items of hardware,
software, and manual-operations. All the system requirements
should be allocated among the hardware configuration items, software
configuration items, and manual operations.

Transform the requirements for the software item into an

architecture that describes its top-level structure and
identifies the software components. Ensure that all the
requirements for the software item are allocated to its software
components and further refined to facilitate detailed design.
Develop and document a top-level design for the
interfaces external to the software item and between the
software components of the software item.

Develop Maintenance Manual

Develop the maintenance manual to ensure continued operation of the
system once it is completed.

Develop Operations Manual

Develop the Operations Manual for mainframe
systems/applications, and the System Administration Manual
for client/server systems/applications.

Conduct Preliminary Design Review

This is an ongoing interim review of the system design as it

evolves through the Design Phase. This review determines

77
MBA 815 MANAGEMENT INFORMATION SYSTEM

whether the initial design concept is consistent with the overall

architecture and satisfies the functional, security, and technical
requirements in the Functional Requirements Document.

Design Human Performance Support (Training)

Identify the users and how they will be trained on the new system. Be
sure to address the Americans with Disabilities Act (ADA) requirements
to ensure equal access to all individuals.

Design Conversion/Migration/Transition Strategies

If current information needs to be converted/migrated/transitioned to the
new system, plans need to be designed for those purposes, especially if
converting means re-engineering existing processes.

Conduct a Security Risk Assessment

Conduct a security risk assessment by addressing the
following components: assets, threats, vulnerabilities, likelihood,
consequences and safeguards. The risk assessment evaluatescompliance
with baseline security requirements, identifies threats and vulnerabilities,
and assesses alternatives for mitigating or accepting residual risks.

Conduct Critical Design Review

The Project Manager and System is Proponent
conduct the de sign review and approve/disapprove the project into
the Development Phase. This review is conducted at the
end of the Design Phase verifies that the final system design
adequately addresses all functional, security, and technical
requirements and is consistent with the overall architecture.

Revise Previous Documentation

Review documents from the previous phases, and assess the
need to revise them during the Design Phase. The updates should be
signed off
by the Project Manager.

Other tasks associated with design and development of

information systems are:

1. Book a technical architect to write the TAD

2. Book a system analyst and, where necessary, a system
designer to write the SDS
3. Circulate completed TAD and SDS documents to MIS
distribution list and arrange internal meeting to discuss, where
necessary
4. Obtain sign off of TAD and SDS from project stakeholders
5. Complete PPDR template

78
MBA 815 MODULE 2

6. Obtain final resource estimates for build stage tasks from the
system analyst and provisionally book developer and
technical architect resource for the build stage
7. Provisionally book the system analyst at 10% throughout the
Buildstage
8. Update sign off log.

3.3 Roles and Responsibilities

• Project Manager: The project manager is responsible

and accountable for the successful execution of the Design
Phase. The project manager is responsible for
leading the team that accomplishes the tasks shown
above. The Project Manager is also responsible for
reviewing deliverables, for accuracy, approving
deliverables and providing status reports to management.
• Project Team: The project team members (regardless
of the organization of permanent assignment) are
responsible for accomplishing assigned tasks as directed by the
project manager.
• Contracting Officer: The contracting officer is
responsible and accountable for procurement activities and
signs contract awards.
• Oversight Activities: Agency oversight activities,
including the IRM office, provide advice and counsel to
the project manager on the conduct and requirements of
the Design Phase. Additionally, oversight activities
provide information, judgments, and
recommendations to the agency decision makers
during project reviews, and in support of project decision
milestones.

3.4 Deliverables

The content of these deliverables may be expanded or

abbreviated depending on the size, scope, and complexity
of the corresponding system’s development effort.

Security Risk Assessment

The purpose of the risk assessment is to analyze

threats to vulnerabilities of a system to determine the risks (potential
for losses), and using the analysis as a basis for identifying
appropriate and cost-effective measures.

79
MBA 815 MANAGEMENT INFORMATION SYSTEM

Conversion Plan
The Conversion Plan describes the strategies involved in converting data
from an existing system to another hardware or software environment. It
is appropriate to re-examine the original system’s
functional requirements for the condition of the system
before conversion, doetermine if the original requirements are still
valid.

System Design Document

This describes the system requirements, operating environment, system
and subsystem architecture, files and database design, input
formats, output layouts, human-machine interface, detailed
design, processing logic, and external interfaces. It isused
in conjunction withFunctional Requirements Document (FRD),
which is finalized in thisphase, to provide a complete
system specification of all user requirements for the system
and reflects the user’s perspective of the system design.
Includes all information required for the review and
approval of the project development. The sections and subsections of the
design document may be organized, rearranged, or repeated as necessary
to reflect the best organization for a particular project.

In most cases there are both user and technical documentation. Without
good documentation the new system may never be used, and it may be
virtually impossible to modify the system in future. Poorly documented
systems have resulted in mistakes that can lead to great loss.

Implementation Plan
The Implementation Plan describes how the information system will be
deployed and installed into an operational system. The plan contains an
overview of the system, a brief description of the major tasks involved
in the implementation, the overall resources needed to
supportimplementation effort (such as hardware, software,
facilities, materials,and personnel), and any site-specific implementation
requirements. This plan is updated during the Development
Phase; the final version provided in the Integration and Test Phase
and used for guidance during
the Implementation Phase.

Maintenance Manual
The Maintenance Manual provides maintenance personnel
with the information necessary to maintain the system effectively.
The manual provides the definition of the software support
environment, the roles and responsibilities of maintenance personnel,
and the regular activities essential to the support and
maintenance of program modules, job streams, and database

80
MBA 815 MODULE 2

structures. In addition to the items identified for inclusion in the

MaintenanceManual, additional information may be provided to
facilitate the maintenance and modification of the system.
Appendices to document various maintenance procedures, standards, or
other essential information may be added to this document as needed.

Operations Manual or Systems Administration Manual

For mainframe systems, the Operations Manual provides
computer control personnel and computer operators with a
detailed operational description of the information system and its
associatedenvironments, such as machine room operations
and procedures. The Systems Administration Manual serves the
purpose of an Operations Manual in distributed (client/server)
applications.

Training Plan
The Training Plan outlines the objectives, needs, strategy,
and curriculum to be addressed when training users on the new or
enhanced information system. The plan presents the activities needed
to support the development of training materials,
coordination of training schedules, reservation of personnel and
facilities, planning for training needs, and other training-related tasks.
Training activities are developed to teach user personnel the use of the
system as specified in the trainingcriteria. Includes the target audience,
and topics on which training must be conducted on the list of
training needs. It includes, in the training strategy, how the topics
will be addressed, and the format of the training program, the list
of topics to be covered, materials, time, space
requirements, and proposed schedules.

User Manual
The User Manual contains all essential information for the user to make
full use of the information system. This manual includes a description of
the system functions and capabilities, contingencies and alternate modes
of operation, and step-by-step procedures for system access and use.

3.5 Issues for Consideration

Project Decision Issues

The decisions of this phase re-examine in greater detail many
of the parameters addressed in previous phases. The design
prepared in this phase will be the basis for the activities of the
Development Phase. The overall objective is to establish a complete
design for the system. The pre-requisites for this phase are
the Project Plan, Functional Requirements Document, and Test
Plan. A number of project approach, project execution, and project

81
MBA 815 MANAGEMENT INFORMATION SYSTEM

continuation decisions are made in this phase.

Project approach decisions include:

• Identifying existing or COTS components that can
be used, or economically modified, to satisfy validated
functional requirements.
• Using appropriate prototyping to refine requirements and
enhance user and developer understanding and interpretation of
requirements.
• Selecting specific methodologies and tools to be used in the later
life cycle phases, especially the Development and
Implementation Phases.
• Determining how user support will be provided, how the
remaining life cycle phases will be integrated, and newly
identified risks and issues handled.

Project execution decisions include:

• Modifications that must be made to the initial
information system need.
• Modifications that will be made to current procedures.
• Modifications that will be made to current
systems/databases or to other systems/databases under
development.
• How conversion of existing data will occur.

Project continuation decisions include:

• The continued need of the information system to exist.
• The continued development activities based on the needs
addressed by the design.
• Availability of sufficient funding and other required resources for
the remainder of the systems life cycle.

The system user community shall be included in

the Design ctions as needed. It is also in the Design Phase
that new or further requirements might be discovered that are
necessary to accommodate individuals with disabilities. If so, these
requirements shall be added to the FRD.

Security Issues
The developer shall obtain the requirements from the System
Security Plan and the FRD and allocate them to the specific modules
within the design for enforcement purposes. For example, if a
requirement exists to audit a specific set of user actions, the
developer may have to add a work flow module into the design to
accomplish the auditing.

82
MBA 815 MODULE 2

Detailed security requirements provide users and

administrators with instructions on how to operate and maintain the
system securely. They should address all applicable computer and
telecommunications security requirements, including: system access
controls; marking, handling, and disposing of magnetic media and
hard copies; computer room access; account creation, access,
protection, and capabilities; operational procedures; audit trail
requirements; configuration management; processing area
security; employee check-out; and emergency procedures.
Security operating procedures may be created as separate
documents or added as sections or appendices to the
User and Operations Manuals. This activity should be
conducted during the Design Phase.

3.6 Phase Review Activity

Upon completion of all Design Phase tasks and receipt of resources for
the next phase, the Project Manager, together with the
project team should prepare and present a project status
review for the decision maker and project stakeholders. The
review should address:
(1) design Phase activities status,
(2) planning status for all subsequent life cycle phases
(with significant detail on the next phase, to
include the status of pending contract actions),
(3) resource availability status, and
(4) acquisition risk assessments of subsequent life cycle phases given
the planned acquisition strategy.

4.0 CONCLUSION

Though there could be several design approach depending on the type of

project, system’s design as a phase in the development of an information
system is what translates all the conception and analysis into reality by
coming up with the sample of what is needed to improve an information
system.

5.0 SUMMARY

• TheobjectiveoftheDesignPhaseistotransformthedefined
requirements into complete, detailed specifications for the
system to guide the work of the Development Phase.
• The purpose of the system’s design stage is also to
architect and design a technical solution that is able to meet all
the requirements of the customer, as defined in the business
requirements document.
• The Project Manager and System is Proponent conduct the

83
MBA 815 MANAGEMENT INFORMATION SYSTEM

critical design review and approve/disapprove the

project into the Development Phase.
• The purpose of the risk assessment is to analyze
threats to, and vulnerabilities of a system to determine
the risks (potentiallosses), and using the analysis as a basis
for identifying appropriateand cost-effective measures.
• For mainframe systems, the Operations Manual provides
computer control personnel and computer operators with a
detailed operational description of the information
system and its associated environments, such as machine
room operations and procedures.
• The decisions of the project decision issues re-examine in
greater detail many of the parameters addressed in previous
phases.
• Upon completion of all Design Phase tasks and receipt of
resources for the next phase, the Project Manager,
together with the project team should prepare and
present a project status review for decision maker and
project stakeholders.

In the next study unit, you will be exposed to Development, Integration

and Testing of Information system.

6.0 TUTOR-MARKED ASSIGNMENT

Discuss 5 tasks and activities associated with design phase of a system

development

7.0 REFERENCES/FURTHER READINGS

Information Resources Management (2003). The Department of Justice

Systems Development Lifecycle Guidance Document.

Norton, P (1995). Introduction to Computers. Macmillan/McGraw-Hill.

84
MBA 815 MODULE 2

UNIT 3 DEVELOPMENT, INTEGRATION AND TESTING

OF INFORMATION SYSTEM

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Development and Integration and Testing Phases
3.1.1 Development
3.1.2 Integration and Testing
3.2 Tasks and Activities
3.2.1 Development
3.3 Roles and Responsibilities
3.3.1 Development
3.3.2 Integration and Testing
3.4 Deliverables
3.4.1 Development
3.4.2 Integration and Testing
3.5 Issues for Consideration
3.5.1 Development
3.5.2 Integration and Testing
3.6 Phase Review Activity
3.6.1 Development
3.6.2 Integration and Testing
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

This unit dwells mainly on tasks, activities, roles and responsibilities of

both Development and Integration and testing phases.

2.0 OBJECTIVES

This unit is designed for you to:

• understand what constitutes system’s development, integration

and testing phase in designing and developing information system
• identify the tasks you need to embark on during the
development, integration and testing phase of systems
development
• comfortably answer the question of responsibilities and
roles in executing the development, integration and testing

85
MBA 815 MANAGEMENT INFORMATION SYSTEM

phase of a systems development project

• be able to know what are the deliverables from
development, integration and testing to be used for subsequent
phases
• identify some issues that need to be considered in
development,integration and testing phase of a system.

3.0 MAIN CONTENT

3.1 Development and Integration and Testing Phases

3.1.1 Development

The objective of the Development Phase will be to

convert the deliverables of the Design Phase into a complete
information system. Although much of the activity in the Development
Phase addresses the computer programs that make up the
system, this phase also puts in place the hardware, software, and
communications environment for the system and other important
elements of the overall system.

The activities of this phase translate the system design produced in the
Design Phase into a working information system capable of addressing
the information system requirements. The development phase
contains activities for building the system, testing the system,
and conducting functional qualification testing, to ensure
the system functional processes satisfy the functional process
requirements in the Functional Requirements Document (FRD). At
the end of this phase, the system will be ready for the activities of
the Integration and Test Phase.

3.1.2 Integration and Testing

The objective of this phase is to prove that the

developed system satisfies the requirements defined.
Several types of tests will be conducted in this phase.
First, subsystem integration tests shall be executed and
evaluated by the development team to prove that the
program components integrate properly into the subsystems and that the
subsystems integrate properly into an application. Next, the testing team
conducts and evaluates system tests to ensure the
developed system meets all technical requirements, including
performance requirements. Next, the testing team and the
Security Program Manager conduct security tests to validate
that the access and data security requirements are met. Finally, users
participate in acceptance testing to confirm that the developed system

86
MBA 815 MODULE 2

meets all user requirements as stated. Acceptance testing shall be

done in a simulated “real” user environment with the
users using simulated or real target platforms and infrastructures.

3.2 Tasks and Activities

3.2.1 Development

Code and Test Software

Code each module according to established standards.

Integrate Software
Integrate the software units, components and modules.
Integrate the software units and software components and test in
accordance with the integration plan. Ensure that each module satisfies
the requirements of the software at the conclusion of the integration
activity.

Conduct Software Qualification Testing.

Conduct qualification testing in accordance with the
qualification requirements for the software item. Ensure that the
implementation of each software requirement is tested for
compliance. Support audit(s) which could be conducted to ensure
that:

• as-coded software products (such as software item) reflect the

design documentation
• the acceptance review and testing requirements prescribed
by the documentation are adequate for the acceptance
of the software products
• test data comply with the specification
• software products were successfully tested and meet
their specifications
• test reports are correct, and discrepancies between
actual and expected results have been resolved
• user documentation complies with standards as specified.

The results of the audits shall be documented. If both

hardwaresoftware are under development or integration,
the audits maypostponed until the System Qualification Testing.

Upon successful completion of the audits, if

conducted, update prepare the deliverable software product for
System Integration, System Qualification Testing, Software
Installation, or Software Acceptance Support as applicable. Also,
establish a baseline for the design and code of the software item.

87
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.2.2 Integrate System

Integrate the software configuration items with hardware configuration

items, manual operations, and other systems as
necessary, into the system. The aggregates shall be tested, as
they are developed, against their requirements. The integration
and the test results shall be documented. For each qualification
requirement of the system, a set of tests, test cases (inputs, outputs,
test criteria), and test procedures for conducting System
Qualification Testing, shall be developed and documented.
Ensure that the integrated system is ready for System
Qualification Testing.

Conduct System Qualification Testing

Conduct system qualification testing in accordance with
the qualification requirements specified for the system.
Ensure that the implementation of each system requirement is tested
for compliance and that the system is ready for delivery. The
qualification testing results shall be documented.

Install Software
Install the software product in the target environment as designed, and in
accordance with the Installation Plan. The resources and
information necessary to install the software product shall
be determined and be available. The developer shall assist
the acquirer with the set-up activities. Where the installed
software product is replacing an existing
system, the developer shall support any parallel running activities
that are required. Ensure that the software code and
databases initialize, execute, and terminate as specified in
the contract. The installation events and results shall be
documented.

Document Software Acceptance Support

Acceptance review and testing shall consider the results of
the Joint Reviews, Audits, Software Qualification Testing,
and System Qualification Testing (if performed). The results
of the acceptance review and testing shall be documented.

The developer shall complete and deliver the software

product as specified. The developer shall provide initial and
continuing training and support to the acquirer as specified.

Revise Previous Documentation

Review and update previous phase documentation, as needed.

88
MBA 815 MODULE 2

Integration and Testing

The tasks and activities actually performed depend on the nature of the
project. The following tasks should be completed during the Integration
and Test phase.

Establish the Test Environment

Establish the various test teams and ensure the test system(s) are ready.

Conduct Integration Tests

The test and evaluation team is responsible for creating/loading the
test database(s) and executing the integration test(s). This is to ensure
that program components integrate properly into the
subsystems and the subsystems integrate properly into an
application.

Conduct Subsystem/System Testing

The test and evaluation team is responsible for creating/loading the
test database(s) and executing the system test(s). All
results should documented on the Test Analysis Report, Test
Problem Report, and on the Test Analysis Approval
Determination. Any failed components should be migrated back
to the development phase for rework, and the passed components
should be migrated ahead for security testing.

Conduct Security Testing

The test and evaluation team will again create or
load the database(s) and execute security (penetration) test(s). All
tests will be documented, similar to those above. Failed components
will be migrated back to the development phase for rework, and passed
components will be migrated ahead for acceptance testing.
Conduct Acceptance Testing

The test and evaluation team will create/load the test

database(s) and execute the acceptance test(s). All tests will be
documented, similar to those above. Failed components will
be migrated back to the development phase for rework,
and passed components will migrate ahead for implementation.

Revise Previous Documentation

During this phase, the Systems Technical Lead or the Developer(s) will
finalize the Software Development Document from the
Development Phase. He/They will also finalize the
Operations or Systems Administration Manual, User Manual,
Training Plan, Maintenance Manual, Conversion Plan,
Implementation Plan, Contingency Plan, and Update the Interface

89
MBA 815 MANAGEMENT INFORMATION SYSTEM

Control Document from the Design Phase. The Project

Manager should finalize the System Security Plan and
the Security Risk Assessment from the Requirements Analysis Phase,
and the Project Management Plan from the Planning
Phase. The Configuration Manager should finalize the
Configuration Management Plan from the Planning Phase. The
Quality Assurance office/person should finalize the Quality
Assurance Plan from the Planning Phase. And finally, the
Project Manager should finalize the Cost Benefit
Analysis and the Risk Management Plan from the
System Concept Development Phase.

3.3 Roles and Responsibilities

3.3.1 Development

• Project Manager: The project Manager is responsible

and accountable for the successful execution of the
Development Phase. The project Manager is responsible
for leading the team that accomplishes the tasks shown
above. The Project Manager is also responsible for
reviewing deliverables for accuracy, approving
deliverables and providing status reports to management.
• Project Team: The project team members (regardless
of the organization of permanent assignment) are
responsible for accomplishing assigned tasks as directed by the
project manager.
• Contracting Officer: The contracting officer is
responsible and accountable for the procurement
activities, and signs contract awards.
• Oversight Activities: Agency oversight activities,
including the IRM office, provide advice and counsel to
the project manager on the conduct and requirements of
the Development Phase. Additionally, oversight
activities provide information, judgments, and
recommendations to the agency decision makers during project
reviews, and in support of project decision milestones.
• Developer: The developer is responsible for the
development activities to include coding, testing, documenting
and delivering the completed system.

3.3.2 Integration and Test

• Project Manager: The project manager is responsible

and accountable for the successful execution of the Integration
and Test Phase. The project manager is responsible for leading the

90
MBA 815 MODULE 2

team that accomplishes the tasks shown above. The Project

Manager is also responsible for reviewing deliverables
for accuracy, approving deliverables and providing status
reports to management.
• Project Team: The project team members (regardless
of the organization of permanent assignment) are
responsible for accomplishing assigned tasks as directed
by the project manager. This includes establishing the test
environment.
• Contracting Officer: The contracting officer is
responsible and accountable for the procurement activities and
signs contract awards.
• Security Program Manager: The Security Program
Manager is responsible for conducting security tests
according to the Systems Security Plan.
• Oversight Activities: Agency oversight activities,
including the IRM office, provide advice and counsel for the
project manager on the conduct and requirements of
the Integration and Test A dditionally, oversight
activities provide information, judgments, and
recommendations to the agency decision makers during project
reviews and in support of project decision milestones.
• User: Users participate in acceptance testing to
ensure systems perform as expected.

3.4 Deliverables

3.4.1 Development

Thecontentofthesedeliverablesmay
beexpandedordependingonthesize,scope,andcomplexityofthesystemsdev
elopmenteffort. The following deliverables shall beinitiated
during the Development Phase:

Contingency Plan
The Contingency Plan contains emergency response procedures; backup
arrangements, procedures, and responsibilities; and post-
disaster recovery procedures and responsibilities. Contingency
planning is essential to ensure that organizations systems are able
to recover from processing disruptions in the event of localized
emergencies or large-scale disasters. It is an emergency
response plan, developed in conjunction with application owners,
and maintained at the primary and backup computer installation, to
ensure that a reasonable continuity of support is provided if events
occur that could prevent normal operations.

91
MBA 815 MANAGEMENT INFORMATION SYSTEM

Contingency plans shall be routinely reviewed, updated, and

tested to enable vital operations and resources to be
restoredas quickly aspossibleand to keep system downtime
to an absolute minimum. A Contingency Plan is synonymous
with a disaster plan and an emergency plan. If the system/subsystem is
to be located within a facility with an acceptable contingency plan,
system-unique contingency requirements should be added as an annex
to the existing facility contingency plan.

Software Development Document

Contains documentation pertaining to the development of each unit
or module, including the test cases, software, test results,
approvals, and any other items that will help explain the functionality of
the software.

System (Application) Software

This is the actual software developed. It is used
for the Test integration Phase and finalized before
implementation of the system. Include all the disks (or other
medium) used to store the information.

Test Files/Data
All the information used for system testing should be provided
at the end of this phase. Provide the actual test data and files used.

Integration Document
The Integration Document explains how the software
components, hardware components, or both are combined,
and the interaction between them.

3.4.2 Integration and Testing

The following deliverables shall be initiated during the Integration and

Test Phase:

Test Analysis Report

This report documents each test - unit/module, subsystem
integration,system, user acceptance and security.

Test Analysis Approval Determination

Attached to the test analysis report as a final result of the test
reviews and testing levels above the integration test; briefly
summarizes the perceived readiness for migration of the software.
Test Problem Report Document problems encountered during testing;
the form is attached to the test analysis reports.

92
MBA 815 MODULE 2

IT Systems Security Certification and Accreditation

The documents needed to obtain certification and accreditation
of an information system before it becomes operational. They include:
System Security Plan; Rules of Behavior; Configuration Management
Plan, Risk Assessment; Security Test & Evaluation;
Contingency Plan; Privacy Impact Assessments; and the
certification and accreditation memorandums. The Systems
Security Plan and certification/accreditation package should
be approved prior to implementation, and every three years
thereafter.

3.5 Issues for Consideration

3.5.1 Development

There are threephaseprerequisitesthat shouldbe completedbeginning

this phase:

• Project management plan and schedule indicating

target date for completion of each module, and target date for
completion of system testing.
• System design document, containing program logic flow,
identifying any existing code to be used, and the subsystems
with their inputs and outputs.
• Unit/module and integration test plans, containing
testing requirements, schedules, and test case
specifications for unit and integration testing.

3.5.2 Integration and Testing

Security controls shall be tested before system

implementation to uncover all design and implementation flaws that
would violate security policy. Security Test and Evaluation
(ST&E) involves determining a system’s security mechanisms
adequacy for completeness and correctness, and the degree
of consistency between system documentation and actual
implementation. This shall be accomplished through a variety of
assurance methods such as analysis of system design
documentation, inspection of test documentation, and
independent execution of function testing and penetration
testing. Results of the ST&E affect security activities developed
earlier in the life cycle such as security risk assessment,
sensitive system security plan, and contingency plan. Each of these
activities will be updated in this phase, based on the results of
the ST&E. Build on the security testing recorded in the
software development documents, unit testing, integration testing,

93
MBA 815 MANAGEMENT INFORMATION SYSTEM

and system testing.

3.6 Phase Review Activity

3.6.1 Development

Upon completion of all Development Phase tasks and

receipt of resources for the next phase, the Project Manager,
together with the project team, should prepare and present a project
status review for the decision maker and project stakeholders. The
review should address:

(1) development Phase activities status,

(2) planning status for all subsequent life cycle phases
(with significant detail on the next phase, to
include the status of pending contract actions),
(3) resource availability status, and
(4) acquisition risk assessments of subsequent life cycle
phases, given the planned acquisition strategy.

3.6.2 Integration and Testing

Upon completion of all Integration and Test Phase tasks and receipt of
resources for the next phase, the Project Manager, together
with the project team, should prepare and present a project status
review for the decision maker and project stakeholders. The review
should address:

(1) integration and Test Phase activities status,

(2) planning status for all subsequent life cycle phases
(with significant detail on the next phase, to
include the status ofpending contract actions),
(3) resource availability status, and
(4) acquisition risk assessments of subsequent life cycle
phases given, the planned acquisition strategy.

4.0 CONCLUSION

Development is what converts the design model into

reality. It is important phase of system’s development. On
the other hand, integration and testing is used to fine-tune a system
to detect errors and shortcomings in systems development processes.

94
MBA 815 MODULE 2

5.0 SUMMARY

• The objective of the Development Phase will be

to convert the deliverables of the Design Phase into a
complete information system.
• The objective of the integration and testing phase is to prove that
the developed system satisfies the requirements defined. Several
types of tests will be conducted in this phase.
• Conduct qualification testing in accordance with the
qualification requirements for the software item. Ensure that
the implementation of each software requirement is tested for
compliance.
• The project Manager is responsible and
accountable for the successful execution of the Development
Phase.
• The Configuration Manager should finalize the
Configuration Management Plan from the Planning Phase.
• The Contingency Plan contains emergency response
procedures; backup arrangements, procedures, and
responsibilities; and post-disaster recovery procedures and
responsibilities.
• Security controls shall be tested before system
implementation to uncover all design and
implementation flaws that would violate security policy.
• Upon completion of all Development, Integration
and Test Phase tasks and receipt of resources for the next
phase, the Project Manger, together with the project team, should
prepare and present a project status review for the decision maker
and project stakeholders.

The next study unit is on implementation and disposition of system.

6.0 TUTOR-MARKED ASSIGNMENT

Compare and contrast roles and responsibilities during

development phase and integration and testing phases of systems
development.

7.0 REFERENCES/FURTHER READING

Information Resources Management (2003). The Department of

Justice Systems Development Lifecycle Guidance Document.

Norton, P (1995). Introduction to Computers. Macmillan/McGraw-Hill.

95
MBA 815 MANAGEMENT INFORMATION SYSTEM

UNIT 4 IMPLEMENTATION AND DISPOSITION

OF SYSTEM

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Implementation and Disposition Phases
3.1.1 Implementation
3.1.2 Disposition
3.2 Tasks and Activities
3.2.1 Implementation
3.2.2 Disposition
3.3 Roles and Responsibilities
3.3.1 Implementation
3.3.2 Disposition
3.4 Deliverables
3.4.1 Implementation
3.4.2 Disposition
3.5 Issues for Consideration
3.5.1 Implementation
3.5.2 Disposition
3.6 Phase Review Activity
3.6.1 Implementation
3.6.2 Disposition
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

From the previous study unit, you have leant about the Development and
Integration and testing phase.

This unit focuses on Implementation and Disposition of system, related

tasks and activities, roles and responsibilities as they concern
system implementation and disposition.

2.0 OBJECTIVES

This unit is designed for you to:

• know what constitutes system’s implementation and

disposition phase in designing and developing information

96
MBA 815 MODULE 2

system
• identify the tasks you need to embark on during the
implementation and disposition phase of systems development
• comfortably answer the question of responsibilities
and roles in executing the implementation and
disposition phase of a systems development project
• be able to know what are the deliverables, from implementation
and disposition to be used for subsequent phases
• identify some issues that need to be considered in
implementation and disposition phase of a system.

3.0 MAIN CONTENT

3.1 Implementation and Disposition Phases

3.1.1 Implementation

Implementation phase of the system development in system’s

design and development is the most expensive and time consuming of
the entire life cycle. Implementation is expensive because so
many people are involved in the process. It is time consuming
because of all the works that has to be completed;
implementing a developed and new information system into
an organizational context is not a mechanical process. The
organizational concept has been shaped and reshaped by
the people who work in the organization. The work
habits, belief, interrelationships, and personal goals of an
organization’s members, all affect the implementation process.
Although factors important to successful implementation
have been identified, there are no more recipes you can
follow. During implementation, you must be attuned to
key aspects of the organizational context such as history, politics,
and environmental demands - aspects that can contribute to
implementation failure if ignored.

In this phase, the system or system modifications are installed and made
operational in a production environment. The phase is initiated after the
system has been tested and accepted by the user and Project Manager.

Activities in this phase include notification of implementation

to end users, execution of the previously defined training plan,
data entry or conversion, and post implementation review. This phase
continues until the system is operating in production in
accordance with the defined user requirements.

97
MBA 815 MANAGEMENT INFORMATION SYSTEM

The new system can fall into three categories; replacement of a

manualprocess, replacement of a legacy system, or
upgrade to ansystem Regardless of the type of system,
all aspects of theimplementation phase should be
followed. This will ensure the smoothest possible transition to
the organization’s desired goal.

3.1.2 Disposition

The Disposition Phase will be implemented to eliminate a large part of a

system or as in most cases, close down a system and end the life
cycle process. The system in this phase has been
declared surplus obsolete and will be scheduled for shutdown. The
emphasis of this phase will be to ensure that data, procedures, and
documentation are packaged and archived in an orderly fashion,
making it possible to reinstall and bring the system back to an
operational status, if necessary, and to retain all data records in
accordance with policies regarding retentionelectronicrecords.
The Disposition Phase represents the end ofsystem’s life
cycle. A Disposition Plan shall be prepared to address allfacets of
archiving, transferring, and disposing of the system and data.

Particular emphasis shallbe given to proper preservation of

the processed by thesystem so
thatitiseffectivelymigratedtosystem, or archived in accordance with
applicable records management
regulations and policies for potential future access. The
system disposition activities preserve information not only
about the current production system but also about the evolution of the
system through its life cycle.

3.2 Tasks and Activities

3.2.1 Implementation

Tasks and activities in the implementation phase are

associated with certain deliverables described in section 3.2. of Unit3.
The tasks andactivities actually performed depend on the nature
of the project description of these tasks and activities is provided
below.

Notify Users of New Implementation

The implementation notice should be sent to all users and organizations
affected by the implementation. Additionally, it is good policy to make
internal organizations not directly affected by the implementation aware
of the schedule, so that allowances can be made for a disruption in
98
MBA 815 MODULE 2

the normal activities of that section. Some notification methods are

email, internal memo to heads of departments, and voice tree
messages. The notice should include:

• the schedule of the implementation;

• a brief synopsis of the benefits of the new system;
• the difference between the old and new system;
• responsibilities of end user affected by the implementation
during this phase; and
• the process to obtain system support, including contact names
and phone numbers.

Execute Training Plan

It is always a good business practice to provide training before the
end user uses the new system. Because there has been a previously
designed training plan established, complete with the system
user manual, the execution of the plan should be
relatively simple. Typically what prevents a plan from
being implemented is lack of funding. Good budgeting
should prevent this from happening.

Perform Data Entry or Conversion

With the implementation of any system, typically there is old data which
is to be included in the new system. This data can be in a manual or an
automated form. Regardless of the format of the data, the tasks in this
section are two fold, data input and data verification. When replacing a
manual system, hard copy data will need to be
entered into the automated system. Some sort of
verification that the data is being entered correctly should be
conducted throughout this process. This is also the case in data
transfer, where data fields in the old system may
have been entered inconsistently and therefore affect the integrity of the
new database. Verification of the old data becomes
imperative to a useful computer system.

One of the ways verification of both system operation and data integrity
can be accomplished is through parallel operations. Parallel
operations consist of running the old process or system
and the new system simultaneously until the new system is
certified. In this way, if the new system fails in any way, the
operation can proceed on the old system while the bugs are worked out.

Install System
To ensure that the system is fully operational, install the
system in a production environment.

99
MBA 815 MANAGEMENT INFORMATION SYSTEM

Conduct Post-Implementation Review

Afterthesystemhasbeenfielded,apost-implementation review
conducted to determine the successoftheproject
throughit’simplementationphase.Thepurposeofthisreviewistoimplemen
tation experiences, to recommend system enhancements, and provide
guidance for future projects.

In addition, change implementation notices will be utilized to document

Userrequestsforfixes toproblems thatmay havebeenduring this
phase. It is important to document any user request for a
change to a system to limit misunderstandings between the end user and
the system programmers.

Revise Previous Documentation

During this phase, the ICD is revised from the Requirements
Analysis Phase. The CONOPS, System Security Plan, Security Risk
Assessment, Software Development Document, System Software and the
Integration Document, are also revised and finalized during
the Implementation Phase.

3.2.2 Disposition

The objectives for all tasks identified in this phase are

to retire system, software, hardware, and data. The tasks and
activities actually performed are dependent on the nature of the
project. The disposition activities are performed at the end
of the systems life cycle disposition activities ensure the
orderly termination of the system, and preserve vital information about
the system so that some or all of it, may be reactivated in the future,
if necessary. Particular emphasis shall be given to proper
preservation of the data processed by the system, so that
the data are effectively migrated to another system, or disposed
of in accordance with applicable records management and
program area regulations and policies for potential future access.
These activities may be expanded, combined or deleted, depending on
the size of the system.

Prepare Disposition Plan

The Disposition Plan must be developed and
implemented. The Disposition Plan will identify how the
termination of the system/data will be conducted, and when, as
well as the system termination date, software components to be
preserved, data to be preserved, disposition of remaining equipment,
and archiving of life-cycle products.

100
MBA 815 MODULE 2

Archive or Transfer Data

The data from the old system will have to be transferred into the
new system or if it is obsolete, archived.

Archive or Transfer Software Components

Similar to the data that is archived or transferred, the
software components will need to be transferred to the new system,
or if that is not feasible, disposed of.

Archive Life Cycle Deliverables

A lot of documentation went into developing the application or system.
This documentation needs to be archived, where it can be referenced,
if needed at a later date.

End the System in an Orderly Manner

Follow the Disposition Plan for the orderly breakdown of the system, its
components, and the data within.

Dispose of Equipment
If the equipment can be used elsewhere in the organization, recycle. If it
is obsolete, notify the property management office, to
excess all hardware components.

Conduct Post-Termination Review Report

This review will be conducted at the end of the Disposition Phase
and again, within 6 months after disposition of the system by
the Project Manager.

3.3 Roles and Responsibilities

3.3.1 Implementation

• Project Manager: The project manager is responsible

and accountable for the successful execution of the
Implementation Phase. The project manager is responsible for
leading the team that accomplishes the tasks shown above.
The project manager is also responsible for reviewing
deliverables for accuracy, approving deliverables and
providing status reports to management.
• Project Team: The project team members (regardless
of the organization of permanent assignment) are
responsible for accomplishing assigned tasks as directed by the
project manager.
• Contracting Officer: The contracting officer is
responsible and accountable for the procurement activities and
signs contract awards.

101
MBA 815 MANAGEMENT INFORMATION SYSTEM

• Oversight Activities: Agency oversight activities,

including the IRM office, provide advice and counsel for the
project manager on the conduct and requirements of
the Implementation Phase. Additionally, oversight
activities provide information, judgments, and
recommendations to the agency decision makers during project
reviews and in support of project decision milestones.

3.3.2 Disposition

• Project Manager: The Project Manager is responsible

and accountable for the successful execution of the
Disposition Phase activities.
• Data Administrator: The Disposition Plan may direct
that only certain systems data be archived.The
DataAdministrator identify the data and
assisttechnicalpersonnel with thea chive process. The
Data Administrator may be involved with identifying
data which due to its sensitive nature must be destroyed.
They would also be involved with identifying and migrating data
to a new or replacement system.
• Security Managers: The security managers will need to make
sure that all access authority has been eliminated for the users.
Any users that only use the application should be
removed from the system while others that use other
applications as well as this one may still need access to the
overall system, but not the application being shut-
down. If there is another application that is taking the place of
this application, the security managers should coordinate
with the new security managers.

3.4 Deliverables

3.4.1 Implementation

The following deliverables are initiated during the

Implementation Phase:

Delivered System
After the Implementation Phase Review and Approval Certification
is signed by the Project Manager and the System Proponent
representative, the system - including the production version of the data
repository - is delivered to the customer for the Operations and
Maintenance Phase.

102
MBA 815 MODULE 2

Change Implementation Notice

A formal request and approval document for changes made during
the Implementation Phase.

Version Description Document

The primary configuration control document used to track and
control versions of software released to the operational
environment. It is a summary of the features and contents for the
software build and identify and describe the version of the software being
delivered

Post-Implementation Review
The review is conducted at the end of the Implementation Phase. A post-
implementation review shall be conducted to ensure that
the system functions as planned and expected; to verify
that the system cost is within the estimated amount; and to verify
that the intended benefits are derived as projected. Normally, this shall
be a one-time review, and it occurs after a major implementation;
it may also occur after a major enhancement to the system.
The results of an unacceptable review are submitted to the System
Proponent for its review and follow-up actions. The System
Proponent may decide it will be necessary to return the
deficient system to the responsible system development Project Manager
for correction of deficiencies.

3.4.2 Disposition

The following deliverables are initiated and finalized

during the Disposition Phase

Disposition Plan
The objectives of the plan are to end the operation of the system in a
planned, orderly manner, and to ensure that system components and data
are properly archived or incorporated into other systems.
This will include removing the active support by the operations and
maintenance organizations. The users will need to play an active role in
the transition. All concerned groups will need to be kept informed of the
progress and target dates. The decision to proceed with Disposition will
be based on recommendations and approvals from an In-Process Review
or based on a date (or time period) specified in the System
Boundary Document (SBD).

This plan will include a statement of why the application is no longer

supported, a description of replacement / upgrade, list of tasks/activities
(transition plan) with estimated dates of completion, and the notification
strategy. Additionally, it will include the responsibilities

103
MBA 815 MANAGEMENT INFORMATION SYSTEM

for future residual support issues, such as identifying

media alternatives if technology changes; new software
product transition plans and alternative support issues (once
the application is removed); parallel operations of retiring, and
the new software product; archiving of the software product,
associated documentation, movement of logs, code; and
accessibility of archive, data protection identification, and
audit applicability.

Post-Termination Review Report

A report at the end of the process that details the
findings Disposition Phase review. It includes details
of where to find products and documentation that has been
archived.

Archived System
The packaged set of data and documentation containing the
archived application.

3.5 Issues for Consideration

3.5.1 Implementation

Once a system has been developed, tested and deployed, it will enter the
operations and maintenance phase. All development
resources and documentation should be transferred to a library or
the operations and maintenance staff.

3.5.2 Disposition

Update of Security plans for archiving and the

contingency plans reestablish the system, should be in place.

All documentation about the application, system logs and

configuration will be archived, along with the data and a copy of the
Disposition Plan.

3.6 Phase Review Activity

3.6.1 Implementation

During the Implementation Phase Review, recommendations

may be made to correct errors, improve user satisfaction, or
improve system performance. For contractor development, analysis
shall be performed to determine if additional activity is within the
scope of the statement of work, or within the original contract. An
104
MBA 815 MODULE 2

Implementation Phase Review and Approval Certification should be

signed off by the Project Manager to verify the acceptance of
the delivered system by the system’s users/owner.

The Implementation Phase-End Review shall be organized, planned, and

led by the Project Quality Assurance representative.

3.6.2 Disposition

The Post-Termination Review shall be performed after the end of this

final phase. This phase-end review shall be conducted within 6 months
after disposition of the system. The Post-Termination Review
Report documents the lessons learned from the shutdown and archiving
of the terminated system.

4.0 CONCLUSION

Most information systems have failed because of the ineffectiveness and

inefficiency in the implementation of the concept and model. The right
team should be put together to ensure safe and accurate implementation
of systems. On the other hand, disposition of developed
information system is necessary for continuity and future reference. It is
particularly important for system’s re-evaluation a redesign. It also
ensures a perfect completion of a project cycle, to make room for other
projects.

5.0 SUMMARY

• Implementation phase of the system development in system’s

design and development is the most expensive and time
consuming of the entire life cycle. Implementation is
expensive because so many people are involved in the
process.
• The Disposition Phase will be implemented to eliminate a large
part of a system or, as in most cases, close down a system and end
the life cycle process.
• The implementation notice should be sent to all
users and organizations affected by the implementation.
• One of the ways verification of both system
operation and data integrity can be accomplished, is through
parallel operations.
• With the implementation of any system, typically there is
old data which is to be included in the new system. This
data can be in a manual or an automated form.
• The Disposition Plan must be developed and implemented.
• After the Implementation Phase Review and Approval

105
MBA 815 MANAGEMENT INFORMATION SYSTEM

Certification issignedbytheProjectManager and the

System is representative, the system - including the
production version of the data repository - is delivered to the
customer for the Operations and Maintenance Phase.
• The objectives of the disposition plan are to end the operation of
the system in a planned, orderly manner, and to
ensure thatcomponents and data are properly archived or
incorporated into othersystems.
• During the Implementation Phase Review, recommendations may
be made to correct errors, improve user satisfaction or improve
system performance.
• The Post-Termination Review shall be performed after
the end of this final phase.

The next study unit is on operations and maintenance of system design.

6.0 TUTOR-MARKED ASSIGNMENT

Discuss the differences between Implementation and Disposition phases

based on tasks and activities.

7.0 REFERENCES/FURTHER READING

Information Resources Management (2003). The Department of Justice

Systems Development Lifecycle Guidance Document.

Jeffrey, A. H. Joey, F.G. & Joseph, S.V. (2005). Pearson Prentice Hall.

Norton, P (1995). Introduction to Computers. Macmillan/McGraw-Hill.

106
MBA 815 MODULE 2

UNIT 5 OPERATIONS AND MAINTENANCE OF

SYSTEM DESIGN

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Maintenance Phase
3.1.1 Types of Maintenance
3.2 Tasks and Activities
3.3 Roles and Responsibilities
3.4 Deliverables
3.5 Issues for Consideration
3.6 Phase Review Activity
3.7 Maintenance Cost
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

This unit treats the final phase of system design which is, operations and
maintenance. It also dwells on related issues on tasks
and activities, roles and responsibilities, deliverables phase
review activity and finally, maintenance cost.

2.0 OBJECTIVES

This unit is designed for you to:

• be able to identify the different types of maintenance

• understand what constitutes operations and
maintenance phase in designing and developing information
system
• identify the tasks you need to embark on during the operations
and maintenance phase of systems development
• comfortably answer the question of responsibilities
and roles in executing the operations and
maintenance phase of a systems development project
• be able to know what are the deliverables from
operations and maintenance to be used for subsequent
phases
• identify some issues that need to be considered in
operations and maintenance phase of a system

107
MBA 815 MANAGEMENT INFORMATION SYSTEM

• explain the relationship between cost of maintenance

phase compared to other phases of systems development.

3.0 MAIN CONTENT

3.1 Maintenance Phase

More than half of the life cycle costs are attributed to the operations and
maintenance of systems. In this phase, it is essential that all facets
of operations and maintenance be performed. The system is
being used, and scrutinized, to ensure that it meets the needs initially
stated in the planning phase. Problems are detected, and new needs
arise. This may require modification to existing code, new code to be
developed and/or hardware configuration changed. Providing user
support is an ongoing activity. New users will require training, and
others will require training as well. The emphasis of this phase
will be to ensure that the user’s needs are met and the system
continues to perform as specified in the operational environment.
Additionally, as operations and maintenance personnel monitor the
current system, they may become aware of better
ways to improve the system and therefore make
recommendations. Changes will be required to fix problems,
possibly add features and make improvements to the system.
This phase will continue as long as the system is in use.

When a system is in maintenance phase, some

persons within system’s development group are responsible for
collecting maintenance request from systems users and other interested
parties such as systems auditors, data center, network management staff
and data analysts. Once collected, each request is analyzed. To better
understand it, it will alter the system and what business benefits and
necessities will result from such a change. If the change request
is approved, a system change is designed and then implemented. As
with the initial development of the system implemented, changes are
formally reviewed and tested before installation into operational
systems

3.1.1 Types of Maintenance

There are several types of maintenance you can

perform on an information system. By maintenance we mean, the
fixing or enhancing of an information system.

1. Corrective Maintenance: this refers to changes made

to repair defects in the design, coding or implementation of
the system. For example, if you have just purchased

108
MBA 815 MODULE 2

a new home, corrective maintenance would involve

repairs to things that had never worked as designed, such as,
faulty electrical outlet, or a misaligned door. Most
corrective maintenance faults surface soon after
installation. When corrective maintenance problems
surface, they are typically urgent, and need to be
resolved to curtail possible interruption normal
business activities. Of all types of maintenance, corrective
maintenance account for activities as much as 75%
of all maintenance (Andrew and Leventhal). This is
unfortunate because corrective maintenance adds little or no
value to the organisation, it simply focuses on removing defects
from an existing system without adding new functionality.
2. Adaptive Maintenance: This involves making changes to evolve
its functionality, to changing business needs, or to migrate to a
different operating environment. Within a home, adaptive
maintenance might be adding storm windows to improve the
cooling performance of an air-conditioner. Adaptive
maintenance is usually less urgent than corrective
maintenance because of business and technology. Changes
typically occur over some period of time. Contrary
to corrective maintenance, adaptive maintenance is
generally a small part of an organization’s maintenance
effort, but it adds value to the organization.
3. Perfective Maintenance: this involves making
enhancement to improve processing performance or
interface usability or to add desired, but not necessarily
required system’s features. In our home
example, Perfective maintenance would be adding a
new room. Many systems professionals feel that
Perfective correction is not really maintenance, but rather
new development.
4. Preventive Maintenance: This involves changes made to a
system to reduce the chances of future system’s
failure. An example of preventive maintenance might be
to increase the number of records that the system process far
beyond what is currently needed, or to generalize how a system
sends report information to a printer so that the system can easily
adapt to changes in technology. In our home
example, preventive maintenance could be painting of the exterior
to better protect the room from severe weather
conditions. As with adaptive maintenance, both Perfective
and preventive maintenance are typically a much lower
priority than corrective maintenance.

109
MBA 815 MANAGEMENT INFORMATION SYSTEM

Over the life of a system, corrective maintenance is most likely to occur

after initial system installation or after major changes. This means that
adaptive maintenance, Perfective maintenance, and preventive
maintenance activities can lead to corrective maintenance
activities if not carefully designed and implemented.

3.2 Tasks and Activities

Identify Systems Operations

Operations support is an integral part of the day-to-day operations of a

system. In small systems, all or part of each task may be done by the
same person. But in large systems, each function may
be done separate individuals or even separate areas. The
Operations Manual is developed in previous SDLC phases.
These documents define tasks, activities and responsible parties,
and will need to be updated as changes occur. Systems operations
activities and tasks need to be scheduled, on a recurring basis,
toensure that the production environment
isfunctional, and is performing as specified. The following is a checklist
of systems’ operations’ key tasks and activities:

• Ensure that systems and networks are running, and available

during the defined hours of Operations;
• Implement non-emergency requests during scheduled
Outages, as prescribed in the Operations Manual;
• Ensure all processes, manual and automated, are documented in
the operating procedures. These processes should
comply with the system documentation;
• Acquisition and storage of supplies (i.e. paper,
toner, tapes,removable disk);
• Perform backups (day-to-day protection, contingency);
• Perform the physical security functions including ensuring
adequate UPS, Personnel have proper security clearances
and proper access privileges etc.;
• Ensure contingency planning for disaster recovery is
currentand tested ;
• Ensure users are trained on current processes and new processes;
• Ensure that service level objectives are kept
accurate and are monitored;
• Maintain performance measurements, statistics, and
system logs. Examples of performance measures include
volume and frequency of data to be processed in each mode, order
and type of operations;
• Monitor the performance statistics, report the results
and escalate problems when they occur.

110
MBA 815 MODULE 2

Maintain Data /Software Administration

Data/Software Administration is needed to ensure that input
data and output data and data bases are correct and
continually checked accuracy and completeness. This includes
ensuring that any regularly scheduled jobs are submitted and
completed correctly. Software and data bases should be
maintained at (or near) the current maintenance level. The
backup and recovery processes for data bases are normally
different than the day-to-day DASD volume backups. The backup
and recovery process of the data bases should be done as a
Data/SoftwareAdministration task by a data administrator.
A checklist of Data/Software Administration tasks and activities
are:
• Performing a periodic Verification/Validation of data,
correct datarelated problems;
• Performing production control and quality control
functions (Jobsubmission, checking and corrections);
• Interfacing with other functional areas for Day-to-day
checking/corrections;
• Installing, configuring, upgrading and maintaining data base(s).
This includes updating processes, data flows, and objects (usually
shown in diagrams);
• Developing and performing data/data based backup
and recovery routines for data integrity and
recoverability. Ensure documented properly in the Operations
Manual;
• Developing and maintaining a performance and
tuning plan for online process and data bases;
• Performing configuration/design audits to ensure software,
system, parameter configuration are correct.

Identify Problem and Modification Process

One fact of life with any system is that change is inevitable. Users need
an avenue to suggest change and identified problems.
A User Satisfaction Review which can include a Customer
Satisfaction Survey can be designed and distributed to
obtain feedback on operational systems, to help determine
if the systems are accurate and reliable. Systems
administrators and operators need to be able to make
recommendations for upgrade of hardware, architecture and
streamlining processes. For small in-house systems,
modification requests can be handled by an in-house process.
For large integrated systems, modification requests may be
addressed in the Requirements document, and may take the
form of a change package, or a formal Change
Implementation Notice and may require justification and cost

111
MBA 815 MANAGEMENT INFORMATION SYSTEM

benefits analysis for approval by a review board. The

requirements document for the project may call for a modification cut-
off and rollout of the system as a first version, and all subsequent
changes addressed as a new or enhanced version of the system. A request
for modifications to a system may also generate a new
project and require a new initiation plan.

Maintain System/Software
Daily operations of the system /software may necessitate
that maintenance personnel identify potential modifications needed to
ensure that the system continues to operate as intended and
produces quality data. Daily maintenance activities for the system, takes
place to ensure that any previously undetected errors are fixed.
Maintenance personnel may determine that modifications to
the system and databases needed to resolve errors or
performance problems. Also modifications may be needed to
provide new capabilities or to take advantage
hardware upgrades or new releases of system software and application
software used to operate the system. New capabilities may take the form
of routine maintenance or may constitute enhancements to the system or
database as a response to user requests for new/improved
capabilities. New capabilities needs may begin a new problem
modification process described above.

Revise Previous Documentation

At this phase of the systems development all security
activities have been completed. An update must be made to the System
Security plan; an update and test of the
contingencyplanshould becontinuous vigilance should be
given to virus and intruder detection. The Project Manager must be
sure that security operating procedures are kept updated accordingly.
Review and update documentation from the previous phases. In
particular, the Operations Manual, SBD and Contingency
Plan, need to be updated and finalized during the
Operations and Maintenance Phase.

3.3 Roles and Responsibilities

This list briefly outlines some of the roles and responsibilities for
key maintenance personnel. Some roles may be
combined orending upon the size of the system to be maintained.
Each system will dictate the necessity for the roles listed below:
• Systems Manager: The Systems Manager develops documents
and executes plans and procedures for conducting activities and
tasks of the Maintenance Process. To provide for
anavenue of reporting and customer satisfaction,

112
MBA 815 MODULE 2

the Systems Manager should create and discuss

communications instructions with the systems
customers.
• Technical Support: Personnel which proved technical support to
the program. This support may involve granting
access rights to the program. Setup of workstations or
terminals to access the system. Maintaining the operating
system for both server and workstation.
Technical support personnel may be involved with issuing user
ids or login names and passwords. In a Client server environment
technical support may perform systems scheduled
backups and operating system maintenance during downtime.
• Operations or Operators (Turn On/Off Systems, Start
Tasks, Backup etc): For many mainframe systems, technical
support for a program is provided by an operator.
The operator performs scheduled backup, performs
maintenance during downtime, and is responsible to
ensure the system is online and available for users.
Operators may be involved with issuing user ids or login names
and passwords for the system.
• Customers: The customer needs to be able to share with the
systems manager the need for improvements or the
existence of problems. Some users live with a situation or
problem because they feel they must. Customers may feel
that change will be slow or disruptive. Some feel the
need to create work-around. A customer has the
responsibility to report problems or make
recommendations for changes to a system.
• Program Analysts or Programmer: Interprets user
requirements, designs and writes the code for specialized
programs. User changes, improvements, enhancements may be
discussed in Joint Application Design sessions. Analysts
programs for errors, debugs the program and tests program
design.
• Process Improvement Review Board: A board of individuals may
be convened to approve recommendations for
changes and improvements to the system. This
group may be chartered. The charter should outline what
should be brought before the group for consideration and
approval. The board may issue a Change Directive.
• Users Group or Team: A group of computer
users who share knowledge they have gained concerning a
program or system. They usually meet to exchange
information, share programs and can provide expert
knowledge for a system under consideration for
change.

113
MBA 815 MANAGEMENT INFORMATION SYSTEM

• Contracting Officer: The contracting officer is

responsible and accountable for the procurement activities, and
signs contract award.
• Data Administrator: Performs tasks which ensure that accurate
and valid data are entered into the system. Sometimes this person
creates the information systems database, maintains the
databases security and develops plans for disaster recovery. The
data administrator may be called upon to create queries
and reports for a variety of user requests. The data
administrator is responsibilities include maintaining the
databases data dictionary. The data dictionary provides
a description of each field in the database,
thecharacteristics, and what data is maintained with the
field.
• Telecommunications Analyst and Network System
Analyst: Plans, installs, configures, upgrades and
maintains networks as needed. If the system
requires it, he ensures that external communications
and connectivity are available.
• Computer Systems Security Officer (CSSO): The
CSSO has a requirement to review system change
requests, review and in some cases, coordinate the Change
Impact Assessments, participate in the Configuration Control
Board process, and conduct and report changes that
may be made, that affect the security posture of the
system.

3.4 Deliverables

In-Process Review Report

The In-Process Review (IPR) occurs at predetermined
milestones usually quarterly, but at least once a year. The
performance measures should be reviewed along with the health
of the system. Performance measures should be measured
against the baseline measures. Ad-hoc reviews should be
called when deemed necessary by either document the results of
this review in the IPR Report.

User Satisfaction Review Report

User Satisfaction Reviews can be used as a tool to determine the current
user satisfaction with the performance capabilities of an
existing application or initiate a proposal for a new system. This
review can be used as input to the IPR Report.

114
MBA 815 MODULE 2

3.5 Issues for Consideration

Documentation

It can not be stressed enough, that proper documentation for the duties
performed by each individual responsible for system maintenance
and operation should be up-to-date. For smooth day -to -day
operations of any system, as well as disaster recovery, each
individual’s role, duties and responsibilities should be outlined
in detail. A systems administrator’s journal or log of
changes performed to the system software or hardware is
invaluable in times of emergencies. Operations manuals, journals or logs
should be readily accessible by maintenance personnel.

Guidelines in determining New Development from Maintenance

Changes to the system should meet the following criteria in order for the
change or modification request to be categorized as
Maintenance; otherwise it should be considered as New Development:

• Estimated cost of modification are below maintenance costs

• Proposed changes can be implemented within one system year
• Impact to system is minimal or necessary for accuracy
of system output

Security Re-certification
Federal IT security policy requires all IT systems to be accredited prior
to being placed into operation and at least every three years thereafter, or
prior to implementation of a significant change.

3.6 Phase Review Activity

Review activities occur several times throughout this phase. Each time
the system is reviewed, one of three of the following decisions will be
made:

• The system is operating as intended and meeting

performance expectations.
• The system is not operating as intended and needs
correctionsor modifications.
• The users are/are not satisfied with the operation and performance
of the system.

The In-Process Review shall be performed to evaluate

system performance, user satisfaction with the system, adaptability to
changing business needs, and new technologies that might
improve the system. This review is diagnostic in nature and can

115
MBA 815 MANAGEMENT INFORMATION SYSTEM

trigger a project to re-enter a previous SDLC phase. Any major system

modifications needed after thesystem has been implemented
will follow the SDLC process
planning through implementation.

3.7 Maintenance Cost

Information system maintenance costs are significant expenditure.

For some organizations as much as 60% to 80% of their information
system budget is allocated to maintenance activities (Kaplan,
2002). This proportion has risen from roughly 50% 20 years ago, due
to the fact that many organizations have accumulated more and older
so called legacy systems that require more and more
maintenance. More maintenance means more maintenance work
for programmers. A recent opinion poll of over 20 executives
revealed that on average, 52% of a company’s programmers are
assigned to maintain existing software (Lytton, 2001).

Only3% is assigned to new applicationdevelopment.Inwhere

a company has not developed its in-house system, but
licensed software, maintenance cost remains high. In many cases
annualmaintenance fee can be as high as 20% of the up-front cost
(Worthen,2003). In addition, about one third of the
cost of
establishingkeepingapresenceonthewebgoestoprogrammingLegard,
2000).

4.0 CONCLUSION

Operations and maintenance is continual through out

the life of poject and thus could be the most expensive and
cumbersome. In fact it is considered as the longest of all the systems
development phases. It consists of making sure that developed
systems run in operational use and continues to do so for as long as is
required. The Centre of Software maintenance estimates that 50% and
90% of cost of computer systems over its lifetime is maintenance.

5.0 SUMMARY

• More than half of the life cycle costs are attributed to the
operations and maintenance of systems. In this phase,
it is essential that all facets of operations and maintenance
be performed.
• When a system is in maintenance phase, some persons
within the systems development group is responsible
for collecting maintenance request from systems users and

116
MBA 815 MODULE 2

other interested parties such as systems auditors, data center,

network management staff, and data analysts.
• When corrective maintenance problems surface, they are
typically urgent and need to be resolved to curtail
possible interruption in normal business activities.
• One fact of life with any system is that change is inevitable.
Users need an avenue to suggest change and identified problems.
• Daily operations of the system /software may
necessitate that maintenance personnel identify potential
modifications neededto ensure that the system continues to
operate as intended and produces quality data.
• Operations support is an integral part of the day-to-day operations
of a system. In small systems, all or part of each task may be
done by the same person.
• The Systems Manager develops documents and executes plans
and procedures for conducting activities and tasks of the
Maintenance Process. To provide for an avenue of
problem reporting and customer satisfaction.
• It can not be stressed enough, that proper
documentation for the duties performed by each
individual responsible for system is maintenance and
operation should be up-to-date.
• Information system maintenance costs are significant
expenditure.

For some organizations as much as 60% to 80% of their information

system budget is allocated to maintenance activities.

The next study unit is on DSDM.

6.0 TUTOR-MARKED ASSIGNMENT

1. Identify and discuss the uniqueness of each of

the form of systems development maintenance.
2. What are the activities associated with the
operations and maintenance phase of systems development.

7.0 REFERENCES/FURTHER READINGS

Information Resources Management (2003). The Department of Justice

Systems Development Lifecycle Guidance Document.

Jeffrey, A.H. Joey, F.G. & Joseph, S.V. (2005). Pearson Prentice Hall.

Norton, P (1995). Introduction to Computers. Macmillan/McGraw-Hill.

117
MBA 815 MANAGEMENT INFORMATION SYSTEM

MODULE 3

Unit 1 Dynamic Systems Development Method

Unit 2 Project Management
Unit 3 Project Planning
Unit 4 Risk Assessments and Management
Unit 5 Design and Planning for GIS

UNIT 1 DYNAMIC SYSTEMS DEVELOPMENT

METHOD

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Dynamic System Development Methods
3.1.1 Principles of DSDM
3.2 Prerequisites for Using DSD
3.3 The Phases of DSDM
3.3.1 Phase 1: The Project life-cycle
3.3.2 Phase 2: The Project life-cycle
3.3.2.1 Stage 1: The Feasibility Study
3.3.2.2 Stage 2: The Business Study
3.3.2.3 Stage 3: Functional Model Iteration
3.3.2.4 Stage 4: Design and Build Iteration
3.3.2.5 Stage 5: Implementation
3.3.3 Phase 3: Post -Project
3.4 Core Techniques of DSDM
3.5 Roles of DSDM
3.6 Critical Success Factors of DSDM
3.7 Comparison to other IS Development Methods
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Reading

1.0 INTRODUCTION

This unit introduces you to the principles, techniques, roles and phases
of DSDM. Issues such as critical success factors of
DSDM and comparison between DSDM and Development methods
are treated.

118
MBA 815 MODULE 3

2.0 OBJECTIVES

This unit of the course is designed for you to:

• be able to explain what is a dynamic systems development method

• identify the basic principles of dynamic systems
development method
• identify and differentiate the different phases of a DSDM
• identify and differentiate the various techniques to DSDM
• be able to identify and discuss the success
factors behind the operations of dynamic system
development method.

3.0 MAIN CONTENT

3.1 Dynamic System Development Methods (DSDM)

Dynamic Systems Development Method (DSDM) is a

framework based originally around Rapid Application
Development (RAD), supported by its continuous user
involvement in an iterative development and incremental
approach which is responsive to changing requirements, in order to
develop a system that meets the business needs on time and on
budget. It is one of a number of Agile developing
software and forms part of the Agile Alliance.

DSDM was developed in the United Kingdom in the

1990s by consortium of vendors and experts in the field of
Information System (IS) development. The DSDM Consortium
combined their best-practice experiences. The DSDM
Consortium is a non-profit and vendor independent
organisation which owns and administers the framework. The
first version was completed in January 1995 and
published Fnebruary 1995. The current version in use at this point
in time (April 2006) is Version 4.2: Framework for Business Centered
Development, released in May 2003.

As an extension of rapid application development, DSDM focuses on

Information Systems, projects that are characterized by tight schedules
And budgets. DSDM addresses the common reasons for system’s
project failure, including exceeding budgets, missing
deadlines, and lack of user involvement, and top
management commitment.

DSDM consists of 3 phases: pre-project phase, project life-cycle

phase, and post project phase. The project life-cycle phase is subdivided

119
MBA 815 MANAGEMENT INFORMATION SYSTEM

into 5 stages: feasibility study, business study, functional

model iteration, design and build iteration, and implementation.

DSDM recognizes that projects are limited by time and resources,

and plans accordingly to meet the business needs. In order to achieve
these goals, DSDM encourages the use of RAD with the consequent
danger that too many corners are cut. DSDM applies some principles,
roles, and techniques.

In some circumstances, there are possibilities to integrate practices from

other methodologies, such as Rational Unified Process (RUP), Extreme
Programming (XP), and PRINCE2, as complements to DSDM. Another
agile method that has some similarity in process and concept to DSDM
is Scrum

3.1.1 Principles of DSDM

There are nine underlying principles of DSDM consisting

of four foundations and five starting-points for the
structure of the method. These principles form the cornerstones of
development using DSDM.

• User Involvement is the Main Key in running an

efficient and effective project, where both users and developers
share a workplace, so that the decisions can be made accurately.
• The Project Team must be Empowered to make decisions that are
important to the progress of the project, without waiting for
higherlevel approval.
• DSDM focuses on frequent delivery of products, with assumption
that to deliver something "good enough" earlier is always better
than to deliver everything "perfectly" in the end. By
delivering product frequently from an early stage of
the project, the product can be tested and reviewed where
the test record and review document can
be taken into account at the next iteration or phase.
• The main criteria for acceptance of deliverable in
DSDM is on delivering a system that addresses the current
business needs. It is not so much directed at delivering a perfect
system addressing all possible business needs, but
focuses its efforts on critical functionality.
• Development is Iterative And Incremental, driven by
users’ feedback to converge on an effective business solution.
• All changes during the development are reversible.
• The high level scope and requirements should be
base-lined before the project starts.
• Testing is carried out throughout the project life-cycle.

120
MBA 815 MODULE 3

• Communication and cooperation among all project stakeholders

is required to be efficient and effective. DSDM is also
supported by some other principles (or so called
assumptions).
• No system is built perfectly in the first try(the
paretoprinciple-80/20 rule). In the process of developing
an information system, 80% of the business benefit comes
from 20% of the system requirements, therefore DSDM starts
implementing this first 20% of system requirements to meet
80% of the business needs, which is good enough as
long as the users are intimately involved in the
development process, and in a position to ensure that
the missing 20% would not cause any serious
business consequences. Implementing the entire requirements
often causes the project to go over deadlines and budgets,
therefore it is most times unnecessary to construct the perfect
solution.
• Project delivery should be on time, on budget and
with good quality.
• DSDM only requires each step of the
development to be completed far enough for the next step to
begin. This way a new iteration of the project can commence
without having to wait for the previous to be completed
entirely. And with every iteration s ystem is
improved incrementally. Recall that the business
requirements are changing over time at any rate.
• Both Project Management and Development techniques
are incorporated in DSDM.
• DSDM can also be used both in new projects and for expanding
current systems.
• Risk assessment should focus on business function
being delivered, not on the construction process nor
on development process artifacts (such as requirements and
design documents).
• Management rewards product delivery rather than task
completion.
• Estimation should be based on business functionality instead
of lines of code.

3.2 Prerequisites for Using DSD

In order for DSDM to be a success, a number of prerequisites need to be

realized. First, there needs to be interactivity between the project team,
future end users and higher management. This addresses well
known failures of IS development projects due to lack of top
motivation and/or user involvement.

121
MBA 815 MANAGEMENT INFORMATION SYSTEM

The second important prerequisite for DSDM projects is

the decomposability of the project. The possibility of
decomposition into smaller parts enables the iterative approach, and
activities that are hard to prioritize often cause delays--exactly
the effect that DSDM developed to avoid. Another group of
projects for which DSDM is not well-suited are safety-critical ones. The
extensive testing and validation found in these kinds of projects conflict
with DSDM goals of being on time and on budget. Finally, projects that
aim at re-usable components might not be well-suited for
development using DSDM, because the demands on
perfection are too high and conflict with the 80%/20%
principle described earlier.

3.3 The Phases of DSDM

The DSDM framework consists of three sequential phases, namely the

pre-project, project life-cycle and post-project phases. The project phase
of DSDM is the most elaborate of the three phases. The
project life-cycle phase consists of 5 stages that form
an iterative step-by-step approach in developing an IS.
The three phases and corresponding stages are explained
extensively in the subsequent sections. For each
stage/phase, the most important activities are addressed
and the deliverables are mentioned.

3.3.1 Phase 1

The Pre-Project
In the pre-project phase candidate projects are identified, project funding
is realized and project commitment is ensured. Handling these issues at
an early stage avoids problems at later stages of the project.

3.3.2 Phase 2

The Project Life-Cycle

The process overview in the figure above shows the project life-cycle of
this phase of DSDM. It depicts the 5 stages a project will have
to go through to create an IS. The first two stages, the Feasibility
Study and Business Study are sequential phases that
complement to each other. After these phases have been
concluded, the system is developed iteratively and
incrementally in the Functional Model Iteration, Design
& Build Iteration and Implementation stages. The
iterative and incremental nature of DSDM will be addressed further in
a later section.

122
MBA 815 MODULE 3

3.3.2.1 Stage 1

The Feasibility Study

During this stage of the project, the feasibility of the project for the use
of DSDM is examined. Prerequisites for the use of DSDM are addressed
by answering questions like; ‘Can this project meet
the required business needs?’, ‘Is this project suited for the
use of DSDM?’ and ‘What are the most important risks
involved?’. The most important techniques used in this phase
are the Workshops. The deliverables for this stage are the Feasibility
Report and the Feasibility Prototype that address the feasibility of the
project at hand. It is extended with a global Outline Plan for the rest of
the project and a Risk Log that identifies the most important risks for the
project.

3.3.2.2 Stage 2

The Business Study

The business study extends the feasibility study. After the
project has been deemed feasible for the use of DSDM, this
stage examines the influenced business processes, user groups
involved and their respective needs and wishes. Again the
workshops is one of the most valuable techniques,
workshops in which the different stakeholders come
together to discuss the proposed system. The information
from these sessions is combined into a requirements list. An important
property of the requirements list is the fact that the
requirements are (can prioritized. These requirements are
prioritized using the MoSCoW approach. Based on this
prioritization, a development plan is constructed as a guideline for the
rest of the project. An important project technique used in the
development of this plan is time boxing. This technique is
essential in realizing the goals of DSDM, namely being on time and on
budget, guaranteeing the desired quality. A system
architecture is another aid to guide the development of the IS.

The deliverables for this stage are a business area

definition describes the context of the project
within the company, architecture definition that provides an initial
global architecture of the IS under development, together with a
development plan that outlines the most important steps in
the development process. At the basehese last two documents
there is the prioritized requirements list. This
list states all the requirements for the system, organized according to the
MoSCoW principle. And last, the Risk Log is updated with the facts that
have been identified during this phase of DSDM.

123
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.3.2.3 Stage 3

Functional Model Iteration

The requirements that have been identified in the previous
stages are converted to a functional model. This model
consists of both a functioning prototype and models. Prototyping is
one of the key project techniques within this stage that helps to realize
good user involvement throughout the project. The developed prototype
is reviewed by different user groups. In order to assure
quality, testing is implemented throughout every iteration
of DSDM. An important part of testing is realized in the
Functional Model Iteration. The Functional Model can be subdivided
into four sub-stages:

• Identify Functional Prototype: Determine the

functionalities to be implemented in the prototype that results
from this iteration.
• Agree Schedule: Agree on how and when to
develop these functionalities.
• Create Functional Prototype: Develop the prototype.
Investigate, refine, and consolidate it with the combined
Functional prototype of previous iterations.
• Review Prototype: Check the correctness of the developed
prototype.

This can be done via testing by end-user, then use the test
records and user’s feedbacks to generate the functional prototyping
review document.

The deliverables for this stage are a Functional Model and a Functional
Prototype that together represent the functionalities that
could be realized in this iteration, ready for testing by users.
Next to this, the Requirements List is updated, deleting the items
that have been realized and rethinking the prioritization of the
remaining requirements. The Risk Log is also updated by having
risk analysis of further development after reviewing the prototyping
document.

3.3.2.4 Stage 4

Design and Build Iteration

The main focus of this DSDM iteration is to integrate the
functional components from the previous phase into one system that
satisfies user needs. It also addresses the non-functional requirements
that have been set for the IS. Again testing is an important
ongoing activity in this stage. The Design and Build Iteration can

124
MBA 815 MODULE 3

be subdivided into four sub-stages:

• Identify Design Prototype: Identify functional and non-

functional requirements that need to be in the tested system.
• Agree Schedule: Agree on how and when to
realize these requirements.
• Create Design Prototype: Create a system that can safely be
handed to end-users for daily use. They investigate, refine, and
consolidate the prototype of current iteration within prototyping
process are also important in this sub-stage.
• Review Design Prototype: Check the correctness of the
designed system. Again testing and reviewing are the main
techniques used, since the test records and user’s feedbacks are
important to generate the user documentation.

The deliverables for this stage are a Design Prototype during the
phase that end users get to test and at the end of the Design and Build
Iteration the Tested System is handed over to the next phase. In this
stage, the system is mainly built where the design and functions are
consolidated and integrated in a prototype. Another deliverable for this
stage is a User Documentation.

3.3.2.5 Stage 5

Implementation
In the Implementation stage, the tested system including
user documentation is delivered to the users and training of future
users is realized. The system to be delivered has been reviewed to
include the requirements that have been set in the beginning stages
of the project. The Implementation stage can be subdivided into four
sub-stages:

• User Approval and Guidelines: End users approve the tested

system for implementation and guidelines with respect
to the implementation and use of the system are created.
• Train Users: Train future end user in the use of the system.
• Implement: Implement the tested system at the location of
the end users.
• Review Business: Review the impact of the implemented system
on the business, a central issue will be whether the system
meets the goals set at the beginning of the project.
Depending on this p roject goes to the next phase, the post-
project, or loops back to one of the preceding phases for further
development.

125
MBA 815 MANAGEMENT INFORMATION SYSTEM

The deliverables for this stage are a Delivered System on location, ready
for use by the end users, Trained Users and detailed
Project Document of the system.

3.3 Phase 3

Post-project
The post-project phase ensures the system operating effectively
and efficiently. This is realized by maintenance, enhancements
and fixes, according to DSDM principles. The
maintenance can be viewed as continuing development, based
on the iterative and incremental nature of DSDM. Instead of
finishing the project in one cycle usually the project can
return to the previous phases or stages so that the previous
step and the deliverable products can be refined.

3.4 Core Techniques of DSDM

Timeboxing
Timeboxing is one of the project techniques of DSDM. It is
used to support the main goals of DSDM to realize the development of
an IS on time, within budget, and with the desired quality. The main
idea behind timeboxing is to split up the project in portions, each with a
fixed budget and a delivery date. For each portion a
number of requirements are selected that are prioritized
according to the MoSCoW principle. Because time and budget
are fixed, the only remaining variables are the requirements. So if
a project is running out of time or money,
requirements with the lowest priority are omitted. This does not mean
that an unfinished product is delivered, because of the pareto, principle
that 80% of the project comes from 20% of the system requirements, so
as long as those most important 20% of requirements are implemented
into the system, the system therefore meets the business needs, and
that no system is built perfectly in the first try.

MoSCoW
MoSCoW represents a way of prioritizing items. In the
context of DSDM the MoSCoW technique is used to prioritize
requirements. It is an acronym that stands for:

10. MUST have this requirement to meet the business needs.

11. SHOULD have this requirement if at all possible, but the

project success does not rely on this.

12. COULD have this requirement if it does not affect the

126
MBA 815 MODULE 3

fitness of business needs of the project.

13. WOULD have this requirement at later date if there is some time left
(or in the future development of the system). Prototyping

This technique refers to the creation of prototypes of the system under

development at an early stage of the project. It
enables the discovery of shortcomings in the system and allows
future users to ‘test-drive’ the system. This way, good user involvement
is realized, one of the key success factors of DSDM, or any System
Development project for that matter.

Testing
A third important aspect of the goal of DSDM is the creation of an IS
with good quality. In order to realize a solution of good quality, DSDM
advocates testing throughout each iteration. Since DSDM is a tool, and
technique independent method, the project team is free to choose its own
test management method, for example TMap.

Workshop
One of DSDM’s project techniques that aims at bringing the
different stakeholders of the project together to discuss
requirements, functionalities and mutual understanding. In a
workshop the stakeholders come together and discuss the project.

Modelling
This technique is essential and purposely used to
visualise the diagrammatic representation of a specific
aspect of the system bus iness area that is being
developed. Modelling gives a better understanding for DSDM
project team over a business domain.

Configuration Management
A good implementation of this configuration management technique is
important for the dynamic nature of DSDM. Since there is more
than one thing being handled at once during the development process of
the system, and the products are being delivered frequently at a
very fast rate, the products therefore need to be controlled strictly as
they achieve (partial) completion.

3.5 Roles of DSDM

There are some roles introduced within DSDM

environment. It is important that the project members need
to be appointed to different roles before they start to run
the project. Each role has its responsibility. These roles are:

127
MBA 815 MANAGEMENT INFORMATION SYSTEM

• Executive Sponsor: So called the “Project Champion”.

An important role from the user organization who has
the ability and responsibility to commit appropriate funds
and resources. This role has an ultimate power to make decisions.
• Visionary: The one who has the responsibility to
initialize the project by ensuring that essential
requirements are found early on. Visionary has the most
accurate perception of the business objectives
of the system and the project. Another task is to supervise and
keep the development process in the right track.
• Ambassador User: Brings the knowledge of user
community into the project, ensures that the developers
receive enough amount of user’s feedbacks during the
development process.
• Advisor User: Can be any user that represents an
important viewpoint and brings the daily knowledge of the
project.
• Project Manager: Can be anyone from user community or IT
staff who manages the project in general.
• Technical Coordinator: Responsible in designing the
system architecture and control the technical quality in the
project.
• Team Leader: Leads his team and ensures that the
team works effectively as a whole.
• Developer: Interpret the system requirements and model; it
includes developing the deliverable codes and build the
prototypes.
• Tester: Checks the correctness in a technical extent by
performing some testing. Tester will have to give
some comments and documentation.
• Scribe: Responsible to gather and record the
requirements, agreements, and decisions made in every
workshop.
• Facilitator: Responsible in managing the workshop’s progress,
acts as a motor for preparation and communication.
• Specialist Roles: Business Architect, Quality Manager,
System Integrator, etc.

3.6 Critical Success Factors of DSDM

Within DSDM a number of factors are identified as

being of mportance to ensure successful projects:

• Factor 1: First there is the acceptance of DSDM

by senior management and other employees. This
ensures that the different actors of the project are motivated

128
MBA 815 MODULE 3

from the start and remain involved throughout the project.

• Factor 2: The second factor follows directly from this and that is
the commitment of management to ensure end-user
involvement. The prototyping approach requires a strong and
dedicated involvement by end user to test and judge the functional
prototypes.
• Factor 3: Then there is the project team.
This team has to be composed of skillful members that
form a stable union. An important issue is the empowerment of
the project team. This means that the team (or one or more of
his members) has to posses the power and possibility to make
important decisions regarding the project without having to write
formal proposals to higher management, which can be very time-
consuming. In order for the project team to be able to run a
successful project, they also need the right
technology con duct the project. This means a development
environment, project management tools, etc.
• Factor 4: Finally, DSDM also states that a supportive
relationship between customer and vendor is required. This goes
for both projects that are realized internally within
companies or by outside contractors. An aid in
ensuring a supporting relationship could be ISPL.

3.7 Comparison to other IS Development Methods

Over the years a great number of Information System

Development methods have been developed and applied,
divided in Structured Methods, RAD methods and Object-
Oriented Methods. Many of these methods show similarities to each
other and also to DSDM. For example eXtreme Programming, [XP]
also has an iterative approach to IS development with
extensive user involvement.

The Rational Unified Process is a method that probably has the most in
common with DSDM in that it is also a dynamic form of Information
System Development. Again, the iterative approach is
used in development method.

Like XP and RUP there are many other development methods that show
similarities to DSDM, but DSDM does distinguish itself
from these methods in a number of ways. First, there is the fact that it
provides a tool and technique independent framework. This allows
users to fill in the specific steps of the process with their own
techniques and software aids of choice. Another unique feature is the fact
that the variables in the development are not time/resources, but the
requirements. This approach ensures the main goals of DSDM,

129
MBA 815 MANAGEMENT INFORMATION SYSTEM

namely to stay within the deadline and the budget. And last
there is the strong focus on communication between and
the involvement of all the stakeholders in the system.
Although this is addressed in other methods, DSDM strongly believes in
commitment to the project to ensure a successful outcome.

This last paragraph is largely incorrect, most of RUP can be

applied without rational tools and XP does not require any particular
tools. XP shares many similarities with DSDM, notably the
'embrace change' philosophy which means requirements can be
changed as well as time and resources.

4.0 CONCLUSION

As an extension of rapid application development, DSDM focuses on

Information Systems, projects that are characterized by tight schedules
and budgets. DSDM addresses the common reasons for
information systems project failure including exceeding budgets,
missing deadlines, and lack of user involvement and top management
commitment.

5.0 SUMMARY

• Dynamic Systems Development Method (DSDM) is a

framework based originally around Rapid Application
Development (RAD) supported by its continuous user
involvement in an iterative development and incremental
approach which is responsive to changing requirements,
in order to develop a system that meets the business needs on
time and on budget.
• DSDM focuses on frequent delivery of products, with assumption
that to deliver something "good enough" earlier, is always better
than to deliver everything "perfectly" in the end.
• In order for DSDM to be a success, a number of prerequisites
need to be realized. First, there needs to be interactivity between
the project team, future end users and higher management.
• The DSDM framework consists of three sequential phases,
namely, the pre-project, project life-cycle and post-project phases.
• The business study extends the feasibility study. After the project
has been deemed feasible for the use of DSDM, this stage
examines the influenced business processes, user groups
involved and their respective needs and wishes.
• The post-project phase ensures the system operating effectively
and efficiently. This is realized by maintenance, enhancements
and fixes according, to DSDM principles.
• Prototyping technique refers to the creation of prototypes

130
MBA 815 MODULE 3

of the system under development at an early stage of the project.

It enables the early discovery of shortcomings in the system, and
allows future users to ‘test-drive’ the system.
• Within DSDM a number of factors are identified as being of
great importance to ensure successful projects.
• Like XP and RUP, there are many other development methods
that show similarities to DSDM, but DSDM does distinguish
itself from these methods in a number of ways.

The next study unit is on project management.

6.0 TUTOR-MARKED ASSIGNMENT

Identify and discuss 5 personnel and their roles in a dynamic

system development method (DSDM).

7.0 REFERENCES/FURTHER READING

Coleman and Verbruggen (1998). A Quality Software

Process for Rapid Application Development, Software
Quality Journal 7, p. 107-1222.

Beynon-Davies and Williams (2003). The Diffusion of

Information Systems Development Methods, Journal of
Strategic Information Systems 12 p. 29-46.

Brinkkemper, Saeki and Harmsen (1998). Assembly Techniques

for Method Engineering, Advanced Information Systems
Engineering, Proceedings of CaiSE'98, Springer Verlag.

Abrahamsson, Salo, Ronkainen, Warsta (2002). Agile Software

Development Methods: Review and Analysis, VTT
Publications 478, p. 61-68.

Tuffs, Stapleton, West, Eason (1999). Inter-operability of DSDM

with the Rational Unified Process, DSDM Consortium,
Issue 1, p. 1-29.

Rietmann (2001). DSDM in a bird’s eye view, DSDM Consortium, p.

3-8. ISDLC, Integrated Systems Development Life Cycle.

131
MBA 815 MANAGEMENT INFORMATION SYSTEM

UNIT 2 PROJECT MANAGEMENT

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Overview of Project Management
3.2 Policy Requirements
3.2.1 Accountability for Projects
3.2.2 Project Management Principles
3.2.3 Authorities and Resources
3.2.4 Project Scope
3.2.5 Management Framework
3.2.6 Project Risk, Complexity and Economy
3.2.7 Project Profile and Risk Assessment (PPRA)
3.2.8 Project Management Practices
3.3 Responsibilities
3.4 The Traditional Project Management Constraints
3.4.1 Time
3.4.2 Cost
3.4.3 Scope
3.5 Project Management Activities
3.6 Project Management Stages
3.6.1 Initiation
3.6.2 Planning and Design
3.6.3 Production or Execution
3.6.4 Closing and Maintenance
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION

As a discipline, Project Management developed from several

different fields of application, including construction,
mechanical engineering, military projects, etc. In the
United States, the forefather of management is Henry Gantt,
called the father of planning and control techniques, who is
famously known for his use of the "bar" chart as a project management
tool, for being an associate of Frederick Winslow Taylor’s theories
of scientific management, and for his study of the work and
management of Navy ship building. His work is the forerunner
to many modern project management tools, including the
work breakdown structure (WBS) and resource allocation.

132
MBA 815 MODULE 3

The 1950's mark the beginning of the modern project management era.
Again, in the United States, prior to the 1950's, projects were
managed on an ad hoc basis using mostly Gantt Charts, and informal
techniques and tools. At that time, two mathematical project
scheduling models were developed: (1) the "Program Evaluation and
Review Technique” or PERT, developed as part of the United
States Navy’s (in conjunction with the Lockheed Corporation Polaris
missile submarine program; and (2) the Critical Path Method (CPM)
developed in a joint venture by both DuPont Corporation and
Remington Rand Corporation for managing plant aintenance
projects. These mathematical techniques quickly spread into
many private enterprises.

In 1969, the Project Management Institute (PMI) was formed to

serve the interest of the project management industry. The premise of
PMI is that the tools and techniques of project management are
common even among the widespread application of projects,
from the software industry, to the construction industry. In
1981, the PMI Board of Directors authorized the development
of what has become The Guide to the Project Management Body of
Knowledge, containing the standards and guidelines of practice
that are widely used throughout the profession.

2.0 OBJECTIVES

The objectives of this unit of the course are for you to:

• have an understanding of what project management is and how it

has developed over the years
• identify the requirements for a successful project
management implementation
• answer the question of the foundational stages of any project cycle
• identify the constraints to a project management initiative.

3.0 MAIN CONTENT

3.1 Overview of Project Management

Project management is defined as the discipline of

organizing and managing resources in such a way that these
resources deliver all the work required to complete a project within
defined scope, time, and cost constraints. A project is a temporary and
one-time endeavor undertaken to create a unique product or service. This
property of being a temporary and a one-time undertaken, contrast with
processes, or operations, which are permanent or semi-permanent
ongoing functional work to create the same product or service over-

133
MBA 815 MANAGEMENT INFORMATION SYSTEM

and-over again. The management of these two systems is often very

different and requires varying technical skills and philosophy, hence
requiring the development of project management.

Project management is also a carefully planned and organized effort to

accomplish a specific (and usually) one-time effort, for
example, constructs a building or implements a new computer
system. Project management includes developing a project
plan, which includes defining project goals and objectives,
specifying tasks or how goals will be achieved, what resources
are need, and associating budgets imelines for completion. It
also includes implementing the project plan, along with careful
controls to stay on the "critical path", that ensure the
plan is being managed according to plan. Project
management usually follows major phases (with various titles for these
phases), including feasibility study, project planning,
implementation, evaluation and support/maintenance. (Program
planning is usually of a broader scope than project planning, but not
always.).

The first challenge of project management is ensuring that a project

is delivered within the defined constraints. The second, more
ambitious, challenge is the optimized allocation and integration of
the needed to meet those pre-defined objectives. The project, therefore, is
a carefully selected set of activities chosen to use resources, (time,
money, people, materials, energy, space, provisions,
communication, quality, risk, etc.) to meet the pre-defined objectives.
Almost any human activity that involves carrying out a non-
repetitive task can be a project. So we are all project managers! We
all practice project management (PM). But there is a
big difference between carrying out a very simple project involving
one or two people and one involving a complex mix of people,
organisations and tasks. This has been true for millennia, but large-
scale projects like the Pyramids, often used rather simple control and
resource techniques including brute force to 'motivate' the workforce!

The art of planning for the future has always been a human
trait. In essence a project can be captured on paper with a few simple
elements: a start date, an end date, the tasks that have to be carried
out and when they should be finished, and some
idea of the resources mpahinesetc) that will be needed during
the course of the project. When the plan starts to involve different
things happening at different times, some of which are dependent on
each other, plus resources required at different times and in
different quantities and perhaps working different rates,
the paper plan could start to cover a vast area and be

134
MBA 815 MODULE 3

unreadable.

You could begin the story of modern project management from this
time. But that would be unfair as project management is not only about
planning but also about human attributes like leadership and motivation.
Nevertheless, the idea that complex plans could be
analysed by a computer to allow someone to control a project is the
basis of much of the development in technology that now allow
projects of any size and complexity not only to be planned but also
modelled to answer 'what if?' questions. The original programs
and computers tended to produce answers long after an
event had taken place. Now, there are many project
planning and scheduling programs that can provide real time
information, as well as linking to risk analysis, time recording, costing,
estimating and other aspects of project control. But computer programs
are not project management: they are tools for project managers to use.
Project management is all that mix of components of control, leadership,
teamwork, resource management etc, which go into a successful project.

Project managers can be found in all industries. Their numbers

have grown rapidly as industry and commerce has realised, that much of
what it does is project work. And as project-based organisations have
started to emerge, project management is becoming
established as both a professional career path and a way
of controlling business. So opportunities in project
management now exist not only in being a project
manager, but also as part of the support team in a project
or programme office, or as a team leader for part of a project. There
are also qualifications that can be attained through the
professional associations.

One reason for the rapid growth is the need to understand how to look
after complex projects, often in high tech areas, which are
critical to business success but also have to use scarce
resources efficiently.

3.2 Policy Requirements

There are definitely some policy requirements expected

of project management principles and concepts and some of them
include:

3.2.1 Accountability for projects

Sponsoring departments must establish an accountability framework for

adequate definition and responsible implementation of

135
MBA 815 MANAGEMENT INFORMATION SYSTEM

projects. The central focus of this framework is a

manager within the sponsoring department, at an
appropriate level, who is appointed as the Project
Leader. The project leader, for each project assigned to him or
her is accountable through the normal chain of command
to the deputy minister for:

• all external aspects including: the continuing

interpretation of operational needs and wider
government objectives, and the validation of planned
project end-product in that context; interfaces with the
senior management of the sponsoring department
and participating departments; and serving as the
spokesperson for the project; and
• all internal aspects including: general supervision
of the project management framework to ensure that project
managers will meet all objectives approved for the
project; preparing project approval documents; vetting
proposals to amend objectives due to changed external
or internal factors; and acting as the authority
for s ubmission of such changes as well as for
progress reporting poroject approval authorities.

3.2.2 Project Management Principles

Departments are expected to establish and approve sound

internal policies, guidelines and practices to be followed
by project project managers and other staff responsible for
identifying, planning, approving/budgeting, defining, and
implementing projects; and for participating in projects sponsored
by other departments. Project leaders are to preserve the integrity of the
accountability framework by ensuring that the requirement to follow
standard project management principles, such as those set out in
Appendix B together with those found in the Project Management
Institute's project management book of knowledge are included in all
pertinent project agreements.

3.2.3 Authorities and Resources

From project inception, sponsoring departments must

delegate authorities and allocate adequate resources
appropriate to the scope, complexity and risk of the project, enabling
the project leader to:

• represent the sponsoring department on matters

pertaining to the project;

136
MBA 815 MODULE 3

• fully define objectives for each phase of the project; and

• be accountable for the achievement of each approved objective.

3.2.4 Project scope

Project leaders are accountable for the full definition of the scope for all
projects including the wider interests of the government. This definition
of scope is to be accomplished with early
consultation with de partments or central agencies affected by
the project. In addition to other elements, the project scope must
describe all the project objectives as identified in other chapters of this
volume. Project scope may also be affected by procurement review or
other environmental considerations.

3.2.5 Management Framework

Project leaders are accountable for the establishment of an

adequate project management framework, for detailed project
definition and to complete project implementation. For certain
projects, the regime may be relatively simple with an
internal, essentially self-contained management office headed
by a project manager responsible for all details of the
project. However, other projects may require a quite
complex management framework involving several significant parallel
activities and external agencies, each with its own manager or
project officer. In all cases, the project leader must maintain the integrity
of his or her accountability through written agreements
with any previous project leaders, project managers, and any
external agencies that carry out activities essential to the
accomplishment of the project. These agreements are to
define details of the task to be accomplished, as well as financial and
progress reporting arrangements.

3.2.6 Project Risk, Complexity and Economy

Project leaders must ensure that project managers perform

adequate project planning that addresses the size, scope,
complexity, risk, visibility and administrative needs of specific
projects. Project leaders must ensure that the proposed
project management framework and allocation of project
management resources are based and optimized on the complexity
and the assessed risk for the individual phases of a
project. The selected project management framework is to describe risk,
and complexity will be managed and reduced in each
phase and throughout the life of the project.

137
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.2.7 Project Profile and Risk Assessment (PPRA)

Early in the life of a project, the project leader is to prepare a

Project Profile and Risk Assessment (PPRA), in consultation
with the contracting authority and, when appropriate, with
participating departments and common service organizations, as part of
the process of developing the management framework within, for the
Treasury Board approval submissions. Guidance for the preparation
and documentation of the PPRA is provided in Appendix C. When
appropriate, the project leader should use the PPRA document
for systematic dialogue with project participants and with
Treasury Board Secretariat, regarding the management framework and
reporting baseline for the project.

3.2.8 Project Management Practices

Guidance for project management practices and the preparation of risk

assessments, PPRAs, supporting documentation, and progress
and evaluation reports is to be.

3.3 Responsibilities

Project Leaders
Project Leaders must notify other federal government
departments or agencies who may be affected by a specific
project, inviting them to participate in an active or coordinative
role as appropriate. The project leader is also responsible for
ensuring that all relevant project submissions and approvals
have been obtained prior to initiating any part of the project. It
also includes the submission of updated project information to
appropriate authorities for significant changes beyond the
reporting baseline established in the original or amended approvals.

The project leader should consult as early as possible, with

Treasury Board Secretariat, particularly for larger
projects of higher risk complexity, proposing a suitable
management framework for staff concurrence. Project leaders
are to ensure that a specific project managed in accordance
with the approved management framework. updated project
documentation may also propose a change in
management framework should the risk assessment
inducted in accordance with the guidelines in Appendix C
demonstrate a decrease (or increase) in project risk.

138
MBA 815 MODULE 3

Project Managers
Project Managers are responsible for the day-to-day management of the
project as set out in the charter or agreement with the project leader.

Participating Departments
Participating departments are to determine the nature and degree of
the effect of the proposed project on their operations, asset base or
other interests. They then respond to the project leader defining the
nature and extent of proposed participation in the project. Joint
commitment to any project and specific activity to be
carriedout by a department that is deemed essential to the success
of the project, must be documented in an appropriate interdepartmental
agreement.

Participating departments are to select their project officers based upon

an established human resources management profile, project
management experience and abilities, and in consideration
of the significance, scope, complexity, risk, and visibility of the
project.

Contracting Authority
The Contracting Authority is responsible:
• for participating in the project as a participating department (as
per paragraph 3 above);
• to ensure the legal soundness of any contract, and to
maintain the government standards of prudence, probity and
equity, when dealing with the private sector;
• to support the project in accordance with any existing legislation
or general interdepartmental arrangements;
• to provide any project-specific services (such as
procurement) as described in any agreement or MOU concluded
with the sponsoring department; and
• to make submissions to the Treasury Board for authority to enter
into contracts and to amend contracts as set out
in the Contracting volume of the Treasury Board Manual.

Monitoring
The Treasury Board Secretariat will monitor departmental
compliance with this policy through review of the
quality of the Project Management Framework and other relevant
sections of project approval submissions, and by reviewing
adherence to the content of Treasury Board decisions.

139
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.4 The Traditional Project Management Constraints

Most people still want their projects to be on time,

meet quality objectives, and not cost more than the budget.
These form the classic time, quality, cost triangle.

In fact if you have an unlimited budget and unlimited

time, project management becomes rather easy. For most people,
however, time and money are critical, and that is what
makes project management so important today. Like any
human undertaking, projects need to be performed and
delivered under certain constraints. Traditionally, these
constraints have been listed as: scope, time, and cost.
This is also referred to as the Project Management
Triangle where each side represents a constraint. One
side of the triangle cannot be changed without impacting
the others. A further refinement of the constraints separates
product 'quality' or 'performance' from scope, and turns quality into a
fourth constraint.

The time constraint refers to the amount of time available to complete a

project. The cost constraint refers to the budgeted amount available for
the project. The scope constraint refers to what must be done to produce
the project's end result. These three constraints are often
constraints: increased scope typically means increased time
and increased cost, a tight time constraint could mean increased
costs and reduced scope, and a tight budget could
mean increased time educed scope.

The discipline of project management is about providing the tools

and techniques that enable the project team (not just the project manager)
to organize their work to meet these constraints.

3.4.1 Time

This often broken down for analytical purposes into the time required to
complete the components of the project, which is then further
broken down into the time required to complete each task
contributing to the completion of each component. When
performing tasks using project management, it is important to cut
the work into smaller pieces so that it is easy to follow.

3.4.2 Cost

Cost to develop a project depends on several variables

including (chiefly): labor rates, material rates, risk management, plant

140
MBA 815 MODULE 3

(buildings, machines, etc.), equipment, and profit. When hiring an

consultant for a project, cost will typically be determined
by consultant's or firm’s per diem rate multiplied by an estimated
quantity for completion.

3.4.3 Scope

Requirements specified for the end result: The overall definition of what
the project is supposed to accomplish, and a specific description of what
the end result should be or accomplish. A major component of scope is
the quality of the final product. The amount of time put into individual
tasks determines the overall quality of the project. Some tasks
require a given amount of time to complete adequately, but given more
time could be completed exceptionally. Over the
course of a project, quality can have a significant impact on time
and cost (or vice versa).

3.5 Project Management Activities

Project Management is composed of several different types of activities

such as:

• Planning the work or objectives

• Analysis & Design of objectives
• Assessing and controlling risk (or Risk Management)
• Estimating resources
• Allocation of resources
• Organizing the work
• Acquiring human and material resources
• Assigning tasks
• Directing activities
• Controlling project execution
• Tracking and Reporting progress
• Analyzing the results based on the facts achieved
• Defining the products of the project
• Forecasting future trends in the project
• Quality Management
• Issues Management.

3.6 Project Development Stages

Regardless of the methodology used, the project development

process will have the same major stages: initiation, development,
production or execution, and closing/maintenance.

141
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.6.1 Initiation

The initiation stage determines the nature and scope of

the development. If this stage is not performed well, it is unlikely that
the project will be successful in meeting the business’s
needs. The key project controls needed here is an
understanding of the business environment, and making
sure that all necessary controls are incorporated into the
project. Any deficiencies should be reported and a recommendation
should be made to fix them.

The initiation stage should include a cohesive plan that encompasses the
following areas:

• Study analyzing the business needs in measurable goals.

• Review of the current operations.
• Conceptual design of the operation of the final product.
• Equipment requirement.
• Financial analysis of the costs and benefits including a budget.
• Select stake holders, including users, and support personnel for
the project.
• Project charter including costs, tasks, deliverables, and schedule.

3.6.2 Planning and design

After the initiation stage, the system is designed. Occasionally, a small

prototype of the final product is built and tested. Testing is
generally performed by a combination of testers and end users, and can
occur after the prototype is built or concurrently. Controls should be
in place s that ensure that the final product will meet the
specifications of the project charter. The results of the design stage
should include a product design that:

• Satisfies the project sponsor, end user, and business requirements.

• Functions as it was intended.
• Can be produced within quality standards.
• Can be produced within time and budget constraints.

Production or Execution
The execution stage includes the actual implementation of the design or
plan. In software systems, this includes conversion (transfer of data from
an old system to a new system), documentation, and training. From an
auditor's perspective, training is also important because it
helps users use the software correctly. The bulk of the
project's work and largest capital expenditure is realized in this
stage.

142
MBA 815 MODULE 3

Closing and Maintenance

Closing includes the formal acceptance of the project and the
ending thereof. Administrative activities include the archiving of the
files and documenting lessons learned. Maintenance is an ongoing
process, and it includes:

• Continuing support of end users

• Correction of errors
• Updates of the software over time

In this stage, auditors should pay attention to how

effectively quickly user problems are resolved.

Over the course of any construction project, the work scope

changes.

Change is a normal and expected part of the

construction process.

Changes can be the result of necessary design modifications,

differing site conditions, material availability, contractor-requested
changes, value engineering and impacts from third parties, to
name a few. Beyond executing the change in the field,
the change normally needs to be documented to show what
was actually constructed. Hence, the owner usually requires a final
record to show all changes or, more specifically,
any change that modifies the tangible portions of the finished work. The
record is made on the contract documents - usually, but not necessarily
limited to, the design drawings. The end product of this effort is what
the industry terms as-built drawings, or more simply,
“asbuilts.”The requirement for providing them is a norm in construction
contracts.

4.0 CONCLUSION

Project management actually manages the production of projects

with schedules and tasks associated with the project. It
often involves detailed expertise in many of the
following areas: planning, cost management, contract
negotiations/procurement, technical writing (proposals, etc.),
research, technical development, information/computer management,
business development, corporate/administrative management, time
management, and others. Adhering strictly to the project
phases, requirements and taking care of the constraints ensures a
successful implementation of project management. Indeed, a
properly managed project is a prided of an effective project

143
MBA 815 MANAGEMENT INFORMATION SYSTEM

management. We need to also remind ourselves there are

several definitions of project management, but basically have
commons traits.

5.0 SUMMARY

• As a discipline, Project Management developed from

several different fields of application, including
construction, mechanical engineering, military projects, etc
• The 1950's mark the beginning of the modern project
management era.
• Project management is defined as the discipline of
organizing and managing resources in such a way that these
resources deliver all the work required to complete a project
within defined scope, time, and cost constraints.
• The first challenge of project management is ensuring that a
project is delivered within the defined constraints.
• Project leaders are accountable for the establishment of an
adequate project management framework, for detailed project
definition and to complete project implementation.
• In fact if you have an unlimited budget and unlimited time,
project management becomes rather easy. For most people,
however, time and money are critical and that is what makes
project management so important today.
• When performing tasks using project management, it is important
to cut the work into smaller pieces so that it is easy to follow.
• Regardless of the methodology used, the project
development process will have the same major stages:
initiation, development, production or execution, and
closing/maintenance.

6.0 TUTOR-MARKED ASSIGNMENT

1. Discuss the traditional constraints to project management.

2. List 10 common tasks in project management.

7.0 REFERENCES/FURTHER READINGS

Berkun, Scott (2005). Art of Project Management. Cambridge:

MA: O'Reilly Media.

Brooks, Fred (1995). The Mythical Man-Month, 20th

Anniversary Edition. Addison Wesley.

Heerkens, Gary (2001). Project Management. (The Briefcase

Book Series). McGraw-Hill.

144
MBA 815 MODULE 3

HolgerNauheimer, Project Cycle Management (PCM): New

Project Management Tools or Recycled Approaches
from Yesterday? AT-Forum, No. 9, 1997).

Kerzner, Harold (2003). Project Management: A Systems Approach to

Planning, Scheduling, and Controlling, 8th Ed., Wiley.

Lewis, James (2002). Fundamentals of Project Management, 2nd ed.,

American Management Association. .

Meredith, Jack R. and Mantel, Samuel J. (2002). Project Management:

A Managerial Approach, 5th ed., Wiley.

Project Management Institute (2003). A Guide to the Project

Management Body of Knowledge 3rd ed., Project
Management Institute.

Stellman, Andrew and Greene, Jennifer (2005). Applied

Software Project Management Cambridge, MA: O'Reilly Media.

Thayer, Richard H. and Yourdon, Edward (2000). Software Engineering

Project Management, 2nd Ed., Wiley-IEEE Computer
Society Press.

Whitty, Stephen Jonathan (2005). A Memetic Paradigm

of Project Management International Journal of Project
Management, 23 (8) 575-583.

Pettee, Stephen R. (2005). As-builts - Problems & Proposed Solutions.

Construction Management Association of America.

Verzuh, Eric (2005). The Fast Forward MBA in Project

Management, 2nd, Wiley.

145
MBA 815 MANAGEMENT INFORMATION SYSTEM

UNIT 3 PROJECT PLANNING

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 The Project Specification
3.2 Providing Structure
3.3 Establishing Controls
3.4 The Artistry in Planning
3.4.1 Who Know Best
3.4.2 Dangers in Review
3.4.3 Testing and Quality
3.4.4 Fitness for Purpose
3.4.5 Fighting for Time
3.4.6 Planning for Error
3.4.7 Post-Mortem
3.4 Planning For the Future
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Readings

1.0 INTRODUCTION
The success of a project will depend critically upon the effort, care
and skill you apply in its initial planning.

MIS projects can be expensive in terms of both time and

money. An organizational MIS may take a decade or more to bring on-
line at a cost of tens or hundreds of millions of dollars. Careful planning
at the outset, as well as during the project, can help to avoid costly
mistakes. It also provides assurance that a MIS will accomplish its goals
on schedule and within budget.

There is a temptation, when a new technology becomes

available, to improvise a solution to its use, that is to get started
without considering where the project will lead. The greatest danger is
that decisions made in haste or on the spur of the moment will have to be
reversed later, or will prove too costly to implement, meaning an MIS
project may have to be abandoned. To avoid disappointing
experiences like these, MIS professionals have developed a well-
defined planning methodology often referred to as project
planning lifecycle. Lifecycle planning involves setting goals,
defining targets, establishing schedules, and estimating budgets for an
entire project.

146
MBA 815 MODULE 3

The original impetus for developing effective lifecycle

planning was cost containment. For many decades, the
rationale for implementing new information technologies was
that, in the long run, such projects would reduce the cost of business
operations.

It is generally recognized that, for the foreseeable

future, most information technologies projects will have to be justified
on the basis of a "do more, pay more" philosophy. This
means that effective lifecycle planning is all the more
important. In the past, projected existing costs could be used as
a baseline against which improvements could be measured. If the cost
curve for new information technologies is always above the baseline,
then greater care must be exerted in setting goals, establishing targets,
and estimating budgets. There is far too great
a danger that, in the absence of such checks and balances, a project may
grow out of control.

2.0 OBJECTIVES

This unit is designed for the students to:

• be able to explain what is project planning

• understand why it is necessary to write a project specification
• identify the components of a project planning based on structure
put in place
• be able to know how to establish control in project execution
• understand the intricacies and skills of project planning.

3.0 MAIN CONTENT

3.1 The Project Specification

A specification is the definition of your project: a

statement of the problem, not the solution. Normally, the
specification contains errors, ambiguities, misunderstandings and
enough rope to hang you and your entire team. Thus before
you embark upon the next six months of activity
working on the wrong project, you must assume that a numbly
was the chief author of the specification you received and
you must read, worry, revise and ensure that everyone concerned with
the project (from originator, through the workers, to the end-customer)
is working with the same understanding. The outcome of this
deliberation should be a written definition of what is required, by
when; and this must be agreed by all involved. There are no
short-cuts to this; if you fail to spend the time initially, it will cost

147
MBA 815 MANAGEMENT INFORMATION SYSTEM

you far more later on.

The agreement upon a written specification has several benefits:

• the clarity will reveal misunderstandings

• the completeness will remove contradictory assumptions
• the rigour of the analysis will expose technical and practical
details which numbties normally gloss over through ignorance or
fear
• the agreement forces all concerned to actually read and think
about the details

The work on the specification can be seen at the first stage of Quality
Assurance since you are looking for and countering problems in the
very foundation of the project - from this perspective the
creation of specification clearly merits a large investment of time.

From a purely defensive point of view, the agreed

specification also affords you protection against the numbties who
have second thoughts, or new ideas, half way through the
project. Once the project usnderway, changes cost time
(and money). The existence of a demonstrably-agreed
specification enables you to resist or to charge for
(possibly in terms of extra time) such changes. Further, people tend to
forget what they originally thought; you may need proof that you have
been working as instructed.

The places to look for errors in a specification are:

• the global context: numbties often focus too narrowly on the work
of one team and fail to consider how it fits into the larger picture.
Some of the work given to you may actually be undone or
duplicated by others. Some of the proposed work may be
incompatible with that of others; it might be just plain barmy in
the larger context.

• the interfaces: between your team and both its

customers and suppliers, there are interfaces. At
these points something gets transferred. Exactly what,
how and when should be discussed and agreed from
the very beginning. Never assume a common
understanding, because you will be wrong. All it
takes for habiual understandings to evaporate is
the arrival of one member, in either of the teams. Define
and agree your interfaces and maintain a friendly contact
throughout the project.

148
MBA 815 MODULE 3

• time-scales: numbties always underestimate the time

involved for work. If there are no time-scales in the
specification, you can assume that one will be imposed upon you
(which will be impossible). You must add realistic dates.
The detail should include a precise understanding of
the extent of any intermediate stages of the task,
particularly those which have to be delivered.
• external dependencies: your work may depend upon that of
others. Make this very clear so that these people too will receive
warning of your needs. Highlight the effect that problems with
these would have upon your project so that everyone
is quite clear about their importance. To be sure, contact
these people yourself and ask if they are able to fulfill the
assumptions in your specification.
• resources: the numbty tends to ignore resources. The
specification should identify the materials, equipment and
manpower which are needed for the project. The agreement
should include a commitment by your managers to allocate or to
fund them. You should check that the actual numbers are
practical and/or correct. If they are omitted, add them - there is
bound to be differences in their assumed values.

This seems to make the specification sound like a long

document. It should not be. Each of the above could
be a simple sub-heading followed by either bullet
points or a table -you are not writing brochure, you are
stating the definition of the project in clear, concise
and unambiguous glory.

Of course, the specification may change. If by

circumstances your knowledge changes then the
specification will be out of date. You should not regard it as
cast in stone but rather as a display board where
everyone involved can see the current, common understanding
of the project. If you change the content everyone must
know, but do not hesitate to change it as necessary.

3.2 Providing Structure

Having decided what the specification intends, your next problem is to

decide what you and your team actually need to do, and how to do it. As
a manager, you have to provide some form of framework both to plan
and to communicate what needs doing. Without a structure, the work is
a series of unrelated tasks which provides little sense of
achievement and no feeling of advancement. If the
team has no grasp of ndividual tasks fit together towards an

149
MBA 815 MANAGEMENT INFORMATION SYSTEM

understood goal, then the work will seem pointless and they will feel
only frustration.

To take the planning forward, therefore, you need to

turn the specification into a complete set of tasks with
a linking structure. Fortunately, these two requirements are met at
the same time since the derivation of such a structure is the simplest
method of arriving at a list of tasks.

Work Breakdown Structure

Once you have a clear understanding of the project, and have eliminated
the vagaries of the numbties, you then describe it as a set of
simpler separate activities. If any of these are still too complex for you
to easily organise, you break them down also into
another level of descriptions, and so on until you can manage
everything. Thus your one complex project is organised as a set
of simple tasks which together achieve the desired result.

The reasoning behind this is that the human brain (even yours) can only
take in and process so much information at one time. To get a real grasp
of the project, you have to think about it in pieces rather than trying
to process the complexity of its entire details all at once. Thus each level
of the project can be understood as the amalgamation
of a few described smaller units.

In planning any project, you follow the same simple steps: if an item is
too complicated to manage, it becomes a list of simpler items.
People call this producing a work breakdown structure to make it
sound more formal and impressive. Without following this formal
approach you are unlikely to remember all the niggling little details;
with this procedure, the details are simply displayed on the final lists.

One common fault is to produce too much detail at the initial planning
stage. You should be stop when you have a sufficient description of the
activity to provide a clear instruction for the person who will actually do
the work, and to have a reasonable estimate for the total
involved. You need the former to allocate (or delegate) the task;
you need the latter to finish the planning.

Task Allocation
The next stage is a little complicated. You now have to allocate the tasks
to different people in the team and, at the same time, order these tasks so
that they are performed in a sensible sequence.

150
MBA 815 MODULE 3

Task allocation is not simply a case of handing out the various tasks on
your final lists to the people you have available; it is far more
subtle (and powerful) than that. As a manager you have to look far
beyond the single project; indeed any individual project can be
seen as merely a single step in your team's development. The
allocation of tasks should thus be seen as a means of increasing the
skills and experience of your team - when the project is done, the team
should have gained.

In simple terms, consider what each member of your team is capable of

and allocate sufficient complexity of tasks to match that (and to slightly
stretch). The tasks you allocate are not the ones on your finals lists, they
are adapted to better suit the needs of your team's development;
tasks are moulded to fit people, which is far more effective than the other
way around. For example, if Arthur is to learn something new, the task
may be simplified with responsibility given to another to guide and check
the work; if Brenda is to develop, sufficient tasks are combined so that
her responsibility increases beyond what she has held before; if Colin
lacks confidence, the tasks are broken into smaller units
which can be completed (and commended) frequently.

Sometimes tasks can be grouped and allocated together. For

instance, some tasks which are seemingly independent may benefit
from being done together since they use common ideas,
information, and talents. One person doing them both removes the
start-up time for one of them; two people (one on each) will be able to
help each other.

The ordering of the tasks is really quite simple, although you may find
that sketching a sequence diagram helps you to think it through (and to
communicate the result). Pert charts are the accepted
outcome, but sketches will suffice. Getting the details exactly right,
however, can be a long and painful process, and often it can be futile.
The degree to which you can predict the future is limited, so too should
be the detail of your planning. You must have the broad
outlines by which to monitor progress, and sufficient detail to
assign each task when it needs to be started, but beyond that - stop
and do something useful instead.

Guesstimation
At the initial planning stage the main objective is to
get a realistic estimate of the time involved in the project. You must
establish this not only to assist higher management with their planning,
but also to protect your team from being expected to do
the impossible. The most important technique for achieving this
is known as: guesstimation.

151
MBA 815 MANAGEMENT INFORMATION SYSTEM

Guesstimating schedules is notoriously difficult but it is helped by two

approaches:

• make your guesstimates of the simple tasks at the bottom of the

work break down structure and look for the
longest path through the sequence diagram
• use the experience from previous projects to
improve your guesstimating skills

The corollary to this is that you should keep

records in an accelssible form of all projects as you do them. Part
of your final project review should be to update your personal data base
of how long various activities take. Managing this planning phase is vital
to your success as a manager.

Some people find guesstimating a difficult concept in that if you have no

experience of an activity, how can you make a worthwhile estimate? Let
us consider such a problem: how long would it take you to walk all the
way to the top of the Eiffel Tower or the Statue of Liberty? Presuming
you have never actually tried this (most people take the elevator part of
the way), you really have very little to go on. Indeed if you have actually
seen one (and only one) of these buildings, think about the other.
Your job depends upon this, so think carefully. One idea is to start with
the number of steps - guess that if you can. Notice, you do not have to
be right, merely reasonable. Next, consider the sort of
pace you maintain while climbing a flight of steps for a long time.
Now imagine yourself at the base of a flight of steps you do
know, and estimate a) how many steps there are, and b) how long it
takes you to climb them (at that steady pace). To complete, apply a little
mathematics.

Now examine how confident you are with this estimate. If you won a
free flight to Paris or New York and tried it, you would probably (need
your head examined) be mildly surprised if you climbed to the top
in less than half the estimated time and if it took you more than double
you would be mildly annoyed. If it took you less than a tenth the time, or
ten times as long, you would extremely be surprised/annoyed. In fact,
you do not currently believe that that would happen (no really, do you?).
The point is that from very little experience of the given problem,
you can actually come up with a working estimate - and one which is
far better than no estimate at all when it comes to
deriving a guesstimating does take a little practice, but it is a
very useful skill to develop.

There are two practical problems in guesstimation. First, you are simply
too optimistic. It is human nature at the beginning of a new project to

152
MBA 815 MODULE 3

ignore the difficulties and assume best case scenario - in producing your
estimates (and using those of others) you must inject a little realism. In
practice, you should also build-in a little slack to allow yourself
some tolerance against mistakes. This is known as defensive scheduling.
Also, if you eventually deliver ahead of the agreed
schedule, you oved.

Second, you will be under pressure from senior management to deliver

quickly, especially if the project is being sold competitively. Resist the
temptation to rely upon speed as the only selling point. You might, for
instance, suggest the criteria of: fewer errors, history of
adherence to initial schedules, previous customer satisfaction,
"this is how long ittakes, so how can you trust the other quotes".

3.3 Establishing Controls

When the planning phase is over (and agreed), the "doing" phase begins.
Once it is in motion, a project acquires a direction
and momentum which is totally independent of anything you
predicted. If you come to terms with that from the start, you
can then enjoy the roller-coaster which follows. To gain some
hope, however, you need to establish at the start (within the plan) the
means to monitor and to influence the project's progress.

There are two key elements to the control of a project

• milestones (clear, unambiguous targets of what, by when)

• established means of communication

For you, the milestones are a mechanism to monitor progress; for your
team, they are short-term goals which are far more tangible
than the foggy, distant completion of the entire project. The milestones
maintain the momentum and encourage effort; they allow the team to
judge their own progress and to celebrate achievement throughout the
project rather than just at its end.

The simplest way to construct milestones is to take

the timing information from the work breakdown structure and
sequence diagram. When you have guesstimated how long each sub-task
will take and have strung them together, you can identify by when each
of these tasks will actually be completed. This is simple and
effective; however, it lacks creativity.

A second method is to construct more significant milestones. These can

be found by identifying stages in the development of a project which are
recognisable as steps towards the final product. Sometimes

153
MBA 815 MANAGEMENT INFORMATION SYSTEM

these are simply the higher levels of your structure; for instance, the
completion of a market-evaluation phase. Sometimes, they cut across
many parallel activities; for instance, a prototype of the eventual product
or a mock-up of the new brochure format.

If you are running parallel activities, this type of

milestone is particularly useful since it provides a means
of pulling together the people on disparate activities, and so:

• they all have a shared goal (the common milestone)

• their responsibility to (and dependence upon) each
other is emphasised
• each can provide a new (but informed) viewpoint on the others'
work
• the problems to do with combining the different
activities are highlighted and discussed early in the
implementation phase
• you have something tangible which senior management
(and numbties) can recognise as progress
• you have something tangible which your team can
celebrate and which constitutes a short-term goal in a possibly
long-term project
• it provides an excellent opportunity for quality
checking and for review

Of course, there are milestones and there are mill-stones. You will have
to be sensitive to any belief that working for some specific milestone is
hindering rather than helping the work forward. If this arises then either
you have chosen the wrong milestone, or you have
failed to communicate how it fits into the broader structure.

Communication is your everything. To monitor progress, to

early warning of danger, to promote cooperation, to motivate
through team involvement, all of these rely upon
communication. Regular reports are invaluable - if you clearly define
what information is needed and if you teach your team how to
provide it in a rapidly accessible form. Often these reports
merely say "progressing according to schedule". These you
send back, for while the message is desired the
evidence is missing: you need to insist that your team monitor their own
progress with concrete, tangible, measurements and if this is done,
the figures should be included in the report. However, the real value of
this practice comes when progress is not according to schedule - then
your communication system is worth all the effort you
invested in planning.

154
MBA 815 MODULE 3

3.4 The Artistry in Planning

At the planning stage, you can deal with far more than the mere project at
hand. You can also shape the overall pattern of your team's working,
using the division and type of activities you assign.

3.4.1 Who Knows Best?

Ask your team. They too must be involved in the planning of projects,
especially in the lower levels of the work breakdown structure. Not only
will they provide information and ideas, but also they
will feel ownership in the final plan.

This does not mean that your projects should be planned by committee -
rather than you, as manager, plan the project based upon all the available
experience and creative ideas. As an initial approach, you could attempt
the first level(s) of the work breakdown structure to
help you communicate the project to the team and then ask for
comments. Then, using these, the final levels could be refined by the
people to whom the tasks will be allocated. However, since the
specification is so vital, all the team should vet the penultimate draft.

3.4.2 Dangers in Review

There are two pitfalls to avoid in project reviews:

• they can be too frequent

• they can be too drastic

The constant trickle of new information can lead to a vicious cycle of

planning and revising which shakes the team's
confidence in any particular version of the plan and
which destroys the very stability which the structure was
designed to provide. You must decide the balance. Pick a
point on the horizon and walk confidently towards it.
Decide objectively, and explain beforehand, when the review
phases will occur and make this a scheduled milestone in itself.

Even though the situation may have changed since the last review, it is
important to recognize the work which has been accomplished
during the interim. Firstly, you do not want to abandon it since the team
will be demotivated feeling that they have achieved nothing.
Secondly, this work itself is part of the new situation: it
has been done, it should provide a foundation for the next step
or at least the basis of a lesson well learnt. Always try to build upon
the existing achievements of your team.

155
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.4.3 Testing and Quality

No plan is complete without explicit provision for testing and

quality. As a wise manager, you will know that this
should be part of each individual phase of the project. This
means that no activity is completed until it has passed the (objectively)
defined criterion which establishes its quality, and these are best
defined (objectively) at the beginning as part of the planning.

When devising the schedule therefore you must include allocated

time for this part of each activity. Thus your question is not only: "how
long will it take", but also: "how long will the testing take". By asking
both questions together you raise the issue of "how do we
know we have done it right" at the very beginning and so the testing is
more likely to be done in parallel with the implementation.
You establish this philosophy for your team by including testing
as a justified (required) cost.

3.4.4 Fitness for Purpose

Another reason for stating the testing criteria at the beginning is that you
can avoid futile quests for perfection. If you have motivated your team
well, they will each take pride in their work and want to do the best job
possible. Often this means polishing their work until it is shines; often
this wastes time. If it is clear at the onset exactly what is needed, then
they are more likely to stop when that has been achieved. You need to
avoid generalities and to stipulate boundaries; not easy, but essential.

The same is also true when choosing the tools or building-blocks of your
project. While it might be nice to have use of the most modern versions,
or to develop an exact match to your needs; often there is an old/existing
version which will serve almost as well (sufficient for the purpose), and
The difference is not worth the time you would need to
obtaining or developing the new one. Use what is available
whenever possible unless the difference in the new version
is worth the money and the initial, teething pains.

A related idea is that you should discourage too much effort on aspects
of the project which are idiosyncratic to that one job. In the specification
phase, you might try to eliminate these through negotiation
with the customer; in the implementation phase you might leave these
parts until last. The reason for this advice is that a general piece of
work can be tailored to many specific instances; thus, if
the work is in a orm, you will be able to rapidly re-use it for other
projects. On the other hand, if you produce something which is cut to fit
exactly one specific case, you may have to repeat the work

156
MBA 815 MODULE 3

entirely even though the next project is fairly similar. At the

planning phase, a manager should bare in mind the future and the
long-term development of the team as well as the requirements of the
current project.

3.4.5 Fighting for Time

As a manager, you have to regulate the pressure and work load which is
imposed upon your team; you must protect them from the unreasonable
demands of the rest of the company. Once you have arrived at what you
consider to be a realistic schedule, fight for it. Never let
the world deflect you from what you know to be practical. If they
impose a deadline upon you which is impossible, clearly state this and
give your reasons. You will need to give some room for
compromise, however, since a flat NO will be seen as obstructive.
Since you want to help the company, you should look for alternative
positions.

You could offer a prototype service or product at an earlier date.

This might, in some cases, be sufficient for the customer to
start the next stage of his/her own project on the
understanding that your project would be completed at a
later date and the final version would then replace the
prototype.

The complexity of the product, or the total number of units, might

be reduced. This might, in some cases, be sufficient for
the customer's immediate needs. Future enhancements or more units
would then be the subject of a subsequent negotiation which, you feel,
would be likely to succeed since you will have already demonstrated
your ability to deliver on time.

You can show on an alternative schedule that the

project could be delivered by the deadline if certain (specified)
resources are given to you or if other projects are rescheduled. Thus, you
provide a clear picture of the situation and a possible solution; it
is up to your manager then to decide how he/she proceeds.

3.4.6 Planning for Error

The most common error in planning is to assume that there will be no

errors in the implementation: in effect, the schedule is derived
on the basis of "if nothing goes wrong, this will take
...". Of course, recognising that errors will occur is the
reason for implementing a monitoring strategy on the
project. Thus when the inevitable does happen, you can react

157
MBA 815 MANAGEMENT INFORMATION SYSTEM

and adapt the plan to compensate. However, by carefully considering

errors in advance you can make changes to the
original plan to enhance its tolerance. Quite simply,
your planning should include time where you stand back
from the design and ask: "what can go wrong?"; indeed, this is an
excellent way of asking your team for their analysis of your plan.

You can try to predict where the errors will occur. By

examining the activities' list you can usually pinpoint some activities
which are risky (for instance, those involving new equipment) and those
which are quite secure (for instance, those your team has done
often before). The risky areas might then be given a less stringent time-
scale - actually planning-in time for the mistakes. Another
possibility is to apply a different strategy, or more resources,
to such activities to minimise the disruption. For instance, you
could include training or consultancy for new
equipment, or you might parallel the work with the foundation of a fall-
back position.

3.4.7 Post-Mortem

At the end of any project, you should allocate time to

reviewing the lessons and information on both the work itself and the
management of that work: an open meeting, with open discussion, with
the whole team and all customers and suppliers. If you think that this
might be thought a waste of time by your own manager, think of the
effect it will have on future communications with your customers and
suppliers.

3.5 Planning for the Future

With all these considerations in merely the "planning" stage of a project,

it is perhaps surprising that projects get done at all. In fact projects
do get done, but seldom in the predicted manner and often as much by
brute force as by carefree delivery, staff are demotivated by constant
pressure for impossible goals, corners get cut which harm your
reputation, and each project has to overcome the same problems as the
last.

With planning, projects can run on time and interact

effectively with both customers and suppliers. Everyone
involved understands what is wanted and emerging problems are
seen (and dealt with) long before they cause damage. If you want
your projects to run this way - then you must invest time in planning.

158
MBA 815 MODULE 3

4.0 CONCLUSION

It is commonly said that if you fail to plan you have planned to fail. This
goes a long way to portray the significance of planning of any project. A
poorly planned project will be poorly executed and
poorly in otutcome. Planning project is a skill that
needs to be learned, unfortunately most people do not want to
learn this all-important act. In fact there is reported history of poor
planning of projects globally.

5.0 SUMMARY

• The success of a project will depend critically upon the effort,

care and skill you apply in its initial planning.
• Planning involves setting goals, defining targets,
establishing schedules, and estimating budgets for an entire
project.
• A specification is the definition of your project: a statement
of the problem, not the solution.
• Having decided what the specification intends, your next problem
is to decide what you and your team actually need to do, and how
to do it.
• Once you have a clear understanding of the
project, and have eliminated the vagaries of the numbties,
you then describe it as a set of simpler separate activities.
• When the planning phase is over (and agreed), the
"doing" phase begins. Once it is in motion, a
project acquires a direction and momentum which is
totally independent of anything you predicted.
• At the planning stage, you can deal with far more
than the mere project at hand. You can also shape the
overall pattern of your team's working using the division and
type of activities you assign.
• Even though the situation may have changed since the last review,
it is important to recognize the work which has been
accomplished during the interim.
• As a manager, you have to regulate the pressure
and work load which is imposed upon your team; you
must protect them from the
unreasonable demands of the rest of the company.
• The most common error in planning is to assume that there will
be no errors in the implementation: in effect, the schedule is
derived on the basis of "if nothing goes wrong, this will take ...".
• At the end of any project, you should allocate time to reviewing
the lessons and information on both the work itself and the
management of that work

159
MBA 815 MANAGEMENT INFORMATION SYSTEM

In the next study unit, you will be exposed to risk

assessment and management

6.0 TUTOR-MARKED ASSIGNMENT

Explain the term Guesstimation and discuss its application in

project planning

7.0 REFERENCES/FURTHER READING

Norton, P (1995). Introduction to Computers. Macmillan/McGraw-Hill.

Wendy Robson (1997). Strategic Management & Information

Systems, FT Prentice Hall, Pearsons Educational Ltd.

160
MBA 815 MODULE 3

UNIT 4 RISK ASSESSMENTS AND MANAGEMENT

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Definition
3.2 Risk Management Process
3.2.1 Identification
3.2.1.1 Objective-Based Risk Identification
3.2.1.2 Scenario-Based Risk Identification
3.2.1.3 Taxonomy-Based Risk Identification
3.2.1.4 Common-Risk Checking
3.2.2 Assessment
3.2.2 Potential Risk Treatments
3.2.3.1 Risk Avoidance
3.2.3.2 Risk Reduction
3.2.3.3 Risk Retention
3.2.3.4 Risk Transfer
3.2.4 Create the Plan
3.2.5 Implementation
3.2.6 Review and Evaluation of the Plan
3.3 Risk Assessment and Cost Estimates
3.3.1 Project Risk Assessment
3.3.2 Levels of Risk
3.3.3 Assessment of Risk
3.3.4 Assessment of High Risk
3.3.5 Assessment of Medium Risk
3.3.6 Assessment of Low Risk
3.3.7 Management of Project Risk
3.4 Limitations
3.5 Areas of Risk Management
3.6 Risk Management Activities
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Reading

1.0 INTRODUCTION

Risk management is basically a process of assessing

risk and development of strategies to curb such identified risk in
management.
This unit examines processes, cost estimates areas and activates of risk
management. Its limitations are also treated.

161
MBA 815 MANAGEMENT INFORMATION SYSTEM

2.0 OBJECTIVES

This unit of the course was designed for you to:

• understand risk assessment and management in

context of management information system as a project
• learn the processes to assessing and managing information
system projects risks
• answer the question of how to assess project risk
• identify the levels of risk
• understand the limitations that follows the process
of risk identification in information system management
• identify the activities that constitutes risk assessment
and management.

3.0 MAIN CONTENT

3.1 Definition

Generally, Risk Management is the process of measuring, or assessing

risk and then developing strategies to manage the risk. In general,
the strategies employed include transferring the risk to
another party, avoiding the risk, reducing the negative affect of the
risk, and accepting some or all of the consequences of a
particular risk. Traditional risk management, which is
discussed here, focus on risks stemming from physical or legal
causes (e.g. natural disasters or fires, accidents, death,
and lawsuits). Financial risk management, on the other hand, focuses on
risks that can be managed using traded financial instruments. Regardless
of the type of risk management, all large corporations
have risk management teams and small groups and corporations
practice informal, if not formal, risk management.

In ideal risk management, a prioritization process is followed

whereby the risks with the greatest loss and the greatest probability
of occurring are handled first, and risks with lower
probability of occurrence and lower loss are handled later. In
practice the process can be very difficult, and balancing between risks
with a high probability of occurrence but lower loss vs. a risk with
high loss but lower probability of occurrence can often be mishandled.

Risk management also faces a difficulty in allocating resources properly.

This is the idea of opportunity cost. Resources spent
on risk management could be instead spent on more profitable
activities. Again, ideal risk management spends the least
amount of resources in the process while reducing the negative

162
MBA 815 MODULE 3

effects of risks as much as possible.

3.2 Risk Management Process

3.2.1 Identification

A first step in the process of managing risk is to identify potential risks.

Risks are about events that, when triggered, will cause problems. Hence,
risk identification can start with the source of problems,
or with problem itself.

• Source Analysis: Risk sources may be internal or

external to the system that is the target of risk
management. Examples of sources are: stakeholders of
a project, employees of a company or the weather over an
airport.
• Problem Analysis: Risks are related to fear. For example: the fear
of losing money, the fear of abuse of privacy information or the
fear of accidents and casualties. The fear may exist with
various entities, most important with shareholder, customers
and legislative bodies such as the government.

When either source or problem is known, the events that a source may
trigger or the events that can lead to a problem can be investigated. For
example: stakeholders withdrawing during a project may
endanger funding of the project; privacy information may be stolen by
employees even within a closed network; lightning striking a B747
during takeoff may make all people onboard immediate casualties.

The chosen method of identifying risks may depend on culture, industry

practice and compliance. The identification methods are
formed by templates or the development of templates for
identifying source, problem or event. Common risk identification
methods are:

3.2.1.1 Objectives-Based Risk Identification

Organizations and project teams have objectives. Any event

that may endanger achieving an objective partly or
completely is identified as risk.

3.2.1.2 Scenario-Based Risk Identification

In scenario analysis different scenarios are created. The scenarios

may be the alternative ways to achieve an objective, or an
analysis of the interaction of forces in, for example, a market or battle.

163
MBA 815 MANAGEMENT INFORMATION SYSTEM

Any event that triggers an undesired scenario alternative is identified as

risk.

3.2.1.3 Taxonomy-Based Risk Identification

The taxonomy in taxonomy-based risk identification is a breakdown of

possible risk sources. Based on the taxonomy and knowledge
of best practices, a questionnaire is compiled. The answers
to the questions reveal risks.

3.2.1.4 Common-Risk Checking

In several industries lists with known risks are available. Each risk in the
list can be checked for application to a particular situation. An example
of known risks in the software industry is the Common
Vulnerability and Exposures list found at http://cve.mitre.org.

3.2.2 Assessment

Once risks have been identified, they must then be assessed as to

their potential severity of loss and to the probability of
occurrence. These quantities can be either simple to measure, in the
case of the value of a lost building, or impossible to
know for sure in the case of p robability of an unlikely
event occurring. Therefore, in the assessment
process it is critical to make the best educated guesses possible in order
to properly prioritize the implementation of the risk management plan.

3.2.3 Potential Risk Treatments

Once risks have been identified and assessed, all techniques to manage
the risk fall into one or more of these four major categories:
(Dorfman, 1997)

• Transfer
• Avoidance
• Reduction (aka Mitigation)
• Acceptance (aka Retention)

Ideal use of these strategies may not be possible. Some of them

may involve trade offs that are not acceptable to the organization or
person making the risk management decisions.

164
MBA 815 MODULE 3

3.2.3.1 Risk Avoidance

This includes not performing an activity that could

carry risk. An example would be not buying a property or business
in order to not take on the liability that comes with it. Another would be
not flying in order to not take the risk that the airplane was to be
hijacked. Avoidance may seem the answer to all risks, but avoiding risks
also means losing out on the potential gain that accepting (retaining) the
risk may have allowed.

Not entering a business to avoid the risk of loss

also avoidsp ossibility of earning the profits.

3.2.3.2 Risk Reduction

This involves methods that reduce the severity of the loss.

Examples include sprinklers designed to put out a fire to reduce the risk
of loss by fire. This method may cause a greater loss
by water damage therefore may not be suitable. Halon
fire suppression systems mtigate that risk, but the cost may be
prohibitive as a strategy.

Modern software development methodologies reduce risk by developing

and delivering software incrementally. Early methodologies
suffered from the fact that they only delivered software
in the final phase development; any problems encountered in
earlier phases meant costly rework and often jeopardized the
whole project. By developing increments, software
projects can limit effort wasted to a single increment. A
current trend in software development, spearheaded by the
Extreme Programming community, is to reduce the size of increments to
the smallest size possible, sometimes as little as one week is allocated to
an increment.

3.2.3.3 Risk Retention

This involves accepting the loss when it occurs. True self insurance falls
in this category. Risk retention is a viable strategy for small risks where
the cost of insuring against the risk would be greater over time than the
total losses sustained. All risks that are not avoided or transferred
are retained by default. This includes risks that are so large or
catastrophic that they either cannot be insured against or the
premiums would be infeasible. War is an example, since most
property and risks are not insured against war, so the loss
attributed by war is retained by the insured. Also any
amounts of potential loss (risk) over the nsured are retained

165
MBA 815 MANAGEMENT INFORMATION SYSTEM

risk. This may also be acceptable if the chance of a very large loss
is small or if the cost to insure for greater amounts is so
great it would hinder the goals of the organization too much.

3.2.3.4 Risk Transfer

This means causing another party to accept the risk,

typically contract or by hedging Insurance is one type of risk
transfer that uses contracts. Other times it may involve contract
language that transfers a risk to another party without the
payment of an insurance premium. Liability among
construction or other contractors is very often transferred
this way. On the other hand, taking offsetting positions in
derivatives is typically how firms use hedging to
financial risk management: financially managed risk.

Some ways of managing risk fall into multiple categories. Risk retention
pools are technically retaining the risk for the group, but
spreading it over the whole group involves transfer among
individual members of the group. This is different from
traditional insurance, in that no premium is exchanged
between members of the group up front, but instead losses are
assessed to all members of the group.

3.2.4 Create the Plan

Decide on the combination of methods to be used for each risk

3.2.5 Implementation

Follow all of the planned methods for mitigating the effect of the risks.
Purchase insurance policies for the risks that have been decided to
be transferred to an insurer, avoid all risks that can be
avoided without sacrificing the entity's goals, reduce others, and retain
the rest.

3.1.6 Review and Evaluation of the Plan

Initial risk management plans will never be perfect. Practice, experience,

and actual loss results, will necessitate changes in the
plan and contribute information to allow possible different decisions to
be made in dealing with the risks being faced.

166
MBA 815 MODULE 3

3.3 Risk Assessment and Cost Estimates

Project leaders should ensure that cost estimates,

including their classification, reflect the assessed risk for the various
phases of projects, and that they have been developed using appropriate
and comprehensive risk estimating practices, in conjunction
with other cost impact assessments. Commercial risk
assessment software packages are available to assist the project
leader in determining internal project risk.

3.3.1 Project Risk Assessment

External risk factors are circumstances over which project management

cannot exert a controlling influence. These factors include such elements
as externally imposed deadlines, cooperative development obligations or
statutory requirements.

Internal risk factors are circumstances that project

management can control. These factors include such
elements as the allocation of adequate resources and the
reliability of cost estimates.

Both internal and external risk factors should always be considered

in the overall risk assessment. Internal risk factors may be more
tangible, and their impacts on cost estimated with a greater degree of
confidence.

For external risk factors, it may not always be possible to provide

cost impacts. However, these external risks must be
identified and sufficiently detailed in project management
and project approval documents to apprise approval
authorities of their existence and potential impacts on the
success of the project.

3.3.2 Levels of Risk

The risk assessment should indicate an overall project risk level as high,
medium or low. As project definition progresses, the risk
assessment should be periodically updated to reflect the
additional information available.

3.3.3 Assessment of Risk

The following is a list of the type of factors that should be considered

when assessing risk. These factors are only indicators of the possibility
of risk. The assessment should consider the significance

167
MBA 815 MANAGEMENT INFORMATION SYSTEM

of these indicators for a specific project:

• the department's allocation of resources to the

project may be affected by changes in government priorities;
• the schedule is externally imposed or the project is
susceptible to time delays resulting from: relatively minor
changes in technology; requirements of participating
departments; available windows of opportunity with
international partners; seasonal considerations (for example,
access to the Arctic); the need for regulatory
approvals (such as environmental assessments), or other similar
factors;
• at the time of the assessment, the private sector does not
have the requisite capability in terms of the technology,
expertise, industrial practices, management techniques or skilled
and stable labour force required to undertake the project;
• the sponsoring department is not experienced in
managing and developing cost estimates for a project of a
particular magnitude or type (for example, international
cooperation including the effect of exchange rates), or cannot
assign sufficient in-house expertise;
• the project is particularly large in scale and complexity,
involving more participating departments or contractors than
similar projects previously sponsored by the department;
• there are no feasibility studies, test or user trial
programs, pre-production appraisals, similar production
items, reliable construction estimates, or they are similar
data upon which they base a risk assessment;
• project deliverables require research, development and
testing of unproven technology or assemblies of products;
• the project requires that work critical to the end-product be done
in several different locations, particularly when the
locations are isolated or environmentally sensitive;
• the project involves inherent hazards of a
biological, chemical, environmental, radiological, explosive,
toxic or other similar nature;
• the continuity or availability of a portion of project funding or
other project activity is contingent upon the ability of other
participants, especially non-federal government
participants, to meet their obligations when and as defined
in project agreements; and
• the impact of potential contingent or residual liabilities arising
from participation in joint or shared funded projects
including liabilities caused by withdrawal from the project by
one or more participants.

168
MBA 815 MODULE 3

Examples of arrangements addressed by the last two

factors include sharing of financial responsibilities in
federal/provincial or government/ private sector joint projects. To the
extent the private sector is involved in the project, the assessment of
these risk factors must involve a review of the technical and financial
stability of the firm and of the industry or environment the firm
operates within. Where there are third-party financial
backers, the assessment of these risk factors must examine the
stability of these companies in view of the security they have offered the
Crown.

3.3.4 Assessment of High Risk

A project (or element of a project) may be assessed as high risk if one or

more of the above hazards exist in a significant way
and, unless mitigated, would result in probable failure to achieve
project objectives. Project management should prepare approaches
to reduce this risk through strategies such as phased development,
funded system design by private industry, prototyping, pilot
systems and user trials. Project management should ensure that
senior departmental management is kept fully briefed regarding these
plans as well as project progress, and be prepared to quickly
request access to sources of expertise within the sponsoring and
any participating departments as well as the contracting
authority.

3.3.5 Assessment of Medium Risk

A project (or element of a project) may be assessed as medium risk if

some of the above hazards exist but have been mitigated to the point that
allocated resources and focused risk management planning
should prevent significant negative effect on the attainment
of project objectives.

3.3.6 Assessment of Low Risk

A project (or element of a project) should be assessed as low risk if the

above hazards do not exist or have been reduced to the
point where routine project management control should be capable of
preventing any negative effect on the attainment of project objectives.

169
MBA 815 MANAGEMENT INFORMATION SYSTEM

3.3.7 Management of Project Risk

Project leaders should ensure that project management:

• initiates, during the project planning phase, a continuing process

for assessing project risk;
• includes, during the project definition phase (when
applicable), formal steps to reduce project risk;
• prepares outline plans for dealing with actual project
contingencies;
• prepares a Project Profile and Risk Assessment as
defined in this Guideline and keeps it up-to-date;
• specifies these measures in the project management
framework sections of project approval documentation;
• prepares revised project approval documentation when the
project risk assessment changes significantly; and
• prepares an outline of a communications plan for high risk
activities that may attract media or public attention, including the
appointment of a spokesperson.

3.4 Limitations

If risks are improperly assessed and prioritized, time can be wasted in

dealing with risk of losses that are not likely to occur.
Spending too much time assessing and managing unlikely risks can
divert resources that could be used more profitably. Unlikely events do
occur, but if the risk is unlikely enough to occur, it may be better to
simply retain the risk, and deal with the result if the loss does in fact
occur.

Prioritizing too highly the Risk management processes

itself could potentially keep an organization from ever completing a
project or even getting started. This is especially true if other work is
suspended until the risk management process is considered complete.

3.5 Areas of Risk Management

As applied to corporate finance, risk management is a technique

for measuring, monitoring and controlling the financial or
operational risk on a firm's balance sheet. See value at risk.

Enterprise Risk Management

In Enterprise Risk Management, a risk is defined as a possible event or
circumstance that can have negative influences on the
Enterprise in question. Its impact can be on the very existence, the
resources (human and capital), the products and services,

170
MBA 815 MODULE 3

or the customers of the Enterprise, as well as external

impacts on Society, Markets or the Environment. ((Author's
Note Amazingly whenever Risk is considered this is often the last
Risk to be formally evaluated with such things as Project Risk
receiving much higher attention.

Project Management
In project management, a risk is more narrowly defined as a
possible event or circumstance that can have negative influences on a
project. Its influence can be on the schedule, the resources, the
scope and/or the quality.

In project management parlance, when a risk escalates, it

becomes a liability. A liability is a negative event or circumstance that
is hindering the project.

Some of the processes for assessing risk include the

following p arentheses contain some of the jargon used to refer to
them).

• Choosing unique identifiers for referring to the same risk in

company or project documents (identification).
• Describing the risk and how it could become a liability
(description).
• Assessing the consequences of that (effect).
• Considering what precautions could be taken to
prevent it (precaution).
• Drawing up contingency plans or procedures for
handling it (contingency).
• Categorizing the risk as new, ongoing or closed (risk status)
• Estimating the probability of the risk becoming a
liability (Risk escalation probability, P)
• Estimating the consequences in terms of time for
the project (Schedule impact, S)

In addition, every probable risk can have a pre-formulated plan to deal

with it to deal with its possible consequences (to ensure contingency if
the risk becomes a liability).

Risk in a project or process can be due either to special

equivalent in the list immediately above.

3.6 Risk Management Activities

In management information management project management,

risk management includes the following activities:

171
MBA 815 MANAGEMENT INFORMATION SYSTEM

• Planning how risk management will be held in the particular

project. Plan should include risk management tasks,
responsibilities, activities and budget.
• Assigning risk officer - a team member other than a project
manager who is responsible for foreseeing potential project
problems. Typical characteristic of risk officer is a healthy
skepticism.
• Maintaining live project risk database. Each risk
should have the following attributes: opening date, title,
short description, probability and importance. Optionally
risk can have assigned person responsible for its
resolution and date till then risk still can resolved.
• Creating anonymous risk reporting channel. Each
team member should have possibility to report risk that he
foresees in the project.
• Preparing mitigation plans for risks that are chosen to be
mitigated.

The purpose of the mitigation plan is to describe how this particular

risk will be handled what, when, by who and how will be
done to avoid it or minimize consequences if it becomes a liability.

• Summarizing planned and faced risks, effectiveness of

mitigation activities and effort spend for the risk management.

4.0 CONCLUSION

Adequate risk assessment and management is important for all projects

regardless of dollar value. An adequate risk assessment usually requires
the contribution and expertise of the contracting authority as well as any
participating departments. This is particularly important
during the initial assessment, which necessarily would be based upon
early project planning data.

5.0 SUMMARY

• Generally, Risk Management is the process of

measuring, or assessing risk and then developing strategies to
manage the risk. In general, the strategies employed
include transferring the risk to another party, avoiding
the risk, reducing the negative affect of the risk, and accepting
some or all of the consequences of a particular risk.
• A first step in the process of managing risk is to identify
potential risks. Risks are about events that, when
triggered, will cause problems.

172
MBA 815 MODULE 3

• Once risks have been identified, they must then be

assessed as to their potential severity of loss and to the
probability of occurrence.
• Project leaders should ensure that cost estimates,
including their classification reflect the assessed risk
for the various phases of projects and that they have
been developed using appropriate and comprehensive risk
estimating practices in conjunction with other cost impact
assessments.
• External risk factors are circumstances over which
project management cannot exert a controlling influence.
• The risk assessment should indicate an overall project risk
level as high, medium or low. As project
definition progresses, the assessment should be
periodically updated to reflect the additional information
available.
• A project (or element of a project) may be assessed as high
risk if one or more hazards exist in a significant way and, unless
mitigated, would result in probable failure to achieve project
objectives.
• If risks are improperly assessed and prioritized, time can be
wasted in dealing with risk of losses that are not likely to occur.
• In Enterprise Risk Management, a risk is defined as a possible
event or circumstance that can have negative influences on the
Enterprise in question.
• In project management parlance, when a risk escalates, it
becomes a liability. A liability is a negative event or
circumstance that hsindering the project.
• In project management, risk management includes planning how
risk management will be held in the particular project.

The next study unit which is the finally study unit for
this course bsasically on design and planning for GIS.

6.0 TUTOR-MARKED ASSIGNMENT

1. Discuss how to initiate and execute a information

system risk assessment
2. In what way can a risk be managed on identification?

173
MBA 815 MANAGEMENT INFORMATION SYSTEM

7.0 REFERENCES/FURTHER READING

Alijoyo, Antonius (2004). Focused Enterprise Risk Management (1st

ed.), PT Ray Indonesia, Jakarta.

Dorfman, Mark S. (1997). Introduction to Risk Management

and Insurance (6th ed.), Prentice Hall.

TenStep, Inc Project Management Best Practices II: Work the Plan

Stulz, René M. (2003). Risk Management & Derivatives (1st

ed.), Mason, Ohio: Thomson South-Western.

174
MBA 815 MODULE 3

UNIT 5 DESIGN AND PLANNING FOR GIS

CONTENTS

1.0 Introduction
2.0 Objectives
3.0 Main Content
3.1 Geography Information Systems (GIS)
3.2 GIS Lifecycle and the Value of a Problem-
Solving
Approach
3.3 Key Aspects of GIS Project Lifecycle
3.3.1 Setting Goals Estimating Costs
3.3.2 The Functional Requirements Study
3.3.3 The Creation of a Prototype
3.4 System Selection as a Compromise
3.5 Planning Schedules and the Scope of Prototype and Pilot
Projects
3.6 Applying the Insights of Project Lifecycle to
Research Projects
3.7 Planning and Database Issues
3.7.1 Security
3.7.2 Documentation
3.7.3 Data Integrity and Accuracy
3.7.4 Synchronization of Usage
3.7.5 Update Responsibility
3.7.6 Minimization of Redundancy
3.7.7 Data Independence and Upgrade Paths
3.7.8 Privacy
4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment
7.0 References/Further Reading

1.0 INTRODUCTION

This final unit of the course material dwells extensively on design

and planning for Geographic Information systems (GIS).

2.0 OBJECTIVES

The objective of this unit is for you to:

• specifically understand the process of developing a

geographic information system
• compare the lifecycle of GIS to other project models

175
MBA 815 MANAGEMENT INFORMATION SYSTEM

• understand he key aspects and issues in GIS project planning

• identify and understand compromises in system selection.

3.0 MAIN CONTENT

3.1 Geography Information System

GIS projects are expensive in terms of both time and money. Municipal
GIS and facilities management projects developed by utilities may take
a decade or more to bring on-line at a cost of
tens or hundreds mfillions of dollars. Careful planning at the outset,
as well as during the project, can help to avoid costly mistakes. It also
provides assurance that a GIS will accomplish its goals on schedule and
within budget.

There is a temptation, when a new technology like

GIS becomes available, to improvise a solution to its use, that is, to
get started without considering where the project will lead.
The greatest danger is that decisions made in haste or on the
spur of the moment will have to be reversed later or will prove
too costly to implement, meaning a GIS project may have to
be abandoned. To avoid disappointing experiences like these, GIS
professionals have developed a well-defined planning
methodology often referred to as project lifecycle. Lifecycle
planning involves setting goals, defining targets, establishing
schedules, and estimating budgets for an entire GIS project.

Figure 1: Cost -Time Analysis of Information Technology projects

The original impetus for developing effective lifecycle planning

was cost containment. For many decades, the rationale for
implementing new information technologies was that, in the long
run, such projects would reduce the cost of business operations.

176
MBA 815 MODULE 3

It is generally recognized that, for the foreseeable

future, most information technologies projects will have to be justified
on the basis of a "do more, pay more" philosophy. This
means that effective lifecycle planning is all the more
important. In the past, projected existing costs could be used as
a baseline against which improvements could be measured. If the cost
curve for new information technologies is always above the baseline,
then greater care must be exerted in setting goals, establishing targets,
and estimating budgets.

3.2 GIS Lifecycle and the Value of a Problem-

solving Approach

Lifecycle planning is really a process of practical problem applied to all

aspects of a GIS development project.

Figure 2: A Project Life Cycle

177
MBA 815 MANAGEMENT INFORMATION SYSTEM

Figure 3: GIS Project Life Cycle

Particular care is exerted in defining the nature of a problem
or new requirement, estimating the costs and feasibility of
proceeding, and developing a solution. This process should not be
abridged; each step is important to the overall process. If this
problem solving approach is applied to the design and
creation of an entire GIS project additional subtasks
must be addressed, as in the diagram below

3.3 Key Aspects of GIS Project LifeCycle

Three aspects of this planning process merit special attention.

3.3.1 Setting Goals and Estimating Costs

Each stage of the project lifecycle process involves setting clear

goals for the next step and estimating the cost of reaching those goals.
If the necessary funds or time are unavailable, it is better to stop the
process than to continue and see the project fail. The process can
begin again when funds are available.

3.3.2 The Functional Requirements Study

The functional requirements study is arguably the most important single

step in the planning process. Here, careful study is
devoted to information is required for a project, how it is to be used,
and what final products will be produced by the project. For a large
organization, this amounts to a "map" of how information flows into,
178
MBA 815 MODULE 3

around, and out of each office and agency. The FRS also
specifies how often particular types of information are needed
and by whom. Furthermore, the FRS can look into the future to
anticipate types of data processing tasks that
expand upon or enhance the organization's work.

By assessing information flows so carefully, the FRS

allows an organization to set goals for all of the subsequent steps in
the lifecycle planning process. The FRS also allows
an organization to information flows across all the
domains of its work, forcing consider how different
systems will be integrated. Without taking an encompassing view
of information flows, a project implemented in one
unit may be of no use to another. It is important to take this broad view
of information flows to avoid stranding projects between incompatible
systems.

3.3.3 The Creation of a Prototype

By the time a project has moved into the development stage, the greatest
temptation is to jump forward to full implementation. This
is a very risky path, for it leaves out the rototyping
stage. Prototypes critical step because they allow the system to be
tested and calibrated to see whether it meets expectations and goals.
Making adjustments at the prototype stage is far easier than later,
after full implementation. The prototype also allows users
to gain a feel for a new system estimate how much time
(in training and conversion) will be required to move to the pilot and
full implementation stages. Finally, a successful prototype can help
enlist support and funding for the remaining steps in
the lifecycle planning process.

As is noted in the module on managing error, the prototype provides

a good opportunity for undertaking sensitivity analysis--testing to see
how variations in the quality of inputs affect outputs of the
system. These tests are essential for specifying the accuracy,
precision, and overall quality of the data that will be created during
the conversion process. If these analyses are not performed, there is a
chance that much time and effort will be wasted later.

3.4 System Selection as a Compromise

In selecting a software and hardware combination, users are often

faced with a number of compromises. For a given price, a system
cannot be expected to do everything. A thoughtful choice is required
in order to select the system that will best meet the

179
MBA 815 MANAGEMENT INFORMATION SYSTEM

principal aims of a project. Figure 1, helps to show how users

might attempt to balance four of the many characteristics of a
given system. In these cases, the compromises involve:

Speed: The speed with which a system can respond to

queries and achieve solutions.

Functional richness: The analytical capabilities of the system and

its flexibility in addressing a wide range of spatial and statistical
problems.

Database Size: The ability to handle large quantities of

spatial and statistical data. Training: The amount of time required to
bring users up to speed on a system and to use the database on a regular
basis.

A. Some applications, such as emergency vehicle

dispatch (911 systems), require high performance speed. Lives are at
stake and the system must be able to match telephone numbers to
addresses and dispatch vehicles instantly. At the same time, an
emergency dispatch system will only be used to serve this single
function and the database will contain only a street grid, address
ranges, and links to telephone numbers.

B. Some applications, such as those undertaken by water, gas, and

power utilities, involve storing vast quantities of
information about huge service territories. Some utilities serve
hundreds or thousands of square miles of territory. Detailed information
must be maintained about all facilities within these
territories. Managing these quantities of information is a key to
selecting the right GIS system. At the same time, speed of
response may be less of a concern since a given piece of
information may only have to be accessed once a
month or even once a Furthermore, functional richness may
be useful, but many tasks (such as maintenance and planning) will
require a limited range of analytical capabilities.

C. Some applications, such as those related to urban planning

and environmental management may benefit most from
great functional richness. Planning and management tasks
may be many and varied, meaning that users must have access to a
wide range of spatial and statistical functions. These may not be used
often but, when used, may be essential to the success of a project.

180
MBA 815 MODULE 3

Figure 4: Criteria for system Selection

D. Some GIS may be used frequently by users with little training or

in situations where there will be high staff turnover.
This is a co nsideration for GIS that are used as part of management
or executive information systems. Upper-level managers who
can benefit greatly from the information provided by a
GIS may have limited time inclination) for training. It is
important in these situations to consider the time it takes to bring new
users up to speed with a new system.

Of course, these are only a few of the factors and scenarios that arise in
GIS system selection. Compromises may have to be achieved with other
system features.

Too often, users imagine that they can find the "perfect" or "best" GIS.
The best GIS is always the one that gets a job done at the right price and
on schedule.

3.5 Planning Schedules and the Scope of Prototype and Pilot

Projects

There is nothing wrong with being cautious during the process of project
planning. Rushing through the procedure exposes an
organization to potentially costly mistakes. Large AM/FM projects
typically take many years to reach the prototype or pilot stages.

Once a prototype or pilot has been approved, even more time will elapse
before full implementation is achieved. Some municipal GIS
projects have been underway for over a decade and still have far
to go before complete implementation and compilation of a full
dataset.

181
MBA 815 MANAGEMENT INFORMATION SYSTEM

Table 1: Examples of AM/FM Pilot Size

Prototype and pilot projects are kept small, as is

indicated in the following table. Remember, prototypes
and pilots are intended to demonstrate functions and
interfaces. What works best is a carefully selected test area
that presents examples of common workflows. It’s a
real size of little consequence in most applications.

3.6 Applying the Insights of Project Lifecycle to Research

Projects

The concepts of lifecycle planning can be applied to projects of lesser

scale and scope, particularly to those pursued in
undergraduate and graduate research. This does not mean
that every project will move through every step outlined
above. Some steps such as benchmarking and system selection
may be irrelevant in a setting where the researcher
must make do with whatever equipment and software is on hand.
But lifecycle planning should not be viewed as a
series of boxes on checklist; it is a process of careful planning and
problem solving. It is this process of careful planning that should be
emulated regardless of the scope or scale of a project.

182
MBA 815 MODULE 3

1. Think Ahead to How the GIS will be Used, But Keep in Mind
Available Sources
Designing an effective GIS involves setting clear goals. The temptation
Is to rush ahead and begin digitizing and converting data
establishing how the system will be used. Even for small GIS projects, it
is wise to engage in a modest functional requirements study. This allows
the user to gain an idea of exactly what data sources are required, how
they will be processed, and what final products are expected.
Without clear-cut goals, there is too great a danger that a project will
omit key features or include some that are irrelevant to the final use.

2. Exert Special Care in Designing and Creating the Database

Again, it is easy to rush ahead with the creation of a database, and then
find later that it has to be reorganized or altered extensively.
It is far more economical to get things right the first time. This
means that the researcher should chart out exactly how the database is to
be organized and to what levels of accuracy and precision. Attention to
(and testing) of symbolization and generalization will also pay off
handsomely.

3. Always Develop a Prototype or Sample Database to Test

the Key Features of the System
No matter the size of a project, the researcher should aim to
create a prototype first before moving toward full implementation of a
GIS. This allows the researcher move through all of the steps of creating
and using the system to see that all procedures and algorithms work as
expected. The prototype can be a small area or may be confined to one or
two of the most critical layers. In either case, testing a prototype is one
step that should not be overlooked.

3.7 Planning and Database Issues

The project planning cycle outlines a process, but the issues that must be
addressed at each stage of this process will vary
considerably o rganization to organization. Some topics are of critical
importance to large municipal, state, and private AM/FM applications,
but less so for research applications of limited scope. Among the
issues that must be addressed in large GIS projects are:

3.7.1 Security

The security of data is always a concern in large GIS projects. But there
is more to security than protecting data from malicious
tampering or theft. Security also means that data is protected
from system crashes, major catastrophes, and inappropriate uses. As a
result, security must be considered at many levels and must anticipate

183
MBA 815 MANAGEMENT INFORMATION SYSTEM

many potential problems. GIS data maintained by government

agencies often presents difficult challenges for security. While
some sorts of data must be made publicly accessible under open
records laws, other types are protected from scrutiny. If
both types are maintained within a single system, managing
appropriate access can be difficult. Distribution of data
across open networks is always a matter of concern.

3.7.2 Documentation

Most major GIS datasets will outlive the people who

create them. Unless all the steps involved in coding
and creating a dataset are documented, this information will be
lost as staff retire or move to new positions. Documentation must begin
at the very start of GIS project and continue through its life. It
is best, perhaps, to actually assign a permanent staff to
documentation to make sure that the necessary information
is saved and revised in a timely fashion.

3.7.3 Data Integrity and Accuracy

When mistakes are discovered in a GIS database, there must be a well-

defined procedure for their correction (and for documenting
these corrections). Furthermore, although many users may
have to use the information stored in a GIS database, not all of
these users should be permitted to make changes. Maintaining
the integrity of the different layers of data in a
comprehensive GIS database can be a challenging task. A
city's water utility may need to look at GIS data about right-of-
ways for power and cable utilities, but it should not be
allowed to change this data. Responsibility for changing and
correcting data in the different layers must be clearly demarcated
among different agencies and offices.

3.7.4 Synchronization of Usage

GIS datasets employed in government or by utilities will

have many users. One portion of the dataset may be in demand
simultaneously by several users as well as by staff charged with
updating and adding new information. Making sure that all
users have access to current data whenever they need it
can be a difficult challenge for GIS design.
Uncontrolled usage may be confusing to all users, but
the greatest danger is that users may actually find themselves
interfering with the project workflow or even undoing one another's
work.

184
MBA 815 MODULE 3

3.7.5 Update Responsibility

Some GIS datasets will never be "complete." Cities and utility territories
keep growing and changing and the database must be constantly updated
to reflect these changes. But these changes occur on varying schedules
and at varying speeds. Procedures must be developed to record, check,
and enter these changes in the GIS database. Furthermore, it
may be important to maintain a record of the original data.

3.7.6 Minimization of Redundancy

In large GIS projects, every byte counts. If a database is maintained for

30-50 years, every blank field and every duplicated byte of information
will incur storage costs for the full length of the project. Not only will
wasted storage space waste money, it will also slow performance.
This is why in large, long-term GIS projects, great attention to
devoted to packing data as economically as possible and
reducing duplication of information.

3.7.7 Data Independence and Upgrade Paths

A GIS database will almost always outlive the hardware and

software that is used to create it. Computer hardware has a
useable life of 2-5 years; software is sometimes upgraded
several times a year. If a GIS database is totally dependent on a
single hardware platform or a single software system, it too will have to
be upgraded just as often. Therefore, it is best to create a
database that is as independent as hadware and software.
Through careful planning and design, data can be transferred as
ASCII files or in some metadata or exchange format from system to
system. There is nothing worse than having data held in a proprietary
vendor-supported format and then finding that the vendor has changed
or abandoned that format.

In this way, GIS designers should think ahead to possible upgrade paths
for their database. It is notoriously difficult to predict what will happen
next in the world of computers and information technology.

3.7.8 Privacy

Safeguards on personal privacy have become a great concern over

the past decade, particularly with the rise of the internet and web.
These concerns arise to two principal situations. The first is the
hacking into, accidentally release, or inappropriate disclosure of
privileged information which can compromise an individual's privacy
with respect to medical conditions, financial situation, sexual,
185
MBA 815 MANAGEMENT INFORMATION SYSTEM

political, religious beliefs & values and other privileged personal

information. The second is the ease with which information and
computer technologies permit the creation of information "mosaics" or
personal profiles from small pieces of seemingly innocuous, non-
confidential data.

4.0 CONCLUSION

Though geographic information systems could be unique in

itself, its project planning cycle still follow the
fundamental stages of every project, be it mall or large.
And irrespective of the extent complexity of GIS project,
by sticking closely with the life cycle such project will be successfully
implemented. This project lifecycle of GIS is adaptable to other project,
even if it is a small project.

5.0 SUMMARY

• GIS projects are expensive in terms of both time and money.

• The original impetus for developing effective lifecycle planning
was cost containment. For many decades, the rationale for
implementing new information technologies was that, in the long
run, such projects would reduce the cost of business operations.
• Designing an effective GIS involves setting clear goals.
• Particular care is exerted in defining the nature of a problem or
new requirement, estimating the costs and feasibility of
proceeding, and developing a solution.
• By assessing information flows so carefully, the
FRS allows an organization to set goals for all of
the subsequent steps in fecycle planning process.
• In selecting a software and hardware combination, users
are often faced with a number of compromises.
• There is nothing wrong with being cautious during the
process of project planning; rushing through the
procedure exposes an organization to potentially costly
mistakes.
• The concepts of lifecycle planning can be applied
to projects of lesser scale and scope, particularly to those
pursued in undergraduate and graduate research.

186
MBA 815 MODULE 3

• The project planning cycle outlines a process, but the

issues that must be addressed at each stage of
this process will vary considerably from organization to
organization.
• In large GIS projects, ever y byte counts. If a database is
maintained for 30-50 years, every blank field and every
duplicated byte of information will incur storage costs for
the full length of the project.

6.0 TUTOR-MARKED ASSIGNMENT

1. Discuss the major system criteria needed for a GIS.

2. Outline some of the planning and database issues for
successful implementation of a GIS.

7.0 REFERENCES/FURTHER READINGS

Aronoff, Stan. (1989). Geographic Information Systems: A Management

Perspective. WDL Publications: Ottawa.

Clarke, Keith C. (2003). Getting Started with Geographic Information

Systems, 4th ed. Upper Saddle River, NJ: Prentice Hall.

Dagermond, Jack, Don Chambers, and Jeffrey R. Meyers.

(1993). "Prototyping AM/FM/GIS Applications:
Quality/Schedule Tradeoffs", Proceedings of the
Thirteenth Annual ESRI User Conference. Palm Springs,
CA. Vol. 2, p. 75-80.

Daniel, Larry. Identifying GIS for What It's Worth.

Daniel, Larry. Looking and Thinking Beyond the Department.

Kenneth E. Foote and Shannon L. Crum, (2000). Project Planning and

Life Cycle.

Lo, C.P. and Albert K.W. Yeung. (2002). Concepts and Techniques of
Geographic Information Systems. Upper Saddle River,
NJ: Prentice Hall.

Huxhold, William. (1995). Managing Geographic Information

System Projects. Oxford University Press: New York.

Longley, Paul A., Michael F. Goodchild, David J. Maguire, and David

187
MBA 815 MANAGEMENT INFORMATION SYSTEM

W. Rhind. (2005). Geographic Information Systems and Science, 2nd ed.

Hoboken, NJ: Wiley.

Obermeyer, Nancy J. and Jeffrey K. Pinto. (1994).

Managing Geographic Information Systems. New York:
Guilford Press.

188