Creation of a Statement of Work (as part of the RFx process)


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:

  • Costs:
    1. 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.)
  • Service Levels and other possible penalties
  • Renewal and cancellation options
  • Transition In / Transition Out terms
  • Warranties and other specific items that are not addressed in the Master Service Agreement (MSA)
  • 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:

  • Software-related services
  • Hardware-related services
  • Consultancy
  • Software development
  • Cloud-related services; from infrastructure to software/solutions
  • Data centre-related services
  • Managed Services
  • 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:
    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.