Engage Business Brain before Choosing Software

The golden rule is that business requirements must be defined before choosing a software solution. This is simple to understand, but not always easy to stick to. Of course, software has to help the business… but gathering the correct information means taking the time to consult the right people, sifting and sorting the information, getting the business requirements down on paper, getting executive buy in and checking afterwards that you did it properly.

How do Business Requirements Get Defined?

The simple answer is “by business people”, but there’s more to it than that. It’s true that the starting point is to match with the strategic objectives of the organization, the thing that the software solution (whatever it is) is supposed to be helping. However, major objectives often don’t translate directly into a software functionality laundry list. Tools exist to help business and technical people do just that. For instance, the IEEE 1074-1995 standard lays out different steps: as a joint business and technical effort, first make a systems requirement specification, with an overall business orientation; from that, make a software requirements specification, which defines what the software will do. Then work backwards to check that every software function defined like this makes a useful contribution to the business.

What if We Forgot Something?

It can happen. The challenge is then to manage the change needed to fix that oversight. Even if the functionality already exists in the software chosen, reconfiguration and rebalancing of system interdependencies can be a delicate operation. Different ways exist to evaluate the completeness, consistency and correctness of requirements, ranging from “use cases” to obstacle analysis. But remember also to get information on requirements from all the relevant sources. For example, go outside the firm to check out some of your major customers to see what they might be asking your company to do in the near future.

The (Infamous) Pilot Project

Software pilot projects can be a good idea – if they are approached correctly. They only become infamous when they are launched as some sort of vague proof of concept, with no clear objectives and no link back to a specific business benefit. This doesn’t mean that a pilot project has to meet the key business objective of a company all by itself. However, it should have a realistic, measurable goal to improve the business in some way, and be measured by that goal in terms of failure or success.

Scope Creep or Business Responsiveness?

You can get it right the first time, but things can still change very quickly in business requirements nowadays. Making sure you invest in a flexible software solution and have access to a savvy team to keep it aligned to business requirements is a good idea. Scope creep as such has a bad reputation and an unsavory name – yet when you rename it “business responsiveness” and build it in to your software selection and IT operations with the right change management processes, and it can stop being a problem and start to become an asset.