RE: Using writing plans in technical writing

Subject: RE: Using writing plans in technical writing
From: "Chris Anderson" <chris -at- bizmanualz -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 24 Aug 2004 10:11:23 -0500



In my humble experience developing operations manuals of policies,
procedures & forms, we have found that it always takes longer than you
think, involves more people than planned, and grows in complexity. To
control this trend, we have developed a writing plan that breaks the process
into five phases with clear objectives set for each phase.

1. Discovery
2. Planning
3. Development
4. Implementation
5. Re-Discovery

Discovery is the process of understanding the problem. It starts by clearly
identifying the mission, objectives and draft action plan. We like to
include clear business objectives with agreed upon effectiveness criteria
beyond compliance. Otherwise, the procedures look like overhead and an
administrative waist of time to everyone else, making it more difficult to
get their buy-in and participation. Once everyone agrees to the objectives
and action plan then we can start planning. This takes 2-4 weeks.

Some may think the 2-4 weeks is a long time here. But, the problem is
getting the buy-in and participation. We do not spend hundreds of hours
rewriting objectives. We do spend time thinking through the problem,
discussing the objectives, researching the effectiveness criteria &
compliance issues, and waiting for (managements) agreement on the projects
direction. Surprisingly, this takes longer than imagined. If everyone
knows all of the details to all of the issues then this goes quickly. The
reality is that everyone knows far less than they should at the beginning.
You just don't know what you don't know, hence the Discovery phase.

Planning starts with a gap analysis to determine the difference from reality
to the objectives. We then take the gap results, objectives and draft
action plan and produce the management materials needed to control the
project and set the budget/expectations including: project roles and
responsibilities, organization chart, MS project plan (activities,
resources, dates, milestones, etc.), reviews structure, status reports,
document control and format, process map, compliance requirements, training,
implementation, testing and audit plans. This takes 2-4 weeks.

We are now 1-2 months into the project and have not written a single
procedure. But, everyone understands the scope of the project, its
relationship to the company objectives, and what their roles are in
development. If we don't get this buy-in by now we are in trouble.

If we start writing procedures without Discovery and Planning then we can
expect delays, cost overruns, scope creep, a lot of rewrites once the
missing elements are discovered, and this eventually leads to the feeling
that nobody wants to work on this project anymore due to the lack of
organization and increasing frustration. But, if we spend the time to
organize it well with a writing plan, then the development and
implementation phases run a lot smoother.

Development starts by identifying a group of related processes and
completing just that group. We try to start with the leading processes in
the chain or system (i.e. customer satisfaction). We produce a process
SIPOC (Supplier-Inputs-Process-Outputs-Customer) diagram and flow chart,
follow the document control and format, use the review structure, perform a
walk through of the related processes, test it for compliance and
effectiveness, and then move on to the next group until finished. This
takes 2-4 months but depends on the number of processes, compliance
requirements, resource constraints, and the skill and knowledge of the
writers/reviewers.

Development also includes the creating of supporting documents such as job
descriptions, forms, training plan, or collection of technical manuals,
references, etc, for document control and later implementation.

As a rule of thumb we find that the Discovery, Planning and Development
phases take up 50% of the total project time but consume 80% of the project
cost. We include the time of all personnel working on the project and not
just the cost of the project leader (p&p specialist).

We are now 3-6 months into the project and have completed the procedure
writing and are ready for a complete document review. We do not recommend
implementing a smaller group of processes until all process are documented
and reviewed as a whole system. Otherwise, you are rewriting and
re-implementing processes and it takes longer to complete development. We
will have a chance to improve the processes later.

Implementation starts with an assessment of employee skills and competencies
to determine training gaps. Then training begins introducing the job
descriptions, processes, procedures, and the relationship of people/tasks to
objectives/effectiveness. This takes 3-6 months or about 50% of the project
time to complete. We are working toward a stable system of processes and
this takes time.

Implementation includes assessment, training, and auditing of the entire
system against the objectives and compliance requirements. The length
depends on number of employees, locations, and processes.

We are now 6-12 months into the project and almost finished. The last step
is to analyze what's been done, review the lessons learned and look for ways
to improve performance, compliance, or effectiveness. The result is a new
set of objectives and action plan for the next period and we begin again.
This phase overlaps with or replaces the Discovery phase of the next year,
which is why we call it Re-Discovery. It is a never ending process.

How do you agree on your objectives, core processes, and effectiveness
criteria? That's another story...



Chris Anderson, Managing Director
www.Bizmanualz.com
130 S. Bemiston Ave. Ste.101, St. Louis, MO 63105
Phone 314-863-5079, Sales 1-800-466-9953,

Empowering organizations to continuously improve compliance, control and
customer success with effective management systems.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.



References:
Re: Using writing plans in technical writing: From: Tony Markos

Previous by Author: RE: Software Companies
Next by Author: RE: business strategy plans?
Previous by Thread: Re: Using writing plans in technical writing
Next by Thread: Re: Using writing plans in technical writing


What this post helpful? Share it with friends and colleagues:


Sponsored Ads