We receive a number of common questions during our training/consulting sessions and also come across similar questions while participating in online groups and forums. Trevor consistently contributes the below groups and forums which you can quickly view:
Some of the questions are below and Perfect Project Planning’s Trevor attempts very short answers:
Should I simply insert a column into the entry table to add an entry or is there a better, more structured way to do this?
I know that it is common practice to simply insert a column here and there in the entry table as required, and I even do it myself sometimes (temporarily only) and I know that others advise it from time to time (“insert this column or that column…”) but it is sloppy housekeeping and if the entry table is too messed up with the extra columns shown and some hidden, it just gets a bit messy, and since some reports reference the entry table it ruins the reports too. The column you want to see is usually in an appropriate table somewhere.
So, instead, switch to the cost table or the work table or the tracking table or the schedule table, whichever has the columns you want, and it will be in context with related columns to.
Why is it so important to have a clear project start milestone and a project finish milestone?
It may seem to be a small thing and it may make no difference in some cases, but having a project start milestone as the only task which does not have a predecessor, and a project finish milestone as the only task which does not have a successor, means that you can always ensure that every task has a predecessor and a successor. Any other task, no matter how simple you think it is, should have predecessors and if nothing else fits the bill then the project start milestone is that predecessor. If a task seems to have no other successor, then the project finish milestone must be that successor. This ensures that every task is on a continuous path from the start milestone to the finish milestone. It ensures a “closed network”, and it gives the best chance of identifying a clear critical path.
What are the aspects of any task?
Microsoft PROJECT (MSP) knows about three aspects of any Task:
- Duration (measured in Working Days)
- Cost (measured in Dollars)
- Work (measured in Hours)
Most of the fields needed for Tracking, the important ones, are in the Tracking Table (View, Table, Tracking).
And what are the numbers associated with the aspects of a task?
There are four important numbers associated with these three aspects of any Task:
a. Total Duration
b. Actual Duration
c. Remaining Duration
d. % Complete = Actual/Total
b. Actual Cost
c. Remaining Cost
d. % Cost Complete = Actual/Total
a. Total Work
b. Actual Work
c. Remaining Work
d. % Work Complete = Actual/Total
There are built-in fields for all of these, except % Cost Complete, and it is easy to make one for this by using a spare Text field, but it is not really needed.
Only any two of these are independent, since Actual + Remaining = Total.
What is % Work Complete and how do I implement it correctly?
Be especially careful about using % Complete, which is about Duration only, to represent how much of the Task has been done. Simple rules:
- MSP does not know (directly) about the progress of the Task itself.
- Only the person who looks at the Task can know how much of it is done, how much remains and how long that will take, ie what the Remaining Duration is.
- Only the person who looks at the Task can make a decision about the estimate of the Remaining Duration.
The Remaining Duration is the really important number because this is what has an effect on the Successor Tasks and the Project Finish Date.
Estimating the Remaining Duration when a Task is partly complete is a second chance to get the estimate right after an observation of how the Task is going.
How do I classify a Task?
A Task is usually about doing something which is objectively measurable, like laying the bricks or pouring concrete, and this gives rise to 4 similar values associated with the Task itself:
a. Total Task
b. Actual Task
c. Remaining Task
d. % Task Complete = Actual/Total
A Task can be something relatively easy to measure, such as “Lay 10000 bricks”, or less tangible than laying bricks, but no less manageable, such as “Write A Report” or “Draw a Drawing” or “Approve an Application”.
This is where the human judgement and estimating come in, in judging the progress and the production rate and deciding whether the original duration estimate was good or bad, by how much, and whether a re-estimate, and an adjustment to the Remaining Duration, is required.
Can I measure/monitor a task by %
A percent measurement of anything must always have a numerator and a denominator, and you should be clear about what they are in every case. Simply, progress monitoring for each task must be based on something (about that Task) which is quantitatively measurable.
Sometimes (a common practice) percentages are presented which do not have a numerator and denominator and are just “gut feel estimates”. Of course, these are not measuring anything objectively or quantitatively, so they are meaningless and useless. Everyone knows about tasks which are reported early as “90% Complete” and then stay there.
How do I ensure that tracking is accurate?
With so much data available, and numerous calculations being done by MSP in the background, it is essential to have a standard, consistent, reliable, repeatable procedure for setting up MSP so that you can see what you are doing when logging progress and updating the project plan.
This procedure checklist is intended, primarily, to ensure that before you start Tracking and updating that you can see what you are doing.
You may wish to develop your own procedure, but make sure you can see what you are doing:
- Save a Baseline (Tools, Tracking, Save Baseline)
- Set a Status Date (Project, Project Information, Status Date)
- Show the Tracking Gantt View (View, Tracking Gantt)
- Show the Tracking Table (View, Table, Tracking)
- Show the Tracking Toolbar (View, Toolbar, Tracking)
- Format Gridlines to show the Status Date, Current Date, Start Date etc (Format, Gridlines)
What’s the easiest way to make sure I can get the data I need when I need it?
Record keeping is the key to having the necessary, accurate, data available when you need it. Work out exactly what records are needed and ensure that they are kept, and make sure they are available. Projects that do not maintain sufficient or accurate records can in turn make meaningful tracking impossible.
When logging and monitoring progress, start with getting the answers to simple questions which are based on objective records and the facts:
- When did the Task Actually Start (if it has started)?
- What has been the Actual Duration?
- When did the Task Actually Finish (if it is finished)?
What is the difference between Hard and Soft predecessor links?
“Hard” predecessors are those which are strictly determined and unavoidable. In the construction industry they are usually a result of the absolute necessity of carrying out one task before another can start, and they are usually the result of the existence of gravity. For example, in a building project you can’t build the roof until you have finished building the walls (usually).
“Soft” predecessors are those which are imposed on the plan by the planner for some reason other than absolute unavoidable necessity. Methods of project modelling are the subject of constant debate.
It is a widely held opinion that predecessors can be used to resolve resource over-allocation. I can see the point of view, and it seems to be widely shared, but I generally take a stricter approach.
Problems can sometimes arise where two tasks, which are not “hard” predecessor/successor, appear to be scheduled to start at the same time, when it is not logically possible for this to be the case. Usually the two tasks are scheduled to be completed by the same person.
As a matter of best practice, I would strongly discourage linking tasks which are “discretionary” or “soft” predecessors, which are just based on preferences for a particular sequence of task execution.
I would strongly encourage reserving predecessor/successor links for “hard” links only.
I also strongly recommend the use of FS0 predecessor links only, and I discourage the use of other kinds of predecessors (FF, SS, SF) and lag (especially negative lag). On the few occasions where perhaps a FF predecessor link (or SS or SF) is realistic, I use them very sparingly, and only after all of the FS predecessors have been identified.
One of the main reasons for this strongly recommended position is that we need to obtain an answer to the question, “how fast can this project be done if resource limitations are not a consideration?”
To do this we need to compress the project as much as possible, so that the only thing preventing a task from being scheduled to start on day 1 is a chain of predecessors going all the way back to the start milestone.
In all but a few special cases (with negative lag, for example), linking tasks makes a chain of linked tasks longer, it consumes float, and if they are on the critical path they make the project appear to finish later.