Delivering bespoke software for clients can be a difficult situation for all parties involved. For a client – the leap of faith is huge – entrusting what can be a significant part of the infrastructure for their existing business or growth strategy with a potentially unknown third party.
As a software developer, I have managed many projects over the years that I have been involved in the industry. I have come to the conclusion that the most critical part of a project – the beginning – is often when both parties – the customer requiring software development, and the software developer implementing the project, are at their most inexperienced.
This inexperience has many side effects – most notably in the field of assumption. The client may take some of the industry knowledge they have for granted – leaving the developer to reverse engineer decades of experience in a matter of days or weeks – before beginning to lay the foundations for a more complex system. Misunderstandings at this stage can lead to cost overruns, cancellation, or systems being implemented that are clearly not fit-for-purpose.
So what steps can the client of a development project take to help improve the chance of success, and how can they find a developer who can develop their project?
I’ve created a simple list of five considerations for potential clients to bear in mind when embarking on their first project:
- 1. Do your research –
- Off the shelf products are often cheaper, more bug free, and take less hassle than bespoke software development. Do you need a developer, or can you get by with an off the shelf service?
- 2. Find a developer with experience relevant to your industry –
- You are the expert in your problem domain – you may however, not be an expert in defining and communicating the challenges you wish to meet in a way that helps a software developer. Finding someone with industry experience will mean that you are spending less time on training a developer to understand your industry, and more time working with them to agree on how best to exploit the opportunity you have found.
- 3. Start Small –
- If you haven’t worked with a developer before, consider if it is worth managing the risk of your inexperience by starting with a small, well defined project – a test bed that isn’t going to cause too much of a problem if it is thrown away or is not delivered.
- 4. Aim to build a long term relationship –
- There is a lot of overhead in forming the relationship needed to ensure good two way communication and trust between client and developer. There is something to be said for minimising this overhead where possible.
- 5. Don’t expect perfection –
- Delivering software to time, on budget, to the right scope is covered by what is known as the “Project Management Triangle” – or often summed up as “Fast, Good and Cheap – pick any two”. All projects and deals have compromises and trade-offs to make them successful and worth doing to both parties. An adequate system that is delivered in a reasonable time-frame with sufficient support to work around any oddities is often more usable than a quest for perfection, doomed never to leave the lab.
As a developer – I am interested to know – how does your experience of negotiating deals with internet/ inbound marketing compare to mine in IT – do you have your own top 5 list? Let me know in the comments below.
Steve has been engaged with the Birmingham tech scene for years, co-organising the grassroots open-source conference YAPC:: Europe 2008, and founding the West Midlands Java User Group in 2014.
- Introducing Duplicate Link Detection - August 27, 2021
- Python – A practical introduction - February 25, 2020
- Get a list of pages on your site with links from other sites. - February 7, 2020
All sound advice. From a UX and design point of view – this quote from Don Norman resonates most closely with me and my experience of consulting:
“Do not solve the problem that’s asked of you. It’s almost always the wrong problem. Almost always when somebody comes to you with a problem, they’re really telling you the symptoms and the first and the most difficult part of design is to figure out what is really needed to get to the root of the issue and solve the correct problem.”
So often, we have customers come to us stating the solution they want, rather than the problem they have. Helping them understand that, and defining the user stories ensures that you have a common and unchanging frame of reference for the design.
May 23, 2014 at 2:25 pm> Thanks for the comment, Nick.
It’s an interesting point you make – the post started off with the working title of “The difference between a brief and satisfaction criteria” – ie the difference between what a client thinks they want, and the solution that will make them happy.
As is so often the case, the end result of my post, after a couple of iterations, didn’t end up looking like the solution I had intially intended to present. Your quote from Don Norman sums this process up beautifully.
May 23, 2014 at 2:41 pmThanks a lot for the post. We are developing software for our brand revamp, and your post was very helpful. Cheers
May 25, 2014 at 7:14 amTotally agree, start small on a project or task, get in the same wave length, do your research, it makes things easier if they have relevant experience it what you need and lower your exception on the 1st task/project.
May 29, 2014 at 12:08 am