Project Requirements: A Guide to Best Practices

By Ralph R. Young

Project Requirements: A Guide to Best Practices gives project managers tools they can assimilate and apply easily to improve project success rates, reduce development costs, reduce rework, and accelerate time to market. Based on experience and best practices, this valuable reference will help you:
• Clarify real requirements before you initiate project work
• Improve management of project requirements
• Save time and effort
• Manage to your schedule
• Improve the quality of deliverables
• Increase customer satisfaction and drive repeat business
Project Requirements: A Guide to Best Practices provides project managers with a direct, practical strategy to overcome requirements challenges and manage requirements successfully.

• Language: English
• Publisher: Berrett-Koehler Publishers, Inc.
• Release date: Mar 1, 2006
• ISBN: 9781523096282

Ralph R. Young

Ralph R. Young, DBA, is an active leader and contributor in systems, software, and process engineering. Dr. Young is the director of Engineering Process Improvement, Systems and Process Engineering, Defense Group at Northrop Grumman Information Technology, a leading provider of systems-based solutions. He supports internal and external projects to improve their capabilities to use process improvement techniques, implement effective requirements practices, and develop innovations to facilitate project management. Dr. Young is a graduate of the University of New Hampshire and earned a Master of Arts in economics and a Doctorate in Business Administration at The George Washington University. He is the author of Effective Requirements Practices (Addison-Wesley, 2001) and The Requirements Engineering Handbook (Artech House, 2004).

Book preview

Project

Requirements

A Guide to Best Practices

Project

Requirements

A Guide to Best Practices

Ralph R. Young

8230 Leesburg Pike, Suite 800

Vienna, VA 22182

[phone]

Fax: [phone]

www.managementconcepts.com

Copyright © 2006 by Management Concepts, Inc.

All rights reserved. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by an information storage and retrieval system, without permission in writing from the publisher, except for brief quotations in review articles.

Printed in the United States of America.

Library of Congress Cataloging-in-Publication Data

Young, Ralph Rowland

Project requirements : a guide to best practices / Ralph R. Young. p. cm.

Includes bibliographical references and index.

ISBN 1-56726-169-8

1. Project management. I. Title.

HD69.P75Y66 2006

658.4’04—dc22

2005056174

About the Author

Ralph R. Young, DBA, is an active leader and contributor in systems, software, and process engineering. His primary interest is to bring a sound working knowledge of best practices to a wide professional and academic community.

Dr. Young is the director of Engineering Process Improvement, Systems and Process Engineering, Defense Group, at Northrop Grumman Information Technology, a leading provider of systems-based solutions. He helped lead his former business unit (Litton PRC) to CMM® level 5 and his current business unit to CMMI® level 5. The Defense Group was the first organization in the world to be evaluated a second time at CMMI® level 5. Dr. Young supports internal and external projects to improve their capabilities to use process improvement techniques, implement effective requirements practices, and develop innovations to facilitate project management. He leads a requirements working group that involves more than 50 requirements engineers from projects in his business unit.

Dr. Young is a graduate of the University of New Hampshire and earned a Master of Arts in economics and a Doctorate in Business Administration at The George Washington University. He is the author of Effective Requirements Practices (Addison-Wesley, 2001) and The Requirements Engineering Handbook (Artech House, 2004).

When

you are inspired

by some great purpose,

some extraordinary project,

all your thoughts break their bounds.

Your mind transcends limitations, your

consciousness expands in every direction, and

you find yourself in a new, great, and wonderful world.

The Yoga Sutras

of

Patanjali

Let’s go! Let’s go! Let’s go!

John 11:7; 11:14; 11:16

Table of Contents

Foreword

Encouragement from a Fellow PM

Preface

Acknowledgments

CHAPTER 1.   Introduction

How the PM Will Benefit By Paying Attention to Requirements

What Are Requirements and Why Are They Important?

Why Pay Attention to Requirements?

Why This Book?

Requirements Activities in the Project Life Cycle

Requirements-Shaping PM Practices

Setting Expectations Concerning the Requirements

Goals of This Book

The Impact of Requirements on Project Success—A Project Management Professional’s Perspective

Identifying Project Stakeholders

Standardized Terminology and Processes

CHAPTER 2.   Key Requirements Success Factors

Criteria for a Good Requirement

Types of Requirements

Need for High-Level Requirements

Key Success Factors

Engage all Project Roles in the Requirements Process

Write a Project Vision and Scope Document

Identify a Set of High-Level Requirements

Use Trained and Experienced Requirements Analysts

Evolve the Real Requirements

Use Mechanisms to Manage Changes to Requirements and New Requirements

Develop and Use a Requirements Plan

Document and Invest in the Project’s Requirements Process

Take Proactive Steps to Address the Most Frequent Types of Requirements Errors

Understand the Real Requirements before Initiating Other Technical Work

Involve the Project’s Customers and Users

Plan for Change

The Experience of Being a User in a Requirements Process

CHAPTER 3.   Partnering for Success

Costs and Benefits of Partnering

Securing the Commitment of Stakeholders

The Partnering Process

The Decision to Partner

Evolving Mutual Expectations

Initial Partnering Workshop

Mutual Support in Ongoing Project Efforts

Sample Partnering Charter

CHAPTER 4.   Requirements-Related Project Startup Issues

Typical Requirements-Related Project Startup Issues

Confusion Reigns

Project Requirements Are Not Clear

A Set of High-Level Requirements Is Not Identified

All Requirements Are Considered Equal

The Team Is under Pressure to Start the Real Work

Requirements Are Not Clarified before Other Technical Work Is Initiated

All Stakeholders Are Not Identified

Effective Communication among Project Participants Is Lacking

Customer Places Too Much Burden for Defining Requirements on the Developers

Users Believe the New System Will Address All Their Perceived Needs

Requirements Process Is Not Documented

Project Staff Are Asked to Use Automated Tools without Training

Suggested Remedies for Typical Requirements-Related Project Startup Issues

Identify a Champion for the Project Requirements Process

Hire and Train Experienced Requirements Analysts

Write a Project Vision and Scope Document

Form and Use a Joint Team

Provide an Initial Project Requirements Briefing

Design, Document, and Use the Project’s Requirements Process

Identify the Real Requirements

Provide Ongoing Training for the Requirements Analysts

Select, Deploy, Implement, and Use Industry-Proven Effective Requirements Practices

Engage All Project Staff in the Requirements Process

Create a Project Configuration Control Board

Undertake Team Building among the Project Staff

Take Steps to Make Effective Use of an Automated Requirements Tool

Requirements-Related Startup Checklist

CHAPTER 5.   Fostering Effective Teamwork

The Need for Effective Teamwork Concerning Requirements Tasks

Fostering Effective Teamwork

Customer and User Involvement in Requirements Activities

The Joint Team

Identifying the Real Requirements

Controlling New Requirements and Changes to Requirements

Using a Requirements Working Group

Addressing Verification and Validation during Requirements Development

CHAPTER 6.   Coaching the Project’s Requirements Manager and Requirements Analyst

The PM as Coach

Coaching Opportunities to Support the Roles of the RA

ROLE 1: Work Collaboratively to Identify the Real Requirements

ROLE 2: Work Effectively with Customers and Users to Manage New and Changed Requirements

ROLE 3: Be Alert to New Technologies

ROLE 4: Facilitate the Project in Reusing Artifacts and Achieving Repeatability

ROLE 5: Assist in Envisioning a Growth Path to the Ultimate System

ROLE 6: Advise the Project on Methods, Techniques, and Automated tools Available to Support Requirements-Related Work

ROLE 7: Use Metrics to Measure, Track, and Control Requirements-Related Project Work

ROLE 8: Facilitate Discussions and Mediate Conflicts

ROLE 9: Study the Domain of the Area in Which the System Is Used

Be Willing to Be Coached!

CHAPTER 7.   Clear Communication: The Key to Project Success

How Communication Affects Requirements Activities

Foster and Encourage Open Communication

Empower Your Team Members

Recognize the Efforts of Your Team Members

Convene a Project CCB

Hold Effective Meetings

Establish Rules of Conduct

Ensure Mutual Accountability

Advocate for Effective Use of E-mail

CHAPTER 8.   Being Agile: The Right Amount of Discipline and Process

Why Processes Help

What Discipline Is Needed?

Where to Start

What Amount of Process Should Be Provided on a Project?

An Example of an Agile Requirements Process from a Real Project

CHAPTER 9.   Continuous Improvement

What Is Continuous Improvement?

Why Pursue Continuous Improvement?

Establishing an Environment of Continuous Improvement

Identify the Business Objectives and Communicate Why They Are Important

Set Goals and Milestones for the Project Based on Stakeholder Needs and Expectations

Emphasize That Every Member of the Project Team Is Valued

Welcome Opportunities for Improvement

Create an Environment of Constructive Information Sharing

Provide Practical Mechanisms for Identifying and Addressing Barriers

Take Time to Assess Results

Respond to Suggestions Made by the Project Team

CHAPTER 10. The Project Manager’s Role Concerning Quality

Setting Quality Goals

The QA Role on a Project

ROLE 1: Become One of the Sources of Process Knowledge

ROLE 2: Develop and Maintain an Environment of Continuous Improvement

ROLE 3: Don’t Audit; Instead, Teach and Coach

Maintaining a Quality Culture on a Project

Using Quality Improvement Tools and Techniques

CHAPTER 11. Requirements, Risk, and the Project Manager

Why Use Risk Management?

Risk Management Planning

Risk Identification

Brainstorming

Taxonomy-based Questionnaire

Lessons Learned Analysis

Risk Assessment

Risk Response Planning

Risk Monitoring and Control

CHAPTER 12. Summary and Suggested Implementation Steps

Suggested Implementation Steps

Summary of Requirements-related Mechanisms

Summary of Other Key Concepts

Fostering Senior Management Commitment

Epilogue

APPENDIX A: Traceability by James D. Palmer

APPENDIX B: Meet Minimum Requirements: Anything More Is Too Much by Neal Whitten

APPENDIX C: Template for a Project Vision and Scope Document

References and Resources for Additional Help

Index

Figures

1-1.     What Drives Requirements?

2-1.     High-Level Requirements Process

2-2.     Involving Customers and Users in Your Project

3-1.     The Partnering Process

3-2.     Sample Issue Resolution Ladder

4-1.     Suggested Remedies for Overcoming Requirements-Related Project Startup Issues

4-2.     Value of Investing in a Requirements Process

5-1.     Sample Requirements Working Group Charter

9-1.     One Characterization of a Positive Project Environment

11-1.   Risk Management Process

11-2.   Probability and Impact Matrix

11-3.   Responding to Risk

11-4.   Typical Risk Response Strategies

Tables

1-1.     Requirements Work Products

2-1.     General Types of Requirements

2-2.     Requirements-Related Roles and Responsibilities

4-1.     Requirements Analyst Skills Matrix

4-2.     Impact of Finding and Fixing a Requirements Defect in Subsequent Project Phases

4-3.     Requirements-Related Project Startup Checklist

6-1.     Recommended Requirements-Related Metrics

7-1.     Communications Aids on a Project

8-1.     Home Grounds for the Agile and Disciplined Approaches

9-1.     Alternative Life Cycle Approaches

10-1.   Plan to Close Gaps between Current Practices and Contract Requirements

10-2.   Factors That Influence the Quality Needs of a Project

10-3.   Quality Standards for Delivered Plans and Reports

10-4.   Sample Comparison of Project Practices to Company Standard

10-5.   Design Plan Process QA Checklist

10-6.   Suggested Interview Discussion

10-7.   Design Plan Process QA Compliance Checklist

10-8.   Postmortem Data Collection and Analysis Elements

11-1.   Likelihood of Risk Occurrence

11-2.   Sample Qualitative Assessment Process

11-3.   Prioritizing Risks

11-4.   Typical Risk Response Strategies

12-1.   Requirements-Related Mechanisms

Foreword

All roads in project management point to one intersection: the requirements roundabout. The successful project manager is able to build the roadmap leading to the intersection, successfully navigate through the options, and find the correct turns to successfully reach the planned destination. Unfortunately, many project managers have great difficulty preparing a plan that accurately builds all the project requirements necessary to negotiate the twists and turns to reach their goal of project success.

One of my favorite quotes comes from John Preston of Boston University:

The nicest thing about not planning is that failure comes as a complete surprise and is not preceded by a period of anxiety.

John’s statement speaks volumes concerning the value of taking time to determine all the requirements necessary for successful project delivery. Requirements come in many forms—business requirements, technical requirements, technical specifications, and project requirements. Project requirements encompass all nine of the Project Management Institute’s Project Management Body of Knowledge areas (time, cost, resources, scope, quality, communication, human resources, risk, and integration). Developing acceptable requirements takes a certain amount of skill. The ability to develop good requirements improves with experience. To build outstanding project requirements that weather the test of changing project scope and changing customer needs and deliver a successful project is an art form. Understanding and managing each of these requirements areas is critical to ultimate project success.

I have observed or participated in many projects in my career. Some were successful; others were challenged or failed. Successful projects all share a common theme: expectations were clear on what was to be produced, when it was expected to be complete, and what it would take to be delivered. Failed projects were clear on the schedule and cost expectations, but artifacts of failed projects seldom reflected concise descriptions of the specifics of what was being built. In short, failed projects lacked clear requirements.

Failed projects are a tremendous cost to organizations. One study noted that fifty-six percent of organizations admit they have failed IT projects in the past 12 months . . . . The average loss incurred by the businesses surveyed was US$13 million per project with the largest single project failure costing US$218 million.¹

Companies cannot afford this level of loss to the bottom line. Best practices companies have begun to provide written guidance within their organizations on development and communication of effective project requirements during the project initiation phase. These companies appropriately manage the scope and changes to those requirements during project execution. As a result, corporations are reaping positive benefits from more effective project delivery than ever before.

In this book, Dr. Young shows how project success is connected to how effectively requirements are developed and managed.

Chapters 1 and 2 are wonderful primers on requirements development and requirements management. Some great practical applications and tips come to you in Chapters 3 through 9. The remaining chapters do an outstanding job discussing organizational evolution and the project manager’s involvement in balancing requirements, risk, and quality.

I encourage you to absorb the content of this book, apply it to your organization, and discover the tremendous returns from exercising Ralph Young’s best practices in project requirements. Every project manager should understand these concepts.

J. Kent Crawford, PMP, PMI® Fellow

CEO, Project Management Solutions, Inc.

¹IT Project Failure is Rampant, The Register, November 26, 2002.

Encouragement from a Fellow PM

Requirements are hard. They are hard to define, they are hard to fulfill, and they are hard to keep current. This is true whether you are designing software or designing a training program.

All project and program managers (PMs) know that requirements are hard and that they are the basis for everything done on the program. Managers know this and usually believe that they have identified the correct requirements at the start of a project. However, providing the right focus on requirements development and management throughout a program takes a real effort. There is always a momentum for acting quickly, and it is very easy to give requirements short shrift. Many times managers think about requirements only in passing, until a critical event occurs to jolt them back to requirements reality. By that time the project is usually in trouble, either minor or major.

In a long-term program, revising requirements periodically is advisable. One thing that managers of long-term programs sometimes forget is that requirements change! I manage a program that provides a system for storing engineering drawings. It is a mature program now. When we were in the early development phases we had a requirement to develop a process for automated bidsets. The client’s need was to prepare a package of engineering drawings to be sent out to potential bidders to provide parts or services. When we started our data collection, we found that it was not unusual for our client to take two full weeks to prepare a bidset, because they had to collect different drawings from different locations, assemble them, ensure that they were the correct drawings, and so forth. Our stated requirement was to decrease that time frame.

As development and deployment progressed, it was wonderful for clients to be able to collect all the drawings online, assemble the bidset, and send it out. Two baselines later, we began to hear that it was unacceptable to wait several minutes for the computer to fetch the drawings! The requirement had changed from two weeks to less than five minutes!

Because of these changing requirements, PMs must remain ever vigilant to identifying and changing dynamically their requirements as necessary. It is no good waiting until the project is completed only to learn that it didn’t answer the mail.

Ralph Young’s book Project Requirements: A Guide to Best Practices is a significant addition to the manager’s tool kit. It puts the onus for requirements squarely where it belongs—with the PM. It is a good primer for new managers responsible for development of software and other related products. It is especially good as a reprise for seasoned managers. We all know that managing by requirements is what we are supposed to do, but it is so easy to let program momentum allow a slip here and a shortcut there undermine the best-laid requirements plans. My project has been CMMI® level 5 for a number of years, and it still is a struggle to keep the program, the engineers, and the clients on the right requirements track. Luckily, we now have a guide geared directly to PMs. Personally, I plan to refer to it frequently!

Kathy Altizer, PM

Northrop Grumman Corporation

McLean, Virginia

Preface

This book is written for the project manager (PM). Its objective is to facilitate the efforts of PMs to focus greater attention on determining the requirements for the things they build and do. Specifically, the goal of this book is to increase the effectiveness of individual PMs and to improve the management of technical projects.

Does this goal sound lofty and unachievable? It’s not really, in my opinion. Improvement will not be difficult if we tend to business. The Standish Group (2000) continues to report that 28 percent of projects will fail outright and 46 percent will finish challenged—late, over budget, or with reduced functionality—and that issues including user involvement, an experienced PM, firm requirements, and proper planning (all focuses of this book) are major factors contributing to these statistics.

In my judgment, the root causes of such issues and problems are that we don’t do what we need to do (even though we may often know what that is). For instance, requirements analysts must build their skills, enabling them to do their job effectively, not just push ahead without the needed qualifications for their work. PMs must demand and facilitate good requirements analysis, not just tolerate whatever they get.

Why don’t we use better practices? This is what I address in this book. I am convinced that you can be more effective, based on my 35 years of experience involving many kinds of projects (and many PMs). I believe that you will find ideas, strategies, methods, tools, and more in this book. The key is that you must select a few and take action on them. Not all, or even most of them—just a few will help make a huge difference.

I know that you are busy. I know that your days fly by, that you work many extra hours, that you have little use for advice that is not practical and useful, that you have many demands on your time, and that people—including staff, customers, bosses, vendors, and marketing representatives—are constantly at your door with needs that require your involvement and attention.

You are the key to the needed approach, because you are a leader and because you control the resources on the project—how the money is spent, who is hired to do the work, and whether people are empowered to contribute their best efforts (or whether they are inclined, for whatever reasons, just to put in their time with reduced expectations and motivation).

I encourage you to spend some time with this book and to try a few of the ideas that seem to make the most sense to you. I hope that you enjoy this book and that you are able to