It’s human nature to want more. We want new cars with all the options, home electronics with all the latest features, houses with more rooms and bigger kitchens. Let’s face it, we all want to show off every once and a while. After all, we’re human, right?
But, how many of us use all the features in our “fully equipped” cars or home electronics? How many times does that extra space in your home collect nothing more than clutter and unused exercise equipment? Better yet, how many of us know how to use some of the features we wanted? When was the last time you read the owner’s manual that came with that new car you just bought? I admit it; I only look at the manual when something goes wrong and I’m pretty sure that my car has features that I’ve never used or don’t even know about.
It’s really no different when it comes to selecting a business application. Whether you’re capturing Business Requirements or developing a Request for Proposal, most of us add everything we can think of when asking for what we want in an application or business solution. Ah yes, the proverbial “wish list”. And, most vendors will do everything they can to promise to deliver on our “wish lists”. From the customer side, I understand the philosophy of casting a wide net. But, how often do we take the time to identify what features and functionality are really needed and focus on them? Is a full size, 3rd row, 4- wheel drive SUV really necessary for a couple living in Manhattan?
When creating business requirements or an RFP, you should ask questions like “do we really need that functionality” or “will we ever use that feature” before adding them to your requirements. You might say why limit your requests? You never know when some of that functionality will be needed. But, there are a few good reasons to focus on JUST what you really need:
- Change Management – This is something that is rarely on the radar when developing business requirements. System rollouts often struggle or stall because of the complexity of the application and the extent to which the new system alters or disrupts the current workflows and business processes.
- Training – The level of training and the training time needed to become proficient with a system can be a function of the system complexity. The amount of training needed by the end users is often overlooked when developing business requirements. Consider how much time and patience you will have while you wait for staff to become fully trained and proficient with your new application.
- Support Issues and Upgrades – Keeping with the new car analogy, "the more features it has the more things that can go wrong". Consider that you may be spending support time resolving issues with features you either don’t use or didn’t need. Also, upgrading a very complex system may require more planning and longer testing time.
So, before heading out to find that perfect system or application, make sure you spend enough time “objectively” considering what you really need. The cost of not doing this may, in the long run, may be more than you are willing to pay.
Note: Healthfirst employment is listed for identification purposes only. Opinions expressed are personal opinions and not those of my employer.#businessrequirements #ProjectManagement #RFP