SDPM - Lecture 7 - Project monitoring and control

Leiden Insitute of Advanced Computer Science

1

System’s Development and Project Management – Project monitoring and control

Prof. Dr. Thomas Bäck

Leiden Institute of Advanced Computer Science Dates

Feb. 1 14:45 – 17:30 Introduction, Project Description Feb. 2 13:45 – 16:30 STEP WISE Approach to Project Planning Feb. 9 13:10 – 15:45 STEP WISE Approach to Project Planning,

SAVE ENERGY Case Feb. 15 14:45 – 17:30 Selecting an Appropriate Software Dev.

Approach Feb. 16 15:15 – 18:00 Activity Planning and Resource Allocation Feb. 22 14:45 – 17:30 Software Effort Estimation Feb. 23 13:15 – 15:45 Risk management, project escalation Mar. 1 14:45 – 17:00 Exam Mar. 2 13:45 – 16:30 Risk Management, Project monitoring and

control Mar. 8 14:45 – 17:30 Software Quality Assurance Mar. 9 13:45 – 16:30 Managing People; Contract Management Mar. 18 15:00 – 17:00 Trade Fair

Leiden Institute of Advanced Computer Science

3

Project control - Motivation

!  Project under way … !  Attention on ensuring progress

!   Monitoring !   Comparison !   Revision of plans and schedules


4

Project control - overview

!  The project control life-cycle !  What’s going on? Collecting control

information !  Excuses, excuses… Reporting upwards !  Doing something about it. Corrective action. !  A continual process !

!   Monitoring against plan !   Revising plan, if necessary


5

Project control – Responsibility ? !  Overall: Project Steering Committee !  Day-to-day: Project Manager

Team leader

Analysis/design section

Team leader

Programming section

Team leader

Quality control section

Team leader

User documentation section

Project manager

Steering committee Client


6

The project control life-cycle

real world

collect data

process data

define objectives

make decisions modeling

implement

data

information

decisions

actions


7

The project control life-cycle Start

Publish initial plan

Gather project information

Compare progress - targets

Satisfactory?

Completed ?

Take remedial action

Publish revised plan

End Project

Review Project

Document conclusions

End

no

no yes

yes


8

What needs controlling

!   Technical integrity !   What tasks have been

completed

!   Business integrity !   Costs of project must be

less than benefits !   Delays in implementation

reduce benefits

!   Project may be on time but only because more resources have been used than were originally budgeted

!   Conversely, project may be late because planned resources have not been used


9

What needs controlling (cont’d)

!  Quality !   A task has not really been finished unless the

product of that task is satisfactory !   Activity reported as finished could need to be re-

worked !   Testing is difficult to control: depends on an

unknown number of errors


10

Requirem. gathering

Errors

Design

More errors

Build

Even more errors

Test

Errors

Errors

Errors HELP!

The bug chain


11

Data collection

!  Partial completion reporting !   Common to enhance existing accounting data

collection systems (e.g. time sheets) to meet needs of project control

!   Asking for estimated completion time


12

Time Sheets

Project Activity Code

Description Hours this week

% complete

Scheduled completion

Estimated completion

P21 A243 Code mod A3 12 30 24/4/05 24/4/05

P34 B771 Document take-on 20 90 6/4/05 4/4/05

Name: Week ending: 30/03/05 Rechargeable Hours

Total: 32


13

Data collection

!  Risk reporting – traffic light method !   Identify key elements for assessment !   Break into constituent elements !   Assess each second-level element

•  Red / Amber / Green (Traffic light)

!   Produce overall assessment •  All second-level assessment -> first-level assessment •  Review for overall estimate


14

Risk Reporting: Red, amber, green

!   Red not on plan: recoverable only with difficulty

!   Amber not on plan: recoverable

!   Green on schedule


15

Some problems with controlling projects

!  99% completion syndrome !   Job reported as ‘on time’ until last scheduled week !   Job reported as ‘99% complete’ for each

remaining week until task is completed !  Solution?

!   Control on deliverables


16

Further problem

!  Scope creep !   Tendency for system to increase in size during

development !  Solution?

!   Re-estimating !   Change control


17

Progress checklist

!   Tasks completed !   Staffing !   Scope (more

requirements) !   External dependencies !   Cost of quality !   Finance

!   Risk analysis !   Can identify sensitive

factors that need monitoring


18

Levels of control

!   End-stage assessment (event driven)

!   Mid-stage assessment (time driven, e.g. monthly)

Checkpoint reports

Project board

Project manager (stage manager)

Project team

Checkpoint meetings e.g. weekly


19

!   As information goes to higher levels it becomes more summarized

!   General directives are filled in with operational details as they filter down

!   Danger of ‘information overload’

Information Control

Decision-making

Reporting on actions

Levels of control


20

Collecting project information

!  Sources !   Checkpoint meetings !   Time sheets !   Machine generated statistics, e.g. connect time !   Internal documents, e.g. error reports


21

Progress report

!  Avoid ‘information overload’ !  Focus on real problems - exceptions to

planned activity !  Some approaches

!   Graphical representation !   Highlight problem cases, e.g. RAG (red/amber /

green) indicators


22

Progress report (cont‘d)

!  Achievements in reporting period !   Tasks that should have been finished !   Tasks that should have been started

!  Costs - actual costs compare to budgeted !  Staffing - joiners, leavers, sickness, etc. !  Risk monitoring - status of identified risks !  Outlook

!   How things are likely to progress in next period


23

Earned value analysis (EVA)

1. Identify ‘modules’ !   Good if users can recognize these

2. Identify ‘checkpoints’ !   When a phase finishes - should be

specific and measurable

3. Identify percentage durations, e.g. !   Design 30% , code 25%, test 45%

4. Estimate size/effort for each module 5. When phase is completed for a module

!   That percentage of the project has been ‘earned’


24

Earned value:

!  0/100 technique: EV = 0% until task completed, then EV = 100%.

!  50/50 technique: EV = 50% as soon as task is started. 100% when completed.

!  Milestone technique: Based on achievement of milestones with assigned values.


25

Earned value analysis - example

Module ID

Est. hours (total)

Est. hours (total)

Design 30%

Code 25%

Test 45%

Hours % Hours % Done Hours % Done Hours % Done

A 100 47.6 30 14% y 25 12% y 45 21% n

B 50 23.8 15 7% y 12.5 6% y 22.5 11% y

C 60 28.6 18 9% y 15 7% n 27 13% n

Total 210 100 30% 18% 11%

% Total 59%

% of total (210)


26

Accumulative chart

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10 11Week number

% Com

plete

Planned

Actual


27

EVA indicators - cost !  BCWP Budgeted cost of work performed

!   = earned value EV !   = The planned (not actual) cost to complete the

work that has been done. !  ACWP Actual cost of work performed, i.e.

what it actually costs to get BCWP !   = actual cost AC !   = Cost incurred to accomplish the work that has

been done to date. !  Cost variance BCWP – ACWP = EV – AC


28

EVA indicators - schedule performance

!  BCWS Budgeted cost of work scheduled: !   BCWP that would be achieved if all work had been

finished on time !   BCWS = Planned Value PV !   = Planned cost of the total amount of work

scheduled to be performed by the milestone date. !  Budget variance ACWP – BCWS = AC-PV !  Schedule variance BCWP – BCWS = EV-PV


29

EVA performance indices

!  Cost performance indicator (CPI = EV/AC) !   BCWP/ACWP

!  Schedule performance indicator (SPI = EV/PV) !   BCWP/BCWS

!  CPI=1 – right on track !  CPI>1 – ahead of plan; cost less than budget. !  CPI<1 – falling behind. !  Value for money indices


30

Accumulative chart Baseline budget PV Planned Value, BCWS

Now

Time

Cumulative Cost %

ACWP, Actual Cost to date (AC)

Earned Value EV, BCWP

Budget variance AC-PV

Schedule variance EV-PV

Schedule variance (time)

Cost variance EV – AC (< 0)

Less work was performed than scheduled

… the actual cost for it was higher than budgeted!

CPI = BCWP/ACWP < 1 à NOT Good! SPI = BCWP/BCWS < 1 à NOT Good!


31

Graphical representation

!   Gantt charts !   Activity bar chart indicating scheduled activity dates and

duration (and floats) !   Shading (for schedule completion) and today ‘cursor‘

!   Slip charts !   Gantt chart plus slip line (bending = bad)

!   Ball charts !   Circles indicate estimated and actual start and completion

points for activities !   Green and red shading

!   Timeline charts !   Recording and displaying changed targets !   Slipping more clearly visualized!


32

Graphical representation (cont’d)

SA

SD1

SD2

CDR1

CDR2

‘Slip-chart’ red-line indicates position as of today A very uneven line suggests need for rescheduling


33

Monitoring priorities

!  Critical path activities !  Activities with no free float !  Activities with less than a specified float !  High-risk activities !  Activities using critical resources


34

Corrective action

!  Tolerance !   Acceptable margins of overshoot may be specified

in plan !  Contingency

!   This is not owned by the activity but by the project: give and take between activities

!  Exception plans !   Drawn up when the original plan needs major

change: especially change to scope or costs !   Requires project board authority


35

Some possible actions to recover project

!  Re-schedule, e.g. precedence requirements !  Make more resources available !  Redefine scope !  Modify quality requirements !  Enhance productivity, e.g. through training,

tools


36

Change control – Task changes !

!   Identification of all items that are subject to change control

!  Central repository of master copies, project documentation, and software products

!  Formal set of procedures to deal with change !  Maintenance of access rights and library item

status


37

Change control – Example

!   Users perceive need for system modification !   User management considers change request, approves, passes

to development mgmt. !   Dev. Mgmt. delegates staff member to look at request, report

practicality and cost. !   Dev. Mgmt. reports back to user mgmt. !   User mgmt. decides whether they want to go ahead. !   Developers are authorized to go ahead. !   Code is modified. !   User mgmt. is notified on completion, software is released for

user acceptance testing. !   Operational release when users are satisfied.

Education

SDPM - Lecture 7 - Project monitoring and control