Milestones and summary tasks RRS feed

  • General discussion

  • Hey everyone,

    A long time ago I'd read that linking summary tasks together was a good idea - if say you had a task of 'development' which was a summary, and had 10 items below it, linking this to say a testing task was a good idea - it meant that adding more development tasks would mean the testing task would move automatically without having to add more predecessors to the testing task each time.

    In theory, this sounds great. Since then I've had some Project training (sadly a while ago and I didn't get to use it much after that). The training, and several articles, suggest that summary tasks should never be used to link tasks - i.e. a summary task should never be a predecessor or successor. (There's many articles on Google, one such example: http://www.stakeholdermap.com/ms-project/link-summary-tasks-ms-project.html)

    In the example I have now I want to create a 'development completion' milestone. At the moment the development phase is quite a few tasks, I guess when I have all of them from the developers it'll be around 200 tasks. Does this mean my dev completion milestone needs to have 200 predecessors, all individually added, with every task then being added to the milestone predecessors column when added?

    This seems to me:

    1. Error prone - add a task, it would be easy to forget to add it to the completion milestone.

    2. Hard to check - with 200 tasks on a milestone it would be hard to see if you'd missed one.

    3. That I must be missing something! - What would someone do with a 5 year project with several thousand tasks?!

    My development schedule is something like this:


       Back end

          Area 1

             Task A, B, C, D...

       Front end

          Area 1        

            Task A, B, C, D...

    Obviously having multiple areas and tasks below them. Could I create milestones at the end of each Area which were linked to individual tasks using the predecessors column, and then could my dev completion milestone be linked to several of these milestones?

    Hopefully you can see my dilemma and someone can suggest a good course of action for me - my situation must be very common.

    Thanks in advance :)

    • Changed type Rob-R Wednesday, June 3, 2015 1:49 PM
    Wednesday, June 3, 2015 9:40 AM

All replies

  • Without knowing much about your overall project structure:

    : If you are going to track 200 tasks, then you are going to have 200 tasks to handle.  Maybe simplify and track less?

    : Since it's a best practice (and I would say a requirement) for all tasks to have successor tasks or milestones (if no successor then what' the point?), then "forgetting" to connect a task to a completion milestone is unforgivable and to do so is a "bug".

    : For a 5-year project, surely one would break it down to be simpler, perhaps by year or key milestones.  One would have to have a milestone plan to manage the project, regardless of how portrayed in the MS Project plan.  (Ideally the milestones used by the Project Team and Sponsors would be the same as in the MS Project plan, of course).

    : Yes, you could have completion milestones by "area", or even by "end" to collect completions within that grouping.  At first glance, that's what I would do.  But--does it actually make sense in your project to organise deliverables by Area and End?  Only you know; but if that does not match how the tasks will be actually be executed, then that may lead to unnecessary complexity. For example, maybe you will have someone be in charge of all the "Task A's", and someone else in charge of "Task B's" regardless of Area and End.  Just think about it.

    : When there are so many ways to organise a project I use a lot of Text Columns to define these other ways to tagging a task, then I use Grouping to show the status/project/plan in all these different ways. The freedom to allow this sort of flexible viewing of a project plan comes alive when one does not do any summary task linking (yet another reason not to that).

    --rms www.rmschneider.com

    • Edited by Rob Schneider Wednesday, June 3, 2015 11:56 AM spelling.
    Wednesday, June 3, 2015 11:55 AM
  • Thanks for your response Rob. I will have these tasks to track but on the whole this won't be that bad. The developers are using another system to record their tasks so I can simply see when tasks are done and mark them as complete. The only option to track less would be to have 'Area A Development' and sum the total of the dev tasks, but in doing that I'll have less information and still have to keep track of the tasks but just roll them up myself.

    What I'd setup before your response was this:

    *All tasks have a predecessor, in some cases this is just the requirements document for the area.

    *All areas have a milestone task 'completion', which uses the IDs of the tasks mentioned above.

    *An overall 'development completion' milestone was created which had the IDs of the above milestones as it's predecessor.

    Is there anything wrong with this logic? - I'm not using summary tasks for any form of linking, just 'chaining milestones' if you like. Assuming this isn't a MS Project no-no it makes perfect sense for the way the project is running in my eyes.

    This does mean one of my milestones at the moment has about 25 IDs as its predecessors but that's still manageable at the moment.

    Thanks for the note about text columns, I too use these a small amount for the reasons you state, it can be very useful.

    Many thanks for taking the time to read my post and for a comprehensive reply.


    Wednesday, June 3, 2015 12:33 PM
  • Hi Rob,

    It's not that Project will explode in your face when you link summary tasks. The thing to remember is, when you link summary task, to NEVER start dragging and dropping tasks from one summary task to another one - that may make your project react badly, i.e. stop calculating altogether on that file - the repair from there is then to unlink summary tasks!

    So feel free to link summary tasks -  but do not complain when you get into trouble after dragging and dropping!


    Wednesday, June 3, 2015 2:39 PM
  • I actually used to do it and find it to work okay, however, with all the reading I've done I sense it's not the best course of action.

    I guess what I'm now doing, and wondering if it's correct, is 'chaining milestones' - so in effect I'm using just straight tasks (not summary) to create milestones, and then I'm creating 'milestones of milestones' and so on...

    Logically this makes sense, but then so did linking summary tasks before I was informed this was bad practice!

    Wednesday, June 3, 2015 2:42 PM
  • 1. The best practice suggested will definitely put the planning of tasks in right path.  When ever I add a task, I start with predecessor, resource, work,.. and complete with successor. We build our plans cohesively so that any new task is never left as an orphan or with out a successor. 

    If a practice of putting predecessors or successors to only non summary tasks is followed, it would be easy to check if a particular non summary task is missing a successor.

    Using milestones to effectively box a set of tasks and drive the dates is a great way of doing things

    I have also noted issues/bugs when dependencies set at summary task level at multiple hierarchical levels have caused erroneous flows.

    Having said that...

    If a natural relation ship between activities is through summary task, then you should not shy away from it 

    For example, once you complete building walls, you would do flooring. There is no harm and technically there is nothing wrong with it. 

    For an advanced user, linking summary tasks helps in multiple ways. 

    The errors explained in article you pasted  are good examples, however they resulted in wrongful usage of concept and not wrong concept by itself. 

    Srikanth Bogadapati

    Please mark as answered if you think this answered your question

    • Edited by SB97 Thursday, June 4, 2015 3:00 PM
    Wednesday, June 3, 2015 7:18 PM
  • Interestingly I never consider successors. I guess if I displayed this column then it would make a lot more sense and if I followed this work flow the chances of 'missing' something would be very small. Thanks for the tip :)

    I think for now I'll stick to not using summary tasks except for 'presentation purposes'. I think that's safer.

    Thanks for the feedback and insight, most helpful.


    Thursday, June 4, 2015 10:50 AM
  • Not specifically to this question, but perhaps this will help: 10 Golden Rules - https://www.youtube.com/playlist?list=PL5hAt2Hk6sY5S4JVcS-So1p2P2R4yO2wf

    Mark M Webster

    Thursday, June 4, 2015 4:32 PM
  • To each his own, but I would definitely not recommend this:



    If you are not considering successors then you are not checking to see that every task has one. This should be checked and every task should have at least one FS0 successor. You need a closed network where every task is on a path from the start milestone to the finish milestone (and no predecessors or successors on the summaries).

    My recommendation: never link summaries, never assign resources, work or cost to summaries.

    Reasons: You want to find a critical path, you want to track progress, you want to be able to level, you don't want circular references... plus other reasons.

    Friday, June 5, 2015 6:45 AM
  • Thanks Trevor. I guess I wasn't considering successors but I was adding them as I was tying predecessors to milestones and milestones - adding the successors column in a plan I have at the moment shows it is correctly linked up. However, doing this via the successors route as opposed to making a massive list of 30 task IDs and copy/pasting from notepad into a milestone will make things much easier.

    Before making this post I never assigned anything to summaries - I quickly found out that lead to over allocation if one wasn't careful, and it didn't make sense - because you're linking someone to a container, not an actual task.

    I'll check out the videos in a moment too - thanks both Trevor and Mark for the links.

    Friday, June 5, 2015 8:07 AM