How do you become good at purchasing software development services?
Many people that I speak to are unsure about their own capability as a customer or product owner when working with a team on the other side of the globe. They usually have concerns regarding them being able to provide enough requirements and good enough requirements regardless of the quality of the development team.
This raises a valid concern given the fact the result of such a problem would be that you have a development team with either not enough to do or doing the wrong thing.
How big is the problem?
I’m not trying to say that there is NO problem with this at all. But I would argue that the problem is a lot smaller than many people believe. Through my own experience I could mention many projects where the quality of the requirements were so bad that they had a negative impact on the end result. That being said, I claim that virtually anyone that has a good understanding of your business can with not too much hassle learn how to become good enough at providing requirements.
I have seen this in many cases and I’ve helped several people with no background in the software development process at all to become very successful in writing requirements to software development teams.
The first thing you have to do to provide accurate and actionable requirements is to make sure that the development team truly understands the problems that you’re solving or the value that you’re providing. This is easily achieved by talking to the dev team about the background to why you are where you are in the business world and explaining the pain points of the end users today.
My claim is that anyone that really understands their own business could probably talk about it for a longer period of time than anyone would be willing to listen to them. And that is exactly what they should do. The main problem in communication between the dev team and the business side of things is to make sure that both parties use the same terminology. You could achieve this by trying to try to teach the business side about software development but I promise that it will always be easier to do it the other way around.
Once a software development team understands the business side you’ve already achieved most of what you need to be successful in providing requirements. It is not you as a product owner or a customer to a software dev team that needs to learn how to speak with developers, it is the dev team that needs to learn how to interpret your requirements based on a common description of your customers reality that you’ve established with your dev team.
One of the most common reasons for failed requirements is that your development team is not suited to receive requirements or fail to ask the right questions.
As in all other parts of your business it is vital to be able to explain why you want to do certain things. Without this type of information it is very easy that you develop the wrong things. If your dev team doesn’t understand why they’re developing a certain type of software there’s a pretty big risk that they will make up their own reason.
It’s a natural instinct to many people to try to write requirements based on what should be done. That is also the most common reason that requirements fail. When providing instructions to a dev team it is much more important that you provide the core description of the problem that you’re trying to solve…WHY?
If you write your requirements by defining the problem that needs solving and for whom and why, then you’re conveying information to your dev team that requires them to think but also to understand. That’s when things really start happening because chances are that you might not have the best solution for the problem, but you sure understand the problem. If you let your dev team be part of HOW to solve your problem you will be much more likely to solve the right problem.
Don’t ever worry that you’re not qualified to write requirements. With the right skill set at the receiving en, they should be able to guide you through the process of becoming good enough and you will actually end up spending less time writing requirements than you were before and you will likely end up with a much better piece of software.