7
Organization
This chapter covers:
•the key roles for an effective organization
•the four levels of project management
•the difference between PRINCE2 roles and job titles
•the importance of stakeholders and communication
•PRINCE2’s requirements for the organization theme
•guidance for effective project organization
7 Organization
Key message
The purpose of the organization theme is to define and establish the project’s structure of accountability and responsibilities (the who?).
Every project needs effective direction, management, control and communication. Establishing an effective project management team structure and approach for communication at the beginning of a project, and maintaining these throughout the project’s life, are essential elements of a project’s success.
For this reason, one of PRINCE2’s principles is that projects must have defined and agreed roles and responsibilities within an organization structure that engages the business, user and supplier stakeholder interests.
Definition: Stakeholder
Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, an initiative (i.e. a programme, project, activity or risk).
In order to be flexible and meet the needs of different environments and different project sizes, PRINCE2 defines a set of roles that need to be undertaken, together with the responsibilities of each of those roles. PRINCE2 does not define jobs to be allocated to people on a one-to-one basis. Roles can be shared or combined according to the project’s needs, but the responsibilities must always be allocated.
PRINCE2 identifies three principal categories of project stakeholders (business, user and supplier; see Figure 7.1), although there may be a wide range of other stakeholders with an interest in the project (e.g. government, regulator or unions). Each of the three principal categories of stakeholders has a specific interest in, or viewpoint on, the project, and each category of stakeholders also has specific roles on the project in order to ensure that their interests are met, as detailed below:
•Business The products of the project should meet a business need that justifies the investment in the project. The project should also provide value for money. The business viewpoint therefore should be represented to ensure that these two prerequisites exist before a project commences and remain in existence throughout the project.
PRINCE2 defines an executive role to represent business interests on the project.
•User PRINCE2 makes a distinction between the business interests and the requirements of those who will use the project’s outputs. The user viewpoint represents those individuals or groups for whom some or all of the following will apply:
•they will use the outputs of the project to realize the benefits
•they will operate, maintain or support the project’s outputs
•the outputs of the project will impact them.
The user presence is needed to specify the desired outputs and ensure that the project delivers them through the supplier.
PRINCE2 defines a senior user(s) role to represent user interests on the project.
•Supplier The creation of the project’s outputs will need resources with certain skills. The supplier viewpoint should represent those who will provide the necessary skills and produce the project product.
The supplier needs to have an understanding of all the relevant standards with which the output (product) needs to comply, and the project may need to use both in-house and external supplier teams to construct the project product.
PRINCE2 defines a senior supplier(s) role to represent supplier interest on the project.
In PRINCE2, the business, user and supplier interests are brought together on the project board, which is accountable for the success of the project (see section 7.2.1.1).
A successful project management team should:
•have business, user and supplier stakeholder representation
•ensure appropriate governance by defining responsibilities for directing, managing and delivering the project and clearly defining accountability at each level
•review the project roles throughout the project to ensure that they continue to be effective
•have an effective approach to manage communication flows to and from stakeholders.
Managers at the level required to make decisions and commitments may be too busy to be involved on a day-to-day basis with the project. However, projects need day-to-day management if they are to be successful. PRINCE2 separates the direction and management of the project from the delivery of the project’s outputs, concentrating on the former and using the principle of manage by exception.
The project management structure has four levels, three of which represent the project management team and a fourth that sits outside the project. Figure 7.2 illustrates these four levels of management.
The four levels of management are:
•Corporate, programme management or the customer This level sits above the project management team but will be responsible for commissioning the project, including identifying the executive and defining the project-level tolerances within which the project board will work. This information should, if possible, be recorded in the project mandate.
•Directing The project board is responsible for the overall direction and management of the project within the constraints set out by corporate, programme management or the customer. The project board is accountable for the success of the project (see section 7.2). As part of directing the project, the project board will:
•approve all major plans and resources
•authorize any deviation that exceeds or is forecast to exceed stage tolerances
•approve the completion of each management stage and authorize the start of the next management stage
•communicate with other stakeholders.
•Managing The project manager is responsible for the day-to-day management of the project within the constraints set out by the project board. The project manager’s prime responsibility is to ensure that the project produces the required products in accordance with the time, cost, quality, scope, benefits and risk performance goals (see section C.5).
•Delivering Although the project manager is responsible for the day-to-day management of the project, team members are responsible for delivering the project product and its components to an appropriate quality within a specified timescale and cost. Depending on the size and complexity of the project, the authority and responsibility for planning the creation of certain products and managing a team of specialists to produce those products may be delegated to a team manager, who is accountable to the project manager (see section C.6).
There will be a wider range of stakeholders which may affect, or be affected by, the project. These stakeholders may be internal or external to the corporate, programme management or customer organization and may:
•support or oppose the project
•gain or lose as a result of project delivery
•see the project as a threat or enhancement to their position
•become active supporters or blockers of the project and its progress.
It is important to analyse who these stakeholders are and to engage with them appropriately. Effective engagement with these stakeholders is key to a project’s success (see section 7.3.9).
Example of stakeholder identification
Stakeholder analysis identified the following stakeholders for a project to relocate a chemical factory:
•a number of unions
•an environmental pressure group
•an industry regulator
•a number of corporate, programme management or customer functions (e.g. internal audit, finance, legal)
•the external contractor
•some members of the public affected by the project.
Note that some of these were external to the project management team but internal to the corporate, programme management or customer organization.
7.2 PRINCE2’s requirements for the organization theme
To be following PRINCE2, a project must, as a minimum:
•define its organization structure and roles. This must minimally ensure that all of the responsibilities in PRINCE2’s role descriptions are fulfilled (PRINCE2’s defined roles and responsibilities principle)
•document the rules for delegating change authority responsibilities, if required
•define its approach to communicating and engaging with stakeholders.
PRINCE2 requires that two products are produced and maintained for the organization theme:
•PID In the context of the organization theme, this provides the single source of reference for how the project is to be managed. The PID sets out the project management team structure and roles.
•Communication management approach This describes the means and frequency of communication to stakeholders both internal and external to the project.
Both these products should be created during the initiating a project process.
Appendix A (sections A.5 and A.20) provides product descriptions and suggested content for these products.
7.2.1 PRINCE2’s mandated project management team roles
PRINCE2 mandates that certain project roles are fulfilled on every project. As noted below, the roles may be combined within certain limits.
Figure 7.3 shows the mandated roles within an illustrative project team structure. Even though the project roles are mandated, the structure is not and is provided only as an example.
Appendix C provides details of these roles and their associated responsibilities. For a specific project these role descriptions should be tailored and supplemented to include information that specifies the responsibilities, goals, limits of authority, relationships, skills, knowledge and experience required. PRINCE2 uses the term ‘project team’ to cover the project management team and everyone else working on the project.
All PRINCE2 projects must have a project board. The project board has authority and responsibility for the project within the instructions (initially contained in the project mandate) set by corporate, programme management or the customer.
The roles and responsibilities of the project board are described in Appendix C, section C.1. They include:
•being accountable to the business, user and supplier interests for the success or failure of the project
•providing unified direction to the project
•delegating, using the PRINCE2 organizational structure and controls designed for this purpose
•facilitating integration of the project management team with the functional units of the participating corporate, programme management or customer organizations
•providing the resources and authorizing the funds necessary for the successful completion of the project
•effective decision-making
•providing visible and sustained support for the project manager
•ensuring effective communication both within the project team and with external stakeholders.
PRINCE2 requires that the project board always represents business, user and supplier interests. This is usually done through the executive, senior user and senior supplier, although PRINCE2 does not require three people on every project board. On smaller/simpler projects some of the roles may be combined.
Although the project board has collective responsibility for the project, the executive, supported by the senior user(s) and senior supplier(s), is ultimately accountable for the project’s success and is the key decision maker. The project board is not a democracy controlled by votes.
The executive’s role is to ensure that the project is focused throughout its life on achieving its objectives and delivering a product that will achieve the forecasted benefits. The executive has to ensure that the project gives value for money, ensuring a cost-conscious approach to the project, balancing the demands of the business, user and supplier.
The executive is appointed by corporate, programme management or the customer during the pre-project process of starting up a project. The role of the executive is vested in one individual, so that there is a single point of accountability for the project. The executive will then be responsible for designing and appointing the rest of the project management team, including the other members of the project board. If the project is part of a programme then corporate, programme management or the customer may appoint some or all of the project board members.
The executive secures funding for the project and is responsible for the business case and continued business justification of the project.
The senior user is responsible for specifying the needs of those (including operations and maintenance services) who will use the project product for user liaison with the project management team and for monitoring that the solution will meet those needs within the constraints of the business case in terms of quality, functionality and ease of use.
The role represents the interests of all those who will use the project product, those for whom the product will achieve an objective, or those who will use the product to deliver benefits. The senior user role commits user resources and monitors products against requirements. For the sake of effectiveness the role should not be split between too many people.
The senior user(s) specifies the benefits and is held to account by demonstrating to corporate, programme management or the customer that the forecasted benefits that were the basis of project approval are in fact realized. This is likely to involve a commitment beyond the end of the project’s life.
If necessary, more than one person may be required to represent the users.
The senior supplier represents the interests of those designing, developing, facilitating, procuring and implementing the project product.
This role is accountable for the quality of products delivered by the supplier(s) and is responsible for the technical integrity of the project. This role will include providing supplier resources to the project and ensuring that proposals for designing and developing the products are feasible and realistic.
In many cases, the senior supplier also represents the interests of those who will provide the maintenance services for the specialist products after closure of the project (e.g. engineering maintenance and support). Exceptions to this do occur, however (e.g. when the maintenance services are provided by the customer organization, such as an internal IT department, or are outsourced to a different supplier). In this instance the operations and maintenance interests are more likely to be represented by a senior user. In fact, the distinction is not really important; what matters is that operations, service and support interests are represented appropriately from the outset.
If necessary, more than one person may be required to represent the suppliers.
The project board is responsible, via its project assurance role, for monitoring all aspects of the project’s performance and products independently of the project manager.
Project board members are responsible for the aspects of the project assurance role aligned with their respective areas of concern (business, user or supplier). If they have sufficient time available, and the appropriate level of skills and knowledge, they may conduct their own project assurance tasks; otherwise they may appoint separate individuals to perform these.
The project board may also make use of other members of the corporate, programme management or customer organization to take on specific project assurance roles, such as appointing the corporate quality manager to monitor the quality aspects of the project. Project board members are accountable for the project assurance actions aligned with their area of interest, even if they delegate these to separate individuals.
Project assurance is not just an independent check, however. Personnel involved in project assurance are also responsible for supporting the project manager, by giving advice and guidance on issues such as the use of corporate standards or the correct personnel to be involved in different aspects of the project (e.g. quality inspections or reviews).
When project assurance tasks are shared between project board members and other individuals, it is important to clarify each person’s responsibilities. Anyone appointed to a project assurance role reports to the project board member overseeing the relevant area of interest, and must be independent of the project manager. The project board should not assign any project assurance roles to the project manager or project support.
As part of its function to monitor all aspects of the project’s performance and products independently of the project manager, project assurance should be involved in all the PRINCE2 processes.
One consideration at project initiation should be who is permitted to authorize requests for change or off-specifications. It is the project board’s responsibility to agree to each potential change before it is implemented. In a project where few changes are envisaged, it may be reasonable to leave this authority in the hands of the project board. But projects may be in a dynamic environment, where there are likely to be, for example, many requests to change the initial agreed scope of the project. Technical knowledge may also be needed to evaluate potential changes.
If it has not already been determined within starting up a project, the project board needs to decide, before the project moves out of the initiating a project process, if it wishes to delegate some authority for approving or rejecting requests for change or off-specifications. These delegated authorities must be written into the appropriate role descriptions. For projects that exist within a programme, the programme management should define the level of authority that the project board will have in order to be able to approve changes.
The project manager and/or the people with delegated project assurance responsibilities may act as the change authority. Refer to Chapter 11 for more information on change.
The project manager is the single focus for day-to-day management of a project. This person has the authority to run the project on behalf of the project board within the constraints laid down by the project board. The role of the project manager must not be shared.
The project manager will usually come from the corporate, programme management or customer organization, but there may be projects where the project manager comes from the supplier. Refer to section 7.3.4 for more information on roles in the context of customer/supplier relationships.
The project manager is responsible for the work in all the PRINCE2 processes except for the directing a project process, and appointing the executive and the project manager in the pre-project process of starting up a project. The project manager also delegates responsibility for the managing product delivery process to the team manager(s).
The project manager manages the team managers and project support, and is responsible for liaison with project assurance and the project board. In projects with no separate individual allocated to a team manager role, the project manager will be responsible for managing work directly with the team members involved. In projects with no separate project support role, the support tasks also fall to the project manager, although they may be shared with team members.
As the single focus for the day-to-day management of a project, there are many different aspects to the project manager role, some of which are shown in Figure 7.4.
The team manager’s primary responsibility is to ensure production of those products allocated by the project manager. The team manager reports to, and takes direction from, the project manager.
The team manager role may be assigned to the project manager or a separate person. There are many reasons why the project manager may decide to appoint other people to be team managers rather than undertake the role themselves. Among these are the size of the project, the particular specialist skills or knowledge needed for certain products, geographical location of some team members and the preferences of the project board. The project manager should discuss the need for separate individuals as team managers with the project board and, if required, should plan the role at the start of the project during the starting up a project process, or for each management stage in the preceding managing a stage boundary process.
The project manager uses work packages to allocate work to team managers or team members. They can be used formally or informally depending on the needs of the project. Defining the deliverables at the appropriate level will assist new team managers in becoming more effective as it is clear what has to be produced and, with the definition of reporting frequency and method, the feedback from the team manager can be clearly controlled.
If the team manager comes from the supplier organization, there could be a reporting line to a senior supplier. It is vital that any such links are understood to avoid conflicts of interest and any undermining of the project manager’s authority.
The structure of the project management team does not necessarily reflect line function or seniority but represents roles on the project. A team manager, for example, may be more senior in the corporate, programme management or customer organization than the project manager, or may be a senior representative from an external supplier. In the context of the project, however, the team manager reports to, and takes direction from, the project manager.
Project support is the responsibility of the project manager. If required, the project manager can delegate some of this work to a project support role: this may include providing administrative services or advice and guidance on the use of project management tools. It could also provide specialist functions to a project such as planning or risk management. Unless performed by a corporate, programme management or customer function, project support is typically responsible for administering change control.
The role of project support is not optional, but the allocation of a separate individual or group to carry out the required tasks is. The role defaults to the project manager if it is not otherwise allocated.
Key message
Project support and project assurance roles must be kept separate in order to maintain the independence of project assurance.
Some corporate, programme management or customer organizations may have a project office (a temporary office set up to support the delivery of a specific project) or a similar structure, which can fulfil some, or all, of the project support role. For more information on the use of a project office, see Portfolio, Programme and Project Offices (Cabinet Office, 2013).
PRINCE2 allows the above roles to be combined within the following constraints:
•the executive and project manager roles cannot be combined
•there cannot be more than one executive or project manager
•the executive’s accountability for project success cannot be delegated
•the project board should not assign any project assurance roles to the project manager, team manager or project support.
When combining roles, the project board should consider any conflicts of responsibilities, whether one person has the capacity to undertake the combined responsibilities, and whether any bottlenecks might be created as a result. Also, it is not recommended to combine the roles of senior user and senior supplier as this can create conflicts of interest for an individual.
PRINCE2 provides role description outlines in Appendix C, and they should be tailored to the needs of the specific project and each specific appointment. In addition, each theme chapter provides the responsibilities relevant to that theme.
7.2.2 The communication management approach
The communication management approach contains a description of the means and frequency of communication to parties both internal and external to the project. It facilitates engagement with stakeholders through the establishment of a controlled and bidirectional flow of information. Where the project is part of a programme, the communication management approach should align with the programme’s approach to stakeholder communication and engagement.
The project manager is responsible for documenting the communication management approach during the initiating a project process. It is also important to review and possibly update the communication management approach at each management stage boundary in order to ensure that it still includes all the key stakeholders. When planning the final management stage of the project it is also important to review the communication management approach to ensure it includes all the parties who need to be advised that the project is closing.
During a project, corporate management, programme management or the customer retains control by receiving project information as defined in the communication management approach and taking decisions on project-level exceptions escalated by the project board.
7.2.3 Organization responsibilities in PRINCE2
Responsibilities for organization in PRINCE2 are set out in Table 7.1. If roles are combined then all the responsibilities in this table must still be undertaken.
Table 7.1 Responsibilities relevant to the organization theme
Rolea |
Responsibilities |
Corporate, programme management or the customer |
Appoint the executive and (possibly) the project manager. Provide information to the project as defined in the communication management approach. |
Executive |
Appoint the project manager (if not done by corporate, programme management or the customer). Confirm the appointments to, and structure of, the project management team. Approve the communication management approach. |
Senior user |
Provide user resources. Define and verify user requirements and expectations. |
Senior supplier |
Provide supplier resources. Advise on the technical aspects of the proposed products. |
Project manager |
Prepare and update the communication management approach. Design, review and update the project management team structure. Plan and undertake stakeholder engagement. Prepare role descriptions. |
Team manager |
Manage project team members. Advise on project team members and stakeholder engagement for their part in the project. |
Project assurance |
Advise on selection of project team members. Advise on stakeholder engagement. Ensure that the communication management approach is appropriate and that planned communication activities actually take place. |
Project support |
Provide administrative support for the project team. |
a Note that change authority is an optional role and has not been included in this table.
7.3 Guidance for effective project organization
Ensure that the organizational structure of the project team is suitable for the size, scale and complexity of the project.
‘Organization’ is the PRINCE2 theme most affected by project size, scale and complexity. The right people with the right experience need to be in the right roles, in the right numbers and at the right time.
Roles and responsibilities need to be carefully considered for all projects. Standard role description outlines will need to be tailored to match each individual’s actual capability and authority in the context of the project role they will be undertaking.
For smaller, simpler projects, the primary concern often is how to ensure that all PRINCE2 responsibilities are fulfilled by a relatively small set of people. Some points to consider include:
•Scaling the project management team is primarily about consolidating role and function. Roles can be combined but should not be eliminated.
•As the executive and senior user roles are both from the customer environment, these can often be combined.
•As the project manager is likely to be much closer to the project board than on larger, more complex projects, members of the project board are often in a better position to carry out their own project assurance rather than appointing another individual to fulfil this role.
•For small teams it may not be necessary to appoint team managers. The project manager of a simple project can carry out those responsibilities.
Typically, on a larger, more complex project, responsibilities will be distributed among a larger set of people, with some roles and responsibilities being shared. For example, there may be multiple senior users. In such circumstances, the primary concern is ensuring that individual accountabilities, limits of delegation and authority, and governance are absolutely clear.
7.3.2 Project organization in an organizational environment
Whether or not a project forms part of a programme or portfolio, it will always exist within both an organizational environment and a wider context. Corporate organizational structures can range from ‘traditional’ functional structures to project-focused corporate organizations and variations in between. In the ‘traditional’ functional structure, staff are organized by type of work (e.g. marketing, finance and sales) and there are clear reporting lines. In contrast, the standard practice in project-focused corporate organizations is to work with project teams.
The level of overlap between the interests of the business, user and supplier stakeholders will change according to the type of corporate, programme management or customer organization and project. For example, there are likely to be more overlapping interests between the business and an in-house supplier than an external supplier.
7.3.3 Projects within a programme
A project can be run as a stand-alone entity or can be part of a programme of related projects (see section 2.5.2). A project which forms part of a programme may be impacted by the programme structure and its various reporting requirements.
The programme and project management team structures and roles need to be integrated such that:
•there are clear lines of responsibility and accountability from top to bottom, and duplication is avoided
•reports and reviews are efficient (e.g. projects within a programme that have common project board members could align stage boundaries, and meet collectively to conduct end stage assessments for all the projects as part of a programme review).
The integration of roles may involve the following:
•The programme manager may be the executive for one or more of the projects.
•Within a programme, there may be multiple project boards, a single body directing several projects (effectively replacing multiple project boards) or a combination of the two.
•A business change manager from the programme may fulfil the project role of senior user (or have input into the appointment of the senior user) for one or more of the projects, or be the executive for one or more of the projects.
•The programme’s design authority (if used) may fulfil the project role of change authority or project assurance for one or more of the projects. The purpose of a design authority at a programme level is to ensure that there is appropriate alignment and control when changes are being planned and implemented.
•A single programme office may take project support responsibilities for all projects.
Programme manager, business change manager and design authority are defined in Managing Successful Programmes (Cabinet Office, 2011) and fulfil programme-level requirements.
What are the roles of business change manager and design authority?
The business change manager is responsible for benefits management from identification through to realization, and for ensuring that the implementation and embedding of the new capabilities are delivered by the projects. The business change manager is a senior role drawn from the area of the business affected by the programme.
The design authority provides expert advice about, and may have responsibility for, some corporate function, service, standard or strategy that will be affected by the programme.
The choice of project structure and appointments will depend on the needs, complexity and scale of the programme. It is the programme manager’s responsibility to assess the pros and cons of the choice of organization structure, and appointments need to be evaluated along with their consequences.
The project’s communication management approach should be aligned with the programme’s stakeholder engagement strategy, with communications being controlled and scheduled as part of the programme communications plan. Stakeholder analysis for the project may be performed by the programme, or the programme may require the project to take a lead with certain stakeholder groups with which it has good engagement.
7.3.4 Projects operating in a commercial environment
There are numerous ways to structure the project management team roles in a commercial customer/supplier context. The aim is to ensure that both organizations establish and maintain sound business justification for their work and that their individual governance is respected. It is important that the project manager has a good understanding of their obligations under any contract with the supplier organization. In PRINCE2, the project manager will normally come from the customer organization. The supplier’s staff may fulfil some of the team manager roles for the project, and they may even be called ‘project managers’ in the supplier’s organization.
There may be projects where the project manager comes from the supplier’s organization. The customer may choose to stay at a distance from the working level and expect the supplier to provide the management of the project. The customer is likely to increase the rigour in project assurance (and indeed may choose to appoint one of its own staff to fulfil the role of project assurance).
Tip
Be careful not to confuse job titles and PRINCE2 roles. A person with the job title ‘project manager’ may not be undertaking the PRINCE2 project manager role. For example, a person from a supplier organization may have the title of ‘project manager’, but might be undertaking the team manager role for a specific project.
It helps to ensure that job titles are mapped to PRINCE2 roles, and that responsibilities for each role are clear and recorded in the PID.
Ensure that every member of the project team understands their project responsibilities regardless of their job title and description.
There may be a joint project board with representatives from the customer and all the suppliers that the customer has engaged. The executive on this joint project board may be supplied by the customer and the senior suppliers will represent each of the suppliers.
The supplier may treat their work package(s) within the customer’s project as a project within the supplier’s organization. This may mean establishing a separate ‘supplier project board’. The relationship between any such boards and the customer’s project board should be defined.
If there are multiple suppliers, all of them may be represented on the project board as it provides a forum for them to integrate direction and decision-making. If there are more than three or four suppliers, however, then it will be typically more effective for the contracts manager responsible for the performance of all the supplier contracts to sit on the project board on their behalf, or it may be appropriate to appoint a prime contractor.
During procurement, the project may need a temporary appointment from within the customer organization (say, from its procurement team) for the senior supplier role until a supplier has been appointed.
7.3.5 Projects using an agile approach
Understanding of the additional delivery-level roles may be needed, and these agile roles should be mapped, as appropriate, to the roles of the project management team structure. The project manager will need to understand:
•how a self-organizing delivery team operates and how this relates to the team manager and change authority roles
•the responsibilities of roles in the agile approach being used
•that, in an agile environment, the user is often represented by a single person, often referred to as the product owner. However, in the context of a project, a wider view of the customer is likely to be needed due to the cross-functional nature of projects
•how agile team leaders liaise with the project manager when more than one team is involved.
The use of management by exception is essential to enable PRINCE2 and agile to be combined in the most effective way. This empowers the project management team and enables it to self-organize within clearly defined boundaries.
More details about how to combine PRINCE2 with agile can be found in PRINCE2 Agile (AXELOS, 2015).
7.3.6 Alternative names for PRINCE2 project roles
Role and job title names vary from organization to organization. It does not matter what a role or job is called as long as all the responsibilities outlined in Appendix C are fulfilled on each project.
The responsibilities of the jobs and roles may also vary; for example, a senior project manager in one organization may actually be performing portfolio management activities or overseeing project managers. Some examples of commonly used alternative terminology are:
•‘sponsor’ or ‘senior responsible owner (SRO)’ instead of executive
•‘business change manager’ instead of senior user
•‘PMO’ instead of project support
•‘work package manager’ instead of team manager.
What is a PMO?
This is a commonly used abbreviation for the office an organization may set up to provide support and other services for its programmes and projects. It is variously called the programme management office, portfolio management office or project management office. It may also be viewed by progressive organizations as a centre of excellence. For more information, see Portfolio, Programme and Project Offices (Cabinet Office, 2013).
7.3.7 Creating an effective project board
A good project board should display four key characteristics:
•Authority The members of the project board should be senior enough within the corporate, programme management or customer organization to make strategic decisions about the project. As the project board is accountable for the project, the individuals chosen must have sufficient authority to make these decisions and to provide resources to the project, such as personnel, cash and equipment. The managerial level required to fill the roles will depend on factors such as the budget, scope and importance of the project.
•Credibility The credibility of the project board members within the corporate, programme management or customer organization will affect their ability to direct the project.
•Ability to delegate A key part of the project board’s role is to ensure that the project manager is given enough ‘space’ to manage the project by keeping project board activity at the right level. Project board members should not be involved in the detail of how the project is managed.
•Availability Project board members who meet all the above characteristics are of little value to the project if they are not available to make decisions and provide direction to the project manager.
The executive, supported by the project manager, is responsible for agreeing a suitable team structure and tailoring it to the project’s size, risk and complexity. The project board needs to represent all the interested parties in the corporate, programme management or customer organization, and involve any suppliers (internal or external) that have been identified.
On a complex project, tailoring the project management team could mean breaking the PRINCE2 roles into multiple appointments; for example, several senior users or senior suppliers could be appointed. However, 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.
Producing a matrix of stakeholders against the project product also helps split the project stakeholders (who need to be engaged as part of the communication management approach) from the project decision makers (who need to be on the project board).
The decision on whether to include external suppliers on the project board may be a cultural one based on fear of divulging commercial or financial information. Leaving them out of the directing a project process could cause delays due to the lack of supplier resources to deal with change and to address specialist issues. It is the executive’s decision as to how this dilemma is solved practically.
7.3.8 Creating an effective project team
7.3.8.1 Balancing the project, team and individual
People are crucial to the success of a project. It is not enough to have the required processes and systems in place: if the people on a project do not work effectively together, then the chances of the project’s success are severely restricted. Knowledge of different types of personalities and how they affect each other can help the project manager to structure balanced teams that can work together effectively during a project.
Different people have different characteristics and a preference for certain types of work and team roles. There are a number of ways of assessing these preferences (e.g. Belbin team role inventory).
Example of team building using different personalities
Some people are very sociable and enthusiastic, generating many different ideas. Others are more analytical, skilled in detailed work and ensuring no tasks get missed. Although it is not usually possible to change people’s characteristics, it is possible to balance a team so that it has an appropriate mix of personality types to enable tasks to be completed effectively.
Project managers who know the natural roles of the team members can use that knowledge to build effective teams during the starting up a project process for the management team and the initiating a project process when identifying team members.
It is important to achieve the correct balance; for example, a team consisting of only ‘ideas’ people risks losing focus on the detail of tasks which need to be performed. Conversely, a team made up of only ‘details’ people may lack a strategic overview of a solution.
7.3.8.2 Line management/functional management
In a strongly functional environment, project managers can find difficulties when managing cross-functional projects due to the inability to agree overall leadership from within the various groups. As a result, the project board may need to be involved more closely to lead, direct and prioritize work and resolve issues. Whatever the environment, the project manager will have to adapt to, and work within, the corporate organization and this will affect the level of management required for the team members.
Example of a project manager’s responsibilities to line/functional management
The project manager may be responsible for carrying out performance appraisals as part of a project, or may provide input to the appraisal undertaken by the functional area of the corporate organization responsible for the team member.
Understanding and working within the wider corporate organization can be challenging for the project manager, particularly if working part-time or on a contract basis. Setting up clear project controls at the start of the project, and agreeing these with the project board, will help to ensure that the project manager understands the level of interaction and support to expect during the project and is given appropriate exposure to other areas of the corporate organization.
7.3.8.3 Training needs for project teams
Project team members may need training to enable them to complete their assigned tasks. This might include training on PRINCE2, specialist training related to their role, or training on the specific processes and standards used on the project.
Project board members may also need training on their roles, including what is expected of them and the procedures needed to carry out their responsibilities. The project manager should ensure that training needs are assessed and built into the appropriate plans.
7.3.8.4 Dealing with changes to the project management team
Ideally, the project manager and project board members should stay with the project throughout its life. In practice, however, this may not always be possible and the project management team and suppliers may change during the project. A clearly defined team structure, together with comprehensive role descriptions outlining the responsibilities for each role, should help to alleviate disruption caused by project management team changes.
The use of management stages also allows a smooth transition for changes to the project management team. Project roles should be reviewed for the next management stage during the managing a stage boundary process. The use of end stage reports and stage plans can help to ensure that any handover procedure is thorough and well documented. Although ideally the executive and project manager should stay with the project throughout its lifecycle, a management stage boundary provides an opportunity to hand over the role during the project if this is necessary.
Example of changes to the project management team
A project may include a procurement step, during which a supplier is selected to develop some of the components of the project product. Before the supplier has been selected, a senior representative from the procurement department may be appointed as the senior supplier on the project. After the supplier has been selected and the project moves to the design step, a senior representative from the selected supplier’s organization could be included on the team as a senior supplier.
Project teams are brought together for the duration of a project and then return to their routine work. The manager of a small project is therefore likely to find that team members are working on the project on a part-time basis. Part-time team members suffer more absences and diversions, as a percentage of their working time, than full-time team members. The project manager should allow for this when designing a plan, either by negotiating guaranteed availability or greater tolerance.
If individuals are tasked with working on too many projects, they may simply stand still on all the projects, expending a lot of effort but making no forward progress. Solutions include undertaking fewer projects in parallel or, if possible, allocating staff full time to projects for limited periods.
Stakeholder engagement is the process of identifying and communicating effectively with those people or groups who have an interest in or influence on the project’s outcome. It is usually carried out at the programme level. All projects need to have some level of stakeholder engagement, particularly if not part of a programme.
Parties external to the project management team can exert a powerful influence on a project. Effective communication with key stakeholders, both internal and external to the corporate, programme management or customer organization, is essential to the project’s success.
Example of stakeholder engagement
Managing Successful Programmes (Cabinet Office, 2011) identifies the following six-step procedure for stakeholder engagement:
•Identifying stakeholders (Who?) Identifying the individual stakeholders involved in, or affected by, the project and perhaps grouping similar stakeholders together so that key messages can be targeted effectively.
•Creating and analysing stakeholder profiles (Why and What?) Gaining an understanding of the influences, interests and attitudes of the stakeholders towards the project and the importance and power of each stakeholder. For instance, is a particular group likely to be negative, irrespective of the message, and therefore require particular care? Stakeholders’ influence and interests, whether rational or emotional, must all be taken into account. They have the potential to affect the success of the project. Perceptions may be mistaken, but they must be addressed. The stakeholders’ perceptions of the benefits should be quantified where possible.
•Defining the stakeholder engagement approach (How?) Defining how the project can effectively engage with the stakeholders, including defining the responsibilities for communication and the key messages that need to be conveyed. For each interested party, agree the:
•information the party needs from the project
•information the party needs to provide to the project
•method, format and frequency of communication
•sender and recipient of the communication.
•Planning the engagements (When?) Defining the methods and timings of the communications. These are best planned after defining how the project will engage with the different stakeholders. When selecting the senders of information, it is important to select communicators who have the respect and trust of the audience. Their position in the corporate, programme management or customer organization and expertise in the subject matter will greatly influence their credibility. Many projects have a formal commencement meeting to introduce the project and its aims to the corporate, programme management or customer organization. If this type of meeting is used, it is important that the members of the project board attend to show their support and commitment to the project.
•Engaging stakeholders (Do) Carrying out the planned engagements and communications. The first two steps in stakeholder engagement (identifying and analysing) also engage stakeholders to some degree.
•Measuring effectiveness (Results) Checking the effectiveness of the engagements. Project assurance could be involved in checking all the key stakeholders, their information needs and that the most appropriate communication channels are covered.