Vanity publishing and the art of saying yes (and no): part 1
Understanding requirements and results
The program lead stops by your desk with a web publishing request: update his entire site with a new tagline and logo, plus new content, a video and a blog, by end of fiscal year. He asks you to also prepare a deck to the senior management committee about the new approach for the site by next week.
Your coffee grows cold as you contemplate the 150 reasons why none of this request is feasible or desirable. For a start, you have very limited resources and most of your team are already scrambling to meet day-to-day publishing needs. How do you constructively say no to such a request and keep a good relationship? Does it ever pay to say yes when it feels like a vanity publishing project?
This three-part blog series will explore ways in which you can respond constructively to define a rationale for saying yes or no, in a way that everyone can agree to.
Your first step is to take a closer look at the client’s needs.
Research your client’s requirements
Why this publishing request and why now? The program lead gave you two hints: there’s a new policy and senior management is demonstrating interest in the short term.
Your initial task is to get time with the program lead to explore the business requirements in more depth. Use these questions as a guide but also listen to your instincts to dig deeper and learn as much as you can:
- What are the program business objectives and outcomes related to this policy?
- Why was a new policy created? Why now?
- Who is most affected by the policy? Why do they need this information? How will people be impacted?
- When does the policy come into effect?
- How will the program performance be measured?
Having this information will help you in two respects:
- You are demonstrating an interest in the client’s goals
- You may find other potential and workable solutions to help the program reach their objectives
Take your preliminary research and reframe this into a 1 to 2-page project brief that clearly describes an outcome-based set of requirements. Again meet with the program lead in person. Email is rarely a good method to clarify multiple assumptions, plus you risk your email being lost among the hundreds to land in your client’s inbox. Validating the requirements and desired results with the client in person will get you more quickly to your next task: using the content in your project brief to create the deck in time for the management meeting.
Next in the series: building a collaborative solution.