This document provides an overview of a presentation on using a "back-casting" approach to gather requirements for implementing Primavera Unifier. The presentation recommends (1) mapping out stakeholders and their needs, (2) creating a forward flow chart of current processes to identify pain points, and (3) working backwards through the flow chart to uncover additional requirements and benefits. Examples of using swimlane diagrams and questioning between steps are provided. The goal is to thoroughly understand requirements to ensure project success and adoption of the new system.

1. REMINDER
Check in on the
COLLABORATE mobile app
Back-Casting: A Flow Chart Junkie’s Approach to
Use Case Requirements for Primavera Unifier
Prepared by:
Cari Stieglitz, PMP
Program Director – ePM Service Lead
Faithful+Gould
This is a subtitle for the presentation
that can be extended to three lines
Session ID#:

2. Introduction
■ Cari Stieglitz, PMP
• ePM Service Lead for Faithful+Gould
• Implemented numerous PMO’s, Project and Program Standards
• Trained in Policy, Procedure and Process writing
• Background in Product Development and Project Management
• Side jobs in Training and Customer Success Management

3. Overview
■ Today we will cover:
• Why are we here?
• Why does this matter?
• How do we get started?

4. Why are we here?
■ The goals and objectives of this session are:
• Remind us why requirement sessions are vital to project
success.
• Learn how to facilitate requirements gathering sessions.
• Know how to visually diagram a process to expose more
requirements.
• Learn how to use the same diagram to verify requirements and
document benefits.

5. How does this apply to Primavera Unifier?
■ Implementing Unifier:
• Implementing a Project Management System – lifecycle and
stage gate methodology with attention to people, process and
templates/tools.
• Complex system with many processes touching other
processes.
• Large change in culture across many stakeholder groups – need
stakeholder input to ensure success and adoption.
• Written processes versus reality – what we have documented
isn’t always what happens because we find workarounds and
solutions.

6. Example of Project Management System

7. Take a Second
■ Think about the last major implementation or continuous
improvement exercise:
• How were requirements gathered for your last project? Who was
chosen to be part of the efforts?
• What surprise requirements were exposed later in the project?
• Did the customer have any complaints with the deliverable?
• How were these “surprise” requirements handled? Were they
included? What was the impact?

8. Common Mistakes
• Not taking time to actually properly gather requirements.
• Using the RFP or RFQ as the final requirements.
• Accepting requirements from one group – without conducting
stakeholder identification exercises.
• Accepting requirements from customers without asking
questions.
• “Sometimes the customer doesn’t know what they want”

9. Introducing “Back-casting”
• Crack the whip! (or fly fishing)
• Similar to forward/backward pass done in a schedule
• Look at the requirements multiple ways in different ways
• Recite the alphabet backwards – stop and think instead of go
through the motions

10. Types of Requirements
• Solving Problems
• Capabilities
• Quality
• Process
• Project Management
■ You must look for all requirements, not just those related
to the product of the project.

11. Requirements
Documents
Requirements
Management
Plan
Requirements
Traceability
Matrix
Project
Charter
Stakeholder
Register
Interviews
Focus Groups
Facilitated
Workshops
Group creativity
and decision
making
techniques
Questionnaires
or surveys
Observations
Prototypes
Inputs and Output to Requirements

12. Before you Begin: “Signed” Charter
■ Charter (or Business Case or Statement of Work)
• Officially defines the Business Need and Goals for the project.
• Sets initial key roles and governance
• Drives which requirements will or will not be adopted.

13. Before you Begin: Stakeholder Analysis
■ Stakeholder Analysis Worksheet
• Asks questions about the project and who is involved.
• To be worked through by the Project Manager, key managers
and executives.
• Asks questions like “Who can make this project a success?” and
“Who can block this project’s success?”

14. Before Requirements: Stakeholder
Identification
■ Stakeholder Register/ Communication Plan
• Outlines each Stakeholder that meets the threshold and how
they will be communicated with during the project.
• Input to Requirements Gathering, Group Brainstorming and
Workshop phase.

15. Before the Session
■ Prepare and document your approach:
• Choose your approach (pre-workshop survey, 1:1 Interviews,
Decision Making, etc.)
• Communicate, communicate and communicate
• How the session will be handled?
• Which questions will be asked?
• What are the goals and expectations?

16. During the Session
• Communicate roles
• Keep conversation open and forward moving
• Know when to put an item on the parking lot
• Group think isn’t always bad
• Answer questions with questions
• Focus on “Need” statements – not solutions!
• Set expectations

17. Set expectations for decision making
• Agree on “how” the group decision will be made.
• Unanimously: Everyone agrees
• One Person (Dictatorship): Reduces stakeholder buy in
• Majority Rules: More than half or plurality (most votes per
option)
• Consensus: General agreement; those who prefer other
options are willing to accept there decision the majority
supports.

18. During the Session: Back-casting
■ The forward pass: A list format of the process with a “Who”
and “Action” column. We will ignore what goes wrong and
how much time it takes.
■ The backward pass: Starting at the end, we will focus on the
relationships between only two steps at a time. We will
determine durations, pain points and issues.
■ The overall review: We will highlight the biggest issues and
translate those into requirements and benefits by asking
multi-level questions.

19. Methodology and Use Cases
■ Two levels:
• Action statements at a higher level eg “Processing an
Invoice” feed into your methodology mapping and Stage Gate
• Detailing these individual actions step by step creates our use
case content
■ Same requirements process can be used for both sessions
■ Keep the same “Action Statements” for user acceptance
testing and help file creation

20. Example: Use Case or “Actions” per Stage
Gate
All Stage Gates Planning Design Pre-Construction Construction Closeout
Logging in and
Setting
Preferences
Documenting Estimates
Issuing Requests for
Proposal
Creating a Contract
Capturing Contracts
items in the Submittal
Register
Tracking Warranties
and As-Builts, etc.
Navigating Unifier
Entering Approved
Budgets
Entering a PO/Task
Authorizations
Creating Contract
Revisions
Providing Submittals Closing out Permits
Requesting a New
User
Revising the Authorized
Budget
Revising a PO
Issuing Letter of
Authorization
Issuing Requests for
Information (RFI)
Lessons Learned
Creating a Vendor
Prequal
Transferring Budget
between Line Items
Entering a PO/TA
Invoice
Submitting a
Contract Invoice
Entering and Viewing
Transmittals
Completing a
Punchlist
Entering a Vendor
Navigating the Project
Cost Sheet
Viewing Vendor Cost
Information
Owner's
Observations
Issuing a Non-
Compliance
Entering Agendas
and Meeting
Minutes
Tracking Risks & Issues
Reconciling Unifier to
Financial Systems
Architect/Engineer
Observations
Tracking Incidents
Adding and
updating Action
Items
Providing Monthly
Updates
Tracking Design
Reviews
Recording Daily
Reports
Conducting Controlled
Inspection
Issuing General
Correspondence
Architect’s
Supplemental
Instructions
Confirming
Stakeholder Needs
Entering and Updating
Permits
Completing Design
Reviews
Tracking Change Control
Tracking Architect
Changes

21. Starting the Forward Pass
• Provide the high level action(s) prior to the meeting or start
in work groups
• Capture the process, using a “who” or Actor, numbered list
and statements that begin with action words.
• Capture time with “After” or “Before” statements and
exceptions with “If”.
• Predecessor to creating the Use Case

22. Example: Use Case, processing an invoice
Who Action
Contractor 1. After completing the work, generates the invoice
2. Mails the invoice.
Front Office 3. After the receiving the invoice, stamps with date received.
4. Places in Project Manager’s interoffice mail.
Project Manager 5. After receiving the invoice, verifies the work billed has been approved and
completed.
5a. If the work is not aligned with the invoice, sends invoice back to contractor
and ends process.
6. Verifies invoice against budget and updates project cost sheets.
7. Stamps invoice with approved and writes account code and PO on invoice.
8. Places invoice in Accounts Payable inbox.
Accounts Payable 9. Enters invoice into accounting system.
10. Generates check.
11. Mails check to contractor.
Contractor 12. Receives payment.

23. Ask Questions
■ What starts the process?
■ Who hands does it pass through?
■ Is it electronic or physical?
■ Do they approve it?
■ Who else verifies, approves or sees it?
■ Is there coding involved? How/where is it entered?
■ Is information entered in multiple steps? Duplicated?

24. Mapping the Table to Swimlane Flow Charts
• Identify the “who” lanes.
• Beginning at the end, visually document the last step.
• Start moving backward and ask questions in between each
step.
• Don’t “resolve” problems – just keep asking questions.

25. Swimlane Flowchart Example

26. Back-Casting: Now go the other way
Between each step:
• Is this really the previous step?
• How long does it take between these two steps?
• What can go wrong? How does that affect duration or
process?
• What else can go wrong? Why does this matter?
• Are there any other steps that could happen here?

27. Just the beginning…
■ Circle or identify “pain points”, inefficiencies or
unnecessary lags – these feed into your road map,
implementation program and benefits register.
■ Translate these into requirements statements (not
solutions!).
■ Requirements feed into scope and business
requirements documentation.
■ Use the same “Action Statements” and language for use
cases, testing scripts and training/help files.

28. Revisiting the Requirements
Change Management – add new requirements as they are
discovered…determine if they are in scope, and which
phase they should be included in.
During or after project, review the requirements
documentation and compare to your benefits.
• Were issues resolved?
• Does it still take x days?
• Are there new pain points?

29. Closing
■ What benefits do you see in this approach?
■ Did we uncover additional requirements?
■ What industry are you in? How can you use this or
adapt it to your industry?
■ Questions for me?

30. Please complete the session
evaluation
We appreciate your feedback and insight
You may complete the session evaluation either
on paper or online via the mobile app