When Good BAs do Bad Things

Featured
13884 Views
1 Comments
68 Likes

Being from Brazil, the topics of ethics and dishonesty have become top of mind for me as President Roussef got put in a presidential time out after being caught up in a corruption scandal involving the country’s state-owned oil company.

And that’s not necessarily a bad thing: as studies in psychology and behavioral economics from academics like Professors Muel Kaptein and Dan Ariely tell us, cheating and dishonesty are inescapable parts of the human condition. Their work reminds us that given the right circumstances, even good people can go astray as our psychology push us down the slippery slope of questionable behavior.

Thankfully, a little bit of knowledge about the forces that drive us to cheat can go a long way helping avoid bad behavior. Here are some common landmines to become aware of so you can make sure to defuse them as you embark in a new BA project:

Tunnel vision. 

When someone is possessed by a singular focus on a particular goal, there is a risk that he or she will start making decisions with disregard for other important considerations such as compassion and ethics. For example, a BA who is obsessed with maintaining a perfect record of delivering requirements on time might become tempted to gloss over stakeholder analysis to eliminate any possibility of delay. Deliberately ignoring some of the affected groups during requirements discovery just to ensure a deadline is met might result in a short-term win, but at the high cost of introducing significant risk of delivering an inferior solution that overlooks relevant needs and expectations across the organization.

The compensation effect. 

When we do a good deed, we tend to assume we’ve accumulated moral capital, and become less likely to scrutinize the moral implications of our bad behavior. For example, if a BA goes out of her way to help a colleague understand a business domain, she could later decide to only take a cursory look at a requirements document during peer review, under the guise of “I’m a good person”, or “It’s just this one time.” By neglecting to do the deep review work that can truly help spot and fix the problems and omissions in requirements early in the project cycle, the BA would be doing a huge disservice not only to the colleague, but also to the whole company.

Broken window theory. 

When chaos and disorder are the norm in an organization, people are more likely to exhibit bad behavior that’s in line with this perceived chaos. An example would be a BA who doesn’t invest the time to write clear, descriptive, and jargon-free requirements because the IT department lacks formal change management controls. Under the justification that the requirements are bound to suffer from future uncontrolled changes anyway, he could decide not to make an effort to make the requirements easier to review and estimate, thus creating additional chaos and increased lifecycle costs.

The Pygmalion effect. 

When someone is treated as a valuable member of their team, they are more likely to act accordingly. Likewise, if they are treated with distrust or disrespect, they’ll develop the propensity to act in a way that justifies that perception. This problem could easily affect a BA working in an environment where business analysis is undervalued, causing them to use lack of management support as an excuse for low performance.

Reactance theory. 

When rules are too strict, or employees see them as unfair, individuals will feel compelled to violate them to gain back their freedom. A typical example is a company with excessive rules about the list of requirements artifacts a BA is supposed to create for each project. Too much emphasis on documentation standards may cause BAs to resent the lack of flexibility required to meet individual project needs, and end up just going through the motions, potentially copying and pasting from older documents without concern for content accuracy just to pretend adherence to the rules.

Obedience to authority. 

When we are following the direction of someone in a position of authority, we may feel like we're less responsible for any wrongdoing. For example, imagine a CIO who prides himself on delivering all software projects "on time, on budget, on spec" without any concern for producing what users really need. If a delivered solution doesn't satisfy user or business needs, stakeholders are instructed to submit change requests after the system is released to production and the project's "success" has been celebrated. Under these circumstances, a BA may feel pressured to "stick with the program". Finishing the requirements quickly may start to take precedence over spending enough time to understand the real business needs and make sure the solution will meet users’ functional and quality expectations.

Bringing It All Together

If you think about it, it’s scary to realize how easily the environment can affect people’s moral compass. When you feel you may be struggling with moral disengagement, the best thing to do is to take personal responsibility. Step back and ask yourself:

• Would I normally consider this action to be wrong?

• Am I using external circumstances to excuse my harmful actions?

• Am I just focusing on compliance and abiding by the rules, or truly committed to doing what is right to deliver the most value to my team and organization?

The best antidote to keep us loyal to our ethical selves is to develop awareness of how prevalent mild cheating is compared to outright fraud, and of what motivates this type of questionable behavior so we can remain vigilant and avoid them.

Have you seen any example of work situations causing BAs to develop unethical behaviors? Do share your thoughts in the comments section below so we can all learn from each other.


Author: Adriana Beal, Product Management & Business Analysis

Adriana Beal has developed a successful career in business analysis and product management, having lead the investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. She is also the coach of Crafting Better Requirements, a program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and the author of the ebook Measuring the Performance of Business Analysts, which has been adopted by dozens of BA managers interested in improving the performance measurement systems in their organizations. Her most recent ebook, designed to help BAs struggling with getting the right information to analyze and use to specify their solutions, is called Tested Stakeholder Interviewing Methods for Business Analysts.

Like this article:
  68 members liked this article
Featured
13884 Views
1 Comments
68 Likes

COMMENTS

dayiku posted on Thursday, December 1, 2016 7:58 AM
Thanks for this.

Only registered users may post comments.




Latest Articles

Domain Expertise and the Business Analyst: How Vital Is It?
Sep 15, 2019
2 Comments
The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains tha...

Copyright 2006-2019 by Modern Analyst Media LLC