1 / 22

TECHNICAL SPECIFICATIONS WRITING & EVALUATION

TECHNICAL SPECIFICATIONS WRITING & EVALUATION. David Stein, Principal dstein@plannet.net 714-982-5814 PlanNet Consulting www.plannet.net. Introductions and Background Dealing with Techies Process for Gathering Required Information Authoring Suggestions Defining Evaluation Criteria

tacey
Télécharger la présentation

TECHNICAL SPECIFICATIONS WRITING & EVALUATION

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TECHNICAL SPECIFICATIONS WRITING & EVALUATION David Stein, Principal dstein@plannet.net 714-982-5814 PlanNet Consulting www.plannet.net

  2. Introductions and Background • Dealing with Techies • Process for Gathering Required Information • Authoring Suggestions • Defining Evaluation Criteria • Reviewing Vendor Responses • Q & A Agenda

  3. PlanNet Consulting • Independent communications technology consulting (voice, data, video, cabling) • Project consulting and managed services for wide range of universities and enterprises • Many national conference presentations (ACUTA, VoiceCon, CORE, ALA, Interop, IPComm) • Numerous articles in BCR • David Stein • 25+ years in communications technology • Managed hundreds of physical infrastructure, voice and data projects Firm Background

  4. Physical Infrastructure • Communications Technology • Systems and Storage • Information Security • Business Continuity • Managed Services Services

  5. CSU • ITRP (System-wide) • CSU Chico and SLO Voice Strategy/PBX • CSULA, CSUDH and SLO Physical Infrastructure • CCCD • NOCCCD LAN (District-wide), new HQ & datacenter • SOCCCD (District-wide voice and data) • Coast CCCD (New datacenter) • UC • UCI – Student Residences (Internet, Physical Infrastructure, voice, wireless) • Federated – CALVIP (CVS) Higher Education Experience

  6. What’s Special about Technology Specifications? • A lot of parties must now play well together • True or False: • Most People can tell you what they want? Setting the Stage

  7. Planning

  8. What type of Procurement Vehicle will be used? • Prequalification • RFI • Bakeoff • RFP (1 or 2 stage) • RFQ • CSI Specification • Division 16 • Division 27 • CMAS • Sole Source Information Gathering

  9. What is the resulting Contract Form? • Master Enabling Agreement • Open for several years • Discount off of List Price Strategy • Single Occurrence Information Gathering

  10. Executive Order 862 • $500,000 value or ‘Great Impact’ • Includes cost of Personnel • Feasibility Study • Formal Solicitation Plan • Procurement • Implementation • Review Special Administrative Guidelines?

  11. When Dealing with Techies UNFAMILIAR with Procurement: • Get involved as soon as possible • Interview them to understand their needs • Schedule recurring sessions • Patience needed on both sides Rule of Thumb

  12. When Dealing with Techies UNFAMILIAR with Procurement: • Administrative Issues of the RFP • T’s and C’s • Acceptance • Understand their funding sources • Educate them on the process and schedule Rule of Thumb

  13. Defining Criteria: • Special Attention to ‘pass/fail’ • What’s the difference between ‘must’, ‘shall’ and ‘should’? • Must have criteria weighting completed prior to receiving responses • Only Publish high level weights to bidders (i.e. price is 35%) Authoring Suggestions

  14. Sample Specification TOC: Authoring Suggestions • 1.Introduction • 1.1.Purpose • 1.2.Background • 1.3.Audience • 1.4.Scope • 1.5.Notation • 1.6.Response Format • 2.Network Architecture • 2.1.ITRP Program Overview • 2.2.Technical Architecture Reference Model (TARM) • 2.3.Development Process • 2.4.Role of this RFI within the Development Process • 2.5.Vision • 2.6.The Network is a Critical Technology Infrastructure Utility • 2.7.Standards-based Solutions

  15. Sample Specification TOC: Authoring Suggestions • 4.Functional Requirements • 4.1.Protocols • 4.2.Performance • 4.3.Scaleability • 4.4.Management • 5.Wireless Architecture • 5.1.Overview • 6.Common requirements • 7.Direction to Vendors • 7.1.Response I: Device-Specific • 8.Response I: Functional Requirements • 9.Implementation, Operation and Support Requirements • 10.Appendices • 10.1.NBSA Document • 10.2.Wireless Architecture Document • 10.3.CSU Standards & Regulation • 10.4.Document References

  16. Example: Authoring Suggestions

  17. Sample Criteria: • Reliability • The CSU is interested in how each vendor will provide redundancy (High Availability) in a wireless LAN. • [R-59] LOW - Redundancy provisions include dual Ethernet ports on a single access point • [R-60] HIGH - Redundancy provisions include RF coverage change within the same frequency due to access point failure • [R-61] HIGH Redundancy provisions include RF channel or interference resolution • [I-18] MEDIUM - The vendor is encouraged to provide any unique solution its product or solution may provide. Authoring Suggestions

  18. Who should lead the Team(s)? • How many evaluation teams? • Technical • Admin/Financial • Strong Leader • Understand Project Goals • Keep Team focused Response Review Team(s)

  19. Who should be on the Team(s)? • Experience with subject matter • Experience with specific project • Right ‘Mix’ of personalities • It’s like a jury! • Team Players Response Review Team(s)

  20. Review and Rank individually • Review and Rank as a team • Hybrid • Keep VERYGOOD Documentation • Justify Rankings, note especially strong or weak responses • Reference Checks Review Methodology

  21. 4.3.1.23 All three vendors mentioned the use of the Network Analysis Module (NAM) device for network management as well as a portable RMON device. SBC, however included these as part of their base design while Verizon and IBM only mentioned these as options. These tools are important for minimizing labor cost, decreasing repair time within the network and offloading processing work on the core switches. SBC’s response is deemed superior. Sample Review Comments

  22. THANK YOU!!! • Q&A? Questions, Discussion and Close

More Related