Guardians of Consequences

Part-3

Part 1 of the ‘Guardians of Consequences’ series, discussed the When /Who/ What/ Why &
How questions that need to be addressed when creating a programme controls business
function (PCBF) which enables the ‘Guardian of Consequences’ role to be effectively
fulfilled, specifically:
 When is the creation of a PCBF appropriate within any enterprise?
 Who to turn to for PCBF expert advice?
 What is the extent of PCBF accountability?
 Why is supply chain cooperation important?
 How is are the relevant PCBF data entities connected?
Part 2 of this series looked more closely at PCBF system data entities and relationships
referred to in Part 1, providing a definition of each entity, and where each needs to reside
in the PCBF toolset.
Part 3 of the series addresses the PCBF Scope Capture and Planning Integration
accountabilities as ‘Guardians of Consequences’.

Figure 3.1
Scope Capture Accountability
Scope Capture involves ensuring that all aspects of Strategic and Business Case scope are
captured in the Programme Control System toolset such that compliance can be determined
at Strategic and Business Case reviews based on:
 Strategy Revision implication reports.
 Business Case Revision implication reports.
 Delivery performance reports.
 Risk management reports.
The Enterprise Scope needs to be disseminated through multiple levels, by subject matter
experts, to ensure that all scope parameters (Schedule/Quantity/Cost/Quality) are captured
at the appropriate level and communicated to those accountable for delivery. Each level of
scope definition must be captured and maintained in the Programme Management Function
PCBF toolset.

Programme Level Scope

Programme Level Scope definition needs to be sufficient to determine how many projects
need to be initiated to deliver a strategic plan.

Project Level Scope

Project Level Scope definition needs to be sufficient to define the discrete project outcomes,
in the form of products and services and integration effort (reflected in a WBS), that need to
be successfully delivered to satisfy the Business Case.

WBS Element Level Scope

WBS Element Level Scope definition needs to be sufficient to define how many Business
Functions need to be involved, to deliver a discrete project outcome represented by a leaf in
the WBS (i.e. an element that has no children).

CAC WBS Level Scope

Control Account Level Scope definition needs to be sufficient to determine how many
different Internal Processes need to be performed by that Business Function to successfully
deliver the associated WBS element.

Planning Package Level Scope

Work Package Level Scope definition needs to be sufficient to determine how many times
any Internal Process needs to be executed to deliver the scope of the associated CAC.

Work Package Level Scope

Work Package Level Scope definition needs to be sufficient to determine how many times
any Internal Process needs to be executed to deliver the scope of the associated CAC.

Risk Mitigation Level Scope

Risk Mitigation Scope needs to be sufficient to determine what needs to be done to provide
the optimum level of protection if a risk becomes a real event. Risks of all types, scale and
severity of impact can be identified. However, not all of these should find their way onto the

2
Project/Programme Risk Register as many of them should be dealt with at departmental
level as part of the normal ‘Business as Usual’ management process.
Entries on the Project/Programme Risk Register should be restricted to those that represent
a threat to the achievement of:
 Strategic outcomes.
 Business Case outcomes.

The definition of such risks must be sufficient to enable the risk exposure profile, and the
effectiveness of agreed risk mitigation activity, to be monitored.

Planning Integration Accountability

When Level 4 Operational Planning or Performance data is received from the supply chain it
is loaded into the customer Programme Control toolset and aggregated to enable
comparison with the customer’s Strategic Plan.

Multiple scenarios are then run to establish which combination of ITT responses constitutes
a Best for Programme outcome, considering the following:-
 Schedule Non-Compliance
 Cost Non-Compliance
 Quality Non-Compliance
 Risk Tolerance Non-Compliance

Schedule Non-Compliance
Schedule Non-Compliance is only a real issue if the Level 0 or Level 1 milestones cannot be
achieved.

Cost Non-Compliance
Cost Non-Compliance is only a real issue if the customer’s Funding Profile will be exceeded
at any time in the Programme lifespan.

Quality Non-Compliance
Quality Non-Compliance is only a real issue if:
 Legal requirements will not be achieved.
 Customer Policy requirements will not be achieved.

Risk Tolerance Non-Compliance

Risk Tolerance Non-Compliance is only a real issue if the current Risk Profile at any time
exceeds the Customer’s Acceptable Risk Profile.

Conflict Resolution
Any non-compliance represents a conflict that requires resolution. The two approaches by
which these conflicts can be resolved are:
Customer/Supplier Negotiations
 Negotiation with one or more suppliers to refine their bid such that the conflict is
overcome without generating a different set of conflicts.
 Customer Business Case Review
 Customer review of the L0 and L1 Milestone requirements to resolve schedule issues.

3
 Customer review of the total scope to resolve funding issues.
 Customer review of the funding availability to resolve funding issues.
 Customer review of the acceptable risk to resolve risk issues.

If any problem is beyond resolution by these methods the Programme should be deemed to
be not feasible and abandoned.

Strategic (Top-Down) Planning Process

During the Strategic (Top-Down) Planning process (as depicted in Figure 3.2) the customer
needs to disseminate and capture the total programme scope and schedule assumptions in
the Programme Control System toolset. This enables the Invitation to tender documentation
to be written and issued and ensures that suppliers have an unambiguous understanding of
the customer expectations.

4
5
 Figure 3.2
Schedule/Scope Tool Data Transfer
Some of the Planning package dates calculated in the Schedule Management tool are
reflected in the Scope Management Tool. The specific dates that need to be transferred
from the Schedule tool to the Scope Management tool are the Planning Package level:
 Earliest Start Date
 Latest Finish Date

These dates are then aggregated in the Scope Management Tool to generate time windows
for each control account, and which are one component of the scope definition written into
the Invitation to Tender documentation (ITT) sent out to potential suppliers.
The Customer Scope Management Tool must contain, as a minimum, the data entities and
attributes depicted in Figure 3.3.

6
 Figure 3.3

The Customer Schedule Management Tool must contain, as a minimum, the data entities
and attributes depicted in Figure 3.4.

7
 Figure 3.4

8
Operational (Bottom-Up) Business Planning Process
When supply chain ITTs are issued, they must have Control Account level information which
consists of:
 Detailed scope of each the specific Control Account (CAC).
 Customer expected outcomes.
 List of Work Packages (Business Processes) that the customer has assumed will need to
be executed.
 Any other relevant assumptions made on the part of the Customer.

Using this information, the supplier typically executes an Operational (Bottom-Up) Level 4
Planning Process (as depicted in Figure 3.5) to create a detailed resource loaded plan for
each Control Account. Irrespective of what combination of specific tools a supplier may have
in their toolset.

9
 Figure 3.5
Each supplier ITT response must contain a resource loaded plan which, as a minimum,
contains the data entities and attributes depicted in Figure 3.6.

10
 Figure 3.6
Any ITT response not containing plans at this level should be considered non-compliant.
However, a supplier’s inability to generate this quality of plan does not have to be a barrier

11
to them bidding for work, as it is possible for the customer to replicate (in the customer’s
toolset) the infrastructure that would normally be required of the supplier. This would leave
the supplier simply having to respond initially, and each reporting period, to questions
posed by the customer.

Data Integration Process

As depicted in Figure 3.7, the Data Integration process involves amalgamating the data from
a range of sources to create a consolidated total real-world view of what can be delivered
by the supply chain. By then comparing this with the top-down expectations of the
customer, the extent of any conflicts, that need resolution, can be identified.

12
 Figure 3.7
Conflict Resolution Process
To enable detailed analysis and comparison, the Strategic and Operational planning data
needs to be loaded into the customer Programme Management Controls Toolset. If the
aggregation of Control Account Level Operational Plans satisfies the Strategic Plan, then the
entire Operational Plan should be deemed acceptable, even if individual strategic
assumptions at Control Account level do not align with the supplier provided data.
However, where the aggregation of Control Account Level Operational Plans does not satisfy
the Strategic Plan then negotiation and resolution of those conflicts is required if the
programme is to continue.

The outcome of any conflict negotiations may result in changes to expectations (Strategic)
and/or the delivery mechanism (Operational) in terms of:
 Timescales
 Funding
 Cost Estimates
 Access to Technology
 Risk Tolerance

13
When any CAC submission has been contractually accepted the Work Packages, derived
from that Operational Planning process, replace the equivalent Planning Packages in the
Customer Programme Management Controls System Toolset. This Control Account level
detail is then incorporated into the Performance Measurement Baseline (PMBR).

Operational Logistics Modelling Process

The logistics modelling demonstrates the capacity of the enterprise to utilise the available
infrastructure to make of all the components, (required to perform the currently planned
work) available at the right place and time in terms of:
 People
 Materials
 Equipment
 Services

This is a key element of the ongoing Programme Integration, and is particularly important at
locations where any of the following apply:
 Large quantities of material are stored temporarily
 Large quantities of equipment are stored temporarily
 Large pieces of construction machinery are utilised
 Work is undertaken in areas with limited access
 Use of temporary roads and utilities is required
 Site configuration changes as the programme of work progresses
 Support Services are required to be available at short notice

Modelling requires the integration of planned and current capacity with planned and actual
demand profiles. As this tends to be very dynamic data the availability of effective
operational tools for collecting and disseminating this data has a significant impact on the
efficient expediting of routine daily activity

Part 4 of the series explores the PCBF Data Maintenance and Toolset Maintenance
accountabilities and the routine business processes that enable the full extent of these to be
fulfilled consistently.

14