NATIONAL ARCHIVES AND RECORDS ADMINISTRATION (NARA)

PROCESS DESCRIPTIONS DOCUMENT

(PDD)
TEMPLATE

<PROJECT NAME> (<PROJECT

ACRONYM>)

Version <x.x> <DRAFT | FINAL>

Prepared by <author>
<Month> <Day>, <Year>
 <Project Name>
Process Descriptions Document (PDD)

Table of Contents
1 Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.2.1 Assumptions 4
1.3 References 4
1.3.1 Documents 5
1.3.2 Forms 5
2 Business Abstract 6
2.1 Business Purpose 6
2.2 Business Scope 6
2.3 Stakeholders 6
2.4 User Roles and Characteristics 6
3 System Abstract 8
3.1 System Purpose 8
3.2 System Scope 8
3.3 System Overview 8
3.3.1 System Context 8
3.3.2 System Functions 8
3.3.3 User Roles and Characteristics 8
4 Introduction to Process Descriptions 10
4.1 Scenarios 10
4.2 Overview of Process Descriptions 10
4.2.1 Process Flow Diagram 11
4.2.2 Actors Table 14
4.2.3 Process Steps Table 15
5 Process Descriptions 16
5.1 Scenario <ID1>: <Scenario Name> 16
5.1.1 Overview 16
5.1.2 Process Flow Diagram Hierarchy 16
5.1.3 <ID1>0 – <Diagram Title> 16
5.1.4 <ID1><Z> – <Diagram Title> 17
Appendix A – Glossary 21

PDD_Template_v.1.2.docx Page 2 of 20
 <Project Name>
Process Descriptions Document (PDD)

Revision History
Date Version Author Revision Description
<mm/dd/ <x.x> <Authoring Organization’s <Summary of the revision; the initial version should
yyyy> Name> say 'Initial Release">

<The version number of the first version should be "0.n" until the final draft is ready to be delivered to
IQ CM; it should be version "1.0" when it is provided to IQ CM. The version number is incremented for
subsequent releases: the project team can decide if it is a new major release (i.e., "X+1.0") or a new
minor release (i.e., "X.n+1").
The document should be labeled "DRAFT" while it is under development and "FINAL when it is provided
to IQ CM.
Please refer to the title page of this template, which displays both the version number and the
document status.>

PDD_Template_v.1.2.docx Page 3 of 20
 <Project Name>
Process Descriptions Document (PDD)

1 Introduction
<Wherever there are angle brackets, please replace them with content or delete them. For example,
“<Year>” would be replaced by “2017”. Also, remove the “Template” watermark using MS Word's
Ribbon > Design tab > Watermark drop down list > Remove Watermark action.>
This section introduces the Process Descriptions for <Project Name> (<Project Acronym>). It discusses
the purpose and content of the document.
<This document reflects the techniques and methodology typically utilized by the Requirements
Management Division (IR); however, using this methodology is not mandatory and a project may use a
different one if there is a reason for doing so. When a different methodology is used, this document may
need to be modified and / or reformatted appropriately to reflect the methodology used.>

1.1 Purpose
The purpose of this document is to present business process descriptions related to the <Organization
name>’s <System Name> (<System Acronym>).
<Include additional information summarizing “purpose”.>

1.2 Scope
This document describes the <Organization Name>'s business processes as they relate to <System
Acronym>.
<Summarize the business functions that are in the scope of this analysis.>
<Indicate whether the process flow diagrams herein cover the current (”as is”) processes and / or the
future (“to-be”) processes.>

1.1.1 Assumptions
The following assumptions pertain to the contents of this document in general and to the business
process descriptions specifically:
● <Assumption1>
● <Assumption2>
● <Assumption3>
1.3 References
This section lists the documents that were utilized during the development of the business process
descriptions.
<A "document" may be a website or web page.>

PDD_Template_v.1.2.docx Page 4 of 20
 <Project Name>
Process Descriptions Document (PDD)

1.1.2 Documents
1.3.1-1. <Document Title> <Version x.x>; <Authoring Agency or Company Name>; <Date
Published>; <hyperlink to document if available> <(accessed on <Date Accessed>)>.

1.1.3 Forms
1.3.2-1. <Form Title> <Form Revision Date or Version Number>; <Agency Name>; <Form
Number>; <hyperlink to form if available> <(accessed on <Date Accessed>)>.

PDD_Template_v.1.2.docx Page 5 of 20
 <Project Name>
Process Descriptions Document (PDD)

2 Business Abstract
This section introduces the <Project Name> project and describes its business context.

2.1 Business Purpose

<Describe at the organization level the reason and background for which the organization is pursuing
new business or changing the current business in order to fit a new management environment. In this
context, it should describe how the proposed system would contribute to meeting business objectives.
Note: Information for this section may possibly be copied from a Business Needs Analysis document,
Business Case, or Concept of Operations.>

2.2 Business Scope

<Provide a short description of the relevant business area including name, objectives and goals. Explain
how the business area's processes will be modified to satisfy the business need.>

2.3 Stakeholders
<List the groups or classes of stakeholders and describe how they will influence the organization and
business, or will be related to the development and operation of the system.>
<If a Stakeholder Analysis (SA) exists for the project, this section could be just a reference to the SA.
Table 2-1 is REQUIRED when a SA does not exist. This table may also be modified as appropriate.>
<The "Symbol" column of Table 2-1 is for the organization symbol when a NARA organization or the
abbreviation / acronym for an external organization.>

Table 2-1: Stakeholders – Organizations

Symbol Organization POC Title Type Main Interests Impact of Project
<This column <The organization's <The title of <primary <The main interests <The impact of the
is for the full name.> the | of the organization outcome of the
organization individual secondary as regards the project on the
symbol when who is the > project.> organization.>
a NARA primary POC
organization for the
or the organization
abbreviation as regards
/ acronym for the
an external project.>
organization.
>

PDD_Template_v.1.2.docx Page 6 of 20
 <Project Name>
Process Descriptions Document (PDD)

2.4 User Roles and Characteristics

<This section should not be used when a System Abstract is used.>
<Identify each type of user, operator, or maintainer of the system by function, and the nature of their
use of the system.>
The <Project Abbreviation> business roles that are relevant to the business area are specified in Table 2-
2.

Table 2-2: User Roles and Characteristics

Role Characteristics
<Role1 Name> Responsibilities:
<TBD>
System Usage:
<TBD>
<Role2 Name> Responsibilities:
<TBD>
System Usage:
<TBD>
<Role3 Name> Responsibilities:
<TBD>
System Usage:
<TBD>

PDD_Template_v.1.2.docx Page 7 of 20
 <Project Name>
Process Descriptions Document (PDD)

3 System Abstract
<This section should not be used when the goal of the document is to describe the business processes
that are associated with a business area, independent of a specific system that is to be developed.>
This section describes the system context for the <Project Acronym> project.

3.1 System Purpose

<Define the reason(s) for which the system is being developed or modified.>

3.2 System Scope

<Define the scope of the system under consideration by
a) Identifying the system to be produced by name.
b) Referring to and stating the results of the earlier finalized needs analysis, in the form of a brief
but clear expression of the user's problem(s). It explains what the system will and will not do to
satisfy those needs.
c) Describing the application of the system being specified. As a portion of this, it should describe
all relevant top level benefits, objectives, and goals as precisely as possible.>

3.3 System Overview

3.3.1 System Context
<Describe at a general level the major elements of the system, to include human elements and how they
interact. The system overview includes appropriate diagrams and narrative to provide the context of the
system, defining all significant interfaces crossing the system's boundaries.>

3.3.2 System Functions

<Provide a summary of the major functions (i.e., fundamental actions and system capabilities) that the
system will perform. The summary should show the different functions and their relationships and
should be organized in a way that makes the list of functions understandable to the stakeholders. This
summary typically consists of a simple hierarchical decomposition of the functions, but is dependent
upon the specific system.
The functions are typically identified via the requirements elicitation activity. Although functional
analysis and decomposition is typically a system engineering activity that is associated with system
architecture and design, some of the techniques involved may be useful to the BA; there are many
information resources available via the Internet.
When a Concept Of Operations (ConOps) exists, it may include a Functional Decomposition that can be
used as a basis for this summary; if the Functional Decomposition is very detailed, you may want to
reduce the amount of detail for inclusion in this document.>

PDD_Template_v.1.2.docx Page 8 of 20
 <Project Name>
Process Descriptions Document (PDD)

3.3.3 User Roles and Characteristics

<Identify each type of user, operator, or maintainer of the system (by function, location, type of device),
the number in each group, and the nature of their use of the system.>
The <Project Name> business roles that are relevant to the <System Name> process descriptions are
specified in Table 3-1.

Table 3-1: User Roles and Characteristics

Role Characteristics
<Role1 Name> Responsibilities:
<TBD>
Work Location:
<TBD>
Equipment Utilized:
<TBD>
<Role2 Name> Responsibilities:
<TBD>
Work Location:
<TBD>
Equipment Utilized:
<TBD>
<Role3 Name> Responsibilities:
<TBD>
Work Location:
<TBD>
Equipment Utilized:
<TBD>

PDD_Template_v.1.2.docx Page 9 of 20
 <Project Name>
Process Descriptions Document (PDD)

2 Introduction to Process Descriptions

This section describes how the <Project Acronym> process descriptions are organized and provides
information regarding the format and layout of the process flow diagrams.

3.4 Scenarios
This section describes the scenarios that describe the <Project Acronym> in the <Business Area Name>'s
business processes. Scenarios can be used to partition complex process flow diagrams to make them
easier to understand.
<Define scenarios in the following table. There may be only a single scenario. Letters are typically used
for the IDs, e.g. "Scenario A".>

Table 4-1: <Project Name> Scenarios

Id Name Description
<ID1> <Scenario Name> <Scenario Description>
<ID2> <Scenario Name> <Scenario Description>

3.5 Overview of Process Descriptions

This section presents an overview of the process descriptions for the scenarios defined in Section 4.1. It
describes the formats and layouts used for the components of each process description.
For each scenario, a set of process descriptions are defined. Each set of process descriptions forms a
hierarchy or "tree", with a single, highest-level process description (node) as the root. Each subsequent
process description (node; branch) of the tree represents a decomposition of the preceding (parent)
process description into an additional level of detail. This decomposition continues until the appropriate
level of detail is reached as identified for the project.
Figure 4-1 presents a conceptual process description hierarchy for a fictional scenario assigned identifier
Z.1

1 Note that a process step is decomposed to provide more detail only when necessary, so a separate process
description/diagram may not exist for every process step; thus, Z2.4.2 appears to be missing in Figure 4-1 but it
just means that process step 2 of Z2.4 does not require decomposition into its own description/diagram.

PDD_Template_v.1.2.docx Page 10 of 20
 <Project Name>
Process Descriptions Document (PDD)

Figure 4-1: Conceptual Process Description Hierarchy for Scenario Z

An individual process description (i.e., node in the hierarchy) consists of three parts: (1) A process flow
diagram, (2) A textual description of the diagram's participants (actors) and (3) A textual description of
the diagram's steps (i.e., the activities or tasks).

2.1.1 Process Flow Diagram

A process flow diagram is laid out as a stacked set of horizontal swimlanes, where a swimlane is a
container for the steps performed by a single actor in the process.
The swimlanes are notionally ordered2 from top-to-bottom based upon when in the process its actor
participates: the swimlane for the first participant is at the top of the diagram and the swimlane for the
last participant is at the bottom.3 When an actor participates in a process many separate times, only one
swimlane is used in the diagram for that actor, and all of the actor's tasks are contained in that
swimlane.

Figure 4-2: Conceptual Process Flow Diagram

2 The notional ordering of the swimlanes is sometimes altered when it results in a clearer or easier to
understand process flow diagram.
3 This ordering of the process flow diagram's swimlanes is in support of the way that the diagram is intended to
be traversed, i.e., from top to bottom and left to right.

PDD_Template_v.1.2.docx Page 11 of 20
 <Project Name>
Process Descriptions Document (PDD)

Table 4-2 describes objects that appear in a process flow diagram and how they are used.

Table 4-2: Process Flow Diagram Legend

Object Description
diagram title USAGE
A textual box at the very top of the diagram that is used to identify the
diagram.
The diagram title itself (i.e., the text in the box) consists of the diagram's
identifier (e.g., "A2") followed by the diagram's name (e.g., "Create Case").
TYPE
There is only a single type of diagram title box.
COLOR
Not applicable – the colors used are standard and unchanging.
swimlane USAGE
A container for the tasks of a single actor. An actor may be an organization,
group, class, role, position, system, system process or system module /
component, as appropriate for the context or level of detail of the diagram. 4
TYPE

4 Higher-level diagrams typically use organizations, groups or classes as actors; lower-level diagrams typically use
roles, positions, systems, system processes or system modules / components as actors.

PDD_Template_v.1.2.docx Page 12 of 20
 <Project Name>
Process Descriptions Document (PDD)

There is only a single type of swimlane (horizontal).

COLOR
The colors for a swimlane are standard and unchanging, although the colors of
the objects within a swimlane may vary.
process step / activity / task USAGE
A process step. The label of the process step box defines the activity or task to
be performed at that point in the process; process steps are connected to
form the process flow.
Each process step is identified by a number in a small circle at the upper right
of the process step box. Numbers are unique within the diagram and the
sequence nominally follows the process flow.
When a process step is decomposed, the new (child) diagram is assigned an
identifier formed from the parent diagram identifier and the parent process
step identifier. For example, if process step "3" of diagram "A2" is
decomposed, the identifier assigned to the new diagram is "A2.3" (and the
name of the new diagram is the label of the process step "3" box). The child
diagram identifier is provided outside the parent process step box at the lower
right when a process step is decomposed.
Process steps are laid out following the process flow as much as possible,
starting at the upper left of the diagram, progressing downward and from left
to right. The diagram should be read in this manner. Any process step box
lacking an incoming connector [i.e., solid-colored arrow] is effectively a
starting point for the diagram.
TYPE
Rectangle with rounded corners Indicates a process step that involves
<Project Acronym>.
Rectangle with angular corners Indicates a process step that does not
involve <Project Acronym>.
COLOR
Dark Blue indicates a process step that involves <Project
Acronym>.
Gray indicates a process step that does not involve <Project
Acronym>.
junction USAGE
A junction is a point where a flow branches into multiple paths ("fan out") or
Asynchronous multiple flows merge into one ("fan in").
Each junction of a diagram is uniquely labeled for easy reference. The label
format is "Jn", where "n" is a positive integer beginning with "1". As for
Synchronous process step boxes, an attempt is made to label junctions sequentially
following the process flow.
TYPE
& AND – All tasks connecting to or from the junction must be performed.
O OR – At least one task connecting to or from the junction must be
performed.

PDD_Template_v.1.2.docx Page 13 of 20
 <Project Name>
Process Descriptions Document (PDD)

X XOR – One and only one task connecting to or from the junction must
be performed.
SYNCHRONICITY
Asynchronous The flows connecting to the junction need not occur at the
same time. Indicated by a vertical line to the left of the label.
Synchronous The flows connecting to the junction must occur at the same
time. Indicated by two vertical lines on either side of the
label. Not appropriate with XOR junctions.
COLOR
Not applicable – the colors used are standard and unchanging.
connector / flow USAGE
A connector indicates a transition (flow; link) from one process step to the
next.
TYPE
A solid arrow indicates a transition. The arrowhead indicates
the direction of flow.
A dashed line indicates an association or relationship.
COLOR
Dark Blue indicates a flow or association that involves
<Project Acronym>.
Gray indicates a flow or association that does not involve
<Project Acronym>.

2.1.2 Actors Table

A conceptual view of the table that describes the actors (swimlanes) that participate in the associated
process flow diagram is provided in Table 4-3.

Table 4-3: Conceptual Actors Table

Actor (Swimlane) Description
<Actor 1 name > <Actor Description>
<Actor 2 name> <Actor Description>

The columns in the actors table are defined as follows:

Actor: The label of the swimlane.
Description: A description of who or what the actor is, within the scope of the diagram.

PDD_Template_v.1.2.docx Page 14 of 20
 <Project Name>
Process Descriptions Document (PDD)

2.1.3 Process Steps Table

A conceptual view of the table that provides a textual description for each step in the associated process
flow diagram is provided in Table 4-4.

Table 4-4: Conceptual Process Steps Table

# Description Business Rules
① <Perform Function A → <TBD>
TBD>
② <Perform Function B → <TBD>
TBD>
③ <Perform Function C → <TBD>
TBD>

The columns in the process steps table are defined as follows:

#: The number of the step (block) in the associated process flow diagram that is
described, i.e., the number in the small circle at the upper right of the block in
the associated process flow diagram.
Description: A textual description of the work performed for the block.
This text will be consistent with the level of the process flow diagram, e.g., the
description of a block in a high-level diagram will be at an appropriately high
level.
Business Rules: A list of the business rules that are associated with the block.
This list will be consistent with the level of the process flow diagram, e.g., the
business rules specified for a block in a high-level diagram will be at an
appropriately high level.

3 Process Descriptions

PDD_Template_v.1.2.docx Page 15 of 20
 <Project Name>
Process Descriptions Document (PDD)

This section presents the process descriptions for <Project Acronym>. It is organized by scenario as
defined in Table 4-1.
<The following document sections essentially comprise an outline, where each outline level represents a
level in the process flow diagram hierarchy (i.e., decomposition). The sections provided in this template
consist of a single section at each level; however, as many or as few sections as are needed may be
utilized at each level in a project's document. This template includes five levels (because this number is
typically sufficient) but more levels may be used if necessary.
Note that, while the *sections* must be sequential, the diagram IDs may not be. This is because some
steps in a process may not need to be expanded.>

3.6 Scenario <ID1>: <Scenario Name>

This section provides the process descriptions associated with Scenario <ID1>, <Scenario Name>.

3.1.1 Overview
<Insert an overview of Scenario ID1 here.>

3.1.2 Process Flow Diagram Hierarchy

Figure 5-1 presents a process flow diagram hierarchy for Scenario <ID1>.

Figure 5-1: Scenario <ID1> Process Flow Diagram Hierarchy

<Insert hierarchy diagram here>

3.1.3 <ID1>0 – <Diagram Title>

This section describes the highest level (i.e., most conceptual and representational) process flow
diagram for Scenario <ID1>.

Figure 5-2: <ID1>0 Process Flow Diagram

<Insert process flow diagram here>

Table 5-1: <ID1>0 Actors

Actor (Swimlane) Description
<Topmost Swimlane Label> <Description of Swimlane Actor>
<Next Lower Swimlane Label> <Description of Swimlane Actor>

Table 5-2: <ID1>0 Process Steps

# Description Business Rules
① <Diagram Block#1 Label> → <Business rule, if any>

PDD_Template_v.1.2.docx Page 16 of 20
 <Project Name>
Process Descriptions Document (PDD)

<Description of process step, i.e., >

<The <Swimlane Actor> performs an <Action>.>
② <Diagram Block#2 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>

3.6.1 <ID1><Z> – <Diagram Title>

<This section represents the decomposition (i.e., a lower-level of detail) of a block on diagram "<ID1>0".
"<Z>" is the number of the associated block of diagram "<ID1>0". For example, "A2" means that this
diagram is a decomposition of block #2 on diagram A0 (i.e., ID1="A" and Z=2).
"Z" does not need to start with 1 and it need not be sequential, i.e., every block on a diagram does not
need to be decomposed.>

Figure 5-3: <ID1><Z> Process Flow Diagram

<Insert process flow diagram here>

Table 5-3: <ID1><Z> Actors

Actor (Swimlane) Description
<Topmost Swimlane Label> <Description of Swimlane Actor>
<Next Lower Swimlane Label> <Description of Swimlane Actor>

Table 5-4: <ID1><Z> Process Steps

# Description Business Rules
① <Diagram Block#1 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>
② <Diagram Block#2 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>

3.1.3.1 <ID1><Z>.<Y> – <Diagram Title>

<This section represents the decomposition (i.e., a lower-level of detail) of a block on diagram
"<ID1><Z>". "<Y>" is the number of the associated block of diagram "<ID1><Z>". For example, "A1.3"
means that this diagram is a decomposition of block #3 on diagram A1 (i.e., ID1="A", Z=1 and Y=3).
"Y" does not need to start with 1 and it need not be sequential, i.e., every block on a diagram does not
need to be decomposed.>

PDD_Template_v.1.2.docx Page 17 of 20
 <Project Name>
Process Descriptions Document (PDD)

Figure 5-4: <ID1><Z>.<Y> Process Flow Diagram

<Insert process flow diagram here>

Table 5-5: <ID1><Z>.<Y> Actors

Actor (Swimlane) Description
<Topmost Swimlane Label> <Description of Swimlane Actor>
<Next Lower Swimlane Label> <Description of Swimlane Actor>

Table 5-6: <ID1><Z>.<Y> Process Steps

# Description Business Rules
① <Diagram Block#1 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>
② <Diagram Block#2 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>

3.1.3.1.1 <ID1><Z>.<Y>.<X> – <Diagram Title>

<This section represents the decomposition (i.e., a lower-level of detail) of a block on diagram
"<ID1><Z>.<Y>". "<X>" is the number of the associated block of diagram "<ID1><Z>.<Y>". For example,
"A1.3.7" means that this diagram is a decomposition of block #3 on diagram A1.3 (i.e., ID1="A", Z=1, Y=3
and X=7).
"X" does not need to start with 1 and it need not be sequential, i.e., every block on a diagram does not
need to be decomposed.>

Figure 5-5: <ID1><Z>.<Y>.<X> Process Flow Diagram

<Insert process flow diagram here>

Table 5-7: <ID1><Z>.<Y>.<X> Actors

Actor (Swimlane) Description
<Topmost Swimlane Label> <Description of Swimlane Actor>
<Next Lower Swimlane Label> <Description of Swimlane Actor>

Table 5-8: <ID1><Z>.<Y>.<X> Process Steps

# Description Business Rules
① <Diagram Block#1 Label> → <Business rule, if any>
<Description of process step, i.e., >

PDD_Template_v.1.2.docx Page 18 of 20
 <Project Name>
Process Descriptions Document (PDD)

<The <Swimlane Actor> performs an <Action>.>

② <Diagram Block#2 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>

3.1.3.1.1.1 <ID1><Z>.<Y>.<X>.<W> – <Diagram Title>

<This section represents the decomposition (i.e., a lower-level of detail) of a block on diagram
"<ID1><Z>.<Y>.<X>". "<W>" is the number of the associated block of diagram "<ID1><Z>.<Y>.<X>". For
example, "A1.3.7.2" means that this diagram is a decomposition of block #3 on diagram A1.3.7 (i.e.,
ID1="A", Z=1, Y=3, X=7 and W=2).
"W" does not need to start with 1 and it need not be sequential, i.e., every block on a diagram does not
need to be decomposed.>

Figure 5-6: <ID1><Z>.<Y>.<X>.<W> Process Flow Diagram

<Insert process flow diagram here>

Table 5-9: <ID1><Z>.<Y>.<X>.<W> Actors

Actor (Swimlane) Description
<Topmost Swimlane Label> <Description of Swimlane Actor>
<Next Lower Swimlane Label> <Description of Swimlane Actor>

Table 5-10: <ID1><Z>.<Y>.<X>.<W> Process Steps

# Description Business Rules
① <Diagram Block#1 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>
② <Diagram Block#2 Label> → <Business rule, if any>
<Description of process step, i.e., >
<The <Swimlane Actor> performs an <Action>.>

Appendix A – Glossary

PDD_Template_v.1.2.docx Page 19 of 20
 <Project Name>
Process Descriptions Document (PDD)

Abbreviation Description
ConOps Concept of Operations
IR [NARA Organization] Requirements Management Division, Information Services
NARA National Archives and Records Administration
PDD Process Descriptions Document
SA Stakeholder Analysis
TBD To Be Determined
<Acronym> <Description of Acronym>

Term Description
<Term1> <Description of Term1>
<Term2> <Description of Term2>

<Delete the word Template from the title page and the footer. Do not forget to remove the watermark!
To remove the watermark in the entire document using Microsoft® Word®, select the entire document
(Ctrl-A) then do Ribbon > Design > Page Background > Watermark from Page Background group >
Remove Watermark.>

PDD_Template_v.1.2.docx Page 20 of 20