2. eDocumentation Process Plan Phase

eDocumentation™ Process
Plan Phase

Knowledge Process, Inc.
www.DocumentationProcess.com
www.KCGGroup.com

Table of Contents – Plan


Table of Contents – Plan ..................................................................................................................... 2

Project Scope and Objectives ............................................................................................................. 5
Scope .............................................................................................................................................................. 5
Objectives ........................................................................................................................................................ 6
Scope changes ................................................................................................................................................ 6
eDocumentation™ Process phase .................................................................................................................... 7

eDocumentation™ Process Flow ....................................................................................................... 8
eDocumentation™ Process phases .................................................................................................................. 8
eDocumentation™ Process phase .................................................................................................................. 10

Policy, Process, and Procedure – What Is the Difference? ............................................................ 11
Policy qualities ............................................................................................................................................... 11
Process qualities ............................................................................................................................................ 11
Procedure qualities......................................................................................................................................... 11
Driving from Hollywood to Los Angeles – A Policy, Process, and Procedure ................................................... 12

Policy .................................................................................................................................................. 14

Process............................................................................................................................................... 16

Procedure ........................................................................................................................................... 19

Content Audit and Evaluation ........................................................................................................... 21
Sources.......................................................................................................................................................... 21
Level of detail ................................................................................................................................................. 22
Complexity of material .................................................................................................................................... 22
Critical nature of materials .............................................................................................................................. 22

Version 1.0 eDocumentation™ Plan Phase Page 2 of 56


Preliminary table of contents .......................................................................................................................... 22

Audience Evaluation.......................................................................................................................... 25
Audience identification evaluation ................................................................................................................... 26
Individual Audience Needs Assessment ......................................................................................................... 26
Management audience ................................................................................................................................... 28

Content Review Team........................................................................................................................ 30
Composition of the Content Review team ....................................................................................................... 30
Member responsibilities .................................................................................................................................. 31
Team responsibilities ...................................................................................................................................... 31

Support Team..................................................................................................................................... 33
Subject matter experts.................................................................................................................................... 33
Systems support ............................................................................................................................................ 33
Vendor contacts ............................................................................................................................................. 33
Technical contacts.......................................................................................................................................... 33
Expeditor........................................................................................................................................................ 34

Content Classification ....................................................................................................................... 35
Classification type .......................................................................................................................................... 35
Content organization ...................................................................................................................................... 36
Overlapping content types .............................................................................................................................. 38

Accessible Policies, Processes, and Procedures ........................................................................... 39
Factors........................................................................................................................................................... 39
Be prepared ................................................................................................................................................... 40

Usability Factors ................................................................................................................................ 42
Factors........................................................................................................................................................... 42



User verification ............................................................................................................................................. 44

Consistent Terms – a Common Language ....................................................................................... 45
1. Dictionary .................................................................................................................................................. 45
2. Inconsistent terms ..................................................................................................................................... 45
3. Source ...................................................................................................................................................... 46
4. Search ...................................................................................................................................................... 48
5. Developing consistent terms ...................................................................................................................... 50

Soft Skills ........................................................................................................................................... 53
What are team soft skills?............................................................................................................................... 53

Knowledge Process, Inc. ................................................................................................................... 56
About Knowledge Process.............................................................................................................................. 56
Copyright ....................................................................................................................................................... 56


Project Scope and Objectives

There is the saying ‘Schedule, budget, or quality – choose two’, implying that you may not be able to achieve the
level of quality required for a project and also meet the schedule and the budget. However, quality is not to be
compromised. It is a changing scope that causes increased budget and schedule. Therefore, fully understanding
a project’s scope and objectives, in every aspect, will alert you to potential ‘scope creep’ that can adversely affect
your project.

This chapter addresses the project scope and how it will affect the development of the Policies, Processes, and
Procedures. Please note that this chapter does not address project management. Project management is a
separate discipline requiring trained expertise.

Scope
The scope should clearly establish a beginning and an end, including the project deliverables. Performing the
planning tasks in the eDocumentation™ Process will assist in defining the scope to research and the
development and implementation of the required Policies, Processes, and Procedures for a project. The
documented project scope should include the following:

Fully define the deliverable; not as a general statement such as ‘Develop the Policies, Processes, and
Procedures for the XYZ implementation’. There should be a clear statement of the Policies, Processes,
and Procedures to be researched, developed, updated, tested, and implemented.

For example, ‘Research and develop Process and Procedures for the Billing Process. Process and
Procedures will be accessible using the enterprise portal. The Processes and Procedures will be
developed using Word ™ and converted to HTML’.

Define what will not be included.

For example, ‘Policy development and training materials for the Billing Process will not be part of the
project. Indexing and online help will be developed after implementation’.

Define the tasks that require support, such as research, testing, and training.

For example, ‘Support resources will be required to research and test the Billing Process and
Procedures’.

Many times Policies, Processes, and Procedures projects are part of a larger project. Therefore, the
documentation project success is often dependent on the planning of the larger project. Care must be taken to
incorporate the Policies, Processes, and Procedures as a Subproject within the master project plan and to ensure
the two scopes are aligned. Therefore, the documentation project becomes dependent upon the master project.
To understand how a documentation project fits within a master project requires further questions.

Is this a major development project?

Is this a new system or upgrades?

How many sites are affected?

How many users are affected?

Are there available users who know the system or processes?

What is the level of detail required for documentation?



Will there be new Policies, Processes, and Procedures or revisions to existing documentation?

Is their new Policy (for example, SOX) being implemented that will require new Processes and
Procedures?

Will the documentation be the source materials for training?

Are the Policies, Processes, and Procedures a part of the overall project plan or simply a one-line task?

How many Documentation developers will be available for the project?

Are the Documentation developers dedicated to this project, or will subject matter experts set up the
Policies, Processes, and Procedures, inclusive with their other project tasks?

Have the Documentation developers been consulted for their input to the project plan?

Objectives
The objectives of a documentation project define what the success will be. This ensures that there are no
surprises and disappointments.

Clear, concise, complete, and correct™ documentation is always the objective. In addition, other objectives may
include the following:

Establish categories and keywords to support the enterprise taxonomy project.

Establish documented controls to support SOX compliance.

Establish a Policies, Processes, and Procedures portal for global access.

Establish an Issue Reporting system on global portal to support change management.

Scope changes
The major reason a project goes ‘out of control’ is an increase in project scope. Increase of scope can be caused
by many conditions - among them the following:

No project champion to control scope and support team.

Project becomes more complex than original project plan.

Request for additional deliverables that were not part of the original project plan.

Increased tasks to develop Policies, Processes, and Procedures that were not part of the original project
plan.

Unclear deliverables.

Unclear objectives.

Lack of meaningful controls, such as milestones and communication.

Key team members are moved off the project or are not available.

Interest and direction declines.



System more extensive or complex than anticipated, causing changes.

Activities that alleviate an increased scope include these:

Perform the eDocumentation™ planning and research tasks so that you have a grasp of the project
scope and objectives.

Maintain a project plan to record, and notify the dependent tasks that affect the documentation project.

Structure the documents so that they can be easily updated as changes are required.

Have proper tools readily available to efficiently prepare the documentation.

Keep consistency between all documents.

eDocumentation™ Process phase
Plan


eDocumentation™ Process Flow

The eDocumentation™ Process is a set of guidelines, not decrees, that guide the Documentation developer
through the research, development, and implementation of Policies, Processes, and Procedures. The objective is
to create and produce Policies, Processes, and Procedures that are clear, concise, complete, and correct™.
Although the Process is a somewhat sequential Process, each phase touches the other phases and relies on the
diligence and quality of the previous phases. Previous phases may be revisited, and if conditions warrant,
modifications may be made to previous assumptions and decisions.

Phase 2:
Phase 1: Build
Plan
Phase 3:
Implement

Phase 4:
Change

eDocumentation™ Process phases
There are four major phases that comprise the eDocumentation™ Process. The phases encompass the tasks
that need to be reviewed and performed as the project progresses, depending upon the company, project, and
scope.

Plan
The Plan phase incorporates the tasks that are required to ensure that the project is properly scoped with
the correct focus, level of detail, team members, and proper content. Planning does not make a project
longer or more complicated, but ensures that erroneous assumptions do not become part of the project
approach and plan. Policies, Processes, and Procedures are usually dependent upon other resources;
therefore, it is important that all the puzzle pieces fit.

Build
The Build phase researches and develops the Policies, Processes, and Procedures. Based on the
decisions from the Plan phase, the Policies, Processes, and Procedures are researched, written, verified,
and tested. This phase is often looked upon as ‘just writing’. However, there are other critical tasks that
are performed in addition to writing.

Implement
The Implement phase rolls out the Policies, Processes, and Procedures to all the users. A Policies,
Processes, and Procedures project is never complete until the users are trained. This is often an
overlooked task, but it is – without a doubt – key to the success of the overall project. The Implement
phase incorporates appropriate change management principles.



Change
The Change phase addresses the process that tracks and updates Policies, Processes, and Procedures.
Change is the nature of Policies, Processes, and Procedures. Updates are often overlooked, and at that
point the Policies, Processes, and Procedures become outdated and less reliable. Therefore, guidelines
and Processes are introduced to assist with keeping Policies, Processes, and Procedures current.

Plan Build Implement Change

Define Project Evaluate Policies,
Perform Content Compile
Scope and Processes, and
Research Documentation
Objectives Procedures

Develop Policy,
Perform Content Create Review Categories
Process,
Audit Tables of Contents and Usability
Procedure

Review Policy, Publish Policies, Project Review and
Define Audiences Process, Processes, and Published
Procedure Procedures Recommendations

Test and Verify Receive Requests
Define Determine
Policy, Process, for Additions and
Project Teams Training Approach
Procedure Changes

Test
Define Content Training Review and Review Planning
Categories and
Classifications Approval Tasks
Usability

Revise
Perform Subject Prepare Training Change Request Review
Policy, Process,
Matter Breakdown Materials and Approval
Procedure

Edit Train
Define Standards Policy, Process, Policies,
Procedure Processes,
Procedures

Define
Approve Policy, Process, Archive Training
Standardized
Procedure Materials
Terms

Mark as Final
Implementation and Training
Define Preliminary Policies,
Review and Published
Table of Contents Processes,
Recommendations
Procedures

Project Planning Phase Development Review and
Review and Approval Approval



Plan

Build

Implementation

Change


Policy, Process, and Procedure – What Is the Difference?

Many years the terms ‘Policies’, ‘Processes’, and ‘Procedures’ have been interchanged. ‘Policies’, ‘Processes’,
and ‘Procedures’ should be considered distinct types of documentation.

The researching and developing documentation requires understanding the distinctions between a Policy, a
Procedure, or a Process. All address related subject matter, but at a different level and with different types of
content. Each type has a unique purpose that drives the content contained in each type of document. Describing
the distinctions using who, what, where, when, why and how often helps to understand and properly structure
them.

Policy qualities
Policies are the business rules and guidelines of a company that ensure consistency and compliance with
the company’s strategic direction. The Policies lay out the business rules under which a company,
division, or department will operate.

Policies are the guidelines under which Procedures are developed. There is not a one-to-one relationship
between a Policy and a Procedure. Policies are not part of the Procedure, because they cannot be
properly structured. However, the Procedure must reflect the business rules contained in the Policies.

Policies address what the Policy is and its classification, who is responsible for the execution and
enforcement of the Policy, and why the Policy is required.

Process qualities
Processes are related activities that produce a specific service or product (example, Procurement to
Payment). The majority of Processes cross departments or functional areas. Each Process designates
the connect points and where it crosses department lines. The documentation presents the total Process.
It is helpful to be able to reference or drill down to the applicable Policy or Procedure for a Process step.
A Process map is a useful tool to graphically display the Process.

Processes indicate where there is a separation of responsibilities and control points. They are also very
helpful to identify Policy and Procedure requirements. Processes address who is responsible to perform
the Process (department, division), what major functions are performed, and when the function is
triggered.

Procedure qualities
Procedures define the specific instructions necessary to perform a task or part of a Process. Procedures
can take the form of a work instruction, a desk top Procedure, a quick reference guide, or a more detailed
Procedure.

Procedures usually are structured by subject (for example, system instructions, report instructions, or
Process tasks). A Procedure usually addresses only a single task. This separation enables Procedure
components to be compiled into special Procedure manuals for specific audiences, end users, and
purposes.

Procedures detail who performs the Procedure, what steps are performed, when the steps are
performed, and how the Procedure is performed.



Driving from Hollywood to Los Angeles – A Policy, Process, and Procedure
Using common maps to illustrate the differences between a Policy, Process, and Procedure, the following
example illustrates that different content is contained within each type of document. While all the information
relates to the subject of driving from Hollywood to Los Angles, different content type is used for different
documents.

Policy

Policies are the
guidelines or laws that
drive the Processes and
Procedures.

Processes

Processes are a high
level view. The tasks
within the overall
process are
identified.

Procedure

Procedures are the
detailed steps
required to perform
an activity within a
process.



Plan


Policy

Policy
Policy aligns and supports the enterprise’s strategic plans, goals, and objectives. It is the foundation for the
content of Processes and Procedures, as they should not contradict a Policy. Policy should remain fairly stable
and not be subject to as frequent changes as a Process or Procedure. Policy should always have a review date
associated with it, to ensure that it is compliant.

Policy is the foundation for an enterprise, country, location, functional area, or department. Policy forms a
hierarchy with each level, aligning with the policies above it. Policy may need to be adapted, based upon specific
requirements or regulations for a country or location. However, these adaptations must align with the policies
above it in the hierarchy. For certain subjects, you may need an umbrella Policy that states the basic and
unchanging content, such as Legal and Financial Reporting. While there may be different country Policies, the
enterprise would have a Policy that is senior to all other Policies.

Policy addresses the laws, guidelines, strategic goals, objectives, best practice, culture, and values of an
enterprise.

There are many purposes for Policy: obtain a high level of quality; understand the legal requirements; obtain
accuracy of processing; obtain consistent and reliable metrics; implement consistent and required controls; and
reduce risks and penalties. Only through Policy can the purposes and requirements be communicated and
implemented.

There are two types of Policies - passive and active:

Passive Policies are stand-alone Policies: For example, a sexual harassment Policy. The Policy provides
the implementation guidelines and requirements – because it is a legal requirement; therefore a Process
or Procedure may not be required for implementation.

Active Policies require supporting Processes and Procedures in order to implement the Policy: For
example, control points within a Process. In order for the Policy to be implemented, the users must know
the exact steps required by management.

Many Policies are cross functional, which requires collaboration during development and reviews. Therefore,
when developing Policy, know who is affected by the Policy.

Because Policy is the foundation for a company, it is essential that management know that the correct version of
a Policy is being used by all who are affected. They will know that the correct version is being used, if they know
who requires the policy; what the effective date is; when the next review is required; where the document is
located; and proper reviews and approvals have been obtained. The first step to achieve the objectives is to set
up the Policy as a separate document. The following should be avoided:

Many Processes and Procedures have a section called ‘Policy’. Processes and Procedures may
reference or provide a link to the applicable Policy, but the Policy should never be incorporated in the
Process or Procedure.

There is usually a one to many relationship between Policy and Procedures. Therefore, one Policy, or
several Policies, may be referenced in many Processes and Procedures. If the Policy is stated or
detailed, not just linked, maintenance of the Policy then becomes impossible. Rather than updating just
one Policy document, multiple Process and Procedure documents must be reviewed and updated.

The Policy is not able to undergo scheduled reviews. Because the Policy can be fragmented between
Processes and Procedures, it is not possible to ensure that all references to the Policy are updated.


Policy

Management is not able to review Policy as a stand-alone document. The Policy becomes fragmented,
and this makes management reviews more difficult. Therefore, a standard review date is difficult to
achieve.

Policy subject matter experts are management and those who have knowledge of the law and legal requirements.
It is necessary to provide management with the tools so that the Policy can be properly stored, accessed, and
reviewed.

Plan


Process

Process
A Process identifies all tasks within a Process and its boundaries, beginning to end. A Process may reference
other Processes, when they are cross functional (for example, Quality and Procure to Pay). Within a Process you
will drill down to a Sub-process or a Procedure. A Process does not present the steps to perform a Procedure.
The Process is a high level view of an overall activity.

Processes, as referenced here, refer to the user Processes; not necessarily Business Process Management
initiatives that are used for enterprise business design. BPM is used to standardize Processes, to attain a
consistent outcome, and to add value for the enterprise. The results of BPM have multiple purposes and are
used for different initiatives. Therefore, for our purposes we do not want to confuse BPM Initiatives with Process
documentation. When it is applicable, Business Process Management maps are used as input for user Process
maps and Procedures.

Enterprise Business Process Initiatives User Processes and Procedures

Procedure
Audits

Business
Process Six Sigma
design

Business
Process Input to Process Procedure
reengineering Process Documentation documentation
To Be
modeling
maps
and maps

SOX work
TQM Procedre
flows

Processes are often referred to as a Process map, because as a map or flowchart it is the easiest way to illustrate
tasks within a Process. A Process will usually be cross functional, as it pertains to multiple functional areas. A
user Process will have multiple purposes - training, research, documentation. Processes can easily become a
maze, if not clearly defined. Process maps that are used for ‘to be’ Processes and are not updated for user
documentation become lost assets and tools for users. Therefore, clear guidelines and standards must be set for
Processes.

Determine the purposes, to prevent a map from having limited usage. Keep in mind that the Processes
are untimely for users.

Determine the hierarchy of the Processes. If a Process is referenced in another Process, single sourcing
should then be used.

Develop a stable reference system for the Processes, in order to link to other Processes.


Process

The following is an example of a Process that results in a Sub-process. Process maps can also have high level
text associated with it. Care should be given with the duplication of information.

Procure to Pay Process
Procurement

2.0
1.0
Purchase
Requisition
material
Receiving

3.0
Receive
material
Accounts
Payable

5.0
4.0 End
Issue
Invoice Process
payment

3.0 Receive material
Who: Receiving manager
What: Reconcile
When: Daily
Where: Receiving system
How: Report 99

Control: Quantity of goods
received to Dollar value of PO


Process

Must a Process always use a map? No, but determine what is easier for the user to read.

Content can be added describing Process overview and basic information.

Process maps are excellent training tools.

Process maps are excellent overviews for complex business Processes and system Processes.

Process maps are excellent guides to applicable Procedures.

The following example is a Process map with the same information in a text format. The Process map is a more
effective tool for users.

3.0 Receive Material
Receiving

3.1 3.2
Receive Create
material receiver

3.3 3.4
Quality

End
Inspect Accept Yes
process
material material

No
Procurment

3.5
Disposition
instructions

Plan


Procedure

Procedure
A Procedure is the detailed steps required to perform a task. The Procedure defines exactly how to perform the
task to obtain the desired result. Procedures can be in the form of keying instructions, approval instructions, or
balancing instructions.

A Procedure guides the user through the steps to perform a specific task. Fundamentals of a Procedure are the
following:

Correct sequence of steps so that the task can be properly performed.

Correct and clear instructions so as not to add confusion.

Easily referenced instructions for critical tasks such as error conditions, controls, cutoff dates.

Proper breakdown of Procedures so that each Procedure is not too cumbersome to reference and use.
There usually are multiple Procedures for a specific Process task.

Complex Procedures, such as financial systems or monthly balancing, may require a Process map or
checklist to help guide the user through a complex Procedure.

Procedure content should adhere to Policy and may reference a Policy title or number using a link. However, the
Policy should not be part of the Procedure. The Procedure should contain only information that pertains to
performing a specific task.

Procedures go hand-in-hand with Processes.

Process is a high level roadmap.

Procedure is the detailed instructions.
3.0 Receive Material
Receiving

3.1 3.2
Receive Create
material receiver

3.3 3.4
Quality

End
Inspect Accept Yes
process
material material

No
Procurment

3.5
Disposition
instructions


Procedure

Plan

Build


Content Audit and Evaluation

The objective of a Content Audit and Evaluation is to determine the quality and quantity of existing content that
relates to the project, and provide a ‘best guess’ as to the scope of Policies, Processes, and Procedures that will
need to researched and developed. During the task you will determine what documentation exists, who uses it,
and the age of the content.

Sources
Existing project related content is a source of knowledge that can be used to ‘get your arms around’ the potential
documentation.

Provide Documentation developer with information to better understand the project.

Provide users with information from which they may assemble issues and questions.

Provide a starting point as to the scope of the Policies, Processes, and Procedures to be researched and
developed.

Legacy documentation
In order to gain a basic understanding of the content, skim sources for major headings, charts, and other
content from the following existing sources:

Policies, Processes, and Procedures

Vendor manuals

System functionality documentation

Individual cheatsheets and notes

Organization charts

Job descriptions (if available)

New documentation
New documentation may have been prepared during a feasibility study or extensive business process
reengineering. This documentation contains the high level impact to Policies, Processes, and Procedures.

Process maps
Process maps may have been developed by other participants that map the new Processes. If so, these
will identify the content that needs to be development and documented.

List the business Processes that will be affected.

List the business Processes that may be affected.

Policies
Determine if new Policies have been identified for development, due to the reengineering of business
Processes.



Systems
If the system functions that will be utilized are known, list those business functions and the
associated system functions.

If the system is new and not well known to people within the enterprise, list the business functions
that will be affected with the new system.

Level of detail
Based upon the Audience Evaluation, who will use the functions has previously been identified. Determine the
level of detail that will be required by the various audiences.

To ensure consistency of operation, the documentation detail must be ‘just right’ so that users will reference and
use the documentation. Therefore, this task is completed during the content research task, when you are working
with the users. You must understand their job, their needs, and their problem resolution requirements. That
understanding will assist you in preparing the documentation with the proper amount of detail.

Complexity of material
Determine the complexity of the materials. Consider the following factors:

Is the material intuitive? Are the actions clearly defined without supporting information?

Does the material have multiple paths? Are these paths self documenting?

Is the input dependent upon the input of other information?

How many steps are required to research the desired result? Do the steps require multiple users?

If the documentation is only a new version, the complexity may be low, even though the documentation,
as a whole, is complex.

Each audience may require only a part of the documentation. Therefore, each audience requires a
complexity evaluation.

Critical nature of materials
Some documentation is more important or more critical than other documentation. For example, a document
updating SOX controls may be more critical than a document updating a system’s function keys. Different
audiences may require a more complex part of the documentation to understand it. Understanding this
relationship gives a priority for the development and implementation of the Policies, Processes, and Procedures.

Preliminary table of contents
The output of the content audit is the preliminary table of contents. This is not the table of contents that will be
generated by the Policies, Processes, and Procedures from the heading styles or tags. The content audit table of
contents is manually developed and serves as an estimate of the Policies, Processes, and Procedures to be
developed.

It is helpful to set up the preliminary table of contents using Excel ™, in order that the various columns can be
sorted, giving different views.

To develop the preliminary table of contents, perform the following steps:

1. Determine major Process being audited.



2. List the departments or the functional area that is part of the major Process.

3. List the sub processes for each functional area.

4. List the existing Procedures that support the sub process.

5. List the source of the Procedures.

6. List the owner of the major Processes.

The following spreadsheet is an example of the existing Procure to Pay Policies, Processes, and Procedures.
The existing materials would be reviewed to determine their use for new documentation. In addition, the
spreadsheet would be distributed for others for collaboration.

Procure to Pay Process
Department Sub Process Procedure Source Owner Policy Source Owner
Originating Prepare Prepare
Department Purchase Req request Originator Mgr,Dept
Approve
request
Generate
Purchase
Request
Review
Purchase Mgr,
Purchase Order Prepare PO Request Notes Buyer Notes Purchasing
Determine
vendor
Review terms
Generate PO
Approve PO
Receive
Receiving Materials Notes Mgr, Receiving Notes Mgr, Receiving
Prepare
Receiver
Inspect
Quality Materials Procedures Mgr, QA Procedures Mgr, QA
Accept / Reject
Materials
Move to System
Inventory Inventory generated Mgr, MM Mgr, MM
Accounts Receive Vendor
Payable Receive Invoice information AP Procedures Controller AP Procedures Controller
Add vendor
information Dated 01/01/01 Dated 01/01/01
Approve
Post Invoice invoice
Record invoice
Generate
Pay Invoice payment



Plan


Audience Evaluation

Audience Evaluation
Evaluating the audience who will use the Policies, Processes, and Procedures is one of the most important
eDocumentation™ planning tasks performed. The Audience Evaluation affects many of the tasks that comprise
the documentation process. The audience is the user and the reason for developing the Policies, Processes, and
Procedures. There can be multiple audiences for the documentation, each having a unique set of requirements
for the documents. Therefore, each audience must be evaluated independently. Upon completion of each
Audience Evaluation, you will be able to tailor the Policies, Processes, and Procedures to their needs and
requirements.

Management
Audiences
Primary Audiences

Secondary Audiences

Policies and
Procedures

Policies and Policies and
Procedures Procedures
Applications Process Flows

Forms Process Flows

Applications

Policies and Applications
Procedures


Audience Evaluation

Audience identification evaluation
The project team will identify user groups that require Policies, Processes, and Procedures. The groups will be
classified into distinct audiences, based on the following factors. The initial evaluation identifies the audiences
and provides general information about how they use Policies, Processes, and Procedures.

Where are the locations of the audiences?
Determine the location of each audience. Are audiences global - in different cities and countries?

What are the languages used by the audiences?
Determine if a language translation is required for each location. If materials require translation, the writing
style must be evaluated to ensure that it will accommodate the language translation.

What is the number and the size of each audience?
The number and size of the audiences determines the general approach for the development and the
implementation of the documentation. For example, there may be 10 locations, each with 1 person; or there
may be 2 locations, each with 200 persons.

If the audience is small, but the material is complex, it is important that the materials have a high level of
detail. Because the audience is small, there might be a critical and immediate need to train the users, due to
potential turnover and lack of backfilling.

A large audience requires electronic media and a formal training program, if the project is new or is a
significant update. After implementation, a large audience will have a support system, as there should always
be available members familiar with the materials. A large audience may present problems over time, in that
they will ask an associate for information rather than referencing their documentation, which will cause
consistency problems.

Therefore, the size of the audience determines the general approach for the development, implementation,
and training of the Policies, Processes, and Procedures.

Individual Audience Needs Assessment
The Needs Assessment of the individual audience evaluates the identified audiences and provides specific
information about each audience. This assessment will ensure that the Policies, Processes, and Procedures will
meet their specific needs. The main factors used are the following:

Is this the primary or secondary audience?
Determine if a specific audience will be the primary or secondary users. Depending on the scope, size, and
implementation approach of the project, multiple audiences can be designated as the primary audience. The
primary audiences will be the highest priority for the Policies, Processes, and Procedures development and
implementation.

What is the job description of the audience?
Determine the basic job description of the audience. Many times the job description will change with a major
implementation. Having a before and after job description highlights those areas that will be new to an
audience and, therefore, may need a higher level of detail for the Policies, Processes, and Procedures. This
alerts you to the following important issues:

Additional responsibilities to be addressed for the audience.

Function should be performed by another audience, because of control issues.


Audience Evaluation

Additional training may be required, before the new Policies, Processes, and Procedures can be
implemented for the audience.

Does the audience process critical data or transactions?
Determine how critical the information, which is processed by the audience, is to the company. If the
information is key to the company or to upstream processes, this again highlights an area that requires a
higher level of detail for the Policies, Processes, and Procedures. Some documentation is more important or
critical than others. For example, a document updating SOX controls may be more critical than a document
updating a system’s function keys. Different audiences may require a more complex part of the
documentation to understand it. Understanding this relationship gives a priority for the development and
implementation of the Policies, Processes, and Procedures.

This factor will also highlight an area of Policies, Processes, and Procedures verification to ensure the
information is correct and the desired results are obtained.

What is the level of detail required by the audience?
Each audience may require a different level of detail for their Policies, Processes, and Procedures.
Understanding the proper level of detail for documentation is directly related to usability. If there is not
enough detail, the user cannot get a question answered in a timely manner and must resort to other sources
for the information. If there is too much detail, the user will become frustrated with the amount of information
and attempt to get the information from another source. The results of this evaluation directly affect usability.

To ensure consistency of operation, the documentation detail must be ‘just right’ so that users will reference
and use the documentation. Therefore, this task may need to be completed during the content research task,
when you are working with the users. You must understand their job, their needs, and their problem
resolution requirements. That understanding allows you to prepare the documentation with the proper
amount of detail. In addition, during the testing task, you may discover that you are missing critical
information.

How does the audience locate their Policies, Processes, and Procedures?
Determine how the user searches to locate and access the Policies, Processes, and Procedures.

Search criteria

Meta data

Taxonomy

Manual searching through files or documents

If the audience currently is using paper-based Policies, Processes, and Procedures, and you will be proving
electronic Policies, Processes, and Procedures, additional training is required on searching and accessing the
new documentation. In addition, many audiences may not be oriented to structured documentation. They will
require training on the differences between a Policy, Process, and Procedure so that they will be able to
efficiently access needed documents.

How does the audience problem-solve?
Determine how the audience solves problems or gets questions answered. This will inform you of the level of
information available to the person. It will also be a lead-in to the level of training that will be required.
Because consistency in results and outcome is desired, you want the audiences to reference the Policies,
Processes, and Procedures for direction and answers. This may require additional training and follow-up to
create this new culture.


Audience Evaluation

The following questions give valuable information as to the type of documentation the audience needs and
wants.

Does the person guess at an answer?

Does the person ask another person?

Does the person have existing documentation?

Does the person use online help?

Does the person keep their own notes?

What is the person’s biggest problem during problem solving?

What is the audience work environment?
Determine the audience work environment.

Do they work as an integrated group?

Do they work alone in a separate environment?

Are they on the phone or with customers a great deal of time?

Is the work primarily transaction driven?

Do they have critical dates on a weekly, monthly, or yearly basis? If they do, the audience may
require check sheets that give critical tasks and their due dates that lead up to the weekly, monthly or
yearly deadline. In addition, additional training may be required for those that ‘lend a hand’ during the
critical deadlines.

Management audience
Management plays a major part in the development of Policies, Processes, and Procedures. Therefore,
management must also be addressed as an audience. Management requirements will be different than primary
or secondary audiences. Management, with the exception of management directly responsible for primary and
secondary audiences, will always require Policies and Processes.

What is the language of the management audience?

What is the location of the management audience?

What are the required critical Policies?

What is the size of the management audience?

How do they want to access their Policies and Processes? Is there a management portal where they
want their documentation?

Are there critical review dates for Policies and Processes? How is management currently informed of
review dates?

Does management author Policies, Processes, and Procedures? If they are the authors, they must
receive and adhere to the eDocumentation™ Process standards.


Audience Evaluation

Plan

Build

Implement


Content Review Team

Content Review Team
The Content Review team is comprised of subject matter experts and management personnel, who review
specific content contained in the Policies, Processes, and Procedures. Coordination is a key factor for the
success of the Content Review team. The individual members review only the documents that pertain to their
subject area or area of responsibility. Some members may review only the final content.

Identification of the subject matter experts is an important factor in the planning and scheduling of a
documentation project. A planning meeting with the Content Review team to determine their requirements,
constraints, statutory issues, and control issues is advisable. Understanding these issues, before developing and
writing the Policies, Processes, and Procedures will prevent schedule delays.

There may be multiple Content Review teams on a project. As an example, Procure to Pay includes expertise in
Purchasing, Receiving, Accounts Payable, and General Ledger. Therefore, there may be a Procure to Pay
Content Review team acting with sub teams comprised of Purchasing, Receiving, Accounts Payable, and General
Ledger. Your Content Review team structure depends upon the size of the project and the company. The
Content Review team should not be so large that it becomes burdensome or so small that vital content can be
overlooked.

Composition of the Content Review team
The Content Review team is comprised of subject matter experts and management personnel, who must guide,
assess, and approve the content. The members of the Content Review team can be fluid. Some members may
serve for a limited period of time or for the length of the project, depending upon their review scope and
knowledge of specific requirements and issues.

Members can be removed and new members added as the content requires or if original members cannot
support the project.

Members are not assigned as a formality. If a person is assigned to the Content Review team, they must be able
and willing to provide the reviews as required and within the scheduled time frame. This may require providing
extra support or backfilling for the team member to allow for the additional responsibility.

The following are examples of the various areas that might be part of the Content Review team, based upon the
type of content being researched and developed:

Management
Process owners

Legal

Human resources

Safety

Subject matter experts
Business processes (i.e. Procure to Pay)

Policies

Statutory (i.e. SOX, GAAP, HACCP)

Controls


Content Review Team

Technical support

Member responsibilities
Individual team members will have specific areas of expertise and responsibility. In order to have a well-balanced
team, the individuals must represent the following:

Expertise in the specific content area

Familiarity with the structure of the organization

Ability to relate information to other areas of the company

Enthusiasm about the project

Ability and willingness to commit time and energy to the project

Determination to resolve issues within the scheduled time frame

Team responsibilities
Team coordination and cooperation will greatly impact the quality of Policies, Processes, and Procedures. Teams
that view and execute the following duties earnestly will enable the Policies, Processes, and Procedures to be
researched and developed in a productive and timely fashion.

Recommend and approve the subject matter breakdown, based on the quantity of content to be
researched and developed.

Set up method for reviewing Policies, Processes, and Procedures. Initially the team may conduct formal
walkthrus to discuss and review the documentation.

Determine the owner for the Policies, Processes, and Procedures.

Determine the lead person for team coordination.

Resolve questions and conflicts between departments as they pertain to the Policies, Processes, and
Procedures.

Identify the key and critical information for the Policies, Processes, and Procedures.

Verify and approve the specific information communicated in the documentation.

Assist with setting up consistent and standard terminology, as it relates to the content.

Request scope of content be increased, if new requirements surface.

Provide approval for the implementation and the distribution of Policies, Processes, and Procedures.

It is also important to note those responsibilities that do not pertain to the Content Review team. If the Content
Review team performs tasks that are outside its scope, such as those listed, the project will begin to wander off
task. In addition, there will be further problems down the road; in that the team’s main purpose – content - will not
have been developed and analyzed.

The team does not perform editing responsibilities.

The team does not set up the implementation plan and approach.


Content Review Team

The team does not establish standards.

Build


Support Team

Support Team
The Policies, Processes, and Procedures developer requires collaboration and support, within the company, to
get answers to the many questions that arise during a documentation project. The Support team must
understand the myriad of issues and questions the documentation developer encounters and must furnish the
answers in a timely fashion.

The Support team is not comprised of members of the Project team. They are supplemental and on-demand. It
is not unusual for the Support team to have members located in different cities or even different countries.

The demands on the Support team are dependent upon the size and complexity of the project. The process that
is used to provide assistance for the documentation developer will vary, based on the size of the project and the
proximity of the Support team.

Two questions need to be answered:

Who has the supplemental knowledge or expertise?

How should the person be contacted?

An enterprise, with an established knowledge culture, understands this need. A framework for available expertise
may currently exist. If a framework does not exist, it should be built as the project progresses, and the required
expertise is discovered.

The Documentation developer should have a list of the members of the Support teams and their areas of
expertise. The list may or may not be available to other members of the team. If the team is large, there should
be a process for contacting a person for assistance, so that it will not interfere with their daily responsibilities.

Subject matter experts
Subject matter experts, that are not part of the project team, may need to be consulted at times during the project.
These resources are very valuable for verifying information or providing quick answers. For example, if your
project is not officially using the Training department, it may helpful to consult the department for training
questions. If your project is small, determine the type of support your company has that will be helpful to you.

Systems support
At times during the project, especially during testing, system support will be needed - some as simple as logon
ID’s. Because system support can be located in multiple locations, knowing the proper person to contact will save
time.

Vendor contacts
When preparing Processes and Procedures for software, a vendor contact may be required; particularly if
modifications have been made to the software. You should know the contractual agreements between your
company and the vendor, before asking for support. However, most vendors do not object to periodic questions.

It is more effective to thoroughly document the question (including screen captures) in an email than to discuss
the issue on the phone. A prompt answer is often received, if the question is properly documented.

Technical contacts
Technical support may include analysts and programmers. There are times when the Documentation developer
has a question that requires a technical person to consult.


Support Team

Expeditor
An expeditor is a person who knows who to go to for a quick resolution of a problem - after all else fails. The
expeditor can be the project manager, a person in management, or any person who knows the organization and
has a certain level of clout. The purpose of the expeditor is to keep the project from falling behind schedule, due
to issues that are not being resolved.

If an expeditor cannot solve a problem, the issue should then be escalated, using the escalation matrix.

Plan


Content Classification

The initial research of a project can be quite overwhelming, because of the amount of data you will need to
analyze. Understanding begins when you are able to see classifications and relationships between the types of
data.

A vast amount of data requires analysis, during the research phase. From the analysis the data will be
transformed into contents for a specific Policy, Process, or Procedure.

When gathering the information, understanding where the information might belong can be a method of sorting
the information.

One of the first tasks, during planning, is listing major functions that are affected. If major functions are performed
in multiple locations, observe that each location might perform the same functions. Determine whether they are
the same functions or different functions, due to different systems, local statutory requirements, different
compliance requirements, or other reasons.

Classification type
Specific types of information will be contained in a Policy, Process, or Procedure. However, content sourced
within a Policy can also be referenced or linked in a Process and/or a Procedure. It is vital that the information is
consistent between all types of documents.

The following matrix refers to major types of content and where that content can be used. These are guidelines,
not rules. Each enterprise should classify their content types to fit their needs.

O Originates

The content will originate within this specific type of document. All content in other document types
align with the content in the originating document type.

A Aligns

The content in the document types must align with the content in the originating source document.
When questions arise as to how to perform a specific Process or Procedure, the author reviews the
originating source to ensure the content is aligned and in compliance. This prevents conflicting
content between document types.

Type of content Policy Process Procedure Lists
Acronyms A A A O
Balancing O A
Business function O
Business task O A
Codes A O
Contact information A O
Controls O A A



Type of content Policy Process Procedure Lists
Cycle time O A
Data elements / field names O
Database O A
Date and time requirement O A A
Department guidelines / rules O A A
Enterprise guidelines / rules O A A
Escalation O A
Exceptions or errors O A
Forms O A
Glossary of terms A A A O
Industry best practices O A A
Messages (error, warning) O
Process task O A
Regulatory – enterprise (SOX, O A A
FEC)
Regulatory - local O A A
Reports O A
Responsibility O A A
Screens O A
Service level agreements O A
System O A
Technical support / help O
Workflow O A

Content organization
The scope of the project defined during the planning phase, defines the types of content – Policies, Processes,
and Procedures - to be developed or updated. You will have either a list of existing documentation to be updated
and expanded or a major function list for the affected locations and departments, which you have prepared. With
this blueprint you will be able to organize the content and determine the documents in which the content resides,
or whether new documents should be created.

Content organization is defined as ‘Where does the content belong?’ The following diagram shows the
relationship between the information contained in the Policies, Processes, and Procedures. Policies, Processes,
and Procedures are dependent upon each other and must be consistent in all ways (features, attributes,
functions, characteristics). The content of the Processes and the Procedures must reflect the Policy guidelines
and rules. Without rewriting, the Policies, Processes, and Procedures must be aligned. Procedures also relate to
each other. Although they are written as separate documents, they can be assembled into different document



sets for different audiences, providing all the information that is necessary to accomplish their responsibility and
task.

Policies 3 3
Share Share
Policies do not 2
Policy
2
Policy
2

duplicate
Accounts Payable
information. The Purchasing Policy Receiving Policy
Policy
Policy may be
shared between
functional areas.

Processes Create Purchase Reference
Receive Materials
Reference
Pay Vendor
Order Only Only
Processes should
not duplicate
functions. They
may reference
other Process
where they
3 way match
connect Set up Vendor Receive Material PO, Receiver,
Invoice

Procedures Create Purchase
Inspect Materials
Remit Vendor
Requisition Payment
Procedures should
not duplicate Create Purchase Record Vendor
tasks. They Order Invoice
should be stand-
alone.

Classify
Identify the content and classify it according to the document type that may use that type of content - Policy,
Process, or Procedure. This will organize the content so that the documents will contain only the proper
content types.

Where used
After classifying the content for each document type, define where the content is used, based on major
business functions (for example, Procure to Pay). Content can be used in different documents, but you only
want to write the content once. By defining where it can be used, you will select the document source of the
content, and all other documents will link or reference it.

For example, you are developing the Procure to Pay Processes and Procedures. When you are researching
the system screen instructions, you will note that the screen is referenced in a business Process (Procure to
Pay), a Procedure, and a system screen Procedure. You will define the source document for the system
screen instructions, and other documents will refer to the source.

Relationships and patterns
When defining where content is used, look for relationships and patterns to be found in the content. For
example, you may notice that, basically, all the vendor business functions refer to the same screens, with
minor changes, based on the function being performed. You may then decide to structure the vendor screen



Procedures, reusing certain information, as opposed to writing the same information multiple times. In the
above graphic, the Create Purchase requisition and Create Purchase order may use the same screens, as
the basic functions are usually the same.

Different locations
Standardizing Processes is achieved by having all locations perform the same tasks in the same manner.
However, globally you might have each location performing a task in a slightly different way. Many times
variations are required, due to local or statutory requirements. In most cases, however, the Processes are
standard.

Determine if localization can be achieved simply by adding a separate section, based on location, or whether
the changes are so vast a new Process or Procedure is required.

Overlapping content types
Policies, Processes, and Procedures are interdependent, based upon the content contained within each one. It
may emerge that the content types overlap between the document types, during classification and organization.
Re examine the content types in order to determine where it actually belongs. This is usually determined by the
purpose and level of detail of the document type.

Processes have different levels – high level overview to detail tasks. The Process, with more detail, may begin to
‘look like’ a Procedure. If this is the case, you need to evaluate the Process and determine if it is actually a
Procedure.

Policies can be at an enterprise, location, or department level. Policies should always stand alone. But at the
department level, a Procedure will provide the detail to implement the Policy. Be sure that the Policy is not
restated in the Procedure.

Policy
Policy Content Types
Content Types Process Process
Content Types Content Types
Change so there
is no overlap

Procedure
Procedure
Content Types
Content Types

Plan


Accessible Policies, Processes, and Procedures

After creating clear, concise, complete, and correct™ Policies, Processes, and Procedures, the main issue
becomes ‘How will the user quickly and easily locate and access the desired Policies, Processes, and
Procedures?’ It should not involve an obstacle course to find the needed information. Users require a clear,
intuitive roadmap, adapted to the user’s way of thinking about their content, regardless of the technology or lack
of technology being used. Advanced technology does not guarantee ease of accessibility.

Changes are not obvious if Policies, Processes, and Procedures are in a shared folder or listed in a
Content Management system. Additional research is then required.

Some companies put Policies, Processes, and Procedures in a shared folder on their server and expect
users to find the Policies, Processes, and Procedures. However, the shared folder does not have any
intelligence associated with it. Although in a central location, they are not easily and readily accessible.

Some companies put in a Content Management system without the correct keywords or categories and
expect users to find Policies, Processes, and Procedures among the hundreds of other documents.

Although a system application may have online help, this is usually restricted to brief system Procedures.
The online help does not address the Policies and Processes associated with the Procedure. Therefore,
critical Policy and Process information would not be accessible.

Some companies use paper manuals and group all of the relevant Policies, Processes, and Procedures
in one place so that the users can scan thru the manual. This can be quite primitive.

Factors
Accessibility takes into account a variety of factors, many of them identified in previous eDocumentation™ tasks.
It is an analysis of the information and verification with the users that determine the final approach. Accessibility
is dependent on the user behavior and requirements, and cannot be comprised of a stand-alone solution – even if
you are using only a paper-based approach.

Audience Evaluation
The Audience Evaluation, performed during the Planning phase, is used for accessibility planning. Each
audience is evaluated to determine the parameters they use to access Policies, Processes, and Procedures.
Such questions that would be asked to identify the factors are the following:

Where are the department or functional Policies, Processes, and Procedures? Are the documents on
a shared drive? Are the documents in a content management system?

How are specific Policies, Processes, and Procedures located? Do the users read the file name? Do
the users use the title? Is there a brief description associated with the document?

How is a Policy, Process, or Procedure determined to be the proper document? Does the user have
to open and read the document to determine if it contains the needed content to answer a question?

Technology used
The available technologies identified during the Planning phase is used for accessibility planning. The
technology is evaluated to determine if it can be used for the project, and if it is appropriate for the project.

What type of technology is used for storing and accessing the Policies, Processes, and Procedures?

Is the technology available to every audience? If not, what is the access method for those
audiences?



What are the basic capabilities of the technology?

Category and keyword evaluation
The categories and keywords identified during the Planning phase are used for accessibility planning. The
categories and keywords are evaluated to determine if they can be used for the project, and if they are
appropriate for the project.

Is a search engine available to the users?

Are categories and keywords defined?

Are the categories and keywords successful in quickly locating a Policy, Process, or Procedures?

Have the categories and keywords been verified and tested with the users?

User functionality
Users of Policies, Processes, and Procedures have unique accessibility requirements.

Notify user of changes to documents so that they will know what to review and when to review.

Provide email notifications to users of new or changed Policies, Processes, and Procedures. The
email should contain a link to the new or changed documents.

Provide alerts on the Home Page to alert users of new or changed documents.

Provide a list of the Policies, Processes, and Procedures with the respective overview descriptions.

Provide meaningful Policy, Process, and Procedure titles to identify the document.

Provide specific and effective category and keywords to search and identify documents. Policy,
Process, and Procedure categories and keywords must be tailored for those documents and users.
They may or may not fit with an existing taxonomy.

Provide a map that acts as a guide to the proper locations for the Policies, Processes, and
Procedures.

Provide users with the capability to sort the Policies, Processes, and Procedures in a way that is
meaningful to them; by category, department, function, review date, author, or owner.

Incorporate change management functionality; reporting needed changes, errors, issues, or
suggestions.

Separate – totally – from the source documents, what the user views and accesses. Do not allow
changes to be made outside the change management Process.

Be prepared
If your company does not currently have technology to support the access of Policies, Processes, and Procedures
(i.e., a content management system; a search engine available to users; a taxonomy for Policies, Processes, and
Procedures; or a web based access for users), it is probably only a matter of time before the technology is
available.

Plan



Implement


2. eDocumentation Process Plan Phase

2. eDocumentation Process Plan Phase

Recomendados

Recomendados

Más contenido relacionado

Similar a 2. eDocumentation Process Plan Phase

Similar a 2. eDocumentation Process Plan Phase (20)

Último

Último (20)

2. eDocumentation Process Plan Phase