7 Incorrect Ways to Use Microsoft Project: Lack of Structure

This is the third article of this series highlighting common incorrect uses of Microsoft Project. The images in these posts are built using the Microsoft Project 2013 Pro edition, but this series can be useful for all versions of the product.

Flaw #1: Date-Related Planning

Flaw #2: Capacity as Activity 

Flaw #3: Lack of Structure (Work Breakdown Structure)

Building a Work Breakdown Structure (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 you more insight in your project. It will be easier to report on progress. Plus, not only you, but your entire 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:

  1. The Project Summary Task
  2. The Outline Codes
  3. Indenting and 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 bottom 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

Outline codes are the numbers that represent a task’s place in a schedule. I can’t provide a better definition of these codes then Microsoft does itself, so here is 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 totaled in the summary.

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 eyes open for my next flaw: To much detail in the schedule.


This article was originally published on Erik van Hurck’s website, The Project Corner. You can visit his website for more helpful tips.

Avatar photo
Written by Erik van Hurck

Erik van Hurck is a Senior PPM consultant for Projectum, a western European Microsoft Partner with offices in Denmark and The Netherlands. On top of that Erik is a Microsoft MVP. As such, Erik assists enterprise customers to adopt the new Power Platform cloud solutions for Project and Portfolio Management. Erik has a personal blog (www.theprojectcornerblog.com) and is also a writer for the Microsoft Project User Group (MPUG.com).

Share This Post
  1. Hi Erik, I think perhaps someone mixed up the images with your posting – the image we have here is of a dependency network, not a WBS!

  2. The development and management of the Work Breakdown Structure is a function of porject scope managment, while task management is a function of time management. And although the WBS forms the foundation of a schedule WBS elements are not tasks. Tasks or activities as they called in the context of MS Project imply work and action. The WBS of a project represents the what, the deliverables and sub-units of those deliverables. Liliana Buchtik in her book “Secrets to Mastering the WBS in Real-World Projects says on page 24, “The WBS doesn’t represent tasks; if focuses on deliverables and outcomes. Listing tasks is something realted to project time management, not related to project scope management. The graphic expression of the WBS is more analogous to an organization and not at all to dependancy network. Practioners need to get this right and we msut disabuse our customers from conflating one with the other. It is immensely frustrating that we should this kind of error on what should be an otherwise fairly simple and straight forward discussion of PM fundamentals.

  3. 1. I would refer to the graphic as neither a WBS or a network diagram, but a logic-linked Gantt chart.
    2. I think some of you missed Eric’s statement before the graphic: “A correct WBS looks like this in the Gantt diagram.” I have some issues with this statement/approach too, but the graphic does make more sense in that context.
    3. Having worked with thousands of novice project managers on the development of WBS, I find the distinction between scope and time management in the development of the WBS/schedule is a little bit like talking about split infinitives to people who just learning to speak English. Personally I would take issue with the statement, but even if you’re theoretically correct, it’s not even a meaningful discussion to have with a novice. In fact, unless you are an expert, it just adds to the sense of confusion and increases the likelihood of the WBS turning into a product breakdown or some other non-WBS structure.
    4. The WBS should be in Project as a correctly structured indented list. WBS Schedule Pro is an excellent tool for taking the pre-existing data and producing a graphical representation of the data. Once the dependencies are identified in Project then the related tool PERT Chart Expert can be used to produce a better looking network diagram than Project produces. (Both tools also allow you to edit to the Project data.)
    5. The premise of the article is correct, in that the lack of a correctly structured WBS in Project is almost a given for every Project file that ever comes my way for me to provide comments on.

  4. 6. Yes, separating out the WBS development (scope) from the network diagram development / dependency identification (sequencing) is vital.

  5. I think everyone’s already hammered the no logic in a WBS rule. I have a question for the group at large, though.

    I usually strive to have all of my deliverables at the same level (WBS/outline level). Sometimes (ok, often), I end up creating artificial levels in order to force my work products to the target level.

    Am I over complicating things, or do you agree that deliverables/work products should all be at the same level?

    Thanks for your input.

  6. When is it practical not to have a predecessor task. To me the first task in the project obviously does not have a predecessor task. But what about as you get further down into the WBS?

  7. Hi Jack,
    Thanks for the respons. In my opinion only the first project doesn’t have a predessesor… Unless there are more then one task starting at the beginning of a project.

    If you have an example of an exception I would love to hear it.

    Kind regards,
    Erik van Hurck

Leave a Reply