Want to create great Microsoft Project schedules? Follow the three best practices I provide in this article. Next time, I’ll share three more best practices to avoid.
DO Create a WBS
As soon as you schedule a project, your next best step is to get a good understanding of all the work that needs to be done. A work breakdown structure (WBS), sometimes known as a product breakdown structure, will create a structure in your schedule that will help you, your team and stakeholders obtain a clear understanding of all the work the project requires.
Creating a good WBS revolves around the use of summary tasks. A summary task will have all related tasks as subtasks. And the summary task will give you a great way to collapse the schedule to its phases.
To create a summary task, make sure you have the summary and the sub tasks in your schedule already. Now select the sub tasks and use the indent action in the ribbon (Tasks tab | Schedule group) or use a shortcut key combo:
Alt-shift→.
Becomes:
DO Use the Baseline Functionality
This next “Do” is related to the moment you have a good schedule in hand. Maybe it includes a WBS and work or cost information, but a minimum of tasks or dependencies. This is when you’d generally expect to contact your employer/client/stakeholder and say, “Hi! This is what I would like to do. It will take me x time to complete and will cost y amount of money.”
If all parties agree on the schedule, this becomes the schedule you’ll look back to once progress is being made and things start to change in the project.
Now, it would be a shame if you changed your schedule and didn’t have a way to look back at the original schedule, right? Maybe you’re in the habit of creating duplicate or “shadow” schedules. Microsoft Project has functionality to help you out here: the baseline.
You can set up to 11 baselines, but the one that is most important to get hold of is called “Baseline” (without a number). This baseline is visible right away when you select the view, “Tracking Gantt.”
In a 2013 article about baselines on my website, I give some information about what is stored in your schedule. And there’s a whole lot more to be learned. The main takeaway for now is this: You want to secure the original schedule without losing the flexibility to monitor the actual project in one file.
DO Monitor Progress in the Schedule
The schedule needs to be a representation of the actual project that’s underway! That means that you have a nice WBS to help your team understand what needs to be done and a baseline to check if you are still on track with the original intent. But most importantly: you want to monitor progress! Make sure you have actual work, actual costs and or a % complete value in your schedule.
If you don’t monitor progress on your schedule, no one will be able to tell the current status of the project by looking at the Project file alone. And if you don’t monitor progress, you won’t know if you’ll reach the final deadline on time or not.
These are busy times, I’m sure you have a lot on your mind. Free your mind by writing the progress in the schedule, monitor changes and act on just the exceptions. That way you won’t have to micromanage every aspect anymore. Also good to remember: You can use the powerful progress reports in Project Professional (2013 and up):
And:
A Final Note
These three actions are the lifeline of good scheduling with Microsoft Project. If you create any schedule without one or more of these Do’s in place, you’ll miss out on a lot of functionality and fun in the product.
Have a “DO” best practice of your own? Share it in the comments below!
Raphael Santos
Hey Erik,
That’s an awesome article. Thanks for sharing!
Bill Souser
Interesting comments about using a WBS…many projects don’t.
Chris R
Erik,
Thanks for the article, but I have to point out that what you are showing as a WBS…really isn’t. MS Project can represent a WBS, but a WBS is deliverables-based, not task-based. Tasks belong in the project scope. I know Project ends up with durations for each entry, but in summary, the WBS is what you deliver, not the how or when you deliver it.
Erik
Hi Chris,
I get a number of WBS puritains every now and then in my discussions on the WBS as I promote its use in Project Professional. I would love to direct them to a source that backs up your statement of “this not being a WBS”.
Do you have any source that backs your story that I could use for this? PMBOK or anything alike?
Thanks for participating,
Erik van Hurck
The Project Corner Blog