Solutions-Based Procurement for Information Technology Acquisitions Michael B. Spicer South Carolina Chief Procurement Off...
Gartner and Forrester <ul><ul><li>70% - 75% of all IT projects fail </li></ul></ul><ul><ul><li>Success Criteria: </li></ul...
Background South Carolina <ul><li>Consolidated Procurement Code enacted in 1981 </li></ul><ul><ul><li>Based on the ABA Mod...
Background South Carolina <ul><li>1981 Code - Request For Proposals   </li></ul><ul><ul><li>Seven Paragraphs  </li></ul></...
Background South Carolina <ul><li>1993  </li></ul><ul><ul><li>Expanded negotiations to include scope </li></ul></ul><ul><u...
Gartner and Forrester <ul><li>70% - 75% of all IT projects fail </li></ul><ul><li>Success Criteria: </li></ul><ul><ul><li>...
A Prescription for Failure <ul><li>The Boss or end user calls IT department and says:   </li></ul><ul><ul><li>I need this ...
A Prescription for Failure <ul><li>1970s  </li></ul><ul><ul><li>Data Processing was in the “glass” room </li></ul></ul><ul...
“ Problem” Definition <ul><li>Project Manager meets with end user to identify the problem </li></ul><ul><ul><li>End users ...
End Users Define Problems in Terms of Symptoms <ul><li>Symptoms may emanate from more than one problem </li></ul><ul><li>O...
Technologists Define Problems in Terms of Solutions <ul><li>Search the marketplace looking at possible solutions to the “P...
“Problem” Definition <ul><li>The Problem is not a set of symptoms </li></ul><ul><li>The problem is not a technological pro...
Detailed Specifications <ul><li>After reviewing as many solutions as time allows (6 mos.), the end user and project manage...
Firm-Fixed Price <ul><li>We ask vendor to propose a firm-fixed price for a poorly defined “Problem”  </li></ul><ul><li>Que...
Contract Management <ul><li>State’s Project Manager  – Technologist </li></ul><ul><ul><li>“ Problem” not properly & comple...
Failure to Define the Problem <ul><li>Failure to properly and completely identify the Business Problem results in: </li></...
A Solutions-Based Procurement <ul><li>Request for Qualifications </li></ul><ul><li>Request for Proposals </li></ul><ul><li...
Request For Qualifications <ul><li>A description of the scope of the work to be solicited by the RFP </li></ul><ul><li>Req...
The Solutions-Based RFP <ul><li>Organizational Background </li></ul><ul><li>Define the Current Business Environment </li><...
Organizational Background <ul><li>Organizational History </li></ul><ul><li>Mission </li></ul><ul><li>Agency Budget </li></...
Define the Current Business Environment <ul><li>Current Processes and Procedures Directly or Indirectly Related to This Pr...
Define the Current Technical Environment <ul><li>All Hardware and Software Currently Used to Address the Requirements of T...
Define the Problem <ul><li>Define the Problem, Not The Solution </li></ul><ul><li>The Problem is ALWAYS a Business Problem...
Evaluating Demonstrations? <ul><li>Demonstrations </li></ul><ul><ul><li>Validation </li></ul></ul><ul><ul><ul><li>Highest ...
Perform Agency Risk Analysis <ul><li>Perform agency risk analysis </li></ul><ul><ul><li>Identify any internal or external ...
Business Proposal or Cost? <ul><li>If cost is not an evaluation criteria, you may consider a business proposal including c...
Business Proposal? <ul><li>Total Cost of Ownership </li></ul><ul><li>Risk Analysis of proposed solution </li></ul><ul><li>...
Cost? <ul><li>Offeror to include project risk analysis, risk mitigation plan, implementation plan, options, staffing plan,...
Considering Options <ul><li>Offerors may have multiple solutions to the same functional requirement, each of which will wo...
Offeror’s Original Proposal Offeror’s Technical Proposal Offeror’s Business Proposal -$$ -$$$ +$ Fully compliant with all ...
Determine Evaluation Methodology <ul><li>Traditional RFP Evaluation Committee </li></ul><ul><li>RFP Evaluation Committee  ...
Subject Matter Evaluation <ul><li>Program personnel only evaluate program portions of proposal </li></ul><ul><li>Technolog...
Determine Evaluation Criteria <ul><li>Functional Capabilities:   How well does the proposed solution meet the needs of the...
Determine Evaluation Criteria <ul><li>Installation and Support:  The degree to which the proposed installation and support...
Set Desired Proposal Format <ul><li>Submittal Letter </li></ul><ul><li>Executive Overview </li></ul><ul><li>Technical Over...
Evaluation and Award <ul><li>Evaluation of Options </li></ul><ul><li>Oral Presentations and Discussions </li></ul><ul><li>...
Final and Conclusive <ul><li>The determinations required by the Code are final and conclusive, unless clearly erroneous, a...
Conclusion <ul><li>Define the Problem, not the solution </li></ul><ul><li>Technology not the problem, IT is a solution </l...
Questions?
Upcoming SlideShare
Loading in …5
×

Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006

617 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
617
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006

  1. 1. Solutions-Based Procurement for Information Technology Acquisitions Michael B. Spicer South Carolina Chief Procurement Officer for Information Technology
  2. 2. Gartner and Forrester <ul><ul><li>70% - 75% of all IT projects fail </li></ul></ul><ul><ul><li>Success Criteria: </li></ul></ul><ul><ul><ul><li>On time </li></ul></ul></ul><ul><ul><ul><li>Within Budget </li></ul></ul></ul><ul><ul><ul><li>Originally Defined Functionality </li></ul></ul></ul>
  3. 3. Background South Carolina <ul><li>Consolidated Procurement Code enacted in 1981 </li></ul><ul><ul><li>Based on the ABA Model Code drafted in 1970s </li></ul></ul><ul><ul><li>Preferred source selection method is Invitation To Bid </li></ul></ul>
  4. 4. Background South Carolina <ul><li>1981 Code - Request For Proposals </li></ul><ul><ul><li>Seven Paragraphs </li></ul></ul><ul><ul><li>“The request for proposals shall state the relative importance of price and of each other evaluation factor …” </li></ul></ul><ul><ul><li>Negotiations limited to price. </li></ul></ul>
  5. 5. Background South Carolina <ul><li>1993 </li></ul><ul><ul><li>Expanded negotiations to include scope </li></ul></ul><ul><ul><li>Price need not be an evaluation factor </li></ul></ul><ul><li>1997 </li></ul><ul><ul><li>Two-Part RFP </li></ul></ul><ul><ul><ul><li>Request For Qualifications </li></ul></ul></ul><ul><ul><ul><li>RFP </li></ul></ul></ul><ul><ul><li>Best Value Bidding </li></ul></ul><ul><ul><ul><li>Cost at least 60%, other factors 40% </li></ul></ul></ul>
  6. 6. Gartner and Forrester <ul><li>70% - 75% of all IT projects fail </li></ul><ul><li>Success Criteria: </li></ul><ul><ul><li>On time </li></ul></ul><ul><ul><li>Within Budget </li></ul></ul><ul><ul><li>Originally Defined Functionality </li></ul></ul>
  7. 7. A Prescription for Failure <ul><li>The Boss or end user calls IT department and says: </li></ul><ul><ul><li>I need this report </li></ul></ul><ul><ul><li>I need to process this form </li></ul></ul><ul><ul><li>I need to automate this process </li></ul></ul>
  8. 8. A Prescription for Failure <ul><li>1970s </li></ul><ul><ul><li>Data Processing was in the “glass” room </li></ul></ul><ul><ul><li>All IT acquisitions were data processing department responsibility </li></ul></ul><ul><ul><li>IT Director assigns someone to manage project </li></ul></ul><ul><ul><ul><li>The best programmer in the department </li></ul></ul></ul><ul><ul><ul><li>The programmer not busy at the time </li></ul></ul></ul><ul><ul><ul><li>Maybe even a programmer analyst </li></ul></ul></ul>
  9. 9. “ Problem” Definition <ul><li>Project Manager meets with end user to identify the problem </li></ul><ul><ul><li>End users identify problems in terms of symptoms </li></ul></ul><ul><ul><li>Technologists identify problems in terms of solutions </li></ul></ul>
  10. 10. End Users Define Problems in Terms of Symptoms <ul><li>Symptoms may emanate from more than one problem </li></ul><ul><li>One problem may generate more than one symptom </li></ul><ul><li>There may be multiple symptoms emanating from multiple problems </li></ul><ul><li>Fixing symptoms may not solve the problem </li></ul>
  11. 11. Technologists Define Problems in Terms of Solutions <ul><li>Search the marketplace looking at possible solutions to the “Problem” </li></ul><ul><li>The Solutions are identified in terms of </li></ul><ul><ul><li>Software and/or hardware that solves the end user’s “Problem” </li></ul></ul>
  12. 12. “Problem” Definition <ul><li>The Problem is not a set of symptoms </li></ul><ul><li>The problem is not a technological problem </li></ul><ul><li>The Problem is a business problem </li></ul><ul><ul><li>I need to perform a business operation more efficiently </li></ul></ul><ul><ul><li>I need to perform a newly assigned business operation </li></ul></ul><ul><li>Define the Problem, not a solution </li></ul><ul><li>Technology is not the Problem, IT is a solution </li></ul>
  13. 13. Detailed Specifications <ul><li>After reviewing as many solutions as time allows (6 mos.), the end user and project manager create detailed specifications </li></ul><ul><ul><li>Define an existing manual or automated system </li></ul></ul><ul><ul><li>Define specific vendor’s solution </li></ul></ul><ul><ul><li>Define a solution that does not exist </li></ul></ul><ul><li>Can anyone say PROTEST? </li></ul><ul><ul><li>Define a minimum acceptable level of performance </li></ul></ul>
  14. 14. Firm-Fixed Price <ul><li>We ask vendor to propose a firm-fixed price for a poorly defined “Problem” </li></ul><ul><li>Question: </li></ul><ul><li>If you define the solution and it does not work, who is responsible? </li></ul><ul><li>If the vendor defines the solution and it does not work who is responsible? </li></ul>
  15. 15. Contract Management <ul><li>State’s Project Manager – Technologist </li></ul><ul><ul><li>“ Problem” not properly & completely defined </li></ul></ul><ul><li>Contractor </li></ul><ul><ul><li>Contract signers and promisers never seen again </li></ul></ul><ul><ul><li>Contractor’s PM – Professional </li></ul></ul><ul><ul><ul><li>Efficient, profitable project – success optional </li></ul></ul></ul><ul><ul><li>Contract Compliance Manager </li></ul></ul><ul><ul><ul><li>Make sure contractor complies with contract </li></ul></ul></ul><ul><ul><ul><li>Generate change orders whenever possible </li></ul></ul></ul>
  16. 16. Failure to Define the Problem <ul><li>Failure to properly and completely identify the Business Problem results in: </li></ul><ul><ul><li>Scope Creep </li></ul></ul><ul><ul><li>Delays </li></ul></ul><ul><ul><li>Cost Overruns </li></ul></ul><ul><ul><li>Contract Modifications and Change Orders (maybe) </li></ul></ul>
  17. 17. A Solutions-Based Procurement <ul><li>Request for Qualifications </li></ul><ul><li>Request for Proposals </li></ul><ul><li>Pre Proposal Conference </li></ul><ul><li>Receipt of Proposals </li></ul><ul><li>Evaluation </li></ul><ul><li>Award </li></ul><ul><li>Looks like an RFP, doesn’t it? </li></ul>
  18. 18. Request For Qualifications <ul><li>A description of the scope of the work to be solicited by the RFP </li></ul><ul><li>Require information only on their qualifications, experience, and ability to perform the requirements of the contract. </li></ul><ul><li>Responses ranked from most qualified to least qualified. </li></ul><ul><li>Proposals solicited from at least the top two qualified offerors </li></ul><ul><li>Failure to be selected to receive RFP is not subject to protest </li></ul>
  19. 19. The Solutions-Based RFP <ul><li>Organizational Background </li></ul><ul><li>Define the Current Business Environment </li></ul><ul><li>Define the Current Technical Environment </li></ul><ul><li>Define the Business PROBLEM </li></ul><ul><li>Demonstrations </li></ul><ul><li>Business Proposal or Cost </li></ul><ul><li>Options </li></ul><ul><li>Minimum Offeror Qualifications </li></ul><ul><li>Evaluation Criteria </li></ul><ul><li>Desired Proposal Format </li></ul>
  20. 20. Organizational Background <ul><li>Organizational History </li></ul><ul><li>Mission </li></ul><ul><li>Agency Budget </li></ul><ul><li>Organizational Structure </li></ul><ul><li>Number of Employees </li></ul>
  21. 21. Define the Current Business Environment <ul><li>Current Processes and Procedures Directly or Indirectly Related to This Project </li></ul><ul><li>Current Legal or Business Mandates </li></ul><ul><li>Any Procedural or Process Documentation Directly or Indirectly Related to This Project </li></ul>
  22. 22. Define the Current Technical Environment <ul><li>All Hardware and Software Currently Used to Address the Requirements of This Project </li></ul><ul><li>Any Currently Owned or Operated Hardware or Software That Could or Should be Utilized to Solve The Problem </li></ul>
  23. 23. Define the Problem <ul><li>Define the Problem, Not The Solution </li></ul><ul><li>The Problem is ALWAYS a Business Problem </li></ul><ul><li>Business Problems Can Include Legal Mandates </li></ul><ul><li>Technology is a Solution, Not the Problem </li></ul><ul><li>Define the Budget Range for this Project </li></ul>
  24. 24. Evaluating Demonstrations? <ul><li>Demonstrations </li></ul><ul><ul><li>Validation </li></ul></ul><ul><ul><ul><li>Highest Ranked Offeror, Not Scored </li></ul></ul></ul><ul><ul><li>Demonstration Evaluations </li></ul></ul><ul><ul><ul><li>All Offerors </li></ul></ul></ul><ul><ul><ul><li>Short List </li></ul></ul></ul><ul><ul><ul><ul><li>All Offerors within a percentage of the highest ranked offeror </li></ul></ul></ul></ul>
  25. 25. Perform Agency Risk Analysis <ul><li>Perform agency risk analysis </li></ul><ul><ul><li>Identify any internal or external political, business, or technological factors or issues that may affect the successful completion of this project. </li></ul></ul><ul><ul><li>There may be opportunities to shift agency risk to contractor in the solicitation </li></ul></ul>
  26. 26. Business Proposal or Cost? <ul><li>If cost is not an evaluation criteria, you may consider a business proposal including cost and submitted with technical proposal, or </li></ul><ul><li>A Business Proposal with Cost submitted separately </li></ul><ul><ul><li>Require a Bill of Materials without cost be included in technical proposal </li></ul></ul>
  27. 27. Business Proposal? <ul><li>Total Cost of Ownership </li></ul><ul><li>Risk Analysis of proposed solution </li></ul><ul><li>Risk Mitigation Plan </li></ul><ul><li>Opportunities for Risk Sharing </li></ul><ul><li>Performance Incentives (maybe allowed) </li></ul><ul><li>Financing Options </li></ul><ul><li>Implementation Schedule </li></ul><ul><ul><li>Staff Deployment Schedule </li></ul></ul><ul><ul><li>Milestones and Deliverables </li></ul></ul><ul><ul><li>Payments tied to Deliverables </li></ul></ul>
  28. 28. Cost? <ul><li>Offeror to include project risk analysis, risk mitigation plan, implementation plan, options, staffing plan, and bill of materials (without pricing) in the technical proposal </li></ul><ul><li>TCO, financing options, performance incentives submitted under separate cover to include Bill of Materials with itemized cost. </li></ul>
  29. 29. Considering Options <ul><li>Offerors may have multiple solutions to the same functional requirement, each of which will work fine with their solution. </li></ul><ul><li>Offerors may propose options that shift risk </li></ul><ul><li>Offeror must fully explain each available option, the cost delta for each option and the exact parts of the original proposal for which the option may be substituted. </li></ul><ul><li>Each option will be considered prior to commencing full proposal evaluation </li></ul>
  30. 30. Offeror’s Original Proposal Offeror’s Technical Proposal Offeror’s Business Proposal -$$ -$$$ +$ Fully compliant with all the specifications, terms, and conditions B o M Bill of Materials Total Cost of Technical Proposal Risks or Options $$$$$$$ $$$$ $$$$ Offeror’s New Technical Proposal Why should the State accept the proposed Risk or Option?
  31. 31. Determine Evaluation Methodology <ul><li>Traditional RFP Evaluation Committee </li></ul><ul><li>RFP Evaluation Committee </li></ul><ul><ul><li>Subject Matter Consultants Available </li></ul></ul><ul><li>Subject Matter Evaluations </li></ul>
  32. 32. Subject Matter Evaluation <ul><li>Program personnel only evaluate program portions of proposal </li></ul><ul><li>Technologists only evaluate technology portions of proposal </li></ul><ul><li>Business personnel only evaluate business portions of the proposal </li></ul><ul><li>These areas may be further subdivided </li></ul><ul><li>Evaluation criteria for each subject area or SME scores roll up into a superset evaluation criteria. </li></ul>
  33. 33. Determine Evaluation Criteria <ul><li>Functional Capabilities: How well does the proposed solution meet the needs of the State as identified herein. </li></ul><ul><li>Technical and Performance Capabilities: How well do the technical and performance capabilities of the proposed solution meet the needs of the State. </li></ul><ul><li>Business Plan: - The impact of the proposed systems on the business and financial operations of the Agency. </li></ul><ul><li>Cost </li></ul>
  34. 34. Determine Evaluation Criteria <ul><li>Installation and Support: The degree to which the proposed installation and support capabilities meet the needs of the State. </li></ul><ul><li>Implementation Plan: Is the plan complete, reasonable, and does it meet the objectives outlined in the offeror’s proposal? </li></ul><ul><li>Qualifications: References (corporate and/or personal), resumes, financial statements, and evidence of ability to conduct business in the State. </li></ul><ul><li>Demonstrations </li></ul>
  35. 35. Set Desired Proposal Format <ul><li>Submittal Letter </li></ul><ul><li>Executive Overview </li></ul><ul><li>Technical Overview </li></ul><ul><li>Detailed Technical Explanation of Proposed Solution with specifications </li></ul><ul><li>Any Available Options </li></ul><ul><li>Business Proposal </li></ul><ul><li>Offeror’s Qualifications </li></ul>
  36. 36. Evaluation and Award <ul><li>Evaluation of Options </li></ul><ul><li>Oral Presentations and Discussions </li></ul><ul><li>Initial Evaluation </li></ul><ul><li>Demonstrations </li></ul><ul><li>Final Scoring </li></ul><ul><li>Demonstration of Highest Ranked </li></ul><ul><li>Negotiations </li></ul><ul><li>Award </li></ul>
  37. 37. Final and Conclusive <ul><li>The determinations required by the Code are final and conclusive, unless clearly erroneous, arbitrary, capricious, or contrary to law: </li></ul><ul><li>No Specifications – No Protest </li></ul><ul><li>Request for Qualifications – No Protest </li></ul><ul><li>Award – No Protest </li></ul>
  38. 38. Conclusion <ul><li>Define the Problem, not the solution </li></ul><ul><li>Technology not the problem, IT is a solution </li></ul><ul><li>Reduce the probability of a successful protest </li></ul><ul><li>A successful IT project must include people: </li></ul><ul><ul><li>Program People </li></ul></ul><ul><ul><li>Technologists </li></ul></ul><ul><ul><li>Project Managers </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Financial </li></ul></ul><ul><ul><li>Legal </li></ul></ul>
  39. 39. Questions?

×