Author: Robin Nicklas

Robin Nicklas is a project management consultant and educator. Since 2001, he has trained project managers in the aerospace, financial, telecommunications, government, and software sectors. Prior to teaching, he spent twenty years in information systems and technology, twelve of which he managed software development at large information service companies. Since 2003, he has taught graduate and undergraduate courses in project management at the University of Washington in Seattle, as well as MS Project courses at Bellevue College Continuing Education since 2011. Robin is a former president of the PMI Puget Sound Chapter in Seattle and a certified PMP. He can be contacted through his website, robinnicklas.com.

Level Remaining Schedule During Tracking

This is the last of four articles I’ve written recently on the topic of on tracking a project. I have outlined a four-step tracking cycle:  set the status date, enter actuals and revisions, reschedule incomplete work, and level the remaining schedule. To explore the last step, let’s consider an example. The below schedule was baselined after initial resource leveling. It is 11 days long. Resource R is constrained to two units. The project started as planned on October 4th. The first weekly status was October 8th. Only two days were spent on Task A. Task B was completed, but Task D was not started. Hence dependent Task F was not started. Incomplete work was rescheduled to start after the status date, resulting in a split of Task A and a Schedule No Earlier Than (SNET) constraint being placed on Task D and Task F. Entering actuals and rescheduling incomplete work created resource overallocations in the remaining schedule. The underutilization of resource R in the first week caused the shifting of four days of work into the remaining schedule. In the Leveling Options dialog, the schedule is leveled from the Status Date through the end of the schedule. You do not want to level the entire schedule since this potentially would overwrite portions of the actual schedule from the beginning of the project. Note that the “To:” date may need to be extended to cover the potential expansion of the schedule during leveling. If we choose to clear the prior leveling in the remaining schedule (by checking the Clear leveling values before leveling box), the leveling yields a 14-day schedule. During the day-by-day leveling starting after October 8th, Task E is critical on October 15th and that is why it is scheduled before Task F. If we choose to not clear the prior leveling within the remaining schedule (unchecking the box), we get a different 14-day leveling of the remaining schedule. With the prior leveling not cleared, Task F is critical on October 15th and is scheduled before Task E. Just as one may want to explore different leveling options prior to creating the baseline schedule, one should explore different leveling options for the remaining schedule. Project shows you only one leveling solution at a time based on the options you select. The one you are looking at may not be the best. As discussed in my prior MPUG postings on the subject, there is a distribution of leveling solutions. In this example, there was no difference in the project duration of the leveling’s. That will not always be the case.

Rescheduling Incomplete Work As Part of a Project’s 4-Step Tracking Cycle

In the first two articles of this series, a four-step tracking cycle was defined. It includes setting the status date, entering actuals, rescheduling incomplete work, and resource leveling the remaining schedule. This article addresses the third step in the cycle: rescheduling incomplete work. Do Not Rewrite Project History The status date defines the time through which project progress has been recorded. Work that was done in the past, prior to the status date, should be recorded in the past. This includes work that was scheduled in the future, but was started early and done in the past. Work that should have been done in the past, but was not, must be rescheduled to be done in the future, after the status date. This ensures that the work is recorded according to when it was performed, not when it should have been performed. A Simple Example In the following example, Task A started on 27th of September was marked as 50% Complete as of the October 1st Status Date. The task’s Status is Late, since the cumulative percent duration complete is less than what was planned through the Status Date. In the subsequent status update, on October 8th, the task is marked as 100% complete. However, it appears as if the remaining two days of work were done during the week of September 27th instead of during the week of October 4th.   We should have rescheduled the incomplete portion of Task A to be completed during the following week, after the October 1st Status Date. To do this, we must check the Split in-progress tasks box in the Schedule Options dialog. This allows us to show that work on the task was interrupted. Then, we use the Update Project dialog to reschedule the incomplete work to start after the current status date (October 1).   The result shows the remaining two days of work split and rescheduled to resume on October 4th.  Note that Project considers the task Status to be On Schedule.  The remaining work has been rescheduled into the future and is no longer considered late. When the task is marked as 100% complete on October 8th, we see that two days of work were completed in the first week and the remaining two days in the second week. How Do You Find Incomplete Work That Needs to be Rescheduled? If you use the standard Incomplete Tasks filter, which shows tasks that are not 100% complete, it shows incomplete work in the past and in the future. If you use the standard Late Tasks filter, it shows tasks with a Status of Late, which means that the Cumulative Percent Complete field is not 100% complete by the Status Date.   Filtering for tasks that are not 100% complete and whose Finish dates are less than or equal to the Status Date works, as well. Selecting the Reschedule option across the entire project in the Update Project dialog finds the late tasks for us. Does it Matter? Some might argue that rescheduling incomplete work does not matter. If a task is completed prior to the Status Date, it is 100% done, regardless of when the work was completed. To see how earned value calculations are affected by not rescheduling incomplete work, see my prior article on the topic.

Entering Actuals During the Tracking Cycle

In my recent Tracking Starts with a Status Date article, a four-step tracking cycle was defined. It includes setting the status date, entering actuals, rescheduling incomplete work, and resource leveling the remaining schedule. Before we begin entering actuals, we need a baseline schedule to which we will be comparing actual performance. We also need a status date. The status date is the reference date through which project progress was recorded. Recording what we did is important, and comparing it to what we thought we were going to do allows us to evaluate the accuracy of our forecast. Where Does Progress Data Come From? Usually, data about work that was done on a project comes from timesheets or cost accounting systems. VBA macros are used to parse this data and populate tracking fields in Project. The type and quality of tracking data can vary widely. Unfortunately, not all organizations collect this information. Or, if they do, it is not coded in a way that permits easy identification of which project or WBS component it applies to. If you work in an organization that does not collect this information, you may need to collect it yourself. If you do not have progress data, you cannot track. What Data Do You Need? There are many variables you can use when tracking: actual start, actual duration, actual finish, remaining duration, actual work, remaining work, actual cost, remaining cost, percent duration complete, percent work complete, etc. The good news is that you may need to record only two or three of these variables per task. Project can compute the rest. When considering duration, work, or cost while tracking, keep this equation in mind: Total = Actual + Remaining Before a task is started, no actual duration, work, or cost has occurred, so the total equals the remaining (or what is planned). Once a task is finished, the total equals what was actually spent and remaining becomes zero.  While a task is in progress, the total can change. Therefore, it is important to capture, not only what was spent, but also what remains. For example, percent work complete is a computed value. If you know actual work and total work, you can compute percent work complete. But, if you do not know remaining work for certain, then your total may be in question and the percentage may be incorrect. Three Schedules:  Current, Baseline, and Actual When you track your project, you have three schedules to manage:  current, baseline, and actual. Baseline Start and Finish dates reflect when you thought the task would start and finish. Actual Start and Finish dates show when the task did start and finish. If Actual Start and Finish dates do not exist, then the current Start and Finish dates reflect the planned for start and finish dates. If Actual Start and Finish dates exist, then they replace the current Start and Finish dates. This can be confusing. Fortunately, the Task Details form displays all three sets of start and finish dates for a selected task. If you have not considered the interaction of these schedules during tracking, I suggest spending a few minutes with the Task Details form exploring the different schedules. In the example below, Task A was baselined to start on September 20th and finish on September 22nd. However, it started on September 21st and is not yet complete. It’s expected to finish on September 24th, taking a day longer than anticipated. Know Which Table Corresponds to Each of the Three Schedules The current schedule is viewed with an Entry table, the baseline schedule with a Baseline table, and the actual schedule with a Tracking table. To record Actual Start and Finish dates from your timesheet data, use a Tracking Gantt chart view. Unfortunately, the default table in that view is an Entry table. It should be a Tracking table, since the Tracking table contains Actual Start and Finish, whereas the Entry table contains the current Start and Finish dates. This leads to untold grief for novice schedulers, who modify the current schedule thinking they are recording the actual schedule. Instead, you’ll have much better success if you use a Tracking table in the Tracking Gantt chart view from the start. The Mechanics of Tracking The tracking process is not as trivial as marking a task complete as planned or using simple percent complete estimates. The process can vary depending upon Task Type, whether your schedule is resource and cost loaded, how many resources and of what type have been allocated to a task, and so forth. You may need to enter only one or two fields and Project will compute the rest. At other times, you may need to gather a different set of fields or enter actuals in a sequence of steps, manipulating Task Type with each step. The details of what progress data to enter and in what circumstances are complex and beyond the scope of this article. Uyttewaal (2010) provides a thorough discussion. See Huffman (2019) and Lewis, et. al. (2019), as well. Specific sources will be referenced at the conclusion of this article. The Tracking table has Actual Start, Finish, Duration, Work, and Cost, as well as Percent (Duration) Complete and Remaining Duration fields. You can easily modify the table by inserting or hiding fields. In the table below, Percent Work Complete, Remaining Cost, and Remaining Work fields were inserted. The Percent Physical Complete field was hidden. For this task, the Actual Start, Actual Duration, and Remaining Duration fields were updated. Project computed the remaining fields. Note that Percent Complete is 25% since the total Duration changed from three to four days after Remaining Duration was updated. Questions to Ask How is progress data for your project collected? How often? How is it entered into Project? Which tracking variables do you collect? Which are computed? Bibliography Uyttewaal, Eric. Keeping the Schedule Up-to-date. Chapter 11 in Forecast Scheduling with Microsoft Project 2010. ProjectPro, 2010. Pp. 601-690. Huffman, Sam. Track the Project. Chapter 8 in Microsoft Project Do’s and Don’ts: The definitive guide to jumpstart your project. MPUG, 2019. Lewis, Cindy; Carl Chatfield and Timothy Johnson. Track Progress: Basic Techniques and Track Progress: Detailed Techniques. Chapter 8 and Chapter 14 In Microsoft Project 2019 Step by Step. Microsoft Press, 2019. Pp. 153-174 and 311-332.

Tracking Starts with a Status Date

There are four steps involved in tracking a project:  setting the status date, entering actuals and schedule revisions, rescheduling incomplete work, and resource leveling the remaining schedule. These steps are repeated throughout project execution once a schedule baseline has been established. Measure Progress Relative to a Schedule Baseline and the Status Date At the end of planning, once you have a time-feasible and resource-feasible schedule, a baseline should be set. This is done using the Set Baseline dialog on the Project tab. If a schedule has been baselined, the Baseline table in a Task Sheet view will be populated and a Baseline task bar will appear in the Tracking Gantt chart view. Prior to tracking, the current and baseline schedules will be the same. While the current and actual schedules change as we track, the baseline schedule remains constant. The status date is a reference date through which progress from the start of the project is measured.  It is set periodically based on how often project time and cost information is collected.  Usually it is weekly, monthly, or quarterly, but, with advances in technology and automation, it could be daily.  Changing the Status Date changes progress measure that are dependent upon what is baselined and when the status date is set. Setting the Status Date There are two ways to set the status date in Project:  in the Project Information dialog and from within the Status Date dialog. Both commands appear on the Project tab in the ribbon and are shown below. If you set the Status Date in one area, it will automatically propagate the other.   Highlight the Status Date Using a Gridline It is good practice to highlight the status date in the Gantt Chart or Team Planner views. This is done using the Gridlines dialog on the Format tab in either view, as illustrated in the following figures.   Questions to Ask If you are currently tracking a project, ask yourself these questions: Has the baseline schedule been set? How often is the status date updated? What is the current status date? If you use different steps in your tracking cycle, please share them in the comments section below.

Multiple Views into the Same Project File

Different views into the same MS Project file enables us to see a schedule from multiple perspectives. Using the split view feature is one way to do this. The Project window is split into two panes, with selections in the top pane controlling what is seen in the bottom pane view. However, there are occasions where the views we wish to combine are not compatible. To circumvent this, we can open multiple windows into the same file. Let’s explore these two techniques in the context of resource management. Split views are helpful in identifying where resource overallocations occur in a Project schedule. A Resource Graph subordinate to a Gantt Chart or a Gantt Chart subordinate to a Resource Sheet are typical split view examples. A split view is created on the View tab by checking the Details box in the Split View command group. A subordinate view to the current view can be selected from the pull-down menu. In the first split view example, a Resource Graph subordinate to a Gantt Chart, we see that resource R with a capacity of two units is overallocated when two concurrent tasks, Y and Z, require more resources than are available on the third and fourth day of the schedule. All the tasks are selected in the top pane, which allows us to see resource R’s loading across all tasks in the bottom pane. In the second split view example, we select resource R in the Resource Sheet and are shown only the tasks that R is working on in the subordinate Gantt Chart, exposing the two conflicting concurrent tasks. The Team Planner view can be used to find overallocated resources, as well. Whereas Project’s Gantt Chart view is task-oriented, the Team Planner view represents a resource-oriented Gantt chart, one in which resources, not tasks, are unique. Managers often create spreadsheets by arranging unique resources in rows, time periods in columns, and tasks in the intersecting cells. These spreadsheets help them to see which task resources are assigned, to whom, and when. Team Planner offers this perspective in Project. As you can see below in Figure 3, the resource overallocation is identified with red brackets. We can resolve the resource overallocation by using the Leveling Options dialog on the Resource tab. After resource leveling, the result is below. Other than the obvious shifting of one of the two conflicting tasks to the right, it would be nice to see the details of how this was scheduled. When we try to add a Leveling Gantt Chart subordinate to Team Planner in a split view, we are presented with an error. To circumvent this, I suggest opening a second window in the same Project file using the New Window dialog on the View tab. Then, display both windows using the Arrange All command. In the lower window, the Leveling Gantt Chart shows that Leveling Delay was inserted prior to task Z, and that is what created the shift. Unlike the split view panes, the two windows are independent of each other. Have you had to create multiple windows in the same Project file?  If so, please share your examples in the comment section.

Visualizing Project Flow Using Cumulative Flow Diagrams

  In my recent article, Sequencing Product Backlog, I used the shortest weighted processing time (SWPT) strategy to sequence a product backlog in order to minimize flow time and work in progress [1]. In that article, I defined four concepts needed to measure flow through the development process: flow units, flow rate, flow time, and work in progress (WIP) inventory. In this article, utilizing the same concepts, I will show you how to use the cumulative flow diagram (CFD) to visualize flow through the development process.   Measuring Flow It is natural to consider a feature in the product backlog as the flow unit in the development process. To be precise, the flow unit is the task that is undertaken to develop the feature. However, not all features deliver the same monetary value. If we do not account for this, we end up comparing apples and oranges. To be able to aggregate our measurements across teams within an organization and across projects with varying types of features, we need to express the value of features in monetary units. In our analysis, we will treat flow units as both features and dollars. We will see that the value-based view of flow is more nuanced. The rate at which flow units move through the development process in a specified amount of time is called the flow rate or throughput. The flow rate is bound by the capacity of the process, which is usually somewhat constrained by resources. We will start our analysis using a single-resource example, but then I will demonstrate how to relax that constraint. The amount of time that a flow unit spends in a process or system is called the flow time. It includes the processing time (cycle time) needed to develop the unit, as well as any time the unit spends waiting to be developed. Typically, features are released for development at the start of a project or the start of a sprint. Flow time is the difference between the unit’s completion time and its release time. Wait time (or queue time) is the difference between the unit’s start time and its release time. Flow time is the sum of a unit’s wait time and processing time. Work in progress (WIP) is an inventory measure. We can count the flow units in the process at any one point in time and average those numbers across the timespan of the project. The total number of units in the process is the sum of those waiting to be started and those actively being developed. Generally, if we want to deliver the most value within the shortest amount of time, we want to limit the amount of WIP, decrease flow time, and increase flow rate, in some combination.   Little’s Law The relationship between flow rate, flow time, and WIP is explained by Little’s Law [2][3][4]. It states that average flow time equals the quotient of average WIP and average flow rate. Table 1 defines the basic parameters and equations. LS is the average number of flow units in the process (not completed), and LQ is the average number of features waiting to be developed (not started). WS is average flow time, and WQ is average wait time. WS equals the sum of WQ and the average processing time. LS equals the sum of LQ and the average number of units actively being developed. The average number of units being developed concurrently is limited by the capacity of the process.     Single-Resource Example If there is only one resource, only one feature can be worked on at a time. Features will be executed serially. The resource Gantt chart and product backlog data for the example used in the aforementioned article are shown below.   In the following figure, there are two cumulative flow diagrams (CFD’s). For the sake of this example, one is feature-based and one value-based. Each CFD has three curves. The top curve shows the number of units released for development. This is the total WIP. All five features were released at the start of the project, and the number of features available for development remained constant over the duration of the project. The inflow curve (middle) shows the cumulative number of started units. Each time a feature was started, the cumulative inflow curve was incremented. The outflow curve (bottom) shows the cumulative number of completed features. Each time a feature was completed, the cumulative outflow curve was incremented. The vertical distance between the inflow and outflow curves represents the number of units (features or dollars) being worked during a given time. The vertical distance between the release and inflow curves represents the number of units waiting to be processed. The vertical distance between the release and outflow curves represents the total number of flow units in the process. In the single-resource example where features are executed serially, the horizontal distance between a feature’s release time and completion time is its flow time, which includes the amount of time it took to develop the feature (its process or cycle time) and the amount of time the feature may have waited to start.  The horizontal distance between the inflow and outflow curves is its processing time.   The CFD on the left above is based on the feature as the flow unit. There are five features that were completed over the 19-week span of the project. This represents a flow rate of 0.2631 features per week (5 features / 19 weeks). The average number of features being worked at any time was one since each feature was developed serially. The average feature processing time was 3.8 weeks (or 1 / flow rate). That is, a feature completed every 3.8 weeks on average. This is referred to as cycle time. Flow time is the difference between a feature’s release time and completion time. It represents the total time the feature was in process, including time waiting to be developed and then actually being developed. In this example, the average flow time was 8.2 weeks, which means that a feature had to wait 4.4 weeks on average before it was started. Over the span of the project, the average number of features either waiting to be started or being developed, was 2.1579. The average number of features waiting to be started was 1.1579. The CFD on the right in the above figure is based on the dollar value of each feature. The flow unit is one dollar, and we track how each dollar flows through the process. The total value of the project upon completion was $212,000. The project spanned 19 weeks. The flow rate was $11,158 per week. The average dollar-value of features both waiting and in development was $68,263. This can be computed as the average of the sum of released but incomplete feature values per time period as it was in the article mentioned above [1]. Given the flow rate and average work in progress (WIP), the average flow time can be computed as 6.1179 weeks using Little’s Law. This means that it takes 6.1179 weeks on average between the time a dollar is invested and the time that a dollar of value is delivered. Note that the average processing time and flow time of one dollar is less than that of one feature. In the single-resource example, we sequenced features in decreasing order of flow rate to provide more value sooner. You can see this in the value-based CFD, but not in the feature-based CFD. Furthermore, in the value-based CFD, note that 42% of the project’s duration is spent waiting on the completion of a feature that provides only 6% of the project’s total value. Perhaps it would be wise to drop that feature in order to complete the project with the remaining features sooner?   What Happens If We Double The Resources? So far in our example, we have used just one resource. If we add another, our capacity is increased so that we can work two features at one time. Figure 3 shows the resource Gantt chart and product backlog data for a two-resource example. The sequencing of features is arbitrary here, but an attempt was made to complete all of the features in the shortest amount of time and preserve the original sequencing. The sum of the feature processing times is 19 weeks. Using two resources, the shortest possible time to complete the release is 10 weeks (with upward rounding). We can see that both resources are fully utilized except for the last period.   The CFD’s for the two-resource example are shown in Figure 4 below. Note that the vertical distance between the inflow and outflow curves increased since more work is being performed concurrently. Also, note that doubling the number of resources cuts the project duration roughly in half. The average flow rate increased while WIP and flow time decreased. One should question whether the gain in accelerated value is offset by any additional cost associated with using a second resource.   CFD Interpretation The CFD offers a visualization of a process’s WIP, flow rate, and flow time. The vertical distance between the released and inflow curves shows the number of units waiting to be processed. The vertical distance between the inflow and outflow curves shows the number of units being processed. The horizontal distance between the inflow and outflow curves shows cycle time. The horizontal distance between the start of the project (release time) and the outflow curve shows flow time. The slope of the inflow and outflow curves shows the flow rate. If the slopes of the inflow and outflow curves are similar, then the two curves will be roughly parallel. This indicates that work is being processed at a stable rate. If the vertical distance between the curves increases, it means that more work is being started than is being completed in a unit of time. If the vertical distance decreases, it means that more work is being completed than started. If the horizontal distance between the curves increases, it means that it is taking longer to complete work that is started. If the horizontal distance between the curves decreases, it means that work is being completed in a shorter period of time. In the feature-based CFD’s above, the inflow and outflow curves were mostly parallel since the flow rate was constant and limited by the number of resources being utilized. However, in the value-based CFD’s the value of the features being processed varies. The features were sequenced so as to achieve more value sooner, hence the flow rate generally decreased as the project progressed. This is an important aspect to consider, and one that is easier to see in the value-based CFD’s.   How Do You Use CFD’s? What types of flow units do you track?  What tools do you use to create CFD’s?  In what ways have CFD’s helped you diagnose process bottlenecks or other process anomalies?  Please share your thoughts and insights in a comment below.   References [1] Nicklas, Robin. (2020, April 21). “Sequencing Product Backlog.” MPUG. https://www.mpug.com/articles/sequencing-product-backlog/. [2] Reinertsen, Donald G. (2009). The Principles of Product Development Flow:  Second Generation Lean Product Development. Celeritas Publishing. Pp. 71-75. [3] Stevenson, William J. (2012). Operations Management, 11th ed. McGraw-Hill. Pp. 800-803. [4] Cahon, Gerard and Terwiesch, Christian. (2013). Matching Supply with Demand: An Introduction to Operations Management, 3rd ed. McGraw-Hill Irwin. Pp. 15-19.  

How To Reschedule Incomplete Work

A colleague posed a problem recently. He recorded earned value after tracking work done in the first status period of his project. When recording work done in the second status period, he returned to the first only to find the earned value had changed. What could have caused this? One possible reason is neglecting to reschedule work that should have been completed prior to the status date. Remaining work must be rescheduled to start after the status date. If we don’t reschedule incomplete work, then actual work will be posted as if it occurred in the past, before the prior status date. This will alter the earned value of the prior period. Here is a simple example. Consider one task that is six days long, with one resource assigned at $100/hr. The current date is April 19th, which is prior to the April 20th project start date. The schedule is baselined.   The status date at the end of the first week is April 24th. The task started late and only three days of work were completed. There is no cost variance. As much was earned as was paid (assuming the resource was paid hourly for every hour worked). There is a schedule variance since we earned three days of work, but planned to do five.   In this first pass, we neglect to reschedule incomplete work from the first week. Instead, we move on to status at the end of the second week, which is May 1st. The task is complete. The % Work Complete field is set to 100%. The Actual Duration is computed to be six days and the finish date is computed as April 28th. There is no schedule variance (the task is complete), and there is no cost variance. We earned the six days that we spent.   Going back to the first status date, the earned value is different from what we saw above. Without rescheduling the incomplete work, it appears that work was done on April 24th. MS Project thinks we earned four of six days of work (0.6 x $4800) in the first period, instead of three of six days of work (0.5 x $4800) shown above.   To correct this, we must first verify that the “Split in-progress tasks” box is checked in the File > Options > Schedule dialog box.   Then, we return to the first status date of April 24th, enter the task tracking information, and use the Update Project dialog to split the remaining work and reschedule it after the status date.  Earned value is now computed correctly.   In the second status period, the task completed within six days of work. Note that the task finishes one day later than above, since no work was done on April 24th. The earned value at the end of the project remains the same.   When we return to the first status date, April 24th, the earned value is correct.   As a twist to the example above, let’s consider what happens if no work was completed on the task prior to the first status date (April 24th). The reschedule incomplete work option of the Update Project dialog will constrain the start of the entire task to after the status date. Below, we see that a Start No Earlier Than (SNET) date constraint has been applied to the task.  While it is advisable to limit use of date constraints, the application of a SNET constraint in this case is benign. It does not impact the remaining schedule.   There are several steps in a tracking cycle, such as to set the status date, enter actuals, reschedule incomplete work, and level the remaining schedule. Rescheduling incomplete work is a vital step that ensures we do not overwrite history as we track project progress and that our earned value assessments remain accurate. Have you used this method to reschedule incomplete work? I would love to hear from you in the comments below.  

Sequencing Product Backlog

When modeling a project as a flow process, one objective is to deliver the maximum amount of value in the shortest amount of time. Most project managers likely start with an inventory of features in a product backlog. The sequence in which features are executed determines whether we will achieve the objective. The effectiveness of the sequencing depends upon the interaction of three process variables:  flow rate, flow time, and the inventory of work in progress (WIP). The graph below illustrates the fundamental relationship of these variables. It exemplifies Little’s Law, which states that average work in progress equals the product of average flow rate and average flow time (Cahon and Terwiesch, 2013). Flow time is the horizontal distance. The inventory of WIP is the vertical distance. Flow rate is the slope (WIP / flow time). The greater the slope, the more work is accomplished per time period. If you want to maximize the value of work delivered in the shortest amount of time, you’ll want to sequence features by monotonically decreasing flow rate.   The inventory of WIP can be measured in a variety of ways. The simplest way is to consider a feature to be the flow unit and to count the number of incomplete features in the process at any time. However, some features may be more important or valuable than others. If those features are weighed according to their potential revenue or cost savings upon completion, then one can assess the value of the WIP inventory using a dollar as the flow unit. If we do not claim a feature’s value until it is completed, then the value is delayed by the flow time of the feature or the amount of time it spent in the process. The flow time of a feature weighted by its dollar value is considered a delay cost. For the sake of a sequencing example, let’s assume we want to minimize the value-weighted flow time of the process. In other words, we want to minimize delay costs.   Start with a Simple Product Backlog . . . The table below shows a product backlog with five features. Processing times and value weights have been assigned arbitrarily. Processing time (duration) is a proxy for the amount of work or cost required to complete a feature. Here, we will measure it in weeks. Feature 4 has the shortest duration and feature 5 has the longest. A feature’s value is the potential revenue or savings realized once the feature is complete. Feature 1 is the most important and feature 5 is the least, in terms of dollar value. All features are available for execution at the start of the process. That is, their release times are zero.   Let’s make two simplifying assumptions. First, the development team can only work on one feature at a time. This limits our discussion to the “single machine” model. With only one resource (i.e., the team), the makespan of the process will be 19 weeks, which is the sum of all of the processing times. Secondly, we are assuming the flow rate at which the team works remains constant. The total value of the features in the product backlog is $212,000. The average flow rate is $11,158 per week.   How Should We Sequence the Backlog? Let’s look at three scenarios. Reinertsen (2009) suggests that if we are indifferent to processing times, we would sequence the features in decreasing order of value. The most valuable features are completed first. If we are indifferent to value, we would sequence the features in increasing order of processing time. In this case, the shortest features are completed first in order to minimize average flow time. When both processing time and value are important, the features should be sequenced in decreasing order of weighted processing time, the quotient of value and processing time. Features that deliver the most value per processing time are completed first in order to minimize average weighted flow time.   Scenario 1: Most Valuable Feature First If we sequence the features based only on value, the result is shown in Table 2 below. The sequence position is determined according to the decreasing order of value weights (w(i)). Reinertsen calls this Highest Delay Cost First (HDCF) sequencing. C(i) is the completion time for each feature. Feature 1 was released to the process at time 0, started at time 0, and completed at time 2. Feature 2 was released to the process at time 0, started at time 2, completed at time 5, and so forth. The flow time F(i) for each feature is the difference between the feature completion time and the feature release time (C(i) – r(i)). It represents the total time the feature was in the process, including any waiting time prior to execution. The delay cost for a feature is the product of its flow time and value weight (w(i) * F(i)). It represents how long we had to wait for that feature’s value to be delivered. The average flow time for a feature is 9.8 weeks. The total cost of delay is $1,381,000.   Scenario 2: Shortest Processing Time First If our goal is to minimize the average flow time (the amount of time a feature takes to complete), we would sequence features in increasing order of process times. This is known as shortest processing time (SPT) sequencing (Baker and Trietsch, 2009). Reinertsen calls this Shortest Job First (SJF). Table 3 shows the result of this ordering. The average flow time for a feature is 8 weeks and the total cost of delay is $1,344,000. This will be the shortest average flow time of the three scenarios presented here. Note that the total cost of delay has decreased compared to the first scenario. The result can be verified by using Excels’ Evolutionary Solver. The objective function is to minimize the sum of flow times by permuting the feature sequence.   Scenario 3: Shortest Weighted Processing Time First If our goal is to deliver maximum value within the shortest time, we would sequence features in decreasing order of value per processing time. This is known as shortest weighted processing time (SWPT) sequencing (Baker and Trietsch, 2009), although Reinertsen refers to it as Weighted Shortest Job First (WSJF) sequencing. Reinertsen’s nomenclature was adopted by the Scaled Agile Framework – Enterprise (SAFe) methodology (Weighted Shortest Job First). Cohn (2005) describes a “relative weighting” technique for sequencing a product backlog, which is similar to what we describe here. In this scenario, the average feature flow time increased slightly to 8.2 weeks, but the total delay cost decreased to $1,297,000, which is the minimum total delay cost of the three scenarios presented. As above, the result can be verified by using Excel’s Evolutionary Solver. The objective function is to minimize the sum of weighted flow times by permuting the feature sequence.   Figure 2 shows the delay cost curves for the three scenarios presented above. The area under the SWPT curve is the least of the three scenarios.   Figure 3 below shows the cumulative value delivered. The slope of the SWPT curve decreases monotonically, whereas the other curves do not.   Little’s Law Revisited At the start of this article, I stated that the effectiveness of sequencing depended upon the interaction of three process variables:  inventory, flow rate, and flow time. Little’s Law states that in a flow process average WIP inventory equals the product of average flow time and average flow rate. The table below shows the value of these variables across all three scenarios discussed above.   The flow unit is one dollar. Flow rate is a constant $11,158 per week ($212,000 / 19 weeks). Average value of WIP can be computed by evaluating the delay cost during each week in the process makespan. Little’s Law enables the computation of average flow time using the average flow rate and average WIP value. Shortest weighted processing time (SWPT) sequencing provides the lowest average flow time and average WIP costs.   References Baker, Kenneth R. and Trietsch, Dan. 2009. Principles of Sequencing and Scheduling. Wiley. Pp. 15-21. Cahon, Gerard and Terwiesch, Christian. 2013. Matching Supply with Demand: An Introduction to Operations Management, 3rd ed. McGraw-Hill Irwin. Pp. 15-19. Cohn, Mike. 2005. Agile Estimating and Planning. Prentice-Hall. Pp. 117-119. Reinertsen, Donald G. 2009. The Principles of Product Development Flow:  Second Generation Lean Product Development. Celeritas Publishing. Pp.191-198. Weighted Shortest Job First. www.scaledagileframework.com/wsjf/  

  • 1
  • 2