I really like the idea of assigning hours to phases so you can charge overages on particular items. Seems like this kind of approach ensures clients make the most of the time allotted to them. They, too, must share in the budgeting responsibilities and consequences.
Simon – we share a lot, but I think our PSA is something we’ll keep under wraps. But my advice would be to make it yours. Don’t be shy about giving it some personality through design and copy.
Copy & paste the code below to embed this comment.
JoelD
Greg,
Great article, thanks for sharing some of the Happy Cog process. I was wondering if you ever tried the other approach you came up with of contracting for a paid discovery phase. After years of this never getting approval, a few of our recent clients have been open to it, and it really helped the project get a jump start with less surprises down the road.
I completely agree with the second approach being the better more agile approach, one that the client should see as more responsible. Just wondering if you’ve tried both.
We have done separate discoveries, and so far, it has worked great. My concern has always been that clients would take your findings and run, but in actuality, they usually stay on for more work.
Be vague—that’s to be grokked, as techies say, sometimes you’ve got to dare yourself. Mostly I don’t enjoy the business or project management stuff dealt with here, but this article struck some cords.
Our clients are very similar and being vague is exactly what we do as well. It not only protects you but it also is a service to the client by allowing flexibility. That said, if you don’t want to be flexible, then you might not want to be vague.
Greg, thank you for the article and taking time to create it. What is your recommendation/advice on using these types of agreements within an organization? I often find that if there is a good level of trust between a project lead and the stakeholder and a good deal of agile practices are being used that contracts and SOWs are not necessary and take more effort and resources to maintain than just having a conversation.
Thanks for the post. I used to do some freelancing work with Flash and I got into a situation when a client wanted more stuff done (re-developed) and since I did not explicitly specified the amount of time (buckets of time) that I’m gonna spend on doing what he wanted, we had a bit of a misunderstanding. Having read your post, I seem to realize how I could take care of that. At least, I’ll use the idea in the future. Thanks again.
Though my thoughts most likely won’t be too unique, I’m gonna say them anyway. :) We are all different people and we all expect (and agree for that matter) to different things, even though while talking with each other we may genuinely be thinking that we totally understand each other. So, you are supposed to put all your conditions on paper. Plus you also need to define the terms we are using because that can easily cause all sorts of misunderstandings as well.
I often find that if there is a good level of trust between a project lead and the stakeholder and a good deal of agile practices are being used that contracts and SOWs are not necessary and take more effort and resources to maintain than just having a conversation.
Yikes. Be careful. Trust can be there one day and gone the next, no matter how careful you are. I’d err on the side of caution and get things in writing. They are indeed a pain, but so are immunizations.
I looked at your SOW; you prob. should include language regarding the IP rights to open-source & 3rd party software after the section on Designer’s Tools.
18 Reader Comments
Back to the Articlewestphahl
Would it be possible to share an example of your PSA? Just curious :)
Best regards,
Simon
zepner
I really like the idea of assigning hours to phases so you can charge overages on particular items. Seems like this kind of approach ensures clients make the most of the time allotted to them. They, too, must share in the budgeting responsibilities and consequences.
Greg Hoy
Simon – we share a lot, but I think our PSA is something we’ll keep under wraps. But my advice would be to make it yours. Don’t be shy about giving it some personality through design and copy.
Paul Burton
Excellent overview Greg.
“Be vague” is the best advice in this article and a reality that took me years of dealing with clients to understand and implement.
That said, I have one minor clarification:
“¢ An MSA (contract) should be specific and buttoned down tighter than Joan River’s face (~Dan Rather).
“¢ The SOW (statement of work) should be vague. The last thing you want is to have your specificity establish job-specific expectations.
Greg Hoy
Paul, your clarification is spot on. Thank you.
TeachingAway
@Simon, I have a service agreement up on docracy – https://www.docracy.com/5598/website-identity-design-contract
I might make a few modifications based on this article (I work on the legal end, so its always nice to hear thoughts from the design end).
Eric
squarecat
AKA CYA…
JoelD
Greg,
Great article, thanks for sharing some of the Happy Cog process. I was wondering if you ever tried the other approach you came up with of contracting for a paid discovery phase. After years of this never getting approval, a few of our recent clients have been open to it, and it really helped the project get a jump start with less surprises down the road.
I completely agree with the second approach being the better more agile approach, one that the client should see as more responsible. Just wondering if you’ve tried both.
Joel
Greg Hoy
Joel –
We have done separate discoveries, and so far, it has worked great. My concern has always been that clients would take your findings and run, but in actuality, they usually stay on for more work.
Mykola
Be vague—that’s to be grokked, as techies say, sometimes you’ve got to dare yourself. Mostly I don’t enjoy the business or project management stuff dealt with here, but this article struck some cords.
Berck
Our clients are very similar and being vague is exactly what we do as well. It not only protects you but it also is a service to the client by allowing flexibility. That said, if you don’t want to be flexible, then you might not want to be vague.
grhook24
Greg, thank you for the article and taking time to create it. What is your recommendation/advice on using these types of agreements within an organization? I often find that if there is a good level of trust between a project lead and the stakeholder and a good deal of agile practices are being used that contracts and SOWs are not necessary and take more effort and resources to maintain than just having a conversation.
businessinvietnam
I agree with this article, very helpful.
Regards,
Michel
Business in Vietnam, Vietnam Business
mrcereal
Someone can say the life is the art of develop relationships :)
vincewicks
Thanks for the post. I used to do some freelancing work with Flash and I got into a situation when a client wanted more stuff done (re-developed) and since I did not explicitly specified the amount of time (buckets of time) that I’m gonna spend on doing what he wanted, we had a bit of a misunderstanding. Having read your post, I seem to realize how I could take care of that. At least, I’ll use the idea in the future. Thanks again.
kenneth.von.rauch
Though my thoughts most likely won’t be too unique, I’m gonna say them anyway. :) We are all different people and we all expect (and agree for that matter) to different things, even though while talking with each other we may genuinely be thinking that we totally understand each other. So, you are supposed to put all your conditions on paper. Plus you also need to define the terms we are using because that can easily cause all sorts of misunderstandings as well.
Greg Hoy
grhook24 said:
Yikes. Be careful. Trust can be there one day and gone the next, no matter how careful you are. I’d err on the side of caution and get things in writing. They are indeed a pain, but so are immunizations.
seezee
Eric,
I looked at your SOW; you prob. should include language regarding the IP rights to open-source & 3rd party software after the section on Designer’s Tools.