Internal politics, departmental divides and feuds among the heads of each thiefdom, makes keeping the website on track difficult.
To make matters worse, the web team often has little power to dictate the future of the website. Instead they are pulled in different directions by managers with varying priorities.
In such a climate many web teams succumb to pressure and end up simply implementing the ideas of management, even if those ideas are obviously detrimental to the organisation’s web strategy.
This is understandable. To do otherwise is to challenge management’s authority and to enter into a personal fight that would be almost impossible to win.
Fortunately there is another way than personal confrontation, that is the creation of policy.
Why policy can help
A well crafted policy is a valuable weapon in a web manager’s arsenal. That is because implementing policy is psychologically different from saying no to a colleague or manager.
When you say no to somebody it is often seen as a personal slight. You are saying no to their idea or suggesting that their opinion is not valid. Implementing a policy on the other hand is much more objective. It isn’t about them or their opinion, it is simply a policy that applies equally to all stakeholders.
In the same way a policy is not about them, it is also not about you. It is not you who is being difficult or obstructionary. Instead, if you word things carefully, you are just enforcing a policy laid down by the company.
So how do you go about forming a policy?
Forming an effective policy
To my mind, policies fall into two broad categories. There are those which are working policies and those which are organisational.
A working policy is a policy your team uses to determine your own working practices, while an organisational policy defines policies that the entire organisation is expected to adhere too.
Let’s look at each in a little more detail.
Working policies
As I said, a working policy defines how you work as a web team. For example it might be policy that your team does not undertake new work without a written specification. Another policy might be that all work needs a senior management sponsor to provide approval before work can be undertaken.
The strength of a working policy is that it rarely needs approval from outside the team. You are simply defining the way you do your own job and telling others of this process in the form of a policy.
Unfortunately because they are arbitrary policies defined only by the web team they carry less weight than something defined organisation wide. That said, having a set of working policies in place lets your internal clients know that you have a standard operating procedure and are not singling them out in someway.
Organisational policies
An organisational policy is one that applies to your web presence as a whole, not just the way you work. Typical examples of organisational policies would include:
- Social Media policy.
- Accessibility policy.
- Content style guide.
These are policies that all content providers have to adhere too and so need a more formal approval process.
Typically this means getting agreement from key stakeholders (such as departmental heads) for the policy and its enforcement. Although this is not always an easy process, it is preferable to debating things on a case by case basis. Also, it is often easier to get approval for an abstract policy than it is for specific circumstances.
The great thing about organisational policies is that once approved they have real power and can be more easily enforced than working policies. Furthermore, people like to be consistent and so if they previously approved a policy they are less likely to challenge it in the future.
Admittedly it might sound like a lot of negotiating and work to get an organisational policy approved, but when you see some examples of policies and how they are implemented, you will quickly realise their worth.
Policies that will make life easier
When establishing a set of priorities begin by identifying problems you encounter regularly. Then create policies that mitigate those problems.
What policies you create will depend on your circumstances, but I wanted to share with you a few examples I have seen other organisations implement. Hopefully these will demonstrate that creating your own policies is worth the work.
Dealing with poorly considered requests
Probably the biggest problem faced by most web teams is requests for poorly considered features. Whether it is a new piece of functionality or entire micro-site, there is nothing more painful than creating something that will make the site worse.
I have seen this problem resolved in a few ways. Some web teams establish a working policy that requires all ‘clients’ to submit a set of business objectives for the project. This encourages them to carefully consider why they want the project.
Other web teams frame the conversation in terms of the user, asking stakeholders to express their requirements as user needs they are trying to meet. Some even go as far as insisting their is some supporting evidence that this is a real user need and not some obscure edge case.
Overcoming time wasters
Part of the reason work requests are poorly considered is because there is no perceived cost associated with the internal web team. Stakeholders waste the web team’s time because it costs them nothing.
Some good working policies can help resolve this issue. For example, many internal web teams crossed charge their time to other departments, effectively becoming a cost centre.
This may not be possible in your circumstances, but that does not mean your time is free. An alternative approach is to calculate how much work costs and have a policy of reporting that to senior management.
If stakeholders are aware that senior management are seeing the costs of projects they have commissioned, they will think much harder about how they are going to justify those costs. This is an effective way of reducing time wasting on trivial work.
Tackling out of date content
Another big challenge faced by internal web teams is maintaining the quality of content across the website. Although they are responsible for the website, they probably do not produce all of the content.
This means they need a way of ensuring content providers keep their content up-to-date and remove content that should no longer be online.
There are various policies to ensure better management of content. For example, you could have a policy that states if content is not reviewed within a certain time, it will be considered out of date and removed.
You could also have a policy that removes content which does not reach a certain threshold of traffic over a defined period.
Of course removing content can sometimes be too extreme. Other options include adding a banner to the page telling users the content could be out of date (an approach once used by the BBC), or simply removing the page from navigation and search.
The point is, having a policy to deal with out of date or redundant content will save a lot of arguments with content providers about the relevancy of their content.
Resolving homepage real estate requests
The final area for dispute that I wish to mention is homepage real estate. Fortunately, with the decline of the homepage, this is not quite the hot topic it used to be.
That said, occasionally stakeholders will ask for their content to be featured on the home page. This can be problematic if the request comes from somebody senior and the content they want on the homepage is not appropriate. That is why having a policy for homepage inclusion is extremely wise.
The University of Surrey has a particularly effective policy in this regards. Candidate content for inclusion on the homepage is first featured on the footer of the site. This gives it exposure across every page of the site and provides an opportunity to see if the content is popular enough to justify a place on the homepage.
The content has a defined period of time in which to meet certain content thresholds in order to justify its migration to the homepage. If content fails to reach the threshold it could either remain on the footer or be returned to its original place in the information hierarchy.
The point here is that content has to justify its position on the homepage based on set criteria, so avoiding subjective arguments.
When policy is rejected
In wrapping up let me be clear that I’m not suggesting having a set of policies is a silver bullet for resolving website disputes. There will be occasions when those with enough authority insist on being an exception to the rule.
In such situations I recommend discussing things with the stakeholder. Explain the reasons for the policy and the consequences of making an exception. Suggest that instead of making an exception the policy could do with adaptation. Ask for the stakeholders’ opinions about how it could be improved. This conversation may encourage them to recognise the value of the policy and the damage of undermining it.
Finally, it often helps for policies to be owned by some form of Web steering group. This means that when somebody wants to be an exception to the rule, that will need to be presented to and discussed by the web steering group. This may help to prevent exceptions being decided by whoever can shout the loudest.
Fortunately these exceptions are rarer than you may think. Generally speaking policies prove an effective way of circumnavigating the politics that prove so time-consuming for many in-house web teams.
Comments