Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For SOWs, I find that it helps to keep them very explicit about the larger goals and the "why" of the project, but vague on details, and then enter into an agreement where the customer pays you to keep scope at a level where the larger goal and "why" can be accomplished within budget, not into an agreement where the customer controls the scope and you just balloon the budget if they increase it.


I tend to keep my SOWs vague so allow for reprioritization of work and protect myself. I also never write SOWs on basis of outcomes, but as an activity. Ie here is what I will do, but if you decide to not take my advise, don’t blame me if the desired outcomes aren’t delivered. This makes a big difference when chasing up invoices.


I read that Alan Weiss preferred to keep SOW detailed so that the client cannot give you extra work during the scope that was not the initial focus due to the vagueness.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: