In my previous post, I explained that I’d be making a case in a series of articles for adding certain features to Microsoft’s Project for Desktop and Project for the web software. Here, I’d like to suggest making Microsoft Project better in terms of Time Modeling, which I see as the simplest way of working with the software. Time Modeling starts with identifying the deliverables. Deliverables are ‘the things of value that a client is asking for and is willing to pay for’ (source: my Forecast Scheduling textbooks). You can create a Time Model of a project by entering the 4D’s: the Deliverables, their Durations, Dependencies between the Deliverables, and the Deadlines (target dates) on each Deliverable.
Deadlines are (agreed-upon) target dates that you can enter for deliverables, milestones, or activities, and Project for the web does not have the Deadlines feature that Project for Desktop has, so my Recommendation (#2A) is that of adding a Deadlines feature to Project for the web. Deadlines are a very useful feature that are not visible in the default views in Project for Desktop. I’d also like to see Recommendation (#2B) the Deadline field visible in all default views in both applications (i.e. Project for Desktop and Project for the web).
Project for the web calculates the Total Slack from interim deadlines within the schedule, but not from the last deadline, the project deadline, which is an odd aberration in the Project for the web offering. If a user enters a deadline on the project finish milestone (i.e. the milestone in the schedule with its finish date furthest out in the future), you would expect that Project would use this project deadline date for the backward pass in the Critical Path calculation; however, this is not the case. The software uses the project finish date instead, which tends to understate the true amount of Total Slack in the project. Project MVP, Dale Howard, expanded this issue in his excellent series of articles on deadlines (here and here). He even recommended using the Finish1 field and another field with a custom formula to set this straight. I’d say that it would be useful Recommendation (#2C) to change Project for the Desktop in such a way that if a user enters a Deadline on the project finish milestone, the application would use the Deadline date, rather than the early project finish date for the backward pass (in the Critical Path calculation). If deadlines in Project for Desktop and Project for the web were implemented in this way, a project manager would always know exactly the amount of buffer (a.k.a. ‘time contingency’) he/she has within the project.
I would like to illustrate my above recommendations with a simple project and some screenshots. This is what Microsoft Project currently calculates:
As you can see, Project for Desktop calculates the Total Slack on the project finish milestone (ID = 11) as 0d (zero days), which is because Microsoft programmed Project to ALWAYS calculate the backward pass in the Critical Path calculation from the project finish date, 11/21 (November 21). This has been the case in every release of Microsoft Project since Project 3.0 from 1992 (the first version I started working with). You can clearly see that the project is meeting its deadline date of 2/3/23 and that there is, in fact, a project buffer that stretches from 11/21/22 (date to left of project finish milestone) until 2/3/23 (date in the field Deadline). That said, it is hard for schedulers to manually calculate the size of the buffer in business days (considering weekends, holidays, etc.). If Project did this for us, a project manager would then know by how many days the project can slip before missing the project deadline of 2/23/23. If a supplier calls the project manager and provides some bad news that, for example, “The fixtures for the bedrooms and bathrooms will be delivered six weeks later than agreed upon,” (s)he will know right away if the project is in trouble. With the way Project for Desktop is now, the PM would be in the dark, and likely wondering: How much time buffer do we have exactly? How many non-working days do we have around the Christmas holiday? Will it all finish on time still with the 6-week slip? As you can see, Project could be a lot more helpful to project managers than it is now.
The below screen shot is what I propose Project for Desktop should calculate, instead, as Total Slack. I have inserted a new column called Total Slack NEW:
You can see that the Total Slack NEW numbers calculated in the backward pass from the Deadline dates are VERY different from the Total Slack numbers Project for Desktop currently calculates. The Total Slack NEW column provides the project manager with the numbers I would like to know. It tells me that I have a total of 74 days of time buffer in my overall project. Meaning that on the midway milestone of 50d and on the earliest milestone, only 10d of time buffer (until the first deadline date). When the project manager receives the same bad news of “There will be a delay of 6 weeks (= 30 business days) on the delivery of the fixtures needed for the bathroom,” he/she manager can directly see that this is well within the 74d (74 business days) buffer the project has. S(he) can stop worrying about it apart from exploring if the schedule should be re-optimized. The project manager could, for example, fast-track task 10 Roof, Gutter, Soffits, and Siding perhaps overlapping it with the slipped bedrooms and bathrooms.
In addition to this, I’d recommend Microsoft change the calculation of the Total Slack numbers in such a way that the backward pass is calculated from the deadlines including the project deadline, or, to be more technically accurate, from the one downstream deadline that is most challenging to meet for that task Recommendation (#2D).
We cannot leave it at that because we also need a new type of Critical Path that will work much better than the current Critical Path. For the next section, I will lean heavily on the proceedings from an international working group I led in 2011 that defined the next version of the 60-year-old Critical Path theory. We called this new edition of the Critical Path theory Critical Path 2.0. If you want to read the White Paper we produced, please navigate to it here: Critical Path 2.0. Microsoft declined to participate in 2011 and never discussed this White Paper with us afterwards. Primavera declined to participate, as well, since they were working on their own, new concept of the Longest Path as their solution to the same problem. The General Manager of Spider participated in our Working Group, and Spider and has implemented several recommendations from the Critical Path 2.0 White Paper.
A ‘Most-Critical Path’
The current definition of Critical Path that Microsoft implemented in Project is the: The Critical Path is the sequence of tasks with zero or negative Total Slack. This definition was proposed by the creators of Critical Path 1.0, Kelley & Walker, in 1959. Critical Path 1.0, in use now for over 60 years. I believe it has aged and is now outdated. Since its inception, powerful project scheduling applications have been created. Microsoft Project, Primavera, and Spider are the original ones remaining that are widely in use.
With the arrival of new features in many editions of Microsoft Project (and other project scheduling applications) that can create some Total Slack on the most-critical tasks, I believe the rigid definition of Critical Path 1.0 needs to be updated. The following features, that are now common in most project scheduling applications, can add Total Slack to the most-critical tasks and make them appear incomplete (just a few tasks critical) or fragmented (a few tasks critical here and there):
- Constraint dates
- Elapsed durations and lags
- Resource Calendars
- Task Calendars
- External predecessors
- Workload Leveling (more on this in a future article)
A partial or fragmented Critical Path is frustrating for users of Microsoft Project that rightfully expect that their Critical Path covers the entire duration of their project and explain its entire duration. For a detailed explanation on why these features break the Critical Path 1.0 in Microsoft Project, please read any edition of my Forecast Scheduling textbook. If you use the features listed, the Critical Path will not cover the entire project duration, only part of it, and you will be in the dark as the project manager on what task may be slipping your project (unless you apply the techniques presented in my Forecast Scheduling textbooks).
Thought leaders from Primavera have proposed their solution of the ‘Longest Path’ for these problems in the early 2000’s, however, their concept does not generate the right path in every situation imaginable. In particular, when you have very-late arrival date of some supplies in the project, there is a very short path with a start date that has a very‑late Start-No-Earlier-Than constraint date that also appears late in the schedule, which will drive the project finish milestone further out. In this situation, the longest path is not the path that you need to know about as a project manager. In this situation, that path is the shortest path in the schedule: The very-late arriving supplies and the tasks you have perform with them.
I find the concept of the Most-Critical Path more useful, and, as far as I can see, the Most-Critical Path is a concept that has universal applicability. It can be defined as: the sequence of tasks with the lowest amount of Total Slack (Total Float) on it (source: Forecast Scheduling textbooks). The ‘lowest amount’ can be the lowest positive number (when there is a time buffer) or the largest negative number (when the project Deadline is missed and the project slips): For example, -10d of Total Slack is lower than +1d Total Slack, and is, therefore, more critical: You will have a harder challenge meeting a deadline with -10 days of Total Slack than one with +1 day of Total Slack.
The Most-Critical Path would look like this in our example project:
You can see that the Critical Path is clearly visible in this schedule: The red tasks and red taskbars are the Critical Path. You can also immediately see in the Total Slack NEW column that there is 74 (business) days of Total Slack in the project, which is almost 15 weeks. Now that we know there is a 6‑week delay on the fixtures for the Bedrooms and Bathrooms deliverable, we can clearly see that there is no problem for this project’s timeline and the project will finish on time.
Note that the project manager had entered the Christmas holidays on the project calendar, so those holidays are already incorporated in the Total Slack calculations shown.
My next Recommendation (#2E) is to switch the Critical Path algorithm over to our new concept of Most-Critical Path and color the Most-Critical Path activity bars and milestone diamonds red in Project for the Desktop and Project for the web.
Notice that we applied some additional formatting in this view that I would like to capture as recommendations as well:
- Recommendation #2F: The text of the most-critical Task names could be colored red, as well, which we would be default in the Gantt Chart and Tracking Gantt Chart. This allows project managers to recognize the Critical Tasks in the Gantt table, as well as in the Gantt timescale.
- Recommendation #2G: The color of the critical milestones diamonds in the timescale should be red, instead of black. This makes all critical dependency arrows red, as well, on the Most-Critical Path, which makes the Most-Critical Path easier to follow by just following the red chain.
- Recommendation #2H: Display any dates to the left of the milestone diamonds, because if they continue to be displayed on the right, they will often overlap with the green deadline arrows. Even better would be if Project were to never overlap dates with the green deadline arrows, but flip them dynamically to the left (when there is buffer) or back to the right (when there are slips) of the diamonds.
These are all the improvements I’m recommending for Time Modeling. Please let me know whether or not you would like to see these new features in Microsoft Project and why. And, stay tuned for my next article in which I’ll venture into Workload Modeling.
Thank you for reading!
