Project management

Techniques for managing a project

What is a project?
communication skills necessary for
dealing with others
the consequences for groups that fail
to function as a team, including:
financial loss
employment loss
missed opportunities

understand the communication skills

required to manage a system
development project, such as:
active listening
conflict resolution
negotiation skills
interview techniques
team building
understand the need to apply project
management tools to develop a system
using a team approach
appreciate the advantages of groups
that function as a team, including:
increased productivity
enhanced job satisfaction
the development of a quality
system

What is a project?
A project refers to a planned idea rather than a routine. In the IT industry, an
information system is referred to as a project which can take the form of a fully
customisable database application, an online transaction system, a multimedia
system, a computer network or online application. Any system designed and
implemented to achieve an objective is a project.

The project triangle

Money, scope and time directly affect the quality of the project.

Sc
op
e

Project management encompasses an array of tasks that need to be achieved in order

for a project to be completed within budget, resources and time constraints.

Quality

Time

Managing a project
Project management is the process of planning, scheduling and controlling all the
activities within each stage of the system development cycle. It aims to deliver a new
system within an acceptable time frame and budget. All aspects of a project need to
be managed, some aspects are more complex than others but are not necessarily
more difficult.
In a project:

Every task has a specific objective to be met or a specified product to be created

Planning is required
There is a predetermined time span that can be absolute (no extensions) or
relative (can be adjusted)
Work can be carried out by a project team or outsourcing someone else
There are many specialisations such as programming, designing and planning,
user interface, management, research and development
Work is usually carried out in phases
Resources available for use on the project are often constrained
Projects are usually large and complex

A project is usually developed in a team. A team is a group of people that preferably

have a diverse set of skills that can target specific aspects of the project itself.
Individuals assigned to a project need to be able to work together as a team, ensuring
that the project can be finished accordingly. Teams will also need to work well between
other teams.
Communication skills
Communication skills are needed to ensure that ideas are understood by all people
involved in a project so that there are no misunderstandings about the ideas being
conveyed. It is best to use a range of communication skills when communicating with
others.
Mirroring

Paraphrasin
g
Summarisin
g
Clarifying
questions
Motivational
responses

Active
listening

Conflict
resolution

Repeating speakers key words

Indicates interest of ideas being conveyed
Allows speaker to reflect on what is being said
Listener uses own words to explain what speaker has said
Allows listener to reflect on what is being said
Encourages refinement of idea
Used to refocus or direct to an important topic
Allows parties to elaborate on idea being conveyed
Encourages the speaker to provide detailed explanations
Can be open or close-ended
Encourages reinforcement of active listening from the listener
Used to convey understanding or personal connection to what
is being said
Restating, reflecting and summarising the speakers major
ideas and feelings
Encouraging the speaker
Response
Engagement
Eye contact
Body language
Acknowledgement
Solves arguments and disputes
Involves listening to other peoples views and looking at the
conflict as a problem to be solved

Compromise
Acknowledging opinions
Mutual respect

Negotiation
skills

Interview
techniques

Team
building

Involves discussing a problem and arriving at a consensus

Listening to different views and compromising to reach a
solution
Recognise win situation for both parties
Give and take
Commitment to an idea
Agreement
Involves careful preparation, implementation and follow-up
A list of questions should be prepared with a clear purpose
Open/closed-ended questions
Relevant question
Proper/clear language
Time
The process of getting a group of people working together
Each team member negotiates a role in the team with specific
responsibilities
The team members efforts are coordinated to ensure the
efficiency of the team
Inclusion
Acknowledgement of ideas/opinions
Specialisation of skills required by entire team
Reward
Interaction

Project management tools

project management tools, including:
Gantt charts
scheduling of tasks
journals and diaries
funding management plan
communication management plan

appreciate the need for complete

documentation throughout all aspects
of the system

Management tools are mainly needed to document a system and communicate

between team members and other teams what are the tasks, who is completing them,
the time frame and money available for each task. They manage time and budget
so that there arent any significant overruns.

A project plan is a summary of a project, clarifying what needs to be done and

helps people to understanding their role in the project. These people should
understand the need for project goals (result of a successful project), deliverables
(tangible items expected from a task) and schedules (time of major tasks and
roles)
Common time management tools include the Gantt chart, journals and diaries
A Gantt chart is a bar chart with each bar representing a task or stage in the
system development cycle. Gantt charts provide a quick method of determining
whether the project is on schedule

A funding management plan ensures the project is developed within budget. It

outlines fund allocation, expenditure mechanisms (how resources will be spent),
task accountability (maximising use of funds) and fund reallocation as needed
(when budgets are surpassed)

A communication management plan outlines the communication medium to

be used (such as email or instant messaging), the line/s of communication (such
as one-on-one or group) and how each party is to communicate to the team and
the client. This is done to monitor development progress such as costs, task
completion, addressing changes and emerging requirements
Management plans in general should account for contingencies when lines of
communication are inadequate or tasks are incomplete due to unexpected
factors such as budget and staffing

Social and ethical design

identifying social and ethical issues

assess the social and ethical

implications of the solution throughout
the project

Design of systems
Information systems should be designed to take into account the strengths and
weaknesses of both people and machines.

Machine-centred systems are designed to simplify what the computer must do

at the expense of participants. They assume people will follow confusing
procedures and illogical user manuals.
Human-centred systems are those that make participants work as effective
and satisfying as possible. They allow people to do their work without wasting
time and effort struggling with the information technology.
User-friendly information systems are more productive as participants do not
waste time and effort dealing with the system.
Work environment

The design of a system impacts on the work environment. The impact can be positive
or negative.
The relationship between people and their work environment is called ergonomics. It
refers to the process of designing or arranging workplaces, products and systems so
that they fit the people who use them.
A new information system will change a participants work.

Use of skills: Participants may be required to retrain and learn new skills
(become multi-skilled) or perform work requiring less skills (become deskilled)
Meaningful work: Participants who work on the computer may not understand
the importance of their work. Their work may be abstract in nature and focused
on symbols on the screen
Nature of the workplace: Part-time work and the use of contracted labour may
increase

Systems and ethics

Ethics is a set of beliefs we hold about what is right and wrong. Issues involving the
use of information systems include:

Environmental damage: Allowing people to work from home, access to

electronic services in country areas, manufacture of silicon chips and paper
consumption
Equity and access: Equal rights for all, people in isolated communities can gain
education previously only available in larger cities, helping the disabled and
gender equity
Invasion of privacy
Freedom of information
Computer crime
Copyright

Understanding the problem

Preliminary investigation
approaches to identify problems with
existing systems, including:
interviewing/surveying users of
the information system
interviewing/surveying
participants
analysing the existing system by
determining:
- how it works
- what it does
- who uses it

apply appropriate techniques in

understanding the problem
interpret a requirements report which
includes:
the purpose of the systems
an analysis of an existing system
definition of extra requirements
diagrammatically represent existing
systems using context diagrams and
data flow diagrams
identify, communicate with and
involve participants of the current
system

Understanding the problem determines the purpose and requirements of a new

system. This is the foundation for the requirements report which defines the
precise nature of the problem to solved, the primary deliverable.

A requirement is a feature, property, behaviour or characteristic that a system

must have in order to achieve its purpose

Analysts have two major tools at their disposal, interviewing users and generating
prototypes.
Interviewing or surveying users of the existing system is a good method for
collecting or obtaining insight into user experiences and problems with the existing
system. Needs and ideas can be given by users that can help improve the existing
system. The larger the sample of users interviewed the better the responses obtained
can be and as a result, more accurate responses to derive requirements. Questions
used in a survey or interview must be planned to obtain specific responses that may
lead to users sharing their experiences and problems with the existing system.
Participants will often provide different responses that users as they have an
understanding of the part of the system they interact with. They often identify

problems and have ideas for how to solve them. They are a vital source of information
for details of the information system.
Analysts may use the responses from both users and participants to develop diagrams
and system models.

Requirements of the new system

requirements reports
create a requirements prototype from
requirements prototype a working
applications packages that provide:
model of an information system, built
screen generators
report generators
in order to understand the
use a prototype to clarify
requirements of the system
participants understanding of the
used when the problem is not
problem
easily understood
repetitive process of prototype
modification and participants
feedback until the problem is
understood
can be the basis for further
system development
The requirement report is a statement about the need for a new system. It outlines
the aims and objectives of the new system and how it will help the client.
The language in the requirements report should be formal and easy to understand,
clear and concise, never implying references or inferences for a particular solution. It
is provided to both the client and the team that is developing the new system. This
report is used in all stages of system development.
The preparation of the requirements report is known as requirements analysis. The
requirements report is used to determine possible solution, their feasibility and
comparison between them.
The contents of the requirements report are usually:

Introduction: System purpose, user needs and system scope (extent to which
the purpose will be met)
General system description: System context (environment it will work in),
major system requirements and participant characteristics (how the participants
will initiate information processes such as access levels)
System requirements: Physical (hardware), performance, security, data and
information and systems operations

A requirements prototype is a working model of an information system, built to

understand the requirements of the new system. This prototypes models the
components of the new system for the users to interact with, accurately simulating
the look and behaviour of the new system such as screen mock ups, sample reports,
forms, etc.
A requirements prototype does not perform any real processing since its aim is to
confirm, clarify and better understand the requirements.
Many requirement prototypes will be created in the process of developing a new
system as changes and feedback from users and participants will be used to make

improvements until the users, participants and analysts are satisfied that the
requirements have been understood.
It would be unfavourable to create a system with 100% efficiency as it will require
large amounts of maintenance for the system.
The requirements for a new system can be determined once participants are
interviewed and a requirements prototype has been made. These are written formally
in the requirements report which also defines inputs and outputs as well as their
relationship.

Planning
Feasibility study
a feasibility study of proposed
solutions, including:
economic feasibility
technical feasibility
operational feasibility
scheduling

conduct a feasibility study and report

on the benefits, costs and risks of the
project

The feasibility study

The aim of planning is to decide which possible solution, if any, should be developed
and decide how it should be developed and managed. The feasibility of developing a
new system is analysed to create the feasibility study report. There are generally 2 to
4 proposals presented.
A feasibility study is a short report that analyses potential solutions in terms of the
known constraints and makes a recommendation. The feasibility study must assess
the feasibility of each possible solution fairly, the requirement report plays a major
role in this regard as without a common set of requirements it would be difficult to
make a fair comparison between different solution options.
Economic feasibility
Economic feasibility (or cost/benefit analysis) compares the costs of developing and
implementing the new system with the expected benefits. It would appear that the
least expensive option to develop and implement would be the most economically
feasible, however this is not always the case. The financial cost of developing a
system should be less than the financial benefit gained from the system.

A cost-benefit analysis compares all the costs with all the benefits in an attempt
to determine the total return on the money invested into the new system
The Net Present Value (NPV) determined the current value of a system and
predicts its worth in the future, a positive NPV indicates a system that retains its
value while a negative NPV indicates an investment that should not be developed
further
The return on investment (ROI) is the difference between the initial NPV and
profit generated once development cost and investment can be recouped
The most economically feasible solutions have a high NPV, high ROI and short
payback period
Technical feasibility

Technical feasibility determines the information technology requirements of the

new system and the technical demands that will be placed on the new system. It is
concerned with the availability of the required information technology, its ability to
operate with other technology and the technical expertise of participants and users to
effectively use the new technology.
Operational feasibility
Operational feasibility determines whether the new system will fit into the
organisation and meet the current goals and objectives. It also determines whether

the new system will have enough support from participants to be successfully
implemented and whether participants can operate the system. A solution option will
be operationally feasible if it meets the needs of the participants and users of the
system.

Scheduling
Schedule feasibility determines whether time is available to implement the new
system. It also examines the consequences should some tasks or the entire project
fail to meet its specified deadlines. The project plan, in particular the Gantt chart, will
specify the deadlines for completion of each development task.

System development approaches

choosing the most appropriate
solution
choosing the appropriate
development approaches
traditional
outsourcing
prototyping
customisation
participant development
agile methods

compare traditional, iterative and

agile system development approaches

Selecting a system development approach

The particular nature of the development team and the individual characteristics of
each project determines which system development approach should be selected.
If a team is focusing on the hardware of an information system, a traditional approach
may work best because hardware requirements are often predetermined. When
developing a system or software, an agile approach works best as it allows the
development of prototypes which can be developed into full applications or systems
very quickly.

Traditional
The traditional approach (also known as a cascade, structured
or waterfall approach) to system development involves formal
Understanding the problem
step-by-step stages where each stage must be completed before
progressing to the next stage. As each stage is completed
deliverables feed down to the next stage and into all subsequent
Planning
stages. Because of this there is no returning to a previous stage
and there are few opportunities for users and others to provide
ongoing feedback. Consequently error and omissions can feed
Designing
through the system development cycle without detection.
This development approach can take long periods of time but is
very well suited for development of systems where the
Implementing
requirements can be determined in advance such as hardwarebased products.
Testing, evaluating and maintaining

Outsourcing
Outsourcing of development tasks involves using another company to develop parts
of the system or even the complete system. It is often more cost effective to
outsource specialised tasks to an experienced company rather than to employ new
staff or train existing staff, particularly when aspects of the system require highly
specialised skills which are unlikely to be required once the system is operational.
Contracting and outsourcing are similar in some respects but when an outside
organisation is contracted they work under the direct management of the contracting
company while outsourcing involves passing control of the entire process over to the
outsourced company. Outsourcing is helpful as the contacting company is not
responsible for troubleshooting when problems arise.

Prototyping
The prototyping approach (also known as
iterative approach) extends the use of
requirements prototypes so that they
evolve to a point where they actually
become the final solution or become
sufficiently detailed that they can be used to
present a concept for full scale
development. Concept prototypes become
an essential part of the requirements for the
new system as they are accurate simulations
of the final system.
Any prototype has the potential to become
the complete and finished system. For the
most part, a prototype will simulate most
operation that a new information system
should do. They help develop an
understanding of the requirements for a new
system.

Understanding the problem

Planning

Designing

Testing, evaluating and maintaining

Understanding the problem

Implementing

Testing, evaluating and maintaining

Customisation
Customisation can allow an existing system to suit the specific needs and
requirements of the new system when it is economically unviable to develop a
completely new system. Most business systems are customised versions of existing
systems, for example virtually all hotels around the world use one of only a handful of
commercially available software and hardware systems. One commercial system can
be selected and customised to suit specific requirements.

Open source software can be easily modified to suit the user. These established
information systems be used by small businesses, meaning they wouldnt need to
develop a completely new system, this would be cheaper and require less IT
expertise. A system development kit (SDK) allows users to add functions or customise
this software. MYOB is an example of a customisable information system, allowing for
business processing and custom modules to be downloaded.
Customisation may involve alterations to the settings of hardware or software or it
may involve changes to functions of the actual hardware or software itself.
Participant development
The participant development approach relies on the people that will use and
operate the final system to also develop the system. This approach requires little
consultations as it is the users and participants that will largely determine the system
requirements. This can speed up development considerably but can have numerous
disadvantages.
The users must have sufficient skills to be able to create the system and understand
the extent of their skills. Systems that will mainly be used by the developer/user are
often suitable candidates. There is no need for detailed documentation in this
approach as the developer is always on hand to answer questions and make
modifications.
Participants are actively involved in developing a system as they can provide
feedback on its systems, such as UI design, efficiency, inputs and outputs and
logistical problems. They should also have a basic understanding of how the final
product should work, such as programming or hardware.

Agile methods
Agile development methods place
emphasis on the team developing the
system rather than following predefined
structured development processes. Agile
methods remove the need for detailed
requirements and complex design
documentation, encouraging cooperation
and team work. They are particularly well
suited to web-based software development
and other software applications that are
modified regularly, evolving over time.
Typically small teams of developers are used
which are better able to share ideas and
work on solutions together. Larger teams
will tend to break into smaller groups but for
agile methods to be a success, members
should be equal with a clear shared
purpose.
For the agile approach, each part of the
software solution relies heavily on the other
related parts. Until the related parts are
created, much of the design will prove
unworkable and will need to be redesigned
or significantly altered.
One significant issue with agile methods is
how to construct agreements when
outsourcing the development without
detailed requirements.
The agile approach is only possible when
there are no detailed requirements while
most problems will occur when
implementing the solution.

Understanding the problem

Planning

Designing

Testing, evaluati

Imple

Understanding the problem

Testing, evaluating and maintainin

Requirements report
the requirements report that:
details the time frame

create Gantt charts to show the

implementation time frame

details the subprojects and the

time frame for them
identifies participants
identifies relevant information
technology
identifies data/information
identifies the needs of users

investigate/research new information

technologies that could form part of
the system

The requirements report should be updated when it is determined how the project will
be managed. Once a suitable development approach has been determined then
sufficient information is available to determine suitable techniques and strategies for
managing project development. The requirements report can be updated with
specifics in regard to the chosen solution and reflect the selected system
development approach.

Participants should be identified, in particular mechanisms for obtaining

feedback should be considered. This is not an issue for participant developed
solutions. When using agile methods consider including a knowledgeable system
participant on the team. Otherwise, regular sessions, meetings or other forms of
communication should be planned and documented to ensure that there is
ongoing, regular communication
Information technology for the new system should be identified including
hardware and software. It must be purchased or its development planned
The input of the new system is data while the output is information. It is likely
that some data will be sourced from another system while other data is entered
directly into the system by users. In either case sample or existing real data will
be needed for testing during the design and subsequent stages
Meeting the needs of users is the aim of successful information systems. For a
traditional system development approach these requirements will have already
been established while for other approaches, particularly iterative prototyping
and agile methods, user needs and requirements will emerge and affect the
progress of development

Designing
Building/creating the system
clarifying with users the benefits of
the new information system
designing the information system for
ease of maintenance
clarifying each of the relevant
information processes within the
system
detailing the role of the participants,
the data and the information
technology used in the system
refining existing prototypes
participant development, when
people within the information system
develop the solution
participant designed solutions
tools for participant development
such as guided processes in
application packages

develop a solution to a problem from

a prototype
use a guided process in an
application to create all or part of a
solution

The design process

The designing stage of the system development lifecycle (SDLC) is where the actual
design is designed and built. This includes describing the information processes
and specifying the system resources required to perform these.
The design process will differ accordingly to the system development approach used
however for all approaches system models are created, using tools such as context
diagrams, dataflow diagrams, decision trees and tables and storyboards. During the
modelling process, data and information produced and used by the system is
determined and clearly defined in the data dictionary. Once the processing and
data/information is understood, the information technology to perform these
processes can be accurately determined.
The information processes are the vital link between all the systems resources,
operating within the new system. Documenting the detail of such processes is
critical to all aspects of the design including hardware purchases. Consequently
detailed models of the solution should be produced.
User interfaces
When designing user interface for information systems, the design team should:

Know what the users goals, skills, experience and needs are
Maintain consistency within the system and other known applications
Make components/elements on all screens/windows readable including text and
logical placement
Clearly show all functions available
Allow for a reaction in the screen/window for every user action
Provide a way of cancelling out potentially dangerous changes

Refining existing prototypes

Existing prototypes can be refined such that they evolve into the final product. There
are a variety of different software applications that allow the user interface and
underlying processes to be easily modified to fulfil new and modified requirements. In
addition to actually building each prototype these applications should assist
developers to maintain different versions of the solutions and provide mechanisms to
easily revert to previous versions as required.
Ongoing user feedback is critical to the success of the prototyping approach. Many
prototyping tools include functions that simplify the creation of prototypes so they can
be easily delivered to and installed by users. For instance, a website that will connect
to an operational database can include a simulated sample database built using a file
based database management system which avoids the need to install database server
software.
Guided processes in application packages
Many software applications include wizards or assists that guide the user as they
perform common tasks. Initiating such as guided process is often the first step when
developing a system using the participant development (or end-user) approach.
Furthermore specific wizards can be initiated to build specific parts of the solution.

System design tools

tools used in designing, including:
context diagrams
data flow diagrams
decision trees
decision tables
data dictionaries
storyboards

use system design tools to:

better understand the system
assist in explaining the operation
of the new system
document the new system

Context diagrams
Context diagrams represent the entire system as a single process. They attempt to
identify the data entering and leaving the system along with its source and
destination (external entity or sink).

Data flow diagrams

Data flow diagrams (DFDs) describe the movement and changes in data between
processes. All processes alter data so the output from a process must be different in
some way to the inputted data. The aim of DFDs is to represent system by describing
the changes in data as it passes through processes.
A level 1 data flow diagram expands a
single process into multiple processes.
A series of level 2 DFDs are drawn to
expand upon each level 1 process into
further processes. A series of
progressively more detailed DFDs refine
the system into its components sub
processes. The lowest levels DFD
contain processes that can be solved
independently.

Decision trees
Decision trees are a tool for documenting the logic upon which decisions are made.
Decisions are made when one alternative is chosen from a range of possible
alternatives. In terms of information systems, each of these alternatives result in
some action or process being performed. Each rule is composed of one or more
conditions that must be satisfied for the rule to be true.

A condition is a factor that needs to be determined

A rule is a test that a condition needs to meet in order to carry out an action

An action is what must happens when a condition is tested

Decision trees represent the rules, conditions and actions as a diagram. In a decision
tree each unique left to right sequence of branches represents a rule which results in
an action.

Decision tables
Decision tables are also a tool for documenting the logic upon which decisions are
made, using a two dimensional table to represent rules, conditions and actions.

Data dictionaries
Data dictionaries are used to detail each of the data items used by system. They
are table where each row describes a particular data item and each column describe
an attribute (property) of the data item. The name or identifier for the data item must
be included together with a variety of other details including data, storage size and
description.

A data item can be a record on a database or spreadsheet

An attribute is a property or field of that record such as total cost and quantity

Often data dictionaries are associated with the design of database where they are
used to document details of each field. Common details include the field name, data
type, data format, field size and description. Data dictionaries are also used in

conjunction with many design tools such as being used to specify details of each data
flow used in context and data flow diagrams.

Storyboards
Storyboards are tools for designing the user interface within software. They
document the layout of elements on individual screens and the connections between
the screens. Storyboards are often hand drawn sketches of each screen showing the
placement of each screen element and its specific details.
Storyboards can also include a diagram (navigation map) that can show the
navigational links between screens, this is particularly valuable for hypermedia such
as websites and multimedia systems. The user interface is often designed when
generating a storyboard as it provides a means to refine a prototype as the storyboard
can show how the final system will look.

Implementing
The implementation plan
acquiring information technology and
making it operational
hardware
software, customised or developed
an implementation plan that details:
participant training
the method for conversion
- parallel conversion
- direct conversion
- phased conversion
- pilot conversion
how the system will be tested
conversion of data for the new
system

determine training needs arising from

the creation of a new system
compare and contrast conversion
methods
justify the selected conversion
method for a given situation
convert from the old system to the
new
implement the appropriate
information technology

Implementation of new system

In the implementation stage of the system development lifecycle, the new system is
installed and commences operation. There are various different methods for
performing this conversion as the old system ceases operation and is replaced with
the new system.
All people involved in the implementation of new information systems must be
organised so they complete their tasks in the correct sequence and at the correct
time. Many people and organisations are involved in the implementation of most new
information systems. This includes organisations that supply and deliver the
hardware, technicians who install communication and other hardware, the people
who install, configure and test the operation of the software, the participants and
trainers who teach the participants to use the new systems.
All underlying hardware should be set up first where the system will be operational
such as network ports, cabling and power supplies. Customised software can be preinstalled off-site or installed on-site.
The implementation plan is a project plan that identifies the tasks, people,
processes, timing and cost of the systems implementation. Factors that must be
considered in the implementation plan include:

How and when the participants are to be trained to operate the new system
The method of converting from the old system to the new system
How the system will be tested
Conversion of data for the new system
Implementing training for participants and users

Training ensures participants can use the new system and understand its benefits.
Training is also needed in the installation of a new system and to ensure that the
computer is being used efficiently.
Traditional group training sessions can occur on-site at a place of employment or
off-site at a training centre. The trainer can be a member of the system

development team or an outsourced specialist trainer. A member of the

development team would be a better choice if the software to be used has been
customised. An outsourced training specialist would be particularly useful if the
software has been purchased with little modification due to their intimate knowledge
of the software.
Peer training is often a one-to-one process where trained users are used to train
their peers. One or more users undergo intensive training in regard to the operation
and skills needed by the new system and how to train others to use the system. Then
the trained user is essentially an onsite expert who works alongside and assists
other users as they learn the skills to operate the new system. This method is less
costly than traditional group training session though ongoing training may lack indepth expertise of the new system. It also allows people to learn by their own means
or at their own pace.
Online training (such as tutorials) and help systems allow users to learn new skills at
their pace and as needed. It is common for larger systems to be provided with a
complete tutorial system which can involve detailed documents, videos and
demonstrations.
This method is becoming increasing popular as it is considered flexible and
manageable for users and participants. It is more suitable to the way that people live
their lives, able to be completed out of normal working hours which is an advantage
for people working from home.
Methods of conversion
The new system operates
concurrently with the old system
until the new system is fully
implemented.
At one point the old system is
replaced entirely by the new
system.

Parallel

Direct

Both systems run concurrently as

the new system gradually replaces
the old system.
A part of the new system operates
concurrently with the old system
until the new system is fully
implemented.

Phased

Pilot

Advantages and disadvantages of method for conversion

Method for
conversion

Advantages

Parallel

Direct

There is a backup to roll back

the system in case the new
system fails
Evaluating the system as it
operates
Saves money as two systems

Disadvantages

Cost of operating two systems

at the same time
Contending with updating and
maintaining data for two
systems at the same time
No backup available

Phased

arent run at the same time

Supposed to be a fast and
efficient method
Backup
One part of the system is
under testing and
troubleshooting at a time
Participants and users have
time to adapt to the new
system

Troubleshooting needs to be
done as the new system
operates
Cost of operating two systems
Data being shared
Transitioning can be confusing
or inconsistent

Pilot

Backup
Issues can be identified ahead
of time
Testing is more localised and
broken down; easier to
manage
Not as expensive as other
methods

Cost of operating two systems

Data being shared between
two systems at the same time

Operation manuals
the need for an operation manual
detailing procedures participants follow
when using the new system

develop an implementation plan for

the project

The need for an operation manual

The operation manual contains procedural information, similar to many online
tutorials and help systems, describing step-by-step instructions specific to the new
system. This can include detailed instructions on how to perform backups, how to add
a new customer account or how to return a product.
Manuals can be printed or online. Online manuals are becoming more popular than
paper-based manuals because they are easy to search and can involve a simulator of
the system.

Testing, evaluating and maintaining

Ensuring the system meets requirements
testing and evaluating the solution
with test data such as
volume data
simulated data
live data
checking to see that the original
system requirements have been
achieved

compare the new system to the old

and evaluate whether the requirements
have been met

Test data
Test data is any data used to test a systems operations according to its purpose.
There are three different types of data to test a system:

Volume data

Simulated
data
Live (or realtime) data

It is test data designed to ensure the system performs within

its requirements when processes are subjected to large
amounts of data in real time for certain circumstances
It tests the performance of systems under simulated
operational conditions such as when many users, connections
or different processes occur at the same time or in different
combinations
The actual data to be collected by the operational system
Ensures the system operates as expected once it has been
installed, such as being capable of dealing with errors
System testing

The process of acceptance testing is where formal testing is carried out on systems
to ensure that the requirements outlined in the requirements report are actually met.
Acceptance testing uses the three types of test data.
Acceptance testing is usually outsourced for large systems though outsourcing can
be effective for any other system. Acceptance testing would be outsourced as there
would be less bias in the process and results will be more objective.

Ongoing evaluation to monitor system performance

trialling and using the operation
manual
reviewing the effect on users of the
information system, participants and
people within the environment
modifying parts of the system where
problems are identified

update system documentation

The operation manual

The operation manual describes all the procedures that participants should follow
when using the new system. These procedures should be made up of step-by-step
instructions for each task to be performed along with decisions which should be
accomplished when the procedure is carried out.

The operation manual is known by a development team as procedural

documentation. It should be easy to read and understand and be supplied with a
new system in order to avoid confusion associated with operations.
The operation manual can be either paper-based or online. An online manual should
be interactive and accessible from anywhere within the system as an integrated
application or separate application.
The operation manual should instruct users on:

What a given task is and why it is required

How the task will relate to other tasks
Who will perform each task and who is responsible for them
When the task should be completed
How to complete the task
Maintenance of the system

Maintenance is the modification of the system by making minor improvements.

During the operation of the system, participants may discover deficiencies in the
system and suggest improvements.
Maintenance may also involve installing new hardware and upgrading software
packages. The longer the system has been operational, the more difficult it is to
change. However, good documentation makes it easier to undertake maintenance
without causing problems elsewhere. Simple changes in a large information system
are often complex to implement and require retesting of other parts of the system
which often results in restarting the system development cycle.
A financial performance evaluation of a systems performance assesses if the
system is performing to a point where there will be a positive return on investment,
paying itself off through its current performance. This evaluation should also consider
management costs, comparing the costs of maintenance to the projected benefits of
the system.
The purpose of a technical performance evaluation is monitor the continuing
achievement of a systems evolving requirements. These technical requirements need
to keep up with the changing demands of the system, hence an evaluation is
needed to help monitor these changes. The frequency of these changes vary
according to the system, from daily to every few years. For example, the requirements
of data storage systems will change daily while the demands of point-of-sale systems
can change weekly or monthly. In contrast, the requirements of a library system
should not change often unless its data collection method is altered.
Technical performance evaluations will be more relevant to systems whose
requirements change often such as financial or stock markets. An evaluation should
consider:

The amount of data in the system: generally as the amount of data in a

system increases, the speed of storage and retrieval decreases
The number of data transactions carried out by the system: generally the
more transactions carried out by the system, the system becomes less
responsive and prompt

The user experience: once users become more experienced with the system,
they will generally not tolerate poor performance and/or functionality issues