How Do I Convince My Team to Adopt Better Requirements Practices?

A reader asks:

I have been working on a project for the past few weeks that has become increasingly frustrating. The way the project has been handled so far defies many of the practices I have been taught in grad school as well as knowledge I’ve been gaining while preparing for the CCBA certificate. The development team is in control of the project, implementing and presenting templates without a single requirement being gathered. There seems to be a general theme requesting all teams to align with the templates created instead of customizing templates according to current processes. Also, BA concepts are being defined incorrectly; for example, there was a suggestion to treat Change Requests as high level requirements.

When I complained that this is against best practices, etc. I was told that what actually happens in projects is different than what I will read in books. This frustrates me; I am now questioning the benefit of learning more from the BABOK and other resources. Especially since this additional knowledge puts me in a difficult situation within a team that is not interested in following the ‘correct’ way of requirements gathering and management. What should I do in this case?

Adriana’s response:

My first reaction to this question was, “Welcome to the real world!”  Having worked as a BA consultant for many years, I would say the situation described is quite common, actually, in organizations of all sizes and industries. I understand the frustration you are feeling. Why even bother learning good practices when they are completely ignored by your team?

As a matter of fact, there is a lot you can do to successfully convince people to change. Here is what has worked for me when I found myself in a similar situation:

1. Learn How to Influence People

Let’s take a look at how you described your approach to solving the problem:

“When I complained that this is against best practices…”

This sentence alone tells me you are not using an effective approach to affect change.

First, project teams typically don’t care about “best practices” (by the way, like many other experienced consultants, I dislike the expression, preferring to use “good practices,” because rarely a practice will be applicable to all cases, and calling them “best practices” seems to imply a universal “silver bullet”). They care about getting the job done on time, on budget, and hopefully resulting in a quality product that satisfies business and user needs.

Second, “complaining” to the team will only make you look like a negative person. When you “complain,” are you also bringing specific suggestions to improve the team’s processes, or just talking about “best practices” in general? The latter will only make you be perceived as a chronic complainer.

What you need instead is to arm yourself with good points that support your argument, and present them in a manner that convinces the listeners to accept your message and act on it.

In a previous article, I wrote about how to successfully sell your ideas to your boss, and the exact same recommendations apply to situations in which you need to persuade your team to change their practices.

(For anyone who hasn’t tried the strategy described in the aforementioned article, I urge you to try the next time you are in a “nobody listens to me” mood. You will be surprised with how much change you can affect by learning the right way to influence people.)

2. Use Evidence-Based Arguments to Support Your Case

Just because the BABOK or other reference recommends a practice or technique, it doesn’t mean it’ll add value to a particular project. Even agile proponents (who in theory believe in “people over process”) can become unreasonably attached to a practice, (see example here of a practitioner complaining of agile coaches who insist that requirements are written in the “As a… I want to… so that …” format without a compelling reason for it).

If you want you team members to start following a better requirement process, make sure you have evidence that your proposed methods will achieve better results. For example, you could take one of the “templates” they are implementing without consulting the business stakeholders, and create a specification for it using good practices in requirements elicitation and documentation.

Then, if the team ignores your specification, keep it on file.  When the business looks at what the developers implemented, and start to create change requests because it doesn’t fit their needs, show again to the team the specification you’ve produced, and point out how rework could have been avoided if they had based their implementation on your solid requirements rather than on their own ideas about how the system was supposed to work.

You can complement your local evidence with studies about the benefits of quality requirements, found in resources such as The Chaos Report and books such as Making Software: What Really Works, and Why We Believe It by Greg Wilson, to support your arguments in favor of better requirements processes.

3. Describe a Compelling Destination

Using data to back up your recommendations is good, but isn’t enough. As explained by the Heath brothers in the book Switch: How to change things when change is hard, just talking about good practices, and even providing data to support your recommendations, isn’t going to light a fire in the hearts of your colleagues. In order to succeed in making people want to change, you must show them where you are headed, and why going there is worth the effort — in terms they can understand.

Make sure you tailor your message to your audience, and paint a vivid picture that shows what could be possible by adopting better requirements processes (e.g., less stress caused by last-minute change requests, less defects in the final product, and so on). Divide your long-term goals in smaller short-term ones that are easier to achieve, so the challenge seems smaller, and the team can celebrate something they’ve done that has been successful.

Complaining and accusing your colleagues of not being interested in following “best practices” won’t get you anywhere. Switch has great suggestions to help people see the need to change, and make change more attractive to them — check out the book’s tips if you feel you need more guidance in overcoming resistance from your colleagues.

>>Learn More About Better Requirements Practices

Looking for practical ways to reduce requirements defects while also improving your requirements specifications? Crafting Better Requirements is a virtual, self-paced course providing multiple rounds of instructor feedback on your requirements specifications. (You’ll earn 21 PDs too.)

Click here to learn more about Crafting Better Requirements

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more


  1. Srila Ramanujam says:

    May be you could try out this too, not sure if it’ll help but in some instances building and nurturing a healthy rapport with the PM on the project is absolutely beneficial in such scenarios and you can probably resort to leveraging the aid and support of the people who drive the project metrics, to make sure they are with you in the “switch” ideology and see the clear advantages to adopting a more process prone Business Analysis methodology, to help all in the long haul.
    It might just be well worth investing those few extra hours upfront, for analysis and scoping and estimating, rather than to be over-occupied dealing with Change requests down the line!!

    Good Luck with your approach nevertheless……

  2. Thank you for leaving your suggestions, Srila!

    Making an effort to develop a good rapport with the PM and other project members is definitely a good idea, as it will help increase one’s level of influence with the team. And pointing out poor project results based on metrics such as level of requirements churn, number of change requests, etc., may become an excellent argument when trying to convince the team about the value of adopting better requirements processes.

  3. Caroline says:

    As analysts we often tend toward rational influencing methods as a large part of our role is to use reasoning methods to help solve problems (best practices, metrics etc). However, appealing to the emotions of the team is equally as important. It took me a while to realize that EVERYONE wants to feel they do a good job, feel appreciated for it and feel that they have contributed to good of the company, not just me 😉 The final part – lighting up an easy to follow series of steps from the current state to a clear destination also makes sense. A disastrous and long trip through the winding streets of London without GPS or a map quickly taught me the value of this in every aspect of life!

    One other reference I’ve found really helpful in “clearing and illuminating the path”: Karl Wiegers Software Requirements 2nd Edition. There are tangible and easy to implement suggestions throughout the book on how to improve the Requirements Development Process. Also, in Appendix C, there is a section on symptoms, root causes and possible solutions. This has been an incredibly valuable resource in my own efforts to improve requirements processes.

    Thanks for the excellent suggestions and reading materials Adriana and Srila.

  4. Hi, Caroline,

    Appealing to the emotions, and “clearing and illuminating the path” are also huge part of the approach suggested in the book Switch, so we are definitely on the same page :-).

    Thank you for adding to the discussion!

  5. cheap Packers jersey