User Documentation Development Life Cycle (UDDLC)

WWW.ALMAHACONSULTING.CA User Documentation Development Life Cycle (UDDLC) STANDARD OPERATING PROCEDURE BUSINESS PROCESS DOCUMENT DOCUMENT STATUS: VERSION 0.1 Department BUSINESS TRANSFORMATION Process Owner Authorized By Issue Date 10/28/2017

CONTENTS 1 Objectives of the Business Process... 4 2 The Approach... 5 3 The Scope... 6 4 Business Rules... 7 4.1 User Documentation Estimates... 7 4.2 User Documentation Resource Allocation... 7 4.3 User Documentation Creation and Updates... 7 4.4 User Documentation Descriptions... 8 4.5 User Documentation Peer Review... 8 4.6 User Documentation Technical Review... 8 4.6.1 BA Technical Review... 9 4.6.2 Tester Technical Review... 9 4.6.3 Conditional Technical Review Sign-Off... 9 4.7 Change Requests to Original User Documentation... 10 4.8 User Documentation Publishing... 10 4.8.1 Special Branch Draft Publication... 10 4.9 User Documentation Integration and Maintenance... 11 4.10 UDDLC Compliance and Alignment with the SDLC... 11 5 UDDLC PROCESS OVERVIEW... 12 6 UDDLC Pre-Documentation Phase... 14 6.1 UDDLC Pre-Documentation Phase Procedural Outline... 14 6.2 UDDLC Pre-Documentation Phase Process Flow... 16 7 UDDLC Documentation Phase... 18 7.1 UDDLC Documentation Phase Procedural Outline... 18 7.2 UDDLC Documentation Phase Process Flow... 20 8 UDDLC Post-Documentation Phase... 22 8.1 UDDLC Post-Documentation Phase Procedural Outline... 22 8.2 UDDLC Post-Documentation Phase Process Flow... 23 9 Process Metrics (KPIs)... 24 10 Process Improvement Recommendations... 26 STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 2

Document Information Release No. Version 0.1 Release Date 10/28/2017 Document Title User Documentation Development Life Cycle (UDDLC) Reference BUSINESS PROCESS REENGINEERING LIBRARY Revision History VN Date Remarks Authored/Revised By V0.1 10/28/2017 1 st draft of the User Documentation Development Life Cycle (UDDLC) STANDARD OPERATING PROCEDURE. Approvals Name Role Original Approval Date: Click here to enter a date. Contribution/Review List Name of person who reviewed and/or contributed to the deliverable Role Distribution List Name of person(s)/entities who received copy of final deliverable Glossary and Acronyms Term Meaning SMERC Subject Matter Expert Review Committee SDLC Software Development Lifecycle PMLC Project Management Lifecycle RFS Request for Service RFE Request for Estimate RFR Request for Resource SRS Software Requirements Specification document SDD Software Design Document BRQ Business Requirements document ACC Acceptance Testing UAT User Acceptance Testing BA Business Analyst TA Technical Analyst PM Project Manager, Project Management STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 3

1 OBJECTIVES OF THE BUSINESS PROCESS The User Documentation Development Life Cycle (UDDLC) is used to formally identify and document the stages involved in user documentation creation and completion based on requests coming through the Subject Matter Expert Review Committee (SMERC), from Intake/SMERC estimations and RFS resourcing through development and maintenance of the completed and published documents. The User Documentation Development Life Cycle (UDDLC) also provides a clear and well-defined methodology for software user documentation, which includes measurable benchmarks and timeframes to monitor progress, and which aligns the software user documentation development lifecycle with the different stages of the Software Development Life Cycle (SDLC) from the inception phase, business and functional requirements analysis and walkthroughs, all the way through testing and system deployment. The User Documentation Development Life Cycle (UDDLC) includes a step-by-step process to user documentation creation, and offers a mechanism for checking quality and accuracy, and making corrections and adjustments at several phases throughout the user documentation development associating benchmark timeframes within each procedure of the documentation development process. The UDDLC dramatically increases the opportunity for client satisfaction and successful and timely completion of the user documentation. The User Documentation Development Life Cycle (UDDLC) focuses on the procedural steps within each process phase of the lifecycle, when and how each procedure is carried out. The process also relies on SMERC s policy guidelines and procedures as the precursor for implementing this process. For each of the procedures and activities listed in the lifecycle phases, the UDDLC highlights who is responsible for performing the procedure, when the procedure should be completed, and the required documentation. The User Documentation Development Life Cycle (UDDLC) forms an integral part of software development and therefore should be used in conjunction with the Software Development Life Cycle (SDLC), as both are parallel as well as intertwined. Where improvement opportunities have been identified, these were recorded as either Key Business Process Improvements (BPI) or Longer Term (LT) Improvement Opportunities. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 4

2 THE APPROACH To map and document the User Documentation Development Life Cycle (UDDLC) STANDARD OPERATING PROCEDURE, the consultants reviewed supporting documentation for the RFS and user documentation requirements and benchmarked against best practices in software development and technical documentation alignment, which provided further insights into the development, publication and maintenance of project-based user documentation. INPUTS ACTIVITIES OUTPUTS SMERC procedures Existing documentation procedures SDLC PMLC Review existing analysis and documentation E2E User Documentation Development Life-Cycle (UDDLC) "Pre-Documentation Phase" Sub- Process "Documentation Phase" Sub- Process Benchmarking and process validation walkthroughs "Post-Documentation Phase" Sub- Process P r o c e s s D o c u m e n t a t i o n STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 5

3 THE SCOPE The following end-to-end process and (3) sub-processes were documented by the consultants E2E User Documentation Development Life-Cycle (UDDLC) "Pre-Documentation Phase" Sub-Process "Documentation Phase" Sub-Process "Post-Documentation Phase" Sub-Process The User Documentation Development Life Cycle (UDDLC) STANDARD OPERATING PROCEDURE is designed to assist the Documentation Services Team in managing all aspects of projectbased user documentation development, related to SMERC requests during the pre-documentation, documentation, and post-documentation phases, ensuring efficient and quality document creation. It DOES NOT INCLUDE The Documentation Helpdesk Support Requests (DHDSR) Business Process, related to receiving, assessing, scheduling, processing, and completing documentation requests through first, second, and third level support and five-state workflow, which is outside the SMERC scope. As part of the implementation of the User Documentation Development Life Cycle (UDDLC), monthly assignment reports and release-based user documentation status reports will be generated and uploaded to MS SharePoint. These reports will be updated on a regular basis to monitor and track each step of the user documentation development. The reports information breakdown allows the Documentation Team to review their respective documentation activities to ensure that the final deliverables will meet or exceed expectations, and allows the Documentation Team-Lead to measure and monitor user documentation development progress and constraints, in terms of time and quality ensuring that all work involved in creating user documentation is identified, and roles and responsibilities are established. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 6

4 BUSINESS RULES This summary highlights the business rules relevant to the implementation of the User Documentation Development Life Cycle (UDDLC). 4.1 User Documentation Estimates L0 (ballpark) Estimates are based on the RFE and the solution provided by the Software Development Team. L1 Estimates update is based on the Level1/Level2 approved BRQ Document. L2 Estimates update is based on the Level1/Level2 approved SRS Document. L3 Estimates update is based on the Level1 approved SDD document. 4.2 User Documentation Resource Allocation User documentation resource allocation is dependent on the release schedule including the ACC Date and the release number as well as the Testing Team s resources estimated start and end dates to allow enough time for the Technical Review Team (BA and Testing) to review and approve the RFS user documentation. When assigning user documentation resources to an RFS, the Resource Manager will send a task assignment notification email, in accordance with the User Documentation Email Draft Template, which includes the estimated work effort days, expected documentation dates, and the Testing team s scheduled dates. The expected documentation dates are also added to the PM Tool notes under the Documentation Stage. Intake must take into consideration user documentation resource constrained scheduling. This helps to ensure that user documentation for a particular RFS is planned in tandem with BA, Development, and Testing Teams work scheduling, and that the tasks for user documentation are incorporated early into the work breakdown and schedule of the RFS project. Failure to do so results in delayed delivery of the user documentation until the scheduled ACC Date or later and/or poor quality documentation that is rushed at the last minute. 4.3 User Documentation Creation and Updates The user documentation is created and/or updated based on the latest Level1/Level2 approved SRS document and the Level1 approved SDD Document. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 7

In case of changed SRS and SDD, the user documentation Author must be notified by email, and the revised SRS and SDD must be signed off with the appropriate approval level in the PM Tool. 4.4 User Documentation Descriptions Suggested user documentation descriptions for RFS releases assigned to the user documentation Author must be sent by the Author, via email, to the PM, BAs, and the Release Management Team, (4) weeks before the ACC Date, in accordance with the RFS Descriptions Template. In which case, the onus is on the assigned BA to ensure that the descriptions in the PM Tool are updated by the date indicated in the RFS Descriptions Email Draft. 4.5 User Documentation Peer Review User documentation peer review involves reviewing the user documentation draft by the user documentation Peer Reviewer to identify defects and correct shortcomings in areas related to using the appropriate user documentation template, correct file-naming convention, placing images correctly, adherence to the Documentation Team Style Guide, correct grammar and spelling, among others, as maintained in the User Documentation Update and Integration Checklist. It DOES NOT INCLUDE technical review, which is performed by the business analyst(s) and tester(s) assigned to the respective RFS. The user documentation Peer Reviewer reviews the source files and the Integration Notes, NOT the PDF version. The user documentation Author will request for peer review and approval, via email, using the User Documentation Peer Reviewer Email Draft Template. After the user documentation has passed the peer review, the approved user documentation draft must be uploaded to the External Review Folder on MS SharePoint, and a note must be added to the PM Tool, indicating that the document is peer-review approved. 4.6 User Documentation Technical Review User documentation technical review involves reviewing the technical content of the user documentation by the technical teams business analysts and testers to verify that the technical information conveyed in the user documentation is correct and accurate. The user documentation Author will request for technical review (BA/Testing) and approval, via email, using the User Documentation Technical (Tester/BA) Reviewer Email Draft Template. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 8

The Technical Review Team must sign off the final approved RFS user documentation, uploaded to the PM Tool, with Level1/Level2 approval maximum by noon Thursday for publications scheduled for Fridays, or by noon Monday for publications scheduled for Tuesdays. The Technical Review Team will notify the user documentation Author, via email, when each Level approval has been granted. This will ensure that enough time is allocated for the Publishing Team to review the final draft prior to publishing. In which case, Level1 Approval is provided by the Tester and Level2 Approval is provided by the BA. 4.6.1 BA TECHNICAL REVIEW BA Technical Review includes, but is not limited to the following: Ensuring that the user documentation introduction is based on the Purpose section of the SRS document. Ensuring that any special module requirements are documented. Ensuring that concepts, selection criteria, and business definitions of fields i.e., functionalities visible to the client are documented and in line with the SRS. 4.6.2 TESTER TECHNICAL REVIEW Tester Technical Review includes, but is not limited to the following: Ensuring the content of the user documentation is accurate and complete in terms of prerequisites and setup. Ensuring the content of the user documentation is accurate and complete in terms of screens, reports, job functions, interface files, web services, and online help tasks steps and results. Ensuring the content of the user documentation is in line with the test results. 4.6.3 CONDITIONAL TECHNICAL REVIEW SIGN-OFF The user documentation Author assigned to an RFS that has only conditional testing sign-off must request direction from the RFS sponsor and PM, via email, on how to proceed using the User Documentation with Conditional Testing Sign-Off Email Draft Template. A note must be added to the PM Tool stating that the user documentation was granted conditional testing sign-off only, to indicate that the user documentation did not pass full technical review due to incomplete testing. Any changes to a user documentation that is published with conditional testing sign-off will be treated as a Revised User Documentation, following the DHDSR business process. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 9

4.7 Change Requests to Original User Documentation Change Requests to an original user documentation BEFORE it was published to clients: A Change Request to an original user documentation before it was published to clients will be documented as part of the original RFS, following the normal UDDLC. Change Requests to an original user documentation AFTER it was published to clients: After the user documentation has been published, any requested change to this user documentation will be treated as a documentation request outside the UDDLC, following the DHDSR business process. 4.8 User Documentation Publishing The user documentation Author must send the publication notification to the Publishing Team in accordance with the User Documentation Update and Integration Checklist and the Ready for Publication Notices Email Drafts. The publication email notification must be received by the Publishing Team latest by 3PM Thursday for publications scheduled for Fridays, or by 3PM Monday for publications scheduled for Tuesdays. RFS user documentation scheduled for interim release will be published on the interim ACC Date. The Publishing Team will generate a User Documentation Release Status Report and will upload it to the Extranet (1) day before Core Publication Date. The user documentation will be published to the clients in accordance with the Publication Checklist of the respective product release. The User Documentation Repository on MS SharePoint must be updated with links to the updated user documentation, in accordance with the Publication Checklist. 4.8.1 SPECIAL BRANCH DRAFT PUBLICATION User documentation deployed to client UAT without undergoing our company s testing, or while our testing has not yet completed, will be published as special branch draft user documentation and will include a header page with a disclaimer and a DRAFT watermark. The draft user documentation will be published officially to the rest of the clients, as part of the next official release, only if the testing has been conducted and completed on the RFS development and associated user document. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 10

4.9 User Documentation Integration and Maintenance Integration of the user documentation into the product guides (user guides and catalogues) and online help files will be carried out within two weeks from the ACC date, in accordance with the Integration Notes and the User Documentation Update and Integration Checklist. Late and revised user documentation will be integrated within two weeks from the publication date. Publication of the Online Help and the PDF Guides will be carried out within the third week from the ACC Date, in accordance with the Publication Checklist. The User Documentation Repository will be updated with links to the updated PDF guides, in accordance with the Publication Checklist. 4.10 UDDLC Compliance and Alignment with the SDLC Full compliance to the User Documentation Development Life-Cycle must be maintained at all times to ensure accurate, consistent, current, and accessible user documentation and full accountability during all phases of the user documentation development. The UDDLC must be aligned with the SDLC throughout the main stages of the software development, from the business and functional requirements analysis and design, through testing, deployment and acceptance testing. This will ensure that frequent enhancements, corrections, and change requests that are made to the system are also reflected on the corresponding user documentation to keep the deliverables up-to-date according to the client and market requirements. To help improve the technical accuracy of the user documentation produced by the documentation team and to enable them to delve deeper into the employed technology, the documentation team should be: Involved in the business requirements, functional requirements, technical specifications, and functional testing walkthroughs and subsequent revisions and meetings allowing them to become hands-on with the product being developed; Included in any Development, BA, and Testing group mailing lists, with respect to changes and updates to RFS related product development. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 11

5 UDDLC PROCESS OVERVIEW END-TO-END USER DOCUMENTATION DEVELOPMENT LIFE-CYCLE Pre-Documentation, Documentation, and Post Documentation Phases OVERVIEW PROCESS REMARKS The User Documentation Development Life Cycle (UDDLC) is broken into three main phases, as follows: PRE -DO CUM ENT ATION PH ASE: This phase starts when a Request for Estimate is received by SMERC. NOTE: The RFE is either for an internal Client (internal development initiative) or for an External Client. SMERC Meeting is set up, during which the SMEs review the RFE and discuss high level solution and work effort estimates. All SMEs are requested to provide their L0 estimates. The Documentation Team-Lead provides user documentation L0 Estimates based on the RFE and the solution provided by the Development Team. Once the RFE and L0 Estimates are approved, Work Intake sends out resource requests, via email. The Resource Manager adds the user documentation resources to the PM Tool after Testing team has added their resources. The Assigned User Documentation Author provides L1 L3 Estimates based on the developed and approved BRQ, SRS, and SDD documents respectively. NOTE: Variations in the estimates must be explained and justified. The assigned User Documentation Author reads through the SRS document and the SRS/SDD cross reference section of the SDD document to analyse the software requirements, and if necessary, corresponds and meets with the BA and the TA teams. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 12

END-TO-END USER DOCUMENTATION DEVELOPMENT LIFE-CYCLE Pre-Documentation, Documentation, and Post Documentation Phases OVERVIEW PROCESS REMARKS DOCUM ENT ATION PH ASE : This phase starts with the creation of the user documentation s first draft. The User Documentation Author creates the first draft and then requests for Peer review and approval. The Peer Reviewer performs peer review against a set of criteria, ensuring adherence to the Documentation Team Style Guide, and Documentation Checklist. The Author makes the necessary changes, reported from the Peer Review, and then sends back for peer review and approval. The peer-review approved draft is uploaded to the External Review folder on MS SharePoint. The Author requests for technical (BA/Tester) review and approval, via email. The Technical Review team reviews the draft user documentation against the SRS and SDD documents and the testing results The Author revises the draft according to the Technical Review feedback, then sends back for technical review and approval. Upon completion of the technical review, the Author is notified that the draft is ready for L1/L2 Approval. The Author uploads the user documentation to the PM Too for L1/L2 Approval. Once approved, sends an email notification to the Publishing Team. POST- DO CUM ENT ATION PH ASE: This phase starts with the publication of the RFS user documentation. The Publishing Team generates and posts the user documentations to the Extranet site. The Author integrates the user documentation into the PDF guides and online help files. The final step includes publishing the online help files and the PDF guides and updating the User Documentation Repository with links to the updated user documentation and the PDFs. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 13

6 UDDLC PRE-DOCUMENTATION PHASE 6.1 UDDLC Pre-Documentation Phase Procedural Outline DESCRIPTION RESPONSIBILITY The Pre-Documentation Phase outlines the steps and procedures involved in assessing, estimating, scheduling and managing user documentation requests coming through SMERC. This includes reviewing RFEs, discussing high level software development and providing L0 work effort estimates, resourcing and scheduling, BRQ document development and walkthrough meeting, L1 Estimates, SRS document development and walkthrough meeting, L2 Estimates, SDD document development and walkthrough meeting, L3 Estimates, analyzing and understanding the software requirements specifications, and meeting with the technical teams to understand the impact on the user documentation. SMERC/Work Intake; SMEs/RFS Stakeholders; BA Team; PM; Documentation Team-Lead; Resource Manager; User Documentation Author. It is the responsibility of SMERC/Work Intake to set up SMERC Meeting and to invite all RFS stakeholders, via email, to review the RFE and discuss high level development solution, in accordance with SMERC/Work Intake policies and procedures. It is the responsibility of all SMEs to meet and discuss high level software development and L0 work effort estimates. It is the responsibility of the Documentation Team-Lead to provide user documentation L0 Estimates, based on the RFE and the solution provided by the Development Team. It is the responsibility of Work Intake to send the resource request to all RFS stakeholders, via email, once the L0 estimates have been approved by the Client. It is the responsibility of the Resource Manager to add User Documentation Resources to the PM Tool and to send a task assignment notification email, in accordance with the User Documentation Email Draft Template. It is the responsibility of the BA Team to develop the BRQ document and to set up a walkthrough meeting and invite all RFS stakeholders, via email. It is the responsibility of the BA Team and the RFS stakeholders to meet and discuss the BRQ document during the BRQ walkthrough, to understand the business requirements of the proposed solution. It is the responsibility of the PM to request for the L1 Estimates, via email, from all RFS stakeholders after the BRQ document has been L1/L2 approved in the PM Tool. It is the responsibility of the User Documentation Author to provide L1 Estimates, updated from the L0 Estimates. It is the responsibility of the BA Team to develop the SRS document and to set up a walkthrough meeting and invite all RFS stakeholders, via email. It is the responsibility of the BA Team and the RFS stakeholders to meet and discuss the SRS document during the SRS walkthrough, to understand the software requirements specifications. It is the responsibility of the PM to request for L2 Estimates, via email, from all RFS stakeholders after the SRS document has been L1/L2 approved in PM Tool. It is the responsibility of the User Documentation Author to provide L2 Estimates, updated from the L1 Estimates. It is the responsibility of the TA/Development Team to develop the SDD document and to set up a walkthrough meeting and invite all RFS stakeholders, via email. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 14

WHEN TO COMPLETE ASSOCIATED DOCUMENTS It is the responsibility of the TA/Development Team and the RFS stakeholders to meet and discuss the SDD document during the SDD walkthrough, to understand the software design descriptions. It is the responsibility of the PM to request for L3 Estimates, via email, from all RFS stakeholders after the SDD document has been L1 approved in the PM Tool. It is the responsibility of the User Documentation Author to provide L3 Estimates, updated from the L2 Estimates. It is the responsibility of the User Documentation Author to study the SRS document and the SRS/SDD Cross Reference Section of the SDD document, as well as all other related reference material, and to explore the application s environment to understand its various features, and to gather more information as needed from the BA and the Development teams, through meetings and queries. When SMERC receives a Request for Estimate (RFE), all SMEs meet to review the request and discuss high level development solution and L0 Estimates. When the Development Team provides their L0 Estimates, the Documentation Team-Lead provides user documentation L0 Estimates. After receiving the Resource Request and after the Testing Team has assigned and scheduled resources, the Resource Manager assigns the user documentation resources in the PM Tool and notifies the assigned resources accordingly. When the BRQ is L1/L2 approved, the PM requests for L1 Estimates from all RFS stakeholders. When the PM requests for the L1 Estimates, and the BRQ document has been L1/L2 approved, the User Documentation Author provides user documentation L1 Estimates, updated from the L0 Estimates. When the SRS is L1/L2 approved, the PM requests for L2 Estimates from all RFS stakeholders. When the PM requests for the L2 Estimates, and the SRS document has been L1/L2 approved, the User Documentation Author provides user documentation L2 Estimates, updated from the L1 Estimates. When the SDD is L1 approved, the PM requests for L3 Estimates from all RFS stakeholders. When the PM requests for the L3 Estimates, and the SDD document has been L1 approved, the User Documentation Author provides user documentation L3 Estimates, updated from the L2 Estimates. When the SRS and SDD documents have been developed, uploaded and approved in the PM Tool with the appropriate approval level, the User Documentation Author studies the SRS document and the SRS/SDD Cross Reference Section of the SDD document. SMERC Agenda; SMERC/Work Intake Policies and Procedures; Request for Estimates (RFE); L0 Estimates; L1 Estimates; L2 Estimates; L3 Estimates; Resource Request; BRQ Document; SRS Document; SDD Document; Existing User Documentation Material. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 15

6.2 UDDLC Pre-Documentation Phase Process Flow STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 16

STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 17

7 UDDLC DOCUMENTATION PHASE 7.1 UDDLC Documentation Phase Procedural Outline DESCRIPTION RESPONSIBILITY The Documentation Phase outlines the steps and procedures involved in developing and reviewing user documentation. This includes developing the user documentation s first draft and sending it for peer review and approval, making changes reported from the Peer Review, uploading the peer review-approved documentation draft to the External Review folder on MS SharePoint, requesting for technical (BA/Testing) review and approval, incorporating the technical review s feedback and comments into the user documentation s final draft, uploading the technical review approved draft to the PM Tool, signing off the technical review approved draft with L1 and L2 approval in the PM Tool, and sending the publication notification email to the Publishing Team. User Documentation Author; User Documentation Peer Reviewer; Technical Review (BA/Testing) Team. It is the responsibility of the User Documentation Author to create the user documentation s 1 st draft based on the L1/L2 approved SRS and the L1 approved SDD and to request for peer review and approval, via email, using the User Documentation Peer Reviewer Email Draft Template. It is the responsibility of the User Documentation Peer Reviewer to perform peer review on the draft user documentation, ensuring adherence to the Documentation Team Style Guide, and the User Documentation Update and Integration Checklist. It is the responsibility of the User Documentation Author to revise and edit the draft user documentation, according to the peer review s comments and feedback, and to send the modified draft back for peer review and approval. It is the responsibility of the User Documentation Author to upload the peer-review approved draft to the External Review folder on MS SharePoint, and to add a note to the PM Tool stating that the user documentation has passed the peer review. It is the responsibility of the User Documentation Author to request for Technical Review from the BA and the Tester assigned to the RFS, via email, using the User Documentation Technical (Tester/BA) Reviewer Email Draft Template. It is the responsibility of the Technical Review Team to perform technical review on the draft user documentation, ensuring adherence to the SRS/SDD documents and the testing results. It is the responsibility of the User Documentation Author to revise and edit the draft user documentation, according to the technical review s comments and feedback, and to send it back again for technical review and approval. It is the responsibility of the Technical Review Team to notify the User Documentation Author that the user documentation draft is ready for L1/L2 approval. It is the responsibility of the User Documentation Author to remove the technical review approved draft from the MS SharePoint External Review folder, upload it to the PM Tool, and to notify the Technical Review Team accordingly. It is the responsibility of the Technical Review Team to sign off the user documentation s final approved draft with L1 and L2 Approval in the PM Tool and to notify the User Documentation Author when each level approval has been granted. In which case, L1 Approval is signed off by the Tester and L2 Approval is signed off by the BA. It is the responsibility of the User Documentation Author to send the publication notification email to the Publishing Team, stating that the user documentation has been approved and is ready for publication. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 18

WHEN TO COMPLETE ASSOCIATED DOCUMENTS When the SRS and SDD documents have been signed off with the appropriate approval level, the User Documentation Author creates the user documentation s 1st draft, according to the RFS scheduled dates. After receiving the request for peer review and approval, the User Documentation Peer Reviewer reviews the draft user documentation according to the scheduled peer review. After receiving the peer reviewer s feedback and comments, the User Documentation Author revises and edits the draft then sends the modified draft back for peer review and approval. After the peer reviewer has approved the draft, the User Documentation Author uploads the peer-review approved draft to the External Review folder on MS SharePoint and adds a note to the PM Tool that the user documentation has passed the peer review. After uploading the peer-review approved draft to the MS SharePoint External Review folder, the User Documentation Author requests for technical review and approval from the BA and Tester assigned to the RFS. After receiving the request for technical review and approval, the Technical Review Team reviews the draft user documentation throughout the testing phase. After receiving the technical review team s feedback and comments, the User Documentation Author revises and edits the draft then sends it back for technical review and approval. After approving the draft user documentation, the Technical Review Team notifies the User Documentation Author that the draft is ready for L1/L2 approval. After receiving a notification email from the Technical Review Team that the draft user documentation is ready for L1/L2 Approval, The User Documentation Author removes the final approved draft from the MS SharePoint External Review folder and uploads it to the PM Tool. After receiving a notification email from the User Documentation Author that the final approved draft is uploaded to the PM Tool, the Technical Review Team signs off the final approved draft with L1 and L2 Approval, latest by noon Thursday for publications scheduled for Fridays, or by noon Monday for publications scheduled for Tuesdays. When the user documentation has been signed off with L1/L2 Approval, the Technical Review Team notifies the User Documentation Author. In which case, the Technical Review Team sends a notification email when each level approval has been granted. When the user documentation has been L1 and L2 approved, the User Documentation Author sends a publication notification to the Publishing Team, latest by 3PM Thursday for publications scheduled for Fridays, or by 3PM Monday for publications scheduled for Tuesdays. SRS Document; SDD Document; Existing User Documentation Material; User Documentation s 1st Draft; User Documentation Peer-Reviewed Draft; User Documentation Technical-Reviewed (Final) Draft; User Documentation Peer Reviewer Email Draft Template; User Documentation Technical Reviewer (BA/Tester) Email Draft Template; Ready for Publication Notices Email Draft; Documentation Team Style Guide; User Documentation Update and Integration Checklist. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 19

7.2 UDDLC Documentation Phase Process Flow STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 20

STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 21

8 UDDLC POST-DOCUMENTATION PHASE 8.1 UDDLC Post-Documentation Phase Procedural Outline DESCRIPTION RESPONSIBILITY WHEN TO COMPLETE ASSOCIATED DOCUMENTS The Post-Documentation Phase outlines the steps and procedures involved in publishing and maintaining user documentation, including generating a User Documentation Release Status Report, publishing the user documentation to the appropriate client(s), integrating the user documentation into the PDF guides and the online help files, publishing the PDF guides and the online help files, and updating the User Documentation Repository on MS SharePoint and the Extranet with links to the updated user documentation and the PDF guides. Publishing Team; User Documentation Author. It is the responsibility of the Publishing Team to generate the User Documentation Release Status Report and to upload it to the extranet site. It is the responsibility of the Publishing Team to generate and post the user documentations to the extranet site and to send email notifications to the appropriate client(s), in accordance with the Publication Checklist and the Ready for Publication Notices Email Drafts. It is the responsibility of the User Documentation Author to integrate the published user documentation into the appropriate product guides and online help files, in accordance with the Integration Notes and the User Documentation Update and Integration Checklist. It is the responsibility of the Publishing Team to publish the online help and the PDF Guides, in accordance with the Publication Checklist, and to update the User Documentation Repository on MS SharePoint with links to the updated user documentations and the PDF guides, in accordance with the Publication Checklist. The Publishing Team generates the User Documentation Release Status Report and uploads it to the extranet site one day before the Core Publication Date. After receiving the publication notification, the Publishing Team generates and posts the user documentations to the extranet site and sends email notifications to the appropriate client(s) on the publication day. In which case, the publication notification must be received by the Publishing Team latest by 3PM Thursday for publications scheduled for Fridays, or by 3PM Monday for publications scheduled for Tuesdays. When the user documentation has been published, the User Documentation Author integrates the user documentation into the PDF guides and the online help files within two weeks from the ACC Date, or within two weeks from the publication date for late/revised user documentation. When the user documentation has been integrated into the PDF guides and the online help files, the Publishing Team publishes the PDF guides and the online help within the third week from the ACC Date. In which case, the online help is published by the Tuesday of the third week. After the publication of the user documentation, the Publishing Team updates the User Documentation Repository on MS SharePoint with links to the updated user documentations. After the publication of the PDF Guides, the Publishing Team updates the User Documentation Repository on MS SharePoint with links to the updated PDF guides. Ready for Publication Notice Email Draft; Publication Checklist; User Documentation; User Documentation Release Status Report; Integration Notes; User Documentation Update and Integration Checklist; Online Help Files; PDF Guides; User Documentation Repository. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 22

8.2 UDDLC Post-Documentation Phase Process Flow STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 23

9 PROCESS METRICS (KPIS) KPI KPI FORMULA KPI NATURE FREQUENCY TARGET % of RFS assignments completed within budget Number of RFS assignments completed successfully within +/-30% of their planned allocated effort divided by the total number of RFS assignments. Budget / Efficiency Monthly 85% The planned allocated effort for an assignment will be the allocation in the PM Tool. % of RFS Descriptions delivered within schedule Number of RFS Descriptions delivered within their respective planned scheduled dates divided by the total number of RFS Descriptions planned to be respectively delivered during the reporting period. Effectiveness Per Release 90% Successful delivery implies RFS descriptions are updated in the PM Tool by the BAs. % of user documentation published to clients within schedule Number of user documentation published to clients within their respective planned scheduled dates (on Core date, and before or on ACC date) divided by the total number of user documentation published to clients for each release. Effectiveness Per Release 85% % of user documentation integrated within schedule Number of user documentation integrated into the guides within their respective planned scheduled dates divided by the total number of user documentation planned to be respectively integrated during the reporting period. Effectiveness Per Release 90% Integration completion implies updating the PM Tool and the extranet with the reference Production Guides Change Log. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 24

KPI KPI FORMULA KPI NATURE FREQUENCY TARGET % of guides (PDF and online help files) published within schedule Number of guides (PDF and online help files) published to clients within their respective planned scheduled dates divided by the total number of guides planned to be respectively published to clients during the reporting period. Effectiveness Per Release 90% Publication of the Online Help and the PDF Guides will be carried out within the third week from the ACC Date. Online help files to be provided to GUI team by 3rd week of ACC date and to the clients' environment by the 4th week of ACC date. % of user documentation assignments on green track Number of user documentation assignments on the green track divided by the total number of user documentation assignments during the reporting period. Effectiveness / Project Management Monthly 85% Green-track implies that the user documentation assignment is not at risk of missing estimated end date, even if the assignment did not meet the expected start date. % of user documentation published to clients after completing technical reviews. Number of user documentation passing full technical reviews before publication to clients divided by the total number of user documentation delivered / published to clients. Quality Monthly and Per Release 100% The Technical Review Completion metric is tied to the L1/L2 (Tester/BA) approval stage in the PM Tool. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 25

10 PROCESS IMPROVEMENT RECOMMENDATIONS Identification of Key Business Process Improvements (BPI) and Longer Term (LT) Improvement Opportunities Process Step Recommendations for To-Be State Key BPI LT User Documentation Development Life Cycle (UDDLC) The use of MS SharePoint Workflow or MS Flow to automate the multi-tier review and approval of user documentation, offering all RFS stakeholders a proper audit trail with faster feedback and timely completion through automated notifications when deadlines are fast approaching, and with the ability to add or remove tasks as necessary, and distribute automatic notifications to affected parties when certain steps in the process have been completed. STANDARD OPERATING PROCEDURE STATUS: VERSION 0.1 26