The Developer: Client Relations 1: Setting Expectations
As like all of us, clients need quite a bit of repetition, if they are to take in and grasp any terms one attempts to set as ‘rules’ upon the hiring of you as developer to make their software and design works.
There is no use in being anything but straightforward and repetitive; nothing complicated by hedges and conditionals; simple statements in simple language; and the same messages regarding terms when spoken to a client as when writing to a client.
Not dictatorial butyet assertive and clear.
These rules ought to be more or less the same set for all your clients. In this they are rather principles of how one oneself goes about ones work and about managing one’s relations with one’s clients. They should be set down in the written Agreement between Parties to the works. They should be offered to the client again in full in the initial progress report you write up for the client; and every now and then, say once a month, the client is reminded of the efficacy of these terms of yours in progess reports.
Such reminders can be vareigated so as not to some like dictatorship, and hinted at but not too vaguely, so that they seep into the relationship gradually and without too much heavy-handedness on your part.
Your terms need to be able to set for the client those expectations a client might reasonably desire, and also they need to set those expectations of behaviour and those protocols which you feel are fair and equitable, but yet they will allow you to work without you getting embroiled and having to manage difficult or crumbling human relations between yourself and the client as you go and ‘on the hoof’.
All the above is an ideal scenario; and of course no set of laid down expectations for clients and for their developers in practice is going to prevent utterly a need for relations to be managed day to day at least somewhat.
Thes expectations need to be formulated, written down and communicated to the client as soon after hiring as is practicable; certainly before any agreement with a client is signed by a developer. Even during negotiations previous to hiring their content ought to be made use of during the negotiation process; so that the cleint has ‘no illusions’ about where a developer satands and how he works.
As a general rule it is always for the best that in negotiations and Agreements, Requirement Documents and Specifcations etc; as much as is possible to be set or settled between parties up front before work on coding/design actually begins. Thus everyone concerned ought to know where they stand and also have in place clear understandings of whatis required of them; when what is reqired is expected; and how the work is in general going to progress.
Rules for behaviour and for settlement of non-deal breaking disagreements, say on how to do a piece of work or what software to use; as well as dealines and billing etc, ought to be laid down and laid out and acknowledged as read and understood by parties.
Behavioural rules will always inevitably be broken in the course of the relationship, but the idea of the writen down and acknowledged agreed protocols is that they act as a guide and a reference point to which a party is able to point and so point up such breaches. An appeal to the ‘spirit of the agrements’ is able to be had by a party with some evidence (the protocols themselves) being available to support such an appeal .
Now all the above so far might seem to you as if it is too longwinded and cumbersome to bother with so as to put in place. Too much time; too much bother; when all that is required and expected is software etc written. For smaller projects maybe there’s a case for saying this with some justice; although for anything above medium sized projects our experience at Anomalist Design LLC has reiterated almost without exception that every client relationship over extended time will require more time and more careful management from parties; this being time and attention which wil eat into development time per se severely and cost you considerably in delays and distractions, in comparison to a situation where you had to put in place up front at the beginnging between parties such mutual safeguards as I am outlining here.
The keys to successful ‘prenuptial-type’ protocols of this kind are:
Comrehensiveness – i.e. any written terms being suficent to cover most or all of the usual sticking points which any experienced developer will know are commonplace arising in the course of working on projects
Clarity of language – i.e. that there in minimum room in writen terms for ‘other interpretations’ or ‘escape hatches’ or else plain fudging becuase of exploitations of vagarires.
Equity of approach – i.e. the terms are fair and balanced; apply whereever appropriate to all parties; demand nothing onerous or drastic excepting in conditions governming extreme situations arising and so are proportional. Where there is room for reasonable doubt on an issue; it is a good because generous policy for the disadvantaged party to allow a benefit of the doubt to the other parties.
Firm answers/courses of action for hypothetical situations foreseen arising – i.e. do not shy away fromcommonplace worst case scenarios – but instead takle th epossibility of the in the shape of rules, protocols, time constraints, recompense, sufficiency of redress/recovery.
Nothing redundant – i.e. be as brief as clarity and comprehensiveness will allow
Setting Agreed and Understood Expectations – i.e. which should be matched with wholehearted commitment to fuflling these when situations arise
Setting Boundaries – i.e. over which parties do not step and were they to step over one of them then set….
Penalties kick in – i.e. and these are concretely expressed and definite in their execution and effects.
Some examples of the kinds of things which are the nitty-gritty, the detail of such key components of up-front Agreements; that is, actual terms and the set expectations etc, themselves will be laid out in another aritcle in this series; together with possibly an instance of such an Agreement which Anomalist Design LLC has used with some success in the course of its working life.
Should you not feel confident about your abilities for drafting such a set of terms; there are web entities which for a small fee are willing to scan and consider your draft|(s) and offer good hints and advice on how to tighten them up and make them good.
Do not duck out altogether and leave it to your admin to deal with writing such items. You need to be initmately familiar with their contents, and with what you are in fact committing to when you sign.
Your efforts at practicing making such documents are able to add clarity to your own vision for the project in hand, and has many such ‘spin-offs’ of benefit to you in clarifying your role(s) in the works. Coninuing perseverance in drafting such documents also will bring little by little greater clarity and penetration to your other written documents; specs and requirement docs, etc; and even to your abilities to envisage routes down which to follow so as to architect projects in general.
The rule here is a general life rule: Nothing, no experience is wasted; whether good or bad, success or failure, loss of gain; all is grist to the mill for the person who is happy to examine his/her experience and draw the life-lessons arising from their examination.
More is to follow. Watch this space.
You can also find this article at our anomalist design blog: http://blog.anomalistdesign.com/the-developer-client-relations-1-setting-expectations/
This article is also posted at my linkedin: https://www.linkedin.com/pulse/developer-client-relations-1-setting-expectations-matthew-raymer?trk=v-feed&lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3BZH4yLq1wKVArv4WHgablvQ%3D%3D