Requirements: Defining Out of Scope: How important is it in your statement of work?

I have had this discussion with multiple people about how to define out of scope in a SoW. And one of the things which I, myself have said in the past and I keep hearing all the times from other manager’s is that it’s difficult to define the out of scope, given the fact that we know very little about the requirements.

Statement of WorkTrue. In reality, it’s very difficult to do an upfront requirements gathering. And without doing a detailed requirements study, we always end up dealing with fixed cost or capped time and material work.

In such cases, defining the out of scope is very important. The out of scope not necessarily have to constrain itself with the requirements. It is also very important to define the services which are not included.

Ah! You sound like a Chief Gyan Officer. Why do you think we should do this?
Say for example, you are a service provider, getting into an agreement with a company for adding additional features to their existing product or project. During your sales process your company would have given an overview of the various services you provide. For this contract, you may be thinking that you are responsible for only adding additional features, but your client might be under the impression that you are taking care of all the aspects of the application (which may not be true).

Other example could be that you have started the discussion with someone and signed the SoW, but now that person has left and you have got a new person as in-charge. Though, you could give the history/details to the new guy, but his perception of offshoring might be different.
So, it’s better to have this clearly defined in your statement of work so that it may be very helpful for you when there is a change or when things are not going well.

So, how do you define this?
Over a period of time, I realized including a responsibility matrix in the SoW will help in bringing everyone to the same page. My version looks something like this…

Functionality Description Vendor Vendee
Requirements Requirements (agreed format)
Acceptance Criteria
Wireframes
User Interface User Interface Design
Information Architecture
Architecture Architecture of the System
Architecture Review
Design for the individual components
Design Review
Code Code Quality Check (Reference: Document ABC)
Automated Unit Test Cases
Testing Creation of Test Plan
Creation of Manual Test Cases
Execution of Manual Test Cases
Test Case Reporting
Automation of Acceptance Test Cases
Functional Test Automation
Performance Testing
Load Testing
Deployment Build Automation
Deployment Helper Utilities
Test Environment Setup
Staging Environment Setup
Continuous Integration Integration of Build, Unit Tests, Acceptance Tests, Functional Tests

When you create this, it will clarify many things for you and your customer. There will be no assumptions. You are clear about what services you are going to provide and your customer will be clear about the services he is buying from you. If it’s co-responsibility then both the parties are responsible.

SoW is a legal document and having a detailed SoW (as much as possible) will always be helpful for both the parties involved.

Always Remember, Businesses are done using head and not with heart!!!

Happy Learning!!!

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s