BFMA Forms Management Book of Knowledge - Sec 1 and 2

Forms/Template Design and Development 206 / 349 draft layout sent by the client. Although not as formal an approval, it makes sense for Program staff to confirm the content at this milestone before developing drafts and options for stakeholders to review. Approval by the client, form owner or stakeholders may be communicated:  Via email confirming the list of form elements.  By signing the requirements and specifications approval document.  Via system approval or e-signature. Form’s design and layout with content – In the case of stationery items and forms following a preset design and layout that has actually been pre-approved by the Forms Management Program and executive management when approving the Forms Style Guide and is only applied. Once adapted to the client’s needs, the approval is more about the content displayed rather than the standard design and layout. For more complex forms, the client’s draft serves as a starting point for the developer who will create new

Forms/Template Design and Development 207 / 349 drafts adding and applying other applicable standards, conventions, design, layout, branding, etc. as determined for each output version required before presenting actual form drafts to stakeholders. Once the developer reaches a point where the draft form appears to be final with every form element requested and needed, approval of both the form’s design and layout with the content is obtained for each output version. Files or copies of every output version of the finalized draft form are sent for approval. The approving authority or authorities return their approval:  Via email.  By signing the draft sample copies.  By signing the accompanying approval document.  Via system approval or e-signature. Translations – The approved original form and the one kept on record as the official form (that is, the primary form) is the version sent to translation, with associated documentation. The translator returns a

Forms/Template Design and Development 208 / 349 translated form either in a list of translated form elements or in a similar form design. The forms developer creates a source file of the translated version of the form and generates files for each intended output version, as required. The new draft samples of the translated form are returned to the translator to ensure the form is correct. The translator confirms the form is correct, or makes edits, as necessary. Last edits are applied to the form’s source file and each output version of the translated form’s final draft. Once approved by the translator:  The form is finalized.  Samples of every output versions of the translated draft form are sent for approval to stakeholders. This is often a formality since approvers may not understand the other language. A copy of the following documents is attached to approval documentation.  The translation request.  The returned translation.

Forms/Template Design and Development 209 / 349  The translated final draft form approved by the translator. These documents serve to confirm to the approving authority that the form was professionally translated and approved as such by the language professional authority. Proofs and test samples – Given the importance of proofs in giving the green light to proceed with the actual printing of a form, their approval is critical, needs to be documented and put in the form history record. Generally, proofs are examined and approved by the Forms Management Program staff or designated staff with experience in printing processes what have the expertise to determine the accuracy and quality of a proof. Approval sent to print providers may be communicated:  Via email for electronic proofs.  By signing on physically printed proofs, test samples or construction samples.  Via system approval or e-signature.

Forms/Template Design and Development 210 / 349 A notification that proofs were approved is sent to the client and stakeholders for information. Printer’s proofs represent the last step to approve before printing a form for which final approval has previously been obtained. Test samples of printer-resident forms or forms with variable data printing, are to be included along with final drafts of every output version of the form, in a formal document seeking approval of such complex eforms. These proofs assure approving authorities that the form’s features, functionality, data merge, printing and information display works as intended. Approval may be communicated:  Via minutes of approving committee meeting decision.  With signatures applied to the approval document.  Via system approval or e-signature. Final approval – Final approval is sought for an approved form solution when content, design, layout, features,

Forms/Template Design and Development 211 / 349 programming and output formats are finalized; after testing and quality management has been completed, and the form is ready for print production or for deployment. Samples of the agreed upon final iteration of the form in all its output versions or instances are produced, and approval documents prepared, as applicable. This last approval before deployment is critical as it:  Implies financial commitments and expenses to the organization.  May significantly affect operations or staff in their work activities.  Impact clients in their business dealings with the organization. In some cases, the final approval is a formality because approvals have been obtained throughout the process at various milestones, otherwise the project would not have proceeded. Approval documents of significant form deployments generally provide:

Forms/Template Design and Development 212 / 349  A brief background and context.  A description of what is to approve (including a list).  Details on each output versions, on tests and quality management performed.  A timeline for deployment.  Copies of the planned communications and announcements to be published and where. Any other relevant associated documents attached as reference (e.g., new or modified policy, procedures, process maps, technical support). This last approval before deployment is critical as it implies financial commitments and expenses to the organization, may significantly affect operations or staff in their work activities, or impact clients in their business dealings with the organization. Files or copies of every output version of the finalized draft form are sent for approval. The approving authority or authorities return their approval:  Via email.

Forms/Template Design and Development 213 / 349  By signing the draft sample copies.  By signing the accompanying approval document.  With an e-signature or a digital signature. When preparing approval documents: • Ensure to clearly indicate the deadline by which the approval must be received. • When seeking approval from many approvers, also include a note stating that if approval is NOT received by the deadline, that the Forms Management Program will deem the form approved. If necessary, indicate the effect a delay would have (e.g., on delivery or deployment schedules as part of larger projects with strict deadlines, or missed legislated requirement deadline). Note: While not feasible or appropriate to include such a note when seeking formal approval from the Forms Committee or the executive committee, it does facilitate the approval process of drafts, final drafts and test samples. When many stakeholders need to approve, this avoids the one or two that delay approving to affect the overall approval process when timelines are often tight.

Forms/Template Design and Development 214 / 349 Before technology became pervasive in everyday work activities, form drafts, proofs, test samples, translations, and final drafts were often approved by asking approvers to sign directly on the printed form’s output version samples. This confirmed the approver had actually seen the final draft state of the form with its official edition date. Some Forms Management Programs may still do this. It has since become common to send approval requests by email: • With draft form output files attached for review. or • With a link that directs the approvers to the draft form output files in a common directory, repository or website. Approvers follow the link to retrieve and view the draft forms to approve. Approval is returned by email, via system approval or e-signature and put in the form history record. All relevant documents pertaining to the development and production of a form, and specifically all approvals, are put on the form history record.

Forms/Template Design and Development 215 / 349 BUSINESS PROCESS ANALYSIS Proposed drafts of forms may be included in business case approval documents submitted to approving committees or senior management for a decision on a form solution. A few drafts are developed by the forms developer under the instructions of the business process analyst and forms analyst to illustrate form options and proposed solutions. The selected and approved solution becomes the focus of the form’s development continuation. During the form’s development, business process analysts often facilitate meetings and demos to obtain feedback from users and interested parties on the proposed form solution, form design, layout, features and functionality included. Especially in the case of eforms, dynamic eforms and online applications, the business process analyst leads demos and presentations using functional prototypes of the form under development. FORMS ANALYSIS During the form’s development, forms analysts often facilitate meetings and demos to obtain feedback from users and interested parties on the proposed form solution, form design, layout, specific

Forms/Template Design and Development 216 / 349 features and functionality included. Especially in the case of eforms, dynamic eforms and online applications, the forms analyst leads demos and presentations using functional prototypes of the form under development. This allows for interested parties to:  Observe the draft form or prototype in action.  Assess whether the features applied meet their needs.  Adjust if necessary.  Provide comments and feedback which are recorded and sent to the forms developer for revision. These meetings and demos are also opportunities for the forms analyst and forms developer to explain reasons for using feature X instead of feature Y. Communicating how and why a form is designed and developed in a specific way helps interested parties understand the overall context surrounding forms development and helps mitigate user resistance at deployment time. Depending on the outreach of the form, meetings and demos are conducted until the form elements and draft output versions are finalized to the satisfaction of the client and stakeholders.

Forms/Template Design and Development 217 / 349 When a form is finalized and samples of the latest draft form are generated in all planned output versions, the forms analyst proceeds to obtain approval from the responsible authorities. FORMS DEVELOPMENT During the development phase of a form, the forms developer may produce several drafts and prototypes of a given form. This depends on the type of form, its complexity and its intended delivery channels. At first, the forms developer may be asked to produce a few forms designs to illustrate possible options that are necessary in support of a business case being prepared by the business process analyst. The draft designs intend to show the different proposed solution options in order for the approving authorities to make an enlightened decision on a form solution. For simple forms that are printed, like stationery items, the forms developer simply applies the appropriate design and layout according to the Forms Style Guide for that item. These rarely require more than one draft since the final sample sent for approval is more to approve the content on a pre-approved design and layout.

Forms/Template Design and Development 218 / 349 Once the final print output version of a form has been approved, the developer: • Creates a high-resolution PDF file of the form. • Sends the PDF form file to the print provider with printing request and specifications asking to see a printer’s proof. • The forms developer or designated staff approves the printer’s proof that follows. More complex forms using electronic features, automated workflow, data exchange, or dynamic forms programmed to display and adapt the form content based on answers provided as the form is being filled out, that are also printed, require a more involved development process. Several drafts may be produced in different output versions. • The forms developer first clarifies the form elements and drafts a few form samples to demonstrate possible design and layout options. • Draft form samples are presented to the client, stakeholders and interested parties to discuss, demonstrate the pros and cons of each design and discuss with them to finalize the list of form elements required.

Forms/Template Design and Development 219 / 349 • Each draft is uniquely identified based on a filenaming convention adopted for draft versions of forms. Once a draft form is agreed to by interested parties: • The forms developer finalizes the draft, refines the design, layout; adds script, programming and features to give it functionality, as applicable. • The client, stakeholders and designated editor review the final draft. • The forms developer applies the last changes, edits and tweaks before generating the files and final draft samples of all intended output versions for final approval before deployment. PRINT PRODUCTION When a form is manufactured, once the draft of the final print output version has been approved, the developer creates a high-resolution PDF file of the form, which is sent to the print provider with the print request and specifications that asks to see a printer’s proof. The print provider:

Forms/Template Design and Development 220 / 349  Uses the PDF file to produce the necessary pre-press work (e.g., prepare a plate or configure the PDF for its printers or presses).  Readies the presses or printers.  Creates a proof. Depending on the output print media and construction, the proof could be a:  New PDF file.  Blueline (rare now with digital proofs).  4-color process printed proof.  Construction sample. A proof is sent to the Forms Management Program to ensure everything is OK before the print provider runs the presses. Proofs are meticulously reviewed and checked for errors before approval is granted to print. A copy of the approved proof returned to the print provider is saved in the form history record.

Forms/Template Design and Development 221 / 349 TECHNOLOGY Today’s forms development software allow for the creation of a form source file to facilitate the creation of drafts, prototypes and samples as well as various output versions. For example From a source file, the forms developer may generate: • Draft samples to illustrate the content design and layout of a form. • A high-resolution PDF intended for the printed output version that becomes a printer’s proof. • A functional prototype of a dynamic form showing intelligent features and functionality. • Draft production files to be deployed on the testing environment as if in production. • Image files. Certain forms may need to be developed in more than one software. Output formats to develop the form in are determined based on the form’s business process documentation, and on specifications and business requirements received.

Forms/Template Design and Development 222 / 349 Technology allows:  The Forms Management Program staff to better demonstrate form drafts and prototypes’ features to users and stakeholders, and enlist their feedback.  The setup of a testing and quality management environment.  For testing areas to perform rigorous testing on forms drafts and prototypes without interfering with the production environment. Source files, output files, drafts, proofs, email approvals, approval documents can be electronically stored and saved in the form history record. FORMS CONTROL As part of the forms technician responsibilities to track the form’s project, every one of the form’s draft iterations produced in every output version, translations, proofs, test samples, final drafts and prototypes are:  Appropriately stored in the designated working directories or form history record during development and testing activities.  Made available to approvers in due course.

Forms/Template Design and Development 223 / 349  Given draft filenames based on the form unique identifier convention to ensure each draft is properly identified as the form evolves.  The relevant draft forms, annotations, associated documents recording decisions about the form content, design, layout, output versions, translations, testing results, print requests, proofs, and approvals are put in the form history record.  When final approval of a draft form is received, interested parties and other areas involved in the next steps, such as testing and deployment, are notified and sent copies of the approved form.  The forms technician enters the applicable activity fields in the forms management database into the form project profile. For example The forms technician enters: - The date a form’s solution option was agreed to and approved. - The Program staff currently working on the form’s project. - Feedback received during the development phase.

Forms/Template Design and Development 224 / 349 - The date the requirements and specifications document was sent to the forms developer. - The date a working draft or final draft was sent for approval and the date approval was received. - The date the form was sent to translation and where. - The date the translation was received and the date when the translator approved the final draft of the translated form. - The date the form was sent to print. - The date the proof was received; the date the proof was approved and returned to the print provider. - The number of output versions required for this form’s project. - The date the form was deployed, etc. The forms technician also takes minutes during meetings, presentations, demos, forms committee meetings and records decisions about forms.

Forms/Template Design and Development 225 / 349 PROGRAM MANAGEMENT In its Program Manual, the Forms Management Program outlines its mandate, mission and how it provides services to the organization. This is supported by procedures and forms request workflow diagrams to help organization staff understand what to expect when submitting a form request. It also supports Program staff in understanding what is expected of them and how they deliver services to the organization. The forms development and approval process vary depending on the complexity of the form, the intended audience, the media and output format of its delivery channels, and project timelines. The Program head ensures the Program Manual has workflow diagrams to illustrate these different development and approval processes according to form type. For example An internal form intended for the use of one functional area may be quickly developed in close collaboration with users and stakeholders of that area and the forms developer. Drafts are quickly reviewed and approved by the area’s authority for deployment.

Forms/Template Design and Development 226 / 349 On the other hand, public dynamic eforms or internal forms used by the whole organization staff could require a more rigorous development and approval process. This is to ensure all organization parties are satisfied business needs met, and to secure budget funding and resources. Such forms often require a multilevel approval, beginning with the authority from: − The client area. − The form owner area. − The Forms Committee. − And possibly the executive committee. The Program head ensures there are guidelines and a general framework to assist Program staff in determining the appropriate approval process to apply depending on the form type and context. Some approval levels may be governed by other organization policies and referenced in the Program Manual. The framework is generic enough and flexible so it can be adapted to different situations. This is to allow for establishing the appropriate approval levels and authorities at the start of a form’s project to every party’s satisfaction and in compliance to existing policies. This is usually discussed and agreed between

Forms/Template Design and Development 227 / 349 the Forms Management Program staff, the client and stakeholders. The Program head supports its staff at different steps of forms development or approvals. For example • When forms development lags or has gone through many iterations without reaching agreement on the elements or final approach, the Program head needs to engage discussions with the client area for resolution. • Represents the Program at meetings aiming to resolve issues on matters relating to forms, forms management and form solutions. • Support Program staff when submitting approval documents with a clear or urgent deadline by which the approval must be received. • Endorse Program staff when sending a note to approvers stating that if approval is NOT received by the deadline, that the Forms Management Program will deem the form approved. If necessary, indicate the impact a delay would have (e.g., on delivery or deployment schedules as part of

Forms/Template Design and Development 228 / 349 larger projects with strict deadlines, or missed legislated requirement deadline). • At times, approvers are invited to a meeting for a presentation of the draft or prototype of the form for its approval. The invitation includes form samples for reference, specifies the purpose of the meeting and requires the presence of area representatives that have the authority to request changes and approve the form. The invitation, endorsed by the Program head, states that if the invited representative cannot be present, they need to designate a replacement with authority to approve on their behalf.

Forms/Template Design and Development 229 / 349 Deployment and implementation The Forms Management Program coordinates with the form owner and stakeholders to determine when, where and how a form is to be deployed. Where a form is to be deployed varies depending on the intended user base and delivery channels. It could include:  Enterprise systems and websites.  Specific groups of users.  Warehouse.  Catalog, library, portal, repository.  Third party sites.  Documents such as a procedures manual. Deployments require some type of communication to staff or client base. A successful implementation may require a quick message or the creation or update of policies, business procedures, user procedures, training, and documentation to support technical support staff or the installation of additional software, hardware or other equipment.

Forms/Template Design and Development 230 / 349 FUNDAMENTALS Deployment = The mechanics of making a form available. Implementation = Other activities and factors that support a smooth transition to using the form. Deployment Forms deployment is the process of making the form available to the intended users and systems in an organized and methodical way. It involves:  Ensuring the network, web or technical environment is configured, set up and ready to receive, install form files and make them accessible. This could include the procurement of peripheral equipment, such as barcode readers for example.  Applying security and access rights and permissions for each form output version deployed and ensuring groups exist or are created on the network.  Removing the output files of earlier eform editions and archiving them, keeping a record of every deployed edition.  Installing eform files of new or revised editions of forms.

Forms/Template Design and Development 231 / 349  Sending form output files to print providers, internal partner services or external service providers.  Arrange for contractual agreements to be in place.  Procuring forms or forms printing, receiving, storing and warehousing stocks of printed forms and updating the inventory system to reflect available stock quantities.  Determining the disposition of stock on hand when a printed form is modified or replaced. Forms deployment is a logistical activity. Merriam-Webster defines logistics as “the things that must be done to plan and organize a complicated activity or event that involves many people.”51 This is the essence of forms deployment. It is a simple concept, really. Regardless of the media and regardless of where the users are located, the form has to be available to them. 51 Merriam-Webster.com, “logistics”

Forms/Template Design and Development 232 / 349 Forms deployment generally is under the responsibility of the Program with the collaboration of other partner areas such as Information Technology and Inventory Management. Just as there is a life cycle for a form, there is a life cycle for deployment. In some respects, each deployment is like a project within the larger form project. Steps of the deployment life cycle include:  Gathering requirements.  Establishing a deployment plan.  Verifying that available output files match destination locations as per determined delivery channels.  Doing the actual deployment to implement the plan initially and through repeated revisions.  Overseeing and tracking the deployment process.  Performing recordkeeping associated with the deployment.  Maintaining the deployed file.  Undeploying (uninstalling) a form. While a form project is in its initial stages, gathering requirements is necessary and part of that is who is going to use the form and

Forms/Template Design and Development 233 / 349 where will the form be accessed, that is, the user point of access. It is imperative to understand this in order to create the correct form output version for each user point of access. Common user points of access and types of output versions include: Office templates – Forms and templates created in an office suite can be deployed within the software as a template (e.g., word processor template file, presentation template file, spreadsheet template file). The office suite is the user point of access. Or these forms and templates may be accessed via a hyperlink in a forms catalog. Deployment to an office suite requires a form or template designed in that office suite. Forms repositories – Electronic forms of all types can be deployed via a forms repository. This is just a file structure with a listing of form filenames. Any type of file can be stored in this manner, whether originating from an office suite or a specialized forms program. Any search capability is a function of the repository software. Windows Explorer is an example of this type of file structure.

Forms/Template Design and Development 234 / 349 Forms catalogs – Users may have an online catalog as a point of access for all their forms. A catalog is an application, not just a file structure. It can be used to order paper forms or launch templates or electronic forms via a hyperlink. This type of user point of access can include all types of forms, both paper and electronic. Search capabilities are limited to whatever capabilities are built into the program. A catalog is more robust than the repository. Deployment to a forms catalog includes a file in a file structure and a permanent hyperlink pointing to that file. There may also be a .jpg file if the forms catalog has a thumbnail image of the form. Forms portals – An online forms portal, a very robust application, can do everything a catalog can do and more. This may include: • Allowing the creation of an often-used forms list. • Displaying the forms that have been completed and saved, mailed and received. • Handling forms created in many different software. • Searching based on the programming.

Forms/Template Design and Development 235 / 349 • Linking to other sites such as the Forms Management Program’s intranet page or to other documents such as the Form Style Guide. • Handling forms communications so users are current with form changes, implementations, out of stock situations and more. Deployment to a forms portal includes a file in a file structure and a permanent hyperlink pointing to that file. There may also be a .jpg file if the forms portal has a thumbnail image of the form. Mobile device – A mobile phone or a tablet can be a user point of access. Each have special requirements for design, and that requirement defines what must be deployed. Deployment to a mobile device requires an application or other specialized file type. A printer – Forms can reside at the printer and when a job is sent from the processor to the printer, the form is picked up from the printer memory. Deployment to a printer typically requires a high-resolution press quality PDF or a file written in the language of the print device.

Forms/Template Design and Development 236 / 349 An online document or webpage – A procedures document with an embedded hyperlink is an example of a user point of access. The user reads the procedure and can access the form used in the procedure directly from it. Government websites that have detailed instructions on how to use a form and include a link to the form are another example. Deployment to an online document may include a permanent hyperlink and a file in a file structure to support the link. Physical delivery – If a form is mailed, shipped or delivered to a customer, the user point of access for the customer is a printed copy. But in order to support this user point of access, the form must be deployed to the print provider in the appropriate format. Further, there are arrangements for storage and/or delivery that are a part of deployment. Deployment to a print provider for a physical delivery user point of access requires a high-resolution PDF. Once a draft form is approved in all its planned output versions, it is ready for deployment.

Forms/Template Design and Development 237 / 349 For printed forms, the first step in deployment is sending the files to the print provider for production and further actions such as storage and shipping are later required. Eforms are output in their final production version files and installed on the intended delivery channels according to the user point of access: catalog, repository, portal system, on internal and external websites, or dedicated network drive, path and directory. Every form output version is finalized and deployed using the same edition date. This is to ensure the integrity of the form edition. This helps staff, trainers, technical support staff ensure they are working with the correct edition of the form at all times. There is a substantial amount of recordkeeping associated with deployment. It is imperative to track:  All the planned user points of access and output versions for each deployment.  Whether or not the actual deployment occurred. Planned deployment is a roadmap of where all the deployments are directed. Planned deployment information includes:  The user points of access.  Output version filename and file type.

Forms/Template Design and Development 238 / 349  Purpose.  Source filename.  Interested parties such as print providers, vendors, system names and more. If using a database, there are multiple deployments for most forms, so tracking the planned deployments must be have a multiple row capability. This information is relatively unchanging and is part of the metadata of a form. It includes:  Actual deployment records where and when that roadmap was implemented.  When was it deployed and by whom?  What file was deployed?  Was this deployment done directly by Program staff or handed off to another group such as Information Technology to be placed on a server?  Is there a transaction number or service number for this action? Actual deployment information is updated every time a form is modified and re-deployed, that is, it is part of a form project. If using a database, there are multiple deployments for most forms, so tracking the actual deployments must be have a multiple

Forms/Template Design and Development 239 / 349 row capability. It should be recorded in the forms management database as part of project data. Once a form becomes obsolete, it must be reverse deployed from all the user points of access where it has been deployed. Keeping good records on the user points of access will facilitate removal of the form once it is no longer in use. If the form has become obsolete and it is going through the cancellation process, the source files and the output files deployed are archived along with other digital records. Sometimes only a particular output version of a form needs to be reverse deployed. For example A form is still active and now lives on the browser in HTML. The office suite version is no longer needed. So, that office suite file needs to be removed from its user points of access. The guide to reversing deployment is the information that is available from the planned deployment and user points of access. Depending on why the form is being removed, one or some or all of the user points of access may need to be addressed. The information in planned deployment is the roadmap to know where to go and what to remove.

Forms/Template Design and Development 240 / 349 Implementation Implementation is about other activities and factors that support a smooth transition to using the form. It includes:  Gathering details from other functional areas involved in the implementation and ensuring they are informed of how the project is evolving.  Collaborating with other functional areas involved in the implementation to ensure everyone’s deliverables are ready at the time of deployment (e.g., policy, training modules, general and user procedures, translation).  Coordinating the timely deployment of form output files on the various platforms as per their delivery channels.  Having a good grasp of the project background, what’s new, what changed and how are users affected. It is important to take into account change management issues.  Ensuring a communication plan is in place. This plan is to ensure the target audience and staff are notified and enquiries and technical support areas are notified so they can be ready to answer user calls once forms are deployed and their availability made public. Activities may be shared between different functional areas and depending on the project, there could be

Forms/Template Design and Development 241 / 349 multiple communications during the project as well as at the time of deployment.  Testing equipment and other peripherals used with the forms. For example A new form with a barcode requires the use of a new hand-held reader. Users who will be handling the forms and scanning the data need to know the equipment is in place and operational. − Program staff ensure this aspect of the form’s project is taken care of, equipment procured, installed, tested and deployed first. − Users need training on how to use the new reader to scan the forms in order to successfully capture the data. − Technical support and staff need to be notified of the existence of the new form and of the new technology. − Depending on the complexity of the form and its function, business procedures and user procedures may be needed to guide staff in their work activities associated to the form.

Forms/Template Design and Development 242 / 349 A big part of implementation is communication with all parties interested in the form, and other functional areas have roles and tasks associated with this:  The forms developer or forms analyst provides details on:  How the form operates or is modified from an earlier edition.  From where the form can be accessed.  Whom to contact for support.  How to dispose of old stock.  Links to related documents, material, the newly deployed forms are included, as applicable.  Partners in other involved functional areas prepare associated material for training purposes, to serve as reference when working with the form, or to notify all interested parties.  Form owners and stakeholders provide relevant details on the reason and context for implementing a new form, modifying it or cancelling it.  Communications and Marketing assist in the writing, review, production, and publishing of the different communication products.

Forms/Template Design and Development 243 / 349  Web Services coordinate any webpages or messages associated with the implementation. In the case of printed forms, the announcement to staff includes important information if or to how to dispose of stock on hand when a form is modified or replaced by another form or system. This is to ensure that:  Staff are advised of what other form, system or tool they are to use to accomplish their work instead of a cancelled form. This is essential for a smooth transition and for staff to carry on with their work activities and not flood the enquiries’ area or technical support staff with calls.  Staff receive clear directions as to specifically what to do with remaining forms’ earlier printed editions. No old form editions remain in cabinets or at the bottom of office drawers to reappear years later and confuse staff.  The correct disposition procedure is taken according to the form’s criticality. In some cases, the risk of recycling them is of no consequence, while others with more security features or sensitive form elements may require complete destruction.  The correct form edition is always used. Older editions:

Forms/Template Design and Development 244 / 349  Continue to be used if the process and procedures allow them until stock of that edition is depleted.  Or are not used when business processes have changed or absolutely require the use of the new or revised form edition.  Deployment and implementation  Deployment and implementation BUSINESS PROCESS ANALYSIS In preparing for the implementation of a form, or to finalize a policy or procedure, the business process analyst might need to update business process maps. The analyst may need to update the process maps to:  Reflect changes or alterations made over the course of the development phase.  Include the assigned form unique identifier. Process maps are useful to other colleagues in preparing communication or reference material such as policies, business and user procedures in which the maps may be included.

Forms/Template Design and Development 245 / 349 The business process analyst, in its capacity as facilitator, might also be called to give live demos to stakeholders, users, trainers, and technical support staff. At times, a short brief demo of the form products to be deployed with a question period is sufficient to inform key players in the organization. FORMS ANALYSIS As the Forms Management Program staff usually in charge of overseeing a form’s project, the forms analyst ensures, from the start, to determine what activities and products are required to ensure a successful implementation of the form. Implementation activities vary depending on the complexity of the form, its intended audience and delivery channels, and on the project scope. The analyst tracks these activities, including those executed by other partner areas (e.g., Training, Policy, Procedure, Information Technology, Web Services, Communications, stakeholders). The forms analyst ensures that the database is up-to-date with the planned deployment information. As business processes change, forms change with them and so their deployments might change. It is imperative that each project include a thorough review of

Forms/Template Design and Development 246 / 349 the user points of access and output versions required for the form in its revised state. Forms may be deployed following a typical form’s project and within an agreed timeline. Some form’s deployment may depend on a specific implementation date aligned with the deployment of other systems or software. These deployment dates are governed by the organizational project plan and schedule. Other form deployments are governed by the enactment of new legislation or changes to legislation. Effective dates of legislation represent mandatory dates by which forms are to be deployed and operational. Like an orchestra conductor, the forms analyst needs to ensure the different material is delivered at the right moment.  Printed versions of the form, training, coaching sessions, demos, documentation to technical support staff may be required before the form’s deployment.  The associated policy, procedures, user procedures, announcements to staff and clients are made ready for publication at the time of deployment.

Forms/Template Design and Development 247 / 349 The forms analyst coordinates with other partners in the project to ensure every area’s respective contribution is delivered according to the project schedule. Generally, the forms analyst is responsible for issuing and publishing announcements about forms. These are published internally or externally, as applicable. The internal message to staff may vary from the one published externally for clients or the general public. These announcements are written with the support of the forms developer for technical details and that of stakeholders for context information. Forms Management Program areas often have a standard template for this type of messaging. The forms analyst ensures to inform staff or clients of:  The title and unique identifier of the form and advise of the different output versions are deployed of the form’s edition.  The reason for a new form (e.g., new legislation, new system), provide links to references or previous communications on the subject.  The reason for changes to an existing form, provide links to the forms deployed, to references (e.g., policies, user procedures) or previous communications on the subject. Give

Forms/Template Design and Development 248 / 349 details on the changes and how they may affect the form’s behavior.  The reason for cancelling a form, by what it is replaced, if applicable, and advise on how to dispose of printed stocks on hand, if printed.  The key form elements they need to be aware of (e.g., the form now displays a barcode to facilitate data capture when received).  Where they can call and whom to contact for help or more information. Depending on the scope of the form’s project, its audience and user base, announcement are approved by:  The head of the Forms Management Program.  The client’s functional area authority, or higher authority, as deemed necessary. Communications and messages are often included in approval documentation. Approvals are obtained before the planned deployment date. Once approved, announcements and associated material are forwarded to the areas responsible for publishing them (if not in

Forms/Template Design and Development 249 / 349 the Forms Management Program area) who prepare and ready the messages, related material, links, etc. The messages are first posted on a test environment allowing the Program staff to check the final output of the published announcement, usually in a web format, and ensure all associated links work properly. Edits are made as required and the approved messages remain until the Program advises to publish.  Advance copies of the announcements are also sent to key partners in the implementation. These are determined on a project-by-project basis and can include:  Technical support staff.  The organization’s enquiries desk.  Trainers.  Groups of power users who may assist and coach during the implementation. … and others. Once confirmation is received that all form output versions are deployed in production and printed forms are in the warehouse for distribution, the forms analyst can authorize the publication of all announcements.

Forms/Template Design and Development 250 / 349 FORMS DEVELOPMENT Once a draft form is approved in all its planned output versions, the forms developer applies the official form’s unique identifier, with the deployment date as its edition date, to the source file and to each output file according to their respective delivery channel and agreed filenaming convention. All files of that edition are saved in their respective directories, repositories, saved, archived and put in the form history record. Forms developers:  Depending on the project, iterative draft copies of a form may be shared with trainers and partners before approval to assist them in preparing material that will be released at the same time the form is deployed.  Prior to deployment, share copies of the final and approved form in required output versions to trainers and other partners to finalize associated material that will be released at the same time the form is deployed.  Might also create images of key steps and functions in the form filling or handling process that are included in training material or user procedures.

Forms/Template Design and Development 251 / 349  Copy the output files to the required directories, repositories for their deployment, and if not deployed by the forms developer, give instructions to partner areas responsible for deploying the form, such as the Web Services or Information Technology. Staff responsible to deploy forms on the production environment:  Are careful to ensure the correct filename is applied to each output version and validates the form edition installed.  Confirm installation of all output versions to the Forms Management Program area. The Forms Management area proceeds to a last testing and quality management exercise to ensure the correct edition and versions of the form are installed and properly launch and execute when accessed. Once all versions are successfully tested in production, the Forms Management Program can proceed with publishing its announcements. Printed forms are essentially deployed once stock has been delivered and accepted following testing and quality assurance of the product. The forms developer or forms technician confirms to the forms analyst the printed forms are ready for distribution. This signals the announcements can be published.

Forms/Template Design and Development 252 / 349 In the case of cancelled forms, the forms developer removes the source file and output files from the active directory or repositories in production or gives clear instructions to the responsible area to remove them. This ensures access links and related information are removed from websites, online catalogs, lists. Instructions are also given on the retention period required for that form’s output files and associated information. The source file and output version files are stored in the archive directory, put in the form history record. DATA COLLECTION AND PRESENTATION Deployment and implementation of a form is the ultimate test in production of the data collection and effectiveness of a form. Despite all efforts to conduct testing and quality management of a form’s data collection functionality and to plan a smooth implementation, one can never be sure of what D-day (for deployment day!) will bring when going live. This is why the Forms Management Program area and its partners remain on alert to address problems or issues that could occur on D-day. Generally, when things go awry, the feedback is quick. Support call tickets are logged and problems reported. Depending on the nature of the problem, tickets are sent to the Forms Management

Forms/Template Design and Development 253 / 349 Program area for resolution. The forms analysts and forms developer analyze the situation and ensure that it gets fixed. For example • Is it a specific field or barcode function that doesn’t capture and send data? • Is its associated equipment that is not functioning, like a scanner? • Is it the workflow engine that is not routing forms and tasks to the correct areas? • Is it a real problem? • Maybe it all is working well, but instructions are misleading or confusing causing misuse? At times, the forms require minor tweaks to fix the problem, and the form is quickly redeployed the same day. Other times, when problems are more complex, solutions might take longer to fix and require that staff be notified. The Forms Management Program and stakeholders may need to decide  To remove the deployed forms and return to an earlier production environment.

Forms/Template Design and Development 254 / 349  To publish instructions for staff to follow until the problem is solved. At a minimum, information about the problem and instructions on what to advise staff are quickly communicated to technical support staff, and an announcement to staff is published for cases that take longer to fix. A new announcement is published when the problem is resolved and the form operational. TECHNOLOGY The different form output versions being deployed have been designed and developed to operate within their respective delivery channel and technology. For example • A PDF fillable eform is developed to work on the web and using Acrobat Reader or Acrobat. An XML or HTML dynamic online form is meant to work on the web. The electronic features they include call upon other technologies such as text readers or programming for data exchange. • Some forms include components that call for the use of other peripheral equipment like scanners or readers.

Forms/Template Design and Development 255 / 349 • Printed forms for mailouts may be deployed via a high-speed printer merging data at print time. Success at deployment time indicates all aspects of the technology were addressed during development. Generally, the deployment of eforms, templates, dynamic forms and online applications are executed by Information Technology staff who are responsible for the production environment. Depending on what is deployed and for what user base, they may use technology to program a global installation or more restricted installation. Access rights and privileges by group are defined, set and readable by the technology in order for the designated users or systems to access the form. The Web Services either copy the form output files on the web servers for public use outside the firewall or for internal use to all staff or to specific intranet or extranet sites inside the firewall. PRINT PRODUCTION Printed forms are ready for deployment once stock has been delivered, approved and received following testing and quality assurance of the product. Forms that are only in print format can