Every Role in a Project Answers a Different Question

Most project structures look the same on paper. A box at the top, a few boxes underneath, and a row of workstreams at the bottom. We have all seen the chart. Most of us have sat inside one.

What we see less often is an explanation of why the boxes sit where they do.

That explanation matters. When people understand why the structure is built the way it is, they stop treating it as an org chart to be filled in and start treating it as a set of responsibilities to be held. That is the difference between a structure that exists and a structure that works.

Here is the way I think about it. Every layer of a project answers a different question. When each layer knows its question, and stays with it, the project becomes easier to operate, easier to communicate, and far more likely to come together as one team.

The Project Sponsor: decisions and oversight

The sponsor answers one question: should we keep going, and on what terms?

The sponsor is not there to run the project. The sponsor is there to own it. That means making the decisions nobody else has the authority to make, such as changes to scope, budget, timeline and risk appetite, and keeping oversight of whether the project is still worth what it is costing.

This role sits at the top for a simple reason. Decisions have to land somewhere. If they do not land with one accountable person, they get spread across committees, emails and hallway conversations until nobody can say who decided what.

The most common failure here is a sponsor who drifts down into management. They start chasing tasks, attending working sessions and solving delivery problems. It feels like engagement. In practice, it leaves the top of the structure empty. The decisions only the sponsor can make stop getting made, because the sponsor is busy doing someone else’s job.

Project Assurance: assess all dimensions

Assurance answers a different question: is it really as it appears?

Assurance takes a holistic view. It looks at every dimension of the project, not just the one that happens to be in the status report this week. Schedule, cost, quality, risk, people, readiness, benefits. It asks whether the picture the sponsor is seeing matches what is actually happening on the ground.

This is why assurance sits between the sponsor and project management, and why it must be independent of both.

It cannot report to the project manager, because it would then be checking its own manager’s work. It should not be the sponsor’s personal opinion either, because the sponsor has a stake in the project succeeding and, like all of us, tends to see what they hope to see.

Assurance is the layer most often left out, usually to save money or because it feels like a vote of no confidence. It is neither. It is the only part of the structure whose job is to see the project whole. Without it, the sponsor is deciding on a picture that has only been drawn by the people delivering the work.

Project Management: lead with clarity

Project management answers the question: what are we doing, who is doing it, and how are we tracking?

I wrote “lead with clarity” next to this box because clarity is the project manager’s real product. Plans, schedules, RAID logs and status reports are the tools. Clarity is the outcome. Everyone on the project should be able to say what they are working on, why it matters, what is next and who they depend on.

The project manager sits in the middle for a reason. Above them is the authority to decide. Below them is the capability to deliver. Their job is to connect the two, turning decisions into direction for the workstreams, and turning the reality of the workstreams into information the sponsor can act on.

When this layer is weak, it shows up as noise. People are busy, but not always on the right things. Questions get asked twice. Decisions get re-opened. Nobody is quite sure what has been agreed.

The workstreams: specialist responsibility

Underneath project management sit the workstreams. Each one answers its own question: how is this part of the work done well?

• Business Analyst: what does the organisation actually need, and how does it work today?
• Change Manager: are people ready, willing and able to work in a new way?
• Training Manager: will people know how to use what we are building on the day they need to?
• Quality Manager: does what we are delivering meet the standard we agreed?
• Subject Matter Experts: is this right for how our organisation really operates?
• Product Owner: what matters most, and in what order?
• Architect: does it all fit together, now and later?

The list is never complete, and it should not be. The workstreams should match the project, not a template.

There are two reasons the work is divided this way.

The first is focus. Each of these areas takes real skill and real attention. When one person tries to cover business analysis, change and training together, one of them will always win, and it is usually the one with the nearest deadline.

The second is ownership. When a workstream has a named lead, there is someone who will notice when their dimension of the project starts to slip, and who has the standing to raise it. When nobody owns change, nobody notices that staff are not ready until go-live.

The Architect is worth a special mention. On my own sketch it sits across the bottom of the workstreams rather than beside them. That is deliberate. The architect’s job is not one part of the solution but how all the parts connect. It is the one workstream that has to look sideways at every other workstream.

A simple example

Consider a council replacing its finance and payroll system.

The CEO or a director sponsors the project. They decide whether a delay in the payroll module is acceptable, and whether to fund an extra phase of data migration.

An independent assurance function reviews the project each quarter. It notices that while the schedule is green, change readiness in the depot and field teams is low, and training has not been planned for shift workers.

The project manager takes that finding, adjusts the plan, and makes sure the change manager and training manager are working from the same timeline.

The change manager engages the depot supervisors. The training manager builds sessions around shift patterns. The SMEs from payroll confirm that the new award interpretation rules match how staff are actually paid. The architect checks that the timesheet integration will still work when the rostering system is upgraded next year.

Nobody in that example is doing anyone else’s job. Each person is answering their own question. And because the structure is clear, the issue raised by assurance travelled to the right people and was acted on without a crisis.

Why the structure is worth getting right

Once the structure of the project set-up is clear, it makes it easier to operate, communicate and develop a cohesive structure to win.

Easier to operate, because people know what they are responsible for and what they are not. They spend less time working out who should be doing something and more time doing it.

Easier to communicate, because information has a path. Issues move up to the person who can decide. Decisions move down to the people who will act. Nothing has to be sent to everyone just in case.

A cohesive structure to win, because the parts support each other instead of competing. Assurance strengthens the sponsor. Project management serves the workstreams. The workstreams give the project manager an honest picture. Each layer makes the others better at their job.

A structure does not guarantee success. People still have to hold their roles when the pressure arrives, and that is a separate discipline. But a clear structure means that when the pressure does arrive, everyone knows which question is theirs to answer.

Here are some questions to ponder.

If you asked each person on your project what question their role exists to answer, how many different answers would you get?

Who on your project is responsible for seeing the whole picture, and are they independent enough to tell you what they see?

And which box on your structure is filled with a name, but not yet with ownership?