"Why" Not "What" Documentation

With my presentation at the Digital PM Summit coming up on October 7th, here is post number nine in my series on organizational growth. This post makes the case that if you want documentation that has a shelf life of more than 6-12 months while growing, you need to focus on the "why" and not the "what" when creating documentation. This post is highly coupled with the previous post on enduring process frameworks, but this one focuses on documentation that persists as a supporting piece of any process that needs to be widely communicated.

Other Posts in This Series:

  1. A Formula for Healthy Project Size Compared to Organization Size
  2. Scaling Projects and Scaling the Organization
  3. Unit Change During Project & Organizational Growth
  4. Family-Sized Business Units & the Agency Holding Company Model
  5. Beware the Matrix Model?
  6. Communication Styles and Team Dynamics
  7. Agile Versus Waterfall, Once and For All
  8. Process Frameworks That Weather Growth
  9. "Why" Not "What" Documentation
  10. Project Manage the Organization
  11. Plan or Pain?

What What Documentation?

"What" documentation is exactly as it sounds; It describes the "what" of a process. "What" documentation is easy to spot. Just look for lots of lists of steps, timing of actions, descriptions of tools, libraries of information, and other nitty gritty details that, while important, are also very much in the weeds of a process. "What" documentation certainly has a place, but that place is not during times of rapid change or growth in an organization. It works great for communicating complex processes at scale and boiling them down into an exact science repeatable by humans who prefer repetition and defined steps in their jobs, but it doesn't scale (up or down). Steps change frequently to adapt to organizational changes, and maintaining "what" documentation becomes an unsustainable goal during times of growth.

"What" documentation also suffers from another problem beyond the inability to scale: it doesn't capture its origins and purpose. Assuming you're not handing your documentation off to robots who interpret the steps and complete them, most human employees using documentation are going to do a much better job following the documentation when they understand the purpose behind what they're doing and its importance to the overall project. Emotional buy-in tends to do that! So make sure your "what" documentation explains WHY the documentation exists, the purpose it serves, and what decisions led to the need for documentation in the first place. Yep, I just described  "why" documentation.

So Why Then?

Correct. If you find yourself in the current predicament of having a lot of "what" documentation, start by going back and adding some "why" to that documentation. If you plan on growing, expect that the "why" parts of your documentation are the only parts that will survive, and often during growth the "why" statements serve as easy decision criteria for whether a particular process should be scrapped or just reworked and improved as needs change. While you're in growth mode, it's likely not worth your time to even attempt to get to the "what" level of documentation, but it becomes even more paramount to properly communicate your intentions and process strategy for your team now and in the future. That goes for even the highest levels "why" including company values, mission/vision statement, and steering principles. In fact, if your organization doesn't have those and is trying to grow, back up a step and make sure that happens!

Short answer: during growth, write "why" as often as possible and avoid the "what" in your documentation. Need a starting point for writing great "why" documentation for your projects and processes? Try this outline:

  • First, start by defining why the need for the process exists and what problems the process seeks to solve for the organization
  • Next, if applicable, relate any importance the process has to high-level strategic initiatives, company values, etc.
  • Then, rather than focusing too in-depth on the specific steps in a process, identify something along the lines of acceptance criteria for the human process which identify with clear yes/no or pass/fail metrics what the process should achieve.
  • Finally, identify any likely pitfalls or areas to avoid in this process that were perhaps tried in the past with little success.

With that outline, you're on the right track to documentation that not only has the ability to survive growth, but helps your team make the correct decisions about what processes exist and for what purposes as the organization's needs change.

Catch me at the Digital PM Summit

Interested in the topic of organizational growth from a PM perspective? Join me and a bunch of fellow PMs at the 2014 Digital PM Summit in Austin coming up in just a few weeks! I'll be presenting a talk similar in nature to my Drupalcon presentation and related to this blog series, but new and improved after additional months of experience and iteration. The Bureau of Digital Affairs did a great job with the inaugural 2013 event, and 2014 promises even more in store. With a great lineup of speakers, topics, and of course after-parties, you'll definitely get your monies worth. I hope to see you there!

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Ready for transformation?