Sri Vidya College of Engineering & Technology Lecturer Notes

Unit -III
3.1 Objectives- Project Schedule
Introduction:
- Activity – Action
- A detailed plan for the project , includes a schedule indicating the start and completion
times for each activity
- By doing this,
o The appropriate resources will be available when required
o Avoid different activities competing for the same resources at the same time
o Produce detailed schedule showing which staff carry out each activity
o Produce a detailed plan to measure the actual achievement
- To be effective a plan must be designed as set of targets, so that the achievements and
non- achievements can be measured.
- Activity plan provide this by providing target start and completion date for each activity
- Using this activity planning, we must ensure that the project activities produces
deliverable product
- Also, Monitoring the project is an important part
- E.g.) Building the House
o Activity 1: Landscaping (Site) the lot
 Task1.1: Clearing and grubbing
 Task 1.2: Seeding the Turf
 Task 1.3: Planting shrubs and trees
o Activity 2: Building the House
 Activity 2.1 : Site preparation
 Activity2.2:Building the exterior
 Activity2.3:Finishing the interior
o Activity 2.1 : Site preparation
 Task 2.1.1: Surveying
 Task 2.1.2: Obtaining permits
 Task 2.1.3: Excavating
 Task 2.1.4: Obtaining materials
o Activity 2.2: Building the exterior
 Task 2.2.1: Foundation
 Task 2.2.2: Outside Walls
 Task 2.2.3: Exterior plumbing
 Task 2.2.4: Exterior electrical work
 Task 2.2.5: Exterior siding
 Task 2.2.6: Exterior painting
 Task 2.2.7: Doors and Fixtures
 Task 2.2.8: Roof
o Activity 2.3 : Finishing the Interior
 Task 2.3.1: Interior plumbing
 Task 2.3.2: Interior electrical work
 Task 2.3.3: Wallboard
 Task 2.3.4: Interior painting
 Task 2.3.5: Floor covering
 Task 2.3.6: Doors and fixtures
IT2403/Software Project Management
Sri Vidya College of Engineering & Technology Lecturer Notes

The objectives of activity planning

• Feasibility assessment
Is the project possible within required timescales and resource constraints? It is not until
we have constructed a detailed plan that we can forecast a completion date with any
reasonable knowledge of its achievability.
The fact that project may have been estimated as requiring two years might not mean that
it would be feasible to complete it within three months were eight people to work on it – It
will depend on the availability of staff and which the degrees to which activity may be
undertaken in parallel.
• Resource allocation
What are the most effective ways of allocating resources to the project. When should the
resources be available? The project plan allows us to investigate the relationship between
timescales and resource availability
- Identify the resources needed for each activity
- These include
 labour
 equipment (e.g. workstations)
 materials
 space
 services
• Detailed costing
How much will the project cost and when is that expenditure likely to take place? After
producing an activity plan and allocating specific resources, we can obtain more detailed
estimates of costs and their timing.
• Motivation
Providing targets and being seen to monitor achievement against targets is an effective
way of motivating staff, particularly where they have been involved in setting those targets in
the first place.
 Co-ordination
When do the staff in different departments need to be available to work on a
particular project and when do staff need to be transferred between projects? The project
plan, particularly with large projects involving more than a single project team, provides an
effective vehicle for communication and coordination among teams.
Activity planning and scheduling techniques place an emphasis on completing the project in
a minimum time at an acceptable cost or, alternatively, meeting a set target date at minimum cost
One effective way of shortening project durations is to carry out activities in parallel.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Project schedule:
• A stage of a larger project, the project plan must be developed to the level of showing dates
when each activity should start and finish and when and how much of each resource will be
required. Once the plan has been refined to this level of detail we call it a project schedule
• Creating a project schedule comprises four main stages.

First step
• step in producing the plan is to decide what activities need to be carried out and in what order
they are to be done_ From this we can construct an ideal activity plan — that is, a plan of
when each activity would ideally be undertaken were resources not a constraint
• This activity plan is generated by Steps 4 and 5 of Step Wise

Second step
• The ideal activity plan will then be the subject of an activity risk analysis, aimed at
identifying potential problems. This might suggest alterations to the ideal activity plan and
will almost certainly have implications for resource allocation.

Third step
• This is resource allocation. The expected availability of resources might place constraints on
when certain activities can be carried out

Final step
• The final step is schedule production. Once resources have been allocated to each activity,
we will be in a position to draw up and publish a project schedule, which indicates planned
start and completion dates and resource requirements statement for each activity.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

3.2 Sequencing and Scheduling Activities

Defining activities
some assumptions that will be relevant when we start to produce an activity plan.
• Activities must be defined so that they meet these criteria.
• Any activity that does not meet these criteria must be redefined.
• A project is composed of a number of interrelated activities. A project may start when at least
one of its activities is ready to start.
• A project will be completed when all of the activities it encompasses have been completed.
• If an activity must have a clearly defined start and a clearly defined end-point, normally
marked by the production of a tangible deliverable.
• An activity requires a resource (as most do) then that resource requirement must be forecast
able and is assumed to be required at a constant level throughout the duration of the activity.
• The duration of an activity must be forecastable — assuming normal circumstances, and the
reasonable availability of resources.
• Some activities might require that others are completed before they can begin these are
known as precedence requirements).

Identifying activities
Essentially there are three approaches to identifying the activities or tasks that make up a
project
 the activity-based approach,
 the product-based approach
 the hybrid approach.

The activity-based approach

• The activity-based approach consists of creating a list of all the activities that the project is
thought to involve.
• This might involve a brainstorming session involving the whole project team or it might stern
from an analysis of similar past projects.
• When listing activities, particularly for a large project, it might be helpful to subdivide the
project into the main life-style stages and consider each of these separately.
• Generating a task list is to create a Work Breakdown Structure (WBS). This involves
identifying the main (or high- level) tasks required to complete a project and then breaking
each of these down into a set of Jower-Jevel tasks.
• Activities are added to a branch in the structure if they directly contribute to the
task immediately above — if they do not contribute to the parent task, then they
should not be added to that branch.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

• The tasks at each level in any branch should include everything that is required to complete
the task at the higher level — if they are not a comprehensive definition of the parent task,
then something is missing. When preparing a WBS, consideration must be given to the final
level of detail

Advantages

• the WES approach include the belief that it is much more likely to result in a task catalogue
• that is complete and is composed of non- overlapping activities.
• project's activities need to be sequenced in the sense of deciding which activities need to be
completed before others can start.
The product based approach
• It consists of producing a Product Breakdown Structure and a Product Flow Diagram.
• The PFD indicates, for each product, which other products are required as inputs.
• The PFD can therefore be easily transformed into an ordered list of activities by identifying
the transformations that turn products into others.
• This approach is particularly appropriate if using a methodology such as Structured
Systems Analysis and Design Method (SSADM), which clearly specifies, for each step or
task, each
of the
products
required
and the
activities
required
to
produce
it.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

The hybrid approach

• The WBS illustrated in Figure 6.2 is based entirely on a structuring of activities.

• WBS may be based upon the project's products as illustrated in Figure 6.5. which is in turn
based on a simple list of final deliverables and, for each deliverable, a set of activities
required to produce that product.
• Figure 6.5 illustrates a flat WBS and it is likely that, in a project of any size, it would be
beneficial to introduce additional levels — structuring both products and activities.
• The degree to which the structuring is product-based or activity-based might be influenced
by the nature of the project and the particular development method adopted.
• As with a purely activity-based WBS, having identified the activities we are then left with the
task of sequencing them.
• A framework dictating the number of levels and the nature of each level in the structure may
be imposed on a NVBS. For example, in their Master Intern Training Plan (MITP)
methodology, IBM recommend that the following five levels should be used in a WBS:
• Level I: Project.
• Level 2: Deliverables such as software, manuals and training courses.
• Level 3: Components which are the key work items needed to produce deliverables, such as
the modules and tests required to produce the system software.
• Level 4: Work-packages which are major work items, or collections of related tasks, required
to produce a component.
• Level 5: Tasks which are tasks that will normally be the responsibility of a single person.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Sequencing and scheduling activities

• Throughout a project, we will require a schedule that clearly indicates when each of the
project's activities is planned to occur and what resources it will need.
• The chart shown has been drawn up taking account of the nature of the development process
that is, certain tasks must be completed before others may start) and the resources that are
available (for example, activity C follows activity B because Andy cannot work on both tasks
at the same time).
• In drawing up the chart, we have therefore done two things — we have sequenced the tasks
(that is, identified the dependencies among activities dictated by the development process)
and scheduled them (that is, specified when they should take place).
• The scheduling has had to take account of the availability of staff and the ways in which the
activities have been allocated to them.
• The schedule might look quite different were there a different number of staff or were we to
allocate the activities differently.
• In the case of small projects. this combined sequencing—scheduling approach might be quite
suitable, particularly where we wish to allocate individuals to particular tasks at an early
planning stage.
• However, on larger projects it is better to separate out these two activities: to sequence the
tasks according to their logical relationships and then to schedule them taking into account
resources and other factors.
• Approaches to scheduling that achieve this separation between the logical an the physical use
networks to model the project and it is these approaches that will

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

3.3 Network Planning Models

Introduction:

• These project scheduling techniques model the project's activities and their relationships as a
network. In the network, time flows from left to right.

• The two best known being CPM (Critical Path Method) and PERT (Program Evaluation
Review Technique).
• Both of these techniques used an activity-on-arrow approach to visualizing the project as a
network where activities are drawn as arrows joining circles, or nodes which represent the
possible start and/or completion of an activity or set of activities.
• More recently a variation on these techniques, called precedence network, has become
popular. This method uses activity-on-node networks where activities are represented as
nodes and the links between nodes represent precedence (or sequencing) requirements.
• This latter approach avoids some of the problems inherent in the activity-on-arrow
representation and provides more scope for easily representing certain situations. It is this
method that is adopted in the majority of computer applications currently available. These
three methods are very similar and it must be admitted that many people use the same name
(particularly CPM) indiscriminately to refer to any or all of the methods.
• In the following sections of this chapter, we will look at the critical path method applied to
precedence (activity-on-node) networks followed by a brief introduction to activity-on-arrow
networks

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Formulating a network model

• The first stage in creating a network model is to represent the activities and their
interrelationships as a graph. In activity-on-node we do this by representing activities as links
(arrowed lines) in the graph — the nodes (circles) representing the events of activities
starting and finishing.

Constructing precedence networks

• A project network should have only one start node

• A project network should have only one end node
• A node has duration
• A node represents an activity and, in general, activities take time to execute.
• Links normally have no duration
• precedents are the immediate preceding activities In Figure 6.9, the activity 'Program test'
cannot start until both 'Code' and 'Data take-on' have been completed and activity 'Install'
cannot start until 'Program test' has finished. 'Code' and Data take-on' can therefore be said to
be precedents of 'Program test', and 'Program test' is a precedent of 'Install'. Note that we do
not speak of 'Code' and 'Data take-on' as precedents of 'Install' - that relationship is implicit in
the previous statement.
• Time moves front left to right

• A network may not contain loops Figure 6,10 demonstrates a loop in a network. A loop is an
error in that it represents a situation that cannot occur in practice. While loops, in the sense of
iteration, may occur in practice, they cannot be directly represented in a project network.

• A network should not contain dangles. A dangling activity such as 'Write user manual' in
Figure 6.11 should not exist as it is likely to lead to errors in subsequent analysis.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

• Redraw the network with a final completion activity — which, at least in this case, is
probably a more accurate

Representing lagged activities

• We might come across situations where we wished to undertake two activities in parallel so
long as there is a lag between the two. We might wish to document amendments to a program
as it was being tested - particularly if evaluating a prototype.
• Where activities can occur in parallel with a time lag between them we represent the lag with
a duration on the linking arrow as shown in Figure 6.13. This indicates that documenting
amendments can start one day after the start of prototype testing and will be completed two
days after prototype testing is completed.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

3.4 Forward Pass and backward pass

Activity-on-node network:
Critical path method uses activity-on-node networks where activities are represented as
nodes and the links between nodes represent precedence (or sequencing) requirements.

Labeling conventions

• There are a number of differing conventions that have been adopted for entering information
on an activity-on-node network. One of the more common conventions for labelling nodes,
and the one adopted here, is shown on the left.
• The activity label is usually a code developed to uniquely identify the activity and may
incorporate a project code
• The activity description will normally be a brief activity name such as 'Test take-on module'.

Earliest start Duration Earliest finish

Activity label, activity description

Latest start Float Latest finish

Adding the time dimension

• Having created the logical network model indicating what needs to be done and the
interrelationships between those activities, we are now ready to start thinking about when
each activity should be undertaken.
• The critical path approach is concerned with two primary objectives: planning the project in
such a way that it is completed as quickly as possible: and identifying those activities where a
delay in their execution is likely to affect the overall end date of the project or later activities'
start dates.
• The method requires that for each activity we have an estimate of its duration. The network is
then analyzed by carrying out a forward pass, to calculate the earliest dates at which
activities may commence and the project be completed, and a backward pass, to calculate the
latest start dates for activities and the critical path.
• In practice we would use a software application to carry out these calculations for anything
but the smallest of projects. It is important, though, that we understand how the calculations
are carried out in order to interpret the results correctly and understand the limitations of the
method.
• The description and example that follow use the small example project outlined in Table 6.1
— a project composed of eight activities whose durations have been estimated as shown in
the table

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

The forward pass

• The forward pass is carried out to calculate the earliest dates on which each activity may be
started and completed.
• Where an actual start date is known, the calculations may be carried out using actual dates.
Alternatively we can use day or week numbers and that is the approach we shall adopt here.
By convention, dates indicate the end of a period and the project is therefore shown as
starting at the end of week zero (or the beginning of week 1).
• The forward pass and the calculation of earliest start dates is calculated according to the
following reasoning.
• Activities A, B and F may start immediately, so the earliest date for their start is zero.
• Activity A will take 6 weeks, so the earliest it can finish is week 6.
• Activity B will take 4 weeks, so the earliest it can finish is week 4.
• Activity F will take 10 weeks, so the earliest it can finish is week 10.
• Activity C can start as soon as A has finished so its earliest start date is week 6. It will take 3
weeks so the earliest it can finish is week 9.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

• Activities D and E can start as soon as B is complete so the earliest they can each start is
week 4. Activity D, which will take 4 weeks, can therefore finish by week 8 and activity E,
which will take 3 weeks, can therefore finish by week 7.
• Activity G cannot start until both E and F have been completed. It cannot therefore start until
week 10 — the later of weeks 7 (for activity E) and 10 (for activity F). It takes 3 weeks and
finishes in week 13.
• Similarly, Activity H cannot start until week 9 — the later of the two earliest finished dates
for the preceding activities C and a
 The project will be complete when both activities H and G have been completed. Thus the
earliest project completion date will be the later of weeks 11 and 13— that is, week 13. The
results of the forward pass are shown in Figure 6.15.

The backward pass

• The second stage in the analysis of a critical path network is to carry out a backward pass to
calculate the latest date at which each activity may be started and finished without delaying
the end date of the project. In calculating the latest dates, we assume that the latest finish date
for the project is the same as the earliest finish date — that is, we wish to complete the
project as early as possible.
• Figure 6.16 illustrates our network alter carrying out the backward pass.
• The latest activity dates are calculated as follows.
• The latest completion date for activities G and 1-1 is assumed to be week 13.
• Activity H must therefore start at week 11 at the latest (13-2) and the latest
start date for activity G is week 10 (13-3).

• The latest completion date for activities C and D is the latest date at which
• activity H must start — that is. week 11. They therefore have latest start dates of week 8 (11-
3) and week 7 (11-4) respectively.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

• Activities E and F must be completed by week 10 so their earliest start dates are weeks 7 (10-
3) and 0 (10-10 respectively.
• Activity B must be completed by week 7 the latest start date for both activities D and El so
its latest start is week 3 (7-4).
• Activity A must be completed by week 8 (the latest start date for activity C) so its latest start
is week 2 (8-6).
The latest start date for the project start is the earliest of the latest start dates for activities A.
B and F. This is week zero. This is, of course, not very surprising since it tells us that if the
project does not start on time it won't finish on time.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

3.5 Activity Float- Shortening Project Duration

Identifying the critical path
There will be at least one path through the network that defines the duration of
the project. This is known as the critical path. The critical path is the longest path
through the network. Any delay to any activity on this critical path will delay the
completion of the project.
The significance of the critical path is two-fold.
 In managing the project, we must pay particular attention to monitoring
activities on the critical path so that the effects of any delay or resource
unavailability are detected and corrected at the earliest opportunity.
 In planning the project, it is the critical path that we must shorten if we are to
reduce the overall duration of the project.
Figure 6.17 also shows the activity span. This is the difference between the
earliest start date and the latest finish date and is a measure of the maximum time
allowable for the activity.

Activity float:
• Although the total float is shown for each activity, it really 'belongs' to a path
through the network. Activities A and C in Figure 6.16 each have 2 weeks' total
float. If, however, activity A uses up its float (that is, it is not completed until
week 8) then activity B will have zero float (it will have become critical). In
such circumstances it may be misleading and detrimental to the project's
success to publicize total float!
• There are a number of other measures of activity float, including the following:
• Total float: the difference between an activity’s earliest start date and its latest
start date is known as the activity’s float – it is a measure of how much the start
or completion of an activity may be delayed without affecting the end date of
the project.
Total float = LF – ES – duration (or LS-ES or LF-EF)
• Free float: the time by which an activity may be delayed without affecting any
subsequent activity. It is calculated as the difference between the earliest
completion date for the activity and the earliest start date of the succeeding
activity. This might be considered a more satisfactory measure of float for
publicizing to the staff involved in undertaking the activities.
• • Interfering float: the difference between total float and free float. This is quite
commonly used, particularly in association with the free float. Once the free
float has been used (or if it is zero), the interfering float tells us by how much
the activity may be delayed without delaying the project end date - even though
it will delay the start of subsequent activities.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

• Calculate the free float and interfering float for each of the activities shown in
the activity network (Figure 6.1 7).

Free and interfering float

Total float = LF – ES – duration
A 7w B can be up to 3 weeks late
0 7 and not affect any
2 9 other activity = free float
2 Free float = ES for following activity - EF for
the current

B 4w D 1w E 2w
0 4 7 8 10 12
5 9 9 10 10 12
5 2 0

C 10w
0 10
0 10
B can be a further 2 weeks late – affects
0
D but not the project end date =
interfering float
Interfering float = total float – free float

Shortening the project duration

• If we wish to shorten the overall duration of a project we would normally

consider attempting to reduce activity durations. In many cases this can be done
by applying more resources to the task - working overtime or procuring
additional staff, for example. The critical path indicates where we must look to
save time - if we are trying to bring forward the end date of the project, there is
clearly no point in attempting to shorten non-critical activities. Referring to
Figure 6.17, it can be seen that we could complete the project in week 12 by
reducing the duration of activity F by one week (to 9 weeks).

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Exercise 6.4
• Referring to Figure 6.17, suppose that the duration for activity F is shortened to
8 weeks. Calculate the end date for the project.
• What would the end date for the project be if activity F were shortened to 7
weeks? Why?
• As we reduce activity times along the critical path we must continually check
for any new critical path emerging and redirect our attention where necessary.
• There will come a point when we can no longer safely, or cost-effectively,
reduce critical activity durations in an attempt to bring forward the project end
date. Further savings, if needed, must be sought in a consideration of our work
methods and by questioning the logical sequencing of activities. Generally, time
savings are to be found by increasing the amount of parallelism in the network
and the removal of bottlenecks (subject always, of course, to resource and
quality constraints).

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

3.6 Activity on Arrow Networks

 The project scheduling techniques model the project's activities and their
relationships as a network. In the network, time flows from left to right.
 The two best known being CPM (Critical Path Method) and PERT
(Program Evaluation Review Technique).
 Both of these techniques used an activity-on-arrow approach to visualizing the
project as a network where activities are drawn as arrows joining circles, or
nodes which represent the possible start and/or completion of an activity or set
of activities.
 More recently a variation on these techniques, called precedence network, has
become popular. This method uses activity-on-node networks where activities
are represented as nodes and the links between nodes represent precedence (or
sequencing) requirements.
 This latter approach avoids some of the problems inherent in the activity-on-
arrow representation and provides more scope for easily representing certain
situations. It is this method that is adopted in the majority of computer
applications currently available. These three methods are very similar and it
must be admitted that many people use the same name (particularly CPM)
indiscriminately to refer to any or all of the methods.
 In the following sections of this chapter, we will look at the critical path method
applied to activity-on-arrow networks

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Activity-on-arrow network rules and conventions

• A project network may have only one start node

• A project network may have only one end node
• A link has duration
• Nodes have no duration

• Time moves from left to right

• Nodes are numbered sequentially
• A network may not contain loops

A network may not contain loops Figure 6.20 demonstrates a loop in a network. A
loop is an error in that it represents a situation that cannot occur in practice. While
loops, in the sense of iteration, may occur in practice, they cannot be directly
represented in a project network.

A network should not contain dangles. A dangling activity such as 'Write user
manual' in Figure 6.21 should not exist as it is likely to lead to errors in subsequent
analysis.
• Redraw the network with a final completion activity — which, at least in this
case, is probably a more accurate

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Using dummy activities

When two paths within a network have a common event although they are, in other respects,
independent, a logical error such as that illustrated in Figure 6.23 might occur. Suppose that, in a
particular project, it is necessary to specify a certain piece of hardware before placing an order for it
and before coding the software. Before coding the software it is also necessary to specify the
appropriate data structures, although clearly we do not need to wait for this to be done before the
hardware is ordered.
Figure 6.23 is an attempt to model the situation described above, although it is incorrect in
that it requires both hardware specification and data structure design to be completed before either
an order may be placed or software coding may commence.

We can resolve this problem by separating the two (more or less) independent paths and
introducing a dummy activity to link the completion of ‘specify hardware’ to the start of the activity
‘code software’. This effectively breaks the link between data structure design and placing the order
and is shown in Figure 6.24.

Dummy activities, shown as dotted lines on the network diagram, have a zero duration and
use no resources. They are often used to aid in the layout of network drawing as in Figure 6.25. the
use of a dummy activities where two activities share the same start and end nodes makes it easier to
distinguish the activity end-points.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Activity labeling
There are a number of differing conventions that have been adopted for entering
information on an activity-on-arrow network. Typically the diagram is used to record
information about the events rather than the activities – activity-based information is
generally held on a separate activity table.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

[Link] Management and category of risks

Every project involves risk. Risk is “an uncertain event or condition that, if it
occurs has a positive or negative effect on a project objectives”, include transferring
the risk to another party, avoiding the risk, reducing the negative effect of the risk, and
accepting some or all of the consequences of a particular risk.

Some definitions of risk

 ‘the chance of exposure to the adverse consequences of future events’
PRINCE2
• Project plans have to be based on assumptions
• Risk is the possibility that an assumption is wrong
• When the risk happens it becomes a problem or an issue

Risk Occurs:
• When the project exceed its original specification
• Deviations from achieving it objectives and so on.

There are two types of risks.

1. Project risk – which prevent the project from being completed successfully.
Project risk are those could prevent achievement of objectives given to the
project manager & project team.
2. Business risk – delivered products are not profitable. Economic downturn or
import of cheaper alternative products.

• Risk evaluation is meant to decide whether to proceed with the project or not,
and whether the project is meeting its objectives.
• Uncertain event or condition that if it occurs has positive or negative condition
on project objectives.
• Key elements of Risk follows:-
 It relates to the future-risk involves speculating about future events.
 Involves cause & effects

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Categories of risk:

This is based on Lyytinen’s sociotechnical model of risk

• Actors relate to all those involved in the project including both developers,
users and managers
• Includes various department specialists, user groups, managers with
different responsibilities.
• if developer builds software components & leave before testing, team
member taking over that component find lack of familiarity with software
make correction of faults difficult.
• e.g. a risk could be that high staff turnover leads to information of
importance to the project being lost
• Technology – both that used to implement the project and that embedded in the
project deliverables – risk could be that the technologies selected are not in fact
appropriate.
• Structure – this includes management procedures, risk here is that a group who
need to carry out a particular project task are not informed of this need because
they are not part of the project communication network
• Tasks – the work to be carried out. A typical risk is that the amount of effort
needed to carry out the task is underestimated.
A risk could be well belong to more than one of the four areas – for example,
estimates being wrong could be influenced by problems with actors (e.g. lack of
experience with a technical domain) or the structure (over optimism of managers keen
to win work).
Exercise 7.2 in the text will be some practice in identifying and categorizing risks

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Some other categories of risks:

• Schedule Risk
 Wrong time estimation
 Resources are not tracked properly. All resources like staff, systems,
skills of individuals etc.
 Unexpected project scope expansions
• Budget Risk
 Wrong budget estimation
 Cost overruns
 Project scope expansion
• Operational Risks
 No proper subject training
 No resource planning
 No communication in team.
• Technical risks
 Product is complex to implement.
 Difficult project modules integration.
 Continuous changing requirements
• Programmatic Risks
 Market development
 Changing customer product strategy and priority
 Government rule changes

ISPL situational factors: the target domain

1. Information system - the characteristics of the information system - these are
independent of the technologies that might be used
2. Computer system - the characteristics of the part of the information system
that have been computerized

ISPL situational factors: project domain

Project • the types of task to be undertaken

Structure • the communication systems,

management structures, work
flows etc
Actors • the people involved in the project

Technology • the methods, techniques and tools

to be used

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

3.8 Managing Risk

The proactive management of risks throughout the software development lifecycle

is important for project success. In this chapter, we will explain the following:

 the risk management practice, which involves risk identification, analysis,

prioritization, planning, mitigate on, monitoring, and communication
 software development risks that seem to reoccur in educational and industrial
projects
 a risk-driven process for selecting a software development model

A framework for dealing with risk

The planning for risk includes these steps:

• Risk identification – what risks might there be?
• Risk analysis and prioritization – which are the most serious risks?
• Risk planning – what are we going to do about them?
• Risk monitoring – what is the current state of the risk?

Risk identification

Approaches to identifying risks include:

• Use of checklists – usually based on the experience of past projects
• Brainstorming – getting knowledgeable stakeholders together to pool concerns
• Causal mapping – identifying possible chains of cause and effect

Checklists

 They are simply lists of the risks have been found to occur regularly in software
development projects
 Creators of checklists also suggest potential counter measures for each risk.
 If manager identifies risk ,he can use counter measures to cope with them.

Brain storming
 Representative of main stakeholders can be brought together ,and a plan is
drafted.
 It is used to identify the possible solutions to the problem.
 All stakeholders have a meeting and risk in the projects are discussed.
Casual mapping
 One way of identifying possible threats to the success of a project & measures
that might eliminate & reduce them is the use of casual mapping.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

 Casual maps & diagrams represent chains of causes & effects that will
influence outcomes in particular area
 Example: Casual map of problem area

Casual map of problem area with solution

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Boehm’s top 10 development risks

Risk Risk reduction techniques

Personnel shortfalls Staffing with top talent; job matching; teambuilding; training and
career development; early scheduling of key personnel

Unrealistic time and cost Multiple estimation techniques; design to cost; incremental
estimates development; recording and analysis of past projects;
standardization of methods

Developing the wrong software Improved software evaluation; formal specification methods; user
functions surveys; prototyping; early user manuals

Developing the wrong user Prototyping; task analysis; user involvement

interface
Gold plating Requirements scrubbing, prototyping,
design to cost
Late changes to requirements Change control, incremental development

Shortfalls in externally supplied Benchmarking, inspections, formal specifications, contractual

components agreements, quality controls
Shortfalls in externally performed Quality assurance procedures, competitive design etc
tasks
Real time performance problems Simulation, prototyping, tuning

Development technically too Technical analysis, cost-benefit analysis, prototyping , training

difficult

Risk Analysis

Risk exposure (RE) = (potential damage) x (probability of occurrence)

Ideally
Potential damage: a money value e.g. a flood would cause £0.5 millions of damage
Probability 0.00 (absolutely no chance) to 1.00 (absolutely certain) e.g. 0.01 (one in
hundred chance)
If there were 100 people chipping in £5,000 each, there would be enough for the 1 in
100 chance of the flooding. If there were 2 floods then the system collapses! Exercise
7.4 in the textbook is strongly recommended to explore these issues. In practice, with
project risks, these quantitative approaches are usually impractical and more
qualitative approaches are used instead. See the next overhead.
RE = £0.5m x 0.01 = £5,000
Crudely analogous to the amount needed for an insurance premium
IT2403/Software Project Management
Sri Vidya College of Engineering & Technology Lecturer Notes

Table 7.3 Risk probability: qualitative descriptors

Probability level Range
High Greater than 50% chance of happening

Significant 30-50% chance of happening

Moderate 10-29% chance of happening

Low Less than 10% chance of happening

Table 7.4 Qualitative descriptors of impact on cost and associated range values
Impact level Range

High Greater than 30% above budgeted expenditure

Significant 20 to 29% above budgeted expenditure

Moderate 10 to 19% above budgeted expenditure

Low Within 10% of budgeted expenditure.

Probability impact matrix

IT2403/Software Project Management
Sri Vidya College of Engineering & Technology Lecturer Notes

R1, R2 etc refer to particular risks (See Table 7.4 in the textbook). They are located on
the grid according to the likelihood and impact ratings that have been allocated to
them. A zone around the top right hand corner of the grid can be designated and risks
falling within that zone are treated as requiring urgent action.

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

3.9 Risk Planning And Control

Risk planning:
Risks can be dealt with by:

• Risk acceptance – the cost of avoiding the risk may be greater than the actual
cost of the damage that might be inflicted
• Risk avoidance – avoid the environment in which the risk occurs e.g. buying
an OTS application would avoid a lot of the risks associated with software
development e.g. poor estimates of effort.
• Risk reduction – the risk is accepted but actions are taken to reduce its
likelihood e.g. prototypes ought to reduce the risk of incorrect requirements
• Risk transfer – the risk is transferred to another person or organization. The
risk of incorrect development estimates can be transferred by negotiating a
fixed price contract with an outside software supplier.
• Risk mitigation – tries to reduce the impact if the risk does occur e.g. taking
backups to allow rapid recovery in the case of data corruption

Risk acceptance

 This is do nothing option.

 We would decide that damage inflicted by some risk would be less than cost of
action.

Risk avoidance

 Some activities are so prone to accidents that it is best to avoid them

 If u are worried about crocodiles then don’t go into the water
 When Manager will decide to avoid the risk he will buy an off the shelf
components.

Risk reduction

Risk reduction leverage = (REbefore- REafter)/ (cost of risk reduction)

REbeforeis risk exposure before risk reduction e.g. 1% chance of a fire causing
£200k damage
REafter is risk exposure after risk reduction e.g. fire alarm costing £500 reduces
probability of fire damage to 0.5%

If you think in terms of the analogy to insurance. An insurance company might

reduce the fire insurance premium from £2k to £1k on condition that a fire alarm is

IT2403/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

installed. The insured would save £1k a year by investing £500 so it would be
worth doing.
RRL = (1% of £200k)-(0.5% of £200k)/£500 = 2
RRL > 1.00 therefore worth doing

Risk mitigation

 Risk mitigation is action taken to ensure that impact of risk is lessened when it
occurs.
 It tries to reduce the impact if the risk does occur e.g. taking backups to allow
rapid recovery in the case of data corruption

Risk transfer
 Risk is transferred to another person or organization
 With software projects example would be where a software development task is
outsourced to an outside agency for a fixed fee.

Evaluating risk to schedule

 We use PERT technique
 Use to evaluate the effects of uncertainty
 PERT require three estimates
 Most likely time
 Optimistic time
 Pessimistic time

 Most likely time --The time we would expect the task to take under normal
circumstances ,denoted by:-m
 Optimistic time—shortest time in which we could expect to complete the
activity, denoted by a.
 Pessimistic time—worst possible ,denoted by b
te=(a+4m+b)/6
 Calculate standard deviation for each project events s=(b-a)/6
 Calculate z value for each event that has target date z=(T - t e) /s
where
t e expected date
T target date

IT2403/Software Project Management