Risk and interdependency in programs

There has been plenty written about how a different approach is needed when managing a program rather than a project. Sometimes the differences are obvious, other times differences are subtler. This article focuses on two areas of planning and control, namely risk and interdependencies. The two areas are tied since interdependencies are one of the primary areas of program risk.

Setting standards

It would come as no surprise that the first recommendation when planning and controlling a program of work is to adopt standards. A standard approach to scheduling, standard use of fields, consistent use of issues and risk logs, standard reports and reporting cycles are all necessary. Standards aren’t popular with some project managers, but can save program managers from a great deal of pain when trying to consolidate and integrate plans and reports across the projects associated with their program.

The approach to scheduling is perhaps the most difficult to achieve, particularly when advanced updating techniques and float calculation may not be well understood by some.

Focus on interdependencies

Assuming the scheduling standards are adhered to, one would assume that a program simply needs a very large schedule. Project managers who move into program management soon find that is not the case. Try making sense of, and keeping up to date, several thousand tasks across multiple schedule files: it soon becomes overwhelming.

One way to manage a large program of work is to use a ‘master and sub-project’ structure, delegating responsibility for creation and maintenance of sub-projects to project managers and/or their schedule support staff. Focus everybody on interdependencies between sub-projects and ensure the producer of the outgoing dependency has ownership of the product and the consequences of any delay.

The interdependencies can be identified very early in the planning process, well before a detailed schedule exists. The following steps may help:

1. Interdependencies are often associated with deliverables. Interdependencies should be represented as milestones, particularly in the recipient schedule.
2. Clearly define the expected state of the dependency, for example ‘draft’, ‘final’, ‘signed off’, to ensure there is no misunderstanding.
3. The producer and recipient need to formalise the agreement; there must be a personal commitment involved.
4. Once agreed, change must be controlled, for example deletion, descriptions, baseline date and so forth.
5. Uniquely identify the outgoing dependency in the incoming file; this will help with electronic data exchange. This can be difficult with MS Project, but there are work-arounds.
6. Consider whether to actually link via interproject linking, whether to just pass through forecast, perhaps into another field, or rely on manual updating.
7. Include interdependency dates in reporting, focus on any shifts in forecasts since the previous report.

Shown below is an example of how a schedule might show dependency forecasts on an incoming dependency and leave the rescheduling decision up to the project manager. Note the project manager has identified the item in the producer’s schedule.

There are several implications of a focus on dependencies when managing schedules that will need to be considered:

• The tendency for dates to continually drift unless project managers are made accountable for the effect of delay on recipients.
• Time needed within reporting cycles for corrective action planning.
• The complexity of whole of program critical path analysis.

Resource dependencies

What is often more difficult to model in schedules is resource dependency. Whether the resources are unique but shared resources, generic resources or specific infrastructure, such as a test environment, modelling a resource dependency can be difficult.

In project scheduling, concepts such as the Critical Chain method were developed to formalise resource dependencies within a project schedule. Applying such a method across a program would prove extremely complex and would be unlikely to provide the desired outcome. A better approach would be to model just the key resource dependencies, making them obvious through the use of milestones and interdependencies, as outlined above. Descriptions should be very clear and agreement from the resource manager sought.

Allocating resources in schedules can provide much value if done in a standard way by people who know how to drive the scheduling tools. Consistent rules, for example fixed duration, effort driven off for those who use MS Project, are needed along with accurate effort-based percentage resource allocation.