I don't know why but when it comes to business systems and custom software development projects most non-technical people just want to punt the ball over to the technology people. I assume most times its largely becuase they feel they can't contribute without a technology background. THAT IS A HUGE MISTAKE. I can't stress this enough so... THAT IS A HUGE MISTAKE. Business Requirements are your business needs in a documented form that the technology group is to build to. If you trust your tech people exclusively to understand the ins and outs of your business and hence your business needs then you are setting yourself up for disappointing results, extended delivery schedules and cost run ups for your technology projects. It doesn't matter if you are seeking technology that is custom coded, prepackaged software or software as a service via the web, each company needs to have business managers write business requirements. It becomes the litmus test for creating value to your business by its technology. If the technology doesn't meet the business needs then managers shouldn't accept the technology delivery. That go, no go decision needs to be made against a Business Requirements document. That document is created with business managers and handed off to technology managers for review and clarification. Before it is fully accepted it is signed off by both groups and it is the "guiding light" for technology documentation, technology development and final technology delivery.
If business managers short cut that process or remain uninvolved then expect to be disappointed and worse yet risk that you spend money and time and add little value to your business.
What Goes Into a Business Requirements Document:
- Business background - it is very possible that outside technologists will be involved in your project and have no knowledge of your business or industry. Let's face it, they see the world very differently from the way you do, so help them. Supply them with details on what your business is about. This includes who the customers are, what you provide as service, most critical competitive advantages and a little about what your business is not but outsiders would consider. Put in what your core competencies are and what is outsourced.
- Prompting for Project - put down the business reasons for why you are pursuing the project. You can touch on technology reasons (i.e. current systems not scalable, too expensive, etc.) but you should stick to business reasons (i.e. scalability - your business is growing or diversifying overseas). Make sure to list the current systems and support architecture that exist in the business and whether they are relevant to the project or not. Even if you think they are irrelevant still list them.
- What business value do you need - list all the business improvements that you expect from the project (i.e. less than 1 day to train someone, instant report generation with real-time data, etc.). Put as many as you like - sky's the limit at this stage. BUT, prioritize them. Most companies don't have the budgets to get everything they dream of.
- Cost savings and payback - make sure to list any cost savings and payback objectives to the project.
Limits on licensing and costs - make sure to explicitly state what is allowable and not from a one-time and on-going budgeting basis. If you want a freeware system or its your preference then be explicit about what you're looking for.
- Set Your Technology Preferences - culturally some companies just want to stick to Microsoft or Oracle or custom code. Make sure to describe your preferences.
- Determine your business representatives - you should determine up front who on the business side will be interfacing with the technology folks during the project. These will be the "go to" people for process questions and minor item decision points.
- List anything existing you like - make sure to provide links to web sites and technologies for anything you like and think you may want to have. This could be small things like look and feel of a software interface to major function items like user defined data interfaces. The more specific and solid the examples you can provide the more likely you'll get a final result you're happy with.