This is the third post in my series on incorrect use of Microsoft Project stand alone version. I hope you can relate to the situations I described so far and I hope you have learned some nice insights on the workings of MS Project. This post will be about structuring your project to an agreeable level. This structure is called a Work Breakdown Structure or WBS for short.
Building a WBS can be a daunting task. There are a lot of things to consider, how many levels of detail will you incorporate in the schedule, how many tasks will be on one level, will we use the standard WBS number or do we need to conform to a financial system?
The rewards however are great! A structured WBS will give more insight in your project. It will be easier to report on progress. Not only you, but your team will be able to read and understand the schedule. So let’s explore this WBS concept some more.
A correct WBS looks like this in the Gantt diagram:
These are the most important items you use while building a Work Breakdown Structure in MS Project:
- The Project Summary Task
- The Outline codes
- Indenting a task
- Outdenting a task
1. Project Summary Task
The Project Summary Task can be found in 2010 and 2013 versions of the product in the “Gantt-chart tools Format” menu. The checkbox should be located on the far right in the screen together with the outline codes. In earlier versions it is hidden away in the “tools –> extra” menu, look for it at the bottem of one of the tabs.
This summary will give you a quick overview of your entire project! How sweet is that? All project costs, work and the total duration (including start and finish dates) are there.
2. Outline codes
The numbers that reprecent a tasks place in a schedule. I can’t provide a better definition of these codes then Microsoft does itself, so here is the link to their definition and how to create them in Microsoft Project.
3. Indenting and outdenting a task
This is key! indenting a task will create a new level in the WBS. The task above the selected task will become a summary task. Summary tasks (like the Project Summary Task) give you an overview of the underlying data. Costs, duration and work will be totalled in the summary.
Here is some advice about the size of tasks within your project. In a project that spans years, 80% of all tasks should not be shorter than 2 weeks. The other 20% are high maintenance tasks, to keep some extra security. Another advice, I believe from the same book: try to limit the number of tasks to 300 max. Projects that are bigger could well be programs, and then you are in a different ballgame.
I hope you liked the post, please let me know if there is anything missing about the WBS. Also feel free to share any interesting links in the comments below. Keep your eye’s open for the post about flaw number 4.
PS.: woohoo half way there!