1. Check the Agreement, Contract or the MOU that the organization has signed with the Vendor
Before sending out an SOW to a proposed vendor, the PM and his team need to check if their organization has already entered into a relevant Master Service Agreement/Contract with the Vendor. This is sometimes also mentioned as a MoU (Memorandum of Understanding) by some organizations. It is this agreement that describes the handshake between the two organizations and also the various confidentiality clauses related to the organizations information, data and products that the vendor needs to maintain secrecy about and ensure that none of this information is disclosed to the external world without prior approval from the customer. This document is the legal binding document between the two organizations which also include the various penalty related information in case the vendor fails to adhere to the conditions or the constraints set forth within the agreement/contract. In case of a scenario, where the PM cannot find a Service Agreement/MoU/Contract with the Vendor, he/she need to contact the company’s concerned legal department to understand about any existing agreements with the vendor or if the organization needs to enter into a new agreement with the vendor prior to entering into an SOW discussion with the vendor.
The below list out the main topics that must be covered within an SOW for an organization to gain maximum benefit by awarding a project to a specified vendor
2. Scope - Project Background and the new Scope Information
Any SOW that is being sent out to a vendor should have clarity on the project background information, product or the applications (that get impacted because of the current project) related history information, technologies that the project, product or the applications are built with, a high level overview of where the project, applications and its architecture sits within the organization and what’s the new thing that will be introduced as part of the current project/SOW. A more detailed information needs to be presented for the scope of work that needs to be implemented as part of the current SOW – this should cover for the strong and specific requirements of what needs to be developed, the inputs, outputs, validations, UI, integration with other pieces, standards to be used, the end-user behavior, architecture, technologies to be used, integration process etc. It is also important to mention the type of software methodology (Waterfall, Agile, etc.) that the customer wants the vendor to use for the given scope of work and also provide clarity on how the scope of work will be elaborated and what is expected of the vendor in terms of the implementation and the corresponding impacts of time, cost and quality based on the methodology selected. It is mandatory that as much details that can be provided in this category of the SOW would help the organization to get a maximum work results as possible. Even a small requirement that’s missed here will need to be developed at an additional cost later in the future. This section should also list out the various assumptions and the dependencies that being thought of for the project – be it code, applications, projects, people, quality, time, cost people etc. – it is worthwhile that these are all evidently listed out in the SOW as well to avoid war-room discussions in the future.
3. Constraints - Technology, Methodology, Testing Considerations, Review Procedure and Penalty Conditions
Once the scope or the so-called requirements are clearly stated with details in the SOW, the information related to the technologies that need to be re-used/used for the current project need to be specifically mentioned with precision on the type, version, degree of complexity and support considerations. This is necessary to ensure that the vendor implements the project using the technology and architecture standards that are on-par with the organization and that these can be easily plugged into the current system without any hindrance to the integration, flexibility, scalability, reliability and performance specifications. Details about the process of Peer Review, Product Quality, Unit Testing, Integration Testing, Data Testing, Security and performance testing and the success criteria for the testing cycles must be clearly stated in the SOW. On the other hand, these success criteria should also be mapped to the corresponding penalties that the vendor would need to face in case of non-compliance with any of the delivery requirements by the vendor. This could also lead to the vendor having to completely re-execute the whole project with no additional cost to the customer/organization.
4. Change Control - How to handle change to the scope of the work or project
One of the most common problems heard in the software services industry even today is that there are always soft and hard communications going back and forth between the customer and the vendor over the issue of scope change and that there has been a misunderstanding of scope between the customer and the vendor which leads to a situation wherein the customer expects a part of the product as part of the defined scope whereas the vendor retracts stating that this scope was not mentioned with the SOW requirements and hence would need to be treated as a scope creep or a scope change. No just this, in such situations, any small change in scope would trigger a corresponding impact of time and cost for either the vendor or the customer depending on the direction the communication wind moves. In order to avoid the above mentioned type of scenarios, an SOW should always contain details about what would mean by a change for the work/project under consideration. It should clearly state what kind of implicit/explicit requirements would be treated as a change and if at some change is identified, define the process route that would be taken to formally approve that change request and also highlight the corresponding implications of time/cost to the project and also to the Customer/Vendor. Rules/Templates/Documents about the change control are normally included within a SOW and these explain the members of the Change Control Board for the current project and the also the process of change control that would need to be followed for a successful project execution.
5. Boundaries and Conditions - Type of Contract, Constrictions of Time and Cost and Project Extension Implications
This is by far the most important information that must be included in a vendor SOW. It encompasses the information related to the type of contract the customer and the Vendor agree to for the given scope of work. Though there are several types of contracts that exist out there, but the “Fixed Cost”
and “Time & Material” are the most common types of contracts that the industry organizations choose based on the type of the project/work they are dealing. If we think from a customer perspective, a” Fixed Price” contract is the most advantageous since it would mean that the vendor agrees to provide all the requirements mentioned for total fixed cost mentioned in the SOW including any bug fixes in the new product, penalty conditions and support the new product as per all the conditions mentioned in the SOW. Most “Vendors” therefore think twice or thrice before they agree to a “Fixed-Price” contract, since once they agree to a fixed cost, they need to abide by all those delivery conditions till the end of the scope of work. But, if you are a customer, a “Fixed-Price” contract is the one you should aim at.
The second one, “Time & Material”, as the name suggests, charges the customer for the amount of time the vendor resources spend on the project (Based on the corresponding resource per hour costs) irrespective of the amount of work completed. The “Time & Material” contracts can be time-bound as well wherein a time constraint if given to the vendor which means that the given scope of work needs to be completed within the given time-frame, no matter how many resources the vendor fields in for the project for the given time-period. And the vendor can charge the customer for the total hours that the vendor resources spend on the project within the given time frame. It is also easier to extend a “Time and Material” contract, since it’s only the new scope of work that gets added to the project and there is no need to add any new budget numbers for the new scope since the contract resource costs and contract type are already agreed upon and it’s just the add-on hours that the vendor will need to charge the customer for the additional scope of work.
An SOW should also contain information about the Payment schedules - meaning the contract should clearly state as to when and in which currency will the payments be made to the vendor based on the progress of the scope of work.
Last but not the least, any SOW, whether it’s written by a customer or a vendor, need to the reviewed and agreed by both the customer and the vendor organizations from a legal perspective, ant mutual corrections that are required need to made and then need to the formally signed by the authorized signatories of the both the parties to ensure that both the customer and vendor are now bound by a strong legal document before they start implementation of their first project promising harmonious partnership for years to come.
Don't forget to leave your comments below.
About the Authors
Ambadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP
Ambadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP has extensive experience in the fields of software project planning, scheduling, risk management, budget management, vendor management, contract management, execution, tracking, monitoring, controlling, quality assurance, and on-time delivery. He is a Project Management Professional (PMP)® credential holder, PMI Scheduling Professional (PMI-SP)® credential holder, and has delivered projects over a wide range of domains, such as Leak Detection Software, Semiconductor software, implementing desktop/mobile websites, and Bio-Information Management Systems, in addition to the field of software services. He earned his bachelor’s degree (B.Tech) in chemical engineering from Pune University, India and earned his master’s degree (M.Tech) in computer-aided process and equipment design from REC/NIT in Warangal, India. Mr. Murthy can be contacted at firstname.lastname@example.org.
Co-Author: Shreenath Sreenivas, B.Sc.(Hons.), M.Sc, PMP
Shreenath Sreenivas, B.Sc.(Hons.), M.Sc, PMP has in-depth knowledge and experience in software project planning, integration management, requirement gathering, risk management, scheduling, vendor management, contract management, execution, monitoring, controlling, quality assurance and on-time delivery. He is a Project Management Professional (PMP)® credential holder and has delivered projects successfully across a wide range of domains, such as Pharmaceuticals, Bio-IT (LIMS), Tax and Accounting, Mobile Web Apps; in addition to the field of software product development and consulting. He earned his Bachelor’s B.Sc. (Hons) & Master’s M.Sc. degrees in Industrial Chemistry from the Indian Institute of Technology (I.I.T.), Kharagpur, India. Mr. Shreenath can be contacted at email@example.com.