Posts Tagged ‘Microsoft Project’

PostHeaderIcon Setting Baselines in Microsoft Project

Baselining a project plan is essential to facilitate accurate tracking of project progress. Project schedules that lack baselines make progress reporting a combination of guesswork and blind faith, yet it is surprising how often this occurs.

Setting a baseline is typically the final act of planning. It should only be done once the sponsor has approved the project plan for implementation, thereby signifying the transition of the project from planning to execution. All documents that reflect the approved project plan should be designated as baseline records, but most importantly it is the detailed schedule that needs baselining to facilitate accurate tracking of progress.

Two Pre-Steps

Before actually setting the baseline, there are two important pre-steps:

  1. Ensure the schedule has been quality checked
    This includes validating the WBS (see A Checklist for Work Breakdown Structures), and verifying the integrity of the duration estimates, dependencies, constraints and resource assignments
  2. Obtain approval of the schedule from the project Sponsor
    This should include a review of all major incremental milestone dates and the level of schedule risk associated with each – not just the final deadline.

Quick and Simple

Saving a baseline in Microsoft Project is a quick and simple thing to do and here’s how:

  • Select either Project, Set Baseline… (Project 2010), or
    Tools, Tracking, Save Baseline… (Project 2003/7)
  • Click to select Baseline
    (rather than Interim plan which is normally used for saving draft versions of plans)
  • Select Entire Project
    Microsoft Project now copies all current schedule information such as Start/Finish dates, estimates and costs into Baseline fields so they can be used as comparisons with Actual information once the project gets underway (see image below).
  • Select View, Tracking Gantt to see the baseline schedule displayed together with the current schedule.

An updated project schedule showing current progress on each task (Start/Finish columns, blue/red bars) compared with the original baseline (Baseline Start/Baseline Finish columns, light grey horizontal bars). Also shown is the total slack on each task (positive slack/blue horizontal lines displaying the late schedule, negative slack/red horizontal lines).

Re-Baselining

Microsoft Project provides for re-baselining via the “Baseline 1”, “Baseline 2” etc. dropdown selections in the Save Baseline dialog. The options for displaying the Gantt bars for any baseline can be set up in Format, Bar Styles (click Insert Row to assign bar and color options for any re-baseline, e.g. for Baseline 1 select “From” as Baseline1 Start and “To” as Baseline1 Finish).

However, once set, the baseline schedule should only be altered (re-baselined) under extreme circumstances (such as a Sponsor-approved major scope change), that render the original baseline schedule obsolete and no longer a meaningful target to aim for and report progress against. Continually re-baselining is not project management – it’s playing politics.

PostHeaderIcon Displaying the Late Schedule in MS Project

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:

Late Schedule Example

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).

PostHeaderIcon Completion Criteria Ensure Done Means Done

How do you know for sure when something is declared “Done”, that it really is? By defining completion criteria. These little nuggets are one of the single most important – yet frequently overlooked – aspects of project planning.

Completion criteria root out ambiguity (see The First Law). They align stakeholders, team members and the customer on the conditions for acceptance and validation of the project outputs. And they improve estimating quality by enhancing understanding of the desired work result.

Its a Binary Thing – “done” or “not done”

Completion criteria should be defined first for the project deliverables, which in doing so will actually help identify tasks for the WBS, and second for (ideally) each task in the WBS itself. Well-written criteria:

  • Are defined by the deliverable or task owner
  • Clearly state the characteristics and attributes of the output  – “what done looks like”
  • May include the measurement and validation requirement – e.g. “who reviews what”
  • Are defined in a binary way (i.e. totally unambiguous).

Can we really do this for every task? You decide – it’s a tradeoff between increased planning effort vs. increased risk. But consider that while this may initially seem onerous, the reality is that it does not take much more effort to write a statement or a couple of bullets specifying what ‘complete’ means (for example in the Notes field in Microsoft Project). Put in the context of the project overall, it’s a seriously small price to pay for dramatically increased clarity and reduced risk of misunderstandings.

PostHeaderIcon Making Risk Management Real

Of all the processes within project management, it would seem that risk management is the one that most often turns into a paper exercise. Lots of projects have lists of identified risks, some have plans to manage those risks but only a few properly integrate risk responses into the overall project plan.

A Small but Crucial Step

Creating risk logs and defining response strategies is a ‘non-productive use of valuable time’ if performed merely to satisfy management, increase comfort levels or just conform to company policy. Those documents will gather plenty of dust. What’s needed is for that information to become an essential component of the detailed schedule. This is a small but crucial step – and often missed.

Here’s how to do it-

  1. Once the project risks are identified, define clear mitigation strategies – i.e. specific actions to proactively (a) reduce probability or (b) minimize or alter the impact of the risk occurrence.
  2. These actions can then easily be defined as “tasks” in a verb/noun format – which means they can, and should, be added to the project Work Breakdown Structure (WBS).

In the example above, a section for Risk Management has been added to the end of the WBS task list in the Microsoft Project plan. Each of the tasks within that section is an explicit risk response activity. Each task will therefore be assigned an owner, linked into the schedule with appropriate duration and resource estimates, and then executed and tracked in just the same way as any other task in the schedule.

Now, we have made risk management real. Its an integral component of the execution plan – not a paper exercise. Remember – if its not in the WBS, its not in the project.

PostHeaderIcon Using Indicators to Track Schedules in MS Project

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.

ColorIndic2

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!

PostHeaderIcon Creating Hammock Tasks in MS Project

A hammock task can be defined as either a summary task that aggregates a related set of activities, or an actual ongoing activity whose start and finish is driven by other tasks or milestones that may or may not be related. In the first case, summary tasks are easily created using the outline feature in Project of course but the second case can present more of a challenge.

In the simple example below, two non-summary hammock tasks are shown.

Hammock3

Both hammocks reflect ongoing activity from the start to the finish of the project. To create Hammock A:

  • Click in the Start cell for the project “Start” milestone and choose the Copy command
  • Click the Start cell for “Hammock A” and choose Edit, Paste Special, Paste Link, and click OK
  • Click in the Finish cell for the project “Finish” milestone and choose Copy
  • Click in the Finish cell for “Hammock A” and paste as a link again

A problem with hammocks is that they may show up as critical items (as here with Hammock A) whereas in reality they do not actually drive the project schedule. Hammock B shows how we can avoid this by linking the finish date to a ‘dummy’ milestone “Finish -1” that we set to finish just before the project finish (predecessor is Finish milestone SF-1).

Using either approach above will allow the hammock to ‘stretch’ or ‘shrink’ as the durations of the other tasks change, during plan updates for example. If necessary, a manual click on the F9 key will force a correct recalculation of the hammock’s duration.