When project managers neglect to gather and manage requirements properly, they send their software development projects careening toward almost certain failure.
But this task is more complicated than making a list of needs. It’s a lot like herding cats. Feral cats.
That’s because, if you’re working in Agile, your requirements will expand and contract over the course of your project, threatening to throw off your budget and timeline. Moreover, clients often don’t know what they need, or they think they need features they don’t.
“It’s up to the project manager to ask the right questions and turn clients’ general ideas into something concrete,” said John McGann, a delivery manager at Covintus, which assembles teams of top developers from around the world to devise software solutions.
McGann recently shared pointers for getting your out-of-the-gate requirements right — and making sure those that pop up later don’t throw your projects into a tailspin.
FORGET THE FEATURES
The time you spend with your client early, before your team writes a single line of code, can make or break a project. The first step is to get clients to forget about technology, which doesn’t tend to be their forte anyway.
McGann takes it to the whiteboard, brainstorming blue-sky goals with clients. Even when working with technical clients, he doesn’t accept their features list at face value. He asks the simple but hard-working question “Why?” — sometimes more than once — to get to the root problem they’re solving.
“At this point, the only thing the client should worry about is how their product will behave in the world,” he said. “Instead of relying on a client's imperfect technical understanding, we can use our expertise to identify the technical solution.”
TELL STORIES
Once you’ve helped clarify the client’s vision, turn to customers. User stories describe needs from a user’s perspective: “As a salesperson, I want to add new prospects to this CRM so that I can follow up.”
“Clients start to think about their product not as a collection of features but as a story,” said McGann, who noted that teams can also expand on these stories, and create new ones for different users, as the project itself expands.
LIMIT PARTICIPANTS
Invite only one or two key decision makers to participate in requirements gathering. If too many people are involved, they can have conflicting ideas and come to a stalemate.
“That key decision maker can obviously bring back our work to their organization, making sure there’s buy-in,” said McGann. “But for that to happen, they need something to actually buy into.”
GET SIGNOFF
Given the likelihood that people will interpret technology differently, ensure that everyone understands your requirements in the same way. Both client and team should sign off on the requirement specifications.
“Assumptions are never ideal,” McGann said. “No one should ever be fuzzy on what you’re going to do.”
BREAK IT UP
As coding begins in earnest, break up your project into modules. Developers can focus on meeting the requirements in front of them, while project managers can work ahead with clients, gathering requirements for subsequent modules.
Modules also allow the team to release demos continually, collecting real-time user feedback. You can then incorporate new requirements into future modules, all while staying on track to deliver within your cost and time estimates.
Photo via Shutterstock
For its roster of entrepreneurial clients, Covintus assembles teams of top software developers from around the world. Working on a fixed-price, fixed-timeline basis, teams devise innovative solutions on time every time. Learn more.
.jpg)
