I was fortunate to catch news of the free webinar on Twitter and signed up quickly before registration closed.
Paul shared his insights and practical tips for web teams in four areas:
- Improve perception
- Manage politics and problem people
- Get signoff from stakeholders
- Avoid scope creep
- Create value for your web teams. Make sure your team members are appreciated across the organization.
- Consider internal charging in your organization. People place value on people/projects that cost $$. Consultants are paid attention to since they are paid.
- Never say no. Saying no only leads to complication. Praise the positive. Concentrate on great ideas, let the client take the credit.
- Remember the clients are subject matter experts. Don’t allow cynicism creep into your attitude. Recognize their expertise in their areas. Be comfortable with saying you’re not familiar with an area, say that it’s not your skill set, and you will bring in an expert.
- To become an expert, take credibility from other people.
- Be positive. People don’t want barriers, they want positive people.
Manage politics and problem people
- Politics will always be a part of the process. Find a way to live with it.
- Identify backers, both internal and external supporters for your work.
- Keep talking. You need to talk across the silos, across the department divides. Do stakeholder interviews. Set up regular meetings with key stakeholders. Engage them. Get conversation going. And keep it going.
- Biggest problem: what’s left unsaid. You need to establish regular meetings with others in the organization.
- Avoid confrontation. Never say no directly. Explain consequences. Don’t become defensive. Hold your tongue. Remain positive and upbeat.
- Empathize. To create a positive user experience, you need to understand the users. Apply your skills to the internal stakeholders. What is their key pain point?
- Remember that not everyone understands the web the same way the web team does. Instead of explaining how the website works to clients and stakeholders, show a demo.
Get signoff from stakeholders
- Meet with stakeholders individually, not in committee meetings.
- Have a process. Be process driven. It shows to your client and stakeholders that you’ve done this before. If the client has been involved throughout the process, there are no surprises when you present proposals. Which leads to a pain-free signoff.
- Always do a big requirements analysis up front, which focuses on meeting business objectives and user goals. When you present the proposal, it will be based on mood boards, business objectives, wireframes, etc. the client has approved. Base everything you do with evidence that has come from the conversations.
- Focus the stakeholder on the right thing. Get them away from thinking of personal opinion: they need to focus on user goals and business objectives.
- Never ask the stakeholder for their opinion; ask how it fits business objective or what the user will think.
- Manage how you receive feedback. Get client to focus on problems they see, rather than the solutions. Example: I don’t like the pink color on the site. Move client to looking at the problem: “Because we are aiming for a male audience, the pink color may not work well.” It gives you the opportunity to suggest other solutions.
- If the client doesn’t communicate the underlying problem, you can’t offer solutions. Always ask clients for problems, not solutions.
- Get feedback individually from stakeholders and users.
- Structure the feedback you’re asking for. Example: Does this reflect the wireframe? Does this meet business objectives? Does this meet user needs? How you gather feedback is as important as reporting it.
- Since signoff of home pages is contraversial, manage home page signoff:
- Downplay the home page. Explain that website visitors people come into other pages on the site
- Get approval on an inside page; the design has already been signed off.
- Explain simplicity works best
- For those stakeholders that want to have decision making power on the home page:
- Gather stakeholders together in one location.
- Explain there are 15 points of user attention that can be assigned to elements on the home page
- Tell stakeholders they can give each element on the home page a point value. If you want users to pay more attention, give that item more points.
- End result: Creates more focus on what is important on page.
- Have a structure. When you receive a brief from the client (insist on a brief), create a statement of work, with timeline and schedule for both you and client. As scope creep happens, you can refer back to document as a binding agreement.
- Set expectations. Outline how process works, what happens and when. Communicate it clearly. Have a kickoff meeting for the project.
- Define participant roles. Explain the relationship, who does what. It’s a partnership, each partner focuses on different things. The client’s job is to focus on problems, your job to focus on solutions. Emphasize how long it takes to create good content for a website.
- When scope creep (also known as project creep) happens, explain that the changes are not in original scope. Features/functionality will be considered for a future phase. If scope slips, or scope increases, emphasize the increase in the time to complete the project.
- It’s important to note that if client slips three days in delivering content, the schedule moves out three days. Because you have work scheduled, you may have to stop work and wait for content to come in.
- Consider phased development.
- Explain costs of scope creep. Say we can do that, but it will cost $$.
While I had a great time at the webinar, chatting with other attendees, and frantically taking notes, I missed much of Paul’s slideshow. Thankfully Paul has offered his video, slideshow, and PDF of the webinar in a presentation pack for those who couldn’t attend (and for those of us who attended but couldn’t catch everything).
Paul is a great speaker; he speaks to me in a way that I feel he’s sitting in my living room, even though he’s across the Big Pond (Atlantic Ocean). Luckily, I’ve had the pleasure of hearing him speak twice in the past two weeks.
I am thankful for his time preparing the presentation, sharing his knowledge, and helping all of us web workers learn new strategies for managing websites. Thanks Paul!