This article is the second part of Paul Boag's series about common problems and difficulties that occur in in-house Web teams working in large companies. The series explains ways to to improve how your team is perceived within your organization, overcome politics and problem people, ensure that a project gets approval and deliver work within scope and on time. Feel free to check part 1 of the article as well.
Ensuring Approval
When working for a large organization, you constantly require the approval of others to move anything forward. If you want a budget for a new Web project, you need to get senior management to buy in. When you conceive an approach for a new design, it needs to go through marketing and the brand police. Sooner or later, everything you want to do on the website needs approval.
This approval process is often a nightmare. But it doesn't have to be. Understanding a little about human behaviour (which you should already know) smoothens the way.
The first step is to identify key influencers.
Identify the Influencers
Every decision-making process has key influencers. Sometimes the influencer is obvious because only one individual gives approval. But it is usually more complex. Sometimes the person you are dealing with is not really the one with the power. In many cases someone else is, someone with whom you have had no contact. When dealing with committees, you will also learn quickly that not all committee members are equal. Some are senior, while others are simply more dominant or aggressive. The trick is to identify the key influencers.
But don't assume that the key influencers are always the loudest or most senior. Sometimes it is those with the most connections or a close relationship with an executive. Identifying who can swing the decision in your favor can be tricky but is incredibly important.
A Web designer tries to identify who the real client is.
Once you have identified them, the next step is to get them on board. This means dealing with them directly rather than wasting your breath arguing in a committee…
Avoid Committees, Talk to Individuals
The committee is the scourge of larger organizations. They stifle anything but the most conservative of ideas, they move slowly, and they undermine decisive action. Unfortunately, committees are here to stay, and there is little point to fighting them. But there is more than one way to skin a cat and more than one way to run a committee. In fact, you can use one of the committee's greatest weaknesses to your advantage.
One reason committees are so slow is because getting everyone in a room to make a decision is hard. In our case, this is a good thing. Instead of meeting the committee as a group, start meeting its members individually. Some of these meetings can be over the phone or quick chats. But with the key influencers, take the time to sit down face to face and properly discuss the project.
Meeting with committee members individually has two advantages.
First, it puts you in control. Losing control in a committee meeting is easy because members are changing your project on the fly. Design projects in particular suffer from this, with committee members making design changes as they will. But it happens in other types of projects, too.
Meeting with committee members individually prevents this, and you have the added advantage of being the only person with all the feedback and opinions. This puts you in control.
Secondly, it limits ego. In meetings, people become conscious of their position in the group. Some dominate either because they are more senior or simply because they like to talk the most. Others feel the need to defend their corner in some departmental feud. Still others feel they have not had their say and walk away feeling frustrated. Meeting with people individually prevents this kind of group dynamic.
While avoiding committee meetings is hugely beneficial, I am not suggesting that you not include stakeholders in the project's process. In fact, collaboration is essential to a project's success.
Collaborate Rather Than Seek Approval
Shutting out others from the decision-making process is tempting. This is a huge mistake.
The client locked behind bars.
I am a big believer in collaborating with stakeholders and internal clients. By collaborating during a project, you change the dynamic of the relationships.
The problem with communicating with stakeholders only when you need their approval is that they feel no sense of ownership over the project. At best, they feel like an outside observer; at worse, they feel ignored. If you include them in the project as much as possible, then they feel engaged and have a sense of ownership. Then they are much less likely to reject project decisions.
Take the signing off of design concepts. Traditionally, this takes the form of a big presentation in which the design is shown to clients for the first time. This approach is flawed, because the client has not been involved in the production of that design. Consequently, they feel excluded from the process and disconnected from the design, leading them almost certainly to request changes in an attempt to regain control and feel engaged.
At our company, we take a different approach. We include the client in the process as much as possible. We discuss sources of inspiration, show them mood boards and sketch out wireframes with them. By the time they see the final design, they feel that it is as much theirs as ours. There are no surprises, and they are much less likely to reject it.
Taking them through this process has the added benefit of educating them about good design. This significantly improves the quality of any feedback they give. And getting the right kind of feedback is vital.
Control the Feedback
Whether you are showing stakeholders a design or asking for feedback on a proposed project, the way you handle responses is critical.
Clients with no mouths are asked for their feedback.
Again, design is a good example of this problem. Too often Web designers send out a design for approval via email with the question, "What do you think?" Never ask anyone "What do you think?" It frames the feedback in entirely the wrong way.
"What do you think?" focuses the reviewer on their personal opinion. It inevitably leads to feedback like, "I don't like the color." As any designer will tell you, comments like this are useless. Ultimately, it doesn't matter whether the stakeholder dislikes the color, as long as the user likes it. Moreover, you have no insight into why the color might be a problem.
Whether you want sign-off on a design or approval for an element, direct stakeholders away from personal opinion and towards relevant questions like, "What will the user think?" or "Does this meet our business objectives?"
For sign-offs, I regularly ask stakeholders the following questions:
- Does this design meet your business objectives?
- Does the design reflect your brand and website identity?
- Does the design align with the mood boards we developed together?
- Does the design reflect the wireframes we agreed upon?
- Will this design appeal to our target audience?
This will go some of the way toward focusing stakeholders on the right issues. However, the odd individual will still come back with comments like, "Can you make the logo bigger?" or "Change the blue to pink." With a little forethought, you can avoid this problem, too.
Focus on Problems, Not Solutions
Whenever we kick off a project with a client who has to sign off on work, we start by defining the role we would like them to play. Instinctively, people try to find solutions to the problems they perceive. Instead of explaining the problem, they make comments like, "Can you change the blue to pink?" But this gives you no insight into the underlying problem they see, which means you cannot suggest an alternative or even better solution.
Encourage clients, then, to articulate the problem rather than the solution. Instead of making do with "Change the color to pink," move them towards, "We're worried our pre-teen target audience won't like the color scheme." Once you understand the problem, you can suggest alternatives, like adding unicorns or puppies!
The desire to suggest solutions is so strong that people quickly fall back into the bad habit. But because you have addressed this behavior up front, reminding them of it and asking what the underlying problem is becomes easy.
Another tactic is to constantly ask why. This question has two benefits. First, it gets people to articulate the underlying problem. Secondly, it gets people to really think through their thoughts rather than give gut reactions.
Gathering good feedback and focusing stakeholders on what matters are important components in the process of delivering a project. Even the most supportive of clients, though, can delay a project when you allow them to move the goal posts.
Delivering In Scope And On Time
In my experience of working and speaking with in-house teams, scope creep is a serious problem. What starts as a relatively simple project quickly escalates into something much more complex and not necessarily better.
The Web designer was unhappy about the client moving the goalposts.
This happens for several reasons. First, the higher the number of stakeholders who are consulted, the more new ideas and requirements are introduced. This is especially true when it comes to integration. Unsurprisingly, large organizations want their departments to speak to one another. But this too often leads to dependencies that slow projects down or halt them entirely.
The second reason is simply that the client cannot think of everything they need in advance. As they become increasingly involved in the project, they see more that can be done. This is understandable. Your internal clients will not be as experienced as you in working on Web projects and so cannot be expected to think of everything up front.
The final reason is that, from their perspective, the consequences of scope creep are minor. The client probably isn't paying for your time and is not responsible for doing the work. They have nothing to lose from adding more complexity to the project.
You, on the other hand, have a lot to lose. Scope creep leads to delays, which makes resourcing for other projects nearly impossible. It also leads to overly complex websites that are hard to use and tricky to maintain.
You can use a number of techniques to limit scope creep without constantly saying no to stakeholders. The obvious one is to cross-charge. Clients are much less likely to request additional work if they know it will cost money. While this technique definitely works, it can appear a little callous and so should be used only as a last resort.
The best method is to establish a structure within which to work.
Work Within a Structure
Structure is useful for setting client expectations. It establishes boundaries up front that all parties have to work within. A key tool for setting boundaries is a statement of work. This document outlines all of the work to be completed and breaks down the tasks and timeframes. This is the blueprint for the project.
The benefit of this document is that it makes it clear from the outset what is within scope and what is not. The client will often fail to clearly communicate some aspect of the project, and this will get picked up if it has not appeared in the statement of work.
The statement of work also sets expectations for how the relationship will operate. It puts you in control and makes clear that the scope is fixed and cannot easily be changed. By outlining timeframes and milestones both for yourself and the client, you reduce the likelihood of slippages. But outlining timeframes and milestones in the statement of work is not enough. You also need to establish the consequences of not meeting these deadlines.
For example, many clients believe that if they deliver content three days late, then the project will slip only by three days. For you, though, this delay affects other work that you have scheduled to follow this project. It is important that they understand that, given your other commitments, even the smallest delay could push the project back weeks.
The same holds true for scope creep. Adding complexity delays the project's completion and thus affects other projects. The problem is that exercising this discipline can make the client feel constrained and perceive you once again as the road block. So, wield this weapon carefully. I soften the blow by talking about phased development.
Talk About Phasing Development
The last thing you want to do is crush your client's enthusiasm for a new idea they've come up with. As I said earlier, you want to remain upbeat and positive. Instead of pointing them to the statement of work to show that their idea is out of scope, enthuse with them about the idea. Discuss it together and outline roughly how it would work. But then point out that implementing it now would impede the project's development, but that it could be implemented as part of a second phase.
You will find that most internal clients and stakeholders do not really grasp the dynamic aspects of the Web. They perceive the Web like print, that once the website goes live it cannot be changed. We know this is not the case; one of the huge benefits of the Web is that it can be changed incrementally.
Get the client to think about the Web project as being rolled out in phases. Launching everything together is unwise for two reasons. First, users do not respond well to sudden dramatic changes to a website (see the Facebook redesign as an example). Secondly, you can never be sure that the functionality they are proposing is what users really want. By rolling out a smaller website, you give users a better chance to interact with it and provide feedback on any functionality they feel is missing.
Finally, phased development limits complexity. With complexity comes a greater risk of something going wrong or the project being delayed. Phased development allows you to test more manageable components and so be confident in what you are delivering.
Conclusions
No doubt, in-house teams face enormous challenges. But hopefully this post has demonstrated that overcoming these challenges by carefully handling internal stakeholders and your own department's image is possible.
I am not claiming that what I have presented here is in any way a magic bullet. You will still meet individuals who refuse to cooperate or who throw their weight around. But by using these techniques, you should at least be able to lessen the load and start enjoying managing your website again. After all, nurturing a website over the long term is a job that many in agency positions, including me, envy. If only you would overcome the bureaucracy.
All images have been kindly supplied by Shuttershock.com
(al)