4 Scheduling Monitoring

SoberIT
Software Business and Engineering Institute

T-76.5612 Software Project Management
Spring 2010

4: Scheduling, monitoring and controlling software project

Tuomas Niinimäki
Software Process Research Group
SoberIT
Helsinki University of Technology

HELSINKI UNIVERSITY OF TECHNOLOGY

SoberIT

What is scheduling?
  Defining the activities needed for certain goal
  Estimating the durations of activities
  Identifying the dependencies between activities
  Sequencing the activities


SoberIT

Resources
Scheduling is builds on ...

Time Scope

  Resource management
  Making sure that needed resources are available
  Cost management
  The cost of activities is acceptable
  Specification of deliverables
  The scope and the quality of deliverables is defined


SoberIT

Who tells what to do?


SoberIT

Defining the activities
  Requirements management
  Various stakeholders: customer, end user, marketing, higher
management, developers, ...
  How to balance between them?

Resources

Time Scope


SoberIT

Defining the activities
  Setting the quality targets
  Quantity over quality?
  What is the purpose of the developed product?

  What is good enough?
  Medical equipment vs. UI prototype


SoberIT

How long does it take?


SoberIT

Estimating the duration
  The relationship between the number of staff working on a
project, the total effort required and the development time is not
linear
  Adding more people increases the need for communication and
management of work activities
  Software project work cannot be partitioned infinitely (Brooks, 1984)


SoberIT

Effort and schedule – non-linear
  The actual relation between schedule months and person months

schedule months = 3.0 * (person months)1/3
(McConnell, 1994)

  Example: 65 person-months -> schedule 12 months -> 5-6 developers
30

25

20

15 Effort
Schedule
10

5

0
1 3 5 7 9 11 13 15 17 19 21 23

SoberIT

  Only 60-70% of work time is used on “real” work
  General staff meetings
  Talking with colleagues
  Drinking coffee, surfing on the web, ...

  Not all of this is inherently harmful for the project!

  Plan for contingencies
  Sick leaves
  Parental leaves
  Other projects “just borrowing a resource”


SoberIT

  Estimating the schedule may be trivial, but to get a realistic
schedule accepted can be the most difficult part of the project

(McConnell, 1994)

  Prepare to have good reasoning behind your schedule estimates
  Do not present overly optimistic schedules
  They will be accepted!
  They will guarantee your project will be late!

  If the schedule is fixed, cut down the scope!


SoberIT

The root causes of overly optimistic
schedules
  External, immovable deadline (e.g. Christmas shopping)
  Top management, marketing or a customer want a particular
deadline, and the project manager can’t talk them out of it
  The project is deliberatelly underestimated by management or
sales in order to submit a winning bid
  The project manager believes that developers will work harder if
the schedule is ambitious
  The project begins with a realistic schedule, but new features are
piled on to the project
  The project is simply estimated poorly
  Developers underestimate an interesting project in order to get
funding to work on it

(McConnell, 1994)


SoberIT

The effects of overly optimistic
schedule
  Late project
  Low-quality product
  Stress
  Non-motivated developers
  High turnover; reduced loyalty
  Strained relations among developers, managers,
customers, marketers and other project stakeholders
  Weakened capacity to develop the next product

(McConnell, 1994)


SoberIT

Late project

Extra work Stress

Low quality


SoberIT

What should we do first?


SoberIT

Scheduling fixed-scope projects
  Do a work breakdown and effort estimates for the tasks
  Identify task dependencies
  In software development, many tasks are not as dependent
on each other as they might be in some other engineering
domains
  With proper interface specification, modules are less
dependent on each others’ implementation
  Construct a network model, do forward and backward
pass to identify the critical path
  Activity-on-node network
  Remember to add contingencies!


SoberIT

Work breakdown structure

Project

Specification Implementation Testing Delivery

Eliciting Implementing Testing Installing
requirements module A module A software
Analyzing Implementing Testing
Training
requirements module B module B
Writing req. Implementing Testing
specification doc. module C module C
Creating Integrating Integration
architecture plan modules testing
Acceptance
testing


SoberIT

Activity-on-node network
Eliciting Analyzing Writing req. Creating
requirements requirements specification doc. architecture plan

Testing
Implementing module A
module A Integrating Integration
Testing modules testing
Implementing module B
module B

Implementing Testing
module C module C

Acceptance Installing
Training
testing software


SoberIT

Arrows denote the task dependencies
Box length represent the task effort/schedule
Critical path

Task 2a Task 3b

Task 1 Task 2b Task 3b Task 4

Task 2c

Time


SoberIT

Arrows denote the task dependencies
Box length represent the task effort/schedule
Critical path Tasks in green are on critical path, i.e. delays
in these tasks delay the entire project!

Task 2a Task 3b

Task 1 Task 2b Task 3b Task 4

Task 2c

Time


SoberIT

Scheduling iterative and incremental
projects
  The understanding of the project increases when the
project progresses
  We know more what we are supposed to do
  We know better how long it will take
  Customer also knows more what she wants
  Changes are expected
  ... and we are prepared


SoberIT

Scheduling iterative and incremental
projects
  In the outset of the project
  Commit to target dates and objectives at macro-level
  Plan the length and number of iterations
  In each iteration
  Explicitly allow the variation of scope
  Plan the next iteration
  Discuss the contents of the project with the stakeholders
  The customer can help in prioritizing the requirements
  Developers can help in estimates


SoberIT

Prioritizing the requirements
  Rank requirements by risk, coverage and criticality
  Risk: All risks related to requirements (e.g. technical
complexity, effort uncertainty)
  Coverage: Major parts of the system are at least
touched on in the early iterations
  Criticality: High business value (e.g. customer’s
prioritization)


SoberIT

Monitoring and controlling software project


http://flickr.com/photos/jdww/322805530/

SoberIT

Monitoring and Control
  Monitoring:
  What is happening?
  Compare to the plan
  Control:
  Use monitoring information
  React to slippage
  Replan to bring the project back on target or revise the target


SoberIT

Levels of Control
  Project board
Project board /
steering group
  Consists of e.g. higher level
managers and customers
  Progress reports and/or
Control

meetings, e.g. monthly
  Inform often enough
Information
Project manager
  Inform about possible problems
early enough: dividing
responsibility
  Project manager reports
Project team   Project manager & project team
  Meetings and/or progress
reports, e.g. weekly or even daily

SoberIT

Reporting Progress
  Achievements in reporting   Avoid ‘information
period: finished tasks overload’
  Future outlook: Planned tasks,   When information goes
how things are likely to progress to higher management
during next period levels summarize more
  Problems encountered   Use visualizations
  Focus on real problems -   graphical representation
exceptions to planned activity   high-light problem
  Costs - actual costs compared to cases e.g. RAG
budgeted (earned value) indicators
  Staffing - joiners, leavers, sickness
etc.
  Risk monitoring – Top-10 Risks

SoberIT

Collecting Information
  Sources of data
  Checkpoint meetings
  Time sheets
  Machine generated
statistics
  Configuration
management data
  Internal documents, e.g.,
error reports
  Informal communication


SoberIT

What does “done” mean?


SoberIT

What does “done” mean?
  Developer has written 250 lines of code for a program that was
estimated to require 500 lines of code
  Why would it be unreasonable to assume that the task is 50 %
complete?


SoberIT

What does “done” mean? A variation
  90% completion syndrome
  job reported as ‘on time’ until last scheduled week
  job reported as ‘90% complete’ for each remaining week
until task is completed

  Solution? % complete
100

80

60

40 % complete

20

0
1 2 3 4 5 6 7 8 9


SoberIT

Solution?
  Define what is a meant by ”a task completed”, e.g.
  Done = developer has tested it Definition of Done
  Done = task has been documented & integrated
  Done = customer has accepted the feature
  Control on deliverables: report only finished tasks
  0-100 rule:
  task completion is 0%, unless
  the task is finished = 100% complete
  0-50-100 rule:
  task completion is 0% initially,
  50% when someone is working on it, and
  100% when the task is finished
  Estimation & WBS: small enough tasks (a few hours – a few days)


SoberIT

Milestones
  They are the checkpoints   Define different level
of the process milestones for your project in
  Traditional project the beginning of the project
management technique
  A set of tasks
  Achieving a milestone
  Assign the date
requires the team to
accomplish a certain   Use them to
predefined set of tasks   follow the progress
  E.g., between   synchronize the
process phases stakeholder expectations
  Milestone reviews throughout the project life
cycle

1 2
km km
HELSINKI UNIVERSITY OF TECHNOLOGY Milestone = virstanpylväs (in Finnish)

SoberIT

Control Points
  Control points are time-paced, i.e., they occur
at regular intervals

  For example in Scrum:
  Release cycle, 3 months
  Sprint, 1 month
  Daily scrum meetings
Strategic Release Management

(R&D Process)

Release Project Cycle 3 months

Sprint 1 month


SoberIT

Measurement
  Measurement is a practice   Collect suitable amount of
providing several benefits: data
  Status visibility   Start with a small set of
  ”What you measure is measurements
what you get” – focuses
activities
  Analyse and give feedback,
both managers and
  Improves morale – brings developers!
attention to chronic
problems
  Helps to set realistic   Use automation
expectations   Provide visualizations
  Groundwork for long-term
process improvement,
e.g. detecting practices
that work

SoberIT

Visualizing Progress
  Visualization enables to see the project progress quickly and
notice the possible slippage
  Stakeholders need the transparency of project progress
  Team members -> motivation
  Management -> possibility to react
  Customer -> payments

  Several ways to visualize progress:
  Choose the one best suitable for your project
  Update frequently
  React to problems


SoberIT

Graphical Representation: Gantt Chart

SA

SD1

SD2

CDR1

CDR2

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


SoberIT

Traffic-light Assessment
Week 1 2 3 4 5 6 Comments
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
...

  Red not on plan: recoverable only with difficulty
  Amber not on plan: recoverable
  Green on schedule

SoberIT

Post-Its and tasks

http://www.flickr.com/photos/alandd/2119855534/

SoberIT

Burn Down Chart
Remaining
work   Reports the amount
of work remaining
  Update continuously
(daily)
  Plot across time
  May go up
  Commonly used by
agile methods

Remaining work
Time
Estimate


SoberIT

Burn Down Chart - explained
Remaining
work
Behind the schedule

Ahead of the schedule

Time


SoberIT

Remaining
work

Variance from the Variance from the
Plan in days Plan in remaining
work

Time


SoberIT

Remaining
work At first, work is
progressing as
planned

Work is being done faster
than anticipated
New work gets added or

Planned work is re-estimated
to take more effort

Time


SoberIT

Earned value management
  Essential features of any EVM implementation include
  a project plan that identifies work to be accomplished,
  a valuation of planned work, called Planned Value (PV) or
Budgeted Cost of Work Scheduled (BCWS), and
  pre-defined “earning rules” (also called metrics) to quantify
the accomplishment of work, called Earned Value (EV) or
Budgeted Cost of Work Performed (BCWP).


SoberIT

Earned value
  Work Scheduled (WS):
  Work to be done, according by the project plan

  Work Performed (WP):
  Actual work completed

  If WP > WS, project is ahead of the original plan
  If WP < WS, project is running late


SoberIT

Example
250

200

150

Work scheduled
Work performed
100

50

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23


SoberIT

Example – Work scheduled explained
250
20 days to do it

200

150
200 work
items to Work scheduled
be created Work performed
100

50

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23


SoberIT

Work performed explained Original
End date
250

200

Extra time
Problems are solved,
(3 days)
150 and project starts to
was needed
progress at planned pace
Work scheduled
Work performed
100
At first, this project is
progressing better
than planned
50
Around day 7, project faces
some problems, and the pace
is slowed down
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23


SoberIT

Earned value, part 2
  Work Scheduled (WS):
  Work to be done, according by the project plan
  Has planned value: Budgeted Cost of Work Scheduled (BCWS)

  Work Performed (WP):
  Actual work completed
  Earned value = Budgeted Cost of Work Performed (BCWP)
  Actual expenses = Actual Cost of Work Performed (ACWP)


SoberIT

  Budgeted Cost of Work Scheduled = BCWS
  = how much money is going to be spent based on the plan

  Budgeted Cost of Work Performed = BCWP
  = Earned Value
  = we plan to charge this money from the completed work
  = the performed work is worth this much money to someone

  Actual Cost of Work Performed = ACWP
  = we have spent this amount of money to get the results we
have


SoberIT

What can we say about the
Example project based on this chart in
general?

What is the situation:
2500

- at the end (day 18)?

2000
- on day 13?

1500

Budgeted cost of work scheduled
Actual cost of work performed
1000 Budgeted cost of work performed

500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


SoberIT

Example – project based on this chart in
general?

2500

2000

1500


500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


SoberIT

general?

There are two phases in this project
2500

2000

1500


500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

First phase (plan) Second phase (plan)

SoberIT

general?

The start of second phase was delayed
2500

2000

1500


500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

First phase (plan) Second phase (plan)
HELSINKI UNIVERSITY OF First phase
TECHNOLOGY Second phase
(actual) (actual)

SoberIT

Example - at the end (day 18)?

2500
All budgeted money was
spent on the project
2000

1500
About half of the
Value (= features) was Budgeted cost of work scheduled
Created Actual cost of work performed
1000
= SCHEDULE VARIANCE
Budgeted cost of work performed
(COST)

500

The project was 6 days late
from the original plan
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 = SCHEDULE VARIANCE
(TIME)


SoberIT

Example
- on day 13?
2500

2000 Actual cost of work performed
Third of the value (= features) was created
= SCHEDULE VARIANCE (COST)
1500

1000

500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


SoberIT

Example
- on day 13?
2500


1500

1000

500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

= SCHEDULE VARIANCE (TIME)

SoberIT

Example
- on day 13?
2500


The project had spent less
1500
Money than planned

= BUDGET VARIANCE
1000

500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


SoberIT

Example
- on day 13?
2500


1500

1000
The project had spent more
than planned to create the
value
500
= COST VARIANCE

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


SoberIT

Example
- on day 13?
2500

Third of the value (= features) was created
= SCHEDULE VARIANCE (COST) The project had spent less
1500
Money than planned

= BUDGET VARIANCE
1000
The project had spent more
than planned to create the
value
500
= COST VARIANCE

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

= SCHEDULE VARIANCE (TIME)

SoberIT

  Schedule variance:
  Cost: Difference between budgeted cost of work performed
(BCWP) and budgeted cost of work scheduled (BCWS)
  Time: Difference between now and the date when currently
completed work should have been completed by the plan
  Cost variance:
  Difference between actual cost of work performed (ACWP)
and budgeted cost of work performed (BCWP)
  Budget variance:
  Difference between budgeted cost of work scheduled (BCWS)
and actual cost of work performed (ACWP)


SoberIT

Possible Actions to Recover Project
  Re-schedule
  Make more resources available
  Redefine scope – leave some features to next versions
  Modify quality requirements
  Enhance productivity e.g. through training, tools


SoberIT

Important in Monitoring and Control
  Plan monitoring and control   Pay attention to terms used:
practices in the beginning of   Use HOURS when talking
the project about efforts
  Monitor the progress very   Use DATES when talking
frequently, e.g. daily or about schedule
weekly   Do not mix estimated
  Give immediate feedback to efforts and calendar
  managers time!!!
  team members
  React to deviations fast


SoberIT

Thank you.

Questions?
Tuomas Niinimäki

tuomas.niinimaki@soberit.hut.fi


4 Scheduling Monitoring

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (8)

Similar a 4 Scheduling Monitoring

Similar a 4 Scheduling Monitoring (20)

4 Scheduling Monitoring