The Art of Procuring Paratransit Software

1. Will RodmanVice President of Business DevelopmentTSS Paratransit The Art of Procuring Paratransit Software

2. Preliminaries • Your current software • Not performing? Why? • Service performance standards • Is productivity not high enough? • Is on-time performance not high enough? • Before you “blame” the software….

3. Preliminaries (continued) • How much of this is attributable to: • Service model • Policies, practices and procedures? • Contractual provisions • Conditions beyond your control • It may not be the software

4. Preliminaries (continued) • But if it is, is the underperformance due to: • Things in the software that you haven’t done? or • Things in the software beyond your control? • Routing algorithms • Lack of – or too complex -- tailoring capabilities • Bottom line: if you cannot shape the results… • Then maybe it is time to switch

5. Other Reasons to Switch • Is your software keeping up with the times? • Run structure/service mix optimization? • Same old algorithms? • Universal speed settings? • Complex parameters? • Confirmed pick-up times without pre-scheduling?

6. Other Reasons to Switch (continued) • Available capacity of other DRT? • Re-optimization (after scheduling)? • Proactive dispatch tools? • Consideration of real-time traffic conditions? • Driver tablets? • Customer self-servicing functions? • Direct booking, cancellations, confirmations • ETAs/vehicle locations • Customer portals

7. Other Reasons to Switch (continued) • Are the reports only somewhat useful? • Is the software just too expensive? • Expensive add-on modules? • Has your vendor forgotten about you?

8. General Considerations • Changes indirectly related to software: • Coincide major changes with new software? • Make major changes beforehand • Why? So you know what is attributable to changes vs. new software • Don’t change too many things at once • Changes directly related to software: • Make major changes after

9. General Considerations (continued) • Do your homework beforehand • Go to tradeshows • Visit websites • Request demo (or say yes to demo offers) • Talk to colleagues you trust from other systems • Request for Information • This will help shape your specifications

10. General Considerations (continued) • Decide what you want, and specify…. • Detailed processes for all functions • Fixes to shortcomings of current shortcomings • New capabilities and/or linkages • Data ownership; open-source requirement? • If changing service model, decide whether… • Transit agency will be the software licensee • Contractor(s) will be the software licensee

11. General Considerations (continued) • 1-step process or 2-step process • Request for Information (Pre-Qualification?) • Request for Proposal • Expiration date or annual re-up date • Type(s) of license (you specify options) • Fixed and Performance-based payment?

12. Procurement Truisms • Insufficient competition drives up price • Why might a software vendor not respond? • Does not know about the procurement • Not enough time to respond and/or to implement • Thinks it is wired • Too much risk – might still bid, but may bid high • Too small? Too large? • Low bid vs. best value • Evaluation emphasis that doesn’t match

13. Procurement Notices Be proactive! Make it easy for proposers!

14. Procurement Truisms (continued) • Do use best value process; you aren’t procuring widgets • Do not reveal license prices before Technical Proposal has been scored • Do not have two different committees evaluating technical and price proposals • It always takes longer than you think it will

15. 1-Step Procurement (9-15 months)

16. 2-Step Procurement (add 3-6 mo)

17. 1-Step vs. 2-Step Process? • 1-Step Process (RFP) • Advantage: Shortens overall schedule • Disadvantages: More to do in each step Limits opportunities to learn and inform RFP • 2-Step Process (RFQ or RFI precedes RFP) • Advantages: Attracts a broader interest Enlightensagency; informs RFP Enables a short list • Disadvantage: Lengthens schedule

18. RFP Structure and Elements • Introduction • Background • Service description / Where you are heading • Current technology platform • Scope of Services and Procurement Schedule • Minimum Qualifications • Licensing Options • Evaluation Process and Criteria • Proposal Structure and Submission • Required General Terms and Conditions / Forms

19. RFP Structure – Introduction

20. RFP Structure – Background

21. RFP Structure – Background

22. RFP Structure – Background (cont’d)

23. RFP Structure – Scope of Work

24. RFP Structure – Firm/Staff Quals

25. RFP Structure - Licensing

26. RFP Structure - Licensing (continued) • What’s included? Upgrades, new versions How much training, support? • License fees often dependent on size of service • Ridership, Fleet Size, Number of Users • Performance-based payments? • Replacing license fees may scare away proposers • Be careful about how to apply -- most performance metrics affected by factors beyond vendors’ control • If used, maybe apply to profit or portion of profit? • Or, leave it up to proposer (e.g., MBTA in Boston)

27. RFP Structure - Transition Costs

28. RFP Structure - Additional Costs

29. RFP Structure - Evaluation

30. Technical Proposal Scoring 100-125 points • Project Understanding 10 • Functional Capabilities of Proposed Solution(s) 50 • Mobilization/Transition Plan 10 • Training and Support Plan 10 • Corp. Capabilities, Experience, Past Performance 15 • Key Personnel Qualifications and Experience 5 100 • Product Demonstration (may include field trip) 25 • Ease of use • Ability to explain how product/processes work

31. Price Proposal Scoring 50 points

32. Proposal Structure & Submission

33. Technical Proposal Elements

34. Price Proposal Elements

35. Last Lesson Learned

36. Thank you! Questions?