45min.
A3.KCI-1. Describe the deliverables
You can only make a schedule and a budget once the scope has been determined. A project cannot start if there is no agreement on what it should deliver, how long it should take and how much it will cost. In one way or another, the work has to be defined.
When determining the scope, you produce a definition, which on the one hand accommodates the required level of control from a management standpoint, and on the other hand, accommodates the required contribution to the goals as seen from the viewpoint of the client organization. A rigorous definition may result in a project delivering the agreed result on time and within budget, but if that result cannot be applied because it is too limited, you can hardly speak of the project being successful. It is not fit-for-purpose.
On the other hand, a definition which is too broad, which gives room for various interpretations, will result in a project never being accepted and being too expensive. Another risk we run arises when we keep adding new elements to the scope in order to satisfy the customer; we call this phenomenon "scope creep". A lot of small changes means we never finish the project, even though we have approval for these changes.
Where possible, you describe in detail what a project will deliver, and you make a connection between delivery, the goal hierarchy and the part products, services or results.
This makes it clear why we need specific deliverables. If there is no connection between the goal and delivery, then the latter should not take place.
If, at the commencement of a project, it is not possible to make a clear definition, it is better to define a preliminary project, which has as its most important result the determination of the deliverables. Only when this is clear, can you start with the actual project. The question now remains, whether you first specify all the deliverables and then develop and deliver them in one go (waterfall method), or whether you prioritize the deliverables and then select small and controllable collections of them, which you then deliver successively (Agile).
The scope describes the project result, how the deliverables are put together, what we deliver and what we are not going to carry out. You also specify the interfaces with other projects or departments on which your project is dependent.
A good scope description contains the following elements:
Name, date.
Business objective.
Project deliverables, and description of the work.
And furthermore, you are involved with:
Out of scope, the aspects that you do not carry out.
Assumptions, uncertain and non-controllable aspects.
Conditions, those subjects the sponsor has to organize to assure a successful
execution of the project.
Constraints, issues that restrict the team in its choices, such as: deadlines,
budget constraints, statutory regulations, etc.
Requirements and interests of the various stakeholders in the project are taken into account as far as is possible.
Once we have described the scope in this way, we break it down and structure it.
Application
You can convert the above into actions on the project/programme/portfolio for which you are currently responsible, by carrying out the following steps:
Define the project deliverables.
Differentiate between goal and deliverable.
Group the goals and the associated deliverables.
Utilize the goal hierarchy.
CASE
EXAMPLE A3.1 Implementation of a packaging installation
In scope: The model X-25 packaging installation, connection and site acceptance test (SAT), to be delivered in the factory in Harare (Zimbabwe).
Out of scope: Employee training will be carried out by the customer.
Assumptions: Transport by sea is not delayed by weather conditions.
Conditions: The electrical connections that must conform to the attached standard.
Constraints: Before the 12th July of the following year.
Transport delay because of bad weather is an already accepted risk, for which the project manager is not responsible. This is also true, if the electrical connections are not satisfactory. The difference between an assumption and a condition is that the former cannot be influenced by anyone, and the latter can be influenced by someone else outside of the project team. Therefore, both fall outside of the project, but we name them, as they both can have a significant influence.
