WEEK 1 INFORMATION SYSTEM PROJECT MANAGEMENT

Expected Learning Outcomes/Specific Objectives:

By the end of this topic, the trainee should be able to:-
 explain the meaning and importance of information system project management
 describe information system project management techniques/tools
 explain the signs of a failing information systems project
 explain the cause of information system project failure
 explain the control measures and techniques of a failing information system

INFORMATION SYSTEM PROJECT MANAGEMENT

Project Management

A project can be defined as a temporary sequence of unique, complex and connected activities
having one goal or purpose and that must be completed by specific time, within budget and
according to specification. It is a planned undertaking that has a beginning and an end and that
produces a predetermined result or product. Every project is constrained by its scope, time goals
and cost goals.
Projects have the following characteristics:
a) Unique purpose – a project is undertaken to fulfil a specific objective
b) Temporary – projects exists for a limited duration of time; often not perpetual
c) Requires resources – such as money, manpower and machine resources
d) Should have a primary sponsor – usually an organization, a department or individual
e) Involves uncertainty – a great deal of the project implementation is unknown therefore need
for planning and management

The key competencies that project managers must develop are known as knowledge areas and
include:

 Scope management
 Time management
 Cost management
 Quality management
 Human resources management
 Communications management
 Risk management
 Procurement management and
 Integration management

The project stakeholders are the people involved in or affected by project activities (including
project sponsor, project team, support staff, customers, users, suppliers and even opponents to the
project).

A project life cycle is a collection of project phases, which includes:

1. Concept
2. Development

1
 3. Implementation
4. Close-out

The first two phases relate to project feasibility and the last two phases focus on delivering the work
and are often called project acquisition.

It is important not to confuse project life cycle with product life cycle. The project life cycle applies
to all projects regardless of the products being produced. On the other hand product life cycle
models vary considerably based on the nature of the product. For information systems a systems
development life cycle (SDLC) is used. SDLC is a framework for describing the phases involved in
developing and maintaining information systems.

Measures of project success

A project is successful when:

 The resulting information system is acceptable to the customer

 The system is delivered on time
 The system is delivered within budget
 The system development process has a minimal impact on ongoing business operations

Causes of project failures

 Failure to establish top-management commitment to the project
 Lack of organization’s commitment to the system development methodology
 Taking shortcuts through or around the system development methodology
 Poor expectations management
 Premature commitment to a fixed budget and schedule
 Poor estimating techniques
 Over-optimism
 Inadequate people management skills
 Failure to adapt to business changes
 Insufficient resources
 Failure to manage the plan

SYSTEMS PLANNING
Involves:

(i) Project identification and selection i.e. high level planning

(ii) Project initiation and planning i.e. low level planning
Project identification and selection
(i) Identify potential development projects

Sources of projects includes:

 Management and business units

 Managers who want to make a system more efficient or less costly
 Formal planning groups

Projects are identified by:

2
  Steering committees
 Top management
 User departments
 Development group or senior information systems staff

Top-down identification focuses on global needs of the organization and is usually done by top
management or steering committees while bottom-up identification usually done by business
unit or information system group doesn’t reflect overall goals of the organization.

(ii) Classify and rank projects

This process is performed by top management, steering committee, business units or
information systems development group. Value chain analysis is often used. This is a method
to analyze an organization’s activities to determine where value is added and costs are incurred.

(iii) Select projects

This is the process of considering short and long-term projects. Projects most likely to achieve

business objectives are selected. Decision requires consideration of:

 Perceived and real needs

 Potential and ongoing projects
 Current organizational environment
 Existing and available resources
 Evaluation criteria
 Outcomes
Project Initiation and Planning
Project planning and initiation involves:

 Team organization
 Establishing management procedures
 Identifying scope – Scope defines the boundaries of a project – what part of the business is
to be studied, analyzed, designed, constructed, implemented and ultimately improved?
 Identifying alternatives
 Feasibility/risk analysis and strategic assessment
Feasibility is the measure of how beneficial or practical the development of an information
system will be to an organization. Feasibility analysis is the process by which feasibility is
measured.

Risk analysis help understand and manage uncertainty. There is need to assess probability,
assess impact and establish contingency plan.

 Estimation – Estimation of resources, such as human effort, time and cost. Estimation is
extremely difficult and (usually) inaccurate.
 Cost/benefit analysis
o Costs
 Development costs are one-time costs that will not recur after the project has
been completed e.g. systems development, hardware/software, user
training, site preparation and data conversion.

3
  Operating costs are costs that tend to recur throughout the lifetime of the
system. E.g. maintenance, data storage expenses, communications expenses,
software licenses. Such costs can be classified as:
- Fixed costs – occur at regular intervals but at relatively fixed rates
- Variable costs – occur in proportion to some usage factor
o Benefits
 Tangible benefits are those that can be easily quantified e.g. cost reduction,
error reduction, increased sales
 Intangible benefits are those benefits believed to be difficult or impossible to
quantify e.g. improved planning and control, improved employee morale,
improved decision making
o Constraints
 Schedule e.g. project must be completed before a certain set date
 Costs e.g. the system cannot cost more than 1m
 Technology e.g. the system must be online, use MS Access database and run
on a Windows platform
 Policy e.g. the system must use double-entry accounting
 Scheduling – Usually use of Gantt charts and PERT/CPM methods (Performance
Evaluation and Review Technique/ Critical Path Method). The tools are not mutually
exclusive (especially when PERT is based on “activity on node” conventions). That is why
most project management software tools maintain both views simultaneously.

PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method)
A PERT chart is a graphical network model that depicts a project’s tasks and the relationships
between those tasks. It was developed in the late 1950’s to plan and control large weapons
development projects for the US Navy. It is a project management tool used to schedule, organize,
and coordinate tasks within a project. PERT depicts task, duration, and dependency information.

Critical Path Method (CPM), which was developed for project management in the private sector at
about the same time, has become synonymous with PERT, so that the technique is known by any
variation on the names: PERT, CPM, or CPM/PERT.

Diagram Symbols
Activity (task to be carried out in the project)
Earliest Time

Event no.

Latest Time

X Y

Task X must be completed before task Y can start

4
 X

Tasks X and Y must be completed before Z can start

Z is a dummy activity; it is represented by a dotted line, it is

required to avoid activities having the same head and tail
events.

Y Z

CPM

CPM provides the following benefits:

 Provides a graphical view of the project.
 Predicts the time required to complete the project.
 Shows which activities are critical to maintaining the schedule and which are not.

CPM models the activities and events of a project as a network. Activities are depicted as nodes on
the network and events that signify the beginning or ending of activities are depicted as arcs or
lines between the nodes. The following is an example of a CPM network diagram:

Activity Listing
Activity Precedence Duration (Weeks)
A - 2
B - 3
C A 1
D A 3
E B 3
F B 4
G C 3
H G 1
I D, E 2
J F 2

5
 Network Diagram

C G

A 1

D 3 H

2 1
Start 3 I

2
E
B Finish
3 J
3
F

Steps in CPM Project Planning

1. Specify the individual activities.

2. Determine the sequence of those activities.
3. Draw a network diagram.
4. Estimate the completion time for each activity.
5. Identify the critical path (longest path through the network)
6. Update the CPM diagram as the project progresses.

1. Specify the Individual Activities

From a work breakdown structure, a listing can be made of all the activities in the project. This
listing can be used as the basis for adding sequence and duration information in later steps.

2. Determine the Sequence of the Activities

Some activities are dependent on the completion of others. A listing of the immediate predecessors
of each activity is useful for constructing the CPM network diagram.

3. Draw the Network Diagram

Once the activities and their sequencing have been defined, the CPM diagram can be drawn. CPM
originally was developed as an activity on node (AON) network, but some project planners prefer to
specify the activities on the arcs.

4. Estimate Activity Completion Time

The time required to complete each activity can be estimated using past experience or the estimates
of knowledgeable persons. CPM is a deterministic model that does not take into account variation
in the completion time; so only one number is used for an activity's time estimate.

6
5. Identify the Critical Path
The critical path is the longest-duration path through the network. The significance of the critical
path is that the activities that lie on it cannot be delayed without delaying the project. Because of
its impact on the entire project, critical path analysis is an important aspect of project planning.

The critical path can be identified by determining the following four parameters for each activity:

 EST - earliest start time: the earliest time at which the activity can start given that its
precedent activities must be completed first.
 EFT - earliest finish time, equal to the earliest start time for the activity plus the time
required to complete the activity.
 LFT - latest finish time: the latest time at which the activity can be completed without
delaying the project.
 LST - latest start time, equal to the latest finish time minus the time required to complete
the activity.

Slack is the amount of time that an activity can be delayed past its earliest start or earliest finish
without delaying the project. .The slack time for an activity is the time between its earliest and latest
start time, or between its earliest and latest finish time.

The critical path is the path through the project network in which none of the activities have slack,
that is, the path for which EST=LST and EFT=LFT for all activities in the path. A delay in the critical
path delays the project. Similarly, to accelerate the project it is necessary to reduce the total time
required for the activities in the critical path.

ES
Convention: Where N is node (activity) number
N
ES – Earliest Event Start Time
LS LS – Latest Event Start Time

C
G
V
2 3
1 3
1 3 6
4 5
5
A H
8
2
D 1

3 I 9
0
6 7
0
4 9
0 2
E 7
J
B 3
3 F 7
2 2
3 6
3
7
4

Critical Path: BFJ

7
 6. Update CPM Diagram

As the project progresses, the actual task completion times will be known and the network diagram
can be updated to include this information. A new critical path may emerge, and structural changes
may be made in the network if project requirements change.

CPM Limitations

a) CPM was developed for complex but fairly routine projects with minimal uncertainty in the project
completion times. For less routine projects there is more uncertainty in the completion times, and
this uncertainty limits the usefulness of the deterministic CPM model. An alternative to CPM is the
PERT project-planning model, which allows a range of durations to be specified for each activity.
Complex projects require a series of activities, some of which must be performed sequentially and
others that can be performed in parallel with other activities. This collection of series and parallel
tasks can be modeled as a network.

In 1957 the Critical Path Method (CPM) was developed as a network model for project
management. CPM is a deterministic method that uses a fixed time estimate for each activity.
b) While CPM is easy to understand and use, it does not consider the time variations that can have a
great impact on the completion time of a complex project.

The Program Evaluation and Review Technique (PERT) is a network model that allows for randomness
in activity completion times. PERT was developed in the late 1950's for the U.S. Navy's Polaris
project having thousands of contractors. It has the potential to reduce both the time and cost
required to complete a project.

The Network Diagram

In a project, an activity is a task that must be performed and an event is a milestone marking the
completion of one or more activities. Before an activity can begin, all of its predecessor activities
must be completed. Project network models represent activities and milestones by arcs and nodes.
PERT originally was an activity on arc network, in which the activities are represented on the lines
and milestones on the nodes. Over time, some people began to use PERT as an activity on node
network. For this discussion, we will use the original form of activity on arc.

The PERT chart may have multiple pages with many sub-tasks.

The milestones generally are numbered so that the ending node of an activity has a higher number
than the beginning node. Incrementing the numbers by 10 allows for new ones to be inserted
without modifying the numbering of the entire diagram. The activities in the above diagram are
labeled with letters along with the expected time required to complete the activity.

Steps in the PERT Planning Process

PERT planning involves the following steps:

1. Identify the specific activities and milestones.

2. Determine the proper sequence of the activities.

8
 3. Construct a network diagram.
4. Estimate the time required for each activity.
5. Determine the critical path.
6. Update the PERT chart as the project progresses.

1. Identify Activities and Milestones

The activities are the tasks required to complete the project. The milestones are the events marking
the beginning and end of one or more activities. It is helpful to list the tasks in a table that in later
steps can be expanded to include information on sequence and duration.

2. Determine Activity Sequence

This step may be combined with the activity identification step since the activity sequence is
evident for some tasks. Other tasks may require more analysis to determine the exact order in which
they must be performed.

3. Construct the Network Diagram

Using the activity sequence information, a network diagram can be drawn showing the sequence
of the serial and parallel activities. For the original activity-on-arc model, the activities are depicted
by arrowed lines and milestones are depicted by circles or "bubbles".
If done manually, several drafts may be required to correctly portray the relationships among
activities. Software packages simplify this step by automatically converting tabular activity
information into a network diagram.
4. Estimate Activity Times
Weeks are a commonly used unit of time for activity completion, but any consistent unit of time
can be used.
A distinguishing feature of PERT is its ability to deal with uncertainty in activity completion times.
For each activity, the model usually includes three time estimates:

 Optimistic time - generally the shortest time in which the activity can be completed. It is
common practice to specify optimistic times to be three standard deviations from the mean
so that there is approximately a 1% chance that the activity will be completed within the
optimistic time.
 Most likely time - the completion time having the highest probability. Note that this time is
different from the expected time.
 Pessimistic time - the longest time that an activity might require. Three standard deviations
from the mean are commonly used for the pessimistic time.

PERT assumes a beta probability distribution for the time estimates. For a beta distribution, the
expected time for each activity can be approximated using the following weighted average:
Expected time = (Optimistic + 4 x Most likely + Pessimistic) / 6
This expected time may be displayed on the network diagram.

To calculate the variance for each activity completion time, if three standard deviation times were
selected for the optimistic and pessimistic times, then there are six standard deviations between
them, so the variance is given by:
[(Pessimistic - Optimistic) / 6] 2

9
5. Determine the Critical Path
The critical path is determined by adding the times for the activities in each sequence and
determining the longest path in the project. The critical path determines the total calendar time
required for the project.

If activities outside the critical path speed up or slow down (within limits), the total project time
does not change. The amount of time that a non-critical path activity can be delayed without
delaying the project is referred to as slack time.

If the critical path is not immediately obvious, it may be helpful to determine the following four
quantities for each activity:

 EST - Earliest Start time

 EFT - Earliest Finish time
 LST - Latest Start time
 LFT - Latest Finish time

These times are calculated using the expected time for the relevant activities. The earliest start and
finish times of each activity are determined by working forward through the network and
determining the earliest time at which an activity can start and finish considering its predecessor
activities. The latest start and finish times are the latest times that an activity can start and finish
without delaying the project. LS and LF are found by working backward through the network. The
difference in the latest and earliest finish of each activity is that activity's slack. The critical path
then is the path through the network in which none of the activities have slack.

The variance in the project completion time can be calculated by summing the variances in the
completion times of the activities in the critical path. Given this variance, one can calculate the
probability that the project will be completed by a certain date assuming a normal probability
distribution for the critical path. The normal distribution assumption holds if the number of
activities in the path is large enough for the central limit theorem to be applied.

Since the critical path determines the completion date of the project, the project can be accelerated
by adding the resources required to decrease the time for the activities in the critical path. Such a
shortening of the project sometimes is referred to as project crashing.

6. Update as Project Progresses

Make adjustments in the PERT chart as the project progresses. As the project unfolds, the estimated
times can be replaced with actual times. In cases where there are delays, additional resources may
be needed to stay on schedule and the PERT chart may be modified to reflect the new situation.

Benefits of PERT

PERT is useful because it provides the following information:

 Expected project completion time.

 Probability of completion before a specified date.
 The critical path activities that directly impact the completion time.
 The activities that have slack time and that can lend resources to critical path activities.
 Activity start and end dates.
10
 Limitations
The following are some of PERT's weaknesses:

 The activity time estimates are somewhat subjective and depend on judgment. In cases
where there is little experience in performing an activity, the numbers may be only a guess.
In other cases, if the person or group performing the activity estimates the time there may
be bias in the estimate.
 Even if the activity times are well estimated, PERT assumes a beta distribution for these
time estimates, but the actual distribution may be different.
 Even if the beta distribution assumption holds, PERT assumes that the probability
distribution of the project completion time is the same as that of the critical path. Because
other paths can become the critical path if their associated activities are delayed, PERT
consistently underestimates the expected project completion time.

The underestimation of the project completion time due to alternate paths becoming critical is perhaps the
most serious of these issues. To overcome this limitation, Monte Carlo simulations can be performed on the
network to eliminate this optimistic bias in the expected project completion time.

Gantt Chart
A Gantt chart is a simple horizontal bar chart that depicts project tasks against a calendar. Each bar
represents a named project task. The tasks are listed vertically in the left hand column. The
horizontal axis is a calendar timeline. The Gantt chart was first conceived by Henry L. Gantt in
1917, and is the most commonly used project scheduling and progress evaluation tool.

Gantt charts give a clear, pictorial model of the project. They are simple and require very little
training to understand and use. They show progress and can be used for resource planning. They
also show interrelationships and critical path.

Gantt Chart Methodology

 List vertically all tasks to be performed
 Tasks identified by number and name
 Horizontally indicate duration, resources and any other relevant information
 Graphical part shows horizontal bar for each task connecting start and end duration
 Relationships can be shown by lines joining tasks – can make diagram

Example of a Gantt Chart (File conversion)

Weeks 0 5 8 10 11 16

Write Conversion Program

Test Conversion Program

Convert Files

Prepare Training

Conduct Training

11
Run Parallel Systems
Different approaches to system development are:

1. System Development Life Cycle (SDLC)

2. Structured Systems Analysis Design Methodology (SSADM) – Data driven methodology
3. Prototyping Method – User driven method
4. Rapid Application Development (RAD)

Symptoms of a failing project

1. Increased or high maintenance costs

2. Frequent system failures

Additional causes of computer project failures

1. Poor planning and/or lack of adequate management. A lot of planning and preparation needs
to be done. The larger and more complex the system is the more planning is required. The
management must take control of planning, defining system objectives and monitoring
progress. The decision to computerize is a management decision. The management should
prepare the staff to accept computerization as it is sometimes feared or resisted.
2. Inadequate systems specification. An organization must define what it expects the computer
systems to achieve, based on its business requirements.
3. Lack, poor, or inadequate documentation. This is a major source of system failures.
4. Technical causes

Project Manager a.k.a. Project Team Leader. Definition:

1. This is a person responsible for overseeing the planning, costing, scheduling and team
organization of a project.

2. This is a senior analyst who uses planning, staffing, organizing, scheduling, directing, and
controlling skills to ensure the success of a project.

Basic functions of the Project Manager (system analyst).

a) Planning project tasks & staffing the project team.

A good manager always has a plan:-

 Each task required to complete the project must be planned.

 The following are other planning issues.

a) How much time will be required?

b) How many people will be needed?
c) How much will the task cost?
d) What tasks must be completed before other tasks are started?
e) Can some of the tasks overlap?
 The project manager should carefully consider the business and technical expertise that may
be needed to successfully finish the project.
12
  The key is to match the personnel to the required tasks that have been identified as part of
project planning.

b) Directing & controlling the project

 Once a project has begun, the project manager becomes a supervisor.

 As a supervisor, the project manager directs the team’s activities, monitor and evaluates
progress to check that the information development project is on time and within budget.
 Supervise the work to ensure that it is carried out to the required standards.
 Every project manager must demonstrate such people management skills as motivating,
advising, coordinating, delegating, and appraising team members.
 Perhaps the manager’s most difficult and important function is controlling the project.
- The project manager’s job is to monitor tasks, schedules, costs and expectations in order
to control those elements.
- The project manager must evaluate the present alternatives and their implications for the
budget and schedule in order to manage expectations.

Work Breakdown Structure

- A project starts out as a statement of work (SOW). The SOW may be a written description of the
objectives to be achieved, with a brief SOW to be done and a proposed schedule specifying the
start and completion dates. It could also contain performance measures in terms of budget and
completion steps (milestones) and the written reports to be supplied.
- A task is a further subdivision of a project. It’s usually not longer than several months in
duration and is performed by a project team/group or organization. A subtask may be used if
needed to further subdivide the project into more meaningful pieces.
- A work package is a group of activities combined to be assignable to a simple organizational
unit. It still falls into the format of all project management. The package provides a description
of what is to be done, when it is to be started and completed, the budget measures of
performance, and specific events to be reached at points in time.
- These specific events are called project milestones.

Examples of typical milestone:

(a) Completion of the design

(b) Production of a prototype
(c) Completed testing of the prototype and
(d) Approval of a plot run.

- The work breakdown structure (WBS) defines the hierarchy of project tasks, subtasks and work
packages. Completion of one or more work packages results in the completion of a subtask;
completion of one or more subtasks results in the completion of a task; and finally, the
completion of all tasks is required to complete the project.

- The work breakdown structure (WBS) is important in organizing a project because it breaks the
project down into manageable pieces.

13
- There is not a single correct WBS for any project, and two different project teams might develop
different WBSs for same project. Some experts have referred to project management as an art
rather than a science because there are so many ways that a project can be approached. Finding
the correct way to organize a project depends on experience with the particular task.

- Activities – are pieces of work that consume time. Activities do not necessarily require the
expenditure of effort by people, although they often do. Example, waiting for paint to dry,
waiting for respondents to respond to questionnaires may be an activity in a project. Activities
are identified as part of Work Breakdown Scheme (WBS). Activities need to be defined in such
a way that when they are all completed, the project is done.

Project Management Info Systems (PMIS) /Projects management software

1. Microsoft Project
2. Microsoft Visio
3. Primavera Project Planner, visit http://www. Primavera.com
4. Time Line
5. Milestone
6. Project Scheduler
7. Schedule Publisher
8. Texim Project.

Microsoft Project

 Microsoft project is a project planning software used to construct structured project planning
charts. This s/ware greatly simplify the preparation of the project management models such as
Gantt and PERT charts
 These models & techniques would be difficult to apply without s/ware assistance e.g. Microsoft
Project
 Today, project management s/ware is routinely used to help project manager’s plan projects,
develop schedules, develop budgets, monitor progress, costs, and generate management
reports.
 It comes with an excellent online tutorial, which is one reason for its overwhelming popularity
with project managers tracking midsized projects. This package aids in scheduling, allocating,
and levelling resources, as well as controlling costs and producing presentation-quality graphics
and reports.

Project planning

A plan, drawn up at the start of a project, should be used as the driver/map for the project. Project
planning is an iterative process which is only complete when the project itself is complete. As project
info becomes available during the project, the plan must be regularly revised. The overall goals of
the organization are an important factor which must be considered when formulating the project
plan. As these change, changes to the project plan are necessary.

Planning process starts with an assessment of the constraints (required delivery date, staff available,
overall budget etc.) affecting the project. This is carried out in conjunction with an estimation of
project parameters like its size, structure and distribution of functions. The project milestones and
deliverables are then defined. A schedule for the project is drawn up and the activities defined in

14
the schedule are initiated or given permission to continue. After some time (usually about 2-3
weeks), progress is reviewed and discrepancies noted. As the initial estimates of project parameters
are tentative, the plan will always need to be modified.

The project plan

It sets out the resources available to the project, the work breakdown and schedule for carrying out
the work. Note: Details of the project plan vary depending on the type of project and organization.
However, most project plans should include the following sections:-

1. Introduction – Describes objectives of the project and sets out the constraints (e.g. budget, time
etc.) which affect the project management.
2. Project organization – Describes the way in which the development team is organized, the
people involved and their roles in the plan.

3. Risk analysis – Describes possible project risks, the likelihood of these risks arising and the risk
reduction strategies which are proposed.
4. Hardware and software resources requirements – Describes the h/ware and the support s/ware
required to carry out the info system development project. If h/ware has to be bought, estimates
of the prices and the delivery schedule should be included.
5. Work breakdown – Describes the breakdown of the project into activities and identifies the
milestones and deliverables associated with activity.
6. Project schedule – Describes the dependencies btw activities, the estimated time required to
reach each milestone and the allocation of people to activities.
7. Monitoring and reporting mechanisms – Describes the management reports which should be
produced, when they should be produced and the project monitoring mechanisms used.
The project plan should be regularly revised during the project. Some parts e.g. project schedule,
will change frequently, while others will be more stable.

Milestones

When planning a project, a series of milestones should be established, where a milestone is an end-
point of a software/system. At the end of each milestone, there should be a formal output, such as
a report, that can be presented to the management. Milestone reports need not be large documents.
They may simply be a short report of achievements in project activity. Milestones should represent
the end of a distinct, logical stage in the project. Note: Indefinite milestones like ‘coding 80%
complete’ which is impossible to validate are useless for project management. To establish
milestones the software/system development process must be broken down into basic activities
with associated outputs.

Deliverables

1. Any of the software, documentation, procedures, user manuals, or training sessions that a
systems analyst delivers to a client based on specific contractual promises.

2. A deliverable is a project result that is delivered to the customer. It is usually delivered at the
end of some major project phase such as specification, design etc.
15
Note: Deliverables are usually milestones but milestones need not be deliverables. Milestones may
be internal project results that are used by the project manager to check project progress, but which
are not delivered to the customer.

Project scheduling

System/software managers estimate the time and resources required to complete activities and
organize them in a coherent sequence. System/software scheduling is no different from scheduling
any other type of advanced project. New aircraft, bridges, and even new models of cars are often
late because of unanticipated problems. Schedules must therefore be continually updated as better
progress information becomes available.

Project scheduling involves separating the total work involved in a project into separate activities
and judging the time required to complete these activities. Some of these activities are carried out
in parallel. Project schedulers must coordinate these parallel activities and organize the work so that
the workforce is used optimally. They must avoid a situation where the whole project is delayed
because a critical task is unfinished.

The project schedule is usually represented as a set of charts showing the work breakdown,
activities, dependencies and staff allocations. System/software management tools e.g. Microsoft
Project are used to automate charts production.

Risk management

Identifying risks and drawing up plans to minimize their effect on the project. You can think of a
risk as a probability that some adverse circumstance will actually occur. Risks may threaten the
project schedule, quality of the system/software that is being developed or the organization.

An important task of the project manager is to anticipate risks which might affect the project and
take action to avoid these risks. The processes of doing that is called project risk management.

3 categories of risks

1. Project risks – affect the project schedule or resources.

2. Product risks – affect the quality or performance of the system/software being developed.
3. Business risks – affect the organization developing or procuring the system/software.
Note: This is not an exclusive classification. If an experience programmer or analyst leaves a
project this can be a project risk.

The project manager should anticipate risks, understand the impact of these risks on the project,
the product and the business and take steps to avoid these risks or minimize their impact.
Contingency plans may be drawn up so that, if the risks do occur, immediate recovery action is
possible.

Stages of risk management process

1. Risk identification – possible project, product and business risks are identified.
2. Risk analysis – The likelihood and consequences of these risks are assessed.
3. Risk planning – plans to address the risk either by avoiding it or minimizing its effects on the
project are drawn.
4. Risk monitoring – The risk is constantly assessed and plans for risk mitigation are revised as
more information about the risk becomes available.
16
Risk management process like all other planning is an interactive process which continues
throughout the project. The risk avoidance and contingency plans may be modified as new risk
information emerges. The results of the risk management process should be documented in a risk
management plan. Where possible it should include a discussion of the risks faced by the project,
an analysis of these risks and plans which are required to manage these risks. It may also include
some results of the risk management i.e. specific contingency plans to be activated if the risk occurs.

Risk identification

It Is the first step in risk management. It’s concerned with discovering/identifying possible risks to
the project. It may be carried out as a team process using a brainstorming approach or may simply
be based on a manager’s experience.

Types of risks

1. Technology risk – risks which arise from the software or hardware technologies which are used
as part of the system being developed.
2. People risks – risks associated with people in the development team.
3. Organizational risks – risks which arise from the organizational environment where the
software is being developed.
4. Tools risk - risks which arise from the CASE tools and other support system/software used to
develop the system.
5. Requirements risks - risks which arise from changes to the customer requirements and the
process of managing the requirements change.
6. Estimation risks - risks which arise from the management estimates of the system characteristics
and the resources required to build the system.

Risk analysis

Each identified risk is considered in turn and a judgement made about the probability and the
seriousness of the risk. The probability might be assessed as very low (<10%), low (10 - 25%),
moderate (25 - 50%), high (50 - 75%) or very high (> 75%). The effects of the risk might be assessed
as catastrophic, serious, tolerable or insignificant.

Once the risk has been analyzed and ranked, a judgement must then be made about which are the
most important risks which must be considered during the project. This judgement must depend
on a combination of the probability of the risk arising and the effects of that risk. In general, all
catastrophic risks should always be considered, as should all serious risks which have more than a
moderate probability of occurrence. The number of risk chosen should be manageable. Start with
ones with catastrophic and serious consequences. Otherwise a large number of risks considered
would simply require too much information to be collected.

Risk planning

Risk planning process considers each of the key risks which have been identified and identifies
strategies to manage the risk. Again, there is no simple process which can be followed to establish
risk management plans. It relies on the judgment and experience of the project manager.
17
Strategies to manage risk

1. Avoidance strategies – Following these strategies means that the probability that the risk will
arise will be reduced e.g. the strategy of dealing with defective components i.e. repairing them.

2. Minimization strategies - Following these strategies means that the impact of the risk will be
reduced e.g. the strategy of staff illness.

3. Contingency plans - Following these strategies means that, if the worst happens, you are
prepared for it and have a strategy in place to deal with it e.g. the strategy for organizational
financial problem.

Risk monitoring

Involves regularly assessing each of the identified risks to decide whether or not that risk is
becoming more or less probable and whether the effects of the risk have changed. It should be a
continuous process and at every management progress review, each of the key risks should be
considered separately and discussed by the meeting.

Challenges facing information systems development projects

1. Team building
2. Expected and unexpected problems
3. Delayed benefits
4. Conflicts amongst team members
5. Lack of adequate resources; specialists, finances etc.
6. Poor leadership and mismanagement
7. Dynamism of ICT sector

18