Most IT projects involve deliverables. Typically this is an IT system, a website, or an Intranet. However life is rarely that simple. Deliverables often include requirements documents, solution specifications, graphics designs, project plans, test plans… the list is endless! Depending on your role in the project (Sponsor, PM, BA, developer) you might have varying views on the usefulness of such documentation. But, extreme scrum aside, they are generally a fact of life.
Writing ‘Solution Specification’ as a deliverable doesn’t really mean anything, especially to clients who aren’t as used to these type of documents as you are. Such a document could be anything, could include anything, and could take many formats. For example does your solution spec include wireframes? Graphic designs? Test scripts?
More importantly what does your client think it includes? If they are expecting fully mocked up wireframes and designs, and you solution spec only includes bullet points of page content, then you might have an issue.
Easiest way round this problem? Just show the client sample documents as part of your sales process or pre project meetings. Show them another clients deliverables (with their permission) or create a random anonymous version for just this purpose. Actually putting something in front of the client will help them understand what they are getting, and maybe highlight areas where you expectations differ.
It might sound simple, but you’d be surprised the number of times I’ve seen this cause problems. In the worst cases you can end up getting into ‘scope creep’ conversations and no one likes those! So avoid the hassle and just show them what they are getting upfront. Minimal effort, big payback.
