A Project Manager’s Guide to Requirements Modeling – Part 1

Originally published in PM Times on March 17, 2015.

We often get asked how project managers (PMs) justify allowing enough time to model requirements on their projects. These PMs complain that although they agree that requirements modeling has huge benefits, they have a hard time justifying the amount of time it takes. This article opens a series on requirements modeling with the emphasis on why PMs should care about modeling requirements. Each article looks at a single model, the benefits of that model to the project, the questions PMs need to ask related to that model, and how much the PM needs to understand in order to manage the requirements modeling activities.

What is a Model?

A model is a representation of reality, like a model car, airplane prototype, or graphical design (e.g., a CAD drawing) of a house. As they relate to requirements, models usually consist of text, graphical representations, or both. Most models have both diagrams and textual components. Text can be sentences (user stories), tables, matrixes, or lists, but words are the primary component. Diagrams (process models and use case diagrams to name a few) are usually visual methods of representing requirements. In software development there are several complementary models that help elicit requirements.

Models can be developed using a variety of techniques, including facilitated workshops, one-on-ones, prototyping, and others. An advantage of graphical models is that they can reduce the ambiguity when only text is used. We will review a number of different models in subsequent articles. Each modeling technique helps ask the clarifying questions needed to uncover hidden requirements. These techniques are interdependent and each is usually completed iteratively throughout the completion of requirements activities.

Why Model Requirements?

In this series, we explore the relationship between requirements elicitation and requirements modeling, elicitation being about asking the right questions. We know that for our projects to succeed and for us to get the information we need to build our end-product, we need good requirements. To get good requirements, we need to ask the right questions. We need to ask both high-level consultative questions to determine the true business need, as well as questions about the features, characteristics, and functionality needed for the end product. We need to go beyond the “who, what when, where, and why” questions which, although helpful to start us out, rarely get to the detail we need. We’ll explore how modeling helps uncover requirements related to these product features and functions in each of the articles in this series.

In addition, there is risk associated with not getting good requirements. Reports like PMI’s 2014 Pulse of the Profession¹ points to the need for getting our requirements right and the high costs associated with not doing so. The Standish Group’s Chaos reports consistently point out the need for stakeholder involvement to get good requirements.²

Iterative Elicitation and Modeling

\We can’t start out modeling requirements without some understanding of the end-product. Therefore, we need to ask enough questions to be able to develop an initial model of the requirements. Once we have a picture, or model, we can start to see the gaps in the requirements, gaps that will almost assuredly lead to additional questions. We call this process of asking questions and modeling requirements Iterative Elicitation and Modeling. Below is a figure illustrating this relationship between elicitation and modeling. It shows that modeling helps us to ask the right questions, questions we most likely wouldn’t think to ask. Asking questions, then, enables us to model the requirements. Modeling requirements, in turn, allows us to ask further questions and ultimately deliver the product that our stakeholders are expecting.

What Does this Mean for Project Managers?

Some project managers are directly involved in these requirements activities, and some are not. In either case, we have found that it is not uncommon for project managers to underestimate the complexity of business analysis work including elicitation and modeling. We think it important for project managers to understand the risk of not taking the time to use models to elicit requirements. Regardless of the role doing the work (project manager, business analyst, designer, developer, or whomever), and regardless of the project approach (Waterfall or Agile), the work needs to get done. It might get done by the development team during each iteration on an Agile project, or it might get done during the business analysis phase(s) or a more traditional project, but details of the end product are necessary in order to provide a product that will work for the stakeholders and be one that they want to use. In all cases, this work takes time and needs to be accounted for as the project manager plans the project.

So How do PMs Justify Taking Time to Model Requirements?

First, it is essential for project managers to recognize the importance of asking the right questions during elicitation. Next, PMs need to understand that if they don’t model the requirements, they will probably not be able to ask the right questions. Then PMs need to put time into their plans for these iterative elicitation and modeling activities. Finally, they need to articulate the importance of taking the time to do this work and the risk of not doing so when they think they don’t have the time.

Don’t forget to leave your comments below.

References