An overview of rating criteria for evaluating software RFP’s
You can use many different scoring schemes for rating criteria for rfp’s. Whatever you use, however, should be applied consistently across all proposals for evaluation.
Types of scorings
- Simple Yes or No scores. Quick and easy to use, but omits how important specific features or functionality are to you.
- Combined weighting and scoring method to indicate to what degree your rfp requirements are met by the vendor/software. Slower to do, but does take into consideration the importance of different criteria within an RFP.
- Scoring schemes and weighting, may be as elaborate as you require. They need to provide you with sufficient analysis/evaluation, without being too complex, confusing or take too long. Our preference is for something that is quick to use and provides the required information eg both option 1’s below - see the RFP Evaluation Template. However, ultimately the choice is yours. Just ensure you have a written justification for your chosen scoring and weighting schemes.
Scoring schemes include
- 0 to 3 range, where your requirements are: not met (0), partially met (1), fully met (2), exceeded (3). Straightforward and easy to use.
- -3 to +3 range, where your requirements are: not met (-3), fully met (0), exceeded (+3), with points in between. More complex, more aggressive scoring, which will separate out the software/vendor’s scores. However, confusingly, a zero score is actually a good score!
- 1 to 10 range, where your requirements are: not met (1) and exceeded (10), with points in between. Again, will separate out software/vendor’s scores more than with a ‘0 to 3’ range. But because of the wider range, it may be more difficult to agree a consensus scoring.
- Percentage of points available overall (adding up to 100) eg software functionality (0 to 50%), support and maintenance (0 to 20%), implementation assistance (0 to 15%) and price (0 to 15%).
- Percentage of points available for each requirement eg exceptional (100%), exceeds requirements (80%), meets minimum requirements (60%), not meeting minimum requirements (30%), unacceptable (0%), with percentages in between.
Weighting schemes include
- 1 to 3 range where an essential requirement is (3), desirable requirement (2), nice to have requirement (1).
- 1 to 5 range, where an essential requirement is (5), desirable requirement (3), nice to have requirement (1). Will give greater emphasis towards the essential and desirable requirements.
- Overall percentage weights eg 50% software functionality, 20% vendor capability and 30% price.
Using scores and weightings
Consensus scores, multiplied by weighting in a matrix provide an unbiased evaluation of the vendor’s proposal. Weighted scores may be summed to arrive at scores for certain functionality criteria or software modules.
Proposals ordered by total weighted scores, form a basic priority list - highest scores first. The results provide a short list of the top 2 or 3 vendors to include within the final software selection process.
25 tips for a more timely and accurate budget
The budget for a new software project is a key component in the ROI calculations. Here are 25 tips for obtaining a more timely and accurate budget:
- Determine your budget process eg
- the steps required to gather the information
- the time scales for your budget process and key dates
- the deliverable(s) required
- who is involved and what resources are available
- the formal review stages
- the number of project budget iterations and re-workings
- how any budgetary disagreements should be resolved
- Is one person to be in overall charge of calculating the project budget? Or will various sections of the budget be allocated to team members to complete and then be consolidated together?
- Ideally there should be input from a number of people associated with the software project. So arrange for contributions from the project manager, project leader, information systems manager, key users, steering group members, vendors (for software quotes) and procurement.
- Remember, your first calculation of the budget is just that – your best estimates and (educated) guesses at the time. Treat the budget calculations as ongoing ‘work-in-progress’ and continually refine and revise, until the budget is approved / finalised. But even after approval, unforeseen events and project changes can force a budget to be revised or reforecast.
- Determine what you are including within your project budget. Include only in-scope items. Exclude all non-scope items. But keep a list of excluded items, so they may be included or budgeted for at a later stage, if required.
- Identify and itemise all project costs
- Determine if you are working on an incremental cost basis (ie only including new or additional costs for your organisation). Or whether you are working on a full costing basis (ie including the project’s share of allocated costs incurred within the organisation). If including allocated costs, do so, on a consistent and agreed basis.
- For purchases, include shipping and sales taxes (eg VAT) if unable to reclaim them.
- Cost all tasks within the project plan. Initially labour costs can be estimated as the number of days x their estimated cost. Later on, more accuracy may be achieved by working in hours and an hourly rate.
- Ensure daily or hourly labour rates include: salary + benefits + pension + social security costs ie the total labour costs.
- Review other software projects / staff performance to get an idea of how long people take to complete specific tasks.
- State your budget assumptions – so if these change, the budget can easily be changed.
- The total project budget is the sum of the itemised estimated costs plus contingency for project risk. Typically, contingency (for project risk) can range from 5% of costs for a small quick project, to 30% or more for a large, complex or long project.
- One option for calculating contingency is to simply add a percentage to the total costs, based on your best estimate. However, for more accuracy, you could identify the known and potential risks and then estimate a contingency for each project cost item. Risks can include: the number of software modules, the number and experience / skills of resources, project dependencies, critical dates, time shortages, implementing over multiple locations, new technology and costs yet to be negotiated.
- Regularly review the budget, both on an informal and formal basis. Whilst the total project budget cost is important, are there any components which look high, low or unusual? What is the budgeted project cost per user (total project budget costs divided by number of users)?
- Look out for obvious over or under budgetary estimates – attempt to be as realistic as possible.
- Compare your calculations with those from the software vendor. What is their estimated total cost for your project / organisation? What is their typical total project cost and typical cost per user, for projects that they have undertaken elsewhere?
- Compare with other projects within your organisation and their deliverables, original budgets, actual costs, over / under budget analyses.
- Is your budget broadly ½ software and ½ labour (ie excluding hardware expenditure within the project)? Or is it roughly one third each for software, hardware and labour (if replacing hardware)? If not, re-examine your costs.
- Are the budgetary items and their costs included in the correct year? Is the budgetary phasing / timing accurate? Have any warranty periods been included, prior to the commencement of annual (maintenance) costs? Would greater accuracy be achieved by phasing costs over months or quarters, rather than in years?
- Are there any budgetary disagreements awaiting resolution? If so, are there project cost implications and have these been included within the budget?
- Is the contingency for project risk large enough? What is used for other similar projects within your organisation? Can an increase be justified?
- Have the budgetary calculations been checked for any spreadsheet errors? If not, double check.
- Have all budget amendments been documented and reviewed? If not, add amendments into the budget and review accordingly.
- Has the budget been independently reviewed eg by another project team member or by a member of the finance department?
And what cloud computing is good for
Cloud computing usage is growing quickly, but is it right for you? We outline below the arguments for and against cloud computing.
- Any device access. You can access cloud data and applications with any computing device connected to the internet.
- Unlimited scalability. You have the ability to scale up your computing requirements, with huge storage capacity.
- You can dramatically boost your infrastructure resources at a relatively low cost.
- Group collaboration is easier, especially if you are jointly working on documents or projects.
- You can quickly obtain and deploy software applications. Therefore, giving you greater flexibility.
- You can access the latest version of software applications.
- Software updates are automatic, saving you time and effort upgrading your own system.
- Potentially lower costs. You pay or rent ‘On-demand’ or SaaS on a subscription basis, rather than purchase software. Up-front costs are likely to be lower, but costs may even out in the longer term. Other software costs may be reduced such as office software costs, if you use the free software available. There is a reduced need for servers and the opportunity to use lower spec / lower cost PC’s and internet devices.
- No fixed costs. All costs are variable.
- Environmental savings – from more efficient use of hardware and power.
Cloud computing is good:
- For collaboration work
- If you work from multiple locations and you need to access your data and applications whenever you are.
- If you need lots of storage space or to upscale, your computing needs very quickly.
- If you wish to spread your costs more evenly over time.
Cloud computing cons:
- A constant internet connection is required. Without the internet, you cannot access your data or application.
- Potential unreliability of cloud computing vendors. So, look at the vendor’s system reliability or downtime reports. Do you need temporary alternatives to deal with any short downtimes eg wireless dongles? Or, applications that you can run locally, and then synchronize when the system is back online?
- High-speed internet connections are required for cloud computing usage. While it is possible with a dial up connection, it is slow and laborious.
- Even with a high-speed connection, performance can be slow, due to the number of users on the internet or competing for resources.
- Many security issues around accessing and storing data (see article on cloud computing and security).
- If you do not wish to rely on the cloud data storage, there is no local physical back up. You will have to back up to your own local device if you need this.
- Costs may quickly increase, if usage / resources are increased. It is worthwhile checking how and when such cost increases may occur.
- Lack of control over data, system performance, the ability to audit or change processes.
- Potential inability to see who is viewing / accessing your corporate data.
- Risk of data loss if your organisation is locked into a proprietary format.
- Limited software features. Some cloud-based software may not be fully featured, and this would need to be checked before signing up.
Cloud computing is not good:
- If you don’t have an internet connection or only have a slow internet connection.
- If your business is tied to existing software applications. Some web-based applications are not completely compatible with offline systems.
- For organisations concerned about security, or have to maintain data privacy requirements for compliance eg for HIPAA, SOX.
Some applications currently appear to be more appropriate for cloud computing eg CRM rather than HR or Payroll. However, it is an individual organisation’s choice as to whether to use cloud computing. As ever, there is a trade-off and the need to consider whether the benefits of cloud computing are worth the costs.
Quickly and easily gather your BI system requirements, prepare your RFI and RFP, and also evaluate vendor responses
This ‘Business Intelligence (BI) RFI/RFP Template’ covers nearly everything you need for gathering BI system requirements, preparing your RFI and RFP (for issue to software vendors) and for evaluating and comparing vendor responses. The BI RFI/RFP Template will:
Save you time identifying and gathering your software system requirements because thousands of carefully researched criteria are listed. Simply choose those you need and set their priorities. Then quickly prepare your RFI and RFP, by just filling in the blanks. And as everything is in MS Excel, it’s quick and easy to amend to your precise needs.
Save you effort as you don’t have to start from scratch. The template reduces the effort involved with specifying requirements and preparing RFI’s and RFP’s.
The standardised format also helps software vendors to more clearly understand your requirements and more easily respond to each requirement, using the space available within the template. So you will receive clearer and improved responses. And consequently, spend less time and effort evaluating and comparing vendor responses.
Save you money as you can use the template yourself. There’s no need for extra staff or resources to help you gather your requirements or prepare your RFI or RFP.
Moreover, the template supports your overall project cost control. It will help you to focus your attention on your real business needs and software selection tasks, rather than considering vanity criteria or wasting time looking at inappropriate software.
Help you to select the right system by providing clarity and transparency. You can see your requirements, easily evaluate and compare vendor responses and so identify the best solution for your organisation.