After a RFx pack has been created and the subsequent evaluation of responses, there will be a negotiation phase which then will result in the creation of a Statement of Work (SoW), defining the details for delivery.
There are various approaches to the creation of a Statement of Work; some critical items that should be defined within the SoW will be discussed here.
1. Commercial and financial terms
The SoW should include all relevant commercial and financial terms and items. This will include:
-
Fixed costs vs. time and material covering items like CPI increases, rate cards, etc.
-
Inclusions and exclusions (e.g. travel, work hours/overtime, etc.)
-
Payment terms (monthly vs. milestones; upfront vs. milestone; etc.)
2. Deliverables
Obviously this will be the main part of the SoW describing what the vendor will actually deliver. The content of this section will depend on the actual scope. Examples are:
The approach to each one of them may vary significantly and may depend on the (existing) relationship and prior experience with a vendor. In general it will be safer, but more time-consuming, to have rather too much detail in the SoW than too little.
Some items that should be included are:
Scope:
This may be very detailed or may just paint the “big picture”. The latter is permissible, if the vendor is well-known and has a proven track record, i.e. has proved to be trustworthy. The “big picture” approach otherwise carries the risk of client/vendor disagreement and additional cost (“This wasn’t defined in the SoW”).
Assumptions, requirements, inclusions and exclusions set clear boundaries for the engagement and will include the integration points – be that with applications, other vendors or existing environments.
Similar to the MSA there are certain advantages with the vendor providing the SoW. In the case of the MSA there should be less need to negotiate – as the vendor obviously will be happy with the MSA’s content. The risk is that the terms will be more favourable to the vendor than for the client and a vendor MSA is unlikely to be as comprehensive.
A typical vendor should have some experience in delivering a proposed solution, i.e. this should not be the first delivery ever (one hopes) and should therefore be well aware of the deliverables and requirement for a successful implementation. It should therefore be less effort for the vendor to create the initial draft of the SoW.
Regardless, if reviewing or writing the SoW one should ensure that the SoW closely aligns to the RFx requirements and response and consistently aligns across all related documents. It can be useful to have a 3rd party review the documentation (RFx pack, MSA, SoW, related procedures and policies, governance details, etc.) to ensure consistency and to minimise the risk of undesirable gaps.