The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner. Please visit their site for more information.
We’ve looked at how you go about communicating scope, now let’s look at the concept of how much effort should go into defining the scope of your project or product development process. This article is based somewhat on text from the book “Customer-Centered Products” by Hooks and Farry.
Scope definition is one of the most critical aspects of project or product management. Without proper scope definition, a project is destined to experience continual scope creep resulting in ongoing timeline and budgeting issues.
When the scope creep happens, the only way around the timeline and budgeting issues will be to introduce many change orders to your customer which will likely decrease their satisfaction level significantly. You’ll still have the timeline issues and the budget issues, but you’ll be able to justify them with the stack of change orders – assuming the customer actually approves all of them rather than flat out canceling the project altogether out of frustration. A much better route is to spend the proper amount of time up front correctly identifying and documenting scope and gaining agreement with the customer on that carefully defined scope.
How much is enough?
Look at your own experience for clues on how big your scope definition effort should be. If large numbers of requirement changes are typical on your projects, it’s likely that you have not been adequately defining scope up front. Increasing your scope definition effort and its dissemination may be especially helpful if a large proportion of prior projects’ requirement changes have involved fixing inconsistencies or dropping low-priority requirements. If your requirement reviews have been plagued with lengthy arguments about the need for particular requirements, you have fallen short on either scope definition or communicating the scope definition or both. A small increase in your scope definition can streamline the requirement definition effort and save a fortune in product development resources by preventing divergence.
Sometimes people are reluctant to draw boundaries early in the project for fear of limiting the possibility for truly creative “breakthrough” solutions. Much has been made of getting many people together for free-flowing “brain-storming” sessions. At first glance, our scope definition might look very limiting. In fact, breakthrough solutions come not from lots of minds operating without boundaries, but from true understanding of and focus on the real need and constraints. This understanding will free you and your team from breakthrough-limiting mindsets.