Politics as business requirement

I've been experiencing some frustration this past week with a client mistaking internal politics with "business requirements". Essentially, we're being asked to structure the underlying architecture of the web site to meet a set of poorly-defined requirements due to the clients' difficulty in influencing other departments with respect to the purpose of the new site.

The key issue we're having is with internal marketing teams not wanting to use a common taxonomy on a shared Web site. The internal teams represent geographic marketing regions, and firmly believe (wrongly, according to the user research) that they need the freedom of labelling information idiosyncratically within their regional section of the site. The internal Web team don't possess the political clout to veto this requirement, and so we're forced to put in place a solution architecture that will accommodate a loosely-defined page architecture - effectively undermining one of our key success requirements: consistent labelling across site sections.

In hindsight we should have been talking to these internal marketing teams a lot sooner, but the client had already produced such a comprehensive set of 'approved' documentation laying out the site's content strategy that we were lulled.

Something to keep in mind in future projects, definitely, but it raises an issue when attempting to create a balance between user & business requirements. When approaching our work I like to review with the business stakeholders their objectives - in the form of marketing plans, business plans, competitor activities etc - and how those objectives might best be achieved through the Web site under review.

At the same time, we'd be conducting user research - in the form of surveys, one-on-one interviews, etc - to determine the user's objectives at the site, and the major tasks that they may need to undertake.

Politics enters the mix when one group of internal stakeholders - for reasons of their own - skips straight to the definition of functional requirements and site features, labelling them as "requirements". All evidence and arguments to the contrary, for example all of that user research indicating that the 'requirements' achieve nothing, are brushed aside. There is no way to balance this type of requirement - balance is not in the picture for this stakeholder.

The only hope here is to attempt to 'sell' this stakeholder on the project vision as early as possible. Sometimes this works. Sometimes... well this past week speaks for itself.