Your SlideShare is downloading. ×
2. eDocumentation Process Plan Phase
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

2. eDocumentation Process Plan Phase

675
views

Published on

Published in: Business, Technology

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
675
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. eDocumentation™ ProcessPlan Phase Knowledge Process, Inc. www.DocumentationProcess.com www.KCGGroup.com
  • 2. Table of Contents – Plan Table of Contents – PlanTable of Contents – Plan ..................................................................................................................... 2Project Scope and Objectives ............................................................................................................. 5 Scope .............................................................................................................................................................. 5 Objectives ........................................................................................................................................................ 6 Scope changes ................................................................................................................................................ 6 eDocumentation™ Process phase .................................................................................................................... 7eDocumentation™ Process Flow ....................................................................................................... 8 eDocumentation™ Process phases .................................................................................................................. 8 eDocumentation™ Process phase .................................................................................................................. 10Policy, 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 eDocumentation™ Process phase .................................................................................................................. 13Policy .................................................................................................................................................. 14 eDocumentation™ Process phase .................................................................................................................. 15Process............................................................................................................................................... 16 eDocumentation™ Process phase .................................................................................................................. 18Procedure ........................................................................................................................................... 19 eDocumentation™ Process phase .................................................................................................................. 20Content Audit and Evaluation ........................................................................................................... 21 Sources.......................................................................................................................................................... 21 Level of detail ................................................................................................................................................. 22 Complexity of material .................................................................................................................................... 22 Critical nature of materials .............................................................................................................................. 22Version 1.0 eDocumentation™ Plan Phase Page 2 of 56
  • 3. Table of Contents – Plan Preliminary table of contents .......................................................................................................................... 22 eDocumentation™ Process phase .................................................................................................................. 24Audience Evaluation.......................................................................................................................... 25 Audience identification evaluation ................................................................................................................... 26 Individual Audience Needs Assessment ......................................................................................................... 26 Management audience ................................................................................................................................... 28 eDocumentation™ Process phase .................................................................................................................. 29Content Review Team........................................................................................................................ 30 Composition of the Content Review team ....................................................................................................... 30 Member responsibilities .................................................................................................................................. 31 Team responsibilities ...................................................................................................................................... 31 eDocumentation™ Process phase .................................................................................................................. 32Support Team..................................................................................................................................... 33 Subject matter experts.................................................................................................................................... 33 Systems support ............................................................................................................................................ 33 Vendor contacts ............................................................................................................................................. 33 Technical contacts.......................................................................................................................................... 33 Expeditor........................................................................................................................................................ 34 eDocumentation™ Process phase .................................................................................................................. 34Content Classification ....................................................................................................................... 35 Classification type .......................................................................................................................................... 35 Content organization ...................................................................................................................................... 36 Overlapping content types .............................................................................................................................. 38 eDocumentation™ Process phase .................................................................................................................. 38Accessible Policies, Processes, and Procedures ........................................................................... 39 Factors........................................................................................................................................................... 39 Be prepared ................................................................................................................................................... 40 eDocumentation™ Process phase .................................................................................................................. 40Usability Factors ................................................................................................................................ 42 Factors........................................................................................................................................................... 42Version 1.0 eDocumentation™ Plan Phase Page 3 of 56
  • 4. Table of Contents – Plan User verification ............................................................................................................................................. 44 eDocumentation™ Process phase .................................................................................................................. 44Consistent Terms – a Common Language ....................................................................................... 45 1. Dictionary .................................................................................................................................................. 45 2. Inconsistent terms ..................................................................................................................................... 45 3. Source ...................................................................................................................................................... 46 4. Search ...................................................................................................................................................... 48 5. Developing consistent terms ...................................................................................................................... 50 eDocumentation™ Process phase .................................................................................................................. 52Soft Skills ........................................................................................................................................... 53 What are team soft skills?............................................................................................................................... 53 eDocumentation™ Process phase .................................................................................................................. 55Knowledge Process, Inc. ................................................................................................................... 56 About Knowledge Process.............................................................................................................................. 56 Copyright ....................................................................................................................................................... 56Version 1.0 eDocumentation™ Plan Phase Page 4 of 56
  • 5. Project Scope and Objectives Project Scope and ObjectivesThere is the saying ‘Schedule, budget, or quality – choose two’, implying that you may not be able to achieve thelevel of quality required for a project and also meet the schedule and the budget. However, quality is not to becompromised. It is a changing scope that causes increased budget and schedule. Therefore, fully understandinga project’s scope and objectives, in every aspect, will alert you to potential ‘scope creep’ that can adversely affectyour project.This chapter addresses the project scope and how it will affect the development of the Policies, Processes, andProcedures. Please note that this chapter does not address project management. Project management is aseparate discipline requiring trained expertise.ScopeThe scope should clearly establish a beginning and an end, including the project deliverables. Performing theplanning tasks in the eDocumentation™ Process will assist in defining the scope to research and thedevelopment and implementation of the required Policies, Processes, and Procedures for a project. Thedocumented 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, thedocumentation project success is often dependent on the planning of the larger project. Care must be taken toincorporate the Policies, Processes, and Procedures as a Subproject within the master project plan and to ensurethe 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?Version 1.0 eDocumentation™ Plan Phase Page 5 of 56
  • 6. Project Scope and Objectives 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?ObjectivesThe objectives of a documentation project define what the success will be. This ensures that there are nosurprises and disappointments.Clear, concise, complete, and correct™ documentation is always the objective. In addition, other objectives mayinclude 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 changesThe major reason a project goes ‘out of control’ is an increase in project scope. Increase of scope can be causedby 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.Version 1.0 eDocumentation™ Plan Phase Page 6 of 56
  • 7. Project Scope and Objectives 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 phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 7 of 56
  • 8. eDocumentation™ Process Flow eDocumentation™ Process FlowThe eDocumentation™ Process is a set of guidelines, not decrees, that guide the Documentation developerthrough the research, development, and implementation of Policies, Processes, and Procedures. The objective isto 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 thediligence 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: ChangeeDocumentation™ Process phasesThere are four major phases that comprise the eDocumentation™ Process. The phases encompass the tasksthat need to be reviewed and performed as the project progresses, depending upon the company, project, andscope. 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.Version 1.0 eDocumentation™ Plan Phase Page 8 of 56
  • 9. eDocumentation™ Process Flow 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 ApprovalVersion 1.0 eDocumentation™ Plan Phase Page 9 of 56
  • 10. eDocumentation™ Process FloweDocumentation™ Process phasePlanBuildImplementationChangeVersion 1.0 eDocumentation™ Plan Phase Page 10 of 56
  • 11. Policy, Process, and Procedure – What Is the Difference? 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, aProcedure, or a Process. All address related subject matter, but at a different level and with different types ofcontent. Each type has a unique purpose that drives the content contained in each type of document. Describingthe distinctions using who, what, where, when, why and how often helps to understand and properly structurethem.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.Version 1.0 eDocumentation™ Plan Phase Page 11 of 56
  • 12. Policy, Process, and Procedure – What Is the Difference?Driving from Hollywood to Los Angeles – A Policy, Process, and ProcedureUsing common maps to illustrate the differences between a Policy, Process, and Procedure, the followingexample illustrates that different content is contained within each type of document. While all the informationrelates to the subject of driving from Hollywood to Los Angles, different content type is used for differentdocuments. 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.Version 1.0 eDocumentation™ Plan Phase Page 12 of 56
  • 13. Policy, Process, and Procedure – What Is the Difference?eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 13 of 56
  • 14. Policy PolicyPolicy aligns and supports the enterprise’s strategic plans, goals, and objectives. It is the foundation for thecontent of Processes and Procedures, as they should not contradict a Policy. Policy should remain fairly stableand not be subject to as frequent changes as a Process or Procedure. Policy should always have a review dateassociated with it, to ensure that it is compliant.Policy is the foundation for an enterprise, country, location, functional area, or department. Policy forms ahierarchy with each level, aligning with the policies above it. Policy may need to be adapted, based upon specificrequirements or regulations for a country or location. However, these adaptations must align with the policiesabove it in the hierarchy. For certain subjects, you may need an umbrella Policy that states the basic andunchanging content, such as Legal and Financial Reporting. While there may be different country Policies, theenterprise 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 anenterprise.There are many purposes for Policy: obtain a high level of quality; understand the legal requirements; obtainaccuracy of processing; obtain consistent and reliable metrics; implement consistent and required controls; andreduce risks and penalties. Only through Policy can the purposes and requirements be communicated andimplemented.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 ofa Policy is being used by all who are affected. They will know that the correct version is being used, if they knowwho requires the policy; what the effective date is; when the next review is required; where the document islocated; and proper reviews and approvals have been obtained. The first step to achieve the objectives is to setup 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.Version 1.0 eDocumentation™ Plan Phase Page 14 of 56
  • 15. 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, andreviewed.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 15 of 56
  • 16. Process ProcessA Process identifies all tasks within a Process and its boundaries, beginning to end. A Process may referenceother Processes, when they are cross functional (for example, Quality and Procure to Pay). Within a Process youwill 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 Managementinitiatives that are used for enterprise business design. BPM is used to standardize Processes, to attain aconsistent outcome, and to add value for the enterprise. The results of BPM have multiple purposes and areused for different initiatives. Therefore, for our purposes we do not want to confuse BPM Initiatives with Processdocumentation. When it is applicable, Business Process Management maps are used as input for user Processmaps 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 flowsProcesses are often referred to as a Process map, because as a map or flowchart it is the easiest way to illustratetasks within a Process. A Process will usually be cross functional, as it pertains to multiple functional areas. Auser Process will have multiple purposes - training, research, documentation. Processes can easily become amaze, if not clearly defined. Process maps that are used for ‘to be’ Processes and are not updated for userdocumentation become lost assets and tools for users. Therefore, clear guidelines and standards must be set forProcesses. 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.Version 1.0 eDocumentation™ Plan Phase Page 16 of 56
  • 17. ProcessThe following is an example of a Process that results in a Sub-process. Process maps can also have high leveltext 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 POVersion 1.0 eDocumentation™ Plan Phase Page 17 of 56
  • 18. ProcessMust 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 moreeffective 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 instructionseDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 18 of 56
  • 19. Procedure ProcedureA Procedure is the detailed steps required to perform a task. The Procedure defines exactly how to perform thetask to obtain the desired result. Procedures can be in the form of keying instructions, approval instructions, orbalancing instructions.A Procedure guides the user through the steps to perform a specific task. Fundamentals of a Procedure are thefollowing: 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, thePolicy should not be part of the Procedure. The Procedure should contain only information that pertains toperforming 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 instructionsVersion 1.0 eDocumentation™ Plan Phase Page 19 of 56
  • 20. ProcedureeDocumentation™ Process phasePlanBuildVersion 1.0 eDocumentation™ Plan Phase Page 20 of 56
  • 21. Content Audit and Evaluation Content Audit and EvaluationThe objective of a Content Audit and Evaluation is to determine the quality and quantity of existing content thatrelates to the project, and provide a ‘best guess’ as to the scope of Policies, Processes, and Procedures that willneed to researched and developed. During the task you will determine what documentation exists, who uses it,and the age of the content.SourcesExisting project related content is a source of knowledge that can be used to ‘get your arms around’ the potentialdocumentation. 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.Version 1.0 eDocumentation™ Plan Phase Page 21 of 56
  • 22. Content Audit and Evaluation 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 detailBased upon the Audience Evaluation, who will use the functions has previously been identified. Determine thelevel 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 anduse the documentation. Therefore, this task is completed during the content research task, when you are workingwith the users. You must understand their job, their needs, and their problem resolution requirements. Thatunderstanding will assist you in preparing the documentation with the proper amount of detail.Complexity of materialDetermine 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 materialsSome documentation is more important or more critical than other documentation. For example, a documentupdating SOX controls may be more critical than a document updating a system’s function keys. Differentaudiences may require a more complex part of the documentation to understand it. Understanding thisrelationship gives a priority for the development and implementation of the Policies, Processes, and Procedures.Preliminary table of contentsThe output of the content audit is the preliminary table of contents. This is not the table of contents that will begenerated by the Policies, Processes, and Procedures from the heading styles or tags. The content audit table ofcontents is manually developed and serves as an estimate of the Policies, Processes, and Procedures to bedeveloped.It is helpful to set up the preliminary table of contents using Excel ™, in order that the various columns can besorted, giving different views.To develop the preliminary table of contents, perform the following steps: 1. Determine major Process being audited.Version 1.0 eDocumentation™ Plan Phase Page 22 of 56
  • 23. Content Audit and Evaluation 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, thespreadsheet 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 paymentVersion 1.0 eDocumentation™ Plan Phase Page 23 of 56
  • 24. Content Audit and EvaluationeDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 24 of 56
  • 25. Audience Evaluation Audience EvaluationEvaluating the audience who will use the Policies, Processes, and Procedures is one of the most importanteDocumentation™ planning tasks performed. The Audience Evaluation affects many of the tasks that comprisethe documentation process. The audience is the user and the reason for developing the Policies, Processes, andProcedures. There can be multiple audiences for the documentation, each having a unique set of requirementsfor the documents. Therefore, each audience must be evaluated independently. Upon completion of eachAudience Evaluation, you will be able to tailor the Policies, Processes, and Procedures to their needs andrequirements. 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 ProceduresVersion 1.0 eDocumentation™ Plan Phase Page 25 of 56
  • 26. Audience EvaluationAudience identification evaluationThe project team will identify user groups that require Policies, Processes, and Procedures. The groups will beclassified into distinct audiences, based on the following factors. The initial evaluation identifies the audiencesand 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 AssessmentThe Needs Assessment of the individual audience evaluates the identified audiences and provides specificinformation about each audience. This assessment will ensure that the Policies, Processes, and Procedures willmeet 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.Version 1.0 eDocumentation™ Plan Phase Page 26 of 56
  • 27. 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.Version 1.0 eDocumentation™ Plan Phase Page 27 of 56
  • 28. 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 audienceManagement 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 primaryor secondary audiences. Management, with the exception of management directly responsible for primary andsecondary 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.Version 1.0 eDocumentation™ Plan Phase Page 28 of 56
  • 29. Audience EvaluationeDocumentation™ Process phasePlanBuildImplementVersion 1.0 eDocumentation™ Plan Phase Page 29 of 56
  • 30. Content Review Team Content Review TeamThe Content Review team is comprised of subject matter experts and management personnel, who reviewspecific content contained in the Policies, Processes, and Procedures. Coordination is a key factor for thesuccess of the Content Review team. The individual members review only the documents that pertain to theirsubject 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 adocumentation 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 andwriting 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 inPurchasing, Receiving, Accounts Payable, and General Ledger. Therefore, there may be a Procure to PayContent Review team acting with sub teams comprised of Purchasing, Receiving, Accounts Payable, and GeneralLedger. Your Content Review team structure depends upon the size of the project and the company. TheContent Review team should not be so large that it becomes burdensome or so small that vital content can beoverlooked.Composition of the Content Review teamThe 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 mayserve for a limited period of time or for the length of the project, depending upon their review scope andknowledge of specific requirements and issues.Members can be removed and new members added as the content requires or if original members cannotsupport the project.Members are not assigned as a formality. If a person is assigned to the Content Review team, they must be ableand willing to provide the reviews as required and within the scheduled time frame. This may require providingextra 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 thetype 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) ControlsVersion 1.0 eDocumentation™ Plan Phase Page 30 of 56
  • 31. Content Review Team Technical supportMember responsibilitiesIndividual team members will have specific areas of expertise and responsibility. In order to have a well-balancedteam, 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 frameTeam responsibilitiesTeam coordination and cooperation will greatly impact the quality of Policies, Processes, and Procedures. Teamsthat view and execute the following duties earnestly will enable the Policies, Processes, and Procedures to beresearched 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 ContentReview team performs tasks that are outside its scope, such as those listed, the project will begin to wander offtask. In addition, there will be further problems down the road; in that the team’s main purpose – content - will nothave been developed and analyzed. The team does not perform editing responsibilities. The team does not set up the implementation plan and approach.Version 1.0 eDocumentation™ Plan Phase Page 31 of 56
  • 32. Content Review Team The team does not establish standards.eDocumentation™ Process phaseBuildVersion 1.0 eDocumentation™ Plan Phase Page 32 of 56
  • 33. Support Team Support TeamThe Policies, Processes, and Procedures developer requires collaboration and support, within the company, toget answers to the many questions that arise during a documentation project. The Support team mustunderstand the myriad of issues and questions the documentation developer encounters and must furnish theanswers in a timely fashion.The Support team is not comprised of members of the Project team. They are supplemental and on-demand. Itis 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 thatis used to provide assistance for the documentation developer will vary, based on the size of the project and theproximity 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 expertisemay currently exist. If a framework does not exist, it should be built as the project progresses, and the requiredexpertise is discovered.The Documentation developer should have a list of the members of the Support teams and their areas ofexpertise. The list may or may not be available to other members of the team. If the team is large, there shouldbe a process for contacting a person for assistance, so that it will not interfere with their daily responsibilities.Subject matter expertsSubject 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 yourproject is not officially using the Training department, it may helpful to consult the department for trainingquestions. If your project is small, determine the type of support your company has that will be helpful to you.Systems supportAt times during the project, especially during testing, system support will be needed - some as simple as logonID’s. Because system support can be located in multiple locations, knowing the proper person to contact will savetime.Vendor contactsWhen preparing Processes and Procedures for software, a vendor contact may be required; particularly ifmodifications have been made to the software. You should know the contractual agreements between yourcompany 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 discussthe issue on the phone. A prompt answer is often received, if the question is properly documented.Technical contactsTechnical support may include analysts and programmers. There are times when the Documentation developerhas a question that requires a technical person to consult.Version 1.0 eDocumentation™ Plan Phase Page 33 of 56
  • 34. Support TeamExpeditorAn expeditor is a person who knows who to go to for a quick resolution of a problem - after all else fails. Theexpeditor can be the project manager, a person in management, or any person who knows the organization andhas a certain level of clout. The purpose of the expeditor is to keep the project from falling behind schedule, dueto issues that are not being resolved.If an expeditor cannot solve a problem, the issue should then be escalated, using the escalation matrix.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 34 of 56
  • 35. Content Classification Content ClassificationThe initial research of a project can be quite overwhelming, because of the amount of data you will need toanalyze. Understanding begins when you are able to see classifications and relationships between the types ofdata.A vast amount of data requires analysis, during the research phase. From the analysis the data will betransformed into contents for a specific Policy, Process, or Procedure.When gathering the information, understanding where the information might belong can be a method of sortingthe information.One of the first tasks, during planning, is listing major functions that are affected. If major functions are performedin multiple locations, observe that each location might perform the same functions. Determine whether they arethe same functions or different functions, due to different systems, local statutory requirements, differentcompliance requirements, or other reasons.Classification typeSpecific types of information will be contained in a Policy, Process, or Procedure. However, content sourcedwithin a Policy can also be referenced or linked in a Process and/or a Procedure. It is vital that the information isconsistent 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 AVersion 1.0 eDocumentation™ Plan Phase Page 35 of 56
  • 36. Content Classification 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 AContent organizationThe 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 updatedand expanded or a major function list for the affected locations and departments, which you have prepared. Withthis 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 therelationship 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 guidelinesand rules. Without rewriting, the Policies, Processes, and Procedures must be aligned. Procedures also relate toeach other. Although they are written as separate documents, they can be assembled into different documentVersion 1.0 eDocumentation™ Plan Phase Page 36 of 56
  • 37. Content Classificationsets for different audiences, providing all the information that is necessary to accomplish their responsibility andtask. 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 screenVersion 1.0 eDocumentation™ Plan Phase Page 37 of 56
  • 38. Content Classification 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 typesPolicies, Processes, and Procedures are interdependent, based upon the content contained within each one. Itmay 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 thepurpose 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 aProcedure.Policies can be at an enterprise, location, or department level. Policies should always stand alone. But at thedepartment level, a Procedure will provide the detail to implement the Policy. Be sure that the Policy is notrestated 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 TypeseDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 38 of 56
  • 39. Accessible Policies, Processes, and Procedures Accessible Policies, Processes, and ProceduresAfter creating clear, concise, complete, and correct™ Policies, Processes, and Procedures, the main issuebecomes ‘How will the user quickly and easily locate and access the desired Policies, Processes, andProcedures?’ 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 lackof 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.FactorsAccessibility 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. Accessibilityis dependent on the user behavior and requirements, and cannot be comprised of a stand-alone solution – even ifyou 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?Version 1.0 eDocumentation™ Plan Phase Page 39 of 56
  • 40. Accessible Policies, Processes, and Procedures 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 preparedIf 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, andProcedures; or a web based access for users), it is probably only a matter of time before the technology isavailable.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 40 of 56
  • 41. Accessible Policies, Processes, and ProceduresImplementVersion 1.0 eDocumentation™ Plan Phase Page 41 of 56
  • 42. Usability Factors Usability FactorsUsability relates to designing and developing user-oriented Policies, Processes, and Procedures so that theinformation is easy to access, easy to understand, and is accurate. The documentation is designed with theusers in mind – who will use the documentation, how they will use the documentation, when they will use thedocumentation, and what content they will need.Users want the Policies, Processes, and Procedures to convey the needed information in a manner that is clear,concise, complete, and correct™.Organizations are at different levels of maturity when developing their Policies, Processes, and Procedures.Some organizations have content management systems while others may still use paper documentation.However, usability factors should be utilized to plan for the best solutions, using the current tools, and also to planfor the future. Structure De sig g n itin Wr Usability Te t rm te n ino on log C y OrganizationFactorsThe content of Policies, Processes, and Procedures serves different purposes. Although the subject matter maybe similar, the purpose and objectives of the documentation will drive the content, design, and structure. Thefollowing are the major factors that affect usability. The factors apply to individual documents and also to thecombined Policies, Processes, and Procedures document set. Content Policies, Processes, and Procedures contain specific types of information which encompass the proper level of detail for the various audiences. A user, knowing the type of information that is needed, can determine the type of document that will contain the information. Separating content type into the proper document - Policy, Process, or Procedure - is the first step toward modular writing. Design Design of Policies, Processes, and Procedures is the look and feel of the documentation. The design should be inviting and not cluttered or difficult to scan or read. Some design objectives are the following:Version 1.0 eDocumentation™ Plan Phase Page 42 of 56
  • 43. Usability Factors Headings can be scanned to determine page content. Proper indention for ease of reading. Consistent graphics between documents. Consistent design, color, and text for process maps. Organization Organization starts with categorizing the content of the Policies, Processes, and Procedures. It defines how the information will be compiled into a complete body of work. Organization also determines how the information will be accessed and referenced by different audiences. Different organization is required for different conditions and, therefore, must be flexible. Proper organization of the Policies, Processes, and Procedures will include tables of contents, indexes, cross references, and other tools for access and reference. Structure The structure of Policies, Processes, and Procedures dictates what type of content is in a specific document. In addition, structure dictates the location and order of the information. Headings are used to structure a document and describe the content that is written. For example, each document should have a Heading 1, relating to the major topic, with Heading 2 and Heading 3 containing the subtopics. Because there may be required information for each Policy, Process, and Procedure (i.e., description, owner) the order of the required information must be predictable. The headings reflect the structure of a document and can be used to produce a meaningful outline. Tables of contents are also based on the heading levels. Great care given to the headings will create a meaningful table of contents for users. Consistent structure makes documentation easier to maintain and easier for the users to use. Modular content Modular writing has the basic concept of writing a topic once and using that module in different documents. Policies, Processes, and Procedures topics are usually not included in multiple document types (i.e., marketing, sales, legal), because they are internal documents. Nevertheless, modular writing principles can be used with success and will avoid redundant documentation. Separating content into the proper category of Policy, Process, or Procedure is the foundation for modular content. Establishing standard templates and styles is the next major step in laying the foundation, because it defines the content for the document. Terminology Consistent terminology, used throughout a body of documentation, reduces confusion and mistakes. Using different terms, when referring to a screen, report, process, department, title, etc. requires the user to interpret the meaning of the term. Consistent terminology also greatly benefits the search function, if your company has such capabilities. Writing A simple and concise writing style should be used. Use of excess words or complex wording only causes the users to needlessly review the Policies, Processes, and Procedures.Version 1.0 eDocumentation™ Plan Phase Page 43 of 56
  • 44. Usability Factors Correct and complete Policies, Processes, and Procedures must be correct and complete. While this usability factor may seem obvious, many Policies, Processes, and Procedures are not correct and complete. Legacy documents may not be correct or complete due a number of factors such as age, missing or incomplete content, and lack of verification.User verificationDo not assume to know specifically what your users need. Verify your design and the usability with the users bydoing the following: Form a representative user group. Ask the users to perform a task using the proposed Policy, Process, and Procedure. Observe what the users do, where they succeed, and where they have difficulties with the Policies, Processes, and Procedures. Can they quickly find the information? Can they perform the task, as it is written? Do they like the design of the document?eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 44 of 56
  • 45. Consistent Terms – a Common Language Consistent Terms – a Common LanguageStandardization of terms is established during the Planning phase and expanded throughout theeDocumentation™ Process. Policies, Processes, and Procedures are rift with multiple names to describe or labela single item – departments, systems, job titles, reports, forms, screens, and fields – to name a few. Setting upconsistent terms greatly assists the usability of the Policies, Processes, and Procedures. Confusion is caused forusers when the same report, screen, or process is referred to by multiple terms, causing the users ‘wade through’a myriad of terms. The basic purpose for consistent terms is as follows: Allows the users to more easily reference and comprehend the Policies, Processes, and Procedures, without multiple terms describing the same departments, systems, job titles, reports, forms, screens, fields, and so forth. Returns more comprehensive and meaningful results to the user during searches.In addition, there are secondary purposes for consistent terms: Creates Policies, Processes, and Procedures that easily reference each other. Allows for consistent document properties that allow for correct searches. Allows Policies, Processes, and Procedures to be developed more effectively. Forms a foundation for building a taxonomy.1. DictionarySetting up consistent terms is basically setting up a dictionary. The dictionary contains the codes, terms, keys,and so forth that are used in the Policies, Processes, and Procedures. The dictionary includes the definition,category, source, and owner. The dictionary’s primary purpose is for the Policies, Processes, and Proceduresterms to be consistent between all documents. However, the dictionary has the potential to be used for spellcheck, auto text, taxonomy, and search functions.2. Inconsistent termsWhile technology can handle inconsistent terms for searching, the confusion caused to the users is not addressedby the technology. Therefore, it is the usage of inconsistent terms that must be remedied to enable the users toeffectively use the documentation.Example: You are creating a Procedure to Add a Vendor. The Procedure includes the system screens andProcure to Pay Process. When referring to the system screens, what name will you use? What screen name will you use, if there are multiple screens for the Add a Vendor Procedure, and each screen uses the same name? Will you refer to multiple screens as screen 1 or page 1? If the screen has a number, will you use that number? However, the documentation will not aid the user, if there is not a descriptive name. Will you refer to the screen with the menu path (option 3, 2, 1)?How will the user refer to the screen in all the Policies, Processes, and Procedures? What will the user use for asearch term? Although, a thesaurus can be set up to search for multiple terms for the Add a Vendor screens, thePolicies, Processes, and Procedures should refer to the term using a consistent term. Therefore, while theVersion 1.0 eDocumentation™ Plan Phase Page 45 of 56
  • 46. Consistent Terms – a Common Languagesearch technology may accommodate inconsistent terms, that should not license the use of inconsistent termswithin the Policies, Processes, and Procedures.Now, multiply the number of terms used in Policies, Processes, and Procedures, and you can see the magnitudeof the problem.3. SourceTerms will have a source and should have an owner. The owners may be the enterprise, department, orDocumentation developer. Usually when starting to write, the Documentation developer will determine the nameof components with the documentation. There are many enterprises that have established dictionaries,specifically those that produce technical documentation. However, when you address Policies, Processes, andProcedures, this effort may not be viewed as critical, and thus not established. When you start to standardizeterms for Policies, Processes, and Procedures, determine the following: Determine if there is an existing taxonomy for the enterprise or a group that oversees taxonomies. Then you may adopt what has been established. Determine if the enterprise has a dictionary for standardized terms for departments, job titles, etc. If not, there may be a conflict between terms used between multiple areas. For example, Human Resources may have a set of standard job titles (Analyst 2), but a department may use their own job titles (AP Processor). Determine if locations have standardized their terms. Locations, especially global locations, may have different terminology. Determine if the locations require different terms. If a location has standard terms, you may adopt what has been established. Determine if departments have standardized their terms. If a department has standard terms, you may adopt what has been established. Determine if there are conflicting standards between the enterprise, locations, and departments. Record all standardized terms in a dictionary and make them available to other departments and Documentation developers. The dictionary should be web based. When multiple departments and developers begin to use and contribute to the dictionary, a process will need to be in place so that all can reference and contribute to the dictionary.Policies, Processes, and Procedures terms are internal terms, as opposed to terms that may be used externally,(for example, customer terms). Differentiate between enterprise terms and internal terms that are used forPolicies, Processes, and Procedures.As you establish consistent terms and the dictionary, create a table that categorizes the types of terms, source,and owner.Version 1.0 eDocumentation™ Plan Phase Page 46 of 56
  • 47. Consistent Terms – a Common Language Term category Source Owner Acronyms Department Process owner Abbreviations Department Process owner Codes Enterprise, Department Enterprise, Department, Process owner Compliance Government, Agency Enterprise Data elements names Department Process owner Department names Enterprise Enterprise Form names Department Process owner Job titles Enterprise Enterprise Keys IT Enterprise Legal Legal Legal Location names Enterprise Enterprise Process names Enterprise Process owner Procedure names Enterprise Process owner Report names Department Report owner System names Department System owner System screen names Department System owner Part names Enterprise Enterprise Product names Enterprise Enterprise Product components Enterprise EnterpriseVersion 1.0 eDocumentation™ Plan Phase Page 47 of 56
  • 48. Consistent Terms – a Common Language4. SearchStating the obvious, there are many search engines available with different levels of robustness. You will, mostlikely, have no input into what your company selects and uses. However, you can maximize the results for thePolicies, Processes, and Procedures by establishing and implementing consistent terms. The result of a searchdepends upon the robustness of the search engine and the consistency of the term. The topic of this paper isTerm consistency - not Selecting a search engine. We will address the factors that you can influence and beresponsible for. Document content A search is also performed on the content or text contained in Policies, Processes, and Procedures. The document is searched for the word or phrase that was entered. The results of the search depend upon how robust the search engine is. This type of search emphasizes the need for consistent terms. You may, literally, receive back those documents that contain the exact phrase - depending upon other factors. The following example displays documents that contain different spelling and abbreviations for Accounts Payable. Although many documents relate to the Accounts Payable Process, only those that match the input word or phrase are selected. Users will quickly become discouraged, if they cannot find the proper document. Different terms for Different documents Search for Acct Pay, Accounts Payable use the different terms displays one document Accounts Accounts Payable Payable Act Pay Act Pay Act Pay Act Pay AP AP Procure to Pay Procure to Pay PayablesVersion 1.0 eDocumentation™ Plan Phase Page 48 of 56
  • 49. Consistent Terms – a Common Language Metadata Metadata is data about a document. Information about a document is set up as the document properties. The properties or metadata give vital information about the documents. Usually you are able to customize the properties to include metadata that is critical (i.e. based on legal requirement). You are then able to search for documents based on classification rather than content. The metadata must also be consistent (for example, use of pull down menus) in order to have access to all documents that match. The document properties contain such information as the following: Title Subject Document type Legal requirement Controls Author Company Department Owner Manager Date created Date modified Review date Expiration date Metadata = Procedure is not Different documents Search for Procedure. Document type consistent use the different terms Two of four documents for Procedure display Work Policy Procedure Instruction Procedure Work Instruction Procedure Procedure Procedure Procedure Process map Proc Procedue Process AP Procedue description Proc Checklist DictionaryVersion 1.0 eDocumentation™ Plan Phase Page 49 of 56
  • 50. Consistent Terms – a Common Language5. Developing consistent termsEstablishing enterprise standardized terms and a taxonomy is an enterprise initiative. Because it is vital to thePolicies, Processes, and Procedures, it must be addressed and may fall, according to others, outside the scope ofdeveloping documentation. However, if there are not standardized terms available within your enterprise, theDocumentation will not be clear, concise, complete, and correct™. Therefore, the Documentation developer muststandardize terms that will be used in the Policies, Processes, and Procedures; if the documentation is part of alarge project, preferably the terms will be standardized within the entire project. However, use caution so thatperforming the task of setting up consistent terms does not turn into a project of standardizing enterprise terms.In order to receive the full benefits of search capabilities, standardized terms are required. Inconsistent Terms Departments Users Forms Accounts Payable Sr. AP Analyst Check Current A/P Acting AP Manager Payment Inconsistent Acct. Pay AP Processor Wire Terms Wire Transfer Applications Policies and Procedures AP System Monthly Review Mgr Payable System Remittance Option 32 AP Menu AP Main Menu AP Shared Service Center Policies and Procedures Accounts Payable Consistent AP Processor Phase 1: Terms Payment Develop Option 32 AP Menu Consistent Terms Metadata: Taxonomy Tag Document  Document Type  Department  Responsibility  Review Date  System Phase 2: Search  Form Develop Taxonomy  Procedure  Accounts Payable  PaymentVersion 1.0 eDocumentation™ Plan Phase Page 50 of 56
  • 51. Consistent Terms – a Common Language Established terms Determine if there is an existing taxonomy for the enterprise or a group that oversees taxonomies. If a taxonomy exists, then you may adopt what has been established. Caution - there is much effort and study that comprises an enterprise taxonomy. Documentation developers should be aligned and consult with the group to maintain the taxonomy standards. If a taxonomy does not exist or is limited, begin standardizing the terms that are used while developing Policies, Processes, and Procedures. Record all standardized terms in a dictionary and make it available to other departments and Documentation developers. The dictionary should be web based. When multiple departments and developers begin to use and contribute to the dictionary, a Process will need to be in place so all terms are consistent. Guidelines The following are guidelines when establishing and setting up consistent terms: 1. Determine the types of terms. 2. Determine the source of information. a. Enterprise b. Department c. Legal or Compliance d. Standards dictionary e. Legacy Policies, Processes, and Procedures f. Application screens g. Reports h. Forms i. Enterprise web site j. Enterprise portal k. index, table of contents, notes 3. Determine who owns the information. a. Taxonomy group b. Enterprise c. Department d. User e. Legal (government, agency) f. None 4. Determine if the term will change.Version 1.0 eDocumentation™ Plan Phase Page 51 of 56
  • 52. Consistent Terms – a Common Language a. Is it a legacy term? b. How does the user refer to the term? c. Is this a legal term? 5. Review terms with the users and gain their approval Format Setting up consistent terms includes establishing a format for the term. What case is used for the term? Sentence case, all caps? What is the order of the words? Is the term lengthy to read? Is the term lengthy or complicated to input? Is the term understandable? Maintenance guidelines Determine who will maintain the dictionary. There must be a Process to add and review terms. Having workflow and a web based list is critical to success. Use the authoring tool to input the terms so that each term does not have to be retyped. For example, with MS Word ® you can use auto correct (tools -> auto correct options) to input terms that can automatically be inserted in a document. When you update legacy documentation, attempt to update the terms to the standards that are being established. This effort will gradually standardize the terms for the Policies, Processes, and Procedures of specific departments, systems, and so forth.eDocumentation™ Process phasePlanVersion 1.0 eDocumentation™ Plan Phase Page 52 of 56
  • 53. Soft Skills Soft SkillsSoft skills complement hard skills, which are the technical requirements of a job. Soft skills are a key requirementduring the eDocumentation™ Process. They are especially important for users, technical staff, and managementduring the following phases: Planning Content research Testing Training ImplementationMany people with specialized knowledge, skills, and experience are working together. Creating and maintainingPolicies, Processes, and Procedures involve a large degree of interaction between team members during thedocumentation Process.What are team soft skills?The soft skills of a team are instrumental in producing a dynamic and successful eDocumentation™ Process.Soft skills are closely related to each other. The team members, who develop and practice such skills, will beproud of the Policies, Processes, and Procedures they have produced.Soft skills needed during the eDocumentation™ Process are as follows: Communication skills Policies, Processes, and Procedures are communications in a written form. In order to write clear, concise, complete, and correct™ Policies, Processes, and Procedures, team members must be able to research and understand the information, before writing begins. This process requires communication skills, which are needed and required during the eDocumentation™ Process. Collaboration Collaboration is the working skillfully and enthusiastically together with others and sharing information. It is a commitment that is required of a team for completing a successful project. Team members must be willing to share information. Solutions can be found and potential problems can be solved only if information is shared. Participation A team must have members who participate. A team is strong and productive if members have the time available to actively participate. Strong teams are comprised of individuals who value their place on the team and are proud of the team’s accomplishments. Leadership Leadership must be provided during a project. Although all team members are not project leaders, members are on the team for their expertise and for a specific purpose. It is imperative that members demonstrate leadership when it is needed.Version 1.0 eDocumentation™ Plan Phase Page 53 of 56
  • 54. Soft Skills Responsibility Responsibility encompasses many attributes - honesty, dependability, and accountability. Team members must be accountable for their decisions. It is beneficial if a person can see and admit errors and then correct them. In a highly political environment this can be a difficult trait to always abide by. However, it is needed and welcomed on complex projects. Flexibility Events can become harried on any project, even with the best project management. During certain phases of the project, and with impending deadlines and deliverables, flexibility is required to support other team members, shift requested priorities, and assist with unforeseen tasks. Team members, who complain and are not flexible, add to the problem. This trait is not to be confused with the natural upsets that result from bad planning and poor project management. Listening skills Team members must listen, without preconceived ideas, when performing research. Members are able to ask questions and clarify answers or refer the question to another member for help only if they listen. Team members, who listen carefully, pick up on potential problems and issues. Users quickly recognize a member who is not listening. Users then lose confidence in the project and question whether their needs will be addressed. Questioning skills Questioning goes hand-in-hand with listening. How is research performed without asking questions? How is a process performed without asking questions? The adage ’There is no such thing as a dumb question’ applies. The complement to asking the question is answering the question. If any form of intimidation is used to suppress the asking of questions, knowledge and expertise, to some degree, are compromised and the correct information will not be attained. Problem solving Problem solving is a thought process. A problem must be viewed from the macro and micro levels. Team members must have a straight-forward view of a problem in order to see its complexity. Team members must be organized and analytical in order to view the possibilities, consequences, and outcome of any solution. Simply solving a problem can create countless other problems, both in the short term and the long term, if the proper solution is not discovered. The team members must know when to contact another member for guidance and information. They must not rely only on their own knowledge and expertise. It is important for the members to know what they do know and what they do not know, before solving complex problems. Research Research requires multiple soft skills. The ability to conduct effective research is a combination of listening, questioning, self motivation, and problem solving skills. Training and teaching skills Project team members are required to train other members, ensuring their understanding of a specific issue or area.Version 1.0 eDocumentation™ Plan Phase Page 54 of 56
  • 55. Soft Skills Work under pressure All projects will cause pressure and stress at some point. A team member should be able to handle the pressure and stress with a light sense of humor and not become angry or overly aggressive, whereby the entire team is adversely affected. Team members should be supportive and assist the team member to solve the problems that are causing undue stress. Diligence Hard-working team members are diligent. Working hard is not a synonym for ‘workaholic’. Diligent team members have the following abilities: Excellent time management skills Organized work habits Effective planning skills Practical prioritization of work Self motivation Self-motivation is a personal attribute. It is not a trait that can be enforced. A self-motivated person has purpose and goals. The self-motivated team member wants the project to succeed and pursues that goal. That member will not accept defeat easily. Self-motivated team members accomplish the following: Meet their deadlines Ensure their research is complete and correct Verify their recommendations are correct and sound Meet their responsibilities and deadlineseDocumentation™ Process phaseIntroductionVersion 1.0 eDocumentation™ Plan Phase Page 55 of 56
  • 56. Knowledge Process, Inc. Knowledge Process, Inc.About Knowledge ProcessKnowledge Process provides services and expertise for the research, development, and validation of Content andDocumentation for Policies, Processes, and Procedures. For more information, contact: Knowledge Process Web: http://www.DocumentationProcess.comCopyright ©2009-2012 by Knowledge Process, Inc. All rights reserved Use of this site/document indicates approval and acceptance of our Terms of Use and Privacy PolicyVersion 1.0 eDocumentation™ Plan Phase Page 56 of 56