Feature Article: "Managing Thyself"

By Justin Baker

Are you repeatedly contracted as a policy & procedure writer only to be stranded in a cubicle out in left field with little-to-no direction, yet are expected to identify documentation requirements, documentation milestones and deadlines? Or even worse, the documentation projects themselves? Ineffective managers abound in all types of organizations are inept at being able to manage contractors in general and policy & procedure writers specifically. "Manage thyself!" I shout from the corporate rooftops. "Manage thyself!"

From my experience and perspective, many IT managers often focus too heavily on solving everyday technical problems to compensate for their lack of management knowledge and skills. They are always putting out "fires" and delving into technical minutiae. This may be the result from having progressed through the IT ranks without proper, formal technology-management or project-management education. By default, they fall back on their old roles of everyday engineering problem solvers to the detriment of their fulltime employees and, especially, their policy & procedure contractors who many times seem to be an afterthought.

Learn Project Management Basics

As a solution to this problem, policy & procedure writers (and all technical-communication contractors) need to understand the basics of project management and need to be able to manage themselves when faced with less-thanstellar management situations. And in keeping with the nature of our general technical-documentation profession, we need to document all significant documentation progress.

To not manage thyself is to potentially be at the mercy of those few unscrupulous IT managers who don’t manage their projects and then blame the lack of focus and/or significant progress on the contractors.

Many projects, including documentation projects, can be structured in four stages:

Project initiation

Project planning

Project execution, and

Project closure

As policy & procedure writers, we are all familiar with the project execution phase to varying degrees, for we all produce something. But understanding the project execution phase in more detail and understanding the other phases will help us to better execute our documentation projects as a whole and protect ourselves in particularly dire situations.

Initiate and Plan the Project

In the project initiation stage, identify your documentation project and the scope of your documentation project (your boundaries of focus). In the project planning stage, develop a variety of plans such as a project plan, a resource plan, a risk plan, a communications plan, and an acceptance plan. Also define planning deliverables and core deliverables such as your project plan and your actual policy and procedure documents; define each deliverable’s acceptance criteria as well.

The project plan details the documentation project’s phases, activities, and tasks. These are the project’s work activities defined in increasingly granularity. The project plan also identifies the resources that perform the work activities. Additionally, the project plan defines a schedule. Apply a specific project schedule to these work activities and resources; this is where Microsoft Project® usually comes in. Microsoft Project can successfully manage the triumvirate of activity, resources, and time for most basic project plans.

The resource plan identifies the resources in detail, the risk plan identifies any potential risk (although from my experience developing documentation is usually a low-risk activity), the communications plan specifically identifies who needs to be involved in communication during the project, and the acceptance plan details the persons and process for securing the acceptance of both planning deliverables and core deliverables.

Execute the Project

In the project execution stage, create your core deliverable(s), which for a policy & procedure writer are policy and procedure documents. This stage involves designing and developing the deliverable, and monitoring and controlling the development of the deliverable and supporting development activities (if development is a group effort). The project execution stage also involves change management, risk management, issue management, communications management, and acceptance management.

Close the Project

In the project closure stage, deliver your documentation deliverable and review your project experience for valuable lessons learned so that wisdom can be derived from your experience and be applied to future documentation projects.

This article presents just an outline of project management. Mastery of the project management’s specific components through education and experience still lie ahead of both you and me.

There are many texts that can educate us on the finer points of project management, most notably Managing Your Documentation Projects by JoAnn T. Hackos (Wiley, 1994). (Although I have yet to read Managing Your Documentation Projects, it appears to be one of the most respected books on the subject).

It would behoove us all to learn the finer points of project management, for it may help us to avoid the negative repercussions of negligent management in the workplace, help us to increase our individual output, and bring further esteem to our technical-documentation profession. Manage thyself, for it may help you avoid the slings and arrows of misfortune (not to mention bad management).

Justin Baker is approaching his tenth year as a technical-documentation professional. You can reach him at bakerjustin@earthlink.net.