During the monitoring and managing phase of a development project, both the content strategist and the project manager work in the background to keep the team aligned and the activity focused. For both roles, this “frameworking” and leadership phase have the same two characteristics:
- Keeping the big picture in mind while contributing to forward progress
- Supporting the team with the resources required to work efficiently and effectively
Neither task is easy. The keys to success in this phase are communication, communication, communication, and – I can’t stress this enough – communication.
So sure, hold your stand-ups and your project team meetings. But also talk one-on-one with folks, Slack with remote workers, chat over coffee in the kitchen. And answer their questions consistently!
You’ll be amazed at the number of different interpretations of the same objective that exist across your development team. If you find that the variation is profound, post, Slack, or email out a quick (and temporary) FAQ. This helps in two ways: It reinforces a consistent message, and it enables folks to refocus on the task at hand so that they are not wasting energy trying to figure out if their understanding matches that of their neighbor.
Note: This blog is the fourth in a five-part series that examines how the elements of the content strategist role both parallel and intersect those of the project manager’s role.
For the content strategist, support of the content development team can also involve the following:
- Updates to the content plan and/or calendar
- Style sheets and job aids, such as content templates
- Proofs of concepts for new content designs
- Incremental reviews for team alignment
Update the Plan Collaboratively – Sort of
Before I delve into each of these, a quick note about content plans and content planning calendars. Whatever tools you use ensure that they contain adequate detail so that the content developers know how the content is to be structured and related and who is responsible for developing (or updating or archiving) what content. I favor wireframes, and hierarchical spreadsheets; I know others use page tables also known as priority guides, especially for web design.
Like all plans, content plans evolve. A content strategist supports the content development team by listening to what they are discovering during their research, engagement with subject-matter experts (SMEs), and drafting processes. Help them evaluate proposed new content against the work-planning questions I supplied in parts 2 and 3 of this series Add any new must-have content to the plan, and highlight or otherwise preserve ideas for future content (call it “phase 2” content if you want).
Note I suggest that you store content plans in a central online location – with the content strategist and her designee as the sole owners of update privileges – version or date the plans, and communicate to the team when you update them. Always, always be careful to explain why plans are being updated.
Most importantly, note that I am not encouraging or supporting scope creep for a documentation project. Far from it. I am encouraging a meaningful and ongoing collaboration with stakeholders, especially content developers, which will reinforce the boundaries of the project.
Support with Internal Guidelines and Job Aids
In addition to reasonably detailed plans, content developers need fully functional, helpful, and efficient tools. Evaluation of tools for structured authoring, content review, and content component management is a topic beyond the scope of this blog. (A place to start is STC’s brief article on the 5 types of authoring tools technical writers use.)
Content developers need to test-drive a new approach, especially if it requires them to develop a different kind of content than they have previously.
That said, in my role as content strategist at Oracle, I also wore an editor’s hat. I supported the team by providing developmental edits – applying standards that I had developed or maintained: style guides, style sheets, specialized templates, and terminology lists. (I eventually took over management of the team glossary.) I also initiated a team collaborative page (we used Confluence) for describing product feature deltas and their impact on existing content.
The benefit of having dual roles was that I was able to observe – and learn from – how the content development staff was implementing the content plan. I also actively engaged with our information architect to help interpret for the staff the specialized content templates that he and I designed together. I sometimes developed dummy content for the templates for demo and training purposes.
Prove Newer Approaches
Which brings me to the role of POC (proof of concept) in content strategy. Wireframes are great for the content design phase of a web-content project, especially when a new, very different approach is being trial-ballooned. You can put a set of wireframe options in front of various potential audiences and gather some quick feedback. I’ve done this several times.
But content developers need to test-drive a new approach, especially if it requires them to develop a different kind of content than they have previously. An example is troubleshooting content. The writing staff needs to understand what constitutes “good content” and find out where challenges might lie.
Asking a developer or two to run trial content through a new or evolved template, process, or output target can reveal potentialities – good and bad – that no one thought of during the design phase. As a result of this proof of concept, templates and other job aids – as well as processes, scripts, and output formats – can be improved before the new approach is rolled out to the entire development team.
Perform Interim Reviews
Don’t wait to run a lessons learned session. After you have rolled out a detailed strategy and run some POCs, check in with the development team on their use of the content plans, templates, process documentation, and job aids that the strategy/architect team has developed with them. Call these check-ins or interim reviews or what you will. They provide an opportunity to course-correct, if need be, before issues become entrenched.
As far as what to review, devise a set of checks and questions before you launch the review meeting. Gather input on pain points from the developers themselves, and add those to the agenda. If the team uses structured authoring, run a code review – or ask a staff expert to do so – across several examples of the same type(s) of content. Any inconsistencies should be discussed, and any necessary revision work should be scheduled.
Don’t forget to review content reuse. Identify maps, files, and processes developed specifically for reuse. How are they working out in practicality? Are repositories/files of common content set up efficiently? Are they accessible – and searchable – by all of the developers?
In a structured authoring environment, content destined for reuse often has to be developed in a dedicated file and tagged with element tags that can span various types of templates. So check for that, too. Most importantly, ensure that content reuse continues to be orderly, logical, and maintainable. Avoid spaghetti code!
Successfully launching the content at the project’s end is, of course, the goal of all of this effort. Don’t forget to celebrate the team’s success!
What comes next is continuous improvement, aided by a good set of metrics – the topic of the next and final blog post (Part 5) in this series.
DK Consulting of Colorado 
4 thoughts on “5 Intersects of Content Strategy and Project Management (Part 4)”