Development of a generic programme

Jill Glover
The pros, cons and potential pitfalls when developing a generic programme.

In many cases, client organisations need to receive and utilise project programmes (ie. Gantt charts developed in Primavera, Microsoft Project, or Asta) from a variety of contractors and subcontractors. The client might consider developing a generic programme template to be used by all suppliers, to standardise the programmes. This may be a better option than receiving programmes from different suppliers in various types of software, with various interpretations of the WBS (Work Breakdown Structure) and different interpretations of the detail required.

However, there are issues for consideration in developing a generic programme. This article looks at the pros, cons and potential pitfalls which may be encountered.

Main considerations for development of a programme template

Developing the correct programme template is challenging, time-consuming and must be cost-effective in what it will achieve. It needs to be developed with a full understanding of the day-to-day project level issues and go through several stages of review and roll-out before being adopted. The issues fall broadly into three categories:

Planning resources within the client organisation

  • The current position of project-level planning within the organisation, ie. how programmes submitted by suppliers are received, reviewed and used.
  • Is there an existing process in place, to ensure the robustness and quality of the programmes submitted by the suppliers and implementing best planning practice, to therefore improve the reliability of any milestone dates which may be used at higher level?
  • Is there a requirement for costs to be shown in the programmes and are the project controls systems advanced enough to ensure that any cost information provided within the programme will be used effectively? It may be that costs are not required in the programme because:
  1. The PMs within the client organisation do not have the time and level of programme knowledge to use cost information for a defined purpose;
  2. There is an inadequate level of planning resource to assist the PMs to review and make use of any cost information contained within the programmes;
  3. The structure of staff resourcing to provide planning expertise may not be clearly defined, if the project controls within the organisation is still in its infancy;
  4. The strategy for acquiring and implementing software licences and training, across the client organisation may not be defined.

Contractual issues

  • The development of any generic programme must consider which contracts will be used, so that they can sit within a contractual context and account for specific programme requirements. For example, under NEC these would include:
  1. Contract Completion and planned Completion dates would need to be shown to monitor change (compensation events);
  2. The requirement for producing separate programmes to show the impact of change (based on the last accepted programme) would need to be accommodated;
  3. Full coordination with the preparation of the Scope documents is needed, to include Key Dates and understanding of any additional contractual clauses to be used such as X5 Sectional Completion or X7 Delay Damages.

Technical/Software/Project Controls issues

  • Consideration must be given to how generic programmes would be stored in a joint system (Enterprise Management approach, owned by the client) and whether this would enable suppliers to access and use them within a shared system. Any issues around contractual ownership of the programme and submission for independent review would need to be clarified.
  • Consideration would need to be given to whether durations, logic and calendars were imposed via a generic programme template. If they are to be imposed, there are issues around whether this programme is still owned by the supplier. For example, how would the supplier be able to mitigate delays if they cannot alter durations and logic. If durations and logic are not to be imposed and fixed, then essentially the generic programme may simply become a defined WBS structure.
  • Consideration must be given on how the generic programme aligns to other systems used within the organisation. For example, if the programme is to be cost loaded, would the programme go down to a level that allows the cost to align to the cost system.
  • Consideration must be given to the reports that will be produced from the programme. Will the programme need to be coded to generate reports and how will these codes be managed to ensure the reports being created are correct?


Development of a generic programme template can avoid having several interpretations of client requirements and therefore save time and money, compared to having suppliers create programmes from scratch. It can also save time in programme review, if logic and timescales are standardised.

The use of a template however, assumes a certain maturity of existing project control systems and relies on an established planning resource capability within any existing business and therefore the implications of developing and using a template should be fully understood.

Written by