I run a development agency at Siam Computing and over the course of 4 years have had my share of clients. Some who have been great while some who have been, let’s say, not so nice.
Sometimes, developers and clients have this love-hate relationship, and I have always wondered how things go from being rosy eyed: ‘thou shalt do no wrong’ to a gut wrenching ‘spit in your mouth’ state.
I had originally titled this article ‘How not to hate your developers’ but realised that the problem is on both sides of the table. Since software development unlike other manufacturing industries deals with some form of human behavior it is much harder to encapsulate all the details that would sum up a project.
Here are a few things that I have learnt in my experience so far —
The ‘Dating’ Period
It’s easy to gloss over the details in a bid to get a project off the ground or to score a new client. Most clients have a high level idea of what they want, but it’s the details that really screws up the relationship. It’s important to think from the end users perspective and ask the right questions.
Also, most businesses these days run on some form of information technology. As a client, if you are building a business that depends on IT, it’s important to analyse your dev partners on grounds more than just their technical competence, for instance —
- Are they prompt in their correspondence?
- Do they understand why you are building it and not just what you are building
- For the small things that aren’t well laid out, can you trust them to take the right decision for your business.
- Since they are in the ‘field’ , will they be able to advise you on the latest in technology and advise you to take decisions accordingly?
- What kind of development process do they follow?
As a client, when you are in your ‘dating’ period, try having a more holistic view of who you are going to partner with, not all the criteria above may apply but think of this time as a means to getting to know the culture and approach of a dev agency.
Likewise for devs it is important to evaluate a client and take a conscious decision if that project/client is right for you. It is important to know if a client treats you like an equal partner in this relationship and is empathetic towards the nuances of software development.
Requirements Gathering
The holy grail of software development is the requirements document. Agreed that with the advent of agile development, a concrete requirements document is a thing of the past, even then it is important to have a clear idea about the direction the project will take.
In my experience, requirements can go awry for several reasons —
- Insufficient client involvement Be wary of a client that isn’t involved in the project. More often than not, this leads to late realisation of what they actually want and make the project go into a never ending talespin.
- Changing business goals It is important to have a larger vision while commissioning a software for development. It’s easy to fall in the trap of ‘let’s do this for the time being’ but being more cognisant towards the overall shape your organisation is taking and building an application towards that will help in the long term.
- Multiple decision makers As they say, ‘Too many cooks spoil the broth’. It is absolutely imperative to have one person call the shots at the end of the day. With too many people donning the hat , the requirements could end up getting spread too thin and the software not doing anything specific.
- Lack of domain knowledge Not having enough experience in a particular domain before building an application around it can have a severe impact, especially if it’s a new business. Having domain knowledge enables you to ask the right questions which eases the process of discovery.
- Scope creep Changing requirements because of lack of apparent impact is one of the most often touted reasons for requirements getting distorted. So many times clients make changes to their requirements because they feel that the impact is fairly minimum. Over time, such repeated changes lead to scope creep. I believe the onus is on the dev to be more conscious towards accepting changes and layout the overall impact towards making repeated changes
It’s crucial to freeze requirements at some stage to avoid rework. In large projects, 20–30% of cost goes towards rework because of poorly defined requirements. It’s highly frustrating as a software developer to keep making tweaks to the architecture which eventually leads to a buggy application with lots of overwrites and poorly written code.
Estimate
Let’s talk money.
Don’t commit if you aren’t sure. Being shy about what it’s actually going to cost to build something or not speaking up while there is a change in requirements doesn’t help anybody. Be open about concerns you might have and communicate the same.
My grandpa once told me that even if I was doing something free for a client, create an invoice for the amount you would have actually charged and give a 100% discount. This way, the person who benefited from your service knows the value of what they are getting.
As developers, it is important to be constantly in touch with the value of your work and be able to communicate that value to your client. This helps the client put things in perspective and reduce scope creep.
Communication
Be empathetic while communicating with your peers in a project. Everybody has their own lingo when it comes to technology and both clients as well as devs should take the extra effort to express themselves well and ensure the other person has understood what is needed.
In software engineering, we have a concept of being ‘DRY’ i.e?—?don’t repeat yourself. However, it’s a crime to apply the same concept while managing software development. Clear, concise and constant communication is essential.
Manage expectations
Telling a client a feature cannot be built because it is out of scope is a hard thing to do, but it’s something that has to be done. It’s better to swallow the bitter pill and keep your client in touch with what’s achievable rather than overcommitting under pressure and then eventually regretting it.
Being open and transparent about the state of a project not only allows you to focus but also helps your client prepare for any eventualities and avoid last minute disappointment.
Build in iterations
For startups, whose ideas are really raw to begin with, I strongly recommend building an mvp first and then spiraling out as the product gets more traction.
Have things written down
Chinese whispers are fun but let’s avoid them when building a custom application. Having stuff written down helps keep everyone on the same page and avoid being in a situation where it ends up being one person’s word against the other.
It does not always have to be long elaborate documents that can take forever to write, it could be something as simple as a basecamp discussion to a simple todo list that you and your client share.
Summing it up
Software development is all about how humans interact with each other to build something out of just a simple thought, so its natural that the whole thing can get quite complicated. But following some of the simple pointers mentioned here can help in a long way. Of course, what I have highlighted is just the tip of the iceberg and there are several other nuances to managing and building a successful application. Stay tuned for more on the topic.
Let me know your experiences working with devs/clients in the comments below 🙂
First published on medium
Follow me on twitter / linkedin
Awarded the
“RodinStar” Post
of the week!!