Posted by:Ranjani Rao January 22nd, 2016

In this age of rapid software application development and especially with the shorter cycles taken to build mobile apps, the agreed-upon scope of work can often become a contentious issue and unless one is careful in terms of scope definition, quite a bit of unforeseen work and money can be at stake.This is unwanted tidings for both the vendor and the client since it leads to unplanned stages in the project and can affect budget and milestones.

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
As clients, people may sometimes ask for a lot of features that may not really gel well with the primary business goals of the app and at the other end of the spectrum, they might not even be aware of the need for a business-critical feature. This is where business analysis and pre-sales professionals can be of help.A good distillation of features to arrive at the crux of what is really good for the app will stand the project in good stead for early completion and ease of enhancements at a later stage.’
  • Technical Complexity Cognizance
        While drawing out in-scope items, ensure you have at least a high-level idea of how each of them can be technically implemented. Having a technical architect evaluate the complexity of the same is essential.  Call out features that need 3rd party integration or additional work that may not be apparent with the ‘business definition’ of the requirement.This helps all stakeholders arrive at an agreeable cost even if not all of them are well-versed with technicalities.It also helps plan for the next steps of work.
  • Contingencies
If you are not sure of the feasibility or estimate of a particular feature at the scope-definition stage, choose to leave it as an open-to-estimation item that will be decided upon during technical design or implementation.Also, propose alternatives in the SOW just in case the feature turns out infeasible. Having alternatives laid out at this stage will help the team design the app keeping in mind these possibilities.
  • 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
All said and done, the scope document must ensure that no party has to unwittingly pay the price for changes in stakeholders’ decisions or choices. Ensure you clearly outline the following
  • 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!

Leave a Reply

Your email address will not be published. Required fields are marked *