Some of the contracting sites force the developer to pay 10% guarantee upfront to take the work - this is a good idea. When they miss a deadline you have the right to cancel the project. The problem with this is you will never get your project - every developer delivers late.
When contracting out a job directly, without the safety of escrow, the client need to carefully consider how they will handle time, budget and spec trade-offs. It’s all down to the contract terms and payment schedule you define.
Definitely ask about there capacity to add resource if things start to slip. Find out their holidays and working hours. Ensure you can communicate frequently and easily. I have the world clocks on my desktop for the time zones I work in and the developers all in skype, this really helps
The best technique is constant communication & a bit of encouragement and praise can help.
Constant delivery (every couple of days) through a very small length project is the no.1 objective.
If you take the pressure off and stop communicating they see this a signal that its not a priorty for you & will work on anoither project. If you give them more than 4 weeks for a project they may decide to do another project first.
This needs the client to invest more time in the spec or have a spec written as a separate project and allow more time for daily project management / communication.
A good technique we use is called critical chain (there is a Goldratt book by the same name). Developers do 3 bad things for project management:
1. Overestimate to build in contingency to manage risk
2. Take all the time given for each task – rarely completing early even though they added contingency
3. Struggle to start and then go nuts near the final deadline
So a fake final deadline with compressed tasks is critical to get them moving at the right pace. Its sounds complex in the book but it’s actually very easy to do critical chain in a spreadsheet –
1. Create your project critical path as normal.
2. Half all the task-time estimates
3. Add on 50% of each task saving as an explicit task buffer
4. Combine all the other 50%'s and make a single project buffer after the last task so the final deadline is now after a very large buffer, but still the same date.
5. Save this as *your* project plan
6. Remove *all* buffers and re-schedule the tasks ASAP from the start date so you have an end date that is now 50% earlier.
7. Publish this to the developer as the real plan
Now when a task overruns you will know if you are in a task buffer (amber) or eating into the project buffer (Red) and can take action accordingly.