Good pointers that a software requirement is in fact political?

Question

Probably an easy one:

Are there any rules of thumb or pointers that could help recognise political requirements?

Let’s say one of stakeholders (your boss, a head of another department or an actual user) asks for a feature or particular characteristic of software being developed by yourself or your team. Is there a litmus test to determine whether requirement is political?

This question is really simple and is not about how to deal with political requirements or whether they are bad or good for software. How do you tell that whatever you have been asked to do is to pursue someone’s tacit or actually openly stated political agenda?

Answer 1

Obviously it's a tricky question and much depends on your definition of the 'political'. I would start with the simple question: * Are the authors/originators of the requirement really using the software in question?

The requirement could come from your boss but it could be a translated valid requirement of the real user

Answer 2

The best idea is to find out what all the features are to be used for, i.e. find out not only how a feature is to be implemented, but also learn why it should be done. It really helps to know the background of the desired solution. It might even allow you to suggest an alternate feature set that might better suit your customer (maybe even play your own political game).

As long as there is anything you do not understand, do not do the project. It will only cause problems at some point.

Answer 3

The use of ambiguous words or phrases is often political.

However,

Never attribute to malice that which is adequately explained by stupidity.

Answer 4

Will it really help you to know? I mean - if you're already embroiled in political games you'll know anyway. If you're not it isn't something you'll be able to use.

If you're going to have to implement the feature anyway I'd say just get on with it. Finding out that it's part of some management game will only demotivate you.

That said - if you're working on the sort of application that's so themware that you can't tell whether it's a real user feature or a political lever of some sort then it's probably a safe assumption that everything is political.

Answer 5

Here are some I've seen:

• It directly contradicts other requirements
• It is clearly not feasible technically
• It is "out in left field" ... it doesn't fit into the defined problem space
• It contradicts common sense

BEWARE ... sometimes this results from your use-cases being wrong or incomplete. I've also purposely allowed some of these to proceed to development (e.g Eye-candy that sells the product but is useless or at least generally not used by the operators).

Answer 6

I would say that you should assume that all requirements are political.

If you are in a situation where more than one person is responsible for determining the set of features you implement, then every feature is effectively a negotiation between those people. That negotiation makes those features political.

However, even if there is only person deciding what features ship, there is still a pretty strong chance that those decisions are political. In any organization of reasonable size (say more than ten people), you are going to have politics. The politics in that situation will differ than the "design by committee situation". They will focus on currying the favor of the person who decides which features ship, rather than on "if you support my feature, I'll support yours" that exists in the committee scenario. That process, however, is still political.

I'm not trying to say that it's not possible to have a development environment free of politics. It is. However, I would say that to pull of it off that you need:

1. A small, tightly knit team
2. A boss that focuses on creating an environment that fosters creativity, and delegating creative ownership, rather than focusing on control over the creative process.
3. Smart, highly talented and creative people that share a strong sense of purpose and aesthetic values.

Missing any one of those things, you are doomed to a repetitive deluge of office politics.

Answer 7

Use the SCRUM approach. Don't describe a feature as

"It should be doing this and that in the following way"

While the sentence above describes all you need to know to implement the feature, it does not justify the feature. My SCRUM book says features should be written down as a story. A story looks like this:

"As a <user-role>
I need a <functionality>
So that I get <business value>"

A feature that cannot be justified using such a story is an unjustified feature and thus there is no use to actually implement it.

E.g.

"As a visitor of a web portal I need a way to authenticate, so I can access my customer data, but nobody else can"

Now you don't only know that you need an authentication for your web portal, you also know who needs it (the visitors, basically everyone planing on using it more intensively) and you also know why it is needed, as it gives the user some value.

Other examples:

"As a passenger I need a list of all my booked journeys, so that I know when I'm going to travel where and won't lose the overview"

"As a book keeper, I'd like to have the sales tax being automatically printed to each bill based on customer data, so that I don't have to enter it manually each time I'm printing a bill"

If every feature needs to be written like that, you'll automatically see if a feature is for the customer, because it is really necessary, or just something your boss/company wants to have and also why they want to have it (what is the big picture behind it? Why are they doing it?).