Author: Eric Uyttewaal

Eric is a thought leader on project, program, and portfolio management. He spends most of his time using software from Microsoft. He has authored seven well-known textbooks including ‘Forecasting Programs,’ 'Forecast Scheduling with Microsoft Project 2010/2013/Online,’ and ‘Dynamic Scheduling with Microsoft Project 2000/2002/2003.’ He founded ProjectPro, which specializes in Microsoft Project, Project Server and Project Online. Eric developed several Add-ins with his team that enhance the capabilities of Microsoft Project in creating better schedules (Forecast Scheduling App), managing cross-project dependencies (CrossLinksPro), identifying and documenting the Critical Path (PathsPro) and creating S-curve reports (CurvesPro). He was president of PMI-Ottawa in 1997. Eric has received awards from PMI in 2009, from MPUG in 2012, and from Microsoft from 2010 until 2017 (MVP).

A Better Microsoft Project: Baselining

This article is the fifth in my series, “A Better Microsoft Project,” You can find the earlier articles here: Introduction, Time Modeling, D * U – W fields, and Workload Leveling. I find baselining to be so difficult in Microsoft Project that no matter how I trained students in doing it right, most would almost always revert back to their old behaviors: not baselining, re-baselining the entire project every week, or re-baselining in an incorrect way. Any of these actions wreck the integrity of the baseline schedule, which is the approved schedule. Ellen Lehnert, a long-standing Project MVP, tells the story that at one medium‑sized company where she taught a MS Project class, she asked the group: “How often do you baseline your project?” The CFO, named Nob (fictitious name), proud of his consistent and perfect project performance, answered promptly: “Every week!” Ellen clarified: “Do you re-baseline your entire project every week?” “Yes” was the emphatic answer. The CEO looked very displeased and muttered to Nob: “We need to talk!” I myself found that at both a major bank and a major government department, project managers were re-baselining their projects every week, and when I asked why, their answers essentially were, “Just because we can.” It is a clear sign of an immature project management culture. Re-baselining your entire project every week is akin to re-writing history or wiping out all your past sins. Examples of re-writing history would be: In USA, if slavery was left out of US history books used in schools. In Canada, if residential schools were not discussed in history books used in schools. The era of residential schools in Canada was when Indigenous kids were taken from their parents and kept in captivity to be “re-educated.” With these extreme examples in mind, I think we can all agree that it is not best practice in any way to re-write history for the purpose of wiping out past sins. Similarly, project managers should not re-baseline activities that already have an actual start date. This practice results in moving the dates of the original, baseline plan to where they actually happened. In archery, this would be similar to moving the bulls-eye to the arrow, whereas the real test of skill is to move the arrows to the bulls-eye, of course. In project management, the real challenge is to keep or move the schedule to align as closely as possible to the static baseline. After you create the first baseline, you should not change the baseline unless you have an approval to do so from the person or people with this authority, as per the governance processes in your organization. With approval, re-baselining should only be done for future tasks, never for completed tasks (unless the baseline was incorrect in the first place), but that is not all! You can only re-baseline some, not all activities, in the future. You cannot re-baseline a future activity that is logically unaffected by the change request. That would be akin to wiping out all your future sins, too. You can only re-baseline future activities that are affected by the change request, as per your network logic (dependencies). So, our CFO, Nob, had a great gig going for him. Every week he would simply wipe out his past sins (by moving the baseline dates of completed tasks to their actual dates) and wipe out any possible future sins (by moving the baseline dates of future tasks to their current forecast dates that often had slipped). Nob was a project manager with a perfect track record in managing projects. His projects would always finish exactly on the planned date (baseline finish). Was Nob an angel or a devil? I am pretty sure his boss, the CEO, was not going to give him a raise in salary, but, instead, wanted to tear him to pieces like a lion feasts on wildebeest in Africa. I deliberately use graphical language to get the severity of the situation across. As a trainer, I eventually gave up getting people to re-baseline properly when they don’t need it, because it is simply too hard to do with Microsoft Project. Without a baseline, you can still check if your project is on time by using Deadlines only. This is explained in my second article. You only need to maintain your baseline when one of the following is true (see my Forecast Scheduling textbooks): Your project KPI’s and metrics use baseline data You use Earned Value Management as your performance measurement system You want to be able to attribute schedule delays to contractors (disputes) If none of the previous points apply to your project, you do not need to maintain your baseline. I would still recommend you quickly set the first baseline, so you can become a better estimator by comparing actuals against your original estimates stored in the baseline. You do not need to maintain that baseline. This leads me to the following question: What feature set is needed in Microsoft Project for proper re-baselining? The following new features are needed in both Project for Desktop and Project for the web. They are not small investments (in particular, the first one will be costly): Recommendation #5A: I suggest locking of certain fields (i.e. field-related locking of data), so the baseline fields (columns) can effectively be protected against accidental, ignorant, or malicious re-baselining. The locks should be part of the security system and be permission-based: Do you have the authority to change the baseline fields? Project for Desktop has only five baselines that can be protected. Each of these is a set of related, baseline fields: start, finish, duration, work, and cost. We do not have real field-level security that can be set up on a field‑by‑field basis for all ten baselines. In Time Models, you only need to protect start, finish, and duration. In Workload Modeling, you can protect Work, in addition, and, in Cost Modeling, you can protect cost, as well. Field-level security is also useful for protecting Deadline dates. Recommendation #5B: Once the first baseline is set, the feature re-baseline for the entire project should be disabled from thereon (except for people with the right permissions). I believe only the option to re-baseline ž For selected Tasks should stay enabled for people with the right permissions. Recommendation #5C: I suggest creating a new change request feature. Once the first baseline is set, project managers should be able to create change requests in their schedule to explore how much more time (duration), workload, and cost a change request would require, so they can fill out the change request form that needs to be submitted for approval. Note that a single change request may require the scheduler to make multiple changes to their schedule. All these changes could be captured in the new “change request” feature. The change request feature essentially is a set of related actions in the list for Undo and known as “Change Request X.” Recommendation #5D: How about a new feature that analyzes if there any interactions between change requests that are still in the queue? Multiple change requests in the queue may start to interfere with one another and the new change request feature should analyze if the newly proposed change request interferes with any queued change requests (in terms of tasks affected, their dates, durations, and cost), and, if so, ask for a decision to prioritize those change requests. The high-priority change requests that do not affect each other will survive. The other, lower-priority change request(s) will need to be modified or canceled. In order to minimize interaction between change requests, it is important that the project governance ensures that change requests are processed regularly (approved/rejected).   Recommendation #5E: Additionally, I suggest a feature to undo a change request: After filling out the change request form, the scheduler needs to undo the entire set of changes of the change request in the schedule (using the Inactive feature, perhaps?) temporarily until the change request is approved. Microsoft Project needs an easy new feature to do this with a few mouse clicks. Each change request should still contain the list of all changes to be made to the schedule. Recommendation #5F: Microsoft Project needs to keep track of which tasks are affected by each change request. A procedure that does this would start by taking a snapshot of all dates, durations, work, and cost numbers. Then, the scheduler enters all changes for the request at hand. Lastly, the Microsoft Project software would identify and flag all future tasks affected (or rescheduled) by the change request by looking at what dates, durations, work, and cost numbers would change and identifying those tasks. Microsoft Project needs to make sure the affected tasks only include future tasks and none of the past tasks that are partially or entirely completed. Recommendation #5G: A new feature to implement change requests once approved would then be required. After approval of the change request, the scheduler should be able to re-instate all changes from the request with a few mouse clicks: Select a change request from the list of queued requests, and click a button to implement the it, re-instating all its changes in the schedule. Recommendation #5H: Microsoft Project should offer to re-baseline all new tasks and all other tasks affected by a particular change request with a few mouse clicks: Select a change request and click a button to re-baseline all new and affected tasks. (NOTE: There is a way to do this currently with Microsoft Project, but, in a training, it takes me two hours to explain this or you will need to read 20 pages in my Forecast Scheduling textbooks and remember each detail. Many are not willing to make such a time investment). It should not be this hard to maintain the integrity of a baseline schedule. This is why I almost always lost the battle to get users to perform proper baselining. With the introduction of Project for the web, Microsoft has another chance to make re-baselining much easier by adding the features I’ve described. Or, in the case of Project for Desktop, Microsoft can resuscitate baselining by adding these new features into that wonderful application. Please leave your comments below if you want better re-baselining features, and, if so, whether I have described them in a way you need them to be. This concludes the fifth in my Better Microsoft Project series of articles. You can find the earlier articles here: #1, #2, #3, and #4. Thanks for reading!

A Better Microsoft Project: Workload Levelling and Resource-Critical Path

Most projects are logic-constrained projects (or, if I might suggest, wrongfully treated as such). A logic-constrained project has a duration only determined by logic (i.e., the network of dependencies).1 As I explained previously in this series of articles, once you have all dependencies, the Most‑Critical Path in the network then determines the duration of the project. For an explanation of this new concept of the Most-Critical Path, please read A Better Microsoft Project: Background Color in D * U = W Fields to Communicate which Fields are Protected and Editable, which concluded our recommendations for Time Modeling. In this fourth article, we will venture into workload modeling and discuss resource-constrained scheduling. A schedule is resource‑constrained when its activities require more resources than are available for (part of) the project duration. In a resource-constrained schedule, the duration of the project is often determined by one or more bottleneck resources (the ones that are in least supply relative to demand for them). When tasks are plenty and resources are slim, schedules tend to extend, and projects take longer than the logic by itself would suggest. If you manage a resource-constrained project, you will often artificially delay activities as to not overwork (or burn out) your team members. Let’s consider what typically causes projects to be resource-constrained: The current supply chain problems, caused by COVID-19 and Russia’s invasion of Ukraine, have turned many more projects from logic-constrained projects into resource-constrained projects. In all releases of Microsoft Project, so far, I believe Microsoft only delivered half of the functionality needed for resource-constrained scheduling when they programmed only the workload levelling algorithms. They also needed several iterations of this functionality before they got it right; it is a very complex subject matter after all. I was first introduced to the complexity of workload leveling by David Curling, the late founder of what is now called the PM World Library, who presented the following puzzle in the early 1990’s to our project management community: What is the shortest possible schedule in the following project? When David posed this challenge, the leveling feature of Microsoft Project 1995 was using only one algorithm: Schedule the least-Total-Slack-task-first. As you can see in the following table, Microsoft was badly beaten by all its competitors, even though, ironically, none of them exist any longer. I scheduled this simple example in four different project scheduling applications and ran their workload leveling function: As you can see, Microsoft Project produced the longest schedule of 32 days, whereas all its competitors produced the shortest possible schedule of 19 days, a significant defeat. Upon further research with other examples, it also became clear to me that Microsoft Project 1995 only used a single algorithm for workload leveling, whereas CA‑SuperProject used multiple algorithms to find the tightest schedule. Starting with the 2010-release, Microsoft Project could find the 19‑day shortest version of the schedule. Running these tests taught me that no single workload‑leveling algorithm could always find the shortest‑possible schedule in all resource-constrained schedules. I was surprised by this finding because, at first glance, the Least-Total-Slack-first algorithm seems the most-logical: Schedule those tasks first that have the least amount of schedule flexibility (Total Slack or buffer), and the most-logical algorithm must be the best, right? In the previous example, we see that another algorithm (shortest-task-first) is necessary to find the shortest possible schedule. In other words, workload leveling is more complex than I thought. I suspect this is true for most people. At around the same time that I was testing this, a realization started to dawn on me. It was that Microsoft had only done the least amount of work to find a minimum‑viable product to sell on a mass‑scale—one with only the feature of workload leveling. Then, they made money on it, but stopped further investment in the product. They sell the product worldwide (which few companies can) on a massive scale (software products can be reproduced infinitely at no cost), so the price can be kept low to keep competition out while also maximizing their profits. Microsoft was the first to develop this successful business formula. I daresay this is ‘lazy,’ and I use the term deliberately here because Microsoft provided only half the solution that is needed for resource-constrained projects. If you have ever looked at the Critical Path in a workload-leveled schedule, you would immediately see that the software is lacking. You may not be as much of a geek as I am, so here is the workload-leveled version of the previous example with the Critical Path highlighted in red: You can see that only two tasks, ‘6 Activity E’ and ‘7 Activity F,’are colored red and highlighted as critical. The Critical Path is incomplete and, essentially, useless. It only explains about half of the project duration, whereas proper a Critical Path would explain the entire project duration. We need a complete Critical Path that covers the entire project duration here—what I’d call a “Resource-Critical Path.” A Resource‑Critical Path takes logical dependencies AND resource dependencies into account. The Resource‑Critical Path for the same example would look like this (output was created with PathsPro, an add-in for Microsoft Project from ProjectPro): The activities that truly explain why this project lasts 32 days are: As you can see, a Resource-Critical Path consists of logical dependencies and resource dependencies, the latter are the ones that Microsoft Project never could identify. That is the second half of the complete solution needed for resource-constrained schedules. In 1959, James Kelley of Remington Rand and Morgan Walker of DuPont developed a technique to analyze a network of dependencies called the Critical Path Method (CPM). He made the assumption that projects have access to unlimited resources and deliberately chose not to deal with the complexities of resource constraints and workload leveling. It was a smart assumption at that time, because we now realize how complex workload leveling is. It was also a reasonable assumption when launching an entirely new concept. This concept of ‘Critical Path’ would eventually conquer the entire world in the following decennia. Today; however, I must ask: Does your current project have access to unlimited resources? Mine never do and never will. In current times, with cut-throat competition that comes from all corners of the world, projects always need to be delivered as soon as possible and resources will always be in short‑supply. Under these circumstances, this assumption of “unlimited resources” is no longer viable. Like they eventually always do, assumptions make an “ass” out of “u” and “me” (long‑form for “assume”). Kelley & Walker’s assumption has outlived its time. In 1999, I started publishing about resource-constrained scheduling in PM Network from PMI with the article, Take the Path that is Really Critical. Ten years later, I started an international working group to define the next edition of the Critical Path theory, called Critical Path 2.0. Critical Path 2.0 had to consider logic-constrained AND resource-constrained projects. If you are interested in deeper reading on this topic, I recommend reading the working group’s final proceedings published here. I felt an urgent need to address the emerging reality of more projects turning into resource‑constrained projects. The need for Critical Path 2.0 is stronger now than it has ever been. Going back to Microsoft! As early as 2000, I started publicly asking Microsoft to add the Resource-Critical Path feature to Microsoft Project in my textbook, Dynamic Scheduling with Microsoft Project 2000. I repeated this request in later editions under the same title, and again in my new textbooks Forecast Scheduling 2010, 2013, and 2018. Here are my requests again: You may be asking, what is this PathsPro you’ve referenced, Eric? Well, in 2012, I decided to hire a programmer and build this complete Critical Path feature myself in the form of an add-in to Microsoft Project that we called PathsPro. It took one year to complete. More info is available here, should you be interested. PathsPro does an amazing job of finding the Most-Critical Path in just about any schedule: Click here for the SanDisk case study, which demonstrates the PathsPro solution for this most challenging group of projects/programs. Again, readers, please let me and Microsoft know what you think of these recommendations in your comments below. Do you support these requests or not, and why? 1Dependencies are relationships between the activities in the project that are necessary from a practical point of view.

A Better Microsoft Project: Background Color in D * U = W fields to Communicate Which Fields are Protected and Editable

This article is the third in this series, A Better Microsoft Project. You can find the first two articles here and here. I believe the fields involved in assigning resources in MS Project have created the most problems and biggest challenges for users in previous decades. Regardless of whether my thousands of students had used MS Project just one month, a year, or even a decade, I could safely assume that simplifying the process of assigning resources was of interest to them! The issue with Microsoft Project is that there are too many fields that make Modeling Workloads too cumbersome: Recommendation #3A: Rename the field Work in Project for Desktop to Effort like has been done in Project for the web. These five fields create a grant total of 3*2*3=18 possible permutations of values, which creates too much complexity for the user. How do you deal with an equation that has three variables: D * U = W? First you protect (or fix) one, then you change the second, and, finally, the third one will always be re-calculated by MS Project! You can protect a value by setting the task field Type to Fixed Duration, Fixed Units, or Fixed Work. This is what I’ve taught students in every one of my classes! People could remember this and it stopped them from fighting with Microsoft Project. An often-heard criticism was, “Microsoft Project is changing the values I just entered!” Let’s simplify by taking an option away that does not make sense. Recommendation #3B is disallow changing the value that is fixed. Project for Desktop allows you to change the Duration on a Fixed Duration task, but let’s think about that. Why would you change a value after you tell the scheduling engine to keep it fixed (constant)? You could also change the Units on a Fixed Units task, and change the Work on a Fixed Work task. This caused many users to get confused and provided me with a lot of training work. Let’s simplify it further and take an option away that adds little value. Recommendation #3C is to remove the field Effort–Driven from Project for Desktop. I suggest this because this field increases the number of possibilities by a factor of two (from 9 to 18) adding much complexity with little, extra usability. The Type of task Fixed Work accomplishes most of what the field Effort–Driven = Yes does. You can see this in the interface: Once Fixed Work is selected, Effort-Driven is always Yes. Good riddance of redundancy that makes the interface unnecessarily complex! How many options are left? Removing the Effort–Driven field removes 9 of the 18 options. Disallowing changing the fixed value removes another three options (from 9 down to 6 permutations). When you fix (protect) one value (one of three), you can only change one of the other two values and get 3*2=6 options for the user: There are still six options to learn, so the user interface needs to guide users well in this, but I believe it would be a big improvement. I also recommend guiding the user by making these additional improvements: This list allows you to pick the (multiple) resource(s) to assign to the task. Perhaps a new assignment-related Units field can be added to this list, too. In the previous screenshot for task 2 Water system, the Duration cell is red and cannot be changed (Fixed Duration), the Units and Effort (Work) cells are green, and one of those can be changed. Let’s say, the user changes the Units value by adding another resource, the Effort (Work) field will be recalculated. Note that: How would all these recommendations work together? Let’s look at some examples. The following project schedule is a Time Model with the Durations entered currently on all tasks and their task Type set automatically to Fixed Duration (all Duration fields have red background color): We will change this Time Model into a Workload Model by loading resources and assigning them to all activities. The result is as follows: Now we want to make a change to this Workload Model. Perhaps we are not happy with the fact that task 3 Septic System takes twice as long as task 2 and we ask the septic engineers to double their human resources working on the septic system while keeping the Effort the same. We expect that Microsoft Project will recalculate and half the Duration and make it as long as its concurrent task 2 Water System: We need to protect the Effort first. With my preceding recommendations in place, we’d right-click on the cell Effort for task 3 and select item Protect the value in this cell from the pop-up menu. As a result, the background color for task 3 Septic System switched. Duration is now green (editable), and Effort of 960h is red and protected. Additionally, the field Type is automatically switched to Fixed Work for task 3 Septic System: The Effort is now protected, meaning the work is not going away. It is just going to be spread over more resources. Now, we can add two more septic engineers on task 3 and the result is that the Effort of 960h is still the same, but the Duration has gone from 60d to 30d, as shown: As you can see, making changes to assignments and producing accurate forecasts of workloads is much easier with this way of working: Since Microsoft Project has a formula with three variables, you should always protect one variable before changing a second variable and then have Microsoft Project automatically recalculate the third variable. Simple and reliable. Do you agree that my recommended changes to the Project interface would make working with Project a lot easier than it is now and that it would lure more users to start modeling workloads in their project? Let me know in the comments below if you like this re-designed interface for assigning resources and changing assignments. I look forward to your feedback.

A Better Microsoft Project for Time Modeling: Deadlines and the (Most‑) Critical Path

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): 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: 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!

A Better Microsoft Project

This article is the first in a series, in which I wish to make a case for adding certain features to Microsoft’s Project for Desktop and Project for the web software. You might wonder why I am publishing on MPUG vs. Microsoft’s feedback portal. Well, I needed more than a few paragraphs to share the features I have in mind. At my company, ProjectPro, we have worked directly with Microsoft Project software for over 30 years, and, during this time, several new features to be added and ideas for other features to be improved have risen to the top. This series of articles is meant to describe in enough detail what we’ve envisioned for both Microsoft Project versions in-use today: To present these recommendations in a structure that, I hope, will be useful, we will utilize our ProjectPro Forecasting Framework with the intention of laying out a high-level roadmap for Microsoft Project in the long-term. This framework originates from 30-years of work experience asking organizations what they need in terms of training. For almost 25 of those 30 years, I shared with my clients a master list of potential course topics and asked them to indicate what they would like their project managers to be trained on. Using this data, I eventually started to recognize three basic user profiles (“user segments” or “customer segments,” in marketing terms). The three are as follows: Before we go further, I believe it is important to address two wide-spread misunderstandings pre-emptively: The complete ProjectPro Forecasting Framework is depicted in the following chart: Some additional facts about our ProjectPro Forecasting Framework: Ever since ProjectPro developed this framework, we only need to ask our clients a single question instead of digging through endless lists of training topics for Microsoft Project. We show them the framework and ask: What forecast do you want to attain when working with Microsoft Project—time forecast, workload forecast, or cost forecast? As I introduce my recommendations for new features or improvements to MS Project, I’ll be doing it within the context of this framework (i.e. a new feature for both applications (Project for the web and Project for Desktop) or a modification of the current features in Project for Desktop). My first recommendation (#1) to Microsoft is to adopt this framework as a high-level roadmap for the software, so I’d say they should firstly, create all the features for Time Modeling. Secondly, I’d suggest they add features to support Workload Modeling. Thirdly (and lastly), I recommend adding features for Cost Modeling. I’d also recommend that they add the Deadline feature to Project for the web (Recommendation #2A), so that it has the capability for simple Time Modeling. We’ll discuss that in my next article, where I’ll continue numbering my recommendations with a unique number, so you can easily refer to any of them when commenting below this article or future articles. In 2019, I met with several leaders at Microsoft Project individually at the Microsoft’s Inspire conference, and I introduced each of them to this framework with the three archetypes of users. I requested they add only one feature to Project for the web; that of Deadlines to complete the capabilities for Time Modeling in Project for the web. Two out of three seemed interested, and I got one, “No.” You can’t say I didn’t try! One leader showed a lot of respect for my work, which warmed my project management heart. Receiving respect from a Microsoft employee has rarely occurred in the past for me I think it is, at least in part, due to the fact that my contacts at Microsoft turn over about every three years; I have already survived at least six General Managers of Microsoft Project. The new shift typically does not know any of the long-serving community members, and does not often have enough time to get good at project management … but, I digress. I’d love to hear from you in the comments below. And look forward to sharing my recommendations in upcoming articles in this series.

Waterfall Should Have Never Existed: Part 2

We left off in Part 1 of this article asking the question of HOW Agile and Critical Path could exist side-by-side in a single project schedule without affecting each other (much)? I laid out three dilemmas there are to resolve when you try to combine these two approaches that are different from each other but not each other’s opposites (as I argued in Part 1): The WBS of an Agile schedule is sprint-oriented (adaptive) with user stories within each sprint, whereas the WBS in a Critical Path schedule (predictive) is broken down in a deliverable-oriented way with activities within each deliverable. Agilists estimate in anything except hours, whereas predictive folks need the estimates expressed in hours to create their Gantt Charts and calculate Critical Path. Agilists don’t like identifying all dependencies between activities, but predictive people need all dependencies, the right types of dependencies and all entered correctly into their scheduling application. They need complete and correct network logic. Let’s dig into the solutions I am proposing now, and remember that I’m suggesting a compromise to make combining BOTH approaches in ONE schedule work. The benefit for this true hybrid approach of Agile and Critical Path is being able to manage your team using Agile (manage down) while managing your executives using Critical Path (manage up). Another use case is if one part of your project team wants to use Agile (software), whereas the others want to use Critical Path (hardware). This hybrid approach if useful for project managers that find themselves in the following situations: You are building a hardware product (Critical Path) that has a software component as well (Agile). You are designing a defense system with tangible components (Critical Path) and software components for intelligence gathering and processing (Agile). You are building a software application (Agile) for a client that expects a full tally of the cost and a firm target date for delivery as captured in a firm-fixed price contract (Critical Path). You are a contract research firm that is performing the clinical study for a new vaccine and needs to create the database and software interfaces specific to this research (Agile), as well as accomplish the purchasing, configuring, and distributing of hardware devices across the world to capture the results of the clinical study (Critical Path). These are just some examples of how you might combine Agile and Critical Path (CP) in one schedule. Let’s solve the dilemmas to make this work. Solution 1: WBS for CP and Agile By tagging each line item (activity or user story) in the WBS and using the grouping feature in your scheduling software, you can easily convert one WBS to another. You can do this in Microsoft Project, Primavera, and most other scheduling applications. Let’s take a look at the Critical Path view with a deliverable-oriented WBS (with deliverables, activities and milestones): Note that each line item (activity) has been tagged in the field Sprints with one of labels Sprint 1 – July, Sprint 2 – August, or Sprint Backlog, which allows me to create the following Agile view using the Group By feature in the same project schedule in Microsoft Project, as shown below with all activities allocated to the sprints and backlog: Solution 2: Converting Agile Estimates to Hours for CPM I once faced having to shorten the schedule of an Agile project for a team that was on the Critical Path of a highly visible, business transformation program at a financial institution. They were managing the data migration from an old system into a new one and presented a schedule that was half a year long. A similar endeavor had taken only three months ten years earlier. It was clear that the executive would not tolerate extending the duration of the program unnecessarily. I offered the option of taking on more team members, but the Agile team did not want a larger team, because that was not ‘Agile’ enough. I reacted in an ‘agile’ way to this ‘Agile’ team’s objection by proposing the start of a second Agile team working side by side with the first. The second team would take half of their workload and shorten their project by roughly half, but they did not want this either … until some executives overrode their objections. ‘Agile’ dictates that you keep the team size constant so that team members get to know each other and learn each other’s strengths and weaknesses. Agile empowers teams by having them self-assign all activities, which can optimize the allocation of assignments and results in a constant stream of productivity (called ‘velocity’ in Agile). Clearly, the dilemma of reconciling different types of estimates is tougher to resolve, but here is the solution I eventually found that is based on keeping a team size fixed. Let’s say that your Agile team consists of a fixed number of people—ten. You have an Agile project with sprints of one month each. Each month is about 4 weeks of 40 hours/week or 160 hours per team member. So, you have 10 team members * 160 hours per month resulting in 1600 hours per month. Let’s assume that the Agile team accepted a total of 800 points into their first sprint of one month long. We know that each point converts into two hours of effort (=1600 hours / 800 points), and we can now convert Agile estimates into hours of effort. We can create a Gantt Chart and have Microsoft Project calculate the Critical Path (provided I have entered the dependencies). You can see this in the previous illustration where each Agile estimate in the column Agile Points is converted using a custom-built formula (using a conversion factor of 3.87 for this particular project). You see the results of this calculation in the column Hours (Agile Pts. * 3.87) that was created using one of the extra number fields (like Number1, etc.) and the customize fields feature accessible from the ribbon (Format, button Custom Fields to enter a Formula). Finally, these calculated effort estimates are copied for this sprint from the formula field and manually pasted into the out-of-the-box Work field while either: Keeping the task Type to Fixed Durations (and Effort Driven is No) if you want to see how many team members need to be allocated to each activity, or Keeping the task Type to Fixed Units (and Effort Driven is No) if you have assigned the resources already and want to see the durations calculated by Microsoft Project. In this case, you may need to make some tweaks to the durations (if they extend beyond the fixed duration of the sprint). You’ll now have a schedule that started with Agile estimates, but also has the estimates in hours—person hours in the field Work and business hours in the field Duration. You need the Durations to build the Critical Path schedule a.k.a. a Gantt Chart. The velocity for a team with a constant number of members typically stays constant over time (across the sprints), and the number of points accepted into each sprint will also stay relatively constant after the third sprint when the proper velocity has been established for that team. The conversion factor can be adjusted after the first few sprints, if needed, because the resulting hours need to be copied into the Work column on a sprint-by-sprint basis. So, for each sprint you can determine a new conversion factor and adjust the formula. In most Agile projects, you don’t need to adjust the formula any longer once the velocity has stabilized after the second or third sprint. No Solution 3: Compromise Needed As the project manager addressing the question ‘to link or not to link,’ I simply request that the Agile team works with me and helps me sort out the dependencies between the activities (or user stories) in the sprints and in the entire backlog. I create a complete and correct network logic for all WBS-items, and this has, so far, been a reasonable compromise for all Agile teams to make. At least for the ones, I have met so far. With these three dilemmas addressed, organizations can make both approaches co-exist in ONE schedule, which allows one to happily switch from an Agile view of the schedule (when presenting to my Agile team i.e. managing-down) to a predictive view of the schedule (when I present to executives i.e. managing-up or managing‑out to clients). Switching views takes two clicks of the mouse, and in short, I manage‑down with adaptive Agile and manage‑up with predictive Critical Path. I also manage-in and relax by keeping a handle on the overview and avoid the stress of a difficult situation where different stakeholders pull me into different directions: i.e. my team wants to be managed in an Agile way, whereas executives that pay my salary, want forecasts. If you would like to learn more about how to convert an Agile schedule to a Critical Path schedule or vice versa, please refer to my textbook ‘Forecasting Programs’ (see this website: Books – ProjectPro Corp). Chapter 3 is entirely dedicated to this topic. To explore the Microsoft Project schedule from which I created the screenshots in this article, download the ZIP-file and Microsoft Project schedule from our website at Articles – ProjectPro Corp. Thanks for reading both parts of this article Part 1 here if you missed it). Please leave any comments you have below. I have made some daring statements and have summarized the last 30 years in the way I see them. I look forward to hearing what you agree and disagree with in this series of articles.

Waterfall Should Have Never Existed: Part 1

I’d like to begin by sharing a brilliant quote that puts the latest project management fashion, Agile, into humbling perspective: “A Waterfall project is just an Agile (Scrum) project with one huge sprint! An Agile project is just a Waterfall project almost entirely implemented using Rolling Wave Planning! (from George Intzesiloglou, UK on 2020-Sep-11 at In the following two-part article, I will argue that: ‘Agile’ is not agile. ‘Waterfall’ is not the same as Critical Path. ‘Waterfall’ should never have existed. Hybrid approaches between ‘Agile’ and ‘Waterfall-that-should-not-be’ should not exist either. A true hybrid approach between ‘adaptive project management’ (Agile) and ‘predictive project management’ (like Critical Path) should exist, can exist, and does exist. This is most viable. In other words, be prepared to have your world shaken up a little bit. To entice you to continue to read, I promise to follow my claims with a solution for doing both Agile and Critical Path concurrently. In fact, you do not have to choose between Agile and Critical Path. Both can be done in one schedule! I will explain how you can marry these two seemingly‑opposite approaches to scheduling in one project in Part 2 of this article. I will even recommend using ‘Agile’ to manage-down (i.e. your project team). At the same time, I will recommend Critical Path (CPM): To manage-up (i.e. your executives), To manage-out (i.e. your clients), and To manage-in (i.e. yourself as the project manager) Let’s use CPM to manage the overview of a project … and your sanity, don’t forget. Before we get to that; however, let’s consider why Agile became so popular to begin with. Why Did Agile Become So Popular? For at least twenty years and counting, the world around us has become more and more software driven, and, as a result, more digital. Electric vehicles are about 50% software, in terms of value, whereas fossil fuel cars are mostly hardware. Banks have essentially been software developing organizations for a long time. Fintech is accelerating this trend. In the last twenty years, records management began moving away from paper records to electronic ones. We see this happening in the medical world nowadays. The wall of paper files in your doctor’s office will soon be gone. Obviously, as digital transformation has occurred, and the number of software projects increased exponentially. This has led to a dramatic growth in software development projects and in the number of software project managers we’ve seen and will continue to see. It’s accompanied by a flourishing consulting industry eager to sell the latest management fad to anyone with a heartbeat and willingness to listen. At the turn of the millennium, software projects were mostly organized in a Waterfall way and were reported to have poor results (Standish Group reports). In 2001, a group of software thought-leaders got together and hammered out the Agile Manifesto. They called themselves the ‘Agile Alliance’ and the Agile movement was born. It is riding the wave of digitizing our world. The Agile movement set up associations (‘Agile Alliance’ and ‘DSDM Consortium’). The latter, Dynamic Systems Development Method (DSDM) came from the Rapid Application Development movement. These associations and thought leaders, authors, and researchers developed several flavors of Agile: Scrum, Scrum XP (eXtreme Programming), ScrumBan, DSDM, DevOps, and Lean-Agile, and market them vigorously. There are even resellers for the DSDM Consortium if you want to sell DSDM. In the process of this development, Agilists hijacked a few techniques and presented them as their own. For example, KanBan and incremental scheduling (a.k.a. ‘Rolling Wave’ scheduling which preceded Agile by many years). Many private companies jumped on the opportunity and have developed software applications to support the Agile way of delivering projects: JIRA, @Task, Monday, Trello, Wrike, VersionOne, etc. As you can see, a whole new cottage industry grew out of the ‘Agile’ movement. Since about 2010, Agile was challenged to start providing solutions at the executive level within organizations. These organizations needed an approach that would start providing predictions. One response to this was Dean Leffingwell private company, Scaled Agile, Inc. He created the ‘Scaled Agile Framework’ methodology (SAFe) and SAFe-assessment tools for organizations, as well as ‘SAFe certification’ for professionals. At the time of writing, over 600,000 practitioners have been trained worldwide in SAFe by over 350 ‘Scaled Agile Partners’ Simultaneously, Scrum was put into the public domain and responded with its ‘Scrum of scrums,’ which seems to flounder in the shadow of Scaled Agile. When executives started to hear about ‘Agile,’ they kind of liked the term and, hence, the term ‘the agile organization’ was born. In short, ‘Agile’ began shaping up for the big leagues (i.e. the executive level). Please note I am using the uppercase ‘Agile’ (as in ‘Agile Project Management’) and the lowercase ‘agile’ (as in ‘more adaptive’). I will use these consistently going forward to separate the ‘Agile’ project delivery method from the common sense meaning of the word ‘agile’ executives felt attracted to. The ‘agile’ Organization Just about every executive wants to have an ‘agile organization.’ The word ‘agile’ is just like the word ‘Quality.’ You cannot say ‘No‘ to it; you cannot NOT want it. Executives cannot say ‘No’ to ‘agile,’ because it is a word that is inherently positive in nature and wanted in a dynamic, capitalist society. The idea of ‘agile’ is something most executives want for their organization. Who does not want their company to be flexible and responsive to our constantly changing world? There are enough changes right now: the COVID-19 pandemic, the Black Lives Matter (BLM) movement against systemic racism, the opposing forces of globalization versus protectionism, the arrival of new technologies like machine learning and artificial intelligence, and our changing climate. In the context of a quickly changing world, executives are being sold on the concept of making their organizations more ‘agile’ (lowercase!) by adopting ‘Agile’ (uppercase!) project management practices. In retrospect, I think it is a widespread misunderstanding that if executives implement ‘Agile Project Management’ (Uppercase), they will make their organizations more ‘agile’ (lowercase). After all, Agile is ‘a highly structured way of delivering projects.’; in other words: ‘Agile’ is not ‘agile’! In my mind, ANY form of project management makes an organization more ‘agile’ as in ‘adaptive’. After all, project management, by its definition, is ‘managing a temporary endeavor that creates a unique product, service, or result’ (PMBOK® Guide, any edition). Hence, project management ALWAYS brings about change, and ‘bringing about change’ is perceived as being ‘agile.’ Over time, it amazed me how ‘Agile Project Management’ (uppercase!) ran away with the main prize of getting the ear of C-level executives: PMI had tried for many years to get their ear after all. Executives, in their eternal quest to making their organization more ‘agile’ grew interested in ‘Agile Project Management’. The good thing is that ‘Agile Project Management’ has brought the topic of ‘project management’ into executive discussions and into the boardroom of organizations, and so PMI followed along. In my mind, implementing ‘predictive project management’ techniques (i.e. Critical Path, Resource Critical Path, Critical Chain, Earned Value, Earned Work) make an organization at least as ‘agile’ (in the sense of ‘more adaptive’) as the ‘adaptive project management’ technique of uppercase ‘Agile’ would. Agile Will Not Conquer the World Agile will never conquer the entire world of projects! There are many types of projects that will NEVER be planned in an Agile way: construction projects, plant shutdown and turnaround projects, software enhancements on core operations systems (as little as possible downtime allowed), and many others. Can you imagine that a cloud scraper would be built in an Agile way: “Oh, we built the next floor, let’s go back to the client now … see if they like this floor and then we will ask them for a budget to build the next floor! Not sure if it will be financed … oh well, we will just stop this project for a while…” This will never happen; Agile will not and should not be implemented in the construction industry—and many other industries for that matter that can only use, sell or lease finished products (as opposed to ‘minimum viable products’, a concept from Agile). Just today, I heard a project manager who builds nuclear power stations say: ‘Agile never made sense to me!’. Currently, Agile is only applied in research, software development, IT, and marketing projects. As far as I have observed, broadly confirmed by the 14th ‘Annual State of Agile’ report from VersionOne: “The survey results indicate that agility is largely confined to [software] development, IT, and operations.” (page 4). In my estimation, Agile will be applied in at most 50% of our world’s projects and, in a few years, less than that as I see in my crystal ball. Why? I think that the market share of Agile will shrink in the future for two reasons: Firstly, executives, sponsors, and investors will never stop asking for forecasts that Agile does not provide, cannot provide, and does not want to provide. Agile is in the school of ‘adaptive project management,’ after all. ‘Agile’ allows the continuous adding of scope to or removing it from the project that is delivered in several fixed periods with a team of fixed size. In this respect, Agile is not the opposite of predictive project management, because none of the predictive techniques prescribes that the scope should be fixed. They use change requests to manage it. Only ‘predictive project management’ (i.e. Critical Path, Resource Critical Path, Critical Chain, Earned Value, Earned Work, etc.) are designed to, and are able to and will always provide time forecasts by identifying the dependencies between the items in the WBS. The key difference between ‘adaptive’ and ‘predictive’ techniques is that all predictive techniques expect you to identify all dependencies between activities (create complete and correct network logic), whereas Agilists are not expected to do that. The second reason that I think Agile will shrink in the future is that it is, in its essence, non-committal in terms of finishing the product or service, and in terms of time (deadline) or cost commitments (budget). Agilists will not commit to building a complete product, neither will they tell you in advance how much it will cost, or how long it will take. Agilists will get you to start investing and then keep you going in a way that reminds me of how consulting firms would string their clients along in the 1990’s using contracts of the ‘Time & Materials’ With a healthy dose of sarcasm, ‘Time & Materials’ can be summarized as: “I will work as slow as possible for as long as possible and expect to be paid for this!” Consulting firms knew how to maximize their profits in the 1990’s! Since, Agile is a new incarnation of Time & Materials contracting in my mind, I am afraid that Agile will be pushed back to a much smaller market share in the world within the foreseeable future. It was no surprise that Time & Materials contracting was relegated to the sidelines by the late 1990’s and replaced by ‘Firm Fixed’ price contracts. For ‘Firm Fixed’ price contracts, you need to establish the entire scope and produce accurate predictions. Predictive project management is much better at forecasting than Agile ever will be. Many people think that ‘predictive project management’ (i.e. Critical Path) is the same as ‘waterfall.’ This is nonsense! ‘Waterfall’ means that, before the project starts, you plan an entire project out in (somewhat) chronological phases. The concept of ‘phases’ feels good, and essentially, ‘phases’ are an arbitrary way to cut up a large piece of bread into smaller slices that you can actually digest. Phases can even overlap in time, because there are no transition criteria that must be met before a project goes from one phase over into the next. This is where Dr. Robert Cooper has improved the phase-based thinking significantly by adding transition criteria to the phases. He captured this in his famous Stage-Gate methodology: Each gate has certain criteria that MUST be met before a project can move to the next stage (phase). Notice that he replaced the word ‘phase’ with the word ‘stage’; he could have called his invention ‘phase-gate’, but he didn’t. Since ‘Agile’ was a reaction to ‘Waterfall that-should‑never‑have‑existed,’ what does this mean for ‘Agile’ itself? Is it a solution that is in a desperate search for a problem? I do not think so. When I state ‘Waterfall’ should have never existed, I am not saying ‘Agile’ project delivery should never have existed. Agile has its place and will hold its place. Agile fits well in a situation where people are working at the frontier of what people know in its broadest sense (knowledge-constrained projects). Obviously, R&D projects are in the field of knowledge-constrained projects. In software development projects, customers often find it difficult to verbalize all requirements, which imposes a knowledge-constraint to the project manager. If you are interested in the topic of picking the right scheduling approach, please retrieve my (free) White Paper ‘Choosing the Best Scheduling Approach for Your Project’ and look at its Project Ideals and Constraints (PIC) matrix: click here ( ) or buy my textbook ‘Forecasting Programs’ (same website, but under ‘Books’). Both discuss what place in this world all scheduling methods that I’ve mentioned in this article, have, including ‘Agile’. ‘Waterfall’ Should Never Have Existed! Predictive project management has never used ‘phases’ for as long as I have been at it (soon 30 years!). Ever since the first PMBOK® Guide was published in 1983, PMI encouraged ‘deliverable-oriented’ Work Breakdown Structures (WBS) rather than ‘phase-oriented’ WBS’s. In contrast to ‘phases’, a ‘deliverable’ is simply defined as ‘a measurable thing of value that someone is willing to pay for’ (source: my textbook ‘Forecast Scheduling’). A ‘phase’ is not measurable, but a ‘deliverable’ is measurable by definition! So, given the fact that ‘Waterfall’ is based on a phase‑oriented breakdown of the work in a project AND ‘phases’ never were the PMI-recommended breakdown-orientation for developing WBSs, I would argue that ‘Waterfall’ never really existed (except in the minds of some software development project managers and their misguided world of Software Development Life‑Cycles (SDLC) of the 1990’s). Hence, I’d like to proclaim: Waterfall is dead! Waterfall should have never existed! Why do we continue to refer to ‘Waterfall’ if it was a dead-end in the first place? Let’s simply stop talking about ‘Waterfall’; it is a dinosaur now; it is dead! Let’s get rid of it; it’s time to move on! To Hybrid or Not to Hybrid? In the past few years, more and more organizations are publicly admitting to the fact that Agile was not implemented as per the Agile textbook, but in a modified way, a mix between Agile and Waterfall-that-should-never-have-existed. Many people are leery of a ‘hybrid‘ approach that indeed raises an important question: Do we end up with the best of both worlds OR the worst of both? Several project managers have written accounts in which they describe how they ended up with the worst of those two worlds of Agile and Waterfall-that-should-never-have-existed. For example, when there are many conflicting deadlines and the portfolio managers are not setting clear priorities, the autonomy of the agile teams will indeed get compromised: “Do this first instead of your sprint work!” Is this particular case, was it a real ‘hybrid’ approach? Not in my mind! At most, this is ‘Agile’ with a ‘portfolio manager override.’ In my opinion, a true ‘hybrid’ form is a combination of an adaptive (Agile) and a predictive method (like Critical Path). When I realized that Critical Path is just a different approach and not the opposite of Agile, I started thinking about the following important question: Can Agile perhaps be combined with Critical Path in one project schedule? I’ve seen many situations where a project team was asking for Agile while executives asked for forecasts. There is a clear use-case for combining Agile with Critical Path in my experience.     Can Agile be Combined with Critical Path in One Schedule? I mentioned already that Agile and Critical Path are NOT each other’s opposite: Agile and Waterfall are opposites, and instead of coming up with some shade of gray that works for everyone, I would like to present a fresh and completely different approach. What if Agile and Critical Path happily existed side-by-side in a single project schedule without affecting each other (much)? How would that work? Well, there are a few dilemma’s to resolve when you try to combine two approaches that look at first sight very different: The WBS of an Agile schedule is sprint-oriented (adaptive) with user stories within each sprint, whereas the WBS in a Critical Path schedule (predictive) is broken down in a deliverable-oriented way with activities within each deliverable. Agilists estimate in anything except hours, whereas predictive folks need the estimates expressed in hours to create their Gantt Charts and calculate Critical Path. Agilists don’t like identifying all dependencies between activities, but predictive people need all dependencies, the right types of dependencies and all entered correctly into their scheduling application. They need complete and correct network logic. I have solved the first two dilemmas, and propose that Agilists need to compromise on the third to make combining BOTH approaches in ONE schedule work, which I will describe in Part 2 of this article series! What do you think, is there a way to use Agile with your team and Critical Path with your executives? Please comment below and look for part 2 of this article, which will lay out solutions to each of these dilemmas we’ve discussed. Read Part 2 of Waterfall Should Have Never Existed

Microsoft’s PPM Cloud Strategy Failed: What Now?

One thing Edward Snowden has taught the world is this: Never trust the US Government or any other government for that matter! US intelligence is into everything they can get their hands in or as the saying goes, can “force their elbow into,” including software applications or datasets owned by US‑based organizations. I believe this is why Microsoft’s PPM (Project & Portfolio Management) Cloud strategy (see here) is failing, and why it is still failing even after Microsoft has built datacenters in countries across the world. One of the main problems is that Microsoft still cannot guarantee that the data NEVER travels via US-based Internet points (IP-addresses). This allows the CIA to eavesdrop on our Cloud data. Only if a firewall is put around an entire country (as we saw China do), can there be some level of protection from curious foreign intelligence eyes. This is why I think that: Project Online has been adopted at such a low rate outside the US (i.e. the rest of the world): I have had numerous conversations with clients in Canada, and have learned that they are not allowed to buy or will not buy subscriptions to Microsoft Project Online. This is true for Canadian Federal Government departments, government agencies, large Canadian companies, and even medium-sized Canadian companies. If this is true for Canada, it is likely also true for the rest of the world. Project Server installed on-premise is a much more viable proposition for any organization outside of the US. Microsofts Downward Spiral In hindsight, Microsoft created its own downward spiral: All Microsoft PPM partners were forced by Microsoft to ONLY sell subscriptions of the cloud-based Project Online since about 2015. Project Server for on-premise was discontinued at the same time. Microsoft PPM partners failed to sell Project Online because nobody outside of the US trusts Microsoft (or the CIA) with their trade secret data, intellectual property, inventions, or even timelines for their inventions (i.e. Microsoft Project schedules). As a result, Microsoft saw a huge decline in their PPM sales revenue stream. Microsoft wondered why and started to dis-invest in Project Online and dis-invest in Microsoft Project (now called ‘Project Online Desktop Client’). By the way, who came up with that? Desperate at this juncture, Microsoft has begun to develop new products: Planner (that does not integrate well with Microsoft Project), Project for the Web (a mickey mouse tool without much business value), and Project Operations (a competing product from the Microsoft Dynamics development group). The marketing of all these offered products is now so confusing that nobody understands them any longer. MPUG recently featured an article entitled, Cloudy Conditions: Clarifying MS Project’s Plans and Pricing Structures on the topic. Cloudy conditions, indeed! We have not seen a major upgrade in Microsoft Project or Project Server functionality since 2010, the year the new ribbon interface and many new features were introduced. Let’s not forget that is ten years ago now! Microsoft has not developed any significant new features in Microsoft Project since 2013 (seven years ago!!) even though their promise was that if we adopted Project Online, we would get a continuous stream of new features. In my view, this turned out to be a false promise, even though Microsoft would argue it’s because Project Online did not sell enough subscriptions. Again, in my view Microsoft basically destructed their own Microsoft PPM business line of products and profit center for Microsoft Project and Project Server. Given the fact that there are an estimated 30 Million users of Microsoft Project worldwide, the user community is large and vibrant. The PPM market is potentially profitable in my opinion, if Microsoft makes a U-turn in their PPM strategy sooner rather than later. So, how can Microsoft get out of this downward spiral, you may be asking. I’ve listed below my five “shoulds” for Microsoft at this juncture: Microsoft should define a new strategy for its PPM division. Microsoft should start investing again in their on-premise PPM products: Microsoft Project, Microsoft Project Server, and Microsoft PWA (Project Web App). Microsoft should re-instate the three-year development cycle for their on-premise PPM products and develop a major upgrade for 2022. Microsoft should listen more carefully to its PPM user community: There are over 400 new feature suggestions on the UserVoice pages for Microsoft Project (see here), so there surely isn’t a lack of ideas. Microsoft should listen more carefully to their Microsoft Project MVPs who interact with more MS Project users every year than any Microsoft program manager or developer ever will. Last year, I gracefully declined Microsoft’s invitation back into the MVP program, simply because in the seven years I was an MVP, Microsoft never gave me the sense that they heard what I or other MVPs were trying to tell them. Microsoft Project and Project Server deserve to be resuscitated by Microsoft! I think it has been difficult enough for Microsoft Partners in the PPM space these last few years, and I’d like to see Microsoft Project users rally together to encourage Microsoft to change its course in the PPM space. If you agree with this opinion, please express your support in the comments section below. If you disagree, please explain why. Thank you!

  • 1
  • 2
  • 5