One of the great struggles of running complex programs is how to prioritize limited resources to work on a number of seemingly critical milestones. The traditional agile approach is to have a rough roadmap, build a backlog and then groom that backlog with the input from the Product Manager to reflect the most important set of deliverables from the customer’s perspective. This sounds fantastic, but there are very often times when in order to achieve the business outcome our customers need requires a set of functionality that needs to be built. In other words a set of milestones to be achieved that are all important for the ultimate outcome our customers are asking for.
Let’s look at an example:
The hypothetical program we are managing is an inventory management system. We got a rough roadmap outline or a sequence of milestones that we need to achieve and some rough level of effort estimates (in a number of sprints):
A. Gather requirements – 2 sprints
B. Architecture Design – 2 sprints
C. Project Plan / Design – 1 sprints
D. Database Design / Deployment – 3 sprints
E. Module Design / Implementation- 5 sprints
F. API Design / Implementation – 2 sprints
G. Logging / Monitoring / Alerting / Dashboards – 3 sprints
H. Security Controls Design / Implementation – 2 sprints
I. Documentation / Training – 3 sprints
J. Pilot / Production Release – 3 sprints
Now some of these activities are dependent on one another, so it helps to create a PDM (Precedence Diagram Method) network diagram:
| Milestone | Predecesor | Duration (Sprints) |
| A | – | 2 |
| B | A | 2 |
| C | B | 1 |
| D | C | 2 |
| E | C | 3 |
| F | C | 3 |
| G | F | 3 |
| H | F | 3 |
| I | H | 3 |
| J | I, G, E, D | 2 |
Now let’s draw the relationship between our milestone in a form of a network diagram.
As you can see, I also highlighted the longest path on our diagram from start to finish, which is our critical path. When we add up the duration of all milestones on our critical path we will determine our overall project duration. In our case it would be A(2) + B(2) + C(1) + F(3) + H(3) + I(3) + J(2) = 16 Sprints. Critical path also means that a delay in completion of any milestone that is on our critical path will delay our overall project completion. For example, if we the design and implementation of our API surface is delayed by 1 sprint our project now takes 17 sprints to complete instead of our previous estimate of 16 sprints.
The next thing we can do at this point is to calculate the float or slack in our project. In order to do that we’ll need to do a forward / backward pass through our diagram to figure out early start / early finish and late start / late finish.
As the name suggests, early start (ES) is the earliest a given activity can start, taking all of its predecessors into account, while early finish (EF) is the earliest a given activity can be finished.
We determine ES / EF values by doing a forward pass through our network diagram. As you can see from the diagram below, all we are doing is adding durations for each of the milestones. If there are multiple options to choose from, such as the case in J, we choose the largest value (14 in this case, vs 8 or 11 for instance)
Late Start (LS) is the latest any given activity can start without impacting the overall project’s duration and late finish (LF) is the latest a given activity can finish without delaying the overall project duration. (note: just so you are not confused, in the key of the diagram above I used LE instead of LF, it means the same thing)
To calculate LS / LF we do a backward pass through our diagram (starting from finish and moving left towards the start). Here instead of adding durations we are subtracting them and in case we have multiple options, instead of choosing the greater of the values as we did in the forward pass, we choose the smaller of the values.
See example below:
As you can see, as an example, for activity F we can choose LF of 8 or 11, we are choosing the smaller of the two – 8. In activity C we have three options 5, 11, 12, again here we are choosing 5, which is the smallest one.
Now that we have ES, LS and EF, LF we can figure out the float of the slack in our milestones. So what is slack. Slack or float simply means the amount of time a particular item can be delayed without impacting the overall project duration.
If you haven’t already noticed, the amount of slack in our critical path items is zero. Which kind of makes sense if you think about it, since delaying any item or a critical path, by definition, will impact the project duration.
Calculating float, now that we’ve done our passes through our network diagram and recorded our ES, LS, EF, LF values, could not be any easier, all we have to do is subtract ES from LS and EF from LF.
For example, let’s figure out the slack (float) in milestone D.
Slack of D = LS (12) – ES (5) or LF (14) – EF (7), in both cases the answer is (11-3) – 5 = 3 sprints.
The same exercise can be done for other non-critical path items E and G. We’ll find they have a slack of 6 and 3 respectively.
How is this information valuable for TPMs?
Knowing the amount of slack can help us in prioritization and resource allocation. Aside from the critical path items which are obviously high priority we also need to prioritize other items based on the amount of slack they have. The smaller the amount of slack the higher our priority should be. If we don’t complete our non-critical path items and let the slack time expire they will become critical path items.
Let’s look at an example. Our milestone D (non-critical path item) has the greatest amount of slack – 7 sprints. So we would give it the lowest priority level. But if we ignore it and don’t get it started before LS (sprint # 12) we now have zero slack and it become another critical path item, which, if not completed on time, (LF or sprint #14) will impact our overall project delivery date.
As a TPM on this project, as my team is completing milestone C, I am faced with a decision of where to allocate our engineers next. I will choose F since it’s a critical path item, that is easy. But what should we do next or, if we have sufficient resources, start working on in parallel? Should we start on E or perhaps H? Provided we have resources available to only work on a single milestone at a time and F is done on time, the amount of slack left on E is 3. So we have to start on the next critical path item H. By the time H is done both E and G have zero slack left and we have to start on the next critical path item I.
What we are seeing from this example is that given this project roadmap we must work on multiple milestones in parallel. If this isn’t feasible given the engineering resources we have on our team, we have two options: ask for additional resources or extend our project duration / delivery target.
As you can see, by performing this exercise we are able to make data driven decisions about prioritization, resource allocation and delivery timeline expectations. This data-driven approach gives us confidence that we are working on the most critical items, while making the conversations with our leadership team much more productive since we are able to back up our decisions and asks with quantitative analysis, instead of relying solely on our best educated guesses and collective gut feelings, which by the way we also shouldn’t ignore.