An effective content strategy requires participation (preferably enthusiastic) from a diverse array of people. When you are communicating with executives, IT specialists, marketing writers, translation coordinators, and more, recognize that each participant (including you) begins with a certain set of expectations and biases.
For example, consider the proof of concept stage. What are the expectations for the proof of concept?
- Engineers: show that something is technically feasible.
- Marketing: show that we can produce something comparable to the highly designed content we produce now.
In one project, this mismatch of expectations caused huge problems. The question was something like, “Can we produce InDesign output from XML?” The answer, from the software side, was yes. But the proof-of-concept InDesign file was, let us say, aesthetically challenged. The marketing team looked at the very unattractive output and was ready to veto the entire workflow.
We have to have extreme clarity on the proof of concept. Are we showing the best-case scenario? “We created some initial output, and cleaned it up for the demo.” Are we showing the initial default output? “It’s ugly, but we can fix the formatting later; the technology works.” And most importantly, have we communicated those expectations or limitations to the people looking at the information?
Team members who are very visually oriented (most marketing and design staffers) need to see attractive demos. Team members who are very process-oriented (often IT and tech comm) need to see demos that promise efficiency. It’s also important to address not the elephant in the room, but the HiPPO—the Highest Paid Person’s Opinion.
Is it acceptable to spend six months on a proof of concept that simply moves your current PDF look and feel onto another production system? Do you need quick wins to keep momentum (and funding) going? How soon will legacy content move to the new system, or will it be updated in the old system?
If these assumptions and expectations are not aligned across the team, you are going to have some big project problems.