I review a lot of documents and provide pricing and contract negotiations advice to clients. Something that bothers me having started my career in consulting is how abysmal the implementation statement of work (SOW) is from most software vendors. For those that do not know what a SOW is, it is pretty much what is says. It is a document in conjunction with your software contract that outlines the work the service provider will perform for the client to implement (or more) the software application. It is a very important document because it enables the service provider and the client to have clear understanding of the scope of work to be performed (and how changes in scope will be managed), the resources required to do the work, and the expected cost. You would be surprised how many SaaS contracts I see where there is no accompanying SOW, just a line item in the contract that provides a price for implementation. There may be a marketing brochure/document that outlines the implementation approach, but nothing concrete that the client can go back to if there are problems during implementation. Even small organizations that are buying relatively inexpensive applications should insist on at least a basic SOW that includes the following items:
Scope - This section would give the provider's overview of the project as they see it and the solution proposed.
Approach - This section would tell the customer how the vendor is approaching the project. This includes what methodology they use and how they want to work with the client to achieve a successful project (including confirming how success is defined). Ideally, the methodology would spell out for each stage of the project what the customer and provider responsibilities would be. There can be a disconnect on approach. Some vendors have a very structured, "fill in the blanks" approach to package configuration that requires customers to provide specific inputs at very specific times to support rapid implementation. For some customers, especially in consensus-driven organizations, it can be difficult to provide that information in a timely fashion which causes frustration for both the customer and the provider.
Resource Requirements/Staffing - This should include a proposed project organizational chart with external staffing roles identified. If the project is scheduled to start within 2 months of the SOW agreement, specific named resources should be included for key roles (like Project Managers and Team Leaders). Resumes for these individuals should also be included with references (for larger projects, you should do due diligence on the people in the key roles). It should also be clear about what work will performed on-site vs. off-site.
Roles and Responsibilities - Provides additional detail for the roles identified on the organization chart so expectations are clear about responsibilities in each role.
Implementation Tasks and Estimates - This is pretty straightforward. This should list the major tasks and activities and the estimated effort for those tasks (ideally broken down by provider effort and customer effort). It is a high-level workplan often accompanied by a Gantt chart that shows the timeline for the project.
Assumptions - These are the assumptions the provider made in estimating the work effort and duration in the previous section. Transparency is key here. A customer needs to make sure that the assumptions are valid.
Billing Rates - There are two choices here: billing rates by role or blended average rate. I think it is easier to manage a blended average rate, but it depends on what kinds of roles are required for the specific project. The main point is that the desired state is to know by role how much work effort is expected and at what cost. For providers you will be doing ongoing work with, it is often desirable to create a master service agreement which includes agreed to terms and conditions and billing rates for all service engagements with the provider.
Costs - There should a summary of costs by either high-level task/activity or role (or both) and how the client will be billed for the services performed (time and material, fixed price, milestone-based, etc.) This can be combined with the implementation tasks and estimates as well.
Engagement Guidelines - This would include things like issue management, change order management, and travel and expense policies.
Software vendors may push back and say that we are doing a fixed price contract so you do not need to worry about this level of detail, especially for a relatively small purchase. I think that is plain wrong. Without this level of detail, you do not know what you are buying and cannot compare bids from multiple providers. Customers often are frustrated by the large differences in cost and effort for implementing similar solutions. HCM software vendors need to step up there game. There is no excuse for not doing a proper SOW as much of the work can be automated (just as RFP responses are now largely automated).
What do you think? Am I missing something important in the minimum SOW? What have you found in dealing with software vendors (SaaS or not) in terms of implementations SOWs?
Well said, Jim. I would add that it's important to spell out the roles, responsibilities, and expectations of the client team members as well. Too many projects fall behind because the client has been unable to dedicate the right number and types of resources to support the implementation.
Posted by: Karen Beaman | August 07, 2010 at 04:43 AM