none
Are spaces between summary items an issue? RRS feed

  • Question

  • Hi

    In previous versions of MS Project having blank lines (spaces) between tasks impacted how project calculated. 

    I often see people creating schedules with GAPs.

    What is the best practice now a days?

    For example...the image below yellow rows.  

    a) Does this impact critical path calculations

    b) I am curious how this impacts project's functions.

    Monday, June 17, 2019 12:52 PM

All replies

  • Hi again Dora,

    Once more, a couple of versions ago, having blank lines could break the project file, so it was advice not to insert blank lines in your project. Now I do believe that this is not an issue anymore more, except maybe if you have some VBA macro parcing your tasks and bugging when the line is blank.

    That being said, to be precautious, I do advice to remove blank lines anyway.


    Hope this helps,


    Guillaume Rouyre, MBA, MVP, P-Seller

    Monday, June 17, 2019 2:48 PM
    Moderator
  • Dora,

    Project doesn’t have a problem with truly empty rows.  They have no practical impact on schedule calculations or any other functions.  Such gaps are typically used to visually emphasize the separation between adjacent portions of the project scope, particularly within project teams of limited experience.  The introduction of a row number/ID without a corresponding task can introduce confusion into subsequent schedule review/analysis/update activities (sometimes bugging poorly-written vba code), so they are generally more trouble than they are worth (IMO).

    The two highlighted rows in your example are NOT truly empty rows.  The burning man indicates that resources have been loaded to blank-named, but not empty, tasks.  Like a number of other tasks in your example, they exemplify the all-too-common practice of assigning the same name (in this case a blank) to multiple tasks in a project.  Such duplicate names introduce the opportunity for human error during schedule development while severely degrading the potential value of alternate views and analyses during project execution.

    Good luck, tom

    Monday, June 17, 2019 2:52 PM
  • Hello Tom

    I appreciate your reply.

    1) I just whipped up the example and did not add resources.  Not sure whey the "burning man" appears.

    2) I found this statement very confusing since you stated "Project doesn’t have a problem with truly empty rows.":  "The introduction of a row number/ID without a corresponding task can introduce confusion into subsequent schedule review/analysis/update activities (sometimes bugging poorly-written vba code), so they are generally more trouble than they are worth (IMO)."  Please clarify.

    Monday, June 17, 2019 3:28 PM
  • Dora,

    1. OK.  Just to clarify, there may be 2 kinds of “Gap” rows in a schedule table:
      1. A null task, i.e. a truly empty row.  This is what you get when you skip a row during task entry in the Entry Table of the default Gantt View, or when you insert a row into the table using the Insert key.  This row possesses an ID value and a Unique ID value, but it is NOT a task.  In vba parlance, ActiveProject.Tasks(ThisEmptyID) is Nothing. 
      2. A blank task, i.e. a task that has been created with a blank name.  This is what you get when you insert a null task and then (intentionally or not) tell Project to modify it.  The resulting row/task possesses an ID, a Unique ID, and a Blank Name; Project populates all other task fields with initial/default values.  In your example, IDs 5 and 9 (and 14) appear to be of this type.  Since you don’t remember doing it, you may have some oddly-written vba code that is making the conversion in the background.  I’d guess these are typically a mistake; can’t remember encountering them in a real project.  Their presence would break any number of rules related to schedule logic, scope, and cost control.
    2. Confining our remarks to the first type above.
      1. The empty space created by null tasks (their only recognized value) goes away as soon as a task filter or group-by specification is applied.  (They will be hidden by any and all task filters and groups.)
      2. The vast majority of shared views in an actively managed project schedule will be filtered and/or grouped.  The primary consequence of the null tasks in such views are simple gaps in the task numbers without corresponding gaps in the visual space.  That just invites questions.  E.g “Why do I see Tasks 4 and 6?  What happened to 5?”
      3. It’s far simpler to create visual space in views by modifying specific row heights in the foreground.
    Monday, June 17, 2019 7:39 PM