Author: Elizabeth Larson

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is a consultant and advisor for Watermark Learning/Project Management Academy, and has over 35 years of experience in project management and business analysis. Elizabeth’s speaking history includes keynotes and presentations for national and international conferences on five continents. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 6 grandsons and 1 granddaughter.

Requirements Management 101

Written by Elizabeth Larson on December 8, 2010. Posted in Articles. 5 Comments on Requirements Management 101

The following is an excerpt from the book Practitioner’s Guide to Requirements Management, Part I: Requirements Planning written by the authors.

Overview

Requirements management, like project management, is a discipline comprised of inputs and outputs, tools, and techniques, processes and activities, but just for the business analysis effort. Requirements management includes the planning, monitoring, analyzing, communicating, and managing of those requirements. Get a quick introduction or refresher on this important topic.

We will briefly look at a few of the key ingredients in managing requirements, including what gets created during planning, documenting “good” requirements, traceability, and managing changes.

Requirements Management

The discipline of planning, monitoring, analyzing, communicating, and managing requirements.

Planning

Two of the key outputs from requirements management are a planned and communicated approach to business analysis and a requirements management plan.

The business analysis approach. The approach that we take to business analysis work is primarily concerned with the type of framework, method, or methodology we use to capture our requirements. The approach is the cornerstone of our effort, and it determines how we go about collecting and managing requirements. It describes the processes we will follow and the templates, if any, that we will complete. the approach will probably be different for different methodologies and frameworks. For example, prioritizing requirements on an Agile project is different from prioritizing them on a Waterfall project. In choosing an approach, we need to make sure that it’s communicated to all appropriate stakeholders and that they are onboard with the approach that will be taken.

The requirements management plan (RMP) describes how the business analysis work will be completed. It describes processes for how requirements will be documented, traced, prioritized, baselined, and changed. We might also think of the RMP as a collection of the plans that are used to manage business analysis. The RMP can be a formal set of documents with many subsidiary plans, such as a business analysis communication plan, business analysis risk plan, estimates for the business analysis work effort, and many more. This type of RMP might be appropriate for larger, riskier projects. On some smaller efforts the RMP can be an informal roadmap. In either case, it is subsidiary to the overall project management plan.

Documenting “Good” Requirements

Requirements documentation. Requirements are always documented, either formally or informally. Requirements might be documented as part of a detailed requirements specification, in the form of a short text known as a user story, or as part of one or several models, such as a business process, data, or use case model, or as a prototype or mock-up. There is no right way or wrong way to document requirements, as long as all the requirements are understood by everyone who hears or reads them–which means they need to be “good.”

What makes a Good Requirement?

In order for a requirement to be worth managing, it must be useful. To be useful, a requirement has to be understood by all key stakeholders. Sponsors and business subject matter experts need to know that the ultimate solution will solve their problem and meet their objectives. Developers need to understand how to design and build the final product. The testing staff needs to be able to find and remove any defects the product may have. Change managers (Human Resources staff, consultants, business managers, etc.) need to understand how the end product will affect the organization. If a requirement is not clear, some or all of the components that comprise the product could be defective. To that end requirements must be clear and unambiguous, consistent, complete, concise, and confirmed (validated and verified). They must also be testable and traceable. Here are some tips to make requirements “good.”

Describe what is needed rather than how the need will be implemented.
Use units of measure or specific words to reduce ambiguity. So, “less than five seconds” is preferable over “fast,” for example.
Use a glossary to reduce ambiguity. As new stakeholders become involved over the life of the project, a glossary can prevent misinterpretations and increase productivity. It is also helpful to include an acronym reference list with the glossary for easy access to those acronyms.
Keep sentences concise and simple in relationship to number of words and grammatical structure.
Organize and group requirements into a hierarchical list, with high-level requirements broken down into sub-requirements as they are uncovered.
Uniquely identify each requirement. Use a hierarchical numbering system (1.0, 1.1, 1.1.1, 1.2, etc.). Such a scheme can be used to more easily trace requirements (see below).
Remove redundant requirements or clarify requirements that seem similar but are really unique.
Use graphical models, diagrams, and prototypes where appropriate.

Traceability

Requirements traceability is a structured way to keep track of requirements. Requirements are traced back to their source, to themselves as detailed requirements are discovered, and throughout the project. Tracing requirements back to their source is sometimes called backwards or upwards traceability and involves linking requirements to the identified business problem, business objectives, and project objectives. Figure 1 illustrates the concept of backwards traceability.

Figure 1 – Backwards Traceability

Tracing requirements throughout the project is called forwards allocation or forwards traceability and involves documenting the linkage between the requirements and other requirements, and requirements to the design, development, testing, and deployment work products. Figure 2 illustrates the concept of forwards traceability.

Figure 2 – Forwards Traceability

Requirements traceability aids requirements management by ensuring that each requirement:

Adds value. By tracing each requirement, its value in helping the organization solve its problems and meet its objectives becomes apparent, thus helping the organization focus on doing all the right things and only the right things.
Belongs in the approved scope. Requirements that cannot be traced do not belong in the project. Scope management is one of the biggest project challenges, so traceability is a useful tool in controlling scope.
Is actually delivered at the end of the project or project phase. Once the right requirements have been identified and agreed upon, it is important to ensure that all the pieces needed to satisfy those requirements are designed, built, tested, and delivered.

Traceability also aids in determining impacts and interrelationships, so that:

The cost of each requirement and requested changes can be more easily estimated.
Testing coverage can be planned.
Risks can be more easily identified, and a risk response plan developed.

Traceability Tip

Use traceability to help ensure that each requirement is linked with project deliverables, project objectives, business problems, and business objectives, thereby preventing rogue requirements from sneaking into the project.

Managing Changes

An important part of requirements management is handling changes. During requirements planning, processes to handle changes are established, including who requests changes, who authorizes them, and who vetoes them. The “who” might be an individual, or it might be some type of change control board. Once the change process is approved, it is necessary to follow it. The approved process depends on the business analysis approach taken, and might vary from project to project. For example, the process for handling changes on an Agile project might well be different from a traditional project. Regardless of what that process is, however, it must be communicated and agreed to by affected stakeholders.

Summary

We have looked at a few of the key ingredients in managing requirements. They included planning tasks of determining the approach and creating the requirements management plan, which needs to be appropriate for the business analysis effort. As we do the business analysis work, we document “good” requirements in the format and to the level of detail required for the project at hand. Finally, to help control the scope, we trace requirements and manage changes.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Is Your Organization Agile Ready? Part 2.

Written by Elizabeth Larson on December 1, 2010. Posted in Articles. 2 Comments on Is Your Organization Agile Ready? Part 2.

Last month’s blog was the first in a series about organizational readiness-ready, that is, to provide resources necessary to succeed in an agile environment. We asked these four questions on our Agile organizational readiness checklist:

Will your organization provide a dedicated product owner for each scrum team?
Will your organization provide dedicated team members?
Does your organization support time-boxing each iteration?
Does your organizational culture support just-in-time requirements?

This month we’re going to look at Agile organizational readiness from the perspective of false expectations for some organizations that have decided to implement Agile methods.

Does your organization support “cowboy” development?

Some organizations adopt what they call an “agile methodology” as an excuse to eliminate discipline, commitment, and ownership. They have the mistaken belief that a lack of discipline equates to getting the work completed sooner. In some organizations senior leadership decides to adopt “Agile” without understanding what it entails and the commitment that is required to make it work effectively. The term “Agile” becomes an excuse for adopting a chaotic, free-for-all environment. Management in these organizations can boast that they’re “doing Agile,” but might not be aware of the frustration such a chaotic environment causes the team.

Does your organization expect that eliminating the role of the BA will eliminate documentation?

I have heard organizational leaders say something to the effect of “we’re going Agile so we no longer need a business analyst” or “don’t put a BA on this Agile project. BAs will just produce a mountain of unnecessary documentation.” They see business analysis as unnecessary work and the BA as a role whose only goal is to produce a massive requirements specification at the end of one long business analysis phase. In reality, the business analyst is a kind of management consultant, someone who acts “as a liaison among stakeholders ..to recommend solutions that enable organizations to reach their goals” (BABOK Guide ® Version 2.0. As wonderfully articulated by Kevin Brennan of the IIBA, organizations which undertake Agile projects still need help understanding their underlying business problems and figuring out the best ways to solve them. They still need projects to help them solve those problems. And they still need a role that will focus on the requirements of the end product (solution), ensuring that the end result of the project provides the expected business value. In other words, the role of the BA is not to produce documentation, but to help ensure that the end product and its associated requirements help the organization reach its goals. In that capacity, every BA is obligated to produce documentation as appropriate to the project at hand.

Does your organizations have realistic expectations of the Scrum Master?

Does your organization expect the technical team “leader?” to be the Scrum Master, providing technical expertise and direction to the delivery team? Having any formal lead role on the Scrum project is problematic. When teams are truly self-organizing as ideally they are on Scrum teams, leaders emerge, rather than being designated. In addition, any time that the Scrum Master spends focused on the technical aspects of the project and directing the delivery team is time not being spent on facilitating, removing roadblocks, calculating the resource capacity and burn down rate, and generally doing the work that Scrum Masters need to do. There is a reason why on some Agile projects the role is called “coach,” not leader. Finally, the Scrum Master who works as the technical lead is at risk of providing a more a technical rather than a business solution.
Does your organization expect the Product Owner to be the Scrum Master? The Product Owner (PO) is a critical role on an Agile project. It represents the business, making the business decisions required to move forward developing the end product. Last month we addressed the importance of having organizational commitment for a full-time PO because it is a full-time position. When the Scrum Master is doing PO work, the Scrum Master work is not getting done. And the decisions made run the risk of ignoring important technical considerations.
Does your organization expect the Scrum Master to play other roles such as business analyst? I attended a presentation recently promoting the idea of BA as Scrum Master. The central theme of the presentation was that because both Scrum Masters and business analysts are facilitators, the BA is in the best position to be the Scrum Master. I found the premise intriguing and well-intentioned, but misguided. The facilitation that is required of a Scrum Master is different from that of a BA. The former focuses on facilitating the team and its ceremonies, the latter facilitating requirements workshops among subject matter experts. And there is vastly more to both roles. It’s almost like saying that because an insurance agent, a bank teller, and a city ombudsman all interface with customers, that one could easily step into any of the other roles.
Does your organization expect the Scrum Master to play multiple roles? All but the smallest Agile projects deserve full-time Scrum Masters. Organizations which believe that they can get by “on the cheap” by combining roles on Agile projects may well suffer disappointment in the results that get produced. As on any other project, each will suffer.

There are many more areas that we could cover, but we’ll leave it for now in the hopes that you’ll add your own ideas and experiences to the topic.

Don’t forget to leave your comments below

Terms, Terms, Terms. Clarifying Some Business Analysis and Project Management Terms

Written by Elizabeth Larson on November 17, 2010. Posted in Articles. 7 Comments on Terms, Terms, Terms. Clarifying Some Business Analysis and Project Management Terms

In order to clarify some basic concepts of business analysis and project management, we need to distinguish between terms that seem similar but are not. Below are some foundational terms and distinctions.

1. Project Management focuses on the work and methods to create new products. The Guide to the Project Management Body of Knowledge (PMBOK^® Guide – Fourth Edition) defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”[1]

2. Process Management concentrates on the workflow and systems that recreate the products that sustain an organization.

3. Products. Throughout this article, we’ll refer to the end result of the project as the product. It can be a product, service, or any key deliverable that is produced as a result of the project. A few examples of products include a new bridge, a new methodology, landscaping, a project management office, a new car, a feasibility study, an HOV lane added to a freeway, a recommendation, a new or changed process, a new banking service, a new website, creation of a new agency, and a new marketing campaign.

4. Product Management uses processes and knowledge to manage product development, support, and marketing of the product. In this article, we cover the part of product management that occurs prior to deploying, selling, and supporting the end product. We focus on the work needed to define the requirements of the end product, to ensure that those requirements are built into the product and tested, and to ensure that the end product meets those requirements. Product managers exist in some organizations as the driving force behind new product development. They often define the high-level product requirements. In such organizations, this product manager often fills the role of project sponsor. See Table 1.1 for a summary.

Characteristic	Projects	Product Requirements	Processes
Ownership	Sponsor	Sponsor	Sponsor
Keeper or custodian	Project manager	Business analyst	Business process analyst
Planning	Project management plan	Requirements management plan	Documented processes
Execution	Performing project execution	Performing BA activities	Performing the process steps
Closeout	Project close and lessons learned	Closeout of phase(s) & lessons learned	Improved processes
Aligns with organizational vision and strategy?	Must	Must	Must

Project, Process, and Product Requirement Characteristics

Projects are initiated in a variety of different ways, such as new government regulations, competitive market forces, and requests to enhance existing products. In other words, someone in the organization requests a new or changed product.

The person who initiates the request is called the sponsor. We’ll explain the full sponsor role later, but for now let’s think of the sponsor as the person who obtains the funds for the project and makes key business decisions.

Once the request has been approved, a project manager can be assigned to manage the project. Projects result in changed processes for an individual or group of individuals large or small. For example, a new bridge results in new traffic patterns and new processes for those taking the bridge. Landscaping requires processes to maintain it; the HOV lane requires new laws and new processes for use by drivers. A new computer system results in new processes for the end-user. Therefore, stakeholders affected by projects, processes, and products all need to be identified and kept informed of the project status. Figure 1 below shows the interrelationship of projects, processes, and products.
larson-Ba_12_shrunk

Figure 1: Projects, Processes and Product Requirements Interaction

Life Cycles, Phases, and Methodologies

Project Life Cycle. A project life cycle takes the project from its inception to its conclusion. In other words, each project is alive. It is conceived, born, it matures, and finally ends. Products have their own life cycles. Typically, product life cycles last longer than project life cycles, because in general the product outlasts the project. However, in the example of a lengthy feasibility study whose product is a recommendation, the life cycle of the project can last longer than the end product. Project life cycles are composed of one or more project phases.

Project Phase. The project phase,as described above, usually marks a milestone, at which point a deliverable is usually produced, reviewed, and approved. The business analysis phase(s), then, produces a set of requirements (features and functions) that must be reviewed and approved.

The names of the project phases do not have to be the same for each project. One organization may have projects in different divisions or business units or agencies, all of whom can have different phase names. Nor are there a set number of phases required for each project. For example, the number of business analysis phases for a software development project can vary, depending on the approach taken to business analysis and the phase-to-phase relationship used. The business analysis effort can occur during one project phase or over the course of many project phases. For example, iterative development of software projects occurs over several project phases, as could the piloting of new business processes. For a complete discussion of lifecycles and phases, please refer to the PMBOK^® Guide – Fourth Edition, section 2.1.2.

Methodology. This prescribes how to get through the project life cycle, including the business analysis phase(s). It usually includes processes, procedures, forms, and templates for completing the project or project phase. Each project phase could, but does not have to, follow the same methodology. There are methodologies for completing business analysis, project management, product development, and testing to name a few.

Iterations, Increments, and Releases

These terms have created a great deal of confusion over the last several years. In the blog Don’t Know What I Want But I Know How to Get It, Jeff Patton uses art, movies, and pop music to explain the difference between “iterating and incrementing.”[2]

In a PowerPoint presentation, Managing Increments and Iterations with “V-W” Staging, Alistair Cockburn distinguishes iterations and increments by referring to increments as “build, deliver, learn, build, deliver, learn,” and iterations as “build, examine, learn, rebuild, ship.”[3] For another short differentiation, see Kevlin Henney’s article from December, 2007.[4]

Incremental development implies that new features and functions are added with each increment. For example, software can be developed using a plan-driven approach, with increments or new functionality added incrementally. Incremental business analysis implies that requirements are defined for an increment, and new requirements are added for each increment. Again, releasing in increments is appropriate for both plan-driven and change-driven approaches.

Iterative development implies planned rework. We expect the product requirements to evolve and change, so that change is viewed as part of the development process, not as a defect. Each iteration evaluates what has been built, and the product is rebuilt as needed. Iteration implies planned rework, because not only do we expect requirements to evolve, but there is a process to handle changes iteratively. Change-driven business analysis combines incremental and iterative requirements definition.

Product and Solution

Although the industry sometimes treats these two terms synonymously, we will use the term “product” for the end result of the project, and the term “solution” to mean the implementation of the requirements. The solution is a term used to describe a set of key deliverables that when taken together solve the business problem for which the project is undertaken.

Here are some examples.

The productof a project is a new marketing campaign. One solutionmight be to hire a consulting firm to produce the campaign. Another solutionmight be to have the advertising department develop it.
The productof a project is a new piece of software. One solutionmight be to build the software. Another solutionmight be to buy it from a vendor. Yet another solutionincludes new software, new hardware, and new processes.
The product of a project is a new order replenishment system. One solution might be the software, hardware, new and changed processes, and a recommendation on whether or not the organization is ready for the change. The requirements describe the features, functions, and capability of the new system. The deliverables (work products) from business analysis include a business requirements document, a recommendation on new hardware, a model of the future processes, and a recommendation on a new organizational structure for the affected business units. The order replenishment system alone will not solve the business problem, so the solution has to include more than just the system. This solution may involve many projects, each of which will have products.

Summary

Making distinctions in terminology is important for both planning and execution of projects, and common language can help reduce misunderstanding and miscommunication. When everyone understands the underlying concepts of business analysis and project management and uses the same terminology, they can complete the work more productively and with less conflict.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Management Institute. A Guide to the Project Management Body of Knowledge, Fourth Edition (PMB[1] Project OK^® Guide). Newton Square, Pennsylvania: Project Management Institute, 2008. p. 435.

Patton, Jeff. “Don’t know what I want, but I know how to get it.” Agile Product Design. 21 Jan. 2008. <http://www.agileproductdesign.com/blog/dont_know_what_i_want.html>.

Cockburn, Alistair, “Managing Increments and Iterations with ‘V-W’ Staging.” <http://alistair.cockburn.us/>.

Henney, Kevin. “Iterative and Incremental Development Explained.” Search Software Quality. 3 Dec. 2007. 29 Jan. 2009 <http://searchsoftwarequality.techtarget./news/article/0,289142,sid92_%20gci1284193,00.html>.

Is Your Organization Agile-Ready? Part 1.

Written by Elizabeth Larson on October 5, 2010. Posted in Articles. 6 Comments on Is Your Organization Agile-Ready? Part 1.

Lately I’ve been getting questions from Agile seminar participants about how to apply Scrum to “real life,” as though these methods are “good in theory, but not at my company!” Some organizations may not be ready to adopt agile methods completely, so I encourage students to take an organizational readiness self-assessment to see if Agile in general and Scrum in particular is right for them. The questions on the self-assessment can be used to begin conversations as a way to raise issues that need to be resolved in organizations thinking about adopting Scrum.

Will your organization provide a dedicated product owner for each scrum team?

A key role on a Scrum effort is the product owner (PO). This is the role that represents the business community, particularly the project sponsor (sometimes called business owner or the stakeholder), and therefore is tasked with answering the business questions and making the business decisions. This is the go-to person for the requirements, for answers to the team’s questions about the features and functions that the business wants out of the end product. This is also the role that prioritizes the items on the product backlog. It seems to me that in the heat of the iteration or sprint, the team needs immediate access to the person making the business decisions. In order to complete the sprint in a short time-frame, such as two weeks, the team cannot wait for the PO to get back to them at their convenience. They cannot wait for the PO to check with other SMEs to come to consensus. The team needs immediate answers. Having a dedicated PO is critical to the success of a scrum team.

Will your organization provide dedicated team members?

Many organizations allocate resources to multiple projects. I often get the question “do the team members ever work on multiple projects in Agile?” When I answer that, in order to complete sprints every few weeks, it is necessary to have dedicated resources, I often get pushback. “Everyone at my organization,” I’m told, “has to work on multiple projects.” In some organizations the motto is “we’ve always done it that way” but we want you to do it faster, which we’re going to call Agile. But you need to continue to do things the old way.

There are huge advantages to having a dedicated team, such as time wasted trying to keep track of where we left off another project or dealing with team dynamics that are wildly different from one team to another. It is hard to create a self-organizing team when members float from one team to another. And team members who have been part of a high-performing, self-initiating, and self-motivated team, all of whom do whatever is needed to get the job done, rarely want to return to a more traditional team. This is particularly true when they have to jump back and forth between the two.

Does your organization support time boxing each iteration?

One of the most frequent questions I get asked is “are Agile time boxes fixed,” going on to explain that at their company the powers that be keep adding features that extend the number of days in the sprint. In these organizations the time boxes become fluid and it’s hard to plan what can get done during the sprint. In order for a team to establish its velocity, that is, how many user stories can get completed during a sprint, it is necessary to have a fixed number of days in each sprint. Organizations insisting on throwing additional features and extending the current sprint may not be ready to take full advantage of Agile projects.

Does your organizational culture support just-in-time requirements?

Organizations that have a one-process-fits-all set of business analysis processes might not be ready for an Agile environment, particularly when those processes have proven burdensome for some projects. I have worked with clients who have proudly showed me their new requirements process. Some of these companies do not differentiate between project types, approaches, and final product, so that the processes for developing software are the same as for new processes, and new product development, marketing campaigns, new bridges, etc., and processes for large projects are the same as for small ones. On the flip side, teams often struggle when organizations don’t recognize the importance of requirements, or the role of the business analyst, or why we need any requirements processes at all. In these companies, doing just-in-time requirements means moving straight to design.

Just-in-time requirements mean that requirements for upcoming sprints are defined completely before the beginning current sprint. One clear advantage is that when requirements are “groomed” or defined before each sprint, time is not wasted during the sprint trying to figure out what each user story means. The PO does not need to take time away from the Team to meet separately with other subject matter experts (SMEs) to uncover needs and expectations. That work has already been completed. As I’ve said in past blogs, who is better to groom the backlog than the BA?

Next month we’ll explore other questions that organizations can use to help them decide whether they are ready to make the necessary commitment to ensure the success of agile adoption.

Don’t forget to leave your comments below

Be Satisfied with what I Give You- It’s Better than what You Asked for

Written by Elizabeth Larson on September 8, 2010. Posted in Articles. 7 Comments on Be Satisfied with what I Give You- It’s Better than what You Asked for

My husband and I usually stay in hotels on vacation and sometimes our expectations, those unspecified requirements, are not met. This blog deals with two aspects of unmet expectations: unwanted features and making changes.

Unwanted Features

How many of us are universally delighted with every room assigned to us? Recently, despite asking for a quiet room with a king-size bed (my husband is 6’3”), we were assigned a room with a double bed facing a busy, noisy street. When we asked to change rooms, the front desk clerk sighed with disgust and said, “But we gave you a suite.” We didn’t ask for a suite. We asked for a quiet room with a king-sized bed. We got features we neither wanted nor asked for and didn’t get features that were important to us. Clearly in the clerk’s mind the suite was more valuable than the features we requested.

I suspect many of our sponsors and other stakeholders end up with features they don’t want without getting the features that are important to them. Years ago I was a banking officer implementing a new teller system. I provided my requirements during a series of meetings with IT. When the design was done I was presented with a series of “wouldn’t it be great if the system could do…” “Yes,” I responded, “it would be great as long as it allowed automated teller balancing.” “Well, no,” I was told. Tellers would still need to follow their current, cumbersome process.

More recently I spoke with an executive involved in a project where she had only one requirement – new information, currently captured, on a current report. When the requirements package was presented, the report was missing. When she questioned what happened to the report, she was told about all the wonderful features and functions the system would provide. But her report was still missing, despite assurances from the sponsor that it would be included.

I’m sympathetic to the business analysts and project managers who want nothing more than to provide outstanding customer service to their stakeholders. I totally encourage project professionals to recommend new direction, new features and functions, new processes, etc. as long as these recommendations include an analysis of the problem, a recommendation to solve the problem, and the benefit of solving it.

Where we get into trouble is by presenting solutions that the sponsor and other stakeholders don’t ask for. During business analysis we sometimes ask leading questions which are less questions and more presenting solutions to unidentified problems. Questions such as “Have you ever thought about…” or “Would you ever consider…” are examples. Even worse is when we think we know more than our stakeholders. We add features that we think are cool or even necessary, and include them as requirements, without first checking with the business stakeholders to make sure the business values and is willing to pay for them.

Making Changes

My Uncle Bill used to tell us that no matter what type of hotel or where it was located, no matter how many of the hotel staff he talked to in advance of their arrival, Aunt Roslyn would look at the assigned hotel room, find it inadequate, and request a change of rooms. When we were younger, we always felt sorry for Uncle Bill. How patient, how long-suffering he was to put up with the inevitable bother of changing hotel rooms.

However, as we’ve aged, my husband and I find ourselves changing rooms more frequently. After the above-mentioned front-desk clerk tried unsuccessfully to convince us to stay in the suite, he told us respectfully but firmly that no other rooms were available and change was not possible. In desperation we agreed to pay a fortune to upgrade to get what we originally asked for. Nevertheless, the clerk appeared unhappy. Clearly, the change request was an anomaly and upset his process.

I suspect that many of our sponsors and other business stakeholders are reluctant to request changes because of our body language, because of a burdensome change process, or because they are used to being told “you can’t have that change. It’s out-of-scope.”

In looking back, it seems that we’ve been less likely to change rooms when we’ve taken a virtual tour of the hotel prior to booking a room. Unlike photos taken at just the right angle to make a tiny, bare room look cozy and comfortable, a virtual tour provides a broader perspective of the room in relationship to the rest of the hotel. Pictures provide a structure for us to help the stakeholders discover their requirements, and one of the best ways to provide pictures is prototyping. Unlike static screen shots or wire frames, prototypes that allow our business stakeholders to “use” the end product help elicit not only their requirements, but also those hidden expectations. Even when the prototypes are low tech rough drafts drawn in PowerPoint or on easel pads, they are an effective elicitation technique.

I’m not sure much will change on future vacations. But that’s OK. Few hotel clerks are as crabby as the one above. We have generally found them to be friendly and flexible, like most of the project professionals we worked with as well.

Don’t forget to leave your comments below