We try to explain what we have in mind, what business result we’re after and what software we envision. Labeling the challenge in outsourcing as ‘making requirements’ has some flaws, however:
a. Many people mistakenly view making requirements as a role of the outsourcer
I view this assumption as flawed. To put this in perspective: I recently placed a job on a website for construction jobs. I’ve had problems with my wooden floor for 2 years now; each 2 months I have to repaint the floor. I explained my problem very clearly on the site. Some handyman sent me a few questions and I got 3 proposals within a day. The handyman can make an offer for the job with the short description and some short additional questions.
In software development, the case is totally different. It is hard to visualize what you need. Needs change during the process of building the software. The team that creates the software has to be involved deeply in determining what needs to be built.
b. It’s largely based on the waterfall method
In waterfall, we first spend weeks specifying, then we build and test. Most companies found scrum and agile to work better. Scrum says you don’t need requirements, you start with an idea. The team (which includes you) creates user stories and from the stories we make working software. Requirements are not made upfront, but are created by the team during the process.
c. Requirements are only part of the story
Building software is a creative team effort. Great software is a product of the people, the roles they have and the process followed to create the software. Good requirements are generated when people, role and process work well together. You don’t want to sit in a room for weeks specifying stuff.
The challenge is not ‘making requirements’. It is getting the process right. It is about getting the right team with experience in your business and in building the solution you envision. It is about a team that sees software development as a partnership. If you ask a great team to estimate and build what you’ve described in big requirements, you will get what you asked for. But the team won’t go the extra mile.
When you make them true partners, the team will be emotionally bound to the outcome. You don’t necessarily need an economic partnership, but you do need an emotional partnership. The handyman who paints my floor is proud of the job he did. He does it for the smile on his and my face when we look at the result of his work. So do software developers. Strong teams want to put their brains into your product, they want to co-create it. If all is nailed in fixed requirements, you withhold them this emotional buying.
It’s often better not to make any requirements. Instead, look for a team with experience in building similar software for companies like yours. And seek a team that longs for true partnership. Engage them in creating the ideas for the software, the product roadmap, so they get an emotional bond with your software.
Read Next >> Outsourcing Via Distributed Agile Teams