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!
