write business requirements

Who should write business requirements?

You believe you need a system to solve all of your problems. Vendors should not write the business requirements. Why? They don’t know the business, like the business.

In a perfect world the business would first document their business requirements.  And, in a not so perfect world .. a software vendor will suggest that they develop them for you.  WRONG APPROACH.

Vendors should not write business requirements for you. Here are five key reasons why:

1. These are business requirements

Doesn’t that title in itself tell you something.  A software or system vendor is not going to know and understand your business.  They won’t know how you do what you do and why.  Sure, they may THINK they have a good idea,  “Well you’re just like Company X that we supplied this system for”.  But you’re not Company X are you, you’re you,  with your own unique business environment.  They have a system that they can tailor or adjust to meet what they perceive as your requirements.  Bottom line is, until they worked in your business for a number of years, they would not know all of the things that are important to your business. They will not write business requirements that truly reflect how you operate or want to operate.

2. They don’t understand the maturity level of your organisation

I am going to use the example of implementing a Project Management tracking system.  Vendors will not know the maturity level of the Project Managers, Project Officers, and Business Analysts etc who do your project work.

Every area within a business has a maturity level based on the skill set of the staff working in it, the systems they have currently, and the way they operate (in general).  This may or may not be different to the overall maturity level of the whole organisation.  This is a very important aspect.   For this example, your project staff might be very junior in their skill and experience level, and yet if a vendor develops the requirements for a system and you implement it to track your projects and the system is set up for a very mature organisation from a project management perspective, there is a problem. How likely are the staff to want to use the system?  If you even get that far down the implementation track.

3. Vendors have a vested interest because they want to sell you their system

Naturally, they know all of their systems ins and outs and want to sell you the most wizz bang package that they can.  Oh, and especially when it’s something that they then have to support, which is going to cost YOU money.  Off the shelf systems are great.  I am not advocating making the choice to go down that path. Simply start with the business requirements, written by the business so that you end up with what you really need to improve your business.

4. Vendors staff may know the system technically, not how it works with your business processes

Vendor staff know the technical aspects of the system and are NOT users of it themselves, in the general business sense.  Therefore they have no understanding of how your users will be using the system.  Back to the maturity point.  If the vendors staff member documenting the business requirements knows all of the fancy elements of the tool, they will want to write the requirements in order to capture these features.  Does the use of these features match the maturity level of the staff who will be using it?  No, they don’t. Your process for managing project might not be the standard model. Even with vendors working with your staff to capture the requirements, there is likely to be a mismatch in terminology and the use of language such that any requirements will be written in a way to not fully meet your needs.  Your staff might call project functions something completely different, within your own environment, but the ‘system’ speak has different definitions.. ones that doesn’t match what you would want.

5. What’s important to the vendor is not important to you

Things that might be of high importance to you, as a business unit/area/organisation, for instance that reporting be in a specific way to match Senior managers requirements, might not be considered as important from the vendors perspective, and so the requirements may not truly reflect what you require.
Getting a vendor to write your business requirements is NOT the easy way out.  Why?  Because if you do, you will more than likely have a lot of REWORK to do, when the business starts to look and play/test/work with the system that is implemented.  Then you’ll really find out, the hard way, that the requirements really don’t match business user needs.  Which in turn shows that it is well worth the resources and time to write business requirements using business resources.  Think about it next time you have requirements gathering to do.

Let the vendors show you how fantastic their systems are AFTER your BUSINESS REQUIREMENTS have been clearly defined by you.

I have seen two many projects where the vendor has written the requirements and the business has not only ended up with a system that doesn’t work for them, they have paid dearly in the future in order to fix the system or in some instances even, replace it with something else.


Written by Karen Munro