4 Scheduling Monitoring

SoberIT Software Business and Engineering Institute

HELSINKI UNIVERSITY OF TECHNOLOGY

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



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



Scheduling is builds on ...

  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

Time

Resources

Scope



Who tells what to do?



Defining the activities   Requirements management

  Various stakeholders: customer, end user, marketing, higher management, developers, ...

  How to balance between them?

Time

Resources

Scope



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



How long does it take?



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)



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

0

5

10

15

20

25

30

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

Effort

Schedule



Estimating the duration   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”



Estimating the duration   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!



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)



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)



Late project

Stress

Low quality

Extra work



What should we do first?



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!



Work breakdown structure

Project

Specification Implementation Testing Delivery

Eliciting requirements

Analyzing requirements

Writing req. specification doc.

Creating architecture plan

Implementing module A

Implementing module B

Implementing module C

Integrating modules

Testing module A

Testing module B

Testing module C

Integration testing

Acceptance testing

Installing software

Training



Activity-on-node network

Eliciting requirements

Analyzing requirements

Writing req. specification doc.

Creating architecture plan

Implementing module A

Implementing module B

Implementing module C

Integrating modules

Testing module A

Testing module B

Testing module C

Integration testing

Acceptance testing

Installing software Training



Critical path

Task 1

Task 2a

Task 2b

Task 3b

Task 4 Task 3b

Task 2c

Time

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



Critical path

Task 1

Task 2a

Task 2b

Task 3b

Task 4 Task 3b

Task 2c

Time

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

Tasks in green are on critical path, i.e. delays in these tasks delay the entire project!



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



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



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)



Monitoring and controlling software project

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



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



Levels of Control

Project board / steering group

Project manager

Project team

  Project board   Consists of e.g. higher level

managers and customers   Progress reports and/or

meetings, e.g. monthly   Inform often enough   Inform about possible problems

early enough: dividing responsibility

  Project manager reports   Project manager & project team

  Meetings and/or progress reports, e.g. weekly or even daily

Info

rmat

ion

Con

trol



Reporting Progress   Achievements in reporting

period: finished tasks   Future outlook: Planned tasks,

how things are likely to progress during next period

  Problems encountered   Focus on real problems -

exceptions to planned activity   Costs - actual costs compared to

budgeted (earned value)

  Staffing - joiners, leavers, sickness etc.

  Risk monitoring – Top-10 Risks

  Avoid ‘information overload’   When information goes

to higher management levels summarize more

  Use visualizations   graphical representation   high-light problem

cases e.g. RAG indicators



Collecting Information   Sources of data

  Checkpoint meetings   Time sheets   Machine generated

statistics   Configuration

management data   Internal documents, e.g.,

error reports   Informal communication



What does “done” mean?



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?



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?

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9

% complete

% complete



Solution?   Define what is a meant by ”a task completed”, e.g.

  Done = developer has tested it   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)

Definition of Done



Milestones   They are the checkpoints

of the process   Traditional project

management technique   Achieving a milestone

requires the team to accomplish a certain predefined set of tasks   E.g., between

process phases   Milestone reviews

  Define different level milestones for your project in the beginning of the project   A set of tasks   Assign the date

  Use them to   follow the progress   synchronize the

stakeholder expectations throughout the project life cycle

1 km

2 km

Milestone = virstanpylväs (in Finnish)



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

Release Project Cycle

Sprint 1 month

3 months

(R&D Process)



Measurement   Measurement is a practice

providing several benefits:   Status visibility   ”What you measure is

what you get” – focuses activities

  Improves morale – brings attention to chronic problems

  Helps to set realistic expectations

  Groundwork for long-term process improvement, e.g. detecting practices that work

  Collect suitable amount of data

  Start with a small set of measurements

  Analyse and give feedback, both managers and developers!

  Use automation   Provide visualizations



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



Graphical Representation: Gantt Chart

SA

SD1

SD2

CDR1

CDR2

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

time



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



Post-Its and tasks

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



Burn Down Chart   Reports the amount

of work remaining   Update continuously

(daily)   Plot across time   May go up   Commonly used by

agile methods

Remaining work

Time Remaining work

Estimate



Burn Down Chart - explained Remaining work

Time

Behind the schedule

Ahead of the schedule




Time

Variance from the Plan in days

Variance from the Plan in remaining work




Time

At first, work is progressing as planned

New work gets added or

Planned work is re-estimated to take more effort

Work is being done faster than anticipated



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).



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



Example

0

50

100

150

200

250

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

Work scheduled

Work performed



Example – Work scheduled explained

0

50

100

150

200

250

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

Work scheduled

Work performed

200 work items to be created

20 days to do it



0

50

100

150

200

250

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

Work scheduled

Work performed

Work performed explained

At first, this project is progressing better than planned

Around day 7, project faces some problems, and the pace is slowed down

Problems are solved, and project starts to progress at planned pace

Original End date

Extra time (3 days) was needed



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)



Earned value, part 2   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



Example

0

500

1000

1500

2000

2500

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

Budgeted cost of work scheduled

Actual cost of work performed

Budgeted cost of work performed

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

What is the situation:

- at the end (day 18)?

- on day 13?



Example –

0

500

1000

1500

2000

2500

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







Example –

0

500

1000

1500

2000

2500

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





There are two phases in this project

First phase (plan) Second phase (plan)



Example –

0

500

1000

1500

2000

2500

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





The start of second phase was delayed

First phase (plan) Second phase (plan)

First phase (actual)

Second phase (actual)



Example

0

500

1000

1500

2000

2500

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




About half of the Value (= features) was Created = SCHEDULE VARIANCE (COST)


- at the end (day 18)?

All budgeted money was spent on the project

The project was 6 days late from the original plan

= SCHEDULE VARIANCE (TIME)



Example

0

500

1000

1500

2000

2500

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



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


- on day 13?



Example

0

500

1000

1500

2000

2500

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





- on day 13?





Example

0

500

1000

1500

2000

2500

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





- on day 13?

The project had spent less Money than planned

= BUDGET VARIANCE



Example

0

500

1000

1500

2000

2500

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





- on day 13?

The project had spent more than planned to create the value

= COST VARIANCE



Example

0

500

1000

1500

2000

2500

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



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


- on day 13?



The project had spent less Money than planned

= BUDGET VARIANCE

The project had spent more than planned to create the value

= COST VARIANCE



Earned value, part 3   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)



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



Important in Monitoring and Control   Plan monitoring and control

practices in the beginning of the project

  Monitor the progress very frequently, e.g. daily or weekly

  Give immediate feedback to   managers   team members

  React to deviations fast

  Pay attention to terms used:   Use HOURS when talking

about efforts   Use DATES when talking

about schedule   Do not mix estimated

efforts and calendar time!!!



Thank you.

Questions?

Tuomas Niinimäki

[email protected]

4 Scheduling Monitoring

Documents

soberit software business

software development

engineering institutedefining

engineering institutewhat

engineering instituteeffort

engineering institutet

engineering domains

engineering institutewho