When I think for many years, even before I played Happy Cog, I think we tended to think of projects as a bit of a one-size-fits-all-ish. Beforehand, we determined what tasks we were going to do, what artifacts we wanted to produce, how many comps we wanted to design and how many revisions we were going to offer. It usually consisted of a site plan with three revisions, 10-12 wireframes with three revisions, three different design comps, created by three different designers, which were reworked three times, and HTML/CSS models for 10-12 pages. For almost every project. This has led to a number of problems. Whether you`re hiring a painter, a builder or a creative company, you need to think about requirements that are also expectations. In our world, there are business requirements, content requirements and technical requirements, to name a few. And you might think that a contract is the right place to document these requirements. I know that I have tried to identify as many of these details as soon as possible in order to minimize risks and ambiguities. It`s hard to do. I would say that the treaty is not the appropriate way to articulation the requirements.
However, the contract should indicate a process in which requirements are collected, assessed and prioritized. What you can do depends on your project budget and program. “The SOW (work statement) should be vague. The last thing you want is for your specificity to define specific expectations. @Simon, I have a service agreement on the work of a thief – www.docracy.com/5598/website-identity-design-contract Although my thoughts are probably not too unique, I will still say them. 🙂 We are all different people, and we expect (and we agree) on different things, even though, speaking to each other, we really think we understand each other perfectly. So you should put all your conditions on paper. In addition, you also need to define the terms we use, as this can easily create all kinds of misunderstandings.
The contribution of the work statement may include business needs, business case, description of the scope of the project and strategic plan. You can create a request/change order safely. But it`s going to get your client fired. In addition to abandoning the pre-prescribing of certain tasks and benefits in advance, we have converted our model into Buckets of hours. We rent our jobs at a fixed fee, but we also know how many hours we have allocated for each stage of the project. After 75% of the hours of a phase, we fire a shot at the bow to inform the customer. Then, when they hit 100% and they use every hour, we stop working and they have to buy more.