In Part 1 I wrote about defining the problem the project sets out to solve and how to write SMART Objectives. Here, we will identify Deliverables and Scope.
These may also be called “outputs” or “products”. Too many Project Initiation Documents specify Deliverables as their objectives. Deliverables are only produced in order to enable achievement of the objectives.
An objective “To implement a new xyz IT system” is not an objective. What is the expected organisational benefit here? If you can see it, feel it, file it, trip over it, or put it on a shelf, it’s probably a deliverable, not an objective! You won’t be able to draw it on a graph.
Many IT and Facilities projects suffer from having deliverables expressed as objectives. The result is that the focus of the project is on delivering “stuff”, rather than improving organisational performance.
One PID that I saw in a public sector organisation only had one deliverable listed: “A PID”. That rather misses the point, doesn’t it, and suggests an obsession with “process”, rather than achievement.
Deliverables are “stuff”.
One of the potential problems with projects is that the scope may “creep” as different stakeholders ask for different, or additional, features of the outputs. Scope may be specified in terms of:
- Geography (e.g. sites, offices, locations)
- Products, services or processes
- People (e.g. grade, role, department)
- Project Activities (e.g. what issues the project will, or will not work on)
It’s usually helpful to define, based on early discussions with key stakeholders both what is in scope and what is out of scope. Agreeing what is out of scope helps you to manage expectations about what the project won’t actually deliver.
Developing a Scope statement has to be done through consultation with the project’s Sponsor, customers/users and other stakeholders. As such, it’s unlikely that they will all have the same views and therefore, some negotiation and hard decisions will be needed. Clearly, the budget and timescales will also affect what the scope of the project can be.
In Part 3 I will discuss Project roles and responsibilities.