Agreements = Expectations

by Greg Hoy

18 Reader Comments

Back to the Article
  1. Would it be possible to share an example of your PSA? Just curious :)

    Best regards,
    Simon

    Copy & paste the code below to embed this comment.
  2. 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.

    Copy & paste the code below to embed this comment.
  3. 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.
  4. 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.

    Copy & paste the code below to embed this comment.
  5. Paul, your clarification is spot on. Thank you.

    Copy & paste the code below to embed this comment.
  6. @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

    Copy & paste the code below to embed this comment.
  7. AKA CYA

    Copy & paste the code below to embed this comment.
  8. 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

    Copy & paste the code below to embed this comment.
  9. 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.

    Copy & paste the code below to embed this comment.
  10. 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.

    Copy & paste the code below to embed this comment.
  11. 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.

    Copy & paste the code below to embed this comment.
  12. 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.

    Copy & paste the code below to embed this comment.
  13. I agree with this article, very helpful.


    Regards,
    Michel
    Business in Vietnam, Vietnam Business

    Copy & paste the code below to embed this comment.
  14. Someone can say the life is the art of develop relationships :)

    Copy & paste the code below to embed this comment.
  15. 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.

    Copy & paste the code below to embed this comment.
  16. 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.

    Copy & paste the code below to embed this comment.
  17. grhook24 said:

    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.

    Copy & paste the code below to embed this comment.
  18. 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.

    Copy & paste the code below to embed this comment.