The little black book that could

Part 1 – Introduction and Description of the problem
Part 2 – Requirements and you
Part 3 – Tracking Features and Bugs
Part 4 – The little black book that could
Part 5 – Your developers – Don’t be a prick
Part 6 – Wrapping up

Part 4 – The little black book that could

So here comes another insight into building projects with outsourced labor found online.

You are going to get burned.

Yes, no beating around the bush. You are going to have bad experiences, you are going to get burned.
Granted, the cost of those burns is going to be manageable – we are looking at cheap, outsourced labor, after all. Still, it is going to sting.

So we are going to try and keep that sting to a minimum.

So what am I proposing to avoid those half-built websites, shoddily thrown together backends, badly designed layouts?

Of course, making one of those trusty excel sheets to keep track. (you knew that was coming, didn’t you?)

Fool me once – shame on you. Fool me twice – shame on me.

It will still happen. You write great specs (of course), you communicate clearly and concisely (naturally), you offer a fair payment for the work (par for the course) and still – shit happens. Or in the age of the net – excuses happen.

Deadlines seem to have a bad effect on pets and relatives of all kind.

Time to go meta

After cutting your losses, renegotiating or transfering your work to another worker, comes the time for your meta-work.
(I define this as work above the level of the project or any ongoing work, defining strategies and processes.)

In this case, this means keeping track of people you gave work to and how they performed.
Besides keeping track of nicknames / avenues of contact, keep track of the deadlines, slippages in deadlines, failures and reasons for failure.
(This is the time for some humble reflection on your own work, such as specifiactions as well.)

Then you have to deliver the

Consequences

  1. Someone who does not deliver on the first or second project – never going to work with them again.
  2. Deliver two projects without fail – ask for a direct mail adress and keep on file.
  3. Three projects without fail – ask for direct contact and the possibility of giving projects privately and on short notice, also bumping up the rate a bit without them having to ask.

After three projects, a dev will still be blacklisted from my list if he fails to deliver for shitty reasons and being rude about it.

But a good dev is cut some (some!) slack.

Why? Because shit happens. Pets do get sick, grandmothers die and sometimes the sky falls on your head.

Here it is important to keep track of how many times this happens and if the person is forward and honest about it. If you are going to disappear for weeks at a time and then come back with a lame excuse – well, you are not on the list of good people to work with anymore. And although I do not think that “outing” people on forums, etc is a good idea .. do not hesitate to contact friends and tell them to avoid that person.

To end this on a more positive note:
People who perform well or even above the specifications should get a slight bump (or bonus) in their pay and should be recommended.
Just fair play.

With a few bad experiences, you will build up a nice little black book of good and exceptional performers who you can contact for your projects.

The little black book that could.

::emp::