Assumptions & Parameters
In continuing my series on writing good proposals I would like to cover the topic of assumptions and parameters. Up until now we’ve explored the earlier sections in a good proposal…description, scope, schedule and budget. Now it’s time to look at one of the last sections, which I call Assumptions and Parameters.
I remember years ago a school teacher told me that assumptions were dangerous. And he further shared…In order for me to remember this fact I should notice the word assume…broken down it says ass, u & me. Like, making assumptions makes an ass out of you and me. Not very funny…But memorable. Assumptions truly do represent a serious threat to successful business dealings.
However, in business it is sometimes necessary to assume certain facts in order to streamline communications. For instance…you can safely assume your client would like you to deliver work free of spelling errors. You can also safely assume a client will be happy if you deliver on time, on budget and free of defects. Other than the common sense stuff there is one (and only one) other time when making assumptions is not dangerous…and that’s when you communicate them. There’s that word again…communicate. It’s really important. Let’s consider a few examples.
Imagine you have been hired to build a web site for a client which is going to include HTML5 pages. You know this means a whole bunch of very popular browsers will not be supported. Is it safe to assume the client knows this? Negative ghost rider! I always include which browsers and other software will be supported in the assumptions and parameters when I start a new project.
Or, let’s say you are a wedding DJ and your bride and groom request a rare recording of an old song for their wedding reception. The song is only available on a scratchy old record album they dug out of grandma’s basement. Can you safely assume they will be OK with it when it skips in the middle of their critical first dance? No way. Write it down. The other important thing about assumptions and parameters is you can’t just write it down and assume the client will notice. That is equally silly…I try to review them once before the client signs and once again during the project kick off meeting. I also refer back to them if any required features end up in conflict with one or more assumptions.
In the end, again, it is all about communication. Don’t assume anybody knows what you are thinking…because they don’t. Every single conflict I have ever had in my professional life can be traced back to a miscommunication or lack of communication. It is fair to say most people I have encountered genuinely want to do the right thing…they just forget to communicate what their version of the right thing to do is. Myself included…