- Impact
- 463
I'm not sure if this is the right place to put this thread, so mods feel free to move to somewhere more appropriate if you wish.
After reading through the Adam Dicker thread, I noticed there were a lot of people who are leaving themselves exposed when it comes to digital development.
I work for a development studio in Sydney, Australia that has worked with some of the biggest brands in the world. I thought it would be useful if I did a quick high level outline of some of the processes we use and documents we require to be signed to make sure everything runs smoothly. This is by no means the only way to do things, but is nevertheless a useful framework.
This can help protect both parties on projects big and small, and ensure you’re not throwing away your hard earned money. Although I’m talking from a development perspective, elements of this process can still be used on digital services such as SEO, lead generation, content writing and so forth.
Many of the problems in the Dicker thread would not have arisen, or would be much easier to clear up if these processes had have been followed.
1. Define the scope
If you want work done you should provide a detailed brief to the prospective supplier outlining exactly what you want them to deliver. This could include such things as –
This will allow the potential supplier to quote more accurately, and will have everyone on the same page from day dot with reasonable expectations.
2. Formal proposal
One the scope and price has been agreed upon, ideally the supplier should supply you with a formal proposal outlining everything they promise to deliver. If you’re hiring a freelancer there is a chance they won’t do this for you. If that’s the case, put together your own and make sure both parties sign it. This is basically a formalised version of the brief but will include extra information such as -
3. Payment Terms
We don’t start any work internally until a 50% deposit is paid, and this is with long standing clients. We definitely wouldn't start work without a deposit for a new client, or someone over the internet. (With tiny jobs sometimes being an exception)
It is pretty standard to pay 50% deposit before work commences and 50% on completion. This way, if items in the formal proposal have not been delivered, you have something to fall back on. It is not reasonable to pay 100% of the cost upfront, especially when we're talking thousands of dollars when work has not yet begun.
It is also common to do milestone payments such as 30% deposit, 20% on delivery of front end, 20% on delivery of CMS, and then 30% on completion.
This should all be specified in the Formal Proposal.
4. Project Release Agreement
This is less for the client and more for the supplier, but is worth mentioning anyway as its part of any good process and you should know what it is if one is placed in front of you. Once the product has been delivered, a Project Release Agreement should be signed signifying that the project has been completed and satisfies all the requirements in the formal proposal.
At this point, two things should happen. One you should pay the final deposit on the work and two, any warranties should begin from this date.
These are four pretty simple thing but they clearly define 1) What you expect, 2) What the supplier promises to deliver, 3) What the payment terms are and 4) When the project has been completed. You'll have all this in writing, and should you have any issues you'll have a much easier time proving who was obligated to do what. "He told me he'd do this for me" in a Skype chat doesn't cut it in the real world.
Again, this is all high level stuff, so if you have any questions let me know and I'll try and answer. I can maybe provide some sample documents if you want as a template, so let me know if that is something people are interested in. As I'll have to significantly modify our internal ones for IP and privacy reasons, can get around to it when I can.
After reading through the Adam Dicker thread, I noticed there were a lot of people who are leaving themselves exposed when it comes to digital development.
I work for a development studio in Sydney, Australia that has worked with some of the biggest brands in the world. I thought it would be useful if I did a quick high level outline of some of the processes we use and documents we require to be signed to make sure everything runs smoothly. This is by no means the only way to do things, but is nevertheless a useful framework.
This can help protect both parties on projects big and small, and ensure you’re not throwing away your hard earned money. Although I’m talking from a development perspective, elements of this process can still be used on digital services such as SEO, lead generation, content writing and so forth.
Many of the problems in the Dicker thread would not have arisen, or would be much easier to clear up if these processes had have been followed.
1. Define the scope
If you want work done you should provide a detailed brief to the prospective supplier outlining exactly what you want them to deliver. This could include such things as –
- Any relevant background information
- Functional specifications
- Wireframes
- Designs
- Devices the site or application should work on
- Deadlines
This will allow the potential supplier to quote more accurately, and will have everyone on the same page from day dot with reasonable expectations.
2. Formal proposal
One the scope and price has been agreed upon, ideally the supplier should supply you with a formal proposal outlining everything they promise to deliver. If you’re hiring a freelancer there is a chance they won’t do this for you. If that’s the case, put together your own and make sure both parties sign it. This is basically a formalised version of the brief but will include extra information such as -
- Testing – What devices (and OS versions), browsers (and browser versions) will be the benchmark for testing?
e.g Technical Testing and UAT (User Acceptance Testing) in IE10+, Firefox30+, Safari5.1.7+ and Chrome35+ on PC and Mac equivalents. iPad 3, iPhone 5, 6, 6 Plus and Sony Xperia Z2 with the latest OS and default browser versions (at time of proposal sign-off) will be the benchmark testing environments for mobile and tablet.
- Specify if hosting costs, domain name registration, SSL certificates etc are included in the project cost. Who’s responsibility is it to set these up?
- Development timeframe
- Payment terms
- Warranty information
3. Payment Terms
We don’t start any work internally until a 50% deposit is paid, and this is with long standing clients. We definitely wouldn't start work without a deposit for a new client, or someone over the internet. (With tiny jobs sometimes being an exception)
It is pretty standard to pay 50% deposit before work commences and 50% on completion. This way, if items in the formal proposal have not been delivered, you have something to fall back on. It is not reasonable to pay 100% of the cost upfront, especially when we're talking thousands of dollars when work has not yet begun.
It is also common to do milestone payments such as 30% deposit, 20% on delivery of front end, 20% on delivery of CMS, and then 30% on completion.
This should all be specified in the Formal Proposal.
4. Project Release Agreement
This is less for the client and more for the supplier, but is worth mentioning anyway as its part of any good process and you should know what it is if one is placed in front of you. Once the product has been delivered, a Project Release Agreement should be signed signifying that the project has been completed and satisfies all the requirements in the formal proposal.
At this point, two things should happen. One you should pay the final deposit on the work and two, any warranties should begin from this date.
These are four pretty simple thing but they clearly define 1) What you expect, 2) What the supplier promises to deliver, 3) What the payment terms are and 4) When the project has been completed. You'll have all this in writing, and should you have any issues you'll have a much easier time proving who was obligated to do what. "He told me he'd do this for me" in a Skype chat doesn't cut it in the real world.
Again, this is all high level stuff, so if you have any questions let me know and I'll try and answer. I can maybe provide some sample documents if you want as a template, so let me know if that is something people are interested in. As I'll have to significantly modify our internal ones for IP and privacy reasons, can get around to it when I can.
