Developer-client relationships go wrong. It’s a fact. Developers that weren’t up to the job, projects that get abandoned, whole web-apps get written that never get used. Hopefully you haven’t experienced this yourself; if you have I am sure that there were some deep lessons learnt from the experience.
The “Win-Win” of web development
It’s not good for either side of this relationship for it to end out of turn, aside from the “cosmic karma” of wrongdoing to others it’s not good business for either party if a software project doesn’t make the cut. To this end, producing a new website or app should be a shared goal between the client and the developer, that’s what the following 5 crucial points try to help you accomplish, a joint vision of a web based outcome.
All the points are crucial, but you can jump here:
- Have a clear vision
- Developers will
- Validate developers and test them
- Clients will
- The three crucial documents
1. Have a clear vision (Mock ups)
One of the most important things when starting out new projects is to mitigate risk. In my opinion the biggest of those risks starts here: your vision. As a client you probably have at least a 50% complete vision of where you want this web development project to go. The real art of successful first stage development is to communicate this vision to your developer with the up-most clarity.
A good developer will be tuned to dealing with clients technical requirements, they will offer solutions to the problems you provide (all web development projects are technical problems to be solved) and will be able to back these up with past examples or laymen’s terms explanations which hit the mark. In this they may be able to guide your vision into a more technically achievable state, you should welcome this but make sure you validate your developer/s (see step 3.)
The clearest way I have encountered of properly communicating your vision is through mock ups. I am not sure whether it’s the pencil to paper connection which makes you think more thoroughly through what you want or whether it’s just the format we developers are used to, but the simple fact is that the end product, the closure of the project will need to look like something. If you make mock ups and share them this takes a huge proportion of the guess work out of the middle and I believe is one of the most crucial ways to mitigate risk when hiring a developer.
- Provide Mock ups (photoshops, wire-frames, doodles, ideas on napkins)
- Welcome developers technical input (respect the knowledge)
- Drive hard on the features you think are most important…
- …but include all features you think are essential
- Research a little on technically what you’re asking for
- Provide a Specification (doesn’t need to be technical)
- Use broad/sweeping phrases “and I want to fully integrate social”
- Add miscellaneous non-development tasks (PPC campaigns, Copy writing)
- Talk about multiple, unrelated projects in the same instance
2. Let the developer show you their will
What kind of developer do you need for this project? Is it a long term, mammoth slog or a quick, light scripting job? You might not even be sure which of these it is yet, but that’s where the conscientious freelance developer comes in. Lay your cards on the table with a good developer and they will propose a solution, timeline and realistic budget. I will talk more about testing your developer in the next point (you should test these 3.)
Compare the responses (hopefully in the form of solution, timeline and price) from several developers. In most cases you tend to get an overall feel from the developer quite easily. This isn’t a question of technical capacity but rather one of attitude and tenacity, after all a developers’ inclination to solve problems is integral to a successful web development project.
Some questions to ask yourself about a potential developer’s will:
- Do they write with substantiating, quantifying words (I will deliver, I propose, I am confident, by July the 30th) or weak/vague terminology (I could do that; I can probably, around 4 weeks)?
- How well do they explain technical problems? (A good technical knowledge should allow them to provide good explanations to someone of any level of understanding)
- How long do they take to get back to you?
- Is this their main job? Do they do this as a hobby?
- Can you call them and get a response?
- Ask your developer if they think your idea is good? (This will tell you a lot)
3. Validate & test developers
There is a reason that job interviews come after previous employer references. A solid developer will have experience, and references, otherwise they haven’t completed or are new to developing (which is OK for some projects, but remember to think about how you can mitigate the risk of an unproven developer vs. an experienced one.)
There are a number of ways to validate developers, I suggest choosing a few of these and then testing them (below):
- Ask for references and call the references – get references of clients satisfied with similar requirements to you
- Check out their profiles on a third party website (freelancer marketplaces)
- Read their blogs/social profiles
- Google them
After you have validated your developer and you are strongly considering them for a task I recommend testing them. This has been done in lots of different ways and which is best will totally depend on your business style and the project you are trying to get developed.
There is a key reason why I have placed Test AFTER validate, this is because both are necessary, but if you go first to testing (as lots do) then you will likely get back 3 good results and quickly employ one – it’s easy to think of testing as validation but to mitigate as much risk as possible I would recommend both. Doing the validation first means you can start with a smaller short list and employ straight after testing, confident in your new developer.
Test your developer by asking for at least a few of these:
- Telephone interview – talk through the project on Skype
- A list of “Deliverables” from your Spec.
- Complete a small chunk of the task (1-5%)
- Verify that your server details let them connect
- Write a summary of the project
4. Show them your will, enthuse them
So far we have focused on choosing and getting things from a potential developer, beyond their capacities and attitudes though, lies another potential barrier to success, you. We can all picture what a nice client is, early payments, adoring praise – that’s not what’s required here, nor is a hard-pushing, late-paying strategy, neither of these will actually help your web development, neither is Win-Win business.
Really this falls under project management and is likely to be the point you all need to focus on least, while it’s still essential to good project outcomes. Once you have shown your developer a clear vision, seen they have the will to complete and validated that they are the right person for the job through their experiences and testing them the last key point to web-development project success is to enthuse your developer.
Enthusing your developer:
- Be straightforward and honest
- Tell them why you picked them
- Get enthusiastic about good work
- Build rewards into your projects for exceptional cases
- Emphasis a feedback loop (if you want one)
- Be timely with responses if you ask that in return
- Give them feedback on their business as a service
- Show that you support the development
5. The three crucial documents
Last but not least, it is integral to get your plans down in the form of solid documents (unless the project is tiny.) All successful client-developer relationships are reliant on a shared vision as I mentioned above, nothing concretes this better than a good set of project documents. Yes it’s important to have mock ups and diagrams, but before that there are three main documents that you should have:
The three important documents:
- List of Deliverables
- Service Agreement
- Client thinks up idea, creates a rough non-technical specification of what they want.
- Developer takes client specification and based on a round or two of questions creates a concrete list of technical deliverables.
- Along with the list of deliverables the developer provides a service agreement.
While the contents of these documents probably gets created in most cases, in an email conversation or over VoIP, I would recommend securing these points in document form to ensure a firm starting point.
Each document is important for several reasons; though these are long enough I may well dedicate a future post to them. Work started before an agreement is made over these three documents will likely run into trouble, by establishing these before commencement both sides are far more likely to be happy with the project outcome.