Programme Governance Model

Copyright © Peter Wheelhouse 2014

 

Design Authority - Role Description

1.  Overview.

The Design Authority is responsible for ensuring that the consequences of any design decision are understood. The Design Authority maintains a consistent, coherent and complete perspective of the programme design, defining the programme critical interfaces, such that business operations can be changed and benefits secured in a coordinated manner across the organisation.

 

The Design Authority is responsible for defining the Programme Blueprint1, for ensuring that all proposed initiatives are in line with the Blueprint, for governing the acceptability of the key deliverables and for maintaining the overall integrity of the programme and its subsidiary initiatives.

 

1A single blueprint for the programme should be developed by expertise from across the area. Deliverables should then be governed to ensure compliance with the blueprint.

2.  Accountabilities.

The Design Authority is specifically accountable for the following:

 

  1. The Design Authority is accountable for ensuring the integrity of the programme – focusing inwardly on the internal consistency of the programme; and outwardly on its coherence with infrastructure planning, interfaces with other programmes and corporate technical and specialist standards.
  2. The Design Authority is the owner of the Programme Change Control Process.
  3. Owner of the following Governance Baseline Components:
    1. Programme Blueprint

3.  Responsibilities.

The Design Authority’s specific responsibilities include:

 

  1. Establishing design blueprints for key deliverables.
  2. Governing the content and shape of key deliverables according to the blueprint.
  3. Confirming that the overall design and project level ‘trade-offs’ will deliver the benefits defined in the programme brief, and that the business will not be unduly constrained in further growth (change) by design decisions.
  4. Designing of business and technical solutions.
  5. Managing the underlying ‘architecture’ or infrastructure, trading between local ‘expeditious’ solutions and investment in more enduring capabilities.
  6. Programme design (in consultation with, and through facilitation of, cross functional teams and technical experts):
    1. Architecture (business and technical);
    2. Sequence tasks, projects and activities in the line;
    3. Evaluate product and task risk.
  7. Commissioning projects:
    1. Prioritise and set up projects to deliver impacts contributing to business outcomes;
    2. Commission work from technical areas and establish cross-functional ‘research’ project teams;
    3. Design control;
    4. Identify and manage key interfaces between constituent projects and own programme and other concurrent programmes, recognising common or conflicting elements in different parts of other programmes;
    5. Monitor programme critical interfaces;
    6. Redesign/design adjustment of overall design in response to progress, unanticipated delay and changing project circumstance;
    7. Monitor risks associated with programme products;
    8. Identify and track the programmes requirements and implications for infrastructure (IT and Non-IT);
    9. Ensure that whatever procedures, systems or components are implemented in projects, their designs are consistent and interfaces between projects are designed consistently;
    10. Ensure that project designs comply with the policies, standards and organisational constraints and are consistent with the supporting services and infrastructures that they use or with which they interface;
    11. Where the impact of a design change is not perceived at the project management level the design authority should take a pro-active role and achieve any necessary design changes to keep the programme moving forward.

Programme Organisation