By its very concept, ‘scope’ is a much broader, more generalized term than the actual ‘requirements’ or ‘specifications’.The scope defines the boundary for the requirements. It is not the requirement itself. Having said that, the scope must be well-defined enough to ensure that there are no surprises springing up during the subsequent stages of the project.
Scope cannot be very specific but since it is so closely tied to cost, it should be concrete enough to clearly establish the coverage of intended work.Needless to say, scope definition is a tightrope that must be cautiously tread; it’s like a scale that needs you to do a fine balancing act between the bigger picture and the details to achieve a comfortable middle ground. Here are a few tips that can help with the scope in your Statement of Work (SOW) or equivalent documents.Keeping these in mind will help the project progress smoothly while streamlining tasks and operations and keeping them efficient.
- Business-side coherence
- Technical Complexity Cognizance
- Contingencies
- Buffer for the expected tangibles
It is already well-known that one should prepare estimates considering all the directly apparent and behind-the-scenes work that will inevitably go into implementation. It is also known that a reasonable time buffer is good to add for any unforeseen circumstances that may arise. But it is also important to account for some of the other tangibles that cannot be written out upfront but are bound to happen.A case in point is given below:
As many of you might have experienced, there are always some things that come up as the app takes shape and you actually get your hands on it – image replacements, text changes, minor UI/UX modifications, small functional enhancements etc. Many a time, these are so tiny that they don’t really warrant a ‘Change Request’ document. But when many of these add up over time and multiple projects, it could sum up to significant effort. So the best solution would be to add an overhead in the estimates to cater to these kind of miscellaneous items. It may account for a small proportion of the overall cost but nevertheless it counts in the bigger scheme of things! It also keeps all stakeholders happy as they see the app getting refined and polished at no new, unforeseen cost.
- Draw the line with the OOS tool
Sometimes, the out-of-scope (OOS) items are more important than the in-scope! Leave nothing to the imagination here when you list out what is NOT covered as part of the deal. Discuss with your colleagues to see what can possibly become a point of contention and clearly spell out the same in this section. OOS items can be functional or non-functional requirements.
- Get the legalities right
- Project Goals
- Pre-requisites to starting the project
- In-scope items
- Out-of-scope items
- Deliverables from various stakeholders
- Project Process
- Schedule and Timelines
- Change Management Process
- Terms and Conditions
- The caveat that the estimates are subject to change after actual specifications are laid out
Have you had interesting, learning experiences dealing with scope in different kinds of projects? We’d love to hear them!
What CIO’s should do in 2016? Click on the image below to learn!
