Sign in

Programme and project accountability: the governance of capital investments White Paper

White Paper

Programme and project accountability: the governance of capital investments White Paper

White Paper

  • White Paper
  • Governance
  • Portfolio management
  • Programme management
  • MoP
  • MSP
  • P3O
  • PRINCE2

Author  Ross Garland

June 29, 2013 |

 36 min read

  • White Paper
  • Governance
  • Portfolio management
  • Programme management
  • MoP
  • MSP
  • P3O
  • PRINCE2

The purpose of this paper is to clarify programme and project accountability. This issue lies at the heart of capital investment governance. The paper demonstrates how the logic behind the concept of accountability can be used to ensure a consistent approach to governance across an organization.

Defining accountability and capital investment governance

The importance of good governance in the delivery of capital investments has been recognized by the Cabinet Office for some time. For instance, the Office of Government Commerce (OGC)1 published a pamphlet in 2005 entitled Common Causes of Project Failure which refers to problems such as ‘lack of clear senior management … ownership and leadership’ and ‘lack of effective engagement with stakeholders’, both of which are important facets of accountability and governance. Addressing such issues across an organization requires a common and consistent language and understanding.

Accountability means being answerable to one’s superior. Accountability is at the core of governance and central to the governance of programmes and projects. Capital investment is the commitment of money to purchase assets. Capital investment governance is the organizational framework that enables effective capital investment decision-making. Therefore clarity of accountability is a prerequisite for effective programme and project decision-making.

1 The OGC is now part of the Efficiency and Reform Group in the Cabinet Office.

Background

QUT study of PRINCE2®

In early August 2010, the Queensland University of Technology (QUT) released the findings of a research project entitled Creating Value in Project Management using PRINCE2. The research project was sponsored by APM Group Ltd (APMG), OGC and The Stationery Office (TSO).

The research project identified ‘the dominant factors which participants believe constrain the success of PRINCE2 projects’. The project identified that it was not the framework that was at fault but rather the organization’s ability to effectively implement that framework. In particular, poor project governance was cited as a major failing:

'PRINCE2 participants were especially trenchant in their judgement of Project Board effectiveness. Project Board members were criticised for: not understanding their roles and responsibilities, lacking experience, or not possessing the necessary competency. Project Boards’ membership was sometimes delegated to staff who had no decision-making authority. Project Boards were not using the Business Case to periodically verify the continuing viability of the project. Senior management was also chided for its lack of commitment and leadership, and a tendency to bypass the Project Board. More generally, organizations were not giving sufficient priority to project governance.’

On the basis of this study alone, it appears that project governance is not well understood or effected. The primary accountability of the project executive in PRINCE2 is for the success of the project. This is clearly not well understood, or at least, its implementation by organizations is flawed. At the core of these issues is accountability. The accountabilities of the key decision makers determine how programme and project boards operate and their relationship with portfolio management or senior executive teams. Unless these accountabilities and relationships are clear, the implementation of methodologies such as PRINCE2 will always run the risk of being flawed. The original PRINCE was established in 1989. If the governance arrangements it proposed are not well understood, it is likely that the governance elements of Managing Successful Programmes (MSP®), released a decade later, won’t be well understood either. The year 2011 saw the release of Management of Portfolios (MoP®) by OGC, and so a further piece has been added to the capital investment governance puzzle.

Fundamental problems of accountability

Experience, and studies such as the QUT PRINCE2 study, suggest a number of fundamental problems associated with accountability in the governance of programmes and projects.

Lack of understanding of the true purpose of programme and project committees

Meetings of governance committees are routinely used by attendees to update themselves on the project’s progress. Quite often they are used as a mechanism for stakeholder management – one need only consider the size of the meeting. Very large meetings are usually indicative of a committee functioning more as a stakeholder group than a decision-making group. Yet programme and project governance should be fundamentally concerned with effective investment decision-making2 since this supports the accountability of the senior responsible owner (SRO) or project executive. When functions such as information-gathering or stakeholder management are incorporated into meetings, the primary remit of the governance committee will suffer.

Insufficient understanding of programme and project accountability

PRINCE2 talks of the project executive being accountable for the success of the project and representing the business, but this can be interpreted in many ways. On a major project, there may be any number of senior executives who consider themselves capable of ‘representing the business’ but only one of them is ideally suited to take on the role of project executive. Organizations need guidance on how to select that person. Similarly, when PRINCE2 states that the project executive is accountable, it means exactly that – that the buck stops with the project executive. However, some organizations insist on project board decisions being ratified or endorsed by one or more senior managers in the organization. Such arrangements are at odds with PRINCE2’s intent of treating the governance of change differently from that of business as usual. This was one of the key findings of the QUT study into PRINCE2 – that organizations were not always implementing PRINCE2 effectively and this was particularly noticeable with the project governance elements of the methodology.

Lack of clarity around the integration of project, programme and portfolio governance

Large organizations are likely to have a mix of projects and programmes, with some form of portfolio management. This can result in numerous programme and project boards along with an executive management decision-making committee. The question of accountability then becomes central since unless the accountabilities and associated decision rights at each governance level (portfolio, programme and project) are consistent and logical, the overall governance arrangements won’t be effective.

2 As opposed to technical decision-making to differentiate it from those decisions made by project managers and their teams.

Existing Best Management Practice guidance on governance & accountability

The following is intended to provide the salient points of the guidance available on governance and accountability. It is not intended to be fully comprehensive.

PRINCE2

Managing Successful Projects with PRINCE2 (OGC, 2009) introduces the concept of the project board comprising the project executive, who represents the business viewpoint and is chair; the senior supplier who represents the interests of those designing, developing and implementing the project’s products; and the senior user who represents the interests of those who will use the project’s products. The project manager reports to the project board but is not a member of it. Board members are supported by assurance roles. The PRINCE2 governance arrangement is shown in Figure 1. Note that details such as assurance roles and change authority have been omitted.

The project board is responsible for ‘the overall direction and management of the project within the constraints set by corporate or programme management’. PRINCE2 shows the project board reporting to corporate or programme management. On the size of the project board, it states that ‘The project board needs to represent all of the interested parties in the corporate organization, and involve any suppliers (internal or external) that have been identified.’ It subsequently modifies this by saying ‘It is good practice to keep the size of the project board as small as possible while still representing all business, user and supplier interests.’ Certainly the former statement could result in very large project boards.

PRINCE2 describes the project executive as being ‘ultimately accountable for the project’s success’ although it also describes the project board as ‘being accountable for the success or failure of the project in terms of the business, user and supplier interests’. The project executive ‘is responsible for the business case’ and ‘responsible for ensuring the business case is written and approved’. PRINCE2 doesn’t actually state who should approve the business case although it comments that ‘In some cases, programme management will provide an approved business case as part of the project brief.’3 The project executive is the ‘single point of accountability for the project’.

The project manager is described as ‘the single focus for day-to-day management of the project’ and operates within the constraints laid down by the project board.

Figure 1 PRINCE2 project governance

Managing Successful Programmes

Managing Successful Programmes (MSP) (Cabinet Office, 2011) integrates its governance approach with that of PRINCE2. Figure 2 gives an interpreted view of the governance relationships between the programme board, the PRINCE2 project board and the sponsoring group. MSP describes the sponsoring group as ‘making the investment decision’ with its role perhaps being performed by ‘a standing corporate portfolio board’. The programme board is chaired by the SRO who is ‘ultimately accountable for the programme’ and ‘accountable for the success of the programme’. MSP describes the programme board as reporting to the SRO. The SRO is supported on the programme board by the following:

  • The programme manager who is responsible for the day-to-day management of the programme and is the ‘agent’ of the SRO
  • The business change manager who has ‘responsibility for benefi ts defi nition and management throughout the programme’ and is ‘key to providing the bridge between the programme and the business operations’
  • Project executives from key projects within the programme
  • The lead supplier if appropriate
  • Representatives of corporate functions such as finance, HR etc.

MSP discusses integrating programme and project governance structures. It implies that not all projects within a programme will have a dedicated project board. In key projects, the project executive may sit on the programme board, while other important projects may have the programme manager acting as the project executive.4

Figure 2 Programme governance arrangements

Portfolio management

Management of Portfolios (MoP) (OGC, 2011) refers to the peak governance body as the portfolio direction group or investment committee and describes it as ‘the governance body where decisions about inclusion of initiatives in the portfolio are made’. The portfolio direction group is supported in its activities by the portfolio progress group which reports to it. This is ‘the governance body responsible for monitoring portfolio progress and resolving issues that may compromise delivery and benefits realization’. The relationship between the portfolio and programme levels in the organization, and their respective accountabilities, are implicitly addressed through the medium of the business case:

  • The decision to include initiatives in the portfolio, and their prioritization, is based on an assessment of the project or programme business case; hence there exists an implicit decision hierarchy between the project/programme board and the portfolio direction group
  • MoP mentions the usefulness of a staged gating process based upon the programme and/or project lifecycles, especially if it is linked to funding. While it does not explicitly state that the gating process is based upon reviews of the business case, it seems likely that this is the case. This indicates, albeit implicitly, a useful accountability split – the SRO approves the business case but the portfolio direction group subsequently determines whether funding will be released.

Portfolio, Programme and Project Offices

Portfolio, Programme and Project Offices (P3O®), published in 2008 by OGC, doesn’t address capital investment governance as such. Instead, and as to be expected, it analyses the governance arrangements for P3O offices – who should head them up, where they should be sited and how they should report. Whilst important, these considerations are not central to this White Paper.

3 Approval of a document is a critical concept in governance since it is tightly linked to accountability. As discussed in section 6, accountability is the cornerstone of good capital investment governance.
4 This is interesting in that the programme manager may well be an outsourced position. In section 6, the importance of the SRO or project executive having a service outcome focus is discussed – this is unlikely to be the case with an outsourced programme manager/executive.

Business as usual versus change

Programmes' and projects are not driven by the need for routine or ongoing operational effectiveness and have very different organizational needs from that of business as usual. Whereas the organization has ongoing operational needs as its primary focus and has an organizational structure designed to deliver this, programmes and projects are a very dynamic environment with a relatively short-term focus. Large programmes create impacts across the organization. Those impacted by the programme or project are not neatly arranged within an organization chart but are scattered throughout it, and perhaps even across other organizations or agencies. It is therefore not surprising that the programme’s needs cannot usually be met by the existing organization structure. This situation is described diagrammatically in Figure 3 for a typical programme.

Figure-3-Organization-structures-do-not-usually-meet-programme-needs.png


This has a number of consequences for programmes and projects. In particular, it means that they cannot utilize the organization structure for their own delivery purposes since that structure is not designed for the delivery of change.

This problem is overcome through the establishment of a programme board specifically designed to meet the programme’s needs. The intent is that key stakeholders are brought together under the umbrella of the programme board to make decisions as a group, thereby ensuring the needs of key stakeholders are met and the delays associated with serial or layered decision-making (as is typical of decision-making in an organization structure context) are overcome.

The governance triangle shown in Figure 4 displays diagrammatically the difference between governing business as usual and governing programmes and projects. It also indicates how the different governance arrangements for business as usual and programmes and projects are aligned at the portfolio level within the organization since the portfolio deals with allocating funds across both types of activity.

Figure-4-The-governance-triangle.png


Accountability

Single point of accountability

Best practice (both PRINCE2 and MSP) promotes a single point of accountability for the success of a project or programme that remains unchanged over the life of the project. PRINCE2 refers to this person as the (project) executive while MSP uses the term senior responsible owner (SRO). A single point of accountability ensures clarity of decision-making and empowers the accountable person within the organization. Constancy of this accountability throughout the project’s life ensures decision-making consistency – the focus of the project, its objectives and the benefits it seeks, remain the same throughout its life, or at least are not changed without due process.5

Without such constancy of accountability, the direction and focus of the project may change. This is because the direction and specific focus that the accountable person brings to the project reflects their role in the organization, and this may shift if the accountable person changes. This is not ideal if the change detracts from the service outcome (see below). Furthermore, transferring accountability from one person to another runs the risk of blurring accountability since decisions at one point in the project lifecycle may have been shaped by those made under previous accountability arrangements.

Identifying the accountable person

Figure 5 shows how a project can be considered as a mechanism to move from one level of service to another, higher, service level. Projects enable step changes in service level. Within an organization there will be a person accountable for delivering the existing level of service. The same person will also be accountable for delivering the future level of service or service outcome that the completed project will achieve.

Figure-5-The-project-as-a-transition-mechanism.png



The accountable person is clearly best placed to define the exact service outcomes they will require in order to deliver the level of service for which the organization will hold them responsible. Meanwhile, the project executive (or programme SRO) will be defining the outcomes the project or programme must deliver. Unless these outcomes exactly match the required service outcomes, the project will deliver a sub-optimal service outcome and the new service level will not be attainable.

The only way to make certain that the outcomes defined and delivered by the project executive exactly match the service outcomes required by the organizational owner of those services is to ensure that both are defi ned by the same person. In other words, service ownership determines project ownership. This places business interests at the heart of project delivery.

Service outcome focus of accountability

Projects deliver assets and assets act as platforms for the delivery of services. The primary reason for investing in a project is to achieve a service outcome. Therefore the service outcome should always be the focus of the project from an investment perspective. Hence, the person accountable for the success of the project should be that person best positioned to maintain a service outcome focus for the investment being made. The choice of candidate is best determined by an examination of organizational roles and responsibilities to identify which role in the organization is accountable for the service outcome in question. Without this approach, there is a risk that the delivered outcome will not provide optimum value for money since decisions may not necessarily be made on the basis of the service outcome. Examples of sub-optimality from a service perspective might be:

  • The timing of the delivery – the asset may have been delivered earlier than was necessary thereby delaying a more worthy project The asset may not be optimally integrated with other assets in the network
  • Changes to the asset’s design may have been approved to meet construction needs but result in additional whole-of-life costs
  • Reduced benefits may occur as a result of changes made during development not being service-outcome focused
  • The project deliverables may not be considered suitable by those involved in service delivery.

The accountability equation

Service outcome accountability determines project accountability since the primary reason for a project investment is to enable a future service outcome. Therefore, if a person is accountable for a service outcome, they are accountable for the project that delivers that service outcome. This equivalence is displayed in Figure 6. Furthermore, when a person is accountable for the success of a project, they must by definition be accountable for the business case, since the business case describes the project and the   justification for undertaking it. Without control over the business case, there can be no control over the project itself. Similarly, there is no accountability without empowerment and that is provided in part by budget accountability – without which there is no real control of the project.

Figure-6-The-accountability-equation.png

Consequently, the accountability equation of Figure 6 must hold for the governance arrangements of a project if the project is to be fully effective. This is not to say that a project will fail if its governance arrangements do not refl ect the accountability equation, but its outputs are likely to be sub-optimal.

Therefore, the person accountable for the success of the project is accountable for, amongst other things:

  • Defi ning and focusing upon the service outcome throughout the project’s life
  • Owning and approving the business case and changes to it
  • The project budget and the tolerances set.

The concepts discussed in this section apply equally to programmes. However, there will be programmes, usually large ones, where there will be more than one service involved (and perhaps more than one organization) and so it will not be as simple to identify who should be made accountable for the programme – there may be several candidates.

What decisions should be made by the project board?

Generally, any decision that can have a material impact on the business case should be made by the project executive and project board. The logic should be apparent: the business case describes the project and the justification for developing it. Since the project executive is accountable for the project, and therefore the business case, any matter that can have a material impact on that business case must fall within the decision remit of the project executive and project board.

The identification of the programme SRO in such circumstances could be addressed by the likely apportionment of risk and capital on the programme, where the SRO is selected from the organization carrying the greatest risk.

Supplier accountability

In-house suppliers often consider themselves accountable for the success of the project – after all, projects are their business. However, the supplier is accountable for delivering the project within the constraints laid down by the business case, i.e. on schedule, within budget, to the required level of quality etc. Hence the project executive or programme SRO approves the business case and the delivery arm delivers within the constraints laid down in that business case. These arrangements can become blurred.

For example, sometimes, in both explicit and implicit purchaser/provider arrangements within an organization, there is a tendency for the purchaser to hand over too much responsibility to the provider and not to fulfil the project executive’s role. This often happens when purchasers are not adequately resourced to fulfil their executive obligations – organizations often concentrate all their project delivery skills in their project delivery group, forgetting the overall project skill needs of the business. Alternatively, the provider (supplier) can ‘capture’ a project and take on too much responsibility and accountability and become a de facto executive. In either case, the consequence is that the delivery arm of the business drives service outcomes and the result is again at risk of being sub-optimal.

5 It is the role within the organization rather than the person that is made accountable.


Decision rights

Clarity around decision rights at the project, programme and portfolio levels within an organization is critical to effective governance. Without such clarity, decision-making becomes ad hoc and blurred. Further, if the governance framework is to be effectively integrated, it is essential to ensure the decision rights are internally consistent and logical.

Projects and programmes

Since PRINCE2 uses product-based planning, many project decisions will, or should, involve approval of key project documents. Foremost amongst the documentation is the business case since it provides the ongoing justification for the project and is therefore central to decision-making.

Figure 6 indicates the importance of linking project accountability with business case accountability. Hence, PRINCE2’s project executive, who is accountable for the success of the project, should be the person who approves the business case. It would be sensible if, at the same time, other board members endorse the document to show their support for it. Remember also that the business case is a live document and is developed throughout the early stages of the project. It will therefore have various iterations that require approval. Documents that feed into the business case, such as the project brief and project plan, should also be approved by the project executive and endorsed by the project executive’s colleagues on the project board. PRINCE2 proposes management by exception. For this to work effectively the baseline against which exceptions are to be measured will need to be well defined and documented. The project will therefore produce other documents that will need approval by the project executive.

What event initiates a project?

Since, according to PRINCE2, ‘a project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case’, it must have a start and a finish. Organizations often struggle to initiate projects effectively because they can’t identify the initiating event.

The solution is straightforward. A project should not exist without governance in place otherwise there can be no effective project decision-making. The very first step in establishing governance is to appoint the accountable person.

Hence the event that initiates a project is the appointment, by corporate, portfolio or programme management, of the project executive.

On large and complex projects, the project executive is likely to be reporting to, or perhaps be a member of, a programme board. Reporting to the project executive will be a project manager. Clarity of decision rights requires all three parties to be clear over who approves what (four parties if a programme manager is included). This should be defined by the programme board (or perhaps even by a portfolio board if there is to be decision-making consistency across the portfolio), but broadly, the project board should make decisions on matters that could have a material impact on the business case. Even before the business case as a well-defined document exists, a high-level business case exists in other forms, such as the project brief. It is the role of project board members to determine what is relevant or significant throughout the project’s lifecycle.

The accountability of the project manager on the other hand relates to delivering the project within the constraints laid down in the business case. Only the project executive (through the project board) can vary the business case. Hence any issues of, or changes to, scope, cost, schedule, risk or quality that fall outside agreed tolerances should be referred to the project board (see box on ‘Making sense of the layers of accountability’ for guidance on decision rights and accountability).

Making sense of the layers of accountability

The project manager is accountable for delivering the project within the constraints laid down in the business case.

The project executive is accountable for the success of the project.

The SRO is accountable for the success of the programme.

The CEO is accountable for the success of the portfolio (assuming the portfolio covers the whole of the organization).

If one project ‘fails’, the focus should be on the project executive.

If many projects within the programme are failing, the focus should be on the SRO since it would appear that the foundation for the success of the projects has not been laid.

If programmes and projects are regularly failing across the organization, the focus should be on the CEO with a view to implementing an investment management framework.

The larger and more complex a project is, the more likely it is to be a programme – in other words, a group of related projects that together will deliver certain benefits. In some instances, one or more of the constituent projects will have business cases that are a subset of the main programme business case. For example, some projects may have no benefits directly attributable to them, but rather contribute to delivering the overall programme benefits. In such circumstances, the project business case is less about justification and more about costs, risks, schedule and scope management. Some, perhaps all, of these parameters may be laid down by the programme board. So in a programme situation, the decision to vary the business case may not be within the remit of the project board but rather fall within that of the programme board. Any decision, whether document-, design-, issue- or risk-related, that can have a material impact on the programme business case should be taken by the programme board. Thus, major project risks on critical projects may be escalated to the programme board.

Most large organizations have some form of executive management team that takes the strategic decisions in respect of the organization. Often such a group, or a subset of it, is constituted as an investment committee6 where, as MoP puts it, its purpose is to make ‘decisions about inclusion of initiatives in the portfolio’. The investment committee is supported by analysis provided by the portfolio office. Inclusion of an initiative is on the basis of its business case compared with the business cases of other initiatives and the extent to which it contributes to the achievement of the organization’s corporate objectives.

The investment committee can, however, make key investment decisions throughout the investment lifecycle using the mechanism of an investment gating process. This decision-making process provides the committee with visibility and control over the organization’s major programmes and projects. An investment lifecycle with associated decision gates is shown in Figure 7. These decisions can be (and usually are) linked to the release of programme or project funds, and are based around iterations of the business case.

Figure-7-Investment-lifecycle-and-associated-investment-decision-gates.png

Note that an investment gating process is different from an assurance gating process such as the OGC Gateway™ review process. Gateway reviews support management in making investment decisions. To do this, they are programmed to occur ahead of an investment gate where an investment decision will be made. Such a review is an assurance mechanism rather than a governance mechanism even though it is integrated with the investment gating process. A programme or project could pass through an investment gate without a review at that gate, or a programme or project could undergo a Gateway review without an associated investment gate.

Typical investment decisions made at each gate in Figure 7 are:

  • Initiation gate Occurs during the strategic assessment stage. At this gate the investment committee’s decision is whether to approve the initiation of the programme.
  • Strategic gate The investment committee’s decision is whether to release funds for the development of a preliminary business case.
  • Preliminary gate The investment committee’s decision is whether to release funds for the development of a final business case.
  • Procurement gate The investment committee’s decisions are whether to commit to funding the Build stage (since once tenders are called there is a certain obligation to proceed given the costs that tenderers will incur), to approve the procurement strategy, and release funds for the procurement stage.
  • Contract award gate The investment committee’s decision is whether to proceed with the award of any external contract and whether to release funds for the Build stage.
  • Readiness-for-service gate The investment committee’s decision is whether to approve the outputs of the investment entering service at the specified time.

Clearly, each organization adjusts the investment lifecycle and investment gating process to best suit its needs.

Note that the investment decision is separate from the decision to approve the business case. The latter is made by the project or programme board on the basis of whether the project or programme is justified. The investment decision is not about project justification, but whether it is in the strategic interests of the organization to invest in that project as opposed to channelling those funds to a different purpose.

Accountability for the success of the portfolio should normally lie with the chief executive officer (CEO). Ideally the CEO should chair the portfolio board but in reality, that responsibility is often delegated to another member of the investment committee.

6 Variously known as investment committee, portfolio management committee/group, portfolio direction group etc.

Issues that may arise

The arrangements described in section 7 represent a model. There will be very few organizations that do not have to modify or adjust these arrangements to make them useful in their particular environment. What should remain constant in virtually any environment are the principles concerning accountability, as described in section 6. The following section describes some of the situations in which organizations may find themselves when developing governance arrangements.

Resourcing the project executive or programme SRO

Organizations with large capital programmes often create divisions that specialize in delivery. A common example of this is the establishment of a ‘major projects’ group within an infrastructure-intensive organization. This division is often resourced with project professionals who have been attracted from across the organization. A potential problem with this is that project executives and programme SROs are seldom members of this major projects group because, as discussed in section 6, project executives and SROs tend to be drawn from those areas with accountability for the service outcome that the change is intended to achieve (which is a different area of the organization from the major projects group). The project executive or programme SRO is effectively the customer of the major projects group and it’s important for the business that they act in a sophisticated and discerning way. They therefore require resources to help develop those aspects of the change that relate to the service outcome – areas such as the business case, benefits, service requirements, and the assurance functions that support these. However, with most project expertise stripped from their area (having been attracted to the major projects group), they may not have the resources to fulfil that role effectively. In the absence of customer-focused resources, the vacuum in these areas will be filled by the major projects group and they are not usually best placed to define such business areas. The outcome may therefore be sub-optimal.

This situation is apt to arise when organizations use a purchaser/provider arrangement (as was mentioned in section 6) since that business model may appear to encourage a handover of responsibility, even accountability, for the project from the customer (purchaser) to the supplier (provider) in the organization. This, in turn, encourages project-focused resources to migrate to the provider side of the business.

Organizations should therefore recognize that the project executives and SROs in the organization must be provided with project resources in order to act as sophisticated customers, and that this may require procurement of additional resources.

Project executive or programme SRO knowledge gap

Organizations can find themselves in the situation where the project executive or programme SRO lacks some of the skills required to undertake the role effectively. They may be the right choice from the perspective of owning the service outcome and therefore best placed to own the project that will deliver that outcome, but not have either the necessary technical skills or the project/programme delivery skills. Such situations may arise, for instance, when a department is introducing a major ICT change and the project executive or programme SRO does not have the ICT knowledge or skills to deliver it. In these circumstances, the answer lies in supporting the project executive or SRO rather than changing the person in the role.

Some organizations do this by introducing the role of project or programme director. This role acts as the eyes and ears of the project executive or programme SRO and focuses on the business perspective while the project manager or programme manager maintains more of a delivery focus. The latter positions normally report to the director role. One way of looking at the relationship between project/programme directors and project/programme managers is that the former spend more time managing upwards to the SRO and the business, while the latter concentrate on managing downwards into the project or programme. Clearly the director role must have strong delivery credentials and their allegiance must be to the project executive or programme SRO.

Programme and project board size

On large programmes and projects, the committee size often grows to accommodate the increasing number of stakeholders – and this is the issue. A project or programme board is primarily a decision-making forum under the definition of capital investment governance described at the beginning of this paper. Usually, large project or programme boards indicate that this purpose has been overlooked and that the board is trying to serve two purposes: decision-making and stakeholder management. The solution is to recognize these as separate activities and to establish separate, although linked, mechanisms to address each. One mechanism for addressing this is provided by Garland (2009) in his book, Project Governance: A Practical Guide to Effective Project Decision Making.

Projects should normally be able to limit project board numbers to around six. If a project struggles to achieve this, it may be because it is actually a programme with a number of related projects. It can be difficult to limit programme board numbers to six since there are necessarily more key stakeholders and perhaps more than one funding party. While there are no hard-and-fast rules, more than 10 in a meeting tends to reduce its effectiveness, assuming all are participating in the business of the meeting.

Too many project boards and not enough SROs

In many organizations, trying to establish a PRINCE2 project board for every project will result in managers spending an inordinate amount of time in project board meetings. Also, some managers will find themselves nominated as project executive or SRO for more projects than they can deal with. Organizations should consider the following options:

  • The number of project boards can obviously be reduced by combining a number of projects under a single project board. The issue is ensuring the right representation on the board to address the needs of each project, without the board becoming too large. The key person, the SRO, is clearly not an issue since they are the common factor on each project. Resist the urge to combine projects under a common board if they do not share a common SRO according to the guidelines of section 6. It will often be the case that senior user and senior supplier roles have some commonality across the projects. Of course, there is an argument that says that this approach isn't actually saving any time since the same matters have to be addressed and whether that happens at one meeting or many is immaterial. The reality is somewhat different – it does save time and it forces greater focus on management by exception and time-keeping.
  • Organizations such as utilities and councils, which often have numerous small projects, can establish one or more standing project boards, where the same members are required for multiple projects.
  • Another option for reducing the workload on SROs is to push accountability for smaller projects to lower levels in the organization. However, it is still best to ensure that the accountability for the project is matched to accountability for the service outcome.
  • Use a tiered system for categorizing projects. At its simplest it can be capital-cost-based although a risk-based framework is better – a capital-cost-based tiering is just a proxy of risk in any case. Lower-tier projects can be governed with less rigour.

Handover of accountability

Ideally, the project executive or programme SRO should hold that role for the duration of the project or programme. This isn’t always possible and on long programmes there may be changes of personnel. Too many changes will most definitely adversely affect the programme. If it can’t be avoided, it may be as well to have a formal handover of accountability, where the key documentation is ‘baselined’ at that time.

Sometimes too, the organization’s business model necessitates accountability being transferred from one part of the organization to another – for instance, from planning to service delivery. In the early planning phases, the service outcome may be owned by the planning function, making them the logical project/programme owners. As the planning progresses closer to implementation, it may be more appropriate for the part of the business that will use the completed project to deliver the service outcome to assume the mantle of accountability. Such a handover can best be managed by observing a few ‘rules’:

  • Accountability should always follow the ownership of the service outcome. It is unlikely, for instance, that accountability would transfer to an ICT delivery group or the construction arm of a business since they do not logically own the service outcome.
  • The handover should be formal, with a formal handover of key documentation.
  • The makeup of the governance body should reflect the new arrangements. Almost certainly, the party that relinquished accountability should remain on the governance body to support the new owner.

Conclusion

Capital investment governance, or the integrated governance of portfolios, programmes and projects, is the framework that enables effective capital investment decision-making. This framework is built around three fundamental concepts:

  • Clarity of accountability and a clear line of sight of accountability from the portfolio level, through the programme level, to individual projects
  • Clarity and commonality of ownership of the service outcome to be delivered by the change, the change itself, its budget and the change business case
  • Clarity of decision rights at each level in the capital investment governance framework.

These concepts must be underpinned by a logic and rationale that resonates with organizations and their management in order to ensure support for the uptake of the governance framework.

Such a framework will provide senior executives with visibility and control of the organization’s investments which in turn will encourage them to continue to use effective capital investment governance.

References

Cabinet Office (2011). Managing Successful Programmes, The Stationery Office, London.

Cabinet Office and HM Treasury (2011). Major Project Approval and Assurance Guidance.

Garland, R (2009). Project Governance – A Practical Guide to Effective Project Decision Making. Kogan Page, London.

National Audit Office (2010) Assurance for High Risk Projects.

Office of Government Commerce (2005). Common Causes of Project Failure (a website authored by the OGC, accessed in February 2011).

Office of Government Commerce (2008). Portfolio, Programme and Project Offices. The Stationery Office, London.

Office of Government Commerce (2009). Managing Successful Projects with PRINCE2. The Stationery Office, London.

Office of Government Commerce (2011). Management of Portfolios. The Stationery Office, London.

Queensland University of Technology (2010). Creating Value in Project Management using PRINCE2. Sponsored by APM Group Ltd, OGC and TSO.

Acknowledgements

Much of the content in sections 5, 6, 7 and 8 draws from Ross Garland’s book, Project Governance – a Practical Guide to Effective Project Decision Making (Garland, 2009).

Figures 3, 4, and 6 and their accompanying descriptions are reproduced with permission from content developed by Ross Garland & Associates Pty Ltd.

This White Paper is sourced by TSO and published on www.best-management-practice.com

Our White Paper series should not be taken as constituting advice of any sort and no liability is accepted for any loss resulting from use of or reliance on its content. While every effort is made to ensure the accuracy and reliability of the information, TSO cannot accept responsibility for errors, omissions or inaccuracies. Content, diagrams, logos and jackets are correct at time of going to press but may be subject to change without notice.

© Copyright TSO. Reuse of this White Paper is permitted solely in accordance with the permission terms at http://www.best-management-pra...

A copy of these terms can be provided on application to Best Management Practice White Paper Permissions, TSO, St Crispins, Duke St, Norwich, Norfolk, NR3 1PD, United Kingdom.