Back casting - a flow chart junkies approach - Oracle Primavera P6 Collaborate 14
Check in on the
COLLABORATE mobile app
Back-Casting: A Flow Chart Junkie’s Approach to
Use Case Requirements for Primavera Unifier
Cari Stieglitz, PMP
Program Director – ePM Service Lead
This is a subtitle for the presentation
that can be extended to three lines
■ 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
■ Today we will cover:
• Why are we here?
• Why does this matter?
• How do we get started?
Why are we here?
■ The goals and objectives of this session are:
• Remind us why requirement sessions are vital to project
• Learn how to facilitate requirements gathering sessions.
• Know how to visually diagram a process to expose more
• Learn how to use the same diagram to verify requirements and
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
• Complex system with many processes touching other
• 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
Take a Second
■ Think about the last major implementation or continuous
• 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?
• 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
• “Sometimes the customer doesn’t know what they want”
• 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
Types of Requirements
• Solving Problems
• Project Management
■ You must look for all requirements, not just those related
to the product of the project.
Inputs and Output to Requirements
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.
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
• Asks questions like “Who can make this project a success?” and
“Who can block this project’s success?”
Before Requirements: Stakeholder
■ 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
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?
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
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
• Consensus: General agreement; those who prefer other
options are willing to accept there decision the majority
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
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
■ Same requirements process can be used for both sessions
■ Keep the same “Action Statements” for user acceptance
testing and help file creation
Example: Use Case or “Actions” per Stage
All Stage Gates Planning Design Pre-Construction Construction Closeout
Logging in and
Issuing Requests for
Creating a Contract
items in the Submittal
and As-Builts, etc.
Entering a PO/Task
Providing Submittals Closing out Permits
Requesting a New
Revising the Authorized
Revising a PO
Issuing Letter of
Issuing Requests for
Creating a Vendor
between Line Items
Entering a PO/TA
Entering and Viewing
Entering a Vendor
Navigating the Project
Viewing Vendor Cost
Issuing a Non-
Tracking Risks & Issues
Reconciling Unifier to
Entering and Updating
Tracking Change Control
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
Example: Use Case, processing an invoice
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
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.
■ 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?
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
• Don’t “resolve” problems – just keep asking questions.
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
• What else can go wrong? Why does this matter?
• Are there any other steps that could happen here?
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
■ Requirements feed into scope and business
■ Use the same “Action Statements” and language for use
cases, testing scripts and training/help files.
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?
■ 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?
Please complete the session
We appreciate your feedback and insight
You may complete the session evaluation either
on paper or online via the mobile app