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.

Things Program/Project Managers Do!

Summer has always been a busy time.  I find that during these days, I have more energy and the to do list grows both at work and at home.  I always feel a little accomplishment when I cross things off my to do list and deliver those products to the customer.  This month, I completed the Requirements Breakdown Structure that I have been working on.  It is a little satisfying when the stakeholders like an innovative product.  During this month, I also conducted a Risk Analysis for an organizational change that is being contemplated.  I hope that my input is helpful for the decision makers when it comes to redesigning the organization. Another product that I delivered was a redesign of part and the Statement of Work for the manufacture of this part.  I also conducted a Schedule Variance on one of my projects for a high level briefing.  All of this is what a day as a Program Manager could look like.

The purpose of this post is not to brag about all the great things that I have done.  They are great things, but nothing in comparison with the great things done by the people who protect us everyday. The purpose of this post is to talk about the variety of things that a program/project manager might be called to do in the course of the project.  I always find that being a program manager allows me to use my creativity to get the products out the door and to tell the story of the products to stakeholders. It is one of the things I find I enjoy about my job.

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.

Tools Tuesday: Requirements Tracker

The requirements tracker is an important tool that you can use to log and track requirements.  I use this tool to log, categorize and to track the requirements that I elicit from the customer.  Of course, this helps as you start to work the project and start to complete the requirements and as new requirements are discovered.  It also helps to keep the track of those requirements that are in the contract and those that are not.

This document was made in excel and is updated as needed.  This is a handy tool to communicate with project team members and stakeholders.

Another way to elicit requirements is through a survey.  I have in the past had mixed results with the survey.  In my recent experience, the survey was not sent to the subject matter experts and the survey data was not very helpful.  As a matter of fact, the group/panel discussion provided much better data.  It was a step backwards from where I wanted to go, but at least I found this out early in the project and did not attempt to provide a product that did not meet the requirements.

This is why requirements are important for the successful project manager.

It's All About Requirements

Before a project is started and maybe even while the project is going on, there needs to be good requirements.  For many projects this is a difficult enterprise.  This is because there may or may not be time to elicit the requirements.  But successful project managers know that this is absolute an imperative action to ensure project management success.

Requirement elicitation is important.  It is important to know exactly what the customer feels the features of a done project look like.  There are  techniques that a project manager use to elicit these requirements.

One technique is to interview the customer about the requirements and what done looks like. This type of information might be in the Statement of Work (SOW) or the Performance Work Statement (PWS), but that is not always the case.  The interview should use probing questions and should refrain from yes and no answers.

Another technique is to hold a panel or focus group of the customer's subject matter experts.  This type of technique can draw out many responses, but it can also get out of hand quickly and requires a steady hand to guide the discussion.

Once the requirements are discovered they need to be categorized as critical, must haves, and like to haves.  This categorization allows the project manager and project personnel to understand the prioritization of work.

Then the project manager needs negotiate all the requirements into the the SOW or PWS and included into the contract. 

All the critical and must-have requirements are tracked in the requirements tracker throughout the project.