You are on page 1of 94

“A project is like a road trip.

Some projects are simple and


routine, like driving to the store in broad day light, but most
projects are like driving a truck off-road, in the mountains at
night” – Kaner, Bach and Pettichord

Lecture 5,6,7,8 and 9


Project
Management

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 1
Introduction
 Every organisation, at some time or other,
carries out projects that must be planned
and implemented.
 People in these organisations gain
experience in project management
 because formal methodologies are not
used and their experience is not
documented effectively, performance does
not improve incrementally
 when key people leave the organisation
their experience leaves with them

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 2
Our Scope
 we shall consider project
management in small to medium
sized enterprises (SMEs)
 However the concepts introduced
in this module are applicable to a
wide range of organisations

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 3
Our Scope

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 4
Project Phases: Planning
 The project must be planned in
sufficient detail to allow it to be costed
and scheduled accurately.
 Facilities for monitoring the project as it
progresses must be built into the plan.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 5
Project Phases:
Implementation
 The project should have a defined start
date and a target end date
 it must be monitored and managed
throughout the implementation phase.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 6
Project Phases: Sign Off
 Authorised personnel should sign off,
the project on completion.
 Expenditure on the project should then
cease and resources allocated to the
project should be released for use on
other projects.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 7
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 8
Project Phases: Review
 After the project has been signed off it
should be reviewed to identify things
that went wrong, with a view to
correcting them in subsequent
projects.
 improved methods of carrying out
project tasks should be considered.
 The review allows incremental
improvement in company
performance.
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 9
Project Tasks
 Examples of high-level tasks are
graphical design, network and systems
implementation, database design, and
front-end software development.
 High-level tasks can be broken down into
sub-tasks, so database design may
consist of entity relationship modelling,
normalisation, specifying queries and
reports etc.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 10
Project Tasks
 Where do we stop breaking tasks down into
sub-tasks?
 It depends, but eventually tasks must be
defined that represent actual work.
 Tasks that represent actual work must be
defined in terms of cost, duration, risk etc.
 A task should also have a defined outcome
allowing it to be clear when the task is
completed.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 11
Project Tasks
 If we define tasks at too high a level
we cannot estimate task durations
meaningfully, if we define tasks in
great detail we may not be able to
see the wood for the trees.
 A sensible approach is to define tasks
to a level of detail that allows us to
estimate key task attributes such as
task duration and task resource
requirements.
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 12
Task Type and Task
Relationship

 The task identifier


 The estimated task duration
 The task start date
 The task completion (end) date
 Task costs
 Task resources
 Task contingency
 Task Risk

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 13
Task Type and Task
Relationship

 Only when all the tasks are completed is the project


complete.
 The start end and end nodes can be thought of as
special dummy tasks that take no time and have zero
resources allocated to them etc.
 We shall call these tasks milestones- in the above
diagram the start and end nodes are milestones.
Milestones are important points in a project.
 The Diagram is called Project Network Diagram
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 14
Task Type and Task
Relationship

 T1 is the immediate predecessor of T2 and T5, and T3 and T6 are


the immediate predecessors of T4.
 T5 and T6 are carried out concurrently with T2 and T3- this is also
called simultaneous engineering or parallel engineering.
 allows the project to be completed in a shorter time than if all the
tasks are carried out serially
 simultaneous engineering carries more risk than serial engineering

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 15
Task Type and Task
Relationship

 Finish-to-Start relationship- task T2 starts


when task T1 finishes.
 Example: Database design and SQL development
– we cannot start to write queries for a database
until we know what the database will look like.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 16
Task Type and Task
Relationship

 Start-to-Start relationship- T4 starts when T3 starts.


 Example: Implementation of the main computer system
hardware and the network hardware. When the site is
disrupted for engineers to install the hardware, the main
computer systems kit and the network hardware will be
installed simultaneously.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 17
Task Type and Task
Relationship

 Finish-to-Finish relationship- T8 finishes when


T7 finishes.
 Example: Final test and product release- final test
must be completed before we finish handing the
product over to the client.
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 18
Task Type and Task
Relationship

 Start-to-Finish relationship- T5 cannot finish


until T6 starts. This relationship is seldom used.
 Example: would be if T5 was replacing T6,
accordingly T5 has to run until its replacement
begins.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 19
Task Type and Task
Relationship

 The above relationships, which are called task dependencies, often appear
artificial until the concepts of task lead and lag times are introduced.
 A lag time is a period between the start or finish of a predecessor and the
start or finish of the successor.
 Conversely, a lead-time is an overlap between dependencies.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 20
Task Type and Task
Relationship

 T3 represents the "power and heat testing" and T4


represents the "software installation" task.
 The 1d forces a 1-day delay for the first machine to be
tested.
 The two tasks can run concurrently, it is just that T3 needs
to be running a day ahead.
 Lag time is used when there is a forced period of inactivity
or delay.
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 21
Task Type and Task
Relationship

 Task T1 represents "Final Test" and Task T2


represents “installation".
 The tasks have a finish to start dependency but a
lead-time of 1 hour has been included so that T2
starts 1 hour before T1 has finished
 note that lead times are entered as negative lags.
The hour unit is specified by the letter h.
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 22
Estimating Task
Durations
 Guessing
Guessing task durations is usually very
dangerous and almost always leads to severe
under estimates.
 Ball Parking
Ball parking is an educated guess
For example if you have managed the
development of several websites you should
be able to give a ballpark figure for the
development time of another.
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 23
Estimating Task
Durations
 Estimating
Estimated durations are the result of some
process
 The Empire State building is about 1000 ft
high- the height of a step is about 10 inches,
so their are about 1200 steps.
 If it takes 2 seconds to climb a step the time
taken to climb all the steps is 2400 seconds.
 That is 40 minutes.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 24
Task Contingency
 We shall introduce the idea of a
task contingency factor, CF, which
is a number greater than or equal
to unity.
 If we estimate a task duration to be
10 days and we assume a task
contingency factor CF = 1.2, it
means we expect the task to take
between 10 and 12 days (10*1.2).

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 25
Student Syndrome
 Student syndrome refers to a situation
where a someone working on a project
believes they have been assigned more
time to do a task than they need
 To resolve this problem, the staff involved
in executing a task should be encouraged
to set challenging targets and
contingency should be the domain of the
project manager.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 26
Network
Diagram

Task ID Predecessors Duration


S None 0 days Milestone
T2 S 10 days
T3 T2 5 days
T4 T3 4 days
T5 T4 12 days
T6 T5,T9 15 days
T7 T2 20 days
T8 T3,T7 12 days
T9 T8 15 days
T10 S 2 days
T11 T8,T10 5 days
T12 T11 4 days
F T6,T12 0 days Milestone
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 27
Critical
Path

 The path through the network coloured red is called


the critical path
 this is the time it takes to complete the project.
 If any of the tasks on the critical path takes longer
than estimated the project will be completed later
than planned.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 28
Slack

 Tasks that are not on the critical path have an


attribute called slack.
 T10, which has a duration of only 2 days, may be
started when the project starts
 Or 2 days before T8 is due to end without affecting
the project completion time
 The slack associated with task T10 is the duration of
T2 + duration of T7 + Duration of T8 - duration of T10

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 29
Slack

 Slack is a valuable tool for the project manager


 if resources required to complete task T10 are
required to complete task T7, T10 can be delayed
until T7 is completed and the resources become
available to carry out T10, without affecting the
completion time of the project

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 30
Task Affiliations

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 31
Indented Task Details

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 32
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 33
Resource
 Different types of resources are required to
carry out a project.
 If we consider the development of a new web
based application for example, we shall require
people to carry out the graphical design, people
to analyse the business requirements, possibly
a database specialist, software developers and
so forth.
 We shall also need time and money, which are
generally fundamental.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 34
Resource Types
1. People
2. Equipment
3. Materials
 Both people and equipment are required
to carry out work on the project and
both have costs associated with them.
 If materials are consumed as the project
progresses then these also have costs
associated with them.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 35
Resource Types
 People and equipment are given a "unit" value
 For example, if a person is available to work on the
project full time they are given a unit value of 1.00
or 100%.
 A group of 3 people available to work on the
project full time are given a unit value of 3.00,
whilst a single person available for only half of the
working time is given a value of 0.5.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 36
Resource Types
 Equipment is treated just like people-
if an item of equipment is only
available for 20% of the working time
it is given a unit value of 0.2.
 Materials (which in most computing
projects equates to hardware and
software) do not have a unit value
associated with them, but they do
have a cost.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 37
Resource Calendar
 The calendar, which is based on a standard
calendar, takes into account company holidays,
the number of hour’s worked/day and the number
of days worked in a week.
 It is possible to assign a calendar to each resource
used on a project, so that an individual's holidays
could be taken into account when planning the
project.
 A similar situation applies to equipment and even
external suppliers.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 38
Resource Calendar

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 39
Resource Utilization
 Resources, particularly human
resources, are seldom available to
work full time on projects.
 The programmers in the department
would not really be available for
development work full time because
they would be expected to provide
technical support for products that
customers are currently using.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 40
Resource Utilization
 It is also unreasonable to expect people to be
available for 100% of the working time during a
project- people need to answer the phone; answer
emails and take care of bodily functions, etc.
 We SHOULD assume that personnel in the
development department are only available for 90%
of the working week and that some individuals will be
available for less than this for development because
of other duties they must carry out on a regular
basis.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 41
Resource Utilization

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 42
Resource Assignment

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 43
Resource Pool

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 44
Resource Cost

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 45
Resource Leveling
 While allocating resources manually,
there may be a chance of overloading
resources.
 In many CASE tools, there is an option
of automatic resource leveling which
is good.
 But sometimes can be devastating if
project manager does not know the
the project resource allocation
thoroughly.
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 46
Task Definitions and
Resources
 Task Duration
Takes how many days/hours/minutes
to complete the project task
 Units
Units refers to the resources used on
the task, for example if the units
are set to 1.0 it would mean one
units of resource are used on the
task.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 47
Task Definitions and
Resources
 The most common unit of resource is people and
if 2 people are used on a task it means the task
units=2.
 Task Work
This is the actual real work associated with a
task, so if it takes 2 people 2 days to complete a
task, the task work is 2*2 = 4 person days.
Task Duration * Units = Task Work

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 48
“Risk Management is Project Management for adults” – Tim
Lister
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 49
Introduction
 Every time we undertake an activity there is
some risk associated with it: even supposedly
non-activities carry risk
 One problem with risk is that most people have
an intuitive approach to it and most people
think they understand it.
 We shall adopt a more formal, but practical,
approach to defining project risks and risk
management.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 50
Definition
 We shall think of risk as an event that
may happen in the future and if it
does happen the consequences are
likely to be unpleasant.
 There are two components to any risk,
the chance that it may occur and the
consequences if it does occur.
 We shall refer to the chance of a risk
occurring as its probability.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 51
Definition
 risk R =F(pr,Cr)
 where pr = the probability of the risk
occurring and
 Cr = the consequences if it does occur.
 F means "some function of“
 we shall not concern ourselves with F -
we shall concentrate on the components
of risk.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 52
Definition
 Every time we carry out an activity with a
risk associated with it we shall assume the
activity has some benefit associated with it.
 We can assume that benefit can be defined
in the same way as risk, that is:-
 B=f(pb,Cb)
 where the pb = the probability of the benefit
occurring and
 Cb are the consequences if the activity
yields the benefit.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 53
Definition
 Every time we carry out an activity with a
risk associated with it we shall assume the
activity has some benefit associated with it.
 We can assume that benefit can be defined
in the same way as risk, that is:-
 B=f(pb,Cb)
 where the pb = the probability of the benefit
occurring and
 Cb are the consequences if the activity
yields the benefit.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 54
Definition
 Note that probability p has a value between 0
and 1 and if the benefit accrues from the
activity the risk will not, which means that
1=pr+pb, or pb = 1-pb, so we can write:-
  R = F(pr,Cr) and B = f(1-pr,Cb)
 In business terms we shall only consider
undertaking an activity if the benefits
associated with it significantly outweigh the
associated risk.
 This means pr should be small, i.e. << 1 and
Cb >> Cr

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 55
Definition
 Many texts define risk as a single number: R=p*C
 We shall not adopt this approach because:-
 Sometimes the there are more than one
consequence associated with a risk, for example a
database is designed incorrectly- the
consequences are financial- say £20,000- there is a
delay to market- say 12 weeks- there is also a loss
of face with our customer.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 56
Definition
 Generating a single number for risk seldom clarifies
the situation- if you attend a meeting where risk has
been reduced to a single number people are forever
asking what the components of risk are.
 Using a single number for risk obscures the problems
associated with the risk- in practice it is often quite
difficult to assess the probability of a risk but its
consequences are usually quite easy to define.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 57
Software risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be
delivered on schedule.
Requirements change Project and There will be a larger number of changes to the
product requirements than anticipated.
Specification delays Project and Specifications of essential interfaces are not available on
product schedule
Size underestimate Project and The size of the system has been underestimated.
product
CASE tool under- Product CASE tools which support the project do not perform as
performance anticipated
Technology change Business The underlying technology on which the system is built is
superseded by new technology.
Product competition Business A competitive product is marketed before the system is
completed.
The risk management
process
 Risk identification
Identify project, product and business risks;
 Risk analysis
Assess the likelihood and consequences of
these risks;
 Risk planning
Draw up plans to avoid or minimise the effects
of the risk;
 Risk monitoring
Monitor the risks throughout the project;
The risk management
process

Risk Risk
Risk analysis Risk planning
identification monitoring

Risk avoidance
List of potential Prioritised risk Risk
and contingency
risks list assessment
plans
Risk identification
 Technology risks.
 People risks.
 Organisational risks.
 Requirements risks.
 Estimation risks.
Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per second
as expected.
Software components that should be reused contain defects that limit their
functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management are responsible for
the project.
Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
Risk analysis
 Assess probability and seriousness
of each risk.
 Probability may be very low, low,
moderate, high or very high.
 Risk effects might be catastrophic,
serious, tolerable or insignificant.
Risk analysis (i)

Risk Probability Effects


Organisational financial problems force reductions in Low Catastrophic
the project budget.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain Moderate Serious
defects which limit their functionality.
Changes to requirements that require major design Moderate Serious
rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
Risk analysis (ii)

Risk Probability Effects


The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant
Risk planning
 Consider each risk and develop a
strategy to manage that risk.
 Avoidance strategies
The probability that the risk will arise is
reduced;
 Minimisation strategies
The impact of the risk on the project or
product will be reduced;
 Contingency plans
If the risk arises, contingency plans are
plans to deal with that risk;
Risk management
strategies (i)
Risk Strategy
Organisational Prepare a briefing document for senior management
financial problems showing how the project is making a very important
contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-
components in components of known reliability.
Risk management
strategies (ii)
Risk Strategy
Requirements Derive traceability information to assess requirements
changes change impact, maximise information hiding in the
design.
Organisational Prepare a briefing document for senior management
restructuring showing how the project is making a very important
contribution to the goals of the business.
Database Investigate the possibility of buying a higher-
performance performance database.
Underestimated Investigate buying in components, investigate use of a
development time program generator
Risk monitoring
 Assess each identified risks
regularly to decide whether or not
it is becoming less or more
probable.
 Also assess whether the effects of
the risk have changed.
 Each key risk should be discussed
at management progress meetings.
Risk indicators
Risk type Potential indicators
Technology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
Organisational Organisational gossip, lack of action by senior management
Tools Reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects
Project Risk Log

 NS- not started , IP- in progress


 C- completed , F- failed

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 71
Risk Strategy
 Carry out the high risk tasks as soon as possible-
exit the project if necessary
 Carry out the high contingency tasks as soon as
possible
 Carry out less contentious tasks after risky tasks
and high contingency tasks have been completed
 Identify tasks as high risk and/or high contingency
tasks during the planning phase

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 72
The Problem

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 73
Comparison of Risk and
Benefit

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 74
Rushdi Shams, Lecturer, Dept of CSE, KUET,
Bangladesh 75
Formal Project Management
Methods
 Network Diagrams
 Gantt Charts
 Critical Path Method (CPM)
 Project Evaluation and Review
Technique (PERT)

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 76
Network Diagrams
 Network diagrams are probably the
most useful way of introducing project
management concepts
 they can give a very graphic overview
of the relationships between project
tasks.
 Network diagrams assist project
managers in calculating and presenting
task precedence.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 77
Types of Network
Diagram
 Thereare two types of network
diagram in use, task on node and
task on arc.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 78
Gantt Charts
 The Gantt chart, or bar chart is familiar to most people
in some form or other.
 Henry Gantt, an American engineer in about 1900, first
introduced the Gantt chart as a project management
tool.
 The length of the bars represents the task duration
 other information may also be included on the charts,
such as resources assigned to tasks and task progress.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 79
Table Entry Gantt Chart
View

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 80
Tracking Gantt Chart
View

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 81
Critical Path Method
(CPM)
 The Critical Path Method of project
management was developed
formally by NASA in the 1950's.
 An extension of network diagrams
 emphasis was placed on project
finance and methods of reducing
project completions times.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 82
CPM
 te = expected
completion time using
normal resources
 Ce = expected cost
using normal
resources
 tc = shortest task time
possible, sometimes
referred to as the
crash time

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 83
CPM
 Cc = task cost when
completed in the crash time
 ts = shortened task
completion time when
additional resources are
assigned to the task
 Cs = cost of the shortened
task when additional
resources are assigned to it

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 84
Slope of the task
 The slope is negative

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 85
Cost of the task
 The cost of a task that
has been shortened
is:-
 Cs = Ce -S(te - ts)

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 86
Slope of the task
 if the expected task
completion time is
100 hours and the
expected cost is
£2500 and the task
crash time is 50 hours
at a cost of £4000,
the task cost slope is:-

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 87
Cost of the task
 If more resources are
assigned to the task
so it is completed in
75 hours, the task
cost is increased to:-

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 88
Project Evaluation and Review
Technique (PERT)
 PERT was also developed formally
in the USA at about the same time
as CPM, in connection with the
Polaris Missile System development
program.
 It was concerned mainly with
project completion time: massive
resources were made available for
the project. 

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 89
Project Evaluation and Review
Technique (PERT)
 PERT uses 3 time estimates for each task:-
 to = the most optimistic estimate of the
task duration
 tp = the most pessimistic estimate of the
task duration
 tl = the most likely time the task is to be
completed in

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 90
The Beta Distribution

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 91
PERT: Another Method
 optimistic weighting = 3
 expected weighting = 0
 pessimistic weighting = 3
 if we have a task contingency
factor of 1.2, and the best (most
optimistic) estimate of the task
duration is 10d, the most
pessimistic estimate of the task
duration is: 1.2 x 10=12 days.

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 92
Reference
 ITProject Management by Ron
Hood and Rob Campbell
 Software Engineering by William
Sommerville, 7th Edition, Chapter 5

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 93
Acknowledgements
 Caption photo credit: World Wide
Web
 Citation credit: Roger Pressman
 Members of ITIL Development
Project Team, University of Bolton,
UK

Rushdi Shams, Lecturer, Dept of CSE, KUET,


Bangladesh 94

You might also like