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 just 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?
Plan How To Manage Scope
This is where the process to collect, define and manage 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 defined, how is it measured, what is the change process, and who accepts deliverables and verifies scope.
Collect Project Requirements
How do you identify and document what customer wants? 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.
Work Breakdown Structure
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.
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.
Control Modifications To Scope (More or Less than planned)
This too is a crucial process in Scope management. Controlling scope is 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 they 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.
Let us understand the differences between Project Scope and Product Scope, in the next post.