After creating your statement of work, and ensuring that it’s crystal clear with activities and deliverables broken down, put into context with clear language, assumptions, and assumptions and properly checked – it’s time to share it with your client.
The temptation can be to stick it in an email and send it on its merry way, crossing your fingers that the client is going to approve it. Therein lies the challenge – the point of creating a SoW is not just to have a wonderful plan for how to deliver a project but to get client signoff so work can get started. So how do you seal the deal and increase your chances of your SoW getting approved?
What’s the catch?
Depending on your client’s previous experience they can be understandably nervous about signing of your SoW because they’re worried that you’re not actually going to deliver what they need. Their ass is on the line and ultimately they don’t want to lose their job. Particularly if the clients don’t fully understand what they’re agreeing to, they can get nervous about signing off a SoW and you start a painful back and forth of revisions that take weeks to be resolved. You need to help your clients understand the SoW isn’t a cunning trap, which when signed, will destory their career.
Catch them up
Talk it through – as much as possible, don’t just hand it over with no explanation So don’t just lob it over the wall and hope for the best. You don’t want to seem disingenuous – you’re not going to build trust with the client if you’re just closing your eyes and hoping for the best. The purpose of the SoW isn’t just to cover our back’s, it’s to align expectations on both sides.
So instead of sending the SoW over by email, make the SoW finalization a conversation, rather than a one-sided rant. Start with reviewing the project goals and the criteria for success and then join the dots by sharing the context for the approach, the specifics around the deliverables, your assumptions and why you’ve made them and how this all ultimately leads to project success.
Start the process of working with your client to tweak it together to ensure that the approach and deliverables are understood and clearly articulated. They need to be comfortable with what they’re signing off. It should feel like it’s a team effort – by involving the client there’s a shared ownership which will build trust and expedite the signoff process.
Ultimately you’re trying to make a conscious shift away from getting a glorified and horrendously complex estimate approved to a shared understanding of success and the best way to get there. Don’t forget to be honest about what you don’t know. Educate the client that you don’t know everything yet – you’re not going to able to include everything within your SoW. In many ways, at this stage, it doesn’t matter, as long as you’re clear about the assumptions you’re making.
It’s not an all-inclusive deal
In your conversations and detailed in your SoW, you need to be clear about what’s not included – Obviously it’s impossible to detail everything a project isn’t going to include, but be sure to discuss areas that are specifically excluded which may include legal advice for contesting, content generation, asset sourcing and licensing – video, images, and fonts, can start becoming very expensive, especially if you’re forking out each year to renew licences.
Additionally, think about expenses, travel, travel time, user testing, incentives, email broadcasting and any post-launch work or optimisation including bug fixing which is part of the software development lifecycle. Finally, be clear about whether or not the development of SoWs for future stages of the project are included.
Sharing is caring
Teaming together to tweak and get signoff on the SoW will ultimately make your life easier. Yes, it’s caring for your clients but really you’re doing yourself a favour too. If the project hits a significant snag, rather than resorting to pointing to the SoW, a document, you have a conversation to refer to; ‘Remember when we discussed…’ is much better than telling the client; ‘But in the SoW it says…’. The reference point shifts from a document to a relationship, which has a much better chance of being successfully resolved.
What do you think?
What do you think we’re missing? What else should PM’s be thinking about when developing a statement of work? We’d love to hear if you’ve got any tips too – why not share them using the comments below?