Fight the system!
By Neil Martin, on 30 July 2010
Earlier this week a few of the Web Services team ‘attended’ a free webinar presented by Paul Boag of Headscape. For those who haven’t heard of Paul before (and who hasn’t?!), Paul is a bit of a guru for the web development community. For many years he’s been blogging and podcasting on all things web. What’s particularly great is that he completely understands that web-related work is often all about people and relationships.
The webinar was titled ‘Fight the system’ and was targeted at internal web teams in large organisations. Large organisations, by their very nature, can create an environment that occasionally leads to issues of conflict between interested parties, departments, etc. and the web team have to negotiate their way through these difficult waters. This can then potentially lead to tricky relationships, poor decision-making, scope creep and an outcome where nobody is really very happy with the website.
Paul focused on four key areas that web teams should consider. These were:
- Raising the reputation of the web team
- How to deal with conflicts, politics and problem people
- How to get signoff
- How to avoid scope creep
Reputation
In terms of reputation, some internal web teams (not necessarily this one!) feel undervalued and lacking the ability to steer a web project in the right direction. Paul suggested that we could all do a lot more to improve our standing and reputation. He suggested to consider some of the following:
- Charge – even if it’s only for a small amount to add value to the work. We have a basic and extended service which does have a charging component. We’ve introduced this because we think it will better define the service that we offer. It should also add value to the extra work we do, such as additional edits that aren’t part of existing templates.
- In your demeanour, be upbeat and positive – try not to say ‘no’ just for the sake of it. If a piece of work is going to be difficult to implement, explain the consequences and consider a phased approach.
- Establish yourself as an expert – be willing to cite other experts as well, and make much better use of facts and figures. For instance a green banner with red text isn’t going to be great, because of accessibility issues, so rather than just saying it’s a stupid idea, show the ‘client’ links to an ‘expert’ article which explains why this won’t be ideal.
- Celebrate good pieces of work – debrief after projects, and don’t be afraid to tell others about how well projects have gone.
Conflicts, politics and problem people
One thing that’s wonderful about web, but can also be frustrating, is that it produces an emotional response from users. Most of the time people do have strong opinions as to how their website looks. This doesn’t, however, mean that they understand best practice and user-centric design. In larger organisations there is obviously going to be politics between various silos, e.g. between technology and marketing teams. Also during meetings there may well be an individual that through sheer presence of personality can force through their ideas even if it’s not beneficial to the website. Paul recommended the following:
- Accept it – learn to live with it, and find better strategies to deal with it.
- Keep talking – problem people sometimes just want to have their voice heard, and will be most frustrated if no-one listens.
- Avoid confrontations - there’s no positive outcome from such situations
- Empathise with stakeholders – share their pains and concerns.
- Show, rather than tell – web teams can sometimes use a lot of jargon which is unhelpful to the client. If you want to demonstrate, for example, a cool jQuery carousel, go off to a website that has one that you like, rather than talk about it using terms like ‘jQuery’ and ‘carousel’.
Signoff
Getting decisions made about web projects can be quite challenging as it’s sometimes not easy to identify who the decision maker is. This is, dare we say, a particular problem within HE, with its traditional committee structures. Paul gave us some food for thought and we may well adopt some of the following approaches:
- Establish the decision maker – quite often this can be quite a senior member of staff, which does present its problems, as they are often very busy people. However trying to make decisions with an intermediary or a group of people tends to end with fuzzy results. Paul suggested meeting with key individuals, rather than groups, as you’re possibly going to get a much clearer picture of goals and objectives.
- Try and adopt some of the processes that are used in agencies, in other words, set clear milestones and timeframes for each key decision. Explain this process to the client from the offset and make them aware of their responsibilities in meeting deliverables within the timeframes set (for example, delivering content on time).
- Capture requirements – and be comprehensive!
- Include them in the development process. Ask them to consider stuff on the fly during meetings. Collaborate, and also refer to earlier decisions where perhaps new ideas conflict with those agreed earlier.
- Get them to focus on business objectives and less on opinions, such as what the website colours should be. Remind them of the user exprience when conversations steer more into subjective territory.
- Manage feedback – ask the client to identify problems rather than solutions. Instead of asking for the homepage to be bright green, ask the question: what is the problem that this decision solves? Is the user base going to specifically benefit from having such a colour scheme?
Scope creep
The bane of all web developers is when a project changes considerably from its original objectives. This can be unnoticeable at first, but obvious half way through. For example a client changes their mind about design elements like fonts, colours, number of pages, site structure, ad nauseum. To avoid this happening Paul offered some advice:
- As mentioned above use an agency approach. Detail the scope of work from the offset and set key milestones and deliverables.
- Explain the process so that it’s well understood with no surprises later on. Establish roles and responsibilities of all parties. Make sure they concentrate on their role and not someone else’s!
- Have a phased approach. If a client comes up with a great idea that is out of scope, mention to them that this is possible, but will have to be shifted to a new phase of the project. Collect the ideas there and then and spec them for later.
- If everything fails fall back on charging!
There was a lot in Paul’s webinar that has given us plenty of ideas as to how to both better manage ourselves, and our stakeholders, and we’d like to thank Paul for sharing his insights – it was a really worthwhile event to be part of!
If you’d like to find out more, it is available (although there is a small charge):
