Determining Project Requirements

Mastering the BABOK and the CBAP Exam

Hans Jonasson

• Publisher: Auerbach Publications
• Year: 2016
• Print ISBN: 9781439896518
• eBook ISBN: 9781498760027
• Topic: Business
• Subtopic: Project Management
• Index: Business

Good requirements do not come from a tool, or from a customer interview. They come from a repeatable set of processes that take a project from the early idea stage through to the creation of an agreed-upon project and product scope between the customer and the developer.From enterprise analysis and planning requirements gathering to documentation,

Chapter 1

Introduction

If you don’t know where you’re going, chances are you will end up somewhere else.

— Yogi Berra

In the last ten years I have taught project management and requirements gathering to over 10,000 people worldwide. In most of those classes there has been discussion about why projects, especially IT projects, fail. Inevitably the number one reason comes back to unclear or changing requirements. When organizations try to address these problems, they often try for quick fixes such as buying new tools or hiring a consultant. However, it takes more than that. Good requirements do not come from a tool, or from a customer interview. They come from a repeatable set of processes that take the project from the early idea stage through to the creation of an agreed-upon project and product scope between the customer and the developer. This repeatable set of processes, and the tools and techniques that help to execute them, are what I want to address in this book.

This chapter sets the stage for the rest of the book by getting you familiar with the format, the writing style, and the purpose of the book. Each chapter has a similar structure and format that are used throughout the book. The content is based on certain choices in regard to what standards to use and what techniques to include. These choices were made by me and are explained in this chapter through a review of the history of systems development and the evolution of today’s standards. One of the primarily goals in this chapter is to let you know how the book is organized, what it covers, and what is expected of you afterward. This is very much in line with what is recommended when creating a good requirements document.

1.1 Objectives

• Explain the purpose of the book.
• Introduce how to use the book.
• Review the target audience of the book.
• Introduce the professional domain of business analysis.
• Review the evolution of business analysis over the last few decades.
• Review the standard-setting forces in the industry today.
• Introduce the project that will be used throughout the book as an example.

1.2 Overview

This book is designed to be used for multiple purposes:

1. As a reference book. Any person involved with gathering requirements can use this book to discover best practices and learn useful techniques, as well as tools and templates, to improve the requirements gathering processes within his or her organization.
2. For self–improvement. A business analyst needing more guidance on requirements gathering techniques, or one who is preparing for any certifications in business analysis, can use this book as a study guide. The book contains exercises and sample solutions to demonstrate how to deal with different situations that may be encountered in the requirements gathering process.
3. As a study guide for the CBAP^® (Certified Business Analysis Professional^™) exam, which will be expanded upon later. The text of the book will greatly help in preparing for the exam. Additionally, this book includes 300 sample questions to help you prepare for the exam.
4. As a course book. Study groups, as well as participants in internal corporate training and consultative training can use this book as a textbook, as it includes built-in exercises, best practices, tools, and templates. Because it also contains comprehensive solutions to the activities, a warning is warranted. The solutions presented are “a solution,” not “the solution.” Because there are no real customers being interviewed, there will be assumptions made, so there is likely to be some difference in the book solution versus your solution.
5. To provide templates. Two different examples of a business requirements document have been included in Appendix B of this book. The first is a comprehensive template, provided courtesy of ESI International, the second a simpler template, suitable for smaller projects. Review them, customize them, and introduce them into your organization.

This book is not intended as a tool book nor does it advocate any special methodology or technique. Its purpose is to give a broad overview of a multitude of business analysis issues and to provide enough information about tools and techniques to enable the reader to select the best approach for different types of projects. It is a generalist book, not a specialist one. For the key areas where an organization may invest a significant amount of time and effort, more comprehensive training should be considered.

To evaluate the current state of the industry and gather pertinent information on the challenges facing the business analysts of today, I conducted a study with a group of business analysts and project participants who had previously attended my training seminars. While not a large or comprehensive study, it served its purpose well by exploring the role of the business analyst in different organizations, the difficulties in capturing requirements, as well as information about the tools used by practitioners to assist in the analysis process. This study is referenced and discussed throughout the book.

One of the questions asked on the survey was “What are the main difficulties with gathering and documenting requirements?” The top five responses were

1. Lack of time or availability on the part of the customer
2. Lack of customer knowledge
3. Lack of buy-in to scope
4. Lack of skilled business analysts
5. No repeatable process from which to learn

These problems, and others, are explored throughout the book. However, at a high level, it is striking that the first three areas all deal with customer issues. Is that because most people responding to the survey were developers, and it is easier to blame the customer? Or is it because customers truly have challenges in the areas of communication and perhaps in their understanding of what the business really needs? It’s likely a bit of both. Either way, it clearly shows the importance of the customer’s role and competency in requirements gathering.

1.3 Early Days

In the early days of computer systems most applications were geared toward solving a specific problem. The customer was often personally known by the developer and had a relatively clear understanding of what was wanted, and the biggest constraint was typically the capabilities of the computers themselves. Hardware was expensive, with limited capabilities. It is always an amazing journey to review what computers were capable of 30 years ago versus what they are able to perform today. And although their capacity continues to improve, the capability of computers is rarely the limiting factor anymore. Back then, computer systems were viewed as tools, like an adding machine or telephone, with no real vision of how the tool could drive organizational change or move the business in new directions. Integration and interoperability were crude at best. Life for the developer was easy, because customers were not very picky and normally were quite happy with any tool that would help them in their day-to-day work. It is interesting to draw a parallel with the early days of television: the programming was sparse, the picture quality low, and many of the shows crude (at best), but in general, people were happy with it because expectations were low and not difficult to meet. Today, with hundreds of channels and digital quality, it seems like most people still have a hard time finding anything they like. Expectations have changed.

Although there were several systems development methodologies around in the mid-1980s, they all tended to have a strong focus on the systems side, often at the expense of understanding the real business need. The creation of the system, or programming of an existing system, was typically the starting point of the project, followed by a multitude of trials and errors. Many projects were canceled and even more were not received well by the customers. There was little or no attention paid to making sure that the developers understood what the actual business problem was that they were trying to solve. Although this was understandable because there was limited precedence in the way of system solutions, customers were often faced with not knowing how to describe what they needed and quite often took the “I’ll know it when I see it” approach.

Gradually throughout the 1980s and 1990s, this started changing. Systems rapidly became more complex, and business more competitive and global, leading to a shift from struggling with what technology could do to struggling with what the business was trying to accomplish. One of the first projects that I worked on after moving to the United States in 1984 was a common accounts payable system for General Motors (GM). Prior to that, the projects I had seen at Volvo Ltd. in Sweden were mostly single-user, relatively nonintegrated applications. At GM, there was a stronger emphasis on capturing what the customer needed, trying to get consensus between different organizations to build “common” systems, as well as trying to closely integrate the accounts payable function with receivables and purchasing (Figure 1.1).

To be successful in that environment (and because the system is still running some 20 years later, I think one could argue that the project was successful), it took a different skill set than that of the traditional systems developer. Although technical skills are still important, systems development now has become more and more about communication, facilitation, negotiation, and basic people skills. There were many very good technical people who didn’t enjoy this new environment, resulting in many issues between the developers, with their minds on the solution, and the users, with their minds on what the business needed.

Although technical skills are still important, systems development now has become more and more about communication, facilitation, negotiation, and basic people skills.

Figure 1.1 Evolution of systems.

In an attempt to try different ways to improve communication between developers and customers, some organizations created account teams made up of analysts responsible for interfacing with the customers, gathering their requirements, and making sure that they were satisfied. Instead of the customer talking to the developer, it became the account team’s responsibility to make sure the development team understood the customer’s requirements. Unfortunately, people put in those positions often did not have a strong business background or a good understanding of what the developers needed. Based on the lack of tools and training, the business analysts were struggling with this dual communication role—talking business to the customer and systems to the developers. It made projects more complex by requiring coordination between developers, users, and go-betweens. It made the need for good project management practices even more critical than before.

1.4 Project Management Institute^®

In the late 1960s, the Project Management Institute (PMI^®) was started. Although its impact was gradual in the beginning, by the mid-1990s PMI had become a driving force in the area of establishing standards for project management. Their Guide to the Project Management Body of Knowledge, currently in its fourth edition, has been instrumental in establishing a common language and a concentration on the planning aspects of a project.

With the help of PMI and various development methodologies, the late 1990s saw good development practices and good management of the development process put into place, enabling the development teams to develop something faster. However, that still left a big void. PMI’s domain is how to take an idea and implement it. The product description (in whatever level of detail it is available) is an input into the project management processes. But who creates the product description? How does the developer make sure that the right product is developed? Obviously, it is ideal to develop a solid product and to do it in an organized fashion; however, if it is the wrong product, there is still a big problem. Some people feel that PMI could have done more to define standards for this,...

Table of contents

• Cover
• Half Title
• Series Page
• Title Page
• Copyright Page
• Table of Contents
• Foreword to the First Edition
• Preface
• About the Author
• 1 Introduction
• 2 Laying the Foundation
• 3 Business Analysis Planning and Monitoring
• 4 Elicitation
• 5 Requirements Management and Communication
• 6 Enterprise Analysis
• 7 Requirements Analysis
• 8 Solution Assessment and Validation
• 9 Preparing for the Test
• 10 Swede-Mart Case Study
• 11 Answers to Test Questions
• 12 Activity Solutions for Swede-Mart Case Study
• Appendix A: Acronyms
• Appendix B: Business Requirements Document Templates
• Appendix C: United Nations Organizational Chart
• Sources and Bibliography
• Index