How to group tasks in MS project



  • What’s the best way to group tasks? I’ve inherited a plan that details work done to specific parts of an assembly. So there is design work, build etc grouped per sub assembly but testing and documentation is split out. So I look at the plan and documentation is (as an example) listed last. Logically in my head I’d be used to this then being one of the last tasks but in fact it could be done earlier. I feel I wants to move the documentation for each sub assembly to the sub assembly section it relates to. What are peoples view on the best way? Hope this makes sense!



  • It seems you are asking what the best philosophy on how one should go about organizing tasks in the base structure of an MS Project schedule (as in, the way tasks are naturally organized when no custom sorting, groups, or filters are applied to the project).

    There aren't necessarily any hard rules for this. What's most important is that tasks are organized in such a way that the schedule is easy to follow, makes sense to the reader, and clearly demonstrates the tasks planned meet the needs and requirements of the Statement of Work. Speaking generically, here's what I like:

    • Milestones at the top
    • Contract Kickoff Tasks
    • Requirements Analysis Tasks
    • Design Tasks
    • Procurement Tasks (if necessary)
    • Testing Tasks
    • Manufacturing/Production Tasks
    • Contract Closeout Work Tasks
    • Level of Effort tasks at the bottom

    Within each of those group, I like to break it down further by Program Phase (if applicable), and then by engineering function. So for example:

    • Design Tasks
      • Preliminary Design Tasks
        • Sub Assembly 1
          • Mechanical Engineering Sub Assembly 1 Preliminary Design Tasks
          • Systems Engineering Sub Assembly 1 Preliminary Design Tasks
          • Software Engineering Sub Assembly 1 Preliminary Design Tasks
          • etc.
        • Sub Assembly 2
          • Mechanical Engineering Sub Assembly 2 Preliminary Design Tasks
          • Systems Engineering Sub Assembly 2 Preliminary Design Tasks
          • Software Engineering Sub Assembly 2 Preliminary Design Tasks
          • etc.
      • Critical Design Work
        • Sub Assembly 1
          • Mechanical Engineering Sub Assembly 1 Critical Design Tasks
          • Systems Engineering Sub Assembly 1 Critical Design Tasks
          • Software Engineering Sub Assembly 1 Critical Design Tasks
          • etc.
        • Sub Assembly 2
          • Mechanical Engineering Sub Assembly 2 Critical Design Tasks
          • Systems Engineering Sub Assembly 2 Critical Design Tasks
          • Software Engineering Sub Assembly 2 Critical Design Tasks
          • etc.

    Like I said, it doesn't have to be this way, but I've found this structure to work well for many projects. I like the chronological flow of the tasks as I view it, going from the start of the contract to the end. Specifically for your case, yes I would move the documentation tasks under the design or testing section for each of your sub assemblies.

    It's important to know that regardless of how you organize the base structure of your schedule, Microsoft Project has a lot of built in features that will allow you to sort, group, or filter on data in any of the task fields to change the view of the schedule to however you'd like to see it. With that said, you still want to make sure the organization of your base structure makes sense.

    You can read more about this topic starting on page 28 of the https://www.ndia.org/-/media/sites/ndia/meetings-and-events/divisions/ipmd/links-and-reference/paseg_v4-final2.ashx . My personal favorite reference document for scheduling.


Log in to reply
 


Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2