Most Business Analysts spend their careers searching for the perfect requirement. We focus on clarity, completeness, and technical feasibility. We consider that if the wording is exact and the logic is sound, the resulting feature will deliver value.
This focus is dangerously naive.
In the corporate world, requirements are rarely about technical necessity. They are instruments of power, used to secure budgets, settle old scores, and protect departmental turf. A politically corrupt requirement is one that looks functional on paper but is designed to serve a hidden, non business agenda. It is a lie disguised as a line item.
If you document a corrupt requirement, your project is doomed, regardless of how good the code is. Your job is not to transcribe these lies. Your job is to expose them. I will show you the seven critical red flags—the political signs—that signal a requirement is designed to help a person, not the business.
# 1. The Requirement Based on Legacy Pain
This is the requirement that starts with the phrase: “Well, we had a major problem with that back in 2012, so we need a manual override…”
The requirement is not based on the current process or the new system’s capabilities. It is based on a traumatic event from a previous, obsolete system. The stakeholder is asking you to spend millions to prevent a problem that the new technology has already made impossible.
The Political Sign: The stakeholder is protecting themselves from a past failure that hurt their career or team. They are prioritizing Personal Safety over Current Efficiency. They need the override not because the system is unreliable, but because they fear being blamed if anything goes wrong in the future.
Your Action: Do not write the requirement. Document the cost of the trauma. Ask: “What is the likelihood of that exact failure happening in the new system?” Then show the cost of building the manual override versus accepting the residual, tiny risk.
# 2. The Solution That Exists Already
You spend hours collecting a requirement only to discover that the same exact functionality is already available in another piece of software the company owns, often one that the stakeholder’s department is supposed to be using.
The Political Sign: This is a blatant Turf Grab. The stakeholder is asking you to duplicate work because they do not want to rely on the team that owns the existing solution. They want their own budget, their own system, and their own headcount to control that function. Their goal is not to improve the business; it is to increase their departmental power.
Your Action: Bring the two system owners into the room. Do not ask what they need. Ask why the existing solution fails to meet the business need. If the answer is “because I do not trust them,” the problem is not a requirement; it is a political conflict that needs executive intervention.
# 3. The Requirement with a Single User
The feature is complicated, expensive, and requires a lot of testing. You trace it back and realize that only one person in the entire organization will ever use it. This person is usually a senior VP or a long tenured manager.
The Political Sign: This is a Power Perk or Pet Project. It is a way for a powerful person to feel heard and important, using company resources to automate a minor personal task. The cost benefit analysis is completely upside down.
Your Action: Quantify the value. Document the cost of the feature, then divide it by the number of daily users (one). Present the number to the sponsor. Frame it as, “This $100,000 feature saves 10 minutes a day for one person.” This forces them to acknowledge the personal luxury they are demanding.
# 4. The Requirement That Defies the North Star
This requirement is logically sound, but it directly contradicts the company’s highest level strategic goal, or “North Star.” For example, the North Star is “reduce time to market,” but the requirement is “add two more layers of managerial approval.”
The Political Sign: This is a Resistance to Change. The stakeholder knows the new strategy is coming, but they do not like how it affects their existing process or their team’s importance. They are trying to use the requirements process to sabotage the strategy by making it slow and difficult.
Your Action: You must use the highest level company goal as a weapon. Do not challenge the requirement itself. Challenge its alignment. Ask: “How does adding this step align with our goal of reducing time to market by 40 percent?” This puts the political burden back on the stakeholder to explain why their requirement is more important than the CEO’s directive.
# 5. The Impossible Interdependency
This requirement demands a perfect, instantaneous flow of information between two departments that historically hate each other or use completely different technologies. Example: The Sales CRM must update the Manufacturing floor sensors in real time.
The Political Sign: This is Requirement Poisoning. The stakeholder knows the technical team cannot deliver this because the required organizational cooperation does not exist. They put it in the document so that when the project fails, they can blame the other department or the IT team for the impossible failure. They are setting up a fall guy.
Your Action: Document the organizational dependency first. Write a separate document that says, “Requirement X is dependent on Department A agreeing to use Data Format Y.” Do not let the IT team start the code until the political agreement is signed off first.
6. The Requirement That is Really a Process Problem
The requirement asks for a complex, expensive software fix to enforce a policy or manage a poor human behavior. Example: The system must use facial recognition and a three step login to ensure people are not sharing passwords.
The Political Sign: The department lacks the Courage to Manage. They know they have a management problem (e.g., poor training, lack of trust, or a bad policy), but they are too afraid to solve the people issue. They are trying to use a software solution to manage people, which is always costly and often fails.
Your Action: Before writing the software requirement, propose a simple policy change or training session. Ask: “Can we solve 80 percent of this problem with a one hour training session and a new HR policy?” Force the team to consider the cheap, painful management solution before committing to the expensive, soft software solution.
# 7. The Unjustified Extreme
The requirement demands a performance level that is far beyond the normal business need, such as demanding 99.999% uptime when the actual business impact of an hour of downtime is minimal.
The Political Sign: This is Fear of Accountability. The stakeholder is creating a buffer to protect their job. They want an extreme level of performance so that if their department is slow, they can blame the IT team for not meeting the impossible standard.
Your Action: Introduce the concept of Tiers of Service. Document what 99% uptime costs versus 99.999% uptime. Show the cost difference and ask the executive to sign off on the specific dollar amount that they are willing to spend to avoid the five minutes of downtime per year. This forces them to ground their demand in financial reality.
The moment you accept a politically corrupt requirement, you stop being a Business Analyst and start being a political scribe. Your greatest value lies in your ability to be objective, to ask the difficult questions, and to protect the company’s money from political waste.