Scope of The Project or How Do We Know What To Do
Come closer my fellow Software Engineers. Today I will tell you the story about the project and how important it is to define its scope.
Сonstruction Of The Сentury
In the lovely town of Sprintfield, an ambitious decision was made to construct a stunning palace near the picturesque Backlog Bay. The people wanted this palace to be the symbol of town’s prosperity and serve as a community centre for gatherings and celebrations.
As the decision was made folks decided to make a committee to turn their dream into reality. There was no end to ideas at the committee meeting. Every town member had a vision for the palace — some wanted spacious halls, while others envisioned blooming gardens, and yet some dreamed of a tower that reached the sky.
At the very first days the ambitious project faced its first challenges. There was no unified understanding of what this palace should look like. The project started with real chaos because the specific scope had not been determined. The committee hastily hired several contractors, each with their own understanding of the project. Materials were ordered without proper planning, some in excess, some in short supply.
Once the construction began, city funds quickly ran out, much faster than expected. Costs ballooned due to the purchase of unnecessary materials, the hiring of overlapping expertise, and constant revisions to the structure. Moreover, the project timeline extended indefinitely as workers were trying to integrate the conflicting designs and functionalities into the palace.
Months turned into years, and the palace, rather than becoming a shining symbol of the town, became a sad reminder of the town’s lack of foresight. The size of the rooms was inconsistent, with some so vast they echoed and others so small they were barely usable. The gardens shaded the palace, and the tower, though tall, offered no decent usage.
Eager to save their dream, the City Council sought the expertise of Mr. Blueprinton, a famous architect known for his talent of planning. “The lack of a clear scope resulted in unpredictable budgets, extended schedules, and a building that failed to achieve its intended purpose.”
Mr. Blueprinton said that each project needs a clearly defined plan. A defined scope would have given the city a clear picture of the costs involved, the time required, and the resources and expertise required.
Blueprint Of The Project
Following the Sprintfield experience with the help of Mr. Blueprinton the citizens of the town understood the importance of clear definition of the project’s scope.
In the complicated world of project management the definition of the scope is the first key of the proper planning and estimation. Just as the palace near the Backlog Bay needed the blueprint, a project requires some fundamental structures like:
- the organisational breakdown structure (OBS),
- the resource breakdown structure (RBS),
- the work breakdown structure (WBS).
The OBS represents a hierarchy that exists in your organisation extended with the responsibilities and relationships of the organisational units and people. The RBS is a logical structure to systematise resources required to accomplish the project. However, in this article we will focus on the WBS.
The definition for WBS is the following:
A WBS is a uniform, consistent, and logical method for dividing a project into small, manageable components for planning, management and control purposes. In other words, it is a complete representation of all outcomes/deliverables that are expected to be achieved within the project.
With Sprintfield’s experience in mind, let’s try to understand how to build a good WBS and apply it to address the scope related issues, ensuring every project detail is well-accounted and estimated correctly.
Why Would We Need It?
Once again, WBS is a hierarchical structure for all project outcomes for the purpose of planning, management and control. Effectively, WBS may be in the form of a list (pic 2) or a tree hierarchy (pic 3).
But it is more than just a simple visualisation of what needs to be done. When done properly WBS becomes a powerful tool offering numerous advantages to your project.
Clarifies Scope Definition: WBS describes the whole scope of work for the project in a structured way. It visualises what should be the outcomes of the project.
Improves Estimation: As WBS breaks the projects into smaller elements it becomes easier to estimate them. The less is estimated task the smaller would be the spread of final costs from the estimate.
Enhances Resource Allocation: WBS allows project managers to approximate what would be needed for what parts of the project, enabling resource allocation optimization.
Facilitates Stakeholder Communication: Visual representation of project structure and outcomes facilitates communication between stakeholders, teams, and clients. All sites could reference the WBS to understand what’s being discussed, reducing ambiguities.
Promotes Project Risks Management: By breaking the project down into components, potential risks at each level could be identified and mitigated in the early stages.
Ensures a Complete Deliverable: The “100% Rule” of WBS (if something is not in the WBS — it is not in the project) reduces the chance of missing out on key deliverables.
Acts as a Basement for Other Processes: A properly-done WBS serves as a foundation for other project management processes, such as activities planning, budgeting, monitoring and risk management.
How To Build It?
Before we move to the guide to build the WBS, we must understand what makes an effective WBS.
The key rule we need to follow is the “100% Rule”. Essentially it means the following:
If something is not in the WBS — it is not in the project. If something is in the project — it should be reflected in the WBS.
From this rule we can derive the following requirements:
- WBS needs to include all of the project deliverables.
- Each element on any of the WBS levels is a sum of its’ ‘children’.
- There can be no implicit work in the project.
- Each element should be achievable and measurable.
The lowest level of the WBS is known as the work package. Work package is a work required to complete a specific job or process, such as a report, design, documentation requirement or portion thereof, piece of hardware, or service. It is the lowest level in WBS structure because it is the point when the cost could be estimated and managed.
Keeping in mind those requirements we may move to create a plan to define a project scope!
In short: you break every outcome until you eventually reach a distinct manageable working package which could be presented as user stories or tasks.
Step 1. Define main deliverables and requirements.
Try to determine the current state of the project and the direction where you should eventually go. You may use a checklist at pic. 5 as a guide for this step.
Step 2: Divide main deliverable into components
Those would be your high level outcomes you need to achieve to complete the project. Important: those outcomes are artefacts not phases. Try to use nouns over verbs.
Step 3: Continue the breakdown process down to the structure
Continue the process until you reach the work package level.
Step 4: Assign responsibilities
It could be departments, teams, contractors etc.
Step 5: Review
As the draft of the WBS is ready you need to review it both inside the project and outside with the stakeholders to eliminate any bias in the structure.
Step 6: Document WBS
Create visually attractive and clear documentation of the WBS and share it within the project. Work with people to identify and document dependencies.
Step 7: Revisit and Refine
As the project progresses from time to time go back to the WBS to check and to make necessary adjustments if needed. WBS is as flexible as the project is.
WBS in Action
Taking inspiration from the Sprintfield case let’s discuss examples of WBS implementation.
One of the textbook implementations of WBS is an agile approach to structure work in software development projects. Let’s take a look at pic 6. This diagram represents one possible way to structure the project work into the packages defined by Agile frameworks. We will touch Software Development processes more in our upcoming articles, but for now we need to highlight that there are some frameworks that introduce rules and entities to build the breakdown of your work. In the agile family of processes the levels of the breakdown have specific names and characteristics. It includes Epics, Features, Stories and Tasks. Each corresponds to one of the levels in WBS, each has estimation in time or story points. To finish the Story you need to finish all the tasks. Tasks are manageable and measurable, they have a responsible executor, priority and deadline. Tasks are the lowest level work packages by all of the properties. Such a structure is not just a theory. It is a day-to-day routine for many software engineers around the world. The clarity and system it brings converts the chaotic software development process into the streamlined flow of the completed tasks and delivered value to the customers.
Common Misunderstandings About WBS
Speaking about the real world application of the WBS we also cannot close our eyes to typical mistakes and misunderstandings around the WBS.
- Confusing WBS with Gantt or PERT charts.
While all of the above tools provide projects with the structure, they serve different purposes. Even though Gantt, for instance, could be considered a subset of the WBS, Gantt chart aim is to define sequence and timeline, while WBS focuses on the deliverables and work packages. - Focus on Sequences, not the Deliverables.
The WBS is not meant to define the sequence in which the deliverables should be implemented. In WBS you need to focus on the deliverable, not the process. - Excessive Focus on the Durations.
Some managers may tend to do the low level estimations as part of the WBS creation. WBS in turn focuses on high level estimations to negotiate the terms of the delivery with the client, to manage customers expectation and do strategic workforce planning. - Underestimation of the 100% Principle.
It states that if something is not in the WBS — it is not in the project. Taking this principle too loose can lead to the fact that as the project develops its scope will inflate dramatically. - Taking WBS as One-Time-Task.
WBS is not a static structure. As the project evolves the corresponding adjustments should be made to the WBS structure.
Fix the Mistakes
Following the initial planning mistakes, the citizens of Sprintfield realised that their palace in the Backlog Bay required not just the blueprint, but the clear deliverable-oriented structure. Mr. Blueprinton returned to them with the proposal of the Work Breakdown Structure designed to aggregate, structurize and visualise outcomes of the Springfield Palace project.
The structure shows how every outcome is the part of the main deliverable — the Sprintfield Palace. This structure bringing people of Sprintfield following benefits:
Tracking: The citizens and the committee could observe how abstract tasks are fitting the bigger picture and keep track of how the project is progressing.
Budgeting: With the defined deliverables the project becomes easier to estimate and cost allocation becomes clear and straightforward.
Requirements management: Presenting the deliverables structure to the customer may clarify the requirements misunderstandings at the very first stages of the elicitation. During the project execution it would be easier to negotiate with the customer requirements and budget changes.
Lessons learned
Vision is Vital
Before you begin to do actual work, you need to have a clear understanding of what should be the result of your project.
Plan Drives Progress
By breaking down the deliverables, you turn the uncertainty of how to carry them out into a series of achievable steps you need to follow.
Good Planning Prevents Poor Performance
The earlier you understand your scope and indicate requirements misalignments, the less it will cost to fix them.
However, with the plan and scope taking shape, Mr. Blueprinton sees the upcoming challenges ahead. He understands that the scope is just the first step in the long journey of Sprintfield Palace Project.
Join us in the next articles where we unravel the future steps in the Palace construction, as the plans will meet the execution and the requirements will turn into reality!
