4 Scheduling Monitoring

1,016 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,016
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
65
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

4 Scheduling Monitoring

  1. 1. 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
  2. 2. SoberIT Software Business and Engineering Institute What is scheduling?   Defining the activities needed for certain goal   Estimating the durations of activities   Identifying the dependencies between activities   Sequencing the activities HELSINKI UNIVERSITY OF TECHNOLOGY
  3. 3. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  4. 4. SoberIT Software Business and Engineering Institute Who tells what to do? HELSINKI UNIVERSITY OF TECHNOLOGY
  5. 5. SoberIT Software Business and Engineering Institute Defining the activities   Requirements management   Various stakeholders: customer, end user, marketing, higher management, developers, ...   How to balance between them? Resources Time Scope HELSINKI UNIVERSITY OF TECHNOLOGY
  6. 6. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  7. 7. SoberIT Software Business and Engineering Institute How long does it take? HELSINKI UNIVERSITY OF TECHNOLOGY
  8. 8. SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  9. 9. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  10. 10. SoberIT Software Business and Engineering Institute 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” HELSINKI UNIVERSITY OF TECHNOLOGY
  11. 11. SoberIT Software Business and Engineering Institute 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! HELSINKI UNIVERSITY OF TECHNOLOGY
  12. 12. SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  13. 13. SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  14. 14. SoberIT Software Business and Engineering Institute Late project Extra work Stress Low quality HELSINKI UNIVERSITY OF TECHNOLOGY
  15. 15. SoberIT Software Business and Engineering Institute What should we do first? HELSINKI UNIVERSITY OF TECHNOLOGY
  16. 16. SoberIT Software Business and Engineering Institute 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! HELSINKI UNIVERSITY OF TECHNOLOGY
  17. 17. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  18. 18. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  19. 19. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  20. 20. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  21. 21. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  22. 22. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  23. 23. SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  24. 24. SoberIT Software Business and Engineering Institute Monitoring and controlling software project HELSINKI UNIVERSITY OF TECHNOLOGY http://flickr.com/photos/jdww/322805530/
  25. 25. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  26. 26. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  27. 27. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  28. 28. SoberIT Software Business and Engineering Institute Collecting Information   Sources of data   Checkpoint meetings   Time sheets   Machine generated statistics   Configuration management data   Internal documents, e.g., error reports   Informal communication HELSINKI UNIVERSITY OF TECHNOLOGY
  29. 29. SoberIT Software Business and Engineering Institute What does “done” mean? HELSINKI UNIVERSITY OF TECHNOLOGY
  30. 30. SoberIT Software Business and Engineering Institute 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? HELSINKI UNIVERSITY OF TECHNOLOGY
  31. 31. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  32. 32. SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  33. 33. SoberIT Software Business and Engineering Institute 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)
  34. 34. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  35. 35. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  36. 36. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  37. 37. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  38. 38. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  39. 39. SoberIT Software Business and Engineering Institute Post-Its and tasks http://www.flickr.com/photos/alandd/2119855534/ HELSINKI UNIVERSITY OF TECHNOLOGY
  40. 40. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  41. 41. SoberIT Software Business and Engineering Institute Burn Down Chart - explained Remaining work Behind the schedule Ahead of the schedule Time HELSINKI UNIVERSITY OF TECHNOLOGY
  42. 42. SoberIT Software Business and Engineering Institute Burn Down Chart - explained Remaining work Variance from the Variance from the Plan in days Plan in remaining work Time HELSINKI UNIVERSITY OF TECHNOLOGY
  43. 43. SoberIT Software Business and Engineering Institute Burn Down Chart - explained 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  44. 44. SoberIT Software Business and Engineering Institute 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). HELSINKI UNIVERSITY OF TECHNOLOGY
  45. 45. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  46. 46. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  47. 47. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  48. 48. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  49. 49. SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  50. 50. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  51. 51. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  52. 52. SoberIT Software Business and Engineering Institute What can we say about the Example – project based on this chart in general? 2500 2000 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  53. 53. SoberIT Software Business and Engineering Institute What can we say about the Example – project based on this chart in general? There are two phases in this project 2500 2000 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 First phase (plan) Second phase (plan) HELSINKI UNIVERSITY OF TECHNOLOGY
  54. 54. SoberIT Software Business and Engineering Institute What can we say about the Example – project based on this chart in general? The start of second phase was delayed 2500 2000 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 First phase (plan) Second phase (plan) HELSINKI UNIVERSITY OF First phase TECHNOLOGY Second phase (actual) (actual)
  55. 55. SoberIT Software Business and Engineering Institute What is the situation: 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  56. 56. SoberIT Software Business and Engineering Institute What is the situation: Example - on day 13? 2500 Budgeted cost of work scheduled 2000 Actual cost of work performed Budgeted 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  57. 57. SoberIT Software Business and Engineering Institute What is the situation: Example - on day 13? 2500 Budgeted cost of work scheduled 2000 Actual cost of work performed Budgeted cost of work performed 1500 1000 500 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 The project was 7 days late from the original plan HELSINKI UNIVERSITY OF TECHNOLOGY = SCHEDULE VARIANCE (TIME)
  58. 58. SoberIT Software Business and Engineering Institute What is the situation: Example - on day 13? 2500 Budgeted cost of work scheduled 2000 Actual cost of work performed Budgeted cost of work performed 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  59. 59. SoberIT Software Business and Engineering Institute What is the situation: Example - on day 13? 2500 Budgeted cost of work scheduled 2000 Actual cost of work performed Budgeted cost of work performed 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  60. 60. SoberIT Software Business and Engineering Institute What is the situation: Example - on day 13? 2500 Budgeted cost of work scheduled 2000 Actual cost of work performed Budgeted cost of work performed 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 The project was 7 days late from the original plan HELSINKI UNIVERSITY OF TECHNOLOGY = SCHEDULE VARIANCE (TIME)
  61. 61. SoberIT Software Business and Engineering Institute 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) HELSINKI UNIVERSITY OF TECHNOLOGY
  62. 62. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  63. 63. SoberIT Software Business and Engineering Institute 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 HELSINKI UNIVERSITY OF TECHNOLOGY
  64. 64. SoberIT Software Business and Engineering Institute Thank you. Questions? Tuomas Niinimäki tuomas.niinimaki@soberit.hut.fi HELSINKI UNIVERSITY OF TECHNOLOGY

×