Hello and welcome to this Parallel Project Training podcast. This podcast is linked to the APM PMQ syllabus for exams starting in September 2024. My name is Ruth Phillips, and I’m here today with one of Parallel’s senior trainers, Lisa Regan. We’re going to be discussing governance. Welcome to the podcast, Lisa.
Thank you, Ruth. I’m really pleased to be here today to talk about governance. This is quite a wide-ranging topic. The learning objective in the APM PMQ syllabus for governance arrangements states that we need to understand governance structures as a framework of authority and accountability for project delivery, which aligns with organisational practice. We’ll be exploring these two aspects of governance: what’s happening at an organisational level and how that might affect the project, and how they align with each other.
Okay, so let’s turn our attention to the first learning outcome. This asks us to understand different types of permanent and temporary organisational structures and their features. It also emphasises that an organisation’s governance approach will influence the approach used for a project. So, let’s talk about that. What are the different types of organisational structure that exist?
From the APM’s perspective, it’s the usual options, with something in between. So, I would say option A is the functional structure, option B is the project-based structure, and the matrix is a halfway house. You might hear the terms ‘permanent’ and ‘temporary’. A functional structure is the permanent setup, which is quite stable. You might not even see the job title ‘project manager’ in a functional setup because the functional manager is the person doing the project management. For example, the head of marketing or the head of finance are the people driving the projects in a functional setup. Their functional work drives what they’re doing, and the fact that they’re managing projects is a side role.
Absolutely. So that’s the functional organisation. What’s another type?
The flip side to that is the project organisation. Going back to the classic definition, a project is a unique, transient endeavour, and a project organisation is also transient. It only exists for the duration of the project. People are brought together just to work on a project team, and when the project finishes, that organisation disappears. It’s not a permanent setup at all, but you would definitely have a project manager in this setup.
What type of organisation has a project organisation at its heart?
In my experience, when I worked at a university, they had a whole arm of their organisation that was just project-focused, for example, academic collaboration projects. It lends itself well to consultancy work.
Yes, that makes sense. Whereas the functional setup—my background is in manufacturing—so I recognise the functional setup, with people in, for example, HR reporting to a director of HR. It’s a really straightforward setup.
It’s interesting comparing and contrasting the two, because I get the impression that in a functional organisation, people are aligned along their functions; their specialities are very stable and more hierarchical. Whereas in a project organisation, it’s a lot more flexible. Once that particular project is completed, the structure changes and coalesces around another set of projects.
Yes, absolutely. There are positives and negatives to both. In the functional setup, if you’re a member of staff, you’ve got a clear career path. For example, if you start as a team leader, you might then move to supervisor, and then to head of whatever the structure is. In a project setup, that’s not as clear. You do make progress, but it’s like a snake rather than a straight line. You jump from project to project, and you do make progress, but it’s not as clear-cut. That might appeal to some people who like variety and challenge; it has definite pros and cons.
Yes. So those are either end of the spectrum. What’s the one in the middle?
The one in the middle is the matrix. The matrix setup tries to get the best of both worlds, so you’ve got a temporary team and a permanent team. You’ve got people doing BAU work and people doing project work in the matrix setup. So, you’ve got a mix of skills. Sometimes people struggle to understand if they are in a matrix or a project setup. It all comes down to what happens at the end of the project. If at the end of the project you go back into the organisation or you go straight onto another project within the organisation, you’re in a matrix. If at the end of the project, that’s the end for you—the contract’s finished and you’re not working for that organisation anymore—you’re in a project organisation. So, in a matrix, it’s a halfway house because you’re reporting to two people: a project manager and a functional manager, which can cause confusion. In my previous career, I had one manager saying, ‘Can you do this? It’s urgent,’ and another manager saying, ‘Can you do this? It’s urgent.’ How did I know which one took priority if those two managers weren’t communicating well?
Absolutely. I’m not going to be too down on the matrix. You can have quite a varied workload with a matrix setup. You can be doing some project work and some BAU work, and I guess it also gives you the opportunity to do things outside of your function. From a personal development standpoint, it can be quite helpful.
Yes. Hopefully, that illustrates functional as option A, project as option B, and matrix as an attempt to get the best of both worlds.
How would those structures and the governance approach an organisation takes inform the approach we need to take for our project governance?
With the functional approach, governance is about things being set in stone. You have strict goals, and you’ve got to be in control of what’s going on. Governance is managed within the functions. If you run an organisation that’s got a strong project focus, governance has a different focus because your whole organisation has a different focus. So, yes, governance will be all project-based. It will focus on things like what methodology you use and making sure that your project is aligned with your strategy, which is really important for governance in a project setup.
Absolutely. Whereas in the matrix, it’s a blend. From a governance point of view, you’d have to be able to handle dual reporting. You talked about having a functional manager and a project manager. Governance would have to be well-defined to ensure that you know when and where to escalate, for example, escalation routes. That’s a real cause of conflict in a matrix situation. Depending on your organisation’s governance, it’s about the balance of power between the functions and the project as to what drives the priorities of the governance approach.
Yes, absolutely. So, we’ve talked about organisational structures. Let’s now turn our focus to our project and the roles and responsibilities within project management. Can you talk me through a typical project management structure in terms of project roles and responsibilities?
Yes, absolutely. I’ll start with the steering group. They are usually peers of the sponsor, and they should be at that level of the organisation where they have influence. They can nominate the sponsor, support and advise the sponsor, authorise the business case, own those high-level risks, and influence and manage stakeholders.
Yes, if an issue is raised that the sponsor cannot resolve, the steering group must step in and use their advice and guidance to support the sponsor. So, we’re looking at senior managers within the organisation—people with the authority and credibility to make decisions and support the project sponsor.
Yes, absolutely.
Now, sometimes I have projects that have project boards. Is that the same group of people as a steering group, or is that something different?
I would say it’s the same thing, just different terminology for the same group of people. Would you agree?
Yes, I think so. I can think of one project where I actually had both a steering group and a project board. The distinction for me was that the steering group did just that—they steered but didn’t necessarily make the decisions—whereas the project board had the authority to make decisions. But pretty much they’re interchangeable. I suppose it depends on the size and complexity of the project, doesn’t it?
Exactly. So, you mentioned the sponsor then. What are they responsible for?
The sponsor must be someone higher in the organisation than the project manager. There’s no point in having a sponsor at the same level as the project manager because they need to take escalation from the project manager. With that in mind, the key focus for the sponsor is the business case. They own the business case and the realisation of benefits. So, they’re involved in that extended project lifecycle.
That’s a really important role because all too often the driving force of the project ends once we’ve delivered the outputs, but we’re only halfway there. We haven’t delivered the benefits yet, so the sponsor having that oversight right through to the end of benefit realisation is crucial.
Yes, absolutely. They are the golden thread. We talked about the steering group supporting the sponsor, and the sponsor should support the project manager. They should help the project manager deal with anything escalated, any issues or changes. If the project manager asks for contingency to be drawn down, hopefully, the sponsor will be in agreement and able to authorise that. They should be supporting the project manager in all aspects. So, if there’s any stakeholder conflict, the sponsor can hopefully pull some strategic strings to resolve it.
That’s really important—understanding the need for that separation. For me, the sponsor is a key governance role because it ensures that the project manager isn’t ‘marking their own homework’, to coin a phrase. You’ve got someone else involved who can provide scrutiny, a sounding board, and make decisions that are slightly separate from the day-to-day management.
What always sticks in my mind, Ruth, is something I learned many years ago: there are only two people needed on a project—a project manager and a sponsor. Everything else can be done by the project manager, but you absolutely need a sponsor for escalation, as you said. In terms of terminology, sometimes they’re called project executive or project champion. There are lots of different terms for this person, but they’re very much the figurehead of the project, having that vision and ownership of the business case. They really know why this project has to go ahead, why it’s needed, and what it’s going to deliver.
Yes. Let’s now turn our attention to another very important role: the project manager. Tell me about the responsibilities of a project manager.
The project manager manages the project. It sounds obvious, doesn’t it? But that’s what they do. I mentioned the sponsor’s role in the business case. The project manager owns the PMP (Project Management Plan), which is that detailed document outlining how you’re going to run the project. The project manager manages the team, the stakeholders, suppliers, end users, and the reporting. They escalate anything or report progress to the sponsor. Fundamentally, they are delivering the project to ensure the benefits are realised.
Yes, I really like that image of the PMP being the contract because the sponsor sets out the business case—what we’re trying to achieve and why. The project manager then says, ‘Right, this is how I’m going to do it for you,’ and the handshake happens, and off we go.
What differences are there between the role of the project manager and the project sponsor?
You mentioned the concept phase regarding the business case. When we get into the definition phase, the project manager owns the PMP. The sponsor approves the PMP. So that’s the difference for me in definition. When we move into deployment, the project manager is front and centre—they’re running the project. The project manager would escalate changes to the sponsor, and the sponsor would consider the changes and approve them. So, in deployment, there’s a big delineation. The project manager is about delivery; the sponsor is about support. Moving into transition, the project manager is managing practical things like final drawings, lessons learned, and final accounts, making sure all contracts are signed and sealed, whereas the sponsor is signing off the outputs and getting ready for benefits realisation. The project manager really won’t be involved in that because, for them, that’s the end.
Yes, you can see that there are distinct differences between what the sponsor and the project manager do across the lifecycle. Thinking about relationships with other people on the project…
Yes. Due to where the sponsor sits, they’ve probably got more of a relationship with senior management and senior stakeholders, but also a close relationship with the project manager. The project manager, again, needs a good relationship with the sponsor and the steering group but probably a closer relationship with their team, motivating and leading them.
The only other thing I could think of, Ruth, is that they have different roles in reviews, don’t they? The project manager is more involved in collecting information, whereas the sponsor reviews that information. Between the two of them, they’ll decide whether it’s a go or no-go for the project.
That leads us nicely back into governance, because you need that separation of responsibilities: one person collates and presents the information, and the other scrutinises it and makes a decision based on it.
Yes, absolutely.
You mentioned project team members involved in delivering the work. Are there any other roles that support the project manager?
We’ve got project users. They’re involved at the beginning and end because they tell you what’s required, and at the other end, they’ll accept the product. They’ll be the ones who tell you whether you’ve met those requirements or not because they own that finished product. They’ll be the people using it. As the project progresses, they should liaise with the project manager, telling you if something isn’t right and requesting changes. Sometimes people think users run the project, but that’s not the case. The sponsor has the final say. Users can ask for a change, but once it’s assessed—whether it’s accepted, rejected, or deferred—the sponsor has the final say.
Sometimes there’s this notion that end users are just one homogenous group with the same opinions, but in reality, that’s not the case. Each user or group of users can have different priorities and requirements, which sometimes come into conflict with one another. That’s why the sponsor’s role is so important.
What about other roles, like the product owner?
The product owner can be a bit niche, and sometimes people struggle if they don’t work in an iterative or agile environment because product owners are integral to those ways of working. Product owners work for your organisation, but they’ve also got an eye on the outside world, if that makes sense. They interface between customers or users, interpreting needs. Product owners need to be technical people. They’ve got to understand what users are asking for and translate that into a scheme of work or a deployment list for the development team within the agile framework.
That’s a really good description of what they do. They’ve got a role within the project, but they’ve also got this longer-term, more business-as-usual view of the product they own. They keep an eye on what’s happening outside the organisation—what technological advances might be coming along that we can take advantage of. They’ve got both that longer-term and project focus; it’s quite an interesting role.
Yes, I agree. What about a Project Management Office (PMO)?
The PMO fundamentally provides administrative support—that’s the base level of a PMO. The idea is to save you time, so they might help write meeting minutes or book meeting rooms. But PMOs have developed more recently. They’ve moved into more technical support, so you can get experts in your PMO in areas like estimation or risk management. They can also be the gatekeepers of the most up-to-date versions of documents—perhaps your configuration management or your configuration librarian.
Yes, absolutely. So, PMOs start with admin support, but in a more developed organisation, they can offer technical support. At the most developed stage, because they’re independent, they can audit and support you in that.
Yes. Key roles, then, within the project management team.
Okay, so let’s look now at our third learning outcome. This asks us to understand why aspects of project management governance are required, such as policies, regulations, functions, etc., and then asks us to consider the impact of the choice of lifecycle on the governance framework and limits of financial authority. Let’s first talk about the aspects of project governance that are required.
It’s good to start with policies. They provide operational guidelines—for example, an expenses policy applies to the entire organisation, not just the project. You’ve got to comply with it wherever you are in the organisation. So, high-level regulations specific to the project, like guidelines and structures, are the next level down. If you work in the construction industry, there are a thousand regulations you’ve got to stick to. Regulations provide confidence to stakeholders. Getting closer to the actual delivery, processes, procedures, and functions are the foundations of project management. It’s all the contents of the PMP, giving instructions on things like which lifecycle you’ll use, how you’ll assess risks, and how you’ll manage costs. So, with processes, procedures, and functions, you’re getting closer to the coalface.
Yes. Processes, procedures, and functions are all aspects of governance, getting more granular as you work through them.
Yes, and the final one—delegated responsibilities—is the absolute nitty-gritty: who’s doing what and setting expectations, often shown in a RACI matrix.
Hopefully, that provides a good overview, starting from high-level organisational governance, which runs all the way down to the day-to-day operations.
My background is in working as a supplier-side project manager within a customer organisation, and it’s often the case that my organisation has different policies, processes, and procedures from the customer organisation. So, when we set up our project management governance, we have to ensure that all those policies and processes are respected, which can be challenging.
Yes, it must cause conflict sometimes.
Absolutely.
Let’s now think about our choice of lifecycle. We’ve got three different lifecycles: the linear lifecycle, the iterative lifecycle, and the hybrid lifecycle, which we have a whole other podcast about. Let’s consider how those lifecycle choices might affect the governance framework setup and financial authority on the project as well.
Starting with linear, that’s usually the place to start, isn’t it? With a linear lifecycle, governance is embedded in every phase of the lifecycle, with go/no-go reviews. It’s very structured—you’re saying yes or no and giving authority to move on or not. Within each phase, reviews should be happening. The project manager collects information from the team members and uses it to make decisions at the decision gates.
In terms of financial authority in a linear lifecycle, your PMP will outline the limits of financial authority—how much you’re allowed to spend, for example, £500 or £5,000. Sometimes funding is released at the beginning of the project, but depending on the project’s level and complexity, funding is usually released after you’ve gone through a review. That relates back to governance. So, the linear lifecycle is very much structured, with strong governance embedded throughout.
Absolutely.
What about iterative?
With iterative, it’s different. I would say governance is more devolved into the project team, although it is still embedded. Typically, it’s more flexible due to the nature of iterative working. You’ll have governance going on within the timebox, but you’ve got to be open to change, which feeds back into the level of control you have. Sometimes there’s a misconception that iterative lifecycles are like the Wild West, where anything goes, but that’s not the case if it’s done properly.
It’s interesting when talking about financial authority in iterative projects. There’s a shift in mindset because the cost for an iterative project is fixed for a timebox. There’s less debate about that than in a linear project, but the governance focus might be more on requirements and scope because decisions need to be made there—are we prioritising the right requirements? Are they going to give us the most benefits? The cost is incidental because we’ve agreed on it, and it’s fixed, so we can crack on.
Yes, the resources are there; you’ve just got to use them to the best of your ability.
What about the hybrid lifecycle?
With hybrid, you’ve got governance in each phase because the hybrid lifecycle has that backbone of the linear lifecycle. But I would say governance can be more flexible in delivery. For example, if you’re delivering something in stages or tranches in your deployment phase, the governance would be more embedded for that tranche.
In terms of finances for hybrid, it’s similar to the linear lifecycle. Funding would normally be released at the stage gates because you’ve still got that backbone in there. One of the major reasons organisations choose a hybrid lifecycle is that they want that more traditional governance structure, but they also want to take advantage of delivering projects in a more agile way.
Yes, they’ve not gone to the Wild West, Ruth.
Yes. The final learning objective is to understand the importance of linking projects to an organisation’s objectives. So, let’s discuss how we do this. I see the organisation as this big nebulous thing, and we’ve got these engines of change known as projects. How do we tie them together? How do we ensure that what we’re doing in the project world is actually meeting our organisation’s aims and objectives?
We’ve got to expand out now. We started by talking about projects, but we need to go into the wider world of programmes and portfolios. So, let’s define these three different structures. Lisa, how does the APM define a project?
It’s a unique, transient endeavour put in place to deliver specific outcomes and benefits. When I think about projects, it’s the coalface—it’s the delivery.
Yes. You mentioned programmes. What are they?
Programmes are fundamentally collections of projects. You can have some BAU in your programme, but you don’t have to. It’s either a collection of projects or projects aligned with some BAU. You’re stepping away from delivery and talking more about coordination in programmes.
I see programmes as a bigger structure to harness the transformational change from several linked projects.
Yes, absolutely.
And then you mentioned portfolios. What are portfolios, and how are they different?
Portfolios are stepping even further away from delivery and the coalface. Portfolios are collections of projects and programmes. When I think about portfolios, I think about resource management—have we got the people and finances to deliver these projects? Are they the right projects for our organisation? Are they contributing to our strategy? It sounds a bit twee, but I think of Churchill pushing tanks across Europe as a portfolio manager. There’s always that picture of him with a little stick, pushing resources to different places. That’s what you’re doing with portfolio management. You’re not on the front line or involved in the actual delivery, but you’re coordinating the pluses and minuses—can we afford it? Have we got the resources? Should we be doing this at all?
Actually, that image of Churchill with his stick is really apt because as the wider organisational strategy changes, you then push different projects and programmes in different directions. It’s not static.
Yes, I once heard that portfolio management is about choosing the right projects and programmes to do, and project and programme management is about doing them in the right way.
Yes, I like that.
Well, I think we’ve had a really good look at governance. There’s a lot to unpack within this learning objective. We’ve explored organisational structures, project roles and responsibilities, how organisational governance can affect project management governance, how the project lifecycle impacts the governance framework, and we’ve also touched on other change structures that link projects back to an organisation’s objectives.
Thanks very much, Lisa. That’s been great.
Thank you. Fantastic. Bye-bye.
