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?
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.)