Chapter 7 - Project Scheduling

Most software projects are late and over budget, why?

  • Unrealistic deadlines established by someone outside the software engineering group
    • based on desired outcomes (time to market, need) rather than reality
    • based on a preset budget (work backward from budget to person hours)
  • Changing customer requirements
  • Honest underestimates
  • Poor risk management
    • technical risk
    • human/resource risk
  • Poor communication and training
  • Failure of management to react and recognize projects that are behind schedule

How to deal with poor initial estimates

  • Perform a detailed estimate, document with past projects. Show why the estimate is bad and the level of "magic" (productivity increase) that would be necessary to make it work.
  • Ask for one large schedule change at the beginning of the project or ask to have the functional requirements changed
  • Propose an incremental development strategy
    • Series of  releases, each with more functionality
    • The first release would have the most critical functions.
  • Clearly show the consequences of what might happen if the bad schedule is forced on the group
    • loss of key personnel
    • unkept promises to key customers
    • cost of replacing/updating poorly tested code once it is distributed
    • damage to company reputation.
  • Be prepared to explain why adding more people to the project won't get it done any sooner. (regenerative schedule disaster)

Project Scheduling Basics

  • Defined : process of distributing estimated effort across the planned project duration by allocating the effort to specific software tasks (analysis, design, code, test, install, document, train, maintain).
  • Basic principles:
    • A macro schedule should be designed first, once analysis has been completed and resources committed, then a detailed schedule can be created.
    • Compartmentalization - break project up into a number of manageable activities
      • each task should be assigned to specific team members
      • each task should have a defined outcome (work product)
      • each task should be allocated a certain number of work hours
      • each task should have a defined start and end date
    • Determine task interdependencies, which ones must come first or be completed before others can start.
    • Assign resources to the task
    • Validate schedule and dates based on available resources
    • Use project milestones to measure team progress (end of analysis phase, end of design phase, etc.)
    • Meeting or missing milestones is a function of both how well the team performed and how well the schedule was created.
    • Empirical data has shown that using fewer people over an extended period leads to greater productivity and reduced cost (at the expense of calendar completion date)
  • Effort Distribution
    • 40-20-40 rule (guideline)
      • 40% analysis and design
      • 20% code and unit test
      • 40% integration and system testing
    • Individual task types that must be scheduled and allocated
      • project planning
      • analysis
      • detailed design
      • code and unit test
      • code and design reviews
      • integration and system testing
      • documentation
      • user training
      • field/acceptance testing
      • installation/distribution
      • maintenance
    • Important milestones
      • Establishment and agreement on functional requirements.
      • Analysis and logical design complete
        • may include prototype system/user interfaces
      • Detailed user interface design complete
        • includes design review and resolution of action items
      • Database detailed design complete
        • includes design review and resolution of action items
      • Network detailed design complete
        • includes design review and resolution of action items
      • Software detailed design complete 
        • includes design review and resolution of action items
      • Code and unit test completed
        • includes code inspections and walk through and resolution of action items
      • User documentation completed
      • Integration complete (Alpha test version of software exists)
      • System testing complete (Beta test version of software exists)
        • includes QA testing  and resolution of action items
      • Acceptance testing complete (Release 1.0 exists)
        • includes customer + QA testing  and resolution of action items
      • Project delivery and installation complete

The project schedule

  • Tools:
    • Task network or PERT chart.
      • Shows all tasks and interdependencies
      • Shows critical path (tasks that must be completed on time so that the entire project is not late)
      • Shows the earliest time a task can begin and the latest time that it can complete
      • cricial path method (CPM)
    • Time line chart (GANTT) 
      • Shows start and end date for each task
      • Shows task assignments per resource
  • Steps to create:
    • Create an overall estimate of effort (chapter 5)
    • Create a complete list of tasks
    • Allocate effort to each task (revise estimate if necessary)
      • Tasks should be in the 1-3 weeks of effort in size.
      • Too large a task does not provide enough control of the process
      • Too small a task does not give workers enough freedom to plan their own activities efficiently and are easy to miss (a couple of sick days ruins the schedule)
      • Time tasks and major project reviews such that some tasks can be reported as being completed at each review (keeps management happy)
    • Determine task interdependencies
    • Create first PERT chart
    • Determine resource availability
    • Assign resources to tasks
      • assign best persons to hardest tasks and to tasks on the critical path
      • allow for project pressure to build and ease at intervals during the project (building at milestones, easing afterward). Constant building of pressure creates too much stress.
    • Validate assignments 
      • does the plan really work
      • does it assume too much overtime 
      • or too high a level of productivity out of marginal performers
      • did you allow for sick days and vacations?
    • Determine critical path, earliest complete, latest complete dates, and amount of float
To calculate the earliest complete date (Te) do the following:
1) Draw your PERT chart and fill in the Estimated time (Et) for each task
2) Start with the first task, the one on the left with no predecessors. Set its earliest complete to its estimated time (Te = Et).
3) Work from left to right following predecessor chain, for each task, the Te will be the maximum Te of its predecessors plus the task's Et. 
      Te = max(Te predecessor) + Et
To calculate the lastest complete date (Tl) do the following:
1) Start with the last task on the far right, one with no successors. Set its Tl to its Te.
2) Work backwards following predecessor links, the Tl for each task in the minimum of the Tl - Et of all its successors. 
Tl = min (Succcessor Tl - Successor Et)
To calculate slack or float
1) calculate Te and Tl and described above
2) for each task the float = Tl - Te
3) whenever the float is 0, then the task is on the critical path.
  • Schedule tracking
    • Conduct periodic status meetings
    • Evaluate results of reviews conducted (quality, number of action items, individual and team performance)
    • Monitor task start/complete dates
    • Monitor completion of milestones
    • Note: if design/analysis took longer than expected, then assume that the other phases will be longer by the same proportion. Do not assume you can make up the time during coding and testing.
    • Meet informally with team members to get subjective assessment of progress and head off problems.
    • Pay attention to your RMMM plan!

Study Guide:

Key words:

40-20-40 rule
CPM
detailed schedule
Earliest Complete
estimates
float
GANTT		 Latest complete
macro schedule
milestone
PERT		 slack
task

Problems :1,2,4,5,7