pm-lotus by Howard Vaughan

Posts Tagged ‘Tracking’

Knowing the latest dates that we can start and finish tasks without impacting the overall project schedule is key to effective time management, especially for those projects where schedule is the least flexible component (see Flexibility Matrix).

Like the critical path itself however, Microsoft Project does not display this information by default. But we can easily set up the display options to reflect the late dates as in the example below:

Here’s how we configure this. First we display the critical path:

• From the menu, select View, Gantt Chart
• Then click the Gantt Chart Wizard button on the Formatting toolbar
• Select “Critical Path”, then Finish, Format It, Exit Wizard.

The critical path tasks are now visible in red. Next we set up the late schedule for the noncritical (blue) tasks:

• On the menu, select Format, Bar Styles
• Then click Insert Row to add a row just above the Critical Path display row (note that inserting a row at the top of the list may not work)
• Enter “Late Schedule” for the ‘Name’ and select your preferred bar styles for the ‘Appearance’ - (in the example above I used a navy horizontal line bounded by small triangles)
• Select “Normal, Noncritical” for ‘Show For … Tasks’
• Lastly ensure that you select ‘From’ “Late Start” and ‘To’ “Late Finish”
• Click “OK”

Now you should see the late schedule bars showing for the noncritical tasks indicating the latest each task can start and finish.

Useful Information

Showing the columns for Total Slack (the difference between the early and late dates) and Free Slack (how long a task can be delayed without delaying a sucessor task) as in the simple example above tells us the following:

• The critical path runs through tasks E, G, J
• The noncritical tasks have varying total slack
  • Tasks B, C, H, L have only 2 days, so are near critical and should be monitored closely for any slippage
  • Tasks A, K have 7 days
  • Task F can be delayed by up to 11 days before the project finish date is impacted
• Tasks B and C have zero free slack so any delay will immediately impact their successor tasks

Track the Slack

Knowing not only which tasks are critical and which are not, but also how much float or slack there is on each non-critical task, helps us prioritize work (according to slack value) and monitor trends in schedule variance (changes in slack week-to-week).

An important aspect of the project manager’s role is the appropriate balancing of trade-offs among the primary project constraints. In most cases this means determining priorities among schedule, scope and resources. The relative importance of these should be defined unambiguously by the project sponsor and then reflected by the PM in a matrix:

Forcing clarity on project constraints and priorities

In the example above, schedule is deemed to have the least flexibility, meaning that everything possible shall be done to meet the target completion date, even if scope has to be compromised in some way, or more preferably, by adding resources to expedite the schedule. It is important to state WHY a particular constraint is either least, moderately, or most flexible, according to the sponsor’s priorities, with guidance on the relative limits of flexibility (so no blank cheques).

This little tool is invaluable to the project manager during both planning (in ensuring the right focus in optimizing the project plan before baselining) and execution (in guiding both the tracking effort and corrective action in the event the project deviates from the plan).

While the relative priorities can be changed by management as desired, a simple rule must be followed to prevent insistence that everything be least flexible – only ONE check allowed per column and ONE check allowed per row.

When I first started in the project management services business, I was repeatedly led to believe that the construction industry was the beacon of leadership in project management maturity. My own experience over the years tended to question that wisdom and now the truth is out that this is indeed all nonsense. According to a recent survey by the Chartered Institute of Building (CIOB), which represents 42,000 members and sets standards for the management of the total building process, the construction industry has much to learn about project management.

The Shocking Truth

Not a towering force in project management

The survey results are based on data from 73 companies and over 2,000 projects. Its conclusions are available on the CIOB website – you can also watch an interesting video of the CIOB president Keith Pickavance presenting the results at the Project Management Asia Conference 2008. They make for a highly uncomplimentary denunciation of the state of project management practices in the industry- for example:

• less than 15% used a linked network to define the schedule
• more than 50% used only simple bar charts
  • (no chance of a critical path)
• more than 50% used paper (not computerized) records
• less than 15% kept logs of changes
  • (not much good in court)
• 95% did not report delays to progress because they:
  • hoped no-one would notice
  • hoped they could catch up
  • did not want to upset the client
  • thought they could blame someone else.

Its not a pretty picture. Little wonder then, that the industry is dogged by delays, compensation claims and disputes.

The Way Forward

Clearly there is a need for some serious project management skills development. In the words of Mr. Pickavance himself:

We have no standards, we have no training, we have no qualifications.

All of which should be manna from heaven for project management educators, particularly in those regions where construction investment is being pumped up to help resurrect limp economies. Assuming of course that the building firms are open to changing their ways.

Ambiguity is the enemy of project success. Its one of the first things I instruct new project managers on. I call it the First Law in project management.

Its not hard to find ambiguity in projects. Look closely at the objectives, the requirements, the scope definition and the schedule. Are they each as clear and as accurate as they can be? Most importantly, do we know what “done” really looks like? This is crucial. (Glen Alleman’s prolific and consistently excellent blog at Herding Cats has a host of outstanding posts on this – check it out). Each ambiguity is a potential source of conflict, rework and failure.

Clarity Checks

The antidote to ambiguity is clarity – here are a few items that must be on the ‘Clarity Checklist’:

• Are deliverables defined with clear boundaries?
  • Are there detailed and explicit descriptions of inclusions and exclusions?
• Are completion and acceptance criteria clearly stated for each deliverable?
  • Do we know what “done” looks like for each deliverable?
• Are tasks defined at an appropriate level of detail?
  • Are most tasks in the range of 4-40 hours of duration? (a useful guide for most projects)
• Are task outputs tangible?
  • Have the outputs been agreed upon by their owners and dependents?
• Is progress tracked at task level?
  • Is evidence of progress validated before being reported upward?

Leaving ambiguity unchecked simply increases project risk. The pursuit of clarity isn’t always popular because it makes people have to think ahead a little harder. But its necessary. So put on your flak jacket and go on a mission – seek out ambiguity and destroy it… before it does some damage.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

Custom fields in Microsoft Project offer a host of possibilities for tracking and managing schedules. I like to use the indicator functionality to help monitor and control progress. In the example below I’ve used the custom field “Number1″ to indicate task status based on total slack.

Here’s how to set this up-

• Select Tools, Customize, Fields
• Select the field “Number1″
• Click Rename to relabel field as “Schedule Indicator”, then OK

• Click on Custom Attributes, Formula
• Enter the formula:
  IIf([Baseline Finish]>100000,-1000,IIf([Actual Finish]<100000 And [Finish Variance]=0,-998,IIf([Actual Finish]<100000 And [Baseline Finish]>[Actual Finish],-998,IIf([Actual Finish]<100000 And [Actual Finish]>[Baseline Finish] And [Finish Variance]>0,-999,[Total Slack]/480))))
• Click OK

• Click on Values to Display, Graphical Indicators, and set up the images in the order below:
  White = -1,000 (will show tasks that are not baselined)
  Blue = -999 (tasks that finished late)
  Dark green = -998 (tasks that finished on time or early)
  Red <=  -5 (incomplete tasks that are late by 1 week or more)
  Yellow <= 0 (incomplete tasks that are up to 1 week late)
  Green >= 0 (incomplete tasks that are early or on time)
• Click OK, OK

Lastly, we set a Deadline on the Project Complete milestone to provoke negative slack values when behind schedule-

• Double click on the milestone name, then go to Task Information, Advanced, Deadline

That’s about it!