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, wordpress.com), 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.