Your SlideShare is downloading. ×
0
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Solutions-Based Procurement NIGP Forum, Tampa, FL 8/8/2006
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

414

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
414
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Solutions-Based Procurement for Information Technology Acquisitions Michael B. Spicer South Carolina Chief Procurement Officer for Information Technology
  • 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. 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. 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. 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. 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. 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. 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. “ 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. 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. 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. “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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Questions?

×