Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Back casting - a flow chart junkies approach - Oracle Primavera P6 Collaborate 14


Published on

For more slides and tutorials visit

Source: Collaborate 14

Published in: Business
  • Be the first to comment

  • Be the first to like this

Back casting - a flow chart junkies approach - Oracle Primavera P6 Collaborate 14

  1. 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. 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. 3. Overview ■ Today we will cover: • Why are we here? • Why does this matter? • How do we get started?
  4. 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. 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. 6. Example of Project Management System
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 25. Swimlane Flowchart Example
  26. 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. 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. 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. 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. 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