Plan vs. Planning

[Duh! after almost two years on Blogger I figured out that there is a "title" block that is not turned on by default. I looked for it when I started transferring my rss reads from NewsGator to Google Reader. All of my blogs said "No title" and everybody else's had titles. It's the cyber equivalent to spinach in the teeth-it leaves you wondering why no one tells you :-0 ]

Documentation Plans: One out of Three Rs

We have a couple of overlapping projects going on at work these days. One is to establish ourselves at Level 3 on the Information Process Maturity Model. Another is to be more compliant with IBM's Information Development Standards. The upshot of this is that I am reflecting on the planning process a lot these days, since both of these efforts deal with planning.

My second career (after being an electronics technician--so long ago I know how vacuum tube circuits work) was in Manufacturing Management, so I have a natural fondness for project planning and tracking which I carried forth into a later career of documentation management. In my current career as Information Architect I find my need for project planning and tracking tools are still welded to my genetic structure. But I have noticed my tool of choice has changed over the years and that my reverence for "the plan" has diminished a bit. But not my respect for "planning," which is what this blog is about.

In short, a lot of mature departments and those striving to be mature place a lot of importance on a written documentation plan, often produced in MS Word and sometimes accompanied by a formal project plan done in MS Project. If I had a nickel for every such plan I've done--well, I'd have about $1.35, which rhetorically doesn't sound too impressive after having done the math, but you get the idea; I've done it a lot.

I think documentation plans have some serious flaws:

• We do them when we are the stupidest about what the project is about and whom it is for.
• Although we write them (one R), I'm not sure anyone reads them (second R).
• Lastly, they lack detail and the underlying engine to do the estimation math (the third R 'rithmatic).

I think project plans done in a project planning tool also have some serious limitations:

• They treat the project as if it is progressive (it keeps moving forward in discrete chunks) and linear (it moves in a straight line). In reality a project is expansive (we learn more about the product, the users, and our production tool sets the further into it we get into the project) and recursive (this expanded knowledge we get by the time we're on chapter three makes us need to rewrite chapter one).
• The critical piece of information we are all after, task duration, is an input and not the result of anything the tool helps us with.
• Whereas just about everybody has Word, Project is not as ubiquitous and distributing the project plan is not as easy as distributing a Word document.

My Tool of Choice

I find I'm getting much better results by using Excel as my planning and tracking tool.

• I spend more time thinking and noodling and less time on writing a document. The subtle difference is that I have shifted my emphasis from "making a plan" (where the plan is an artifact to be distributed and checked off) to "planning."
• Excel is great for making and manipulating lists. Once I have identified topics, assigned writers, categorized topics, set dates, whatever, I can filter and sort by any of those classifications.
• Once the list of topics is created in Excel, I can use its calculation capabilities to help me estimate the project.
• Everybody has Excel and the plan, schedule, and tracking file for a project (a single workbook with multiple worksheets) can be placed on a shared drive and be viewed and updated by anyone on the project.

The problem is that Excel is not usually considered a technical communicator's tool and so we do not get exposed to it in school or at the conferences. I'd like to see that change, since it is uniquely capable (by "it" I really mean a spreadsheet tool) of letting a project plan mature from broad, static statements to detailed inventories of information topics to be developed and then let you calculate estimates for those topics and create realistic schedules that can be monitored at a weekly granularity.

For the next few blogs, I will discuss in more detail how a spreadsheet can be used to plan and monitor information development projects. Even if you do not throw away your conventional documents about documents approach to planning, maybe you will find it worthwhile to stick a couple of more Rs into the process.