Posts Tagged ‘Scheduling’

PostHeaderIcon Program Management Essentials

The world is (slowly) moving toward a shared understanding of the term “program”. There are still widely varying interpretations of project vs program but the most common themes are that programs typically drive significant strategic change, involve the integration and coordination of multiple component projects (and sometimes non-project work too), and focus on outcomes rather than outputs.

Alignment and Integration

Where all these criteria are fulfilled, major problems arise when the program is treated simply as a large project, meaning that planning and oversight is overly tactical to the detriment of the more strategic activity necessary for program success (see Big Programs, Basic Flaws).

Seven Key Elements

Ensuring the program delivers what was intended requires special emphasis given to areas such as strategic alignment, stakeholder management, scope and schedule integration, and benefits planning.

The following major elements of program management help provide appropriate focus:

1 – Business Case

Programs should have a well-articulated justification for the investment, that centers on the estimated costs of implementation and ongoing operations against the anticipated benefits to be gained and offset by the associated risks.  The business case lays out the strategic context of the program and shapes its overall mission and vision. Once approved, the business case provides a point of reference throughout the program (updated as necessary) in order to ensure a continued business rationale for the initiative.

2 – Program Organization

This should comprise a single program manager with unambiguous reporting lines to an executive steering committee (program board) that adequately reflects major stakeholder interests, budgetary control and resourcing. Other advisory committees may be set up to review and guide specific aspects of the program but the board always has ultimate decision-making authority. The program manager should have ready access to an individual program sponsor to resolve issues and obtain guidance not requiring involvement of the other board members.

3 – Stakeholder Alignment

The sheer scale of a program will usually infer involvement of many parties with vested interests. Stakeholder analysis will help to identify individual concerns and parties needing the greatest attention, and subsequently define appropriate response strategies. It also assists in identifying risks associated with (real or perceived) negative outcomes. Properly managing relationships with key stakeholders requires detailed communication plans and, (sometimes forgotten), ensuring adequate time and effort is expended in acting on those plans.

4 – Benefits Realization Plan

Since programs focus on outcomes (vs. projects which focus on outputs), a core element of program setup is the development of a plan that (a) assigns metrics to identified benefits, (b) forecasts when and how those benefits will be realized and (c) maps program deliverables to the benefits which are in turn linked to program objectives. This helps ensure that assumptions in how each benefit will be realized are validated and that all required deliverables are clearly identified.

5 – Program Architecture

The program architecture identifies component projects and the major interfaces between them. A vital aspect of developing the architecture is scope integration, whereby the boundaries of each component are validated to ensure that program objectives can be fulfilled without gaps or overlapping effort among the constituent projects. A high-level program roadmap is an important tool in depicting anticipated sequencing of the projects, target dates for key interfaces, review/approval gates and other milestones, and successive stages of funding.

6 – Integrated Master Schedule

An effective integrated master schedule (IMS) consolidates all component project schedules and links them at the task level with specific, clearly defined interfaces with explicit completion criteria. Depending on the schedule criticality, the use of simulation tools and optimization techniques are often essential tools to properly manage schedule risk and greatly increase credibility of the plan and confidence.  The IMS re-validates the program roadmap and benefits plan and together with an interface tracking log will therefore provide the basis for much of the program manager’s performance monitoring focus during program execution.

7 – Tiered Governance

While project managers within the program will typically track progress against schedule, cost and technical performance, the program manager needs to ensure not only proper roll-up of this data (possibly via a program office) to control overall program progress but also to implement tracking of benefit metrics, as per the benefits realization plan. A well-designed program dashboard reflects both types of metric to provide the board with a holistic view of both the strategic and tactical performance aspects of the program.

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 Project Management Checklists

Much more than a Memory Jogger

Much more than a Memory Jogger

Among all the tools at our disposal for managing projects, programs and portfolios, checklists are perhaps the simplest and most productive means of building consistency in work practices. Checklists are useful in almost every field of human endeavor, and in particular where repeatability and systematic action drive performance. Yet they are still much under-used in the planning and managing of projects.

As a good friend of mine, Nick Gogerty, recently posted in Checklists, hedge funds and human behaviour, checklists provide for better outcomes – both individual and team. And the more collective experience that goes into the creation of a checklist, the more value it will have. Well thought-out checklists are indispensable wherever there is a need for control, risk reduction, rapid response or safety – as doctors, flight crew, investors and others the world over can testify, the checklist provides efficient guidance, increased confidence and focus under stress (see The Checklist Manifesto – How to Get things Right – a great-sounding read that Nick highly recommends).

Twelve Checks for Planning

Likewise for project managers – checklists can be used for all manner of things. Where training builds knowledge, checklists facilitate application.  Here is a high level twelve-point checklist for use during project planning:

  1. Have the needs and concerns of all key stakeholders been considered and resolved?
  2. Does the project have an overall approved mission statement defining the scope, schedule and resources/budget?
  3. Has the relative flexibility among scope, schedule, resources and budget been determined?
  4. Have all project deliverables been identified and described in detail with unambiguous completion criteria?
  5. Are roles and responsibilities defined and agreed upon for all project team members?
  6. Has an appropriately detailed work breakdown structure been created with input from key team members?
  7. Has a credible schedule with identifiable critical path and late schedule been developed from the WBS and optimized within the project constraints?
  8. Have milestones been included in the schedule to track major events, completed phases and/or deliverables and external dependencies?
  9. Have workload commitments been identified for each week of the project and agreed to by team members and their managers?
  10. Have response plans been developed for the most significant threats to project success?
  11. Has a change management process been defined and agreed to by all key stakeholders?
  12. Has the governance structure for the project been established with an agreed sponsorship role and expectations set for review frequency and format?

One of the features of checklists is that they can be designed to extend hierarchically, such that a sub-checklist could be developed to facilitate any or all of the checks above (e.g. a stakeholder analysis checklist or a risk management checklist). The PMI, training firms and PMOs would do well to promote checklists more strongly – project managers like to use checklists; not many want to read through an overweight methodology. And managers like checklists because they improve quality and instill consistency. For the converted, I’ll have more checklists in future posts.

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 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 The Flexibility Matrix

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

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.

PostHeaderIcon Credibility requires Detail (the 2nd Law)

Most projects are underplanned. They’re already late before they start. For a host of reasons – the usual suspects include a lack of project management discipline, inadequate tools and training, unclear objectives, top-down influence, overworked and under pressure team members – projects get planned with insufficient detail.

The reality is that detail is the basis for accuracy in all projects. Plans that lack appropriate detail can’t be believed. This is what I call the Second Law of project management.

The consequence of a lack of detail is a project suicide spiral:

Understate what’s needed… Misunderstand what ‘done’ looks like… Miss stuff out… Underestimate time and effort requirements to do the work… Overcommit resources to unrealistic schedules…
Present bad news to customer.

Breakdown Checks

Without a credible plan, a project manager lacks credibility with the team and stakeholders. Only when we get to the detail is the full extent of work revealed, which means developing a great Work Breakdown Structure. Here are a few WBS must-do’s:

  • Ensure tasks are small enough so that-
    • Estimates of effort and duration are as accurate and credible as possible
    • Task durations are typically no greater than the time between progress updates
  • Define explicitly what ‘done’ means-
    • Especially for any task that is unfamiliar, complex or difficult to break down
  • Assign a single owner to each task-
    • Have them verify that the expected workflow minimizes likelihood of any missing tasks
  • Use a checklist of often forgotten tasks-
    • e.g. meetings, defect resolutions, reviews and approval cycles.

They say the devil is in the details – and just looking for a chance to cause trouble. Good process and a little extra planning time will build protection.

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

PostHeaderIcon Construction Industry needs Project Management Education

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

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:

– more than 50% of projects reported on managed with simple bar charts and no CPM
– less than 15% used a linked network to define the schedule
– only 10% had a QA system in place to quality control the network
  • 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.

PostHeaderIcon Ambiguity kills Projects (the 1st Law)

Not so clear

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’:

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)

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!