As a software vendor, we receive and review dozens (hundreds?) of Requests for Proposal (RFP’s) every year for HR Case Management, Knowledge base and Self-service software.
The Rise of Feature Overload
It used to be that the typical RFP requested between 75 and 150 product features (excluding non-functional requirements, like data security). But within the past 18 months, that number has increased dramatically. The typical RFP now requests 150-300 features, with a few outliers exceeding 500. Feature overload is clearly becoming an unhealthy issue.
But wait – that’s not all …
Many of the RFP’s classify the feature requests as “Low,” “Medium” or “High” priority. And when they do, it’s not uncommon for over 90% of the features to be ranked as “High” priority. I should think a high priority feature is one that you can’t live without; a feature without which the project would likely fail. Well, you know what? That’s rarely the case.
When your eyes are bigger than your stomach
When some companies implement a category of enterprise software for the first time, many of them act like hungry patrons at an all-you-can-eat buffet (I know – I’ve been on both sides of the table!). We load up our plates with everything that looks good, with little regard to how much of it we’ll actually consume.
The end-result is either a lot of wasted food, an upset stomach, or both.
According to research by Cambridge, MA based Standish Group, 19% of software features in production are “Rarely” used, and 45% are “Never” used. How many of those “Never Used” features were high priority when the project began? (If you do the math, 90% X 45% = 40% of all the features are never used!)
A better way to eat a buffet
Instead of loading up your plate on the first trip to the buffet table, why not just take those items that you know you really want, and will really eat? You’ll have satisfied your core cravings, while knowing that you can go back to the table for some extras later.
A better way to implement software
Some of the most successful implementations take a similar iterative approach. Instead of loading up on a lot features during the initial implementation, they’ll implement a leaner selection of on core features that are necessary to get the project off the ground, and the users on board.
This iterative approach can be a healthier way to consume software for everyone involved.
It’s better for your project team:
- The initial implementation is faster.
- There’s less training required.
- User adoption is faster, when the system is simpler to use.
Faster implementations with higher user adoption portend more rapid and substantive ROI.
It’s better for the end user:
- Fewer new features make a system simpler.
- Simpler systems are easier to learn.
- Easier systems are less frustrating, and remove a barrier to engagement.
It’s better for the customer-vendor relationship.
- The more functionality you choose to implement, the more that can go wrong in the project.
- The less that does go wrong, the more likely the relationship will be a healthy one.
- Healthy relationships are, well, healthier. And healthier is always better.
The next time you’re implementing software, consider keeping your features appetite in check – at least during that first trip to the buffet table. Remember, the you can always go back for more.
