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.
True. 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…
|Requirements||Requirements (agreed format)|
|User Interface||User Interface Design|
|Architecture||Architecture of the System|
|Design for the individual components|
|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|
|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!!!