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.

Procurement Approaches - Processes and Issues


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

Procurement Approaches - Processes and Issues

  1. 1. CSE5806 Telecommunications Management Lecturer: Ken Fletcher Lecture 7 Procurement Procedures
  2. 2. Reference Sources <ul><li>NOTE: </li></ul><ul><ul><ul><li>These sources are indicative - there are many other good texts available in libraries and on the Internet. They are referenced here as this presentation draws on them extensively. </li></ul></ul></ul><ul><li>Better Practice Guide – Selecting Suppliers </li></ul><ul><ul><ul><li>Australian National Audit Office 1998 then click on ‘Publications’ </li></ul></ul></ul><ul><li>Better Practice Guide – Contract Management </li></ul><ul><ul><ul><li>Australian National Audit Office 2001 http:// then click on ‘Publications’ </li></ul></ul></ul>
  3. 3. Project Lifecycle - Eng’g Processes Shaded area shows work normally considered for external “Procurement” System Specifications System Specifications System and Sub-System Specifications Detail Design Ideas Sub-system Testing System Testing Acceptance Testing Progress Clockwise Review Operations Strategy Studies Operations Analysis Architectural Design User Requirements Specification User Oriented Testing - Functional and Performance System Oriented Testing- Technical Functionality, plus Connectivity and Interfacing Acquire and Implement Sub-systems Sub-system Oriented Testing- Detailed Functionality, plus Connectivity and Interfacing
  4. 4. System Life Cycle <ul><li>Acquisition era </li></ul><ul><ul><ul><li>Strategy Formulation </li></ul></ul></ul><ul><ul><ul><li>Broad Design (Architectural design) </li></ul></ul></ul><ul><ul><ul><li>Specification (may involve another level of design) </li></ul></ul></ul><ul><ul><ul><li>Tendering Process (RFI-RFP/RFT) </li></ul></ul></ul><ul><ul><ul><li>Selection (Evaluation and identification of ‘Preferred supplier) </li></ul></ul></ul><ul><ul><ul><li>Contract negotiations and signing </li></ul></ul></ul><ul><ul><ul><li>Building, Installation,Testing and Training </li></ul></ul></ul><ul><ul><ul><li>Commissioning and Implementation (“Setting to Work”) </li></ul></ul></ul><ul><li>Operations </li></ul><ul><ul><ul><li>Operational Use </li></ul></ul></ul><ul><ul><ul><li>Maintenance and Support </li></ul></ul></ul><ul><ul><ul><li>Enhancement, extensions, modifications </li></ul></ul></ul><ul><li>Close Down and Replacement/Disposal </li></ul>
  5. 5. Acquisition Strategy <ul><li>Many approaches possible: </li></ul><ul><ul><li>Acquire (buy) in-house </li></ul></ul><ul><ul><ul><ul><li>Operate and support using in-house resources </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Acquire using in-house resources, but operate outsourced </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Variations and combinations of above – </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>eg acquire and operate in-house under local management control, using outsourced services for specialised services such as Telecommunications, maintenance, training </li></ul></ul></ul></ul></ul><ul><ul><ul><li>Up front costs are high – acquisition effort, equipment costs </li></ul></ul></ul><ul><ul><ul><li>Risks can be high – ie responsibility primarily in-house </li></ul></ul></ul><ul><ul><ul><li>Benefits good – eg in-house control, expertise development </li></ul></ul></ul><ul><ul><li>Outsource all aspects of the function totally </li></ul></ul><ul><ul><ul><ul><li>Outsourcing company responsible for acquisition and operation </li></ul></ul></ul></ul><ul><ul><ul><li>Costs become annual ‘operations’ rather than ‘capital’ costs – </li></ul></ul></ul><ul><ul><ul><ul><li>eg low (or zero) up-front costs, no issues of owning obsolescent equipment </li></ul></ul></ul></ul><ul><ul><ul><li>Some loss of control and flexibility </li></ul></ul></ul><ul><ul><ul><li>Still requires extensive in-house effort to manage </li></ul></ul></ul><ul><ul><ul><ul><li>planning, specification of functional needs, oversight and controls etc </li></ul></ul></ul></ul><ul><ul><ul><ul><li>BUT effort is less than with full ownership and operational management </li></ul></ul></ul></ul><ul><li>Generally a mixture of approaches is used. </li></ul><ul><ul><li>This session focuses on in-house activity of managing the acquisition </li></ul></ul>
  6. 6. Acquisition Role-Players <ul><li>Inside Staff </li></ul><ul><ul><ul><li>Are there enough staff with appropriate experience & skills? </li></ul></ul></ul><ul><ul><ul><ul><li>Internal staff are rarely involved in major acquisitions – eg every ‘n’ years </li></ul></ul></ul></ul><ul><ul><ul><li>What about non-performance or poor performance? (job on the line) </li></ul></ul></ul><ul><li>Consultants and Specialists (or ‘Short Term’ specialist employees) </li></ul><ul><ul><li>They do this sort of thing often - possibly several times each year </li></ul></ul><ul><ul><ul><li>They often have broad experience in most aspects of acquisition work – </li></ul></ul></ul><ul><ul><ul><ul><li>RFP/T preparation, tender bidding, tender evaluation, system/acceptance testing </li></ul></ul></ul></ul><ul><ul><ul><li>Can usually call on scarce resources or experience from colleagues </li></ul></ul></ul><ul><ul><ul><li>May continue into operational support – ease the transition period </li></ul></ul></ul><ul><ul><li>Issues when using consultants </li></ul></ul><ul><ul><ul><li>Often lack user-domain knowledge </li></ul></ul></ul><ul><ul><ul><li>No emotional ownership of the systems/task – (commitment?) </li></ul></ul></ul><ul><ul><ul><li>Issues of legal liability if things don't work – who is responsible? </li></ul></ul></ul><ul><ul><ul><li>Are the consultants truly independent of suppliers? </li></ul></ul></ul>
  7. 7. Acquisition Role-Players (2) <ul><li>Outsourcing of Acquisition Task </li></ul><ul><ul><li>Pay someone else to buy equipment etc for you </li></ul></ul><ul><ul><ul><li>All of the advantages and disadvantages of Consultants </li></ul></ul></ul><ul><ul><ul><ul><li>Provision of skills and people – eg Expertise and staff numbers </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Independence of suppliers – </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>but check their past tasks for possible conflicts of loyalties </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Less skills transfer than using resident consultants or short term employees </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Commitment to long term goals may be questionable </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Whose goals – yours or theirs? </li></ul></ul></ul></ul></ul><ul><li>Removes emotional ownership issues </li></ul><ul><li>Clearer focus on performance (or no payment) </li></ul><ul><li>Issues of liability – who is responsible if it does not work? </li></ul>
  8. 8. Purchasing Models Many variants are possible Main ones used are: Often a mixture of approaches is used eg different phases of a major project use different models X X Multiple supplier X X Single supplier Variable Price Fixed Price
  9. 9. Purchasing Models – Fixed Price <ul><li>Fixed price purchasing (aka ‘ Firm Fixed Price ” (FFP)) </li></ul><ul><ul><ul><li>Requires that both purchaser and supplier are clear about scope of work – </li></ul></ul></ul><ul><ul><ul><ul><li>good for well known and well defined tasks such as payrolls, </li></ul></ul></ul></ul><ul><ul><ul><ul><li>poor for leading edge systems where both the task and technology are not well understood leading to high risks ( price will be loaded to accommodate the risk ) </li></ul></ul></ul></ul><ul><ul><li>Single Supplier - Fixed Price (SSFP) </li></ul></ul><ul><ul><ul><li>Single supplier for whole task, usually including installation and training </li></ul></ul></ul><ul><ul><ul><li>Supplier may subcontract some/most of the work, but retains responsibility and liability as “Prime Contractor” or “Prime Systems Integrator” (PSI) </li></ul></ul></ul><ul><ul><ul><li>Most appropriate where the task is well defined in testable terms. </li></ul></ul></ul><ul><ul><ul><li>Good where the overall task is intimately associated with many minor aspects requiring close coordination of many parties (e.g. supply and install a network, where power, air conditioning, cable installation, security, building works etc etc are involved) </li></ul></ul></ul><ul><ul><li>Multiple Supplier - Fixed Price (MSFP) </li></ul></ul><ul><ul><ul><li>Requires purchaser to have more staff designing, coordinating, managing (outcome very dependent on inside staff numbers and expertise) </li></ul></ul></ul><ul><ul><ul><li>May be cheaper than SSFP </li></ul></ul></ul><ul><ul><ul><ul><li>(Prime Contractor or PSI usually charges 15% to 30% add-on to sub-contract costs for supervising the sub-contractor and for integrating their work into the main task) </li></ul></ul></ul></ul>
  10. 10. Purchasing Models – Variable Price <ul><li>Single Supplier - Variable Price (SSVP) </li></ul><ul><ul><ul><li>Project cannot be specified in sufficient detail to allow fixed price approaches Eg leading edge technologies </li></ul></ul></ul><ul><ul><ul><ul><li>Actual task is defined as the work progresses and knowledge is gained </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Often a multi-stage project, where each stage is managed as a Fixed Price task, with one sub-task in each stage to define and cost next stage </li></ul></ul></ul></ul><ul><ul><ul><li>Project often subject to exchange rate changes or other factors beyond control of contractor </li></ul></ul></ul><ul><ul><ul><li>Often needs a &quot;head&quot; contract to define the rules. </li></ul></ul></ul><ul><ul><ul><li>Often called &quot;time & materials&quot; contract. </li></ul></ul></ul><ul><li>Multiple Supplier - Variable Price (MSVP) </li></ul><ul><ul><ul><li>Combines MSFP and SSVP aspects </li></ul></ul></ul><ul><ul><ul><li>Really a project which is self-managed and self sub-contracted. </li></ul></ul></ul>
  11. 11. Procurement Procedures Sequence and Indicative Timescales (Times shown are indicative for a ‘high tech’ $50M+ task) Starting Point - After concept has been developed, and strategic decision to go ahead RFI preparation, responses, and decisions (3-12 months) RFP/RFT preparation (1-3 months) Tendering period (2-4 months) Tender evaluation (3 months) Contract negotiation and award (2-6 months) Contract execution (6-36 Months to build, install, test etc)
  12. 12. Request For Information (RFI) <ul><li>Used in major projects where the tasks to be done and the technologies available are intertwined – </li></ul><ul><ul><ul><li>especially where the purchaser is unsure of what can be done and the estimated costs involved, or seeks info to guide strategic decisions </li></ul></ul></ul><ul><ul><ul><li>Eg general need known, but technical possibilities not known, and the purchaser has flexibility to alter the ‘needs’ and timings to match the technical and financial realities </li></ul></ul></ul><ul><li>Paints broad functional picture and requests innovative proposals </li></ul><ul><ul><ul><li>eg “We want a network capable of (broad functional description, possibly never done before)” </li></ul></ul></ul><ul><ul><li>Usually a semi-controlled ‘fishing expedition’ by the purchaser </li></ul></ul><ul><ul><li>Expects would-be suppliers to do leg-work (at their expense) in the hope of a future sale </li></ul></ul><ul><ul><li>Mainly used for major projects in a big organization </li></ul></ul><ul><ul><li>Often followed by one or more RFP/RFTs tailored as a result of the RFI </li></ul></ul><ul><ul><li>Often used to develop short list of potential suppliers </li></ul></ul>
  13. 13. RFI Issues <ul><li>Usually more or less unfair to respondents and would-be suppliers </li></ul><ul><ul><ul><li>Costly to respond, with low probability of future work </li></ul></ul></ul><ul><ul><ul><li>Respondents may need to disclose information which is later used to their disadvantage </li></ul></ul></ul><ul><ul><ul><ul><li>proprietary information ‘leaked’ to competitors </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Immature information eg probable future releases of equipment </li></ul></ul></ul></ul><ul><ul><ul><li>Unfairly used by purchasers to ‘test the offerings in the market place’ rather than to make real strategic decisions </li></ul></ul></ul><ul><ul><ul><li>Used by purchasers to develop a superset of offerings being requested in an RFP/T (which nobody can satisfy) </li></ul></ul></ul><ul><li>Can be good for both purchaser and would-be suppliers </li></ul><ul><ul><ul><li>Identifies innovative possibilities and potential suppliers </li></ul></ul></ul><ul><ul><ul><li>Advises industry broad concepts of forthcoming RFP/Ts </li></ul></ul></ul><ul><ul><ul><ul><li>Allows industry to prepare themselves (plan and build bidding team etc) </li></ul></ul></ul></ul><ul><ul><ul><li>Enables development of short list of bidders for RFP/T </li></ul></ul></ul><ul><li>Should always include Non-disclosure contracts on both parties </li></ul>
  14. 14. RFI to RFP/T Period <ul><li>Purchaser should use RFI information to: </li></ul><ul><ul><li>Plan and consolidate strategic directions and decisions </li></ul></ul><ul><ul><ul><ul><li>Budgets </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Technical directions </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Timescales and schedules </li></ul></ul></ul></ul><ul><ul><li>Develop technical specifications which are </li></ul></ul><ul><ul><ul><li>Well written – understandable, non-ambiguous, complete, consistent </li></ul></ul></ul><ul><ul><ul><li>Fair to all parties (not biased to any particular vendor or style) </li></ul></ul></ul><ul><ul><ul><li>Achievable and satisfactory to real needs </li></ul></ul></ul><ul><ul><ul><ul><li>Neither a superset of all possibilities nor so specifically a subset that the real need is not satisfied </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Within the timeframes needed </li></ul></ul></ul></ul><ul><ul><ul><li>Able to be tested (quantified, defined, bounded) </li></ul></ul></ul><ul><li>Reason for above? Because the RFP/T period implies limited communications between purchaser and bidders </li></ul>
  15. 15. Request for Tender or Proposal <ul><li>Referred to as RFT or RFP </li></ul><ul><li>Is issued to all prospective suppliers </li></ul><ul><li>Involves a detailed specification of the facilities/system and/or the functionality expected, and requests sufficient information to enable: </li></ul><ul><ul><ul><li>Reasoned evaluation of alternatives </li></ul></ul></ul><ul><ul><ul><li>Contract to be placed with one or more of the bidders for the ultimate supply and operation </li></ul></ul></ul><ul><li>Usually requires the respondent (aka ‘Tenderer’ or ‘Bidder’) to undertake significant design work </li></ul><ul><ul><ul><li>Especially if a ‘functional specification’ style of RFP/T </li></ul></ul></ul><ul><ul><ul><li>Usually requires bidders to submit detailed costing, draft design documents, management plans, etc for ‘evaluation’ purposes </li></ul></ul></ul><ul><li>Needs to include a statement that purchaser reserves the rights determine which, if any , tender is accepted </li></ul><ul><ul><ul><li>A legal issue to avoid being forced to take lowest bid, or any other bid if the costs are too high </li></ul></ul></ul>
  16. 16. Why do it? <ul><li>RFP/T approach seen as : </li></ul><ul><ul><li>Encouraging competition between prospective suppliers </li></ul></ul><ul><ul><li>Method of getting best value for money </li></ul></ul><ul><li>The RFP/RFT provides: </li></ul><ul><ul><li>Framework for the systematic definition of needs </li></ul></ul><ul><ul><ul><li>Facilitates control of the acquisition process </li></ul></ul></ul><ul><ul><li>Fair description of needs for all would-be suppliers to bid against </li></ul></ul><ul><ul><ul><li>Consistent task for bidding by all would-be suppliers </li></ul></ul></ul><ul><ul><li>Standard framework for vendor proposals </li></ul></ul><ul><ul><li>Standard framework for evaluation of proposals </li></ul></ul><ul><ul><ul><li>Very important that evaluation stage be considered in the RFP or RFT </li></ul></ul></ul><ul><ul><li>Vehicle for communicating business, technical, legal and insurance issues that purchaser desires in the final contract </li></ul></ul><ul><ul><ul><li>(Bidders may propose variations or alternatives to these for negotiation) </li></ul></ul></ul>
  17. 17. The RFP/RFT Request : <ul><li>Usually issued in sections which can be split apart for the bidding work - eg: </li></ul><ul><ul><ul><li>Introduction </li></ul></ul></ul><ul><ul><ul><li>Administrative Requirements (see later notes for statements of compliance) </li></ul></ul></ul><ul><ul><ul><li>Technical Requirements (see later notes for statements of compliance) </li></ul></ul></ul><ul><ul><ul><li>Business Requirements (see later notes for statements of compliance) </li></ul></ul></ul><ul><ul><ul><li>Legal/Insurance details </li></ul></ul></ul><ul><ul><li>Each section should be suitable for separation during bidding period – ie largely suitable for ‘stand-alone’ work </li></ul></ul><ul><ul><ul><li>Different people or groups will respond to each part </li></ul></ul></ul><ul><ul><ul><ul><li>Engineers/Tech staff respond to Technical requirements </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Accountants or costing specialists develop the costing sections </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Lawyers review and guide the contractual/legal aspects </li></ul></ul></ul></ul><ul><li>Should be reviewed internally before issue, and endorsed at appropriate senior levels – both financial/legal and technical. </li></ul>
  18. 18. RFP/T Request (2) <ul><li>Often contains draft contract for consideration and comment </li></ul><ul><li>Often contains the structure for a formal proposal from the vendor/supplier (see later slides for example) </li></ul><ul><li>Typically lists points on which prospective vendors/suppliers must reply appropriately </li></ul><ul><li>Usually contains a requirement that bidders give a ‘statement of compliance’ against each and every requirement in the RFP/T </li></ul>
  19. 19. RFP/T tips <ul><li>Have a good architecture or technical direction in mind when writing the Technical specification </li></ul><ul><li>Have experienced spec writers develop Tech Specs </li></ul><ul><ul><ul><li>Use of a committee to write them results in a ‘camel’ </li></ul></ul></ul><ul><ul><ul><ul><li>Lumpy, bumpy and nasty – with little coherence or completeness </li></ul></ul></ul></ul><ul><ul><ul><li>Yet a Tech spec written by an individual will be restricted by the person’s bias and limitations </li></ul></ul></ul><ul><ul><ul><li>Seek a middle approach </li></ul></ul></ul><ul><ul><ul><ul><li>Develop spec using limited numbers of people </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Oversight spec using committee of stakeholders </li></ul></ul></ul></ul><ul><ul><ul><li>Do not take too long to develop specification </li></ul></ul></ul><ul><ul><ul><ul><li>Technological overrun occurs, where the early sections reflect a different era to other sections </li></ul></ul></ul></ul><ul><li>Crucial to be well written </li></ul><ul><ul><ul><ul><li>Clear and unambiguous </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Such that resulting bids can be easily evaluated </li></ul></ul></ul></ul>
  20. 20. Who Tenders or Bids? <ul><li>Vendors and Would-be Suppliers respond because of: </li></ul><ul><ul><ul><li>Open public tender (advertised in press, trade papers, web sites) </li></ul></ul></ul><ul><ul><ul><li>By invitation (e.g. short-list from RFI) </li></ul></ul></ul><ul><ul><li>Large companies have specialised bidding teams </li></ul></ul><ul><ul><li>Small companies cannot afford costs of excessive bidding </li></ul></ul><ul><ul><ul><li>May ride under the umbrella of a larger ‘Prime bidder’ </li></ul></ul></ul><ul><li>Public bodies usually required to have a multiple tenderers as a guard against corruption and collusion between bidders </li></ul><ul><ul><ul><li>Typically three required for government tenders </li></ul></ul></ul><ul><ul><ul><li>Many companies require three or more </li></ul></ul></ul><ul><li>Purchaser may pay (token) fee to selected short-list bidders </li></ul><ul><ul><ul><li>especially for extensive design or creative work. </li></ul></ul></ul>
  21. 21. Costs of Bidding/Tendering <ul><li>Acquirer’s or Purchasers viewpoint </li></ul><ul><ul><ul><li>Inevitably under-costed and under-resourced – </li></ul></ul></ul><ul><ul><ul><ul><li>resulting in less than optimum value-for-money </li></ul></ul></ul></ul><ul><ul><ul><li>Allow for 0.5% to 1% of cost of job for specification and evaluation </li></ul></ul></ul><ul><ul><ul><ul><li>More if extensive travel is required to research needs and solutions </li></ul></ul></ul></ul><ul><li>Bidder’s viewpoint </li></ul><ul><ul><ul><li>From 2% to 4% of cost of job for large ‘functional’ RFP/Ts </li></ul></ul></ul><ul><ul><ul><ul><li>(eg high level design, detail designs, extensive research is required, many draft plans, samples of outputs, compliance with complex proposed contractual conditions etc) </li></ul></ul></ul></ul><ul><ul><ul><li>More if extensive research, travel or effort required to satisfy the demands for innovation, examples, supporting documents, presentations, tight timeframes to bid (eg hiring aircraft to deliver the bid documents) etc </li></ul></ul></ul><ul><ul><ul><li>Is it worth the cost and financial risks? Could we do better bidding other work? </li></ul></ul></ul>
  22. 22. Costs in Bids <ul><li>Apart from the obvious costs of doing the job: </li></ul><ul><ul><li>Bidders price reflects cost of bidding or tendering </li></ul></ul><ul><ul><ul><ul><li>Bidders should expect to win approximately one in three bids, therefore cost add-in to cover expenses of failed bids is 6% to 12% of cost of this bid </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Purchasers with bad reputations (eg using too many bidders, frequently aborting bid work or not proceeding with purchases after bid work) will have higher prices proposed to cover the risks that bidders perceive. </li></ul></ul></ul></ul><ul><ul><li>Bidder’s price reflects perceived risk in the task </li></ul></ul><ul><ul><ul><li>High risk = higher prices </li></ul></ul></ul><ul><ul><ul><ul><li>High risk may be technical, contractual or schedule risks (eg innovative or leading edge technology, severe penalties in contract, difficult schedules etc) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>May be perception (reputation) that the purchaser is difficult to satisfy </li></ul></ul></ul></ul><ul><ul><li>Bidder’s price may reflect an unwillingness to do this job </li></ul></ul><ul><ul><ul><ul><li>They do not really want to do the job at this time and only bid to keep their name in the game because of fear of being ignored in future </li></ul></ul></ul></ul><ul><li>Excessively low prices generally indicate either: </li></ul><ul><ul><ul><ul><li>Misunderstanding of the job, or </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Desperation for work </li></ul></ul></ul></ul>
  23. 23. Bid Period Protocols <ul><li>During the bidding period certain protocols used to ensure fairness and openness in the process eg </li></ul><ul><ul><li>Purchaser does not publicly identify prospective bidders </li></ul></ul><ul><ul><ul><li>unless this is done via a list freely available to all bidders </li></ul></ul></ul><ul><ul><li>RFP/T docs made available to all bidders at same time </li></ul></ul><ul><ul><ul><ul><li>public advertisements may have some ‘late’ requests for documents </li></ul></ul></ul></ul><ul><ul><li>All bidders are issued with identical documents </li></ul></ul><ul><ul><li>Communications between bidders and purchaser must be: </li></ul></ul><ul><ul><ul><li>Restricted to specified senior levels – </li></ul></ul></ul><ul><ul><ul><ul><li>usually only one person at each organisation </li></ul></ul></ul></ul><ul><ul><ul><li>Written (email/fax generally OK if followed up with hard copy) </li></ul></ul></ul><ul><ul><ul><li>Clarification requests & responses distributed to all bidders </li></ul></ul></ul><ul><ul><ul><ul><li>Bidders need to be careful that their queries do not disclose sensitive info </li></ul></ul></ul></ul>
  24. 24. Sample Proposal Outline <ul><li>Following OHPs indicate a sample proposal outline that could be suitable for many ‘high-tech’ bids </li></ul><ul><li>It not necessary to follow this, but doing so provides a reasonable coverage of the issues </li></ul><ul><ul><li>Use only the parts appropriate to the particular task </li></ul></ul><ul><ul><li>There is some duplication of information in this sample, which indicates alternative locations for the information </li></ul></ul><ul><li>NOTES: </li></ul><ul><ul><li>Bid must be read and understood by evaluators who may have no real ability to contact the bidder for clarification </li></ul></ul><ul><ul><ul><li>In order to facilitate fairness to all bidders </li></ul></ul></ul><ul><ul><ul><li>To provide ‘transparency’ of the evaluation process </li></ul></ul></ul><ul><ul><li>The claims made in the bid are often able to be legally considered a part of the “contract to supply” – inflated claims are financially dangerous </li></ul></ul>
  25. 25. Sample Proposal Outline (adapted from Rosenthal) <ul><li>Executive Summary </li></ul><ul><li>System Objectives </li></ul><ul><li>Proposed Solution </li></ul><ul><ul><li>System Overview </li></ul></ul><ul><ul><ul><li>Architecture </li></ul></ul></ul><ul><ul><ul><li>Functional Characteristics </li></ul></ul></ul><ul><ul><ul><li>Performance Characteristics </li></ul></ul></ul><ul><ul><li>Technological Methodology </li></ul></ul><ul><ul><ul><li>Equipment Configurations </li></ul></ul></ul><ul><ul><ul><li>Software Description </li></ul></ul></ul><ul><ul><ul><li>Maintenance Proposals </li></ul></ul></ul><ul><ul><ul><li>Site Preparation needs </li></ul></ul></ul>(Continued)
  26. 26. Sample Proposal Outline (2) <ul><li>Implementation Plans (What will be done, how it will be managed) </li></ul><ul><li>Financial Data </li></ul><ul><ul><li>Presented by type and date </li></ul></ul><ul><ul><ul><li>Capital, maintenance, operational, consumable etc and </li></ul></ul></ul><ul><ul><ul><li>Anticipated date for expenditure or demand for payment </li></ul></ul></ul><ul><ul><li>For </li></ul></ul><ul><ul><ul><li>Hardware </li></ul></ul></ul><ul><ul><ul><li>Software </li></ul></ul></ul><ul><ul><ul><li>Manpower etc </li></ul></ul></ul><ul><li>Legal and Insurance </li></ul><ul><ul><li>Warranties </li></ul></ul><ul><ul><li>Representations and Certificates (Copies) </li></ul></ul><ul><ul><ul><li>Certificates of Professional Indemnity , Worker’s Compensation, Public Liability insurance </li></ul></ul></ul><ul><ul><ul><li>ISO 9000 certification etc </li></ul></ul></ul>(Continued)
  27. 27. Sample Proposal Outline (3) <ul><li>Schedules for : </li></ul><ul><ul><li>Implementation </li></ul></ul><ul><ul><li>Training </li></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>Delivery </li></ul></ul><ul><ul><li>Payments – progressive payments and trigger points </li></ul></ul><ul><li>Confidentiality of Arrangements and Information </li></ul><ul><ul><ul><li>Which information is ‘proprietary or commercial-in-confidence </li></ul></ul></ul><ul><li>Product Literature (summary only, details in an annex) </li></ul><ul><li>Sample or proposed Contract </li></ul><ul><li>Glossary of Terms </li></ul>(Continued)
  28. 28. Sample Proposal Outline (4) <ul><li>Technical Aspects </li></ul><ul><ul><li>Operational Considerations </li></ul></ul><ul><ul><li>Functional Requirements </li></ul></ul><ul><ul><ul><li>How these have been addressed </li></ul></ul></ul><ul><ul><li>Backup & Recovery </li></ul></ul><ul><ul><li>System Benchmarks (performance benchmarks) </li></ul></ul><ul><ul><li>Interface Requirements </li></ul></ul><ul><li>Implementation arrangements and procedures </li></ul><ul><li>Maintenance proposals and arrangements </li></ul><ul><ul><li>During development and installation period </li></ul></ul><ul><ul><li>Within warranty period </li></ul></ul><ul><ul><li>Following warranty period </li></ul></ul><ul><li>Training </li></ul><ul><li>Installation support </li></ul>(Continued)
  29. 29. Sample Proposal Outline (5) <ul><li>Resumes of key personnel </li></ul><ul><li>Customer-furnished equipment (CFE) </li></ul><ul><ul><li>How this will be used – including accounting for it, maintenance etc </li></ul></ul><ul><li>Customer Furnished Information (CFI) and Data (CFD) </li></ul><ul><li>Multi-vendor interface – management and support, including problem resolution </li></ul><ul><li>User environment </li></ul><ul><ul><li>Product performance </li></ul></ul><ul><ul><li>Product reliability aspects </li></ul></ul><ul><ul><li>Product compatibility (upward, downward, with other manufacturers etc) </li></ul></ul><ul><ul><li>Product enhancement (upgrades to new versions) </li></ul></ul><ul><li>Project direction – Management etc </li></ul><ul><li>Site Specifications and access requirements – what is needed or assumed </li></ul><ul><li>Documentation – what will be supplied, how many copies, when </li></ul><ul><li>Standards (compliance), testing against etc </li></ul><ul><li>Current hardware/software environment including developmental environment </li></ul><ul><li>Acceptance Test criteria and procedures </li></ul>
  30. 30. Sample Proposal Outline (6) <ul><li>Business Requirements </li></ul><ul><li>Finance and legal Issues </li></ul><ul><ul><li>Costs and Pricing </li></ul></ul><ul><ul><ul><li>Excess use charges (rentals) </li></ul></ul></ul><ul><ul><ul><li>Unit pricing (over time) </li></ul></ul></ul><ul><ul><ul><li>Discounts </li></ul></ul></ul><ul><ul><ul><li>Expansion costs </li></ul></ul></ul><ul><ul><ul><li>Maintenance costs </li></ul></ul></ul><ul><ul><li>Estimating techniques </li></ul></ul><ul><ul><ul><li>How this job was estimated </li></ul></ul></ul><ul><ul><ul><li>How any subcontracts will be estimated </li></ul></ul></ul><ul><ul><li>Financing method (customer, supplier) </li></ul></ul><ul><ul><li>Emergency substitute equipment – </li></ul></ul><ul><ul><ul><li>how decision is made, what will be supplied </li></ul></ul></ul><ul><ul><li>Supporting documentation for financial issues </li></ul></ul><ul><ul><li>Option to buy (after rental/lease contract) </li></ul></ul><ul><ul><li>Accruals towards purchase </li></ul></ul><ul><ul><li>Investment tax credit </li></ul></ul><ul><ul><li>Local involvement statements – eg ANZ content </li></ul></ul>(Continued)
  31. 31. Sample Proposal Outline (7) <ul><ul><li>Warranties </li></ul></ul><ul><ul><li>Training </li></ul></ul><ul><ul><li>Implementation & delivery schedule </li></ul></ul><ul><ul><li>Upgrades </li></ul></ul><ul><ul><li>Trade-ins </li></ul></ul><ul><ul><li>Equipment condition </li></ul></ul><ul><ul><li>Price protection </li></ul></ul><ul><ul><li>Exchange rates variations </li></ul></ul><ul><ul><li>Use of sub contractors </li></ul></ul><ul><ul><li>Bidder’s Acquisition policies and procedures </li></ul></ul><ul><ul><li>Standard contract form from the Bidder </li></ul></ul><ul><li>Product life cycle </li></ul><ul><ul><li>Technological obsolescence issues eg </li></ul></ul><ul><ul><ul><li>Proposals to handle situation where equipment proposed is superseded before purchase </li></ul></ul></ul>(Continued)
  32. 32. Sample Proposal Outline (8) <ul><li>Bidding Company Information </li></ul><ul><ul><ul><li>Corporate identity, legal structure eg Pty Ltd, Key personnel </li></ul></ul></ul><ul><ul><ul><li>History </li></ul></ul></ul><ul><ul><ul><li>Financial stability (including financial history) </li></ul></ul></ul><ul><ul><ul><li>Relevant past experience </li></ul></ul></ul><ul><li>Annexes, Appendices and Attachments </li></ul><ul><ul><li>Contain details of many points covered throughout the bid </li></ul></ul><ul><ul><ul><ul><li>Brochures and technical specifications of equipment </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Detailed drawings of floor layouts, buildings etc </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Detailed mathematical / simulation models of performance, reliability </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Work management details </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Work breakdown structure (WBS) lists/charts </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>PERT/CPM and Schedules (eg Micro Project outputs) </li></ul></ul></ul></ul></ul><ul><ul><li>Formal ‘statements of compliance’ will be an annex if not submitted elsewhere above </li></ul></ul>(end of Sample Proposal Outline)
  33. 33. Tender (Bid) Evaluation Period <ul><li>Proposals and Tenders (aka “Bids”) are evaluated by the purchaser following bid submission date </li></ul><ul><li>Late bids may be ignored (RFP/T docs need to state this) </li></ul><ul><ul><ul><li>Sometimes worth looking at, but a bid that is late without a valid reason implies a would-be supplier less organised than others </li></ul></ul></ul><ul><li>Bids may be evaluated by in-house or consultant staff </li></ul><ul><ul><ul><li>Non-disclosure and commercial confidentiality agreements needed! </li></ul></ul></ul><ul><li>Other points: </li></ul><ul><ul><li>additional requests should go to all bidders </li></ul></ul><ul><ul><li>common to short-list some bids for deeper investigation </li></ul></ul><ul><ul><li>common to invite bidders to meetings & information sessions. </li></ul></ul>
  34. 34. Tender Evaluation (2) <ul><li>Must be seen as balanced, unbiased & independent </li></ul><ul><ul><ul><li>Especially when evaluating government tenders </li></ul></ul></ul><ul><ul><li>Will cause loss of confidence by bidders if perceived as inconsistent, prejudged, biased, unfair, unreasonable or incompetently performed </li></ul></ul><ul><li>Must apply the same criteria to all submissions </li></ul><ul><li>Must handle non-monetary aspects in the same consistent manner </li></ul><ul><li>Difficult to handle inconsistent approaches between bidders </li></ul><ul><ul><ul><li>One bidder proposes 12 months warranty, while another proposes 24 months </li></ul></ul></ul><ul><ul><li>How do you handle this? </li></ul></ul><ul><ul><ul><li>I try to convert both warranty periods to a monetary value </li></ul></ul></ul>
  35. 35. Technical Evaluation <ul><li>Fairness and consistency paramount </li></ul><ul><li>Significant judgment and decision making skills needed </li></ul><ul><li>Proposals in excess of requirements are difficult to handle </li></ul><ul><ul><li>Eg Requirement is “able to support 24 users” </li></ul></ul><ul><ul><ul><li>One bidder claims ‘complies’ </li></ul></ul></ul><ul><ul><ul><li>Second bidder claims ‘able to support 36 users’ </li></ul></ul></ul><ul><ul><ul><li>Third bidder claims ‘able to support 128 users’ </li></ul></ul></ul><ul><ul><li>Which is best, or all considered equal? </li></ul></ul><ul><ul><li>How you handle this type of situation is very important </li></ul></ul><ul><li>Beware of ‘expectation creep’ among evaluators and in-house staff </li></ul><ul><ul><li>Expectations often evolve (creep upwards) as the evaluation progresses </li></ul></ul><ul><li>Will inevitably you will need some system of ‘weighting’ requirements </li></ul><ul><ul><li>(weighting should be described in RFP/T documents) </li></ul></ul><ul><ul><li>EXAMPLE regarding a coffee drinking vessel or ‘Coffee Cup’ </li></ul></ul>
  36. 36. Contracts <ul><li>Purchase/supply contract is a crucial component of the process. </li></ul><ul><li>The contract should contain: </li></ul><ul><ul><li>Definition of terminology used </li></ul></ul><ul><ul><li>Clear statement of what the supplier is to provide </li></ul></ul><ul><ul><ul><li>Quantified values rather than qualitiative statements </li></ul></ul></ul><ul><ul><li>Refers back to material in tender submission, plans, etc. </li></ul></ul><ul><ul><li>Clarifies status of pre-contract assurances, agreements, etc. </li></ul></ul><ul><ul><li>Definition of buyers obligations </li></ul></ul><ul><ul><li>Definition of acceptance tests </li></ul></ul><ul><ul><li>Definition of remedial action if tests are failed </li></ul></ul><ul><ul><li>Definition of intellectual property rights, etc. </li></ul></ul><ul><ul><li>Define liabilities for copyright, patent, etc. </li></ul></ul><ul><ul><li>Establish basis for ongoing support </li></ul></ul><ul><ul><li>Define responsibilities of both parties if the contract is breached. </li></ul></ul>
  37. 37. Legal Aspects <ul><li>Many acquisition projects end up in legal proceedings </li></ul><ul><ul><li>System alleged not to perform as expected or agreed </li></ul></ul><ul><li>Main areas of contention: </li></ul><ul><ul><li>Definitions of functionality </li></ul></ul><ul><ul><li>Definitions of performance </li></ul></ul><ul><ul><li>Validity of performance tests </li></ul></ul><ul><ul><li>Representations made before/during tendering or tender evaluation </li></ul></ul><ul><li>Essential to: </li></ul><ul><ul><li>Have all representations in writing </li></ul></ul><ul><ul><li>Tie representations to contract </li></ul></ul><ul><ul><li>Avoid vague terms (&quot;reasonable&quot;) </li></ul></ul><ul><ul><li>Avoid unrealistic expectations </li></ul></ul><ul><li>Outcomes: </li></ul><ul><ul><li>Damages </li></ul></ul><ul><ul><li>Varied contract (other deliverables) </li></ul></ul>
  38. 38. Ethical Considerations <ul><li>Supplier: </li></ul><ul><ul><li>Accurate representation of capability </li></ul></ul><ul><ul><li>Meet staffing commitments </li></ul></ul><ul><ul><li>Avoid external pressure (board, political, etc.) </li></ul></ul><ul><ul><li>Avoid tricks and traps (word gets around) </li></ul></ul><ul><li>Customer: </li></ul><ul><ul><li>Equal handling of tenders </li></ul></ul><ul><ul><li>Ignore extraneous issues (e.g. hospitality) </li></ul></ul><ul><ul><li>Objective scoring techniques </li></ul></ul><ul><ul><li>Confidentiality of supplier information </li></ul></ul><ul><ul><li>Professional handling of unsuccessful tenders </li></ul></ul>
  39. 39. Consider: <ul><li>Q: Should there be differences between private and public bodies in their manner of procurements? </li></ul><ul><ul><li>Why? – or are we simply continuing an outdated approach? </li></ul></ul><ul><li>Is there a better way than the processes described here? </li></ul><ul><ul><li>Eg What if the available budget was advertised to bidders rather than being hidden from them? </li></ul></ul><ul><ul><ul><li>This would have the advantage of automatically scoping the task value. Thus, bidders way out of the expected cost value could opt to ‘no bid’ Many aspects of uncertainty and risk would be clarified by publishing the expected value. </li></ul></ul></ul><ul><ul><ul><li>Bidders would then differentiated by value for money rather than price </li></ul></ul></ul><ul><li>Is the alternative seen as fair to all? </li></ul>