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

1. Simple Yes or No scores. Quick and easy to use, but omits how important specific features or functionality are to you.

1. 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.

1. 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

1. 0 to 3 range, where your requirements are: not met (0), partially met (1), fully met (2), exceeded (3). Straightforward and easy to use.

1. -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. 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.

1. 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%).

1. 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. 1 to 3 range where an essential requirement is (3), desirable requirement (2), nice to have requirement (1).

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.

1. 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:

Project budget process

1. 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

1. 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?

1. 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.

1. 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.

Budget costs

1. 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.

1. Identify and itemise all project costs

1. 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.

1. For purchases, include shipping and sales taxes (eg VAT) if unable to reclaim them.

1. 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.

1. Ensure daily or hourly labour rates include: salary + benefits + pension + social security costs ie the total labour costs.

1. Review other software projects / staff performance to get an idea of how long people take to complete specific tasks.

1. State your budget assumptions – so if these change, the budget can easily be changed.

Budget risks

1. 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.

1. 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.

Budget review

1. 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)?

1. Look out for obvious over or under budgetary estimates – attempt to be as realistic as possible.

1. 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?

1. Compare with other projects within your organisation and their deliverables, original budgets, actual costs, over / under budget analyses.

1. 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.

1. 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?

1. Are there any budgetary disagreements awaiting resolution? If so, are there project cost implications and have these been included within the budget?

1. Is the contingency for project risk large enough? What is used for other similar projects within your organisation? Can an increase be justified?

1. Have the budgetary calculations been checked for any spreadsheet errors? If not, double check.

1. Have all budget amendments been documented and reviewed? If not, add amendments into the budget and review accordingly.

1. Has the budget been independently reviewed eg by another project team member or by a member of the finance department?

30 widely used reasons for changing systems are listed below

Most organisations changing their software systems will find many reasons to justify their actions. Some, however, will only have a few reasons, which are so critical, that their system needs replacing simply because of these.

Generally, the more reasons that apply, the more likely you need to change your system. How many apply to you and your organisation?

Software system functionality reasons

1. Web enablement
2. Additional functionality available within the new software
3. Workflow and automation
4. Present systems comprise separate stand alone systems with limited integration between each other
5. Integration with other systems

Management information reasons

1. Improving the quality and quantity of management information
2. Improving accuracy of information
3. Improving access to and speed of access to management information
4. Improving the flexibility of and speed to produce management information

 System operations reasons

1. Improving system processes
2. Reducing manual effort and duplication of data handling
3. Improving system flexibility to handle continual business change
4. Improving system performance, speed and time to process data
5. Improving data input / collection capability eg automated feeds, bulk data entry
6. Improving transfer of information between systems
7. Improving system reliability
8. Present system is ageing, has not been upgraded and is now becoming difficult to maintain
9. Easier system development in the future
10. Supporting an increased number of system users
11. Improving data storage

Vendor reasons

1. Providing unsatisfactory / poor support
2. Withdrawing support
3. No longer supplying a specific range of products
4. No longer developing products that you use

Organisational reasons

1. Changing provision of services eg outsourcing, creating shared service centres
2. Changes of hardware
3. Rationalisation of systems and vendors
4. Reorganisation eg due to take over, merger, decentralisation, restructure or disposal of business units
5. Reducing costs (total cost of ownership)
6. Other actions leading to a sudden and permanent large change in numbers of suppliers, customers, employees and consequent reduction of systems requirements

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.

Cloud computing pros:

- 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.