Implementing Requirements Management: A Pattern for Success *

By: Betty Luedke

Abstract: After guiding the Requirements Management (RM) Process/Tool Implementation at several medium-to-large government and commercial organizations, an approach has emerged to successfully implement a RM process with tool support. This approach is sensitive to the environment in which it is used.

Betty Luedke is an accomplished project manager, requirements analyst, and facilitator with 22 years experience in the software development industry. Her broad experience in the analysis, design, and development of object-oriented, relational, and hierarchical data systems for consumer finance, engineering, and medical functions has enabled her to effectively keep the user foremost when applying requirements management (RM) best practices in real product development situations. Betty is a principal consultant for Borland where she: instructs/mentors on CaliberRM and RM processes and techniques; is certified to teach the Karl Wiegers' course, "In Search of Excellent Requirements"; develops requirement management and change management processes; conducts process gap analysis making recommendations for improvements; and, develops RM implementation strategies and mentors client implementation personnel.

Before joining Borland, Betty was a senior systems consultant for The Associates providing team management for project development/business analysis, a senior data architect for Burlington Northern Railroad providing data analysis/database implementation, and a computer systems specialist for Computer Sciences Corporation (CSC) providing enterprise functional/data analysis. Betty holds a Bachelor of Science degree in Mathematics/Education from Florida State University in Tallahassee, Florida with additional coursework in Computer Science.

betty.luedke@borland.com

Implementing Requirements Management: 

A Pattern For Success

Betty Luedke - Borland Software Corporation


Introduction

Key To Success

Process

People

Technology

The Pattern

Select a 'Steering Committee'

Level Set Concepts/Best Practices and Organization's Situation

Plan Process/Tool Implementation

Prepare the Environment

Conduct a Pilot Effort

Determine 'Next Steps'

Factors

'Right' Steering Committee

'Right' Mindset

'Right' Timing

'Right' Pilot

Organizational Support

The 'Measuring Stick'

The 'Secret'

Summary


Introduction

After guiding multiple Requirements Management (RM) Process/Tool Implementation efforts at a number of medium to large government/commercial organizations, an approach has emerged to successfully implement a RM process with tool support.  As you will see, this approach is sensitive to the environment in which it is used and is based on the experience of what has worked or not worked in specific environments.  Although the pattern for success grew out of implementing a RM process with tool support, the lessons learned here are applicable to the implementation of any system development process (test management, configuration management,...) with tool support.

Key To Success

There are three very important considerations to keep in mind if we want our implementation of a RM process/tool to be successful.  These considerations are PROCESS, PEOPLE and TECHNOLOGY.

Our goal is to be effective and  efficient not only in the RM process/tool we are implementing, but in the way we go about this implementation.  A basic but driving insight is that PROCESS and PEOPLE make an effort effective, and TECHNOLOGY at best can make an effort efficient.   With this in mind, we need to do all three because if we focus on:

  • Just TECHNOLOGY.............we become very efficient about being ineffective!
  • Just PROCESS-PEOPLE.......we become very effective about being inefficient!

Focusing PROCESS, PEOPLE and TECHNOLOGY at the same time is the key to  being effective and efficient!

So, what do we really need to do!

Process

From a PROCESS perspective, we actually have two things going on.  We need to understand:

  1. The RM process we are implementing.
    • It should be noted that many organizations do not have a well-defined, well-grounded RM process.
    • To be successful, at least a minimal, well-grounded RM  process/strategies needs to be part of the implementation effort.
    • The effectiveness of the RM process will affect the efficiency of the tool used to support it.  In other words, the more effective the RM process is the more probable it is that the tool supporting this process will facilitate efficiency.  Conversely, if the RM process is ineffective, then the efficiency of the tool supporting this process will be compromised.
  2. The steps needed to implement the RM process with tool support.
    • If the RM process is new, then there will be training considerations from a PEOPLE perspective.

People

From a PEOPLE perspective, we also have two dynamics.  We need to identify:

  1. The roles in the RM process we are implementing.
    • These system development roles are recognized in the RM process but must be supported in the RM tool (CaliberRM).
  2. The participants in the implementation of the RM process with tool support and the training needed for a successful implementation.
    • The participants guiding this implementation will be the steering committee.  They will need to be trained/mentored on the RM process/tool that is being implemented.  If the RM process is new, it is likely that you will also need to define system development roles and role participation for each task in the RM process.
    • The initial participants in the actual implementation will be the pilot team.  Like the 'steering committee', they will need to be trained/mentored on the RM process/tool that is being implemented. 
    • The subsequent participants in the actual implementation will be the remaining project teams.  Like the 'steering committee' and the pilot team, they will need to be trained/mentored on the RM process/tool that is being implemented. 

This paper focuses on "the participants in the implementation of the RM process with tool support", namely the 'steering committee' and the pilot team.  These participants will need to be trained/mentored on the RM process/tool that is being implemented.  Once again, if the RM process is new, it is likely that you will also need to define system development roles and role participation for each task in the RM process.

Technology

From a TECHNOLOGY perspective,  there are three things on which we must focus.  They are:

  1.  Understanding the functionality of the new tool that will support the RM process we are implementing.
    • The functionality of the new tool needs to be understood so its configuration reflects RM best practices and in turn efficiently supports the RM process. 
    • If the RM process is new and the tool is new, it will be necessary  to define tool procedures for each task in the RM process.
    • The system development roles are identified in the RM process but must be supported in the new RM tool.  In other words, a requirements analyst must be able to capture requirements-related information in the new RM tool, and consumers of requirements, such as designer, developer or tester, must be able to answer their requirements-related questions using the information in the requirements repository.
  2. Understanding the functionality of the existing tool that supports the current RM process.
    • It is important to understand enough about how the existing tool supports the current RM process to be able to facilitate the migration of information residing in the existing tool to the new tool.
  3. Determining the migration of information residing in the existing tool to the new tool.
    • The primary participants in this implementation are the steering committee and the pilot team.  There are many decisions to be made about moving the existing requirements information for its current location to the new repository.  These decisions include:
      • WHAT information needs to be moved?

      • WHERE is this information located?

      • WHAT is the integrity of the current requirements information?

      • WHAT refinement/reorganization will be necessary to match the best practices organization of information in the new requirements repository?

      • WHAT historical information, if any, is needed?

      • WHEN in the life cycle of a particular project will this information be moved?

      • WHAT effect will migrating the requirement information have on the project team if it is not at the beginning of the life cycle?

      • WHO will move the information?

      • WHO will determine if the migration was successful?

      • WHO will refine/reorganize the information if appropriate?

      • WHO from the business will validate that the requirements now in the new repository are correct?

      • WHO will ensure that the new requirements repository will be used as source of record for all requirements?

 

The Pattern

 

This pattern for success has been lifted from the planning, organizing and executing of eight RM process/tool implementations efforts ranging:

FROM

  • Requirements Management/Change Management/Configuration Management/Test Management Processes supported by CaliberRM/StarTeam/TestDirector

TO

  • Requirements Management Process supported by CaliberRM

TO

  • Requirements Management Process only

It was found that the steps we went through in each of these experiences were very similar, but the actions taken and the artifacts produced varied reflecting the needs of the environment and the maturity of the organization. As stated earlier, this pattern for success can be used to implement a number of system development processes, but we will focus on the implementation of the RM process. 

The basic steps below are not to be followed blindly because it is the nuances picked up during planning, implementation and measurement that will lead the team to success: 

  1. Select a steering committee to guide your RM Process/Tool Implementation effort
  2. Level set RM concepts/best practices and organizations situation 
  3. Plan the RM Process/Tool Implementation effort
  4. Prepare the environment
  5. Conduct a pilot effort
  6. Determine next steps

Select a 'Steering Committee'

The 'steering committee' participants should be representative of the roles that author or consume requirements.  They should also:

  • Be global thinkers without hidden agendas
  • Want to collaborate on a better environment in which to build software
  • Be willing to embrace new ways of thinking
  • Be enthusiastic about and willing to find a better way

It is important for this core group to be as small as possible and still be credible and functional.  Three to five participants is ideal.  Cast of thousands does not work very well unless managed by selecting a core group from the cast.  Success here is all about the recommendations being perceived as credible because the participants are trusted.

Level Set RM Concepts/Best Practices and Organization's Situation

Work with the steering committee to:

  1. Promote a consistent understanding of RM concepts and best practices. 
    • This can be done through training, but most often it is an abbreviated presentation (2-3 hours) of the major  RM concepts.  You must at least minimally train the steering committee on RM concepts, best practices and basic tool functionality if this group is to effectively guide this RM process and tool implementation.
  2. Understand the organizations current situation (processes, projects, challenges, goals,..). 
    • This sharing time (2-3 hours) consists of identifying items that need review and crystallizing a feel for the environment.  It is important that the RM concepts be understood first because they will act as a backdrop for the discussion around the organizations situation.
  3. Understand/validate the next steps for planning the RM process/tool implementation, preparing the environment and conducting a pilot.
    • Even though the pattern for success puts forth the steps for the RM process/tool implementation, these steps must be owned by the steering committee.  In other words, the steering committee must make these actions their own by adjusting the steps where their environment dictates.
    • State RM concepts/best practices (CouldBe) first before focusing on the organization's current situation (AsIs) because concepts/best practices need to be the context within which the current situation is seen.  This helps set up a logical next step of what we need to do (WillBe).
  4. Recognize who can be heard.
    • In any culture change (which implementing a RM process usually is), there are voices that can be heard and ones that can not.  It may be that management will be listened to or that a credible developer will be listened to or the outside voice of a consultant will be listened to.  We also need to consider from whom a particular message should come.  A 'goal' message should come from those in charge, where a how to should come from someone credible in the development community.

Plan Process/Tool Implementation

Work with the steering committee to:

  1. Articulate RM Process/Tool Implementation Success Criteria/Measurement. 

    • The RM Process/Tool Implementation Success Criteria and Measurement below is an example of what it might mean to be successful.  Going through this exercise with the 'steering committee' is a way to reach a common understanding of what success means.  Simply fill in the blanks (indicated by the column headings):

      • This process/tool implementations will be deemed a success if __________________.

      • This criterion has been met if _________________.

 

 

 

SAMPLE RM Process/Tool Implementation Success Criteria/Measurement

 

 

  1. Develop a RM Process/Tool Implementation Plan

Develop a RM Process/Tool Implementation Plan tasks and responsibilities.  Review this plan for alignment with the Success Criteria/Measurement and from the PROCESS, PEOPLE and TECHNOLOGY perspectives to ensure completeness.  The Process/Tool Implementation Plan tasks below are not intended to be a complete list of tasks, but rather an example of tasks that will probably be necessary from the PROCESS, PEOPLE or TECHNOLOGY perspectives.  This sample can be used to identify tasks prior to putting theses tasks into a project management tool, such as MSProject.  Think of this as a worksheet for creating a project plan.  You may find duplicate tasks identified because a task is needed to provide coverage from multiple perspectives.

SAMPLE Tasks for Process/Tool Implementation Plan

PROCESS- PEOPLE-TECHNOLOGY


 

Prepare the Environment

Work with the steering committee to stabilize the environment by determining and defining such items as:

PROCESS
  • Requirement type strategy
  • Requirement trace strategy
  • Requirement baseline strategy
  • Requirement management process (tasks/steps)
  • Change control process
  • Requirements information structure
  • Requirement documentation guidance

 

PEOPLE

  • System development roles
  • RM techniques
  • Requirement review guidance

 

PROCESS-PEOPLE

  • RM task-role participation matrix

 

TECHNOLOGY

  • CaliberRM installation/configuration
  • CaliberRM backup/disaster recovery procedures
  • CaliberRM project 'container' export
  • CaliberRM Document Factory templates
  • Requirement migration approaches for existing requirements

 

PROCESS-PEOPLE-TECHNOLOGY

  • CaliberRM tool procedures for each task/step in the RM process
  • CaliberRM project startup guidance
  • RM process/tool mentors

Conduct Pilot Effort

Work with the steering committee to:

  1. Identify an appropriate pilot and/or identify risks associated with using a particular project as a pilot by:
    • Defining/refining pilot selection criteria:
      • To use the pilot selection criteria, adjust the Values and Ideal Project as needed before rating Project A or B.
      • Add your own questions providing Values and Ideal Project information.
      • You will notice that Questions 16 and 17 explore whether or not the project manager/requirements analyst is 'credible' or not.  This does not have anything to do with how knowledgeable or skilled the project manager/requirements analyst is, but it has everything to do with whether or not this person's voice can be heard.  For instance, if the project chosen has a project manager/requirements analyst that is new to the organization, then the assessment of the success/failure of the RM process/tool implementation effort may be suspect by others in the organization because this person is not really known and they are unsure how 'credible' the assessment really is. 
    • Selecting appropriate pilot(s) using the pilot selection criteria below noting that some variances from the Ideal Project may be acceptable and may even be without risk.

 

SAMPLE Pilot Selection Criteria

#

Question

Values

Ideal Project

Project Example

Project A

Project B

1

Has project manager/requirements analyst had exposure/training in RM concepts/tool?

Yes

No

Yes

Yes

2

Has project team had exposure/training in RM concepts/tool?

Yes

Some

No

Yes

Some

3

Is project manager/requirements analyst well-grounded in RM concepts?

Yes

Partially

No

Yes

 

Partially

 

 

4

What is the projects corporate visibility?

High

Medium

Low

Medium

Low

 

 

5

Is the project on a corporate critical path?

Yes

No

No

No

6

Is this a significant project?  (high cost)

Yes

No

No

No

7

What is the value of the product to the company?

High

Medium

Low

Medium

Medium

8

What is the project risk (resource, time, budget)?

High

Medium

Low

Low

Low

9

What level of pressure is this project experiencing?

High

Medium

Low

Low

Low

 

 

10

Where in the development life cycle is the project?

Plan Project

Gather requirements

Design application

Develop application

Test application

Deploy application

Plan Project

Plan Project

 

 

11

Is this project developing a new product or enhancing an existing product or integrating existing functionality?

New development

Enhancement

Integration

New development

New Development

Enhancement

 

 

12

How complex is the project development?

High

Medium

Low

Low

Low

13

How complex is the project team situation (location, experience, leadership,)?

High

Medium

Low

Low

High

14

Is the product being developed in phases?

Yes

No

No

Yes

15

What are the expectations coming into RM Process/Tool implementation?

(Describe)

Process change

Improvement after learning curve

Process change

Improvement after learning curve

16

Is project manager credible?

Yes

No

Uncertain

Yes

Yes

 

 

17

Is requirements analyst credible?

Yes

No

Uncertain

Yes

Yes

18

What is the attitude of the project manager/requirements analyst?

Going to make it happen

Willing

Cautious

Reluctant

Have to do

Going to make it happen

 

Going to make it happen

 

 

19

What is the attitude of the project team?

Going to make it happen

Willing

Cautious

Reluctant

Have to do

Going to make it happen

 

Cautious

 

 

20

Is requirements analyst available?

Yes

No

Yes

Yes

21

Does project have CaliberRM licenses?

Yes

No

Yes

Yes

 
  1. Have management talk with the pilot team about goals and expectations.
  2. Train pilot team(s) in RM concepts/process/tools.
  3. Migrate existing requirements, if appropriate.
  4. Mentor pilot team(s) in RM concepts/process/tools.
  5. Monitor pilot teams progress (early and often) making necessary adjustments based on lessons learned.
  6. Assess the success of pilot effort using the established success criteria/measurement.

Determine 'Next Steps'

Work with the steering committee to:

  1. Determine where improvements are needed.
    • You should expect, even with a well thought through implementation plan, that there will be areas in the RM process, techniques, tool configuration/integration, tool procedures, ...  that will need to mature beyond their initial implementation.
    • Mentally plan for these improvements because this will set the stage for continuous improvement.
  2. Determine rollout strategy and plan.
    • Keep in mind that your rollout strategy and plan should consider the following in addition to training and mentoring:
      • The phase of the lifecycle a project is in
      • The existing requirements needing to be migrated to the new requirements repository
      • Number of licenses needed
      • Administrative support required.
    • Also, build into your rollout strategy and plan time for:
      • Lessons learned
      • Feedback on needed improvements
      • Accomplishing agreed upon improvements

Factors

For this or any approach for implementing a RM process/tool to succeed, it is important that:

  • The RM process/tool implementation effort be undertaken with the 'right' guidance at the 'right' time using the 'right' pilot team.
  • There is organization support.
  • A 'measuring stick' is identified and the implementation effort is monitored and improved.
  • You have the 'secret' to pulling off an effort such as this.

 

'Right' Steering Committee

The steering committee must be made up of the right participants.  If the steering committee, individually and collectively, do not embrace this implementation effort, the results will be flawed, success will take longer or, worse case, the effort will fail.  Attitude is very important, and credibility is critical.  These participants can and should be your evangelists and explorers.

 

'Right' Mindset

The mindset  must be right from the RM concepts perspective.  Historically, requirements have been written in a document and quality has been measured by the weight of the document.  This mindset will not get us where we need to be.  It is a step forward to see each requirement (usually one sentence) as a discrete and categorized item, such as might be represented in a spreadsheet.  However, it is not until each requirement is discrete, categorized and predictably related to other requirements (and other system development artifacts, such as tests, design,...) that true RM best practices can be realized.

 

'Right' Timing

The timing must be right.  If the participants (management included) are not feeling much PAIN, there will be little incentive to think about things differently, alter procedures or go through the learning curve.  Timing is everything!  Don't give up if a perfectly good RM process does not stick the first time.  Success requires the 'right' message, the 'right' messenger and willing participants.  Don't beat yourself up, but do consider timing as an important factor in success.

 

'Right' Pilot

The right pilot must be selected.  If the pilot selected is on the organizations critical path where there is a lot at stake ($$, time to market,...), pressure will probably preclude having adequate time to reflect on lessons learned, make improvements or reap the full benefits after  the learning curve.  However, if a high profile project is identified as a pilot, every effort should be made to mitigate the risks identified by the project selection criteria.  Pick the 'right' pilot by selecting a project that is not on critical path, but important enough to be credible.  The pilot selection criteria will help you make a wise choice and identify any risks.  The care and nurturing of a pilot team that is embarking into uncharted waters is essential.  To this end, monitoring and mentoring are both a 'must'.

 

Organizational Support

An organization is made up of management, project teams and individuals.  Support is needed from the top and the bottom.  It does not work very well if you have a dictator with unwilling troops or, vice versa, if you have savvy troops and an unenlightened leader.  Management needs to support the RM process/tool implementation effort by providing direction, funding, staffing,...  The project teams need to want a 'better way' and be willing to creatively work toward that goal and the individual needs to be willing to move from a place of comfort.  You need 'champions' at the top and 'evangelists' and 'explorers' among the troops.  Lip service is loud, but actions/behavior are the telltale indicators as to whether or not the manager, the project team or the individual has truly 'signed on'! 

 

The 'Measuring Stick'

To really be successful the RM process/tool implementation effort must be recognized as a major step toward maturing and improving your organizations system development process.  It is not enough to feel the PAIN and just try something different.  It is not enough to identify success criteria and never look at them again.  It is not enough to buy a tool and experiment with it.  It is, however, recognizing some of the root causes of PAIN in your organization and proactively bringing PROCESS, PEOPLE and TECHNOLOGY to bear that will make a difference!  So, if we do exactly that--put PROCESS, PEOPLE and TECHNOLOGY in place--should we not ask, "How are we doing?"

Of course, the RM Process/Tool Implementation Success Criteria and Measurement facilitate measuring the success of a particular effort based on expectations.  But if we are really trying to see how mature our organization is in developing and managing requirements, we might look to the Capability Maturity Model (CMM).  The CMM is just one of a number of 'measuring sticks' that could be used to determine organizational progress.  The CMM clearly places the development and management of requirements as key in attaining Level 2 - REPEATABLE and Level 3 - DEFINED.  Below highlights those areas of the CMM which specifically speak to requirements:

Level 2 - REPEATABLE

Key Process Area - Requirements Management

  • Goals
    • System requirements allocated to software are controlled to establish a baseline for software engineering and management use.
    • Software plans and products and activities are kept consistent with system requirements allocated to software.
  • Practices
    • The software engineering group reviews the allocated requirements before the are incorporated into the software project.
    • The software engineering group uses the allocated requirements as the basis for software plans, work products and activities.
    • Changes to the allocated requirements are reviewed and incorporated into the software project.

Level 3 - DEFINED

Key Process Area - Software Product Engineering

  • Goals
    • The software engineering tasks are defined, integrated and consistently performed to produce software.
    • Software work products are kept consistent with each other.
  • Practices
    • ...
    • The software requirements are developed, maintained, documented and verified by systematically analyzing the allocated requirements according to the project's defined software process.
      • The individuals involved in developing the software requirements review the allocated requirements to ensure that issues affecting the software requirements analysis are identified and resolved.
      • Effective methods for requirements analysis are used to identify and derive the software requirements.
      • The software requirements are analyzed to ensure that they are feasible and appropriate to implement in software, clearly stated, consistent with each other, testable and complete (when considered as a set).
      • The software requirements are documented.
      • The group responsible for system and acceptance testing of the software analyzes each software requirement to verify it can be tested.
      • The methods of verifying and validating that each software requirement is satisfied are identified and documented.
      • The software requirements document undergoes peer review before it is considered complete.
      • The software requirements document is reviewed and approved.
      • The software requirements document is reviewed with the customer and end users, as appropriate.
      • The software requirements document is placed under configuration management.
      • The software requirements are appropriately changed when the allocated requirements change.
    • ...
As the CMM appropriately points out, building maturity is more than following a set of practices.  Maturity includes the commitment to perform as well as the ability to perform at both the organizational and individual level.

 

The 'Secret'

All involved (management, steering committee, pilot team,...) must understand what it takes to pull off this type of effort and not become overwhelmed by it. 

Here is the secret

Know the RM process, the roles and techniques needed to perform each RM task, the requirement information structure needed to capture useful information, and how to configure/use a tool to support this endeavor. 

It is PEOPLE, PROCESS and TECHNOLOGY working together that make success happen!

 

Summary

In summary, the pattern for success for implementing a RM process with tool support was born out of multiple experiences where a RM process with or without tool support was effectively implemented.  However for you to be successful, you must make this path your own by:

  • Recognizing the importance of PROCESS-PEOPLE-TECHNOLOGY in making your effort effective and efficient.  It is not an 'either/or'; it is an 'and' when it come to PROCESS-PEOPLE-TECHNOLOGY and success.
  • Knowing the pattern for success:
    • Select a steering committee to guide your RM Process/Tool Implementation effort
    • Level set RM concepts/best practices and organizations situation 
    • Plan the RM Process/Tool Implementation effort
    • Prepare the environment
    • Conduct a pilot effort
    • Determine next steps

  • Taking action by executing the pattern for success with:

    • 'Right' steering committee

    • 'Right' mindset

    • 'Right' timing

    • 'Right' pilot team

    prepared with

    • RM best practices

    • RM tool that can support RM best practices (CaliberRM)

    armed with

    • Organizational support

    • A 'measuring stick'

    • The 'secret'

  • Listening along the way and adjust as appropriate.

  • NEVER GIVING UP!


  Latest Comments  View All Add New RSS ATOM

Move mouse over comment to see the full text

Server Response from: ETNASC04