Evaluating the response
| Module 1 | Planning |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
| |
|---|---|---|---|---|---|---|---|
| Module 2 | Solicitation |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
| |
| Module 3 | Contracting |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
| |
| Module 4 | Additional resources |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
|
Unit 6
|
| Module 5 | All toolkit downloads |
Unit 1
|
Reviewing the bids and making a selection based on the evaluation criteria you published can be daunting and even confusing. Chances are that the clearer and more consistent, concrete and realistic you were in the solicitation document/PWS, the easier your review process will be. It can be useful to invite reviewers from outside your program to help ensure an objective review and scoring of bids. In some jurisdictions, the contracting office will establish the review panel.
Considerations
- Typically, the program will determine the technical criteria for the evaluation, and also the weight and value of the technical score relative to pricing.
- If procuring a new system, requiring software demos or access to a training environment can be an excellent method for evaluating a system. After all, the primary objective of the solicitation is to select an appropriate vendor/product!
- Access to the training environment can provide practical insight into usability and even configurability of the system. Make sure that your solicitation process leaves sufficient time for scheduling and conducting demonstrations if you choose to do so.
Check-list for evaluating the response:
- Have you developed clear instructions for reviewers?
- Have you developed score sheets that match the criteria or other information from evaluation and scoring in the solicitation?
- Have you established a tone of objectivity and non-bias for the review process and the reviewers?
- Have you warned reviewers to be wary of “the grass is greener” thinking? That is not an appropriate evaluation criterion and will not necessarily prove to be true.
- Taking a use case approach to product demonstrations (e.g., “Show us how a user would mark a patient as inactive,” “Demonstrate how a new vaccine shipment is entered for private inventory,” or “Show us how a provider generates a list of patients due for shots in the next month”) can provide a good sense of how well the system supports functionality that is important to you and/or efficient workflows for users. It can also prevent the offerors from focusing only on the most favorable aspects of their software.
- In comparing costs between offered products, a best practice would be to conduct a total cost of ownership calculation looking at all aspects of acquiring, installing, configuring, enhancing and maintaining the product and any underlying licenses over a five-year period.