Content Strategy for Project Managers
A growing team of Project Managers in a company, for whom change is constant, needed a way to recognize, document, and communicate project changes to a lot of different people. Their stakeholders were worldwide, so time zones were a consideration. They were also very different in what they needed. Sponsoring executives needed summary information, technical teams wanted diagrams and specs, and external vendors needed some information, but not all. The team thought they wanted good-looking documents to provide instructions. What they really needed was strategic content for their audiences. Turns out, the key to managing change was to prevent it.
- De-mystify the project management process for stakeholders
- Allow different content views – tech details for IT, summary dashboards for executives, external updates with limited information
- Reduce duplication of effort to create artifacts
- Identify, manage, document, and communicate change
The Methodology
The first step was to identify what information stakeholders needed and how they wanted to see it. The project teams had things under control, they just weren’t communicating progress back to their partners in a way that could be passed up the chain. In short, sponsors didn’t have visibility into project status.
We helped the team map out their processes, then helped them see things from their audience’s point of view. A detailed functional requirements document made sense to a technical stakeholder, but the business team wanted a dashboard of progress, risks, tasks, and timelines.
Once we knew the audiences and objectives, we were ready to build a plan.
Findings
What we found through interviews and reviews of current and previous projects was that there was a large gap between what the business stakeholders thought they had requested and what the Project Managers understood the request to be. Business teams didn’t know what they didn’t know, and they were often too vague in their requirements. And Project Managers didn’t always read between the lines. They heard the explicit requirements, but often missed the features that were implied.
Analogy: the business requirement was to have new pants. But unless they specified that there be a zipper, a button, and pockets, they were only going to get pants.
This created a culture of continual change, one that increased scope and caused delays if the gaps were recognized, and caused friction and disappointment if they weren’t, and the final product was less than expected.
The Solution
We helped the team implement standards and checkpoints, ones that formalized the process of defining projects, and enabled the business to make changes early, before development began.
The original request was to help them document and communicate change. But we helped them recognize something just as important – better understanding among all parties at the beginning limited the number of changes later.
Business stakeholders now had a procedure to add/change/delete requirements, one where the teams could prioritize them and either act on them or capture them for future versions.
This project, for us, began as an IT organization asking us to create forms and documents for them to use with stakeholders to show progress. They wanted technical writers to make their ideas beautiful (which we did).
But our client’s implied requirements were to help them manage their stakeholders, to mitigate and manage change, and to increase their credibility as a world-class project management organization.
It was part technical writing, part content strategy, and part good old-fashioned branding and public relations. The result was a simple, scalable set of artifacts to be used at different stages in the development cycle, accompanied by reporting tools and checkpoints to communicate progress (and success), along with a governance plan to make sure everyone was doing things the same way as everyone else.