A Guideline for Estimating a Programme

By Bob McGannon, PMP, GWCPM

Programme level resource forecasting is a considerably complicated exercise, as a number of variables must be considered. There exists a base set of data that must be compiled, plus other items that are often underestimated or overlooked when creating forecasts for resource usage across a programe.. What follows is a list of ‘base data’ that needs to be compiled to facilitate forecasting and then some additional information that can be helpful when compiling programme estimates. It takes effort, but accurate programme estimates are achievable and extremely valuable.

Start with a Good Base of Data

A key to accurate programme estimation is having a good pool of data from which to derive estimates. These data items include:

  • History from similar programmes, organisational records, and other resources such as www.gantthead.com (for IT programmes) can be helpful here
  • Early collection of ACTUAL HEADS DOWN hours to accomplish tasks – NOT duration (see below for rationale for using heads down hours)
  • Complexity factors for each project within the programme. Complexity factors are numerous, including:
    • Degree of integration needed/integration points
    • Vendors, number of and degree of interaction directly between vendors
    • Geographic locations
    • Regulatory or environmental considerations
    • Size
    • New technology
    • Available technical skill
    • Available managerial skill
    • External factors such as policy making, media visibility
  • Dependencies on business/governmental or other ‘external’ entities as they can add duration and elongate completion times, skewing estimates
  • Risk – this needs to be factored into programme plans and associated estimates
  • Percentage of an eight hour day that all personnel will be dedicated to accomplishing programme related tasks (ie: heads down time). The guidelines for this need to be generated at a programme level. Rarely do personnel get to work on programme/project tasks for an entire eight hour day. Add in environmental factors and the hours per day can reduce considerably. (Example: Oil cleanup crews in the Gulf of Mexico – due to heat and humidity – have to take certain breaks each hour, significantly reducing their ‘active workday’ hours.) Groupings of task types and resource types need to be defined at a programme level to facilitate this ‘hours expected per workday’ guide. As a solution goes into production this is a considerable factor. This percentage – in hours per day – needs to be established and actuals tracked for each resource type. Programme schedules need to be adjusted, or personnel workloads need to be adjusted on an ongoing basis to maintain schedule and estimate integrity.  The range for a typical ‘office worker’ is 6-7 hours per day for fulltime team members dedicated to your programme.  Hours needs to be adjusted accordingly when team members are not full time and/or they are working on multiple projects and initiatives.  Please keep in mind if you build a plan based on 6.5 hours per day per person and  someone works 8 hours on a given day on your programme, they should be AHEAD of schedule.  If they are not – the programme will be over budget very quickly.

Carefully Calculate Integration Estimates

There are a number of other programme related items that are often estimated poorly and should be conservatively estimated as part of the programme estimation. Programmes often include significant integration, and integration activity is notorious for being under-estimated.  As a result significant cost and time must be factored in for integration, including:

  • Integration between information tool changes and the business processes they are intended to support
  • Integration between applications, between applications and new infrastructure, and between applications and infrastructure changes. These can be significant, and inherently risky. Distinct and independent projects should be included within the programme to a) examine, b) plan, c) test and d) execute these integrations separate from the projects making the application or infrastructure changes themselves to ensure management and overall business risk containment is in force.
  • Training and post installation support for users that have to absorb significant changes in relatively short periods of time. Programme managers often miss the need to integrate their solutions into the everyday work life of the users of their programme deliverables.
  • Business Change Management needs to be planned for and budgeted during the early stages of the programme to ensure an effective change management transition.

Often Overlooked Items

In addition to the data above, some factors are often overlooked while attempting to generate good programme level estimates. These are often overlooked because general and unsubstantiated assumptions are applied and not validated. These include:

  • Given many programmes include the use of operational personnel, discrete and readily applicable workload prioritisation standards need to be derived and communicated to all programme staff – and programme estimates created accordingly. For example, a discrete set of ‘workload prioritisation standards’ may look like this:
    1. Severity 1 operational issues need to be addressed
    2. Programme tasks are to be accomplished
    3. Departmental support as determined by the department manager, given no work is present in category 1 or 2 above
  • With the above distinctly defined workload prioritisations, personnel can clearly address programme work with a minimum impact from operational issues, and schedule/estimation integrity can be maintained.
  • Cross project dependencies, within the programme(s) need to be defined in at least THREE ways. (Maybe even more based on the nature of the programme.) These dependencies are:
    • Logical product related predecessors/successors
    • Critical skill availability – in a market where skills are at a premium, it is easy to blow out estimates and schedules by not performing resource constrained scheduling across a programme. Optimisation of critical skill usage is a major programme management factor
    • Risk carry over – what risks come to fruition on one project in the programme portfolio may cause other projects to make adjustments. For example, if time is allocated in contingency to accommodate the unexpected, and one project needs to utilise that contingency time, other projects in the programme portfolio may need to be adjusted to take less risky approaches, so as not to overrun the schedule. Many other risk relationships between projects should also be considered, especially in technical areas. Quite often, technical changes with one project deliverable can have an effect on the deliverables expected from other projects. Estimate changes need to be considered along with these technical changes.

The items above constitute a substantial element of work and strong governance based decision making. However, they are absolutely necessary to produce and maintain programme level estimates with integrity. They represent a ‘good start’, as published estimates need to be adjusted and nurtured with care to ensure they are meaningful.

Making Estimates Meaningful

The estimate process is not a single event, it should evolve over time. In a programme environment this is especially true, given that projects can be initiated, and come to conclusion during the life of the programme. Considering also that programmes themselves cause business change; the availability of resources and time to dedicate to the programme can change drastically. Estimates need to be refreshed regularly to accommodate these changes.

Estimates that are produced by the programme team should detail not just the costs and the time, but a significant set of detail about the scope and the assumptions being made about the percentage of time personnel will be spending on programme tasks. As the programme proceeds, the percentage of time actually being spent on programme tasks needs to be tracked. This tracking is not just in hours, but also as a percentage of overall work hours spent by project personnel. If the projected number of hours planned for programme tasks is being met, yet it is due to significant amounts of overtime being spent by programme personnel, the project is at risk. What the actual percentage of programme versus operational work should be noted, and adjustments made to ensure workloads and expectations are reasonable over the extended time the programme will be in place.

Good programme estimates are possible, however the programme management team needs to dedicate considerable time in the derivation and ‘care and feeding’ of the estimation process throughout the programme lifecycle to ensure estimates are reasonable.  This is time well spent as appropriate funding enables your programme to focus on the delivery of the product instead of fighting for funding to keep it afloat!

Bob McGannon is a Founder and Principal of MINDAVATION, a company providing project management training and consulting, leadership workshops and team building programs throughout North America, Europe and Australia. Bob can be reached at MINDAVATION via the web at WWW.MINDAVATION.COM or by calling (02) 6232 6005.

The Mindavation Foundation is proud to donate 5% of profits towards development of youth leaders.
Copyright © 2011 Mindavation - All rights reserved.