Written by Martin Cooperwaite, co-founder, Kiandra IT
When you embark on a software development project, most companies will need to look externally for assistance. Let’s presume that’s your job – to find the external help.
And whether or not this project is a new website, or a portal to enable customers to interact or trade with you, or a completely new platform to enable a key initiative (it doesn’t really matter what it is), it’s going to boil down to an agreement on a list of requirements, and then the delivering of these.
When you engage one or more external software development companies to assist your business, the first step generally is a conversation-of-sorts to discuss what it is that you want.
So let’s dive in a little bit to this ‘conversation’.
The software development vendor, in my opinion, has two key roles to provide to you to earn your business:
- They need to be able to deliver great software – of course
- They need to be able to consult, and provide key ideas to make WHAT you build better, before you build it.
Any good provider will have done lots of projects, for lots of different organisations, and probably in many different industries. So what you get after doing lots of projects, for lots of organisations, in lots of different industries, is a big large juicy lump of experience. And one of the things I’ve learnt along the way is that the manner in which we solved a problem for one client, with a dash of lateral thinking and a sprinkle of creativity, can be tremendous insight on how to solve a problem for another client in a completely different industry.
Yes, it’s much ‘safer’ for the provider to just sit back and take notes, preparing a list of features to deliver. This way the responsibility is on the client for WHAT is to be developed. Much more comfortable for the vendor. However that’s doing you, the client, a disservice. The requirements clarification process should be consultative, and it must be structured so that at the end of the process, you have a solution vision better than it was before. Otherwise, you are paying the high costs for outsourced development with only half the benefits.
This is also one of the reasons why I think that the ‘traditional’ tender process, with a one-way non-consultative communication of requirements, is doing your organisation a disservice. In my opinion, great software development is more of a creative undertaking than an engineering one, and so even if you do get a number of quotes to compare, you can never actually compare apples with apples because no two apples are the same. So your basis of comparison should be how thoroughly they demonstrate that they ‘get’ your business, the risk assessment and ROI, and the value of the consulting and advice they provide before they are formally engaged – with the right people in the room, collaborating.
So the next time you engage a potential vendor, if the conversation is 90% one way, walk away.