Implementing a Requirements Development and Management Processes

Posted on: May 31st, 2013 by Lou Wheatcraft No Comments

Have you ever tried to convince management and coworkers that maybe it was time to implement or perhaps improve your organization’s Requirement Development and Management (RD&M) processes but faced a wall of resistance?  Believe me, you are not alone.  I have heard many reasons for not implementing or improving RD&M processes, some of which are:

  • “We have been doing product development using our current processes for years, why should we change?”
  • “Those processes may work for others, but not for us.”
  • “We don’t need a formal requirements process, our designers know what the customer wants.”
  • “Writing down requirements does not make sense because everyone knows them already.”
  • “We are experts – we don’t need to document requirements.”
  • “Requirements don’t add value to our development efforts — most of the requirements we get are horribly written, they are vague, ambiguous, and are always changing!!

Sound familiar?  Some of the push back can be attributed to a lack of understanding of the importance of requirements and the role they play throughout the product development life cycle.  I addressed this issue in my blog entitled “Requirements – What’s the Big Deal????

So how can you convince management that a new or improved RD&M process is needed?  3 words – RETURN ON INVESTMENT!  Think about it…what has been the impact of poorly defined scope or requirements on product profitability?  Recalls, returns, warranty costs, negative reviews, decreasing market share – not good for profitability or margins.  The return on investment (ROI) argument usually works with management especially when you can convince them that by investing in an RD&M process, they can realize a solid foundation of requirements from which to design, develop and deliver a winning product.  The better the scope and requirements, the less rework and the fewer the overruns.  By following a proven RD&M process, you increase the probability of achieving a competitive advantage by removing the bad scope and requirements obstacles to being able to deliver your product on time, on budget, and that meet or exceed customer and quality expectations.

Let’s talk about the issue of defective requirements that are poorly written, vague, ambiguous, and incomplete requirements.  The root causes of these defects are often an absence of a formal RD&M process, a lack of training in implementing and following that process, and/or a failure of management to enforce the existing RD&M process.  I address the risks to the organization of not implementing good RD&M processes in a paper entitled “Triple your changes of project success – Risk and Requirements”  Send me an email at and I will send you a copy of the paper, a presentation that goes with the paper, and a checklist for a self assessment as to the risks facing your organization because of a poor RD&M process and the best practices you can adopt to mitigate these risks.

Concerning the issue of requirements always changing, I address this in two blogs: “Why Do My Requirements Keep Changing?” and “Controlling and Managing Change”.

The information in these referenced sources should provide you with the information you need to make a good case for implementing or improving your RD&M process.

Even if you are able to make a good case for implementing an RD&M process or improving your existing RD&M process and have management backing in doing so, the rank and file may still push back.  When this happens, the source of the push back is more often due to cultural dread and anxiety associated with change not process aversion.

Changing culture is often met with opposition.  To combat this opposition, you need to use your soft skills and manage your stakeholders.  Determine which stakeholders are for and against the change.  Then determine why they are resisting the changes you are proposing.  For each individual or group, identify his or her concerns and devise a strategy to get the change adversaries to become change advocates.  Start with those stakeholders that have the most influence and convince them by addressing their concerns.  You may need to enlist the aid of other stakeholders that can help you influence those that oppose the change.

Many engineering organizations tend to be very conservative in the way they do business.  Rather than making a big revolutionary change, develop a strategy that involves incremental change over time.  It is easier to eat a turkey in small bites rather than trying to stuff the whole bird in your mouth at once.  True, it may take a long time to get where you want to be, but as long as the small changes result in improvements and actually make the engineers’ jobs easier, they will go along with the change.  Most people follow the path of least resistance.  You need to make the path you’d like them to follow easier / more beneficial than the current one.  If the change is more difficult or makes communication harder, you are fighting a losing battle.  For example, your lead engineer or project manager may already be over their head and working 50-60 hour weeks.  You want them to learn and implement a new process and a new tool to develop and manage requirements.  Good Luck.  However, if you agree to provide them with a dedicated requirement engineer or business analyst to help implement and follow the new process they will be more receptive.

People have to be convinced of the utility of the changes, how the changes result in a better product, and result in less rework for them. [Frequently the reason they are working the long hours is because they are always fighting fires, going from one crisis to another, that resulted from having bad requirements in the first place! You need to change the culture from one of firefighting to one of fire prevention.] As time passes, they may even start to be advocates for the changes that have been made and welcome further change.  Depending on the size of your organization, this process could take several years.

Because you will be in this for the long haul, you must persevere and not give up and lose faith.  Be prepared to make changes when things don’t work as expected.  Always keep the end in mind.  Incorporate the incremental changes into the existing process rather than replacing the existing processes wholesale.  Work to gain acceptance slowly.  Get your people used to seeing and using bits of the processes in small ways and grow it outwards.  People will never appreciate you telling them that their current way is poor or old fashioned – they have to discover the benefits of incorporating your proposed changes themselves.  As the old saying goes: “No one wants to be told their baby is ugly!”

Use a pilot project. Our advice is to study the current organization and workflow and look for a small project that you can use to demonstrate the benefits of your proposed changes in the short term.  You can use this pilot project as a viable example to effect larger scale change within your organization.

Several key steps include:

  1. Develop a practical RD&M process.   A good process is one that people can follow as part of their job, not something they have to do in addition to their job.  Also the process needs to fit the product line, domain, and culture of the organization. The implementation needs to be tailored to your organization, don’t try to follow a process developed by a tool vendor for some other organization.
  2. Invest in training in your proposed RD&M process and the requirement management tools involved.
  3. Pick an example project and assign the grass roots RD&M advocates to that project.
  4. Keep metrics so that the ROI of following the RD&M process can be clearly communicated.
  5. Once the project is completed successfully (an assumption) then the project can be used as an example to get other projects to follow.  The core grass roots folks can then be spread out among other projects and mentor other Project Managers and Systems Engineers and train them and their teams in the use of your RD&M process and tools.

In many of the cases where adoption has been successful, there has been a strong grass roots approach that has gradually gained acceptance across the organization, but typically only after one team has proven success.

You know you are successful in implementing an RD&M process in your organization when it is considered to be the standard to product development.  However, the road to success is long – it takes very strong, unwavering leadership and experience to get this done right.  It is human nature to try to push back and say that it isn’t possible.  It is possible!

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.

Tags: , , , , , , , , , , , ,
Posted in Requirement Development, Requirement Management | Tagged , , , , , , , , , , , , | Leave a comment

Leave a reply