How To Find Requirements

Lately I have been working on getting the requirements for a product from the customer.  I find that gathering those requirements is a critical piece of the puzzle for project success.  Many a project goes bad because of either a lack of requirements or the wrong requirements.

Gathering requirements is not easy, the customer is busy and the customer may not even be the end user.  There are a couple methods that I use to get those requirements.

The user survey is one method.  This method is a little hands off, but it can provide very good insight especially if the questions asked are open ended.  Additionally, there has to be followup sometimes and that might pose difficulties if the end users are at distant locations or if they are otherwise not available.

The other method that I use is extensive interviews.  These interviews are used to drill down to the essence of those requirements.  Sometimes you have to ask the question "why" to make sure you get the real reason for the requirement.  It is not enough to take those requirements at face value, because this is usually only focused on the pain of the moment and not the root cause of the issue the product or project is intended to solve.

Requirements gathering can be difficult and confusing.  Bad requirements is one of the reasons that projects fail.  This stage is critical for project managers and the project manager should devote the time to truly understand the requirements.

Requirements?

Recently I took on a project that needed help.  In my position, I commonly get brought into projects that have issues and need help.  This particular project is the acquisition of a piece of equipment. From the beginning of the project, there were no requirements.  The organization wanted this particular piece of equipment, but they did not have the requirements to use it.  I guess they were in a "buy it and we will figure it out" situation. This situation is not really what you want before an organization makes an expensive capital purchase.

The purchase is on hold.

We are now going back to the beginning and gathering the requirements and specifications for this piece of equipment.  I am building a Requirements/Specification Breakdown Structure to help visualize those requirements/specifications. Additionally, I am building the Requirements/Specification Breakdown Structure to show management the business case for the purchase of this machinery from this point of view.  The danger is that the data will not bear out the case for the purchase of the equipment and the previous work will be wasted, but that is why we have the process.

One lesson learned from this situation is to start with the actual requirements before falling in love with a piece of equipment.  Requirements need to be validated through the organization and provide an answer through a real business case.  So many organizations do not do this and end up wasting time and money on actions that do not provide value to the organization.