Rethinking Project Requirements

Before kicking off a new digital project, you need a thorough project brief, which can only come together accurately (and effectively) once you’re prepared to answer a few basic questions that you’re probably already familiar with: who, what, why, when, and how. When our team at Modern Tribe approaches a new project of any size, we tackle project definition through two major components:

Gathering Requirements:
• Who are the users?
• What do they need?
• Why do they need it?

Building a Roadmap:
• How will we build it?
• When will we have it done?

On the surface, these critical process milestones are closely intertwined. But each step requires independent consideration, allowing us to think about goals and objectives first, without getting mired in logistics and stuck on the realities of budgets, timelines, and technical limitations. First, we get clarity on what success looks like. Then we focus on how to bring that vision to reality.

You’re unlikely to be the only decision maker in your organization, of course. There’s more likely a whole team of people waiting to offer input on what these priorities look like and where the biggest needs reside. Soliciting this input and subsequently organizing the resulting information in a cohesive way can be a time-consuming—and quite frankly, exhausting—endeavour. By creating some structure around this process, you can turn hours of wandering brainstorms into a short series of workshops that will ultimately tie your project scope back to your organization’s most important objectives. This can be especially helpful when you’re faced with a large, heavily invested team that may have a wide variety of technical aptitude, comfort, and confidence.

Getting People Engaged

“Requirements definition” has a tendency to sound pretty technical; many key business leads who could otherwise offer valuable early input instinctively end up opting out of this highly strategic early step because of misperceptions. Project leads also have a tendency to want to keep a small, efficient team, and might not want to invite too many opinions. But if stakeholders aren’t engaged early on, we almost inevitably hit some major roadblocks, “mystery voices,” and unanticipated requirements that could have been otherwise captured early in the process with the right engagement tools.

Think of “requirements definition” as a fancy way to say “goal setting.” We’re building alignment on the priorities for the project and establishing success criteria. From the most straightforward website to a more complex digital project, that particular conversation is super relevant to the technical and non-technical alike.

Fueling User Stories

We’re not just building a product—we’re building a solution. Solutions solve something. So let’s start by understanding what challenges we’re trying to solve. Give your departments or business units the required space to talk about their core business objectives and the unique users and goals that drive success in each of those areas.

User stories are a great way to document this information. A classic user story looks like this:

As a <user> , I want <some goal> so that <some reason>.

But there’s often some additional context that’s helpful to capture at the ideation stage. Practically speaking, here’s a framework you can use for the initial discussion, whether you’re whiteboarding in person or brainstorming remotely through a shared spreadsheet.

Adding Context

For each department or business unit, create a thorough list of key business functions. Establish user types, goals, and desired outcomes for each one. Then, based on your current system or process, determine how satisfied the team is with the status quo. Discuss if this function should be retained from the way you operate today, rebuilt in a similar fashion on the new platform, or reimagined completely.

Business Objective

Remember to conduct this exercise for internal users and external users. Evaluating from an internal perspective gives us the opportunity to understand opportunities to streamline workflows or reduce the strain your valuable human resources.

The goal of this initial session is to go wide and shallow, ensuring that you capture all the key objectives at a high level without letting the conversation get too detailed in any one requirement. You’ll get a bird’s-eye view of the landscape and be able to identify the best areas to spend your creative energy moving forward.

Prioritizing Needs

For each of these user stories, ask your stakeholders to prioritize using three ratings: 1) Must have, 2) Should have, 3) Nice to have. This allows you to put aside the questions of budget and timeline while capturing the importance level of each. When you get to the estimating or roadmapping stage, you’ll have the data you need to make important decisions about what stays and what goes. If you find yourself with a group of all “must haves,” try asking them to rank their requests in priority order instead.

Brainstorming with a Mission

At the end of your session, be sure to revisit the future-state categories you assigned. For anything that’s marked as “retain” or “refine,” you’ll probably be able to capture any details or requests in that initial session. For requirements that need to be reimagined, set aside separate follow-up brainstorms with specific subject matter experts to dive a little deeper on the goals for these particular features:

• What are the challenges with the current method?
• Are there specific platforms or technologies that should be integrated or considered?
• Is there an off-the-shelf solution that meets our needs, or are there solutions that we have explored and ruled out?

Moving these detailed conversations to separate, focused sessions helps you streamline the conversation without causing fatigue for the rest of the group. Your stakeholders will be grateful that you’re using their time efficiently, and you’ll make a strong start in building trust in your core project team.

Putting it All Together

Once each department or team has created their list of requirements, compare across teams and look for places where there are shared goals or similar requests. The consolidated items can go in a general requirements section, with separate sections for unique requirements from each department. Once you have that curated list, you’ll have the critical data to inform your project scope—whether you’re tackling this project internally or preparing to craft an RFP. Either way, the energy you invest at this early stage will give you a solid understanding of the challenges your new platform needs to solve and opportunities you can create for your users.