Top Five Frustrations of Requirements and How to Avoid Them

Thank you!

Download the Paper

About this Paper

Every year, the complexity of projects increases. The average requirements document is over 100 pages and changes 20 times during the development process. It’s brutal. That means as a Business Analyst or Project Manager, you likely spend hours circulating, editing and tracking changes to a hefty requirements document with the hope that your team actually stays engaged and reads it. Wishful thinking, right?

The old way takes crazy heroics and is a nightmare to manage using Word, Excel and email. Your time is more valuable than that.

The problem isn’t the requirements document itself. The problem is in using the document as the place to manage requirements. If you’re hoping to set expectations, communicate project details, and track changes throughout the process with documents – good luck. You’ll need it.

So, what can we do? Well, we can tell you one thing. We can’t continue to do things the same way and expect a different result. As the people who are responsible for ensuring everyone understands what we’re building and why (a.k.a. requirements), we have to evolve how we work. We must embrace new techniques and tools to find a better way to communicate requirements and deliver the right solutions while making the process as enjoyable as possible. We’re not suggesting there is a silver bullet. Project execution isn’t that easy.

We’ve compiled the top 5 frustrations based on what we’ve experienced and seen others endure over the years. And, we include a tip for how to combat each one. All of these tips support a new, more collaborative way of working which focuses more on the people and the communication needed to be successful versus the documents. We believe requirements management isn’t about managing documents, it’s about keeping your team in sync on the goals of a project and executing on building what’s right.

FRUSTRATION: The 11th hour swoop-in

An executive comes to you last minute with feedback that you needed three weeks ago.
Is it a must-have change or a nice-to-have change? Do you push the deadline? Do you immediately push-back to say, “Thanks, but we’ll get that into the next release?” Maybe you go home after working late again and watch the movie “Office Space” for the 30th time to try to laugh it off so you don’t go postal on your boss the next day.

TIP: Be open

Give management better visibility and a continuous feedback loop to address issues before it’s too late.

To be honest, we’ve been on both sides of this frustration. It’s unpleasant to be the swooper and the swoopee. The reality is that managers are busy dealing with a million different issues, and whether right or wrong, they will focus on what’s most urgent. Also, ideas come to management and other stakeholders after they see prototypes and realize what was specified in the initial requirements document a month ago isn’t the best solution now.

To prevent the 11th hour swoop-in, you have to be transparent and open for feedback at all phases of the project, and have frequent check-ins to get reactions early. If your team and executive staff are in the same office, this is easier to accomplish. Have a whiteboard or dedicated wall in a prominent location sharing the latest designs. Every day, they’ll walk by and have an opportunity to react to what they see. Most people respond better to visuals versus written words to understand the user experience.
If you’re a distributed team in multiple locations, as is common today, then a specialized tool that provides everyone a central hub for the project’s requirements, related designs and real-time feedback will help. They’ll see what’s happening as the project evolves no matter where they are, and you’ll be able to keep your finger on the pulse to hedge any disagreements or potential gotchas from happening later.

FRUSTRATION: Decision rehashing

Hosting endless meetings where half the time is wasted revisiting old decisions or bringing others up to speed.

We’ll admit this one drives us crazy. We dislike meetings. But, we especially dislike meetings that are monopolized by rehashing decisions already made. “Why did we decide to change the functionality of that feature?” “When did we approve that?” “Bruce was out last week, can we revisit the plan so he’s up to speed?” Painful, inefficient, frustrating.

TIP: Be clear

Provide full context of the decisions being made so everyone understands the scope of the project and why. People need clarity and understanding to execute at their best.
This applies upstream to your stakeholders and customers so they understand what they’re getting and it applies downstream to your design, development and QA teams so they know exactly what to build and to test properly. As a solution, new collaborative tools exist that will help you capture the healthy debates and ongoing discussions that naturally take place around requirements, and they don’t require hosting more meetings. People can add their feedback anytime and see what others are saying to agree or disagree, approve or reject, or propose edits to refine the solution.

Also, the decisions that occur in meetings aren’t easily tracked in documents and people’s memories fade as time goes on. How many times have you left a meeting feeling great, thinking everyone is on the same page, only to find yourself debating what the team decided a few weeks later?

If this is an issue for your organization, adopt a new technique to capture decisions in line with requirements, and make them easy for the team to view anytime. This will eliminate ambiguity and ensure that decisions about the project are crystal clear.

FRUSTRATION: Change tax

Manually sending updates to everyone when something changes kills a third of your day.

Anytime you’re doing something manually, ask yourself, “Can we automate this?” With today’s tools, often the answer is “yes.” In the case of executing complex projects, change is just something that’s going to happen. And, often for good reasons. As you get deeper into the design and development of a project, you know more than you did at the beginning. Thus, you and your team will think of better ways to build the desired product as you iterate upon the requirements along the way. If you try to manage versions by tracking changes in Word documents, then you’re going to experience a huge tax on your time. It’s nearly impossible to write the perfect requirements document the first time. So stop believing that’s a goal.

TIP: Be iterative

Embrace changes intelligently by connecting the dots, quickly assessing the impact and communicating the changes to the right people involved automatically.

We can’t talk about requirements without talking about change. And we can’t talk about change without talking about being “agile.”

The #1 reason to adopt agile within your organization is to create a culture that is nimble so your team can respond quickly and effectively to changing requirements. Thus, iterating as you go.

Don’t get hung up on the labels or the debate of whether Scrum vs. Kanban is superior. There is no definitive, one-size-fits all process. Agile first and foremost is a cultural mindset, not a prescriptive development process.

You want your entire organization to feel empowered to propose a change if they find a better solution. If you’re coming from a more traditional Waterfall approach, your challenge with adopting agile is to avoid going from one extreme to the next. There is a myth that agile is about not having a plan and just building – which isn’t the case for most organizations. Smart agile teams maintain requirements best practices borrowed from traditional methods such as traceability, impact analysis and change management, so they can understand the ripple effect that a change has on the rest of the project. It’s a balancing act between agility and formal control. Some call it a hybrid approach. Again, the labels don’t matter. The key is to find the mix of techniques that works best for your team so you can execute projects without friction. That’s what matters.

FRUSTRATION: Attention deficit

Creating a detailed 200-page plan that no one has time to read once, let alone every time a change occurs.

You did it. You just completed a month-long effort eliciting feedback from 50 stakeholders and writing the most beautiful requirements document of your life. From a CMMI or BABOK perspective, it is pure poetry of shall statements and use cases. Okay, enjoy that moment for about 30 seconds, because it will quickly be replaced with the fear of whether anyone will actually ever read it.

As project complexity increases, how do you articulate what the plan is without creating a monster of a document? It’s tough. The issue might not be the length of the complete specification document. The issue is that you’re trying to communicate the entire plan to everyone using the document. In reality, most people only work on and care about specific parts of the plan at any given time.

When one item changes and you send a new version of the entire requirements document, it’s both information overload and white noise at the same time. We can’t expect people to hunt and peck for what changed and determine each time if it’s relevant to them or not. This old way is incredibly inefficient, and people just stop paying attention.

TIP: Be relevant

Adopt the philosophy that everyone is simply too busy to absorb the entire document. Because literally, they are. To avoid being frustrated by your organization’s collective attention deficit, relevancy is key.

This is an area where tools can help you break large, complex projects into smaller manageable parts, and let people filter in on what’s relevant to them. We recommend you manage the scope of projects item by item to get work done. If you’re curious what we mean by “item,” a requirement is an item. A use case is an item. A test case is an item. A defect is an item.

People naturally work on a list of a few items at a time. It’s how our brains work and we’re more productive that way. By itemizing the scope of your projects using a tool with a relational database, it will allow people to focus on specific items they are working on, while maintain context of the overall project. Then, as needed for baselines, releases or milestones, you can group together items and summarize the project via reports or a specification document for a holistic view.

FRUSTRATION: Mismatched expectations

A stakeholder thinks he is getting X, Y & Z and is actually getting X, A & B. It feels like a punch in the gut. You and your team put your blood, sweat and tears into delivering a project only to learn after the launch that the end users aren’t happy. What the heck happened? How did we miss the mark? Why is there an expectation gap?

TIP: Be proactive

People have selective memories. We all remember what we want to hear. What stakeholders forget is the additional things they add along the way or the reprioritization of features as the scope evolves over time. The X becomes X+1, and the Y becomes Y+2 and soon Z is out and instead the priority shifted to A and B, but not everyone was clear on the trade-offs that were made because the decision was made over the phone from a late night call with the customer.

The intent was right, the team was being agile, but what was missing was the captured communication with the stakeholders documenting the requests, agreements and approvals by the appropriate stakeholders.

Next time, get buy-in on the priorities and capture the justification of what’s in and what’s out of a project, to ensure everyone has the same expectations. Without adding a lot of unnecessary overhead, new tools offer the capability to capture the reviews, approvals and electronic signatures for scope changes as part of the natural workflow.

That way everyone can feel confident they know the true plan and the team can feel good about delivering what’s promised. You deserve to have the launch event be a celebration not an interrogation of what went wrong.