Steve’s team is building a Hotel Management software.
Maggie submitted her software program that took care of guest registration when they arrive at the reception.
Beth from the testing team took it up for testing and rejected the whole delivery.
Reason?
Maggie did not take care of the functionality that arriving guest who is a ‘Club member’ had a different rate card to be applied.
“Different rate card? Where is this requirement written?” Maggie said in disbelief.
“I don’t know where is it written, but it was mentioned by someone during the Requirement Clarification meeting with customer last month”, was Beth’s reply.
“If it is not written in the Use case,” said Maggie, “it doesn’t get into the code”.
“Hey, Special Guests use case captures user registration but I am not sure if it talks about the rate card”, said Anil, a fellow developer.
“Then it is not part of the scope” Maggie said.
Beth shook her head.
So did Steve, the project manager, realizing that he had a problem on his hands. Requirements were not documented and detailed properly, in spite of him conducting regular Requirement Clarification meetings with the customer.
To manage scope, project manager needs to think about project activities required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.
“only the work required” – is very important. In my own experience, we had to pay dearly for over enthusiasm shown by developer (in one of the instances, I being the one) by adding functionality that was ‘cool’ but was not documented in requirements. Problems such as Gold plating and Scope creep in such cases can hurt team’s schedule, productivity, and quality quite badly.
Why does this happen?
And more importantly how to make sure things like this will not happen on your project?
This is what the processes in Scope management knowledge area address. Let us look at them very briefly.
Plan to Manage Scope
This is where the process to collect, define and manage project scope is defined. You may be using existing practices from defined templates or a best practice from another project taken from organizational process assets.
Scope management plan addresses questions like,
- who has the authority and responsibility for scope management,
- how is scope statement prepared,
- how Work Breakdown Structure is derived from detailed scope,
- how changes to project scope is handled by way of preparing and managing Scope Baseline,
- who accepts deliverables and verifies scope, and how it is done.
At this point you may be wondering, what is the difference between project requirements and scope?
Well, that is a fantastic question and needs to be clearly understood before going further with scope management study. Click here to understand the difference (opens in new window).
Collect Project Requirements
How do you identify and document what customer wants, in other words, project requirements?
This process description answers this question with some neat tools and techniques. Bear in mind that this is one of the crucial processes in a project, because unless right requirements are captured properly the deliverables cannot be guaranteed to satisfy customer.
Define Project and Product Scope
Once you know what customer needs, this process helps you add clarity to project and product requirements by detailing the requirements.
If you are not clear about the difference between the project scope and product scope, please take a pause right now and understand what do they mean.
Define Work Breakdown Structure
..or WBS, is a critical process in arriving at project scope from customer requirements.
This process is all about breaking down the monolith. Project deliverables are broken into smaller activities that can be easily managed, tracked, implemented and tested.
The Create WBS process contains an in-built mechanism to ensure that the team actually implements all of the requirements. This is termed as 100% rule.
A completed WBS represents all the deliverables of the project – including the outcome of project management activities, such as documents and plans. If you are at the leaf node of the WBS structure (one that does not have further child nodes) and roll up all of the nodes into their parent, and roll up parents into their parents, till all the way up – it would cover ALL of the work that project team ever does. Hence this technique ensures that team does only requirements related work, nothing more, nothing less. This is called ‘100% rule’. More on this here.
Validate that Deliverables Meet Scope
When a deliverable arrives, you will have to verify them against the requirements. Customer acceptance is dependent on how well finished deliverables adhere to the defined scope.
The first team that does this, informally, is the development team itself. If you are talking about software project, then the team does this using primarily using unit tests and integration tests.
The quality team does this by systematically going over the test cases and also by performing various types of tests such as load tests, performance tests, functional tests, system tests, usability tests, and finally acceptance tests.
Control Modifications to Scope (More or Less than planned)
This is a crucial process in Scope management, to manage changes to project and product scope. Controlling scope is also a preventive or course-corrective exercise to ensure that team produces only what customer wants, nothing more or less. This is where change requests are generated too.
Although these processes appear to be nicely sequenced, in real project environment these processes overlap with each other, and with other processes from other knowledge areas in ways that are unique to that project.
Some of the processes are done at regular intervals when needed, some on a daily basis, and some just once in a phase.
Let us move on and understand the differences between Project Scope and Product Scope, in the next post.
