Management Control

Overview:

Standards:

What is different for programmes?

Roles and Responsibilities:

Project Role/Activities	Programme Manager	Project Executive	Project Manager	Senior User	Head of Portfolio	Business Architect	Business Analyst	Portfolio office
Set up the Assurance Plan	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Defining and managing delivery within scope	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Maintain control in line with the Align Framework lifecycle and decision gates	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Impact assessment and control of changes	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Progress reporting against success factors	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Tracking of dependencies from other projects	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Quality specification and acceptance procedures	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Scaling controls appropriately	Approves	Authorises	Actions	Approves	Assures	None	None	Advises

 

 

Programme Role/Activities	Senior Responsible Owner	Business Change Manager	Programme Manager	Head of Portfolio	Portfolio office
Development of the programme Management Controls strategy	Authorises	Approves	Actions	Assures	Advises
Establish the Integrated Assurance Strategy	Authorises	Approves	Actions	Assures	Advises
Managing project delivery within scope	Authorises	Approves	Actions	Assures	Advises
Maintain control in line with the Align Framework lifecycle and decision gates	Authorises	Approves	Actions	Assures	Advises
Management and control of changes across the  programme	Authorises	Approves	Actions	Assures	Advises
Control of changes to dependencies internal and external to the programme	Authorises	Approves	Actions	Assures	Advises
Programme monitoring and reporting	Authorises	Approves	Actions	Assures	Advises
Scaling controls appropriately for projects	Authorises	Approves	Actions	Approves	Advises
Review of programme controls effectiveness	Authorises	Approves	Actions	Approves	Advises

 

Role Key:

Accountabilities	"Authorises" - provides the Board endorsement that the activity has been undertaken
	"Approves" - provides business approval of the result of the activity
Responsibilities	"Actions" - responsible for ensuring the activity is undertaken effectively, can be delegated
	"Advises" - provides guidance and help where needed
	"Assurance" - formal independent review

 

Control Techniques

Delivery Lifecycle and Gates

The delivery lifecycle defines the journey of an idea from concept to delivery, it is designed in a flexible way to enable policy teams to evolve concepts, under control, that may or may not lead to a project at some stage.

The lifecycle provides a number of pre-determined stages that all initiatives will follow, each stage is made up of a number of milestones that provide the consistency and visibility of project progression across the organisation.

The lifecycle has guidance on how to move between the milestones and the areas that need to be considered.

The lifecycle only defines the management milestones for tracking progress. Each programme and project will have unique activities that it will need to achieve.  Therefore, it is likely that a number of specific milestones and activities will be required to reflect the scale and nature of the programme or project.

Additionally, for simple projects it may be possible to pass through certain milestones very quickly as little work will be required.  The milestones in that situation can act as a checklist to ensure nothing has been missed.  For larger programmes, each milestone may take months or even years.

The key value of a consistent set of milestones is that at the portfolio level the progress towards completion can be easily tracked and assessed.

The end of each of the lifecycle stages will involve a decision gate review to decide if the project or programme is still viable - this is a fundamental basis for the control.

 

Scope Management and Progress Tracking

The most common cause of project failure is the lack of clarity and definition around the scope and business requirements. This leads to inappropriate expectations being set for stakeholders and difficulty in identifying and delivering the correct solution.

The initiation documentation should clearly state what will be delivered and when. There should be an operating model that sets out not just the products (deliverables) that will be created, but how will they be deployed to deliver outcomes that will improve operations or performance.

The scope of the change should see the full impact of the outcomes, not just focusing on what it will create.  Consequently, impact assessments of change can be effectively carried out.

There should be robust and regular progress reporting that focuses on ensuring that the programme and project are progressing towards achieving their objectives.

 

Scaling Controls

The scaling of the project controls are linked to the risk profile assessment, which will diagnose the complexity and difficulty of the change. This will be affected by many factors, including:

• Cost of the change
• Previous experience of this type of change
• Predictabilty of the outcomes
• Availability of resources
• Impact on the organisation structures and working practices
• Impact on operational processes and ways of workings
• Likely levels of stakeholder resistance/support
• Complexity of the technology or the assets
• Dependecies on other changes
• Size of the benefits

 

The Risk Profile Assessment will allocate the project a level of High, Medium or Low risk.

All projects will follow the common lifecycle; however, the levels of control for a high risk change will be more robust than those for a low risk change.

 

Setting Objectives

At the outset of the change, there is often ambiguity about what is going to be achieved; however, working to clear the ambiguity is key aspect early in the lifecycle. This will require engagement at a number of levels.

The Project Executive will need to clarify the strategic context and constraints within which the project should deliver. These will provide the top level objectives resulting from the discussions with the stakeholders.  

Objectives can be categorised as follows:

• Strategic objectives- the objectives that are driving the need for the project.  They may be linked to the corporate objectives, meet a legislative requirement, serviced weaknesses, competitor behaviour or be in response to a policy decision that needs to be implemented.    Work to define the benefits of these objectives may already have been undertaken and should be captured - relevant to the management board and major investment decision makers.
• Operational objectives- those that are driving the business need for the project at an operational level. They are likely to reflect the need for greater efficiency or to improve the quality of services that are being delivered. This may have been defined as part of the development of the benefits, so there may be specific objectives that the operations will need to meet to satisfy the benefit profiles.
• Project objectives - those that are linked to the internal performance of the project or are specific to the way the project will operate. For example, in the way that it approaches the development of options or manages a major constraint. Other project objectives should reflect the compliance to corporate standards and how it will achieve effective delivery. 

Failure to capture this holistic view of what is required through the objectives can be attributed to many perceived project failures.

As a rule of thumb, all objectives should be:

• Specific to the programme or project
• Measurable - so that success is tangible
• Attributable to individuals within the programme or project
• Realistic within the constraints and resources within which the project will deliver
• Time-bound - so that at each gate progress can be assessed.

 

Quality Management

Quality management in a programme or project is a very wide ranging topic. For the purposes of management control it is focused on delivering the outputs and capability to a standard that is acceptable to deliver the change.

Outputs (PRINCE2 calls them products) can range from a document to a bridge - each has to be produced to a particular standard to be acceptable.

At programme level quality is associated with the management processes. The outcomes are defined in the blueprint which is delivered by the projects, so the focus of this section is on project quality.

Quality is the definition of what success will look like. It is the functionality and quality of the outputs. This is derived from the objectives which outline the problem being solved; the requirements which are what is needed to solve the problem and the outputs are the assets that will be used. 

Managing quality is about getting the outputs right first time.  What the project doesn't want to happen is for something different to turn up on site on the day of installation to what was required.

The other aspect to quality is the evolving expectations of stakeholders, who may have specified one thing, but in their view it becomes morphed into something completely different through over publicising the benefits or the positives. These are the sources of perceived project failures.

Quality is managed by measuring and monitoring the quality of the outputs being developed against the quality criteria during design and development rather than wait to see the finished article, after much time and effort may have been wasted creating the wrong thing.

The sources of acceptable criteria were defined in the product descriptions and these should provide the basis for the assessment process.  Managing the progress towards the delivery of the product may be defined in terms of establishing reviews at points where deviations can be managed, namely:

• Outline design
• Prototype build to prove concept
• Functional testing to prove it does what it says
• Piloting to test it in a live environment
• Final roll out

Each of these may trigger payments if a supplier is involved, which is a good way to control the expenditure related to value delivered.   These steps could also be used to measure percentage of the task completed.

Reviews can take two forms, a formal scheduled review and/or spot checks on progress.

Opportunities may arise through the quality control process to deliver requirements that were identified at the outset, but were not left out of scope as they were categorised as "nice to haves", this in turn increases the value to the operations, or a completely new opportunity may arise unexpectedly.

Changes to quality should be regarded as issues and follow the change control procedures.  Any changes to requirements from either the supplier or the customer will have a time and cost impact which must be assessed.

Tolerance and Change Control

There are three major areas of control in a project:

• The time the project takes
• The resources (cost) used by the project
• The quality of what the project produces.

The project must manage these dimensions as a change to one will affect the other. If the project runs late, it will consume more resources and cost more.  The only way to affect this is to change the scope and reduce the quality requirements or amount of what is delivered, this will enable the project to re-plan, claw back time and achieve its objectives within the same resources (cost).

To manage this effectively, it is essential that internal and external resources are calculated.

Tolerance therefore can be allocated against:

• Cost - the most common tolerance refers to the budget; this allows flexibility on where the money is being spent.  For most organisations when tolerance is set, the budget available to the programme/Project Manager would only be 90% of the total to ensure that cost is controlled appropriately, enabling escalations and changes to be managed effectively.
• Timescale - by setting a tolerance on the time within which the project or an element of the project can run late, the project may be able to stay within tolerance on quality or cost. It may be that the deadline has no tolerance, in which case, this will mean the tolerance will need to be set on quality or budget.
• Quality - the Requirements and Product Descriptions will set out what the acceptable criteria for the quality of the project outputs will be.  It may be that pursuit of perfection will significantly increase the cost of the product (unless it has been set at fixed price).  The key to finding tolerance on quality is calculating the time and cost of the minimum functionality, the tolerance can then be set on how important the additional functionality is.  The Time Boxing technique mentioned earlier can be used to manage the building of the product.

Remember that projects run a year late one day at a time. Once time slips it cannot be made up without re-planning and changes to the way it is being delivered (taking corrective action).  The challenge is to manage drift of costs, time or quality that aggregates below the radar and becomes transparent later in the day.

Integrated Assurance

There are various definitions of what integrated assurance means, but this one from Beyond Boundaries (Kubitscheck, Gower) seems to encapsulate the key points: “Integrated assurance refers to a structured approach for gaining a holistic picture of the principal risks and the level of residual exposure an organisation is required to manage. It involves aligning and optimising the organisation’s assurance over the management of those risks and core business activities in line with the board’s risk appetite and exists to support the board’s risk oversight and risk taking”. Assurance gives confidence to the key stakeholders that plans and objectives are achievable.

Main forms of assurance that are generally available are:

• Tier 1 – The P3M3® maturity model - assesses the organisation’s overarching maturity. This provides insight into the organisations systemic strengths and weaknesses which will ultimately dictate the likelihood of success.
• Tier 2 – Independent reviews - use either internal peer groups or external experience to take an independent view of programme or project. These are normally advisory in so far as they can judge the likelihood of success. As they are independent they are not part of the delivery regime so must provide an independent objective view on the business viability of achieving the outcomes and the process for achieving them.
• Tier 3 – Internal reviews - these reviews are the ‘stop/go’ points, so these are not advisory, they have teeth and bite because this is where the justification for continuing with the investment are made and where accountability sits. These reviews may need more technical expertise to assess the technical viability of the approach and their ability to meet the business requirements. At this level there could be internal health checks rather than formal gate reviews and as such are less likely to have teeth

This article explains how to achieve this integration.

How2Guides: