PRINCE2® defines a project as “A temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case.” The words “delivering one or more business products” here lead us to lay down as to what exactly we are going to deliver in this project. The boundaries within which we are going to do this will have to be drawn and ascertained whether we have the resources to achieve the above.
The boundaries are the limits within which the project will be managed and these are called the Scope of the project. This precision and clarity with which the project team can write the Scope of a project ensure the success of a project.
Triangle of Project Constraints
The six main aspects or variables of a project in which a Project Manager has to manage are Cost, Time, Scope, Quality, Risks, and Benefits. If Time, Cost, and Scope are three sides and Quality, Risks, and Benefits are three angles of an equilateral triangle then it will be apparent to the reader that changing any one of them will have an impact on the other five. The first two, Cost and Time are the top-priority ones.
The Business Case written and amplified in the pre-project processes defines the cost and timescale besides listing the Benefits, Risks and stating the Quality requirements of the product based on Customer’s Quality Expectations and Acceptance Criteria. The sixth main aspect Scope is covered for a Plan and it is the sum total of its products and the extent of their requirements. Whilst a Business Case tells us ‘Why’ we are doing a project Scope tells us as to ‘What’ exactly is the project delivering.
Functional and Non-Functional Requirements
Irrespective of whether one is doing a Waterfall or an Agile Project, being absolutely certain of what the customer, as well as the stakeholders require, is essential for the success of a project. The requirements help us define the scope and capturing them right at the beginning of a project simplifies the Scope Management. Functional requirements are those which tell us what a product must do and what all the steps it will take to perform that function. Think of Functional requirements as-
“This product shall- ( perform some action )-”.
Non-Functional requirements, on the other hand, are related to the system. Think of them as efficiency, quality, reliability etc. As an example-
“No patient shall be discharged without the issue of a discharge slip from the doctor”.
This is a Functional Requirement.
“Patients will be discharged within 30 minutes of receipt of discharge slip from the doctor”.
This is a Non-Functional Requirement of the hospital’s system of discharging a patient. It speaks of the hospital’s efficiency. Functional requirements define the product scope. With Non-Functional requirements added, they help define the Project Scope.
PRINCE2® recommends Product-based Planning. It means breaking down of the Project Product into smaller and identifiable components. The Project Product Description is broken down into Product Description of each component. Then a Product Flow diagram is created. This enables working out the Product Scope of the project besides writing Plans and Quality Management Approach based on Customer Quality Expectations and Acceptance Criteria.
In Agile projects, the customer may not be very clear at the start of the project as to what he wants. His requirements keep changing with each delivery. MoSCoW helps in streamlining and prioritizing the requirements. Thus essential requirements without which the customer will not accept the completed product are listed under Must Have. Some requirements which have a high priority but are not absolutely essential fall under Should Have and those of low priority but useful to have will be listed in Could Have category. Won’t Have means either the project will not provide it or it will be held over to be considered at a later date or even passed over to the next project. MoSCoW prioritization technique is a useful tool to arrive at an agreement between the Customer and the Project Manager to arrive at a requirements list which is deliverable and both the parties are very clear as to what (Scope) the project is going to deliver. MoSCoW can also be used for Waterfall projects, prioritizing Risks and most importantly define Scope Tolerances.
Reasons of Scope Creep
Most Projects have a tendency to exceed their original boundaries. This is called Scope Creep. One of the common cause of scope creep is the liberty given to the customers and stakeholders to Raise an Issue or Request for Change.
Each RFC has to be considered for its impact on the Business Case. In order to work within the Cost and Time limits, a Project Manager should have a clear understanding as to what is in the Scope and what is not. Some Project Managers have a tendency to provide much more than the scope of the project. This is called Gold Plating and it is more relevant to software projects.
The other reasons for Scope Creep could be wrong estimations of Time and Cost during the planning stage. Sometimes a project may be issued with a legal legislation forcing it to exceed the project scope. Lastly, it could be the fast-changing technology which could compel a Project manager to recommend increasing the budget or/and time. Be as it may, the Project Manager has to study and analyze the change in terms of its-
And finally, seek approval of the Project Board before implementing a change.
Tips to Eliminate Scope Creep
a) It is imperative for the Project Manager to be alert to all Requests for Change, Issues and Off Specifications. The aim is not to stop a change but to study its impact on all the six constraints and then take approval of the Project Board before implementing it. Issue and Change Control Procedure should be in place.
b) Any good Project Manager will ensure that the project remains aligned with the project plan. This is his endeavor when he is controlling a stage on a day-to-day basis. He has to, therefore adhere to a Change Control procedure either laid down by his organization or as recommended by the PRINCE2 manual. He first ‘Captures’ the issue to determine its severity and then ‘Assesses’ its impact on the project objectives and the Business case as well on its Risk Profile. Thereafter, he identifies and evaluates options to propose the best corrective action to be taken to bring the project back on track if it is estimated that implementing the requested change might entail exceeding the tolerances of the all the project constraints especially of Cost and Time. He puts it up for the approval of the project board. The PB will ‘Decide’ whether to approve, reject or defer the option. The corrective action would then be ‘Implemented’ by the project manager or the nominated Change Authority as directed by the project board.
c) A Project Manager should be absolutely clear as to what the customer wants. In fact, all stakeholders should be involved in forming the requirements list.
d) The goals and objectives of the project should be clear before the project starts. The deliverables should be well understood by all members of the Project Management Team.
e) Estimation Techniques used whilst making Project Plan or Stage Plan should be efficient.
f) Ensure that there are minimal changes affecting critical path tasks.
g) Avoid Gold Plating
The client is not concerned about the commitment, they are worried about their business!
The scope is the heart of the project that estimates whether the result is successfully achieved or not. We must at least be able to manage scope creep if we can’t find ways to avoid it completely. Doing a proper research and gathering all the essential requirements for a project can help us develop and understand a well-defined project scope that reduces scope creep. With the ability to find the signs of scope creep we will be better able to manage it proactively.