Requirements versus partnership

One recurring theme in software development is ‘requirements’. This seems to be one of the most challenging starting point of any software development project. My experience is that the crucial point is ‘explaining what you have in mind, what you want to achieve’. Now I see the following problems with labelling the challenge in outsourcing as ‘making requirements’:

a. It implies that making requirements is largely a role of the outsourcer 

Outsourcers oftentimes do see this as their responsibility. I would argue that this assumption is flawed. During the weekend I placed a job on a ‘handyman’ website. I want to re-paint my wooden floor. I had problems with the floor, having to paint it each 2 months. I could explain my problem very clearly. As a reply, I got few questions and some proposals. With one round of answers, the handyman can make an offer for the job. 

But in software development this doesn’t work. It is hard to picture what you need and ideas change during the development process. The team that builds the software needs to be engaged in determining what needs to be built.

b. It’s based on the waterfall model

We used to build software step by step, first spending weeks specifying everything, then building and testing it. We found that scrum and agile work better. In scrum you don’t need to have big requirements, you can enter the process with a vague idea. The team then comes up with user stories that are converted into working software. Requirements are made by the group during the whole process, not upfront. 

c. It reduces the challenge to ‘requirements’, which isn’t the whole story

Software development is a creative team effort. Great software is a product of the people you have on the team, the roles they have and the process they follow to produce the software. Good requirements follow if people, roles and process work synergetically. It’s not one person sitting in a room thinking about what to build and putting that in a document. 

The challenge in software development is not ‘making requirements’ in isolation. It is getting the whole process right. This starts with getting the right team that knows how to build what you want built. It requires a team that views building software as a partnership. When you send these great requirements you made up in your company to a team and ask them to estimate this, you get what you asked for. But the team probably won’t go the extra mile.

When you make an effort to make them a true partner, the team will be vested in the outcome. This doesn’t need to be an economic partnership, it can be an emotional partnership. The handyman who fixes my floor takes pride in the end result. He does his job because he loves the smile on my face when he does the job well. So does a software team. Effective teams want to put their ideas into your software, they take pride in co-creating it. But if all is already nailed in solid requirements, there is no space for that and they’ll just build what you ordered. 

This implies that it’s often better not to make requirements at all. Instead, find a team with experience in what you want to build, which understands your business and which goes for true partnerships. And then engage them in ideation from the beginning, so they get an emotional bond with your software.