Scheduling and Tracking

• Schedule Development
• Work Breakdown Structure (WBS)
• Network Analysis
• Scheduling Workflow
• PERT Estimation Technique
• Project Tracking

• Schedule development is the culmination of the other Project Time Management processes we have discussed:
  • Activity definition
  • Activity sequencing
  • Activity resource estimating
  • Activity duration estimating
• It is an iterative process to determine planned start and finish dates for activities
• It is a continuous process throughout project, addressing approved changes and risks^①

• Project scope statement
  • Scope statement is the source of assumptions and constraints on the project
  • (PMI) “ Assumptions are those documented, schedule-related factors that, for schedule development purposes, are considered to be true, real, or certain.”^①
  • (PMI) “ Constraints are factors that will limit the project management team‘s options when performing schedule network analysis.” ex: “only use internal HR”
  • Date constraints (contract dates, market windows, external deliveries) and milestones (deliverable dates) are of greatest importance in schedule development
• Project management plan (document)
  • Almost any of the many sub-plans (resource management plan, quality assurance plan, etc.) and other elements in the Project Management Plan may exert an influence on schedule development
  • One of the most critical elements for schedule development in the PM Plan is the risk register and risk-associated plans^②

• 1.0 Retail Web Site
  • 1.0 Project Management
  • 2.0 Requirements Gathering
  • 3.0 Analysis & Design
  • 4.0 Site Software Development
    • 4.1 HTML Design and Creation
    • 4.2 Backend Software
      • 4.2.1 Database Implementation
      • 4.2.2 Middleware Development
      • 4.2.3 Security Subsystems
      • 4.2.4 Catalog Engine
      • 4.2.5 Transaction Processing
    • 4.3 Graphics and Interface
    • 4.4 Content Creation
  • 5.0 Testing and Production^①

• Generic term for discrete unit of work with definable end results
• The “one-to-two” rule
  • Often sized for: 1 or 2 persons for 1 or 2 weeks^①
• Basis for monitoring and reporting progress
  • Can be tied to budget items (charge numbers)
  • Resources (personnel) assigned
• Ideally shorter rather than longer
  • Longer makes in-progress estimates needed
  • These are more subjective than “done”
  • “4/40” or “8/80” rule ( shortest/longest duration): sizing from 4 to 40 hours to avoid micromanagement, or 8 to 80 max to ensure visibility.
  • Not so small as to micro-manage^②

• PM must map activities to chosen lifecycle
• Each lifecycle has different sets of activities
• Common process activities occur for all lifecycle models (waterfall, agile, etc.): Planning, configuration, testing
• Operations and maintenance phases are not normally in plan (considered post-project)
• Some models are “straightened” for WBS
  • Spiral and other iterative models -> Linear sequence several times (design Iteration 1 -> Design iteration 2, etc.)
• Deliverables of tasks vary by methodology (waterfall: requirements doc, for Agile: User sories)^①

• Top-Down: Start with the overall project goal or deliverable, then break it down into major components and subcomponents.
• Bottom-Up: Start by identifying detailed tasks or activities, then group them into higher-level categories.
• Analogy: Use a WBS from a similar past project as a template, adapting it to the current context.
• Rolling Wave: Plan at a high level initially, then add detail as more information becomes available:
  • 1 st pass: go 1-3 levels deep
  • Gather more requirements or data
  • Add more detail later
• All WBS Techniques rely upon Expert Judgment^① !

• Top-down
  • Start at highest level
  • Systematically develop increasing level of detail
  • Best if
    • The problem is well understood
    • Technology and methodology are not new
    • Project is similar to an earlier project or problem
  • But is also applied in majority of situations^①

• Bottom-up
  • Start at lowest level tasks
  • Aggregate into summaries and higher levels
  • Cons
    • Time consuming
    • Needs more requirements complete
  • Pros
    • Detailed^①

• Analogy
  • Base WBS upon that of a “similar” project
  • Use a template
  • Pros
    • Based on past actual experience
  • Cons
    • Needs comparable project^①

• Brainstorming
  • Generate all activities you can think of that need to be done
  • Group them into categories
• Both Top-down and Brainstorming can be used on the same WBS
• Remember to get the people who will be doing the work involved (buy-in matters!)^①

• Network scheduling
• Costing
• Risk analysis
• Organizational structure
• Control
• Measurement^①

• Should be easy to understand
• Some companies have corporate standards for these schemes
• Some top-level items, like Project Mgmt. are in WBS for each project
  • Others vary by project
• What often hurts most is what’s missing
• Break down until you can generate accurate time & cost estimates
• Ensure each element corresponds to a deliverable^①

• Network analysis is the technique that generates the project schedule
• Network analysis may use several different analysis methods to calculate the early and late start dates for project activities. These methods may be combined and include:
  • Gantt Charts
  • Critical Path Method (CPM)
  • Critical Chain Method (CCM)
  • What-if analysis
  • Resource leveling^①

• There are a number of network analysis techniques available – we will concentrate on the Critical Path Method (CPM)
• The Precedence Diagram Method (PDM) is a graphical network technique that establishes activity sequencing
• Network analysis may also make use of parallelism in project activities to allow schedule compression^①

• Activity. An activity always consumes time and may also consume resources. I use task and activity equivalently
• Critical. A critical activity or event is one that must be achieved by a certain time, having no latitude (slack or float)
• Critical path. The critical path is the longest path through a project network. Because it has no slack, all activities on the critical path must be completed as scheduled, or the end date will slip^①
• Events. Beginning and ending points of activities are known as events. An event is a specific point in time
• Milestone. An event representing a point in a project of special significance. Usually the completion of a major phase of the work. Project reviews are often conducted at milestones^②

• A Precedence table documents task durations and interdependencies
• Include duration estimation of each task
  • Any potentially risky task (technology, skills, dependencies) should include contingency factor
  • Include contingencies to mitigate potential resource shortages
• Determining task interdependencies
  • Goal is to determine predecessor/successor relations
  • Understanding interdependencies allows proper ordering in scheduling tasks
  • Understanding interdependencies also helps in finding possible parallel tasks, which can shorten schedule
  • Determining task interdependencies must be a team effort to avoid unpleasant surprises^①

Program Evaluation & Review Technique or PERT developed to handle

uncertainty in activity durations

• Identify the tasks (or activities) required to complete the given project and their dependencies.
• Estimate durations using three-point estimation: PERT uses optimistic, pessimistic, and most likely time estimates to calculate expected durations using the formula: Expected Time(TE)= (O+4M+P) / 6
• Construct "network diagram" of the activities and their dependencies, each event (milestone) is represented by a node, arrows represent activities^①

• Widely used three-point estimate with PERT (Program Evaluation and Review Technique)
• Defines three estimate points as:
  • Most likely: estimate that occurs with greatest frequency
  • Optimistic: shortest duration, taken as 10th percentile value
  • Pessimistic: longest duration, taken as 90th percentile value
  • PERT activity duration estimate T_E and its standard deviation (s_E or σ) are calculated according to:

T_E = (E_optimistic + 4·E_most_likely + E_pessimistic) / 6

s_E = (E_pessimistic − E_optimistic) / 6^①

• s_E measures the uncertainty or variability in the estimate.

• Slack time, also known as float, is the amount of delay expressed in units of time that could be tolerated in the starting time or completion time of an activity without causing a delay in the completion of the project.
• Slack time is the difference between the late finish and the early finish (LF-EF)^①. If the result is greater than zero, then the activity has a range of time in which it can start and finish without delaying the project completion date.
• If an activity has zero slack, it determines the project completion date. In other words, all the activities on the critical path must be done on their earliest schedule or the project completion date will suffer.
• If an activity with total slack greater than zero was delayed beyond its late finish date, it becomes a critical path activity and causes the completion date to be delayed.
• The sequence of activities that has zero slack is defined as the critical path
• In general, the critical path is the path that has 0 slack.^②

• The critical path method (CPM) focuses on calculating theoretical start and finish dates for every activity in the project.
• CPM performs these calculation without regard for resource limitations, which can lead to resource over-allocation or inefficient multitasking
• A forward pass analysis performs schedule calculations that identify the early start and finish dates of activities and the project^①
• A backward pass analysis performs schedule calculations that identify the late start and finish dates of activities and the project, as well as total and free float^②
• Total float (TF) is the amount of time an activity can be delayed without delaying the project as a whole
• Free float (FF) is the amount of time an activity can be delayed without delaying its successor (dependent) activities
• Note that total float is global to the project, while free float is local to the neighborhood of the activity^③

Gantt Chart (named for Henry Laurence Gantt) consists of a table of

A

project task information and a bar chart that graphically displays project schedule, depicting progress in relation to time and often used in planning and tracking a project.

• Horizontal bar chart format, with bars representing the phases and activities of the WBS
• Time extends along the horizontal axis
• Able to show planned and actual progress on tasks as well as task dependencies^①
• Effective communication tool but with limitations
  • Very low information density: lots of wasted space
  • Not very useful for large projects^②

• Advantages:
  • Easy to understand
  • Easy to change^①
• Disadvantages:
  • Only a vague description of the project
  • Does not always show interdependency of activities
  • May not show results of an early or late start of an activity^②

• The critical chain method (CCM) is a project management technique that is an improvement of the Critical Path Method as it takes into account the availability of resources.
• In software engineering projects, CCM can be used to identify and manage critical tasks, reduce project risk, and improve project delivery time.
• CCM focuses on the resources required for project activities, attempting to keep them leveled throughout the project
• CCM, assumes that all activities have a statistically-probable range of durations and uses this assumption to create a more flexible and resilient schedule
• Resources are assigned to the activities using the most likely durations
• The longest sequence of activities in the project is called the critical chain^①

• Suppose a software development team is tasked with developing a new mobile application.
• The project timeline is six months, and the team must deliver a functional prototype at the end of the fourth month.
• To manage the project using CCM, the following steps could be taken:

1. Identify the critical tasks: The team would begin by identifying the critical tasks that must be completed to deliver the functional prototype on time. These tasks might include developing the user interface, integrating with external APIs, and testing the application.^①

1. Estimate task duration: Once the critical tasks have been identified, the team would estimate the duration of each task, taking into account any potential delays or obstacles that might arise during the development process.
2. Create a buffer: To account for potential delays and risks, the team would create a buffer at the end of the project timeline. This buffer would be used to ensure that the functional prototype is delivered on time, even if some tasks take longer than expected.
3. Manage the critical chain: Using CCM, the team would manage the critical chain of tasks by focusing on the critical tasks and ensuring that they are completed on time.^① This might involve reallocating resources, adjusting task priorities, or providing additional support to team members as needed.
4. Monitor progress: Throughout the project, the team would monitor progress and adjust the project plan as needed. This would help to ensure that the project stays on track and that the critical tasks are completed on time.

• Buffer Types:
  • Project buffer
    • Contingency time to the whole project inserted at end of the project.^① Any delay in the Longest Path will consume some or all of the buffer.
  • Feeder buffers
    • inserted at the point where non-critical chains feed into the critical chain. This is to ensure that any tasks feeding into the Critical Chain may not delay the Critical Chain.
  • Resource buffers
    • Alerts or placeholders to ensure critical resources are ready when needed.^②

• It is a scenario-based analysis of schedule to determine effects of various scenarios on different aspects of the project
  • Example Delay delivery of a critical component by various amounts to determine effect : on schedule; “COTS supplier is unable to provide a critical component at all”

What-if scenario analysis

• effectively tests the robustness of the project schedule in response to adverse circumstances
• Most common technique uses Monte Carlo simulation to generate a population of possible project schedule outcomes
  • Think of executing the same project 10,000 times with the same resources, different boundary conditions, and no memory between executions
• Very useful in preparing contingency and response plans for project risks^①

• Resource leveling (smoothing a surface) is applied to a schedule analyzed by CPM
• Addresses situation where resource availability is constrained by time or amount of the resource available
• May also be used to keep resource usage at a constant level during certain time periods in the project
• Resource leveling is needed when resources have been over-allocated or assigned to two or more activities in the same time period
• May change the critical path^① in the schedule model

• Uses a number of different approaches, including:
  • Assign under-allocated resources to multiple tasks to keep them busy
  • Move key resources off of non-critical tasks
  • Delay start of task until required resources are available, possibly using lags
  • Split tasks into two or more subtasks so the subtasks can be assigned to different resources^①

• Project schedule network diagrams
  • Show both project network logic (sequencing) as well as critical path schedule activities
  • Usually displayed as an activity-on-node diagram
• Gantt charts
  • Specialized bar charts format to show activity start and end dates, along with durations
  • Easy to read but limited by low information density
• Milestone charts
  • ‘Stripped-down’ version of Gantt chart, showing only milestones^①

• How can you shorten the schedule?
• Via
  • Reducing scope (or quality)
  • Adding resources
  • Concurrency (perform tasks in parallel)
  • Substitution of activities^①

• Shortens the project schedule without changing the project scope, to meet schedule constraints, imposed dates, or other schedule objectives
• There are two types of schedule compression, crashing and fast-tracking
• Crashing. Analyzes cost and schedule trade-offs to get the greatest amount of compression with the least cost:^①
  • Add resources to critical path tasks, be more efficient, changing approach used to perform work, work overtime
  • Limit or reduce requirements (scope)
  • Changing the sequence of tasks

• Fast-tracking . Activities that would normally be done sequentially are done in parallel.
  • Fast-tracking can lead to rework and increased risks due to unforeseen dependencies: Involves some risk^①
  • Fast-tracking only works when activities can be overlapped to shorten the total duration

For both schedule compression approaches, you cannot compress more than 25% (According to Boehm)^②

• Book: “ The Mythical Man-Month ”
  • Author: Fred Brooks
• “ The classic book on the human elements of software engineering ”
• First two chapters are full of terrific insight (and quotes)

Sample Quotes

• “Cost varies as product of men and months, progress does not.”: progress does not scale linearly. Adding more people doesn’t necessarily mean faster progress.
• “Hence the man-month as a unit for measuring the size of job is a dangerous and deceptive myth”: A unit that assumes one person working for a month is equivalent to two people working for half a month^①

• Why is software project disaster so common?

1. Estimation techniques are poor & assume things will go well (a very optimistic ‘unvoiced’ assumption)
2. Estimation techniques falsely confuse effort with progress, hiding the false assumption that (You can just throw more people at a problem and expect linear acceleration.)
3. Managers often don’t push back against unrealistic deadlines or vague estimates: Good managers defend the integrity of the schedule, even when it’s unpopular.
4. Schedule progress is poorly monitored: Without clear metrics, slippage goes unnoticed until it’s too late.
5. When schedule slippage is recognized, the natural response is to add manpower. Which, is like dousing a fire with gasoline: Brooks’s Law: “Adding manpower to a late software project makes it later.”^①

• Over-Optimism
  • “All programmers are over-optimists”
  • 1st false assumption: “all will go well” or “each task takes only as long as it ‘ought’ to take”
  • The Fix: Consider the larger probabilities
• Cost (overhead) of communication (and training)
  • nb_communication_channels = n(n-1)/2, O(n²), n: number of team members^①
• How long does a 12 month project take?
  • 1 person: 12 months
  • 2 persons = 7 months (2 man-months extra)
  • 3 persons = 5 months (3 man-months extra)^②
  • Fix: don’t assume adding people will solve the problem

• What is the most mis-scheduled part of process?
  • Testing (the most linear process)
  • delays in earlier phases compress the time available for testing
  • Why is this particularly bad?
    • Occurs late in process and without warning
    • Higher costs:
      • Primary cost: Time and effort to fix bugs.
      • Secondary cost: Rework, missed deadlines, reputational damage, or even system failure if bugs escape into production.
  • Fix: Allocate more test time
    • Understand task dependencies (testing depends on completed, integrated components)^①

Reliance on intuition and guesses

• What is ‘gutless estimating’? Estimators don’t push back on unrealistic deadlines.
• Q: “How does a project get to be a year late”?
  • A: “One day at a time”: Missed check-ins ( Regular project reviews or sync points that are skipped, delayed, or done superficially ), Untracked slippage, Quiet scope creep
• Studies show that:
  • Each task: twice as long as estimated
  • Only 50% of work week was programming
• Fixes
  • No “fuzzy” milestones: avoid vague goals like “almost done”: use measurable deliverables.
  • Reduce the role of conflict: Encourage honest dialogue between developers and managers.
  • Identify the “true status”: Use metrics, demos, and progress tracking to know where things really stand.^①

• Define activities
  • Use of WBS template helps guide definition process and organize activities
• Perform activity sequencing
  • Develop schedule framework according to what is logically possible – perform resource allocation later
• Estimate effort – the total number of labor units ( staff-days) for e.g. each activity
• Identify resources for each activity
• Apply calendars to schedule framework^①

• Estimate activity duration based on resources for activity
• Perform forward pass and backward pass critical path analysis to generate schedule model
• Perform ‘what-if’ scenario analysis to identify contingency and risk response needs
• Apply resource leveling to schedule model
• Apply schedule compression, if needed^①

• Illusion of Progress: The early phases (design/specification) are done, which can give a false sense of completion. The reader of the table may get a feeling that around 50% of the project is done, but the most effort-intensive and risk-prone phases, coding and testing, are still underway or not even started: What is the actual percentage?^①

Task — How complete?

• Conceptual Design: 200/200
• Program Specification: 300/300
• Coding: 150/600
• Documentation: 10/100
• User Manual Production: 0/400
• Testing: 0/500

660 / 2100 × 100 = 31.4% complete^①

Setup :

1. Establish a WBS to divide the project into manageable components
2. Identify the activities required under each WBS element
3. Estimate the effort required for each activity (assign labor hours or cost)
4. Schedule tasks: start/end dates and resources
5. Assign planned value to each task

Execution :

1. Update the schedule by reporting activity progress (% complete for each task)
2. Record actual costs on the activities (real expenditures)
3. Calculate EV metrics: compute EV, PV, AC, CPI, SPI
4. Analyze the data (variance): CV = EV – AC; SV = EV - PV
5. Take corrective action: Reallocate resources, adjust scope, revise schedule, etc.^①

• Total Budget: 1000 person-hours
• Task A: Estimated 100 hours
  • Planned Value (PV) = 100
  • Actual Cost (AC) = 120
  • % Complete = 100% → Earned Value (EV) = 100
• Cost Performance Index: CPI = 100 ÷ 120 = 0.83 → Over budget
• Schedule Performance Index: SPI = 100 ÷ 100 = 1.0 → On schedule^①

• Avoid “fuzzy” milestones:
  • Earned value credit is given only when the task is 100% complete
  • Partially completed tasks are NOT given partial credit (in most software projects)
  • Large tasks can/must be broken into subtasks
• Size tasks to allow frequent completions (e.g., 8–80 hour rule).
• Use objective progress measures (e.g., demos, deliverables).
• Encourage honest reporting and team buy-in.^①

PV in story weeks = Σ time estimated for the story (all stories completed in the iteration)

• In Agile (iterative) context: Use story points as effort units.
• Track velocity to estimate future capacity: Project velocity tells you how many story points you can allocate to the next iteration.
• Combine EV with burn-down charts for visual tracking.
• The customer gets to pick stories that equal the project velocity.^①

• The metric is calculated by reviewing work the team successfully completed during previous sprints; for example, if the team completed 10 stories during a two-week sprint and each story was worth 3 story points, then the team's velocity is 30 story points per sprint.
• Generally, velocity remains somewhat constant during a development project, which makes it a useful metric for estimating how long it will take a team to complete a software development project.
• If the product backlog has 300 story points, and the team is averaging 30 story points per sprint, it can be estimated that team members will require 10 more sprints to complete work. If each sprint lasts two weeks, then the project will last 20 more weeks.^①

• Planning, Estimating, Scheduling, and Tracking are a continuum
• Projects need to be partitioned for manageability
  • Work Breakdown Structures are a great way to do this (or stories for agile)
• Sequencing Tasks & Activities is vital
  • Gantt Charts allow quick reference
  • Network Techniques such as Precedence Network Diagrams, the Critical Path Method, and PERT Charts are useful tools
• Project Tracking is important for project visibility
  • The Earned Value Technique is a key tool in this
• The project charter typically includes information such as the project's objectives, scope, timelines, budget, risks, and assumptions. It also identifies the project team members and their roles and responsibilities.^①