Business Requirements Document:

Customer/Client Sign-off Template

Instructions for Usage
All organizations have slightly different terminology and/or methods for tracking the creation, review and approval of
project documentation throughout the lifecycle. This template is developed based on executing projects across the
following types of projects/firms/environments:

● Investment Banking, Asset & Wealth Management, Private Banking, Hedge Funds, Pension Funds, Private
Equity, Ratings Agencies and Financial Technology Vendors
○ Capital Markets projects (i.e. trading processes, systems, new business activities/products)
○ Operations projects (i.e. operations processes, systems, regulatory initiatives)
○ Back Office projects (i.e. P&L processes, systems, regulatory initiatives; Finance, Legal & Compliance)
○ Business intelligence/analytics/reporting design and build out; data warehouse and data feed construction
○ Internal custom applications, vendor rollouts, external client-facing processes and systems
○ Projects run by the business/front office, technology, internal management consulting
● Agile, Rational Unified Process (RUP) and Waterfall environments with/without centralized technology
change architecture and processes; outsourced development, centralized infrastructure and enterprise
architecture
● Process changes, system implementations, joint process/system implementations, post-merger change
and integration management and prototyping

There is no way one single template can capture all of the above flavors and varieties, but generally the goal of
organizations and projects when it comes to tracking sign-off is that it’s about Who, What, When and Why, or more
specifically:
● Who authored the document
● Why the document was created and what the document is intended to do
● Who reviewed the document, what version was reviewed, and when and why they are considered an
appropriate reviewer (and proof of said review with feedback)
● Who approved the document, what version was approved and when and why they are considered an
appropriate approver (and proof of said approval)

All of that has value in that it allows for an organization to attempt to maintain transparency and controls around the
project and change process. The below template assists in the following:
● Maintenance of consistency, clarity and understanding of what was reviewed, what was approved and therefore
what is being used for subsequent work activities
 ● Scope of Sign-off: Recognizes that, especially on large projects, not all approvers need to approve “everything”;
there is a limit to what a single person can be responsible for, and so approvers are responsible for their
applicable areas and functions
● In addition, for this to be valid, it assumes the document is in sufficient shape with the appropriate detail and
definitions to help reviewers and approvers identify their applicable areas and functions

A majority of change in financial services involves not just people and processes, but systems and applications. It would
not be unfair to say that more than 75% of projects have this type of impact—and so it has made it into this generic
template.

Additionally, you often find that the organizations still using BRDs (as there has been a significant uptick in traditional
financial services moving from Waterfall to Agile, where BRDs are not used) will generally have a split between the
“business side” Business Analyst and the IT Business Analyst. This template also captures that split, as well as how the
functions overlap (e.g., for a BRD the IT Business Analyst is not just a reviewer but should be an approver since they
need to confirm their understanding as this is the baseline document for them to continue their work in functional analysis
and/or technical specifications).

Lastly, the project manager needs to sign off on all documentation, if only as a confirmation that the work has been done,
it’s been appropriately reviewed and approved, and they will adhere to the change management process (as necessary)
in the future to maintain the validity of the requirements.
 Business Requirements Document: Customer/Client Sign-off

Document Name Project ID

Document Type Project Name

Document Project Sponsor

Version

Document Author Project Manager

Document Description Link to Document

(Description of this document) (Sharepoint, Share Drive,

Embedded)

Reference Documents Link to Document

(Document Name) (Sharepoint, Share Drive,

Embedded)

IMPACTED APPLICATIONS

Application ID Application Name Function / Description

(Org ID, if (e.g. Trading Platform –

applicable) Commodities)

SCOPE OF APPROVAL

Agreement that the business requirements as defined within this document (or series of documents) are reflective
of business needs for the defined scope of the project and/or phase. These represent the baseline business
requirements for which subsequent documentation (e.g. functional requirements, technical specifications, test
scripts/cases, etc.) or activities (systems analysis, infrastructure build, code development, etc.) will be completed.

Agreement that any future changes to these requirements to be reviewed/agreed by impacted parties as part of the
agreed change management process.

Agreement that additional work to define more detailed requirements and/or technical specifications can start or
continue through to completion.

Agreement that development can start or be continued through to completion.

(Add any other organization specific needs that are used to define what the approver is responsible/accountable
for)

REVIEWERS

Name Department Role / Function Version/Date

Approved/Comments

Program Manager (Embed / link if e-mailed)

Peer Review

IT Development
Manager

Enterprise Architecture

QA Manager

(Other types of
reviewers)

APPROVERS

Name Department Role / Function Version/Date

Approved/Comments

Project Sponsor (Embed / link if e-mailed)

Business SME

Business Product
Manager

IT Business Analyst

Project Manager

(Other types of
reviewers)