What is Requirements Gathering?
This post describes the best practices associated with planning for a custom software development project.
Wouldn’t it be nice if you knew a realistic cost and timeline before you commit additional resources to a new software project? Just like you need a blueprint from an architect before you commit to building your dream house, you need to undergo solid requirements gathering before you make a final decision on your software project.
Every software product or design has to go through requirements gathering.
Let me say that again: Every software product or design must go through requirements gathering.
When embarking on a custom software project, you must define what the product is going to look like, what it’s going to do, and what it’s not going to do. This has to be done from both business and technical perspectives. The process should include designs of the needed screens, workflows, use-cases, a definition of what technologies will be needed, definition of scope; the list goes on.
Before requirements gathering, you have an idea for a product or program. You may have solicited some “ballpark estimates” from a few development shops or even your own team. But, until requirements gathering is complete, product owners do not have a realistic idea of scope, timeline, or cost.
What is the benefit of requirements gathering to a product manager?
Product managers need to have confidence in their product so they can justify the expense and time. Businesses care about how much it’s going to cost, which is why the normal first step is to solicit some "ballpark estimates" from a few development firms. This is cutting corners. It does not give the product manager or the business team adequate information to make a sound business decision.
After undergoing real requirements gathering, you will have an accurate picture of the timeline, resources, and cost that will inform the business process. Part of this requirements gathering process can be some research centered around the core of the product to find out how it resonates with your target audience. Requirements gathering also shows you the bare minimum effort needed to execute the product in a way that still solves the problem brilliantly. This automatically brings your target market for the ‘Minimum Viable Product’ (MVP) into focus and helps your business efforts and development efforts sync up.
No doubt about it, requirements gathering gives you more than a technical roadmap for the development of the product or feature. When done well, it also informs the business decisions that you need to make.
Are ballpark estimates really worthless?
If you already believe me, then you can skip the rest of this section. Remember all those estimates you got from some development shops for free? The ones they wouldn’t put their skin behind unless they padded it by 300%? Those are worthless. Deciding on a development shop based on a ballpark estimate is a terrible idea.
For example, say you have an app idea for a GPS-enabled social mapping app. It needs to:
- Add data points to a map based on a user’s GPS location
- Route the user to a destination they choose
- Save and send a user location to another user
- Have the ability to share on social media.
That’s great! You have the early beginnings of some business requirements. You even have some use-cases:
- User can share their location by pressing a button and their friends can see where they are.
- When a friend’s location is updated, my map is updated and I get a push notification on my phone.
- User can search for a location to travel to based on a map API and start voiceover directions by clicking a button
Meeting these requirements isn’t tough. It’s even inexpensive. A development shop could create a simple specification from your 3 requirements and 2 use-cases and give you a ballpark estimate for those features in a couple or hours. But that’s not the whole story.
Let's say you get three estimates:
AppVille will build your idea for $15,000, HappyAppy will build your app for $17,000 and SmartDev comes in at $50,000.
Well, what's next? Why are they so far apart? In this scenario it’s likely that the first 2 companies are only estimating the features you asked for, and the third company is estimating what you could actually need to bring the idea to market. This is a common occurrence.
To continue the example, let's say you sign a contract with HappyAppy for $17,000 for the 5-6 defined requirements. You’re on the hook to spend that money with them. First step is a robust requirements gathering phase that they can bill for, under contract - they’ve got you. At the end of the requirements gathering phase, once they work on some mockups and designs, they pull that beautiful app out of your head and nail down ALL the features you need to bring it to market, you come to find out it’s going to cost $40,000.
Can you afford that? It's time to take a step back and evaluate if you can make a return on your investment quickly enough; whether you want to spend that much money at all; or worst, what corners you have to cut to get the app to fit into the original $17,000 budget. Do you have enough confidence in your idea to spend over twice the original budget?
This scenario happens all the time and it makes me mad. The requirements gathering phase should be an exchange of ideas. It should be beautiful and creative, iterative, and most importantly, it should give you all the information you need to make a good decision about moving forward with your project.
Decoupling Requirements Gathering from Development
You and your development shop should be on the same page after requirements gathering - expectations should be accurately set and you should view each other as part of the same team. The requirements gathering phase is all about YOU and arming you with good information before you take the leap to actually develop your project.
At Anthroware, we complete the requirements gathering phase outside of a development contract. This is one of the most important things we do. It’s tougher to get the work initially, because companies are often chosen largely based on the ballpark estimate, but it allows us to help get some really important questions answered to help the product owner gain confidence in the development. We want to give our customers real value, and this is one of the many ways we work towards that goal.
Think about the app development scenario from before. Imagine that you hired Anthroware and you used real, valuable metrics like interviews with the development team, average years of experience vs. average rate, safe build practices, and burn rate (asset capacity).
First on the docket is to try and get some confidence that this product is worth building (good topic to write about later). Once the product owners have confidence that the product solves the pain point in brilliant fashion, we move on to the big question: Cost.
It’s worth spending a few thousand dollars up front to get an accurate description of cost and timeline. We might spend $3,000 on requirements gathering and find out the product costs $40,000 to develop--but guess what? Even though you've chosen us to do the work if you move forward, we haven’t signed a contract that hooks you for a single dime. You have no obligations. You can evaluate your next steps with nothing holding you back from making the right business decisions.
The Steps of Requirements Gathering
- Find out if your product is worth building. Either figure this out by yourself, or get a team of experts to help you. Your product needs to solve a real problem, and solve it well. If you aren’t confident in your idea’s ability to give you a return, then stop.
- Interview development companies. Ask them about their software development lifecycle. Ask them what to expect from a requirements gathering phase. Ask them how accurate their estimates are after a requirements gathering phase.
- Ask them if they use safe development practices with backups, and ask them about the specific team you will get for this project. (A great metric is to ask the average experience level of the team and the average rate. If you can get this from every company then you are comparing apples to apples -much better than ‘ballpark estimate’ hell. A similarly sized team with an average 9 years of experience at an average rate of $116/hour compared to 5 years of experience at $110/hr. If your product is highly technical, then you might want more experienced developer, whereas if it’s mainly straightforward web development, then you might get away with a lower average hourly rate by using less experienced engineers.)
- Make a development team decision and expect to pay a few bucks to get the blueprints for your software. Requirements gathering could be a few hundred bucks or $10,000 plus depending on the size of the project. The great news is that final number is fuzzy at first, but starts to come into focus quickly, so you’ll know if it’s a $15,000 project or a $150,000 project early on.
- Develop with clearly set expectations, focused development goals, and have a great contract.
Development should be about solving the problem. And if you follow these steps, then the development direction is clearly geared toward solving it brilliantly.
Once you have confidence that your idea is solving a problem and doing it better than the competition, everyone on the team can understand and support the goals of the project. Your requirements are now clearly written down and drawn out with screen mockups and use-cases, and maybe even some qualified user research data. If you're really sophisticated then you might even have some qualified market and user research data to support your brilliant solution to the pain this product solves.
Pat yourself on the back - you’re ahead of the game! I mean it. It’s really tough to get all this information together. Lets take a moment and reflect on what we’ve gained from undergoing a thorough requirements gathering phase:
- An accurate idea of realistic COST and TIMELINE
- An idea of how the features interact with each other - the core features should be identified. This means you can identify the MVP and get to work.
- Expectations. You have a good idea of what the product will do, what it won’t do, and how it will look. Setting correct expectations is probably the most important part of providing value. You know what you’re going to get and we know what we’re going to build.
- Team communication is tighter and more goal oriented, which means project management cost is greatly reduced
- Efficient development based on clear deliverables leads to incalculable savings of time and money.
- Both the client and the development group are able to feel both valuable and valued - this is so important.
- Have you identified the value of this software? Do you know what it's worth? If you know the cost and time to market from good requirements gathering then you can make a more accurate financial model to help sell the project to your bosses, or yourself.
TL;DR - So what is the main takeaway?
There is no way for me to communicate all the details and nuances of this topic in this short article. Software development and design is a living, breathing thing that changes to fit each scenario. These are the basics, but hopefully this has been enough information to help you think through some positive steps you can take to make sure your next project is a success.
For product managers, fighting for real requirements can be hard. But once you’ve gotten them, it's much easier to be on the same page with the business managers and bosses that might otherwise have unrealistic expectations. Requirements are a communication tool. The benefits extend to the business managers, product managers, project and development managers, developers, and most importantly, to your customers!