When I first started using Microsoft Project, I took it for granted that I should replicate the WBS in the task list and use that to structure my work packages. After working with Project a little while, I'm wondering if I should structure my work packages into phases instead (the project Program).

Right now, all my leaf tasks are the work packages. All summary tasks are elements from the WBS, arranged in the same hierarchy as the WBS.

Should I have the summary tasks be project phases instead? In this way, the work packages would be listed (more or less) chronologically instead of the deliverable based structure of the WBS.

In this setup I would use the WBS field to map the work package to the WBS maintained elsewhere. When sorting by the WBS field, MS Project shows the hierarchical relationship, so you could still view the WBS hierarchy in Project.

Does anyone have experience using this approach? Is this how MS Project is designed to be used?

  • Hello Marwan, you'd have more views (and therefore, more answers!) if you abstract 'MS Project' to a 'task tracking system'.
    – Tiago Cardoso
    Commented Mar 13, 2014 at 10:51
  • Thanks for the tip, but I did want to focus the question how to use this specific tool as opposed to how to use 'task tracking systems' in general. I don't know much about other systems, but I thought some would have built-in support for separate views for WBS, Program, Schedule.
    – Marwan
    Commented Mar 13, 2014 at 14:17

3 Answers 3


With regards to the level of detail on your project, I'd say you may be going one step further but overlooking one a basic one:

What are we trying to achieve with any task management system?

Most of the time, the reason one would use a task structure is to make workable more pieces manageable and traceable. As Cornelius Fichtner reminds on his PrepCast, we must eat an Elephant one bite at a time. Only you can know how much you can eat at once. So, if the granularity you're using is ok (regardless on what's based on) than your project is fine.

Now, Back to the original question, does it worth to change the approach from deliverable-oriented to cycle-oriented?

I believe it'll eventually depends on the nature of your project.

  • If you can close the deliverables for granted, I'd keep using your approach, deliverable-oriented.

  • If your project has all / most of the deliverables intertwined and will be tested and reviewed together, I'd say the cycle-oriented would be easier to manage.

The cycle-oriented might make easier to manage the project especially when CRs (that are likely to be cross-deliverables) start to arise.


  • The deliverables are in fact intertwined, which is why I was considering shifting to a cycle oriented approach. What are CRs?
    – Marwan
    Commented Mar 13, 2014 at 9:04
  • Change Requests, the nightmare for any organized plan :D
    – Tiago Cardoso
    Commented Mar 13, 2014 at 10:24

I tend to logically group deliverables that are related to project "phases". These could be the phases from PMBOK, but it is probably better to group them in what PRINCE2 terms "management stages". Examples of these include:

  • Project Planning. So things like stakeholder analysis, developing schedules, risk analysis, etc.
  • Solution Design. Includes requirements gathering and validation, not only for software/hardware but also for associated business processes.
  • Solution Development. So taking requirements that have been collected and validated and turning them into tools/methods. Also includes UAT and formal acceptance by end users
  • Implementation. Includes your planning to manage change outside of the project team, communications, training, etc

Doing this gives you the advantage of having logical points in the project where you can refresh your business case and verify that it makes sense to continue the project.


Manage your schedule using MSProject and manage your WBS elsewhere.
Since MSProject is for schedule management (in most cases) it's natural to split yor scope by phases (iterations, etc.) in your plan. The main benefit is that's easy to comprehend and control dependencies between work packages

  • Thanks for the straightforward answer. Any tips on keeping the MSProject schedule and external WBS synchronized?
    – Marwan
    Commented Mar 13, 2014 at 9:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.