There is a direct link between the accuracy of requirements and the outcomes of a project.
Consider this situation: a workplace design and build contractor’s project is nearing completion. The excited future occupants walked through their near-complete office only to escalate to their CEO that the washrooms were not as they expected.
When the escalation reached the Contractor, he remembered that the project requirements stated that the washroom walls and doors had to be floor to ceiling, and indeed they are executed in the same manner. He checked the finishes and fittings with the signed-off scope, and everything seemed to be in order. He made further inquiries and found that the occupants’ displeasure was that the toilets in the common core had stall partitions, which were initially a part of the landlord’s scope. However, what the Contractor missed in the signed-off scope document was the list of exclusions.
The Contractor had no choice but to redo the toilets at his own cost, at an expedited schedule, and with more resources, which led to quality compromises and customer dissatisfaction.
We define project scope as requirements that will be included as well as those that will be excluded. The failure to fully define a project’s scope can result in lost time and increased spend.
The Journey of Scope from Start to End of the Project
Our contractor example addressed the “Why” of managing scope already. Now comes the question – “Who” will be providing the scope?
While the project delivery approach could be within any framework — a traditional waterfall, agile, or hybrid — for a successful project, one must involve the stakeholders influencing the project outcomes from the initial stages of requirements gathering, mutual buying–in, implementing, and finally validating scope.
The first step is to understand the stakeholders’ requirements, expectations, and problems before addressing and solving them. Understanding requirements is essential because stakeholders or requirements that get missed initially will inevitably surface later in the project. In a traditional waterfall project, requirements uncovered later are more challenging, time-consuming, and costlier to integrate.
When it comes to gathering requirements to define scope, it is essential to distinguish how scope is viewed in a waterfall and an agile approach and when it is defined in each approach.
The “How” and “When” in Waterfall
In most waterfall approaches, the aspiration is to define one hundred percent scope, the corresponding schedule, and cost baselines before implementing the project to reduce uncertainty. In a nutshell, the project delivery is controlled to scope. In case of scope changes, formal change authorization procedures are used to approve changes to schedule and costs. It is evident in the waterfall approach, the scope is defined early in the project before implementation.
However, there may be some overlaps during implementation for scope portions not impacting the schedule and budget. Waterfall approaches are suitable for industries where project implementation is highly material or labor-intensive; hence changes will produce a lot of waste. For instance, no one would like to build and rebuild a wall to decide where one must build a wall.
The journey of scope in a waterfall approach is illustrated in Fig 1.
- Once the stakeholders (Customers) from whom requirements are to be collected have been identified, the first step is to gather all the requirements. Some commonly used tools for gathering requirements include – Brainstorming, interviews, workshops with cross-functional experts, surveys, and questionnaires.
- Due to inherent project constraints and competing requirements, teams have to deliberate with the stakeholders to define and mutually agree to the scope that would help adequately meet the project outcomes.
- Subsequently, the agreed scope is implemented by the performing organization and is validated by the customer.
Fig 1: Journey of Scope in a waterfall approach
The “How” and “When” in an Agile
In agile approaches, the focus shifts from delivering to scope to achieving business outcomes early and adding value to the customer. To achieve these objectives, agile teams must be open to leveraging uncertainty in scope to value realization.
In agile projects, the costs and schedule are fixed along with the most desired features that add customer value. The granularity of features evolves as the implementation starts, which means the features at the bottom of the list could be very sketchy initially. A customer who wants to build a new e-commerce website and wants it to be different from those existing in the market would have the essential features in the first release, and the inputs for building the website over subsequent releases may be provided and refined over time.
The journey of scope in an agile approach is illustrated in Fig 2.
- In an agile project, the Product Owner is a single identified entity who liaises with stakeholders and helps the project team build the product backlog, prioritize the features, and refine them through the implementation.
- The set of feature(s) selected to be developed in a particular sprint or release is planned with more granularity before development.
- Once development is complete, sprint reviews are conducted with the Product Owner and the customers for either acceptance of feature(s) or feedback.
- Based on this, the Product backlog is refined for further development.
Developing and managing scope can be done using collaboration software like Microsoft Office Suite (Word, Excel spreadsheet), Google Drive, or OneDrive where multiple user access is required, or project management software like ProofHub, SwiftKanban, or JIRA. Whichever platform you use, constant communication is the key to effective planning and managing of project scope.
Also Read: Top Confluence Software Alternatives 2021
Attention Project Managers!
While managing project scope, there are some cautions to exercise.
At all times, the project management team must avoid scope creep on projects. PMBOK Guide 7th Edition defines scope creep as “Uncontrolled expansion to project or product scope without adjustments to time, cost, and resources.” Scope creep often leads to schedule and cost overruns, conflicts and disputes related to costs between the performing organization and the customer, and eventually ruins relationships. Whenever additional requirements are added, it is prudent to advise the customer promptly of the possible impacts on the project deliverables and take consensus to avoid scope creep.
Isn’t it a great idea to make your customer happy by providing freebies? It may sound great at the moment. However, some freebies — like additional features not included in the original scope — may come with additional costs that the team may miss, like the cost of new components, additional resources to build it, and testing. Even if they are real freebies, there is a risk of setting precedence for higher customer expectations that may lead to customer dissatisfaction when you don’t provide similar service for later projects. Offering freebies (often referred to as ‘Gold Plating’) is not a good practice.
Manage scope to define resources
A simple ‘To do list’ would save time and several dollars during grocery shopping. As project implementation and product development are multiple times more challenging than grocery shopping, we can appreciate how important it is to have a detailed scope of what needs to be done to achieve business value within the available resources.
Get our best stuff.
