Reengineering the Acquisition/Procurement Process:  Requirements Collection Methodology<br />and                  Thomas V...
Agenda<br />Project Methodology<br />Requirements Collection<br />Customer Sessions<br />Customer Voting<br />Stakeholder ...
Project Approach<br />Utilize Lean Six Sigma and Reengineering methodologies and techniques<br />Focus on the Customer, an...
Project Methodology<br />Major improvement can come about through a single paradigm change, or by a combination of smaller...
Methodology: Project Plan<br /><ul><li>Each phase has required products and independent reviews
Phase A: Concept Studies/Development
Validate Customers, Stakeholders, and Process Performers
Requirements; Concept; Prelim. Concept of Operations; Prelim. Project Plan
Concept Review
Phase B: Preliminary Design
Requirements (baseline); Prelim. Design; Concept of Operations; Project Plan; Integrated Baseline (tech-sched-cost)
Pre-PDR peer reviews; PDR; Confirmation Review
Phase C: Final Design & Build
Phase D: System Assembly, I&T, and Launch
Phase E: Operations & Sustainment</li></ul>Phase B<br />Phase C<br />Phase D<br />Phase E<br />Phase A<br />
Acquisition Reengineering Activity 1:Gather Customer Requirements<br />Activity 1 - Requirements Generation<br />Objective...
Requirements collection & analysis tools<br />Customer/stakeholder/process performer groups identified<br />Collection ses...
Source Type, e.g., Project Manager
Requirement statement
Requirement rationale
Requirement impact
Upcoming SlideShare
Loading in …5
×

Taylor.randall

13,700 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
13,700
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Taylor.randall

  1. 1. Reengineering the Acquisition/Procurement Process: Requirements Collection Methodology<br />and Thomas Vanek<br /> Booz Allen Hamilton<br />NASA PM Challenge 2011<br /> February 9–10, 2011<br /> Randall L. Taylor<br /> Project ManagerAcquisition Reengineering Project<br /> Jet Propulsion Laboratory<br /> California Institute of Technology<br />Copyright © 2010. All rights reserved.<br />
  2. 2. Agenda<br />Project Methodology<br />Requirements Collection<br />Customer Sessions<br />Customer Voting<br />Stakeholder and Process Performer Sessions<br />Preliminary Benchmarking<br />Preliminary Requirements<br />Quick Hits <br />Where are we Now? <br />
  3. 3. Project Approach<br />Utilize Lean Six Sigma and Reengineering methodologies and techniques<br />Focus on the Customer, and how we can do a better job.<br />In line with the Acquisition Division Mission & Vision<br />The Project is “Exploratory”.<br />Explore solutions that make life better for Subcontract Managers & Contract Technical Managers<br />The Project is conducted like a flight project, using various tools & techniques<br />
  4. 4. Project Methodology<br />Major improvement can come about through a single paradigm change, or by a combination of smaller but important changes.<br />FY09<br />FY10<br />
  5. 5. Methodology: Project Plan<br /><ul><li>Each phase has required products and independent reviews
  6. 6. Phase A: Concept Studies/Development
  7. 7. Validate Customers, Stakeholders, and Process Performers
  8. 8. Requirements; Concept; Prelim. Concept of Operations; Prelim. Project Plan
  9. 9. Concept Review
  10. 10. Phase B: Preliminary Design
  11. 11. Requirements (baseline); Prelim. Design; Concept of Operations; Project Plan; Integrated Baseline (tech-sched-cost)
  12. 12. Pre-PDR peer reviews; PDR; Confirmation Review
  13. 13. Phase C: Final Design & Build
  14. 14. Phase D: System Assembly, I&T, and Launch
  15. 15. Phase E: Operations & Sustainment</li></ul>Phase B<br />Phase C<br />Phase D<br />Phase E<br />Phase A<br />
  16. 16. Acquisition Reengineering Activity 1:Gather Customer Requirements<br />Activity 1 - Requirements Generation<br />Objective: to capture customer requirements as the basis for proposing a concept (and subsequent design) that meets the requirements in a verifiable manner<br />Requirements are solicited from:<br />Customers – primary customers are Project Managers and Proposal Managers<br />Stakeholders – we have a long list (e.g., Legal, Property, Invoice Management, Engineering and SMA management…)<br />Process Performers – buyers, negotiators, Contract Technical Managers (primary), others<br />Employ a modified version of the JPL Resource Management System technique <br />Products include preliminary requirements set & recommended “quick hits” (Lean Six Sigma Kaizen events and Just-Do-Its) for implementation<br />Establish JPL acquisition process definition<br />Phase A<br />Phase B<br />Phase C<br />Phase D<br />Phase E<br />
  17. 17. Requirements collection & analysis tools<br />Customer/stakeholder/process performer groups identified<br />Collection sessions technique(s) mapped out<br />Session pre-work conducted prior to each session<br />Customer Requirements Collection Method<br />Illustrative<br />Sampling of requirement fields<br /><ul><li>Source Name
  18. 18. Source Type, e.g., Project Manager
  19. 19. Requirement statement
  20. 20. Requirement rationale
  21. 21. Requirement impact
  22. 22. Requirement source
  23. 23. Mandatory?
  24. 24. Top Five?
  25. 25. Requirement category
  26. 26. Disposition
  27. 27. Disposition Rationale
  28. 28. Process Owner
  29. 29. Stakeholders
  30. 30. References
  31. 31. Implementation Method
  32. 32. Verification method
  33. 33. Status
  34. 34. Comments</li></li></ul><li>Customer Sessions<br />
  35. 35. Customer Voting<br />Summary<br />Following the Customer sessions, performed preliminary data analysis, identified the most commonly voiced/most impactful ideas, and prepared an electronic ballot for Customer voting.<br />51% of customers who attended the Customer Sessions responded.<br />Customers were asked to <br /> (1) make choices from a list of 40 items based on importance (Not Important at all, Fairly Important, Very Important) and <br /> (2) respond with the Top 5 items from the list by typing the number of his/her selections in an input box.<br />General<br />Email with link to ballot was sent to customers on the <br /> morning of Monday, May 17<br />Eligible voters: 224<br />How many have voted: 115<br />Voting complete: May 25<br />Sample<br />
  36. 36. Ballot Analysis<br />Customer voting is one data point — but a very important one. <br />The customer voting process proved to be an excellent communication/feedback mechanism for the customers: they felt they were heard. <br />It also proved to be a useful educational vehicle for the Acquisition Division process performers who attended the sessions.<br />Voting analysis focused on five “cuts” at the data:<br />1. Those items receiving the largest number of “5” ratings <br />Ten items received 35 or more votes in this range, which means that at least 30% of those who voted rated them the most important (despite some voters finding the item not applicable to them).<br />2. Those items receiving the largest number of combined “4” and “5” ratings.<br />Thirteen items received 50 or more votes in this range, which means at least 44% of those who voted rated them high (despite some voters finding the item not applicable).<br />3. Those items receiving the largest number of “Top Five” designations.<br />4. Those items specific to Commodities receiving high ratings.<br />5. Those items specific to Subcontracts/Bypass receiving high ratings.<br />
  37. 37. Customer Ballot email sent 5/17/10<br />
  38. 38. Customer Voting: Part 1(115 responses)<br />The following are the items rated a 5 on the scale ranging from 1: Not important at all to 5: Very important.<br />The following are the items rated either 4 or 5 on the scale ranging from 1: Not important at all to 5: Very important.<br />
  39. 39. Administrative Divisions/Stakeholder Sessions<br />
  40. 40. Process Performer Sessions<br />
  41. 41. Objective: To identify key acquisition/procurement major process improvement areas that might not surface from the requirements collection sessions, but have been previously done by other Acquisition initiatives.<br />Methodology<br />Literature search, by Booz Allen Hamilton and by JPL, plus review of relevant Acquisition Div. activities.<br />Reviewed the following Division activities<br />Division Strategic Plan — BAH compared project Preliminary Requirements to the Strategic Plan<br />Idea Summits — BAH compared project Preliminary Requirements to the collected ideas<br />R2C — JPL reviewed scope of potential Oracle Advanced Purchasing Suite implementation against the Project Plan<br />KPIs — BAH compared project Preliminary Requirements to the proposed Key Performance Indicators<br />Benchmarking resulted in some changes to the Preliminary Requirements (and ideas for Quick Hits and Phase A2/3 study)<br />Preliminary (Coarse) Benchmarking<br />
  42. 42. Booz Allen Benchmarking Materials – JPL Analysis – P1<br />* See Backup slides for references: “Appendix: Booz Allen Benchmarking References”<br />
  43. 43. Preliminary Requirements<br />Objective of preliminary requirements: to serve as the basis for conducting Phase A2/3 conceptual design and targeted benchmarking; also provides a resource to identify Quick Hits for management.<br />Methodology<br />Reviewed brainstorming ideas from customers, stakeholders, and process performers<br />Reviewed ballot results<br />Reviewed BAH & JPL benchmarking materials<br />Turned the most popular and/or most promising ideas into preliminary requirements<br />Added a small number of constraints that the new process must comply with<br />BAH tested the draft preliminary requirements set against the Division Strategic Plan (goals and actions) and against the Idea Summits brainstorming ideas<br />Results were very good (not identical) alignment.<br />
  44. 44. Acquisition ReengineeringPreliminary Requirements P1<br />Requirement 1. Programs, Projects, Tasks, and Proposals shall contact Acquisition at the beginning of their life cycle to formulate acquisition strategy and negotiate support commitments.<br />Requirement 2. Acquisition transactions shall be planned to support project/task and one-year-money need dates. Planning shall include end user and supporting discipline rec-dels.<br />Requirement 3. The process shall identify multiple acquisition strategy options for support effort subcontracts.<br />Requirement 4. The process shall identify multiple acquisition strategy options for system contract subcontracts.<br />Requirement 5. The process shall track purchase requisition entry through purchase order award and purchase order award through purchase order closure, while publishing the cycle time metrics for customers.<br />Requirement 6. Purchase Requisition required steps and responsible parties shall be published for end users (requestors) and preparers.<br />Requirement 7. Special Provisioners shall be established to acquire designated products and services for the end users in lieu of a Purchase Requisition transaction.<br />Requirement 8. Procurement Control Points shall be established only where necessary and approved and shall process requests within a goal of 1 work day.<br />Requirement 9. The process shall establish a method for identifying significant repetitive-buy commodities and options for quickly acquiring them.<br />Requirement 10.iProcurement shall be enhanced by expansion of included commodities and improved user search capabilities.<br />
  45. 45. Quick Hits<br />“Quick Hits” are process improvement ideas that meet the following criteria:<br />They have clear value to customers (primarily), stakeholders, and process performers<br />They are properly sized to be implemented within 6 months or less (Kaizen-sized or smaller)<br />They do not require any programming by Institutional IT<br />The necessary resources are available and fit within the Acquisition Division budget (or possible small augmentation)<br />Their implementation is not expected to introduce impediments to the broader process reengineering effort<br />An improvement opportunity that requires more study, or otherwise does not meet the above criteria, would be included in the Phase A/B reengineering activity.<br />Quick Hits may be implemented in several ways, e.g.:<br />Just Do It<br />Facilitated focus group<br />Acquisition mini-team<br />Kaizen event<br />The list of recommended Quick Hits is a menu for management to choose from.  They can be implemented in any order.  Apart from Just Do it items, prudence dictates embarking on a maximum of 3 Quick Hits per quarter (to ensure adequate oversight and synergistic coordination with other activities as well as to put less strain on the budget).  <br />
  46. 46. Where Are We Now?<br />Completed purchase requisition sub-process reengineering (11 “enablers” all operational)<br />Completed Standard Subcontract Data Requirements (SDRL/DRDs) (official in command media)<br />Received ATP for two Quick Hits <br />Control points sub-process <br />Communication norms<br />Initiated planning for Advanced (Targeted) Benchmarking activity<br />
  47. 47. Summary<br />Completed 44 requirements collection sessions with 391 persons, representing customers, stakeholders, and process performers<br />Conducted customer voting with a 51% response rate<br />Performed preliminary benchmarking<br />Generated process Preliminary Requirements to guide new process conceptual design<br />Provided recommended Quick Hits for management consideration<br />Refined the plan for conceptual design phase<br />— Additional information is available in IEEE paper, “Reengineering the Acquisition/Procurement Process: A Methodology for Requirements Collection” (available from the authors)<br />

×