Some of the problems in projects and change are down to the wrong perspective of scope. Specifically, project managers and change managers need to look at the scope of their work from different perspectives. Let’s explore this a little more.
The Project Manager
In simple terms scope is based on the idea that there needs to be some boundary of responsibility for a project and the work of its project team and project manager.
Scope does not define what is delivered - that is defined in the requirements, nor how it is to be delivered - that is described in plan amongst other artefacts. Scope merely defines the limits to that what and how. Essentially, the project manager is responsible for worrying about all those things that are within scope. Everything outside of this boundary is someone else’s problem.
Of course, life is not quite as simple as this. There are often external dependencies. An external dependency being something outside of the project’s scope, but which the project needs to be able to complete its work. Managing external dependencies is a balancing act of not getting too involved in things outside of the project’s scope, but not remaining distant and being surprised if they are not delivered. Even here, a clear definition of scope helps. Scope is a good starting point to identify external dependencies.
Being able to determine and agree the scope is an important project management skill. It is a foundation stone for planning, resourcing and managing expectations. Early in my career as a project manager I thought I was pretty good about clearly defining scope, using a combination of understanding, analysis and hard-nosed negotiation.
I worked out a number of questionnaires to help in defining scope which I found useful. You can find them in my books The Project Manager Mastering the Art of Delivery, and inThe Project Managers Book of Checklists.
The Program Manager
Anyone who has worked on big initiatives soon learns that as projects scale up into complex groups of inter-related activities the concept of scope remains important. Determining what is in and out for a program of work is critical.
But there is a challenge, and that is that whilst our lives would be easier with a hard and fast definition of scope, this is more difficult to achieve with complex programs.
There are various definitions of program managers. For me, what differentiates a program manager from a project manager, is that a project manager is responsible for a set of deliverables, whereas the program manager is responsible for an outcome. The outcome can be defined in terms of business benefits or a change in an organization.
This means the program manager’s idea of scope has to be different than a project manager’s. The scope of activities required to achieve a business outcome is usually a superset of those required to produce a set of deliverables.
In practice, this tends to mean that scope for a program is a wider, less precise and needs to be treated a bit more flexibly than a project’s scope. The intention is the same – to define a boundary which limits the program. But these boundaries are a little less fixed than those in a project. Defining the scope for a project can often be done and dusted in the early stages of the project. For programs there is usually a process of ongoing refinement of and negotiation about scope as the program evolves.
When I first became a program manager it took me a while to understand this. I tried to tie down my scope into an inflexible, hard and fast set of guidelines based around deliverables, not outcomes. I learnt that life was not so simple!
The Change Manager
One of the disciplines found in most projects nowadays is change management. On some initiatives there are dedicated change managers, on others the work of change management may be rolled up into the work of the project or program manager. I think this consolidation of roles is problematic because the scope for a change manager may be different than for a project manager.
The project manager’s goal is to efficiently and effectively produce a set of deliverables. For a project manager scope is as much about what to exclude as include within the project. Anything that is not relevant to the production of these deliverables should be kept out of scope. For program managers the world cannot be quite so black and white, but still the aim must be to try and limit scope.
Change managers also try and limit the scope of their work, but need to start from a very different viewpoint. For project managers, and to some extent program managers, the viewpoint on scope needs to be focused on the deliverables or outputs of the initiative.
Change management is concerned with ensuring the stakeholders impacted by a project are ready, willing and able to work with whatever the project produces. But you can’t do this by only looking at what an individual project produces. Everyone’s ability to absorb change is also a function of what other change those people are going through. For change managers scope must consider a user perspective.
As a project manager I want to try and ignore any other projects running in parallel. As a change manager I really need to think about all the projects that result in change for my stakeholder group.
This does not mean change managers have to worry about everything everywhere. A change manager’s scope of may be limited to a particular subset of stakeholders – but it needs to consider all the changes effecting these stakeholders.
A simple way of thinking about this is that project managers’ scope is about deliverables, whereas change managers’ scope is about stakeholder groups. It’s not really quite as simple as this, but it’s a reasonable starting point.
If you choose to combine the role of project and change manager, it can be challenging to managing these differing perspectives on scope. Well, that’s my view anyway. I’m interested to hear other perspectives …