How to contract consultant developers

Another post that has been sitting in my drafts waiting for prompting to publish: this time the prompt came via Paul Miller tweeting and also recently in taking on some new independent development consultants, which I hope this post will help explain why I contract the way I do.

So first question is “why should I outsource my development work”?  It is -as most of you know- a painful process: 1.) searching for developers: googling, discussion forums, posting job adverts, trying to chase down contacts via linked-in, sorting through old business cards to find ‘that one guy’, etc); 2.) choosing the developer you trust: picking from a selection of independent developers or even worse having to speak to the salesman that act as gatekeepers to the developers; 3.) pitching your development idea: even when you do get through to the real developers pitching them your idea is usually met with skepticism for the way they know it should be developed; 4.) agreeing on the size of work that can be accomplished: getting agreement on an objective that meets both technical capabilities and user needs, knowing that the developer or salesman has far overstepped their ability to achieve the project on time or to spec; 5.) writing up a contract: trying to decide when to pay, how to pay, if their should be penalties, what happens when problems occur, what documentation should be completed and in what form, how many iterations you can have for slight interface alterations, what kind of testing might need to occur, who is the final adjudicator of the contract, and so forth and so on… And that is just what the client has to go through, I can only assume it is twice as worse for the developer.

So what follows is my humble opinion and experience in working with consultant developers and what I’ve come to understand as best practice for writing out a contract.  First and foremost it should be said that I will gladly work with any developer no matter what location, and we’ve had consultancy work that spans the globe: London, Minnesota, Shanghai, Atlanta, Australia, New York, Argentina, California…(and that was just the past six months work!).  Above all else I think the most important aspect of the outsourced developer contract is that both the client and consultant are happy with what has been accomplished and the way in which it was done: this is because the end goal of any contract should be to move to the next contract.  In short, once you find a good developer (or client) then you want to stick with them as it makes getting through the contracting pain that much easier.

Overall, the methodology we base most of our development workpackages upon is Agile Prototyping.  Basically, we think of the Agile Manifesto as a kind of “Developer Code” (which is like the ‘Pirates Code’ in that it is more a ‘set of guidelines’ than a ‘set of rules’).  Saying that there is one rule we try and hold true to throughout: “users (or user representatives) and developers must work together throughout the project.” Recently, we’ve also come to adopt some other popular memes from Agile SCRUM, namely we have come to try and use ‘the sprint’ which is just another way for saying: “deliver working interfaces frequently…with a preference to the shorter timescale.”  We’ve also found that adding deadlines when problems are found are a good way to force the team to discard the work-package and move on (aka the best thing about code is that it can be select ‘A’ => ‘X’).

Ok, on to the step-by-step process I’ve come to adopt for getting to an agreed upon workpackage contract:

1.) Having that first conversation with the developer is key; to be able to clearly state your objectives (or rather the users’ objectives) and have a vision for what change this will bring about in the users’ behaviour.  Also this first meeting should not be long and is just an opportunity to see if the developer is actually interested in doing the work.  Either the developer will engage and tell you the technology hurdles to be overcome or they might just sit and listen (either is ok: remember developers are a rare breed!).  If the developer does not get back to you in a fortnight or so then perhaps consider that this developer might not be the right one (or that your ideas is not a good one). I can’t stress this point enough: if the developer is not interested in this work you will not achieve your overall aim and vision.  You must have a developer who sees value in the work you want to do. Also, it is good if this first meeting can be face-to-face, or rather more importantly don’t sign any contract until you have met the developer face-to-face (and preferably over beer <- that should be free for the developer!).

2.) If the developer gets back to you after this first meeting and shows interest then you are ready to take the next step: user cases, user cases, user cases and then some user personas if you have time.  I can not begin to express the number of contracts written up that express what is supposed to be accomplished on behalf of the user and then as soon as a working interface is presented the first response is: “this doesn’t quite work for the user”.  Fair enough users change, but if you write down your user cases with specific details (e.g. even down to ‘the time it will take the user to first click a button on your interface’) it will save you pain and money in the long run.  Here is an example of a couple of average user cases in which most people will initially start.  Once you have your user cases, if you have the time you should try and create user personas.  The user persona is a imaginary person who can be used as a proxy user to talk about the interface so that the developers or user representative are cognisant that they should be speaking from the point of view of the end user (NOT THEMSELVES!).  Never underestimate your ability to project your own user preferences on to the app you are building. Keep in mind that the user case is the basis by which the developer will make all kinds of small decisions such as how search results should be ranked or how quickly an application needs to engineered to respond to the users needs.

3.) Now comes the most essential part of the entire application: you must wireframe before you sculpt!  Once you have your user cases you are ready to start drawing the interfaces on pieces of paper or in photoshop (we’ve also been playing with Flex just for ease in drawing buttons and actions: not necessarily as a technology for the final interface).  It is important to note here that the word “wireframing” comes from sculpting where the artist would literally sculpt wires before moving to the stone for the final product.  It is also worth noting that “prototyping” means “throwing stuff away” and so a good series of wireframes will interate through several versions before being contracted: a.) hand-drawn diagrams, b.) move to storyboarding, and c.) a finally end up with a realistic looking photoshoped (or Flex) looking interface.  This final wireframe will be the basis for how your contract with the developer is set up so you must have it as robust as possible before proceeding, the wireframe is your point of no return.

4.) Contract time, by now you have all the information needed to sign a contract. Between the user cases and/or personas and wireframes you have the product you want delivered and specifications by which it should be delivered.  I won’t go into the legal jargon of the contract but I find it best to first submit the user cases and wireframes to the consultant developer as the contracts (I usually publish them on a 3rd party website like Flickr).  The consultant at this point should write up a purchase order to specify that the workpackage delivered should meet the specifications of the user cases and wireframes and cite both published documents in the purchase order.  Now depending on the amount of money you are spending (and I keep the workpackages as small as possible) you can either write up a formal contract or use the Purchase Order as the contract itself.  Just make sure the PO or Contract references the wireframes and usercases as the primary spec to which the developer must work to and deliver.  It also helps if you put the wireframe and user cases in a public space where dates are assigned by a third party company (eg flickr,, this way they can be added to but not renegotated after contract has been signed with a specified date.

5.) Penalties, documentation, testing and tweaks: if you are purchasing multiple workpackages at the same time (not advisable) then you should have penalty clauses written in the contract, though do remember that this often makes the developer uphappy which is a bad thing, they need to feel inspired not obligatory.  I’ve yet to implement a penalty clause, rather I prefer to have a documentation clause that clearly states that any failure to deliver will result in documentation clearly explaining the problem and why the effort failed.  Personally, I often find that passing on our mistakes is sometime more valuable than the code that is created, and it really is very rarely the developer’s fault (developers are usually a bread that like to achieve and impress).  Speaking of documentation, I also prefer to write my own documentation when a project suceeds, this forces me to get to know the code that was developed in case I need to pass the code on to another developer (i.e. like knowing the boiler in your house in case you loose your handyman and need to tell the new handyman).  There is also testing the app for scalability but again doesn’t need to be done until your servers are telling  you so.  It is also worth mentioning that you should have a clause written in the contract stating that once an initial interface is produced a grace period of two or three weeks should be given for minor tweaks.  This of course can get fuzzy as the user is always changing.  I usually request one round of small tweaks that the developer will fix as part of the workpackage.

6.) Method of Payment: now you only need to decide on method of payment; my institution requires that we pay in “arrears” so the work has to be -for the most part- finished prior to payment.  Most developers are fine with this as we are a large stable institution not going anywhere soon.  If you are an SME I would expect to pay at least 50% before development is began.

So there is consultant developer contracting 101 from me, or rather my flavour of the month on project management.  As development changes (and it does so quickly) so will the contracts have to change.  I do think it is important to keep in mind that at the end of the day satisfaction comes from the end user in having an experience that works with their own psychology.  Even now as your eyes move across this page you are assuming certain things, certain ingrained pathways for how your brain wants to interpret each word.  The same can be said as your brains get used to web pages and they way they appear, the way the buttons react and workflows are revealed.  By keeping the wireframe as contract you are keeping the money about the users satisfaction.  If you deliver something that the user isn’t happy with then it is the contract that has failed not the developer.  Best of luck!


~ by dfflanders on November 4, 2008.

8 Responses to “How to contract consultant developers”

  1. great article, as a developer i always want an educated client because when the dynamic is good the production quality is much better.

    Do you know of a way to find good Usability Firms, guidelines?


  2. Great article. Just wondering how you embed/negotiate intelectual copyright ownership?

  3. […] […]

  4. When we outsource the process of wireframing (hand drawing, storyboarding, working prototypes) is treated as part of the discovery, and we pay the developer. This is a good opportunity to try out working with the developer before committing to a big project, and the developer doesn’t have to do any free consulting.

  5. from Fred above “Do you know of a way to find good usability firms, guidelines?” I just had the same question asked by one of the development firms we work with, as apparently there is a shortage of usability experts in London right now? As for our approach, we’ve begun training our own usability expert: a year on and it is working out really well, she is a great member of the team to have on call at all times and she knows how to deal with the developers and her ranting colleagues! Perhaps a bit sexist but there is something in the combination of a ‘male developer’ and ‘female usability expert” that works, given the female is comfortable with geeks <- need an evolutionary psychologist to figure this one out? When hiring our usability expert I asked all the candidates to describe a task they would accomplish on the internet. In hearing their verbal descriptions of a visual thing, we were really able to narrow down the best candidate and have been training her up since. This also helps with the contracting process as there is someone on staff to firmly represent the interests of your users. If you use an outsourced usability expert their motivations are divided between running up the consultancy bill and representing the user. Though there are usability experts we absolutely trust who do great jobs. I suppose I need to put up a post on usability experts as well since I originally started out as one.

  6. I think Mitch is spot on (above) “when he stresses the point of “working with the developer before committing to a big project”. I can’t stress enough that while development firms are keen for you you to use them and only them for the project, I have always found it best to use multiple developers (and I tend to go with the smaller independent firms). If you are going to use only one firm then some serious foreplay needs to occur if trust is to be established. I suppose I need to shift my thinking in regards to “free consultancy” as well, as I usually use it is as means to see how much a developer is interested in the project, but perhaps not the best thing as no one likes doing free work. Again, I would fall back on the Agile manifesto here, and the importance to keep each workpackage as small as possible. Also in calculating the number of WPs that may occur, it is good to factor in that several WPs will be a fail. Failure is one of those things I’ve really tried to embrace these days, though don’t forget to then celebrate the small victories, e.g. if ‘hello world’ worked then go have a pint in the middle of the day or light up a cigar a do some back-patting, gratitude is as important as the failures.

  7. from Mark: “Just wondering how you embed/negotiate intellectual copyright ownership?” <– we are privileged in this area as we are public sector funded (high education universities), therefore we do all of our code as open source. If you would like to be apart of this “no penalties in learning development” and “FOSS is the way to go” then please do contact me. Though the debate does rage between GPL vs. BSD. My default is GPL, but if the consultant has a good reason why they might be able to promote the code and project later on in a ‘good will’ way then we’ll go with BSD. I’m not too bothered, though Eben Mogel on FOSS is worth having a look at if you have any doubt about why it should be Open Source.

  8. […] […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: