This module is all about creating and updating project schedules – for a variety of life cycles.
A project schedule is a model that presents linked activities with planned dates. It shows durations, milestones and the necessary people and resources required. Schedules let us know when things start and end, and how activities roll up to milestones or releases. Once created, they can also be used to track actual project performance against and keep stakeholders informed of progress.
Predictive projects outline how scheduling will occur using a Schedule Management Plan. This might be a stand-alone document or section in the general Project Management Plan. It describes how activities will be defined and progressively elaborated.
The Schedule Management Plan also outlines the scheduling method used (Gantt chart, network diagram, etc) and other specifics about the schedule, including:
- Accuracy of duration estimates – e.g. activity estimates are +/- 20%
- Units of measure – e.g. all estimates are in person-days
- Control thresholds used to monitor performance – e.g. activities are deemed overdue 2 days past their scheduled completion date
- Reporting formats – e.g. The project Gantt chart and network diagram will be updated weekly and published as PDFs on the project portal. Estimate updates and questions should be emailed to the project manager…
Agile projects use the product backlog and release plans that typically utilize release roadmaps to schedule the project. This collaborative and iterative process involves the product owner prioritizing the backlog and selecting release candidates and the development team who provide activity estimates, dependency information, and other support.
Agile schedules initially rely on traditional estimation approaches (bottom-up estimation of features, comparison to previous projects, a calculation based on story points) to create the first schedule. Then transition to more of an evidence-based schedule as production data from the team emerges.
Since agile projects exercise all of the development disciplines every iteration, we can use actual rates of progress to validate and create more accurate schedules that are net of interruptions, defect rates, new scope evolution, etc. So, typically agile projects start with wide margins of schedule variance, but then become much more predictable as they switch over to evidence-based scheduling.
Traditional approaches also refine schedules and plans as new data emerges. This is the core of progressive elaboration and rolling wave planning. What sets agile practices apart is having experience-based data about all activities and phases of development plus deployment gained in each iteration.
2.6.1 Estimate Project Tasks (milestones, dependencies, story points)
Before we can develop a schedule, we need estimates for the activities that will make up the project. These activities might be called tasks or work packages depending upon your project environment. They are the lowest level of the WBS, the smallest decomposed work package, the tasks that make up user stories in the product backlog.
Traditional Activity Estimation
We create activity estimates in a traditional, predictive project environment by estimating the WBS work packages after reviewing the relevant planning documents and artifacts. The first four steps are performed once, and the second four steps are performed for each WBS work package:
- Review the Schedule Management Plan for guidance on the approach
- Review project assumptions and constraints
- Review Enterprise Environmental Factors (any policies, procedures, or legislation that exist inside and outside of the organization that will impact the way you schedule)
- Review Organizational Process Assets (any plans, processes, and knowledge bases specific to scheduling)
Then, the real process of activity estimation begins. For each WBS element:
- Decompose the work package into its smallest component parts
- Consult subject matter experts if anything needs explaining further
- Evaluate any activity constraints
- Estimate the activity and record the results, then go get the next WBS work package
Agile Activity Estimation
Our description of the agile estimation process zooms out further to explain some of the earlier project life cycle activities that impact the final schedule.
- Project scope is likely first explored using a vision exercise such as Design the Product box.
- Feature workshops identify the majority (80%+) of the product features. Rather than spending more time speculating what might be required, developing increments of a working solution is used to uncover the remaining 20%.
- The candidate feature list is prioritized by a product owner into a product backlog.
- The product owner establishes an initial release plan, working with the development team to create coarse-grained estimates for the product features/stories.
- Before Sprint/iteration planning, the stories are refined and estimated in more detail.
Agile approaches embrace the fact that it is usually impossible for novel, complex or high-change projects to plan everything in advance. Instead, they recommend exploration through prototypes to surface all the requirements and their relative priorities.
Starting with a backlog that we know likely contains only 80-90% of the final features means our activity estimates must include a contingency. As the project team works through the backlog, we can expect some changes and new feature requests.
The amount of work completed per iteration (velocity) and rates of scope growth are noted and used to predict completion dates. If, for example, it takes 4 months to complete 50% of the backlog, we can project another 4 months for the remaining features. Since the progress to date is net of discovery work, scope expansion, and change requests, these items will also be factored into future projections.
This all works in theory if the second half of the backlog is similar to the first half. If we saved all the problematic things until later, we are likely in for a nasty surprise. However, since backlogs are sorted with the high business value and risky elements first, work is generally easier and more negotiable the further down the backlog we get.
Lean Pull Scheduling
Lean approaches do not use iterations and instead continually pull items from a work queue as capacity becomes available. They also spend less time estimating work items and instead ensure items are of a similar size and measure throughput.
Throughput is the number of these small items a team completes in a given period of, say, a day or a week. Cycle time is how long things take, from starting work on them to finishing them. Using throughput, cycle time, and other related metrics, lean teams can schedule work and provide estimates without producing detailed activity estimates.
2.6.2 Utilize Benchmarks and Historical Data
OPAs and Lessons Learned
To help with scheduling, traditional projects use Organizational Process Assets (OPAs) such as previous project plans, published industry benchmarks, and risk and issues logs from other projects. They also access knowledge bases such as lessons learned. The idea is to reuse and apply this historical information to create as robust and realistic schedules as possible.
For example, if permits and approvals typically take two months for a project of this size, then it makes sense to schedule at least two months for the same process on our new project. In addition, applying historical data is valuable for projects that share activities with previous projects. However, when undertaking essentially new work, we need a different approach.
Agile Velocity and Lean Throughput
Agile and lean approaches accept that most knowledge-work projects are unique and difficult to tie back to historical data for scheduling insights. The next best thing we can do is to ensure our future projections take into account our current rates of progress. We can also reflect back often and try to improve our rate of progress.
Velocity measures the amount of work (usually recorded in points) that the team can complete in a period, such as a Sprint or iteration. So, it is helpful for team capacity planning and confirming the viability of schedules. In addition, since each iteration should be exercising all of the development disciplines, it provides a valuable metric that is net of all interruptions for meetings, support, defect corrections, etc.
Teams using more of a Lean-inspired approach such as Kanban or flow-based agile use throughput to measure their rates of progress. Throughput is a count of work items completed per day, week, or month and can be used to predict future completion dates and assess the impacts of improvements.
Both velocity and throughput rely on recent team performance. This means that they are not very useful at the beginning of a project since there has been no recent performance. However, as work progresses, they become more valuable than historical data from other projects since they relate specifically to this project environment.
2.6.3 Prepare Schedule Based on Methodology
There are several ways to create and present a project schedule. Popular choices include:
Gantt Chart – A histogram-based view of the project showing activities, durations and milestones. Gantt charts also typically show precedence relationships, people assigned to the work and percent complete information.
Milestone Chart – Summarized view of the major milestones of a project, usually on one page. Milestone charts are useful for senior management who do not want to see all the gory details.
Network Diagram with dates and dependencies–
Network diagrams show the schedule with start and finish dates for activities and the interrelationship of activities. This clearly shows the interdependencies of activities and may allow us to find schedule compression opportunities.
Critical Path
Often activities happen in parallel, so the overall project duration is not the sum of all the activity estimates. For example, in the network diagram above, two parallel paths of work occur after Activity 1 finishes. The top path (Activity 2 followed by Activity 4) will take 4 weeks + 3 weeks = 7 weeks to complete. The bottom path (Activity 3 followed by Activity 5) will take 9 weeks to complete. This longest path (highlighted in yellow below) is known as the critical path.
This path is critical because any delays to activities on this path will delay the Finish date. A one-week delay to any activity on the critical path would result in a one-week delay to the project Finish. Unlike a one-week delay to Activity 2 (which is not on the critical path), which would not impact the Finish date at all.
The critical path is the longest path (by activity durations) through the project network diagram. Ironically, this longest path represents the shortest time the project can be finished in.
Float, Free Float, and Total Float
Activities not on the critical path have some wiggle room. For example, a delay to starting them or an overrun on completing them – providing not too much, will not delay the project finish. This wiggle room for non-critical-path activities is called Float.
Float is the amount of time an activity can be delayed without delaying the project finish date or any consecutive activities. The network diagram above shows that Activity 2 happens in parallel with Activity 3 and takes one week less to complete. So, we could start late or run over 1 week without a scheduling problem.
Also, since the following activity, Activity 4 is 3-weeks long, we could delay Activity 2 by up to 2 weeks before that top path now becomes the critical path. We call the first kind of float Free Float. It is the time we can delay by without impacting any subsequent task’s earliest start dates. A two-week delay for Activity 2 is its Total Float, the maximum time it could be delayed by before delaying the project finish date.
Dependencies
Activities have logical relationships. The relationship indicates if the start or finish of an activity is dependent on the start or finish of another activity. For example, a building inspection cannot start until the workers have finished building the walls and roof. This is an example of a mandatory dependency, but there are others
- Mandatory – Contractually required or inherent in the nature of the work. E.G. By law, we cannot start the drug trials until we have finished experimenting with the formula.
- Discretionary – Based on knowledge or best practice. E.G. We should not move our belongings in until the lease is signed.
- External – Related to non-project activities. E.G. We are waiting for the 3D printers to be delivered before we begin printing prototype products.
- Internal – Based on things within the project team’s control. E.G. We will wait for Bill to finish Activity A before asking him to start on Activity B.
Precedence Relationships
We can start moving into a home before it is fully finished, but we cannot start wearing new shoes before we receive them. Activities have logical dependencies, as shown below:
1) Finish to Start (FS) – The most commonly used relationship. After Activity 1 finishes then Activity 2 starts. E.G. After the foundation is cured, we start building the walls.
2) Start to Start (SS) – Once Activity 1 starts, so can Activity 2. This is common with long-running activities, we may not have to wait until it finishes, but we do have to wait until it starts. E.G. Building screen prototypes and User Interface (UI) evaluation.
3) Finish to Finish (FF) – Activity 2 cannot finish until Activity 1 is finished. E.G. System changes and regression testing.
4) Start to Finish (SF) – Activity 2 cannot finish until Activity 1 starts. These are quite rare and often related to FS relationships or handovers to other groups E.G. We can only finish hand over to production for our new system after support has started.
Agile Scheduling
When using agile approaches, the scheduling process starts with the Product Owner creating a Product Roadmap that shows features targeted for upcoming releases. There is no single format for a Product Roadmap, and some examples are shown below:
Product roadmaps show features and capabilities planned for releases. These releases are typically delivered by iterations of work that contain features and user stories pulled from the product backlog as shown below.
Within the hierarchy of releases, features, user stories and tasks, user stories are the lowest business understandable units of work. They represent things we can discuss, prioritize, demo and gain acceptance for with the product owner and other business or customer representatives.
If we were developing a Netflix-type movie streaming service, we might have user stories about searching for movies by genre, actor or filming location. User stories are typically broken down further into tasks that get estimated by the team. These tasks may not be business-understandable, such as what database structures and indexes we should use to support the movie search requirements.
Iteration based scheduling
During sprint or iteration planning, the team estimates the work selected by the product owner. They should know how much they can deliver by comparing the total size of the work selected (perhaps in story points) with how much work they could complete in previous sprints/iterations.
Flow-based scheduling
By ensuring work items are of about equal size and complexity, lead time and cycle time can predict when work items will be completed. Throughput (the number of items completed per period) can also be used to determine how long a list of work items should take to complete.
Acknowledging the Quality of the Input Data
These agile approaches lack the numerical precision and mathematical logic of traditional scheduling approaches. For example, there is no critical path calculation, no analysis of float, and less precedence weighting. These traditional techniques do work for agile projects, but we need to consider the quality of the input data and the frequency of changes.
In high-change project environments, building novel products with rapidly evolving tools, our activity estimates are often today’s best guess. Applying math to a collection of guesses does not yield reliable answers. However, and this is where the danger lies, we might be lulled into thinking these schedules are accurate because we used fancy tools and techniques to arrive at them. Then next week, the product owner reprioritizes the backlog and adds new items based on demo feedback, and the projections and schedules all need redoing. Now our seemingly accurate plan has been replaced with another, and next week the process repeats.
Instead, agile and lean approaches embrace frequent reprioritization and use more straightforward tools such as “Remaining work” divided by “Average rates of progress” to provide a continuously evolving but realistic view of the schedule.
2.6.4 Measure Ongoing Progress Based on Methodology
Once the project is running, how do we track progress? There are several options, both for predictive approaches and agile ones also. Let’s examine a few.
Traditional Ongoing Progress Tracking Tools
Traditional, predictive approaches track progress against approved, baseline plans. The assumption is if we get behind, corrective action is needed. This is a valid assumption if we can create reasonably accurate upfront plans. Traditional tracking tools include:
- Tracking Gantt Charts – Gantt charts are not only useful for creating schedules, they can be used to track progress and roll-up percent complete figures also.
- Earned Value Management (EVM) – Earned value management provides tools to track progress against baselined plans. Particularly relevant to tracking schedules is the Schedule Performance Index (SPI) metric. SPI is a measure of schedule efficiency calculated as earned value (work delivered) / planned value (how much you planned to deliver). A SPI score of below 1 means we are behind schedule. A score of 0.85, for instance, would indicate we are progressing at only 85% of the rate initially scheduled.
Agile Ongoing Progress Tracking Tools
Agile approaches acknowledge that initial plans are likely to change since they were made when we know least about the project (at the beginning). In these high change environments, we could spend lots of effort in analysis trying to remove ambiguity or build an increment of functionality we know about and evolve from there.
(This idea of clarification via development rather than analysis is a very different mindset that some practitioners find natural and others find offensive. It was debated ad-infinitum 20 years ago, and while no clear winner emerged, learning through exploration has gained traction.)
Tracking progress on agile projects usually comprises of showing the rate of work completed compared to the work remaining. Then extrapolating the current rate of progress into the queue of work to predict when it should all be done. Or how much will be done by a specific date or spend amount.
Release Burndown Graphs – Show the estimated work remaining and the projected completion rate.
The example above shows the planned completion rate by the dotted blue line and the actual completion rate shown with the solid red line. Extrapolating the red line currently suggests the project will finish slightly late.
Cumulative Flow Diagrams (CFD) – Show the rate of completion, much like Burndown graphs, but also the rate of scope growth (if any).
Here the red region shows the total number of features. We started at 400, but over time this grew to 500 – maybe as more required functionality was discovered or asked for. The yellow region shows work in progress, and the green region completed work items. If we were to extrapolate the green region top line out until it hits the 500 features line, that would tell us when we are likely to finish (maybe November or December?)
Other tools exist, such as taskboards, burnup graphs and capturing client satisfaction from demonstrations. Because agile and hybrid approaches work in short increments, there are usually many opportunities to gauge progress and infer where current trends will lead us.
2.6.5 Modify Schedule, as needed, Based on Methodology
Stuff happens, plans change, and we need to deal with it. Therefore, a crucial part of the success of running any project is having a plan to update the plan. In other words, knowing how we will deal with all the changes that are inevitably going to happen.
Traditional Approaches to Change
Some people in the agile community believe traditional approaches are pretty brittle and unable to change. This is not the case. Traditional, predictive projects have several mechanisms for handling change and updating plans as new details emerge or circumstances evolve.
Rolling Wave Planning is an iterative planning technique in which the work to be accomplished in the near term is planned in detail, and the work further out is planned at a higher level. This way, we do not develop overly detailed plans for periods long in the future which are likely to change.
Progressive Elaboration is the concept of adding more detail to our plans as more information becomes available. So, if we learn something that impacts our plans, we update them. Used in combination with rolling wave planning, progressive elaboration helps ensure plans are crafted with appropriate levels of detail and updated when needed.
Traditional projects constantly monitor the status and progress of the project. If changes are necessary, they manage them to the schedule baseline and update the new schedule as needed. In general, deviations from the plan and the need to update the schedule are seen as an inconvenient cost that should be minimized, but processes and Change Control Boards exist to handle low to medium rates of change well.
Agile Approaches to Change
Changes are expected on agile projects. There are several functions built into the agile life cycle that facilitate frequent and rapid appraisal of changes. These include:
Frequent demonstrations – Regularly bringing sponsors and customer representatives together to review the evolving product/service can seem a double-edged sword. On the one hand, we get rapid confirmation the team is building the right solution. But, on the other, we get lots of change requests and suggestions for improvements. This can feel difficult to handle at the time, but it is positive if viewed from a longer-term perspective. It is better to learn about changes or potential improvement early in the life cycle while changes are comparatively cheaper than if attempted later.
Backlog reprioritization – As changes are received, they get added and reprioritized in the product backlog. Modern agile project management tools make reprioritizing stories easy and show ripple on impacts. In addition, when writing user stories, teams are encouraged to make stories independent, so there are the least possible dependencies between requirements, which also helps with reprioritization.
Short planning cycles – After creating high-level release plans, agile approaches deliberately only plan the next couple of weeks in detail. This ensures the concept of rolling wave planning occurs. Additionally, the agile methods recommend keeping backlog items as largely empty placeholders until close to their development. This limits analysis and design effort to only the ideas that get developed, reducing waste.
Product owner works as their own Change Control Board – As described in Task 3.3 Evaluate Changes, the product owner takes on all the responsibilities of a traditional Change Control Board. They evaluate, approve and sequence changes for the product backlog. This works great when we have an engaged, knowledgeable product owner, but agile projects struggle when these duties are not performed well. Project managers can help by emphasizing the significance of the role.
Frequent Retrospectives – Handling high rates of change while also working efficiently through a backlog is a difficult task that requires collaboration and communications. Frequent retrospectives provide teams with a forum to review what is working and what needs improvement. By meeting weekly or bi-weekly (the most common iteration lengths), issues can be quickly surfaced and potential solutions generated by the team for trial in the next iteration.
2.6.6 Coordinate with other Projects and other Operations
It might be tempting to keep news of delays “under wraps” while we try to catch up, but that rarely happens. So instead, project managers should share information, good and bad, to optimize value at the organizational level.
Update Program and Portfolios with Forecasts
When our project is part of a program or a portfolio, we need to evaluate if our schedule changes affect other program or portfolio components. Perhaps our delay (or acceleration) may not impact the other projects. However, if it does, the overall effect on the more extensive program or portfolio could be significant.
So, be transparent, share forecasts and updates to help planning.
Deliverables and Tools
- Activity duration estimates
- Activity cost estimates
- Story estimates
- Relative estimating
- Affinity estimation
- Feature estimates
- Task estimates
- Backlog
- Backlog reprioritization
- Burndown / burnup charts
- Cumulative flow diagrams
- Throughput analysis
- Velocity analysis
- Project schedule
- Release plan
- Product roadmap
- Earned Value
- Updated schedule
- Updated product backlog
- Network diagram
- Planning meetings
- Negotiations
Related Topics
- 2.1 Execute project with the urgency required to deliver business value
- 2.5 Plan and manage budget and resources
- 2.8 Plan and manage scope
- 2.9 Integrate project planning activities
- 2.10 Manage project changes
- 2.14 Establish project governance structure
- 2.15 Manage project issues
- 3.3 Evaluate and address external business environment changes
Further Reading
Congratulations! You score 100% and won the 2.6 Manage Schedule Badge.