Tag: Elicitation

Beyond Requirements Analysis – Enterprise Analysis

Written by Alan S Koch on September 15, 2009. Posted in Articles. 1 Comment on Beyond Requirements Analysis – Enterprise Analysis

“What do your Business Analysts do?”

“They develop and manage project requirements, of course. What else would they do?”

What else indeed!

The BA Body of Knowledge (BABOK®) defines what a professional BA should know and do. Much of it is focused on requirements work – but not all. One of the knowledge areas that takes the BA beyond requirements work is “Enterprise Analysis.”

Enterprise Analysis (EA) encompasses those activities that the job title “Business Analyst” actually points toward: analyzing business processes. The majority of these activities is outside of projects, and in fact, put the BA into the position of recommending and justifying projects.

Enterprise Analysis

Analyzing business processes is indeed a big part of what we do during Requirements Analysis. But that is not the only context where this analysis should be done, and in fact, it is not the most valuable time to do it. In the Enterprise Analysis knowledge area, the BABOK identifies several other contexts in which such analysis should be done.

Activity: Creating and Maintaining the Business Architecture

As the name of this activity implies, “Creating and Maintaining the Business Architecture” is an on-going activity that has as its focus the entire enterprise. The “Business Architecture” is a model of all the business processes that are used throughout the enterprise. It shows how they work and relate to each other.

The net result of this is an understanding that most organizations lack, of how all their moving parts mesh with each other. This broad understanding of the enterprise’s processes becomes the foundation for all of the other responsibilities of the BA. But its bigger value comes in providing every member of the organization with a clear understanding of how his or her department and individual job fits into the bigger picture

Recommending and Justifying Projects

The bulk of the activities described in the Enterprise Analysis knowledge area center around proposing and justifying projects. These are activities that occur in some form or other in any organization. But with the BA’s involvement, they can provide much more value and ensure the organization’s resources are spent on the most valuable projects.

Activity: Conducting Feasibility Studies

Projects are created to solve a problem or to take advantage of an opportunity. It is rare for there to be only one available solution to a problem or opportunity, so part of project initiation involves exploring the alternatives. The BA can provide a valuable service by calling upon his or her understanding of the Business Architecture to analyze the feasibility of a variety of options.

Activity: Determining Project Scope

Scope definition should not be the first step in requirements development; it should be done during the project proposal process. How can the decision-maker(s) approve or disapprove a project without a clear understanding of its boundaries?

Activity: Preparing the Business Case

The business case is the logical argument for embarking on a project. It consists of contrasting the status quo (current situation) with the various options for addressing the problem or opportunity at hand and recommending the most appropriate option. In most cases, these options are being contrasted in terms of money (e.g., “If we spend $x on this project, it will result in $y increased revenue per year”).

Activity: Conducting the Initial Risk Assessment

An important piece of information that the decision-makers need is an understanding of the risks involved in a project. Clearly, you cannot do a complete risk-planning workshop before the project has been initiated (that is part of the Project Planning process). But an initial survey of the project risks can provide the decision-makers with key information.

Activity: Preparing the Decision Package

The BA has no authority to approve or disapprove any project. The people who do have that authority rarely have the time that is necessary to do the requisite research. So, the BA’s role in the decision-making process is to do all of the necessary research, and compile it into a form the decision-makers can use.

Activity: Selecting and Prioritizing Projects

After a project has been approved, it should not be a foregone conclusion that it will begin immediately. Projects must be prioritized against each other so the organization’s resources can be deployed in the most appropriate way. Again, the BA is not the decision-maker, but provides the necessary analysis to the decision-makers.

Project Work beyond Requirements

The last three activities that the BABOK includes under the “Enterprise Analysis” knowledge area are project-related activities that go beyond Requirements Analysis. They continue the theme of Enterprise Analysis by maintaining a broad organizational view of the project.

Activity: Launching New Projects

Here, the BA works with the appropriate people in the organization to ensure that the necessary resources, including the right project manager, are committed to the project. The BA’s unique role in these activities is to focus on the bigger picture of why the project was approved and how it fits into the bigger organizational context. This ensures that the intent of the decision-makers is honored as the project is framed and kicked off.

Activity: Managing Projects for Value

In this activity, the BA works closely with the project manager to ensure the project is tracking toward providing the value that was promised in the business case (above). The BA helps the project manager keep the project’s value proposition on track. And if the assumptions on which the project was approved turn out to be false, the BA can help the decision-makers determine their best response.

Activity: Tracking Project Benefits

In this last activity, the BA closes the loop on the business case (above). The business case proposed making certain investments in order to accrue certain benefits. After the project is over, the actual investments are known, and the actual benefits can be measured. At some appropriate time after deployment, the BA should report back to the decision-makers about how the results of the project compare with the business case. This discussion process will help the organization make better decisions in the future.

Expanding Your Value as a BA

Requirements Analysis is an important way for the BA to provide value to his or her organization. By adding Enterprise Analysis, the BA can dramatically increase his or her value by ensuring that every project fits well into the bigger picture and provides the best possible result to the organization.

Don’t forget to leave your comments below

Alan S. Koch, PMP is a speaker and writer on effective Project Management Methods. He is a certified Project Management Professional and President of ASK Process, Inc, a training and consulting company that helps companies to improve the return on their software investment by focusing on the quality of both their software products and the processes they use to develop them.

Mr. Koch’s 29 years in software development include:14 years designing, developing and maintaining software; five plus years in Quality Assurance (including establishing and managing a QA department); eight years in Software Process Improvement and 10 years in management

Mr. Koch was with the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) for 13 years where he became familiar with the Capability Maturity Model (CMM), earned the authorization to teach the Personal Software Process (PSP) and worked with Watts Humphrey in pilot testing the Team Software Process (TSP).

For more information about Mr. Koch: http://www.ASKProcess.com/experience.html.

This article was originally published in Global Knowledge’s Business Brief newsletter. (www.globalknowledge.com)

Capturing Requirements with Use Cases

Written by Todd Wyder on August 25, 2009. Posted in Articles. 1 Comment on Capturing Requirements with Use Cases

Use cases are becoming more mainstream as a method for capturing requirements, as evidenced by the endorsement of big companies and methodologists such as Booch, Rumbaugh, and Coad. One benefit of use cases is that each one encapsulates a set of requirements. This encapsulation lets you easily manage and track the use cases individually and provides a better alternative to prose requirements.

There is more to effectively using use cases than just capturing them and putting them into diagrams. As you implement use cases, you need to validate them, determine their size, and establish a plan for implementation. Then, you need to incorporate the use cases into your system design and turn them into code and documentation. Throughout this process, you must also be aware of the status of each use case. This article will discuss ways to do all these things.

Validating Requirements with Use Cases

Once you’ve captured a use case, you need to confirm whether it accurately describes the system and is truly needed by the system’s users. Sometimes, in the course of development, you realize some of the requirements you’ve created are unnecessary or peripheral to the main purpose of the system. You must identify these as soon as possible, so you can work on the functionality that is the most valuable to the customer. But how do you determine which use cases are most important to your users? You use a method called Quality Function Deployment (QFD).

QFD helps you weigh use cases to determine which ones are important and which can be discarded. To use QFD, users representing each group in the actor catalog are given a list of the abstract use cases and $100 in virtual cash to spend on the ones they think are the most important. The amounts are then tallied to determine which features are the most desired.

When using QFD, it’s important to keep one caveat in mind: make sure you include on the list all the obvious features the users will expect in the system, because it’s very likely these features will not come up while you’re gathering use cases. For example, in the banking program, users would obviously require a “transfer funds” use case. However, because they expect this feature to exist, they might not consider it important and not allocate funds for it. It’s important to allow for this and include the basic functions of the system into the QFD.

Sizing

Because use cases describe functionality from the user’s point of view, they can be directly converted to function points. Assigning function points to use cases helps us understand how large a use case is and the associated effort needed to produce it.

We can use this knowledge in iterative development to divide the iterations into roughly equal sizes and determine earned value. Some companies use earned value to recognize revenue. You can do this by dividing the estimated cost of a program by the number of function points, which yields a cost per function point. Each use case then becomes part of the executable. Multiply the number of function points associated with each use case by the cost per function point. The result is the amount of revenue recognized. You can use this same technique for project tracking by using the number of function points delivered to determine the progress on the project.

Iterative Development

Determining the implementation order of requirements involves several conflicting factors: the needs of the customer, the needs of the development team, and the needs of management. The customers would like to see the parts of the program they want implemented first. The development team needs to work on the most complex parts of the program first, so it can move from high complexity to low complexity. Management would like to work on the parts with the highest risk, so they can move from high risk to low risk.

So, how do you balance all three concerns? The customer’s needs are known through QFD. If you deliver the iterations based on the QFD scores, you ensure customer satisfaction. But to also satisfy the needs of the development team and management, it’s best to rank each use case for complexity and risk as well. Here’s one way to do this: Rank complexity on a scale from one to five, with one being very simple, four being very complex, and five unknown. Rank risk similarly, with one being marginal, four being high risk, and five unknown. Once you’ve rated all the use cases, multiply complexity, risk, and the QFD percentage to get a weighted value that takes into account customer satisfaction, complexity, and risk.

Design

Use cases can help you create your system design and also serve as the foundation of design reviews. Use cases can be readily converted to object, interaction, and event diagrams and used as a basis for CRC cards. In a design review, use cases force designers to show how each use case is enabled by the design, and which elements of the design are not part of any use case. This ensures all requirements are implemented and no unnecessary work is done.

Testing and Documentation

Use cases are the backbone of testing and documentation. If the use cases are clearly stated and testable, they form the basic system test plan. They are also well suited for acceptance testing, in which users test all use cases on the system and approve the system’s performance of each one. Because use cases represent the user’s perspective, they can form the initial user manual, online documentation, or help file. Some divisions of Microsoft use a similar technique; they write the user manual first and it becomes the specification for the program.

Use Case Tracking

To make sure you deliver what the customer has asked for, you need to know the status of each use case. Knowing where each use case is within the software life cycle is valuable for managing the project and determining status. You can accomplish this goal by assigning each use case a Work Breakdown Structure (WBS) in the project plan. Then, as you track the project, you also track each use case. This also yields a method for determining WBSs.

As your project progresses, you need to manage and control your use cases. A repository makes this possible. One method is to keep the data in a groupware database product such as Lotus Notes and include the following information on each use case:

A short descriptive name of the use case in the form of an action verb and noun, such as “export to spreadsheet”
A detailed description of the action the use case performs
The preconditions: other activities that must take place before this use case executes
The post conditions: the actions that will happen to the use case after it executes
The exceptions: what happens if the use case fails
The pattern name from Coad, Gamma, and so on
The Work Breakdown Structure (WBS)
The number of function points required
The location of the design files for the use case
The location of code files for the use case
The modifications made to the system, the date the modifications were made, and the name of the person who made them.

Use cases are a valuable tool for capturing and managing requirements. You can use them in all facets of the software development life cycle. As you move throughout the different phases of your next project, think of how use cases could be involved and how you would manage them. If you manage and track use cases well, you’ll be able to use them to their fullest.

Don’t forget to leave your comments below

Todd Wyder is Vice-President Product Management and Development at COE Truman Technologies, Inc., a 25 year old information firm that provides software products and professional services to a wide range of industries. Todd is a goal-oriented executive with experience in planning, developing and implementing cutting-edge information solutions to address business opportunities

Projects without Borders; Gathering Requirements on a Multi-Cultural Project

Written by Elizabeth Larson on August 11, 2009. Posted in Articles.

Co-authored by Richard Larson

One of the most difficult tasks project managers and business analysts face is obtaining customer requirements. Even when business customers and the business analyst work in the same building, misunderstandings are bound to arise. And as more and more businesses expand beyond their borders, different terminology and ways of doing things the risk of things going awry gets even greater. It’s a challenge to ask the right questions, get the right people involved, and document unambiguous requirements, regardless of the backgrounds of those participating. When the project includes multi-cultural stakeholders, particularly if they comprise a virtual team working in geographically dispersed areas, often thousands of miles, time zones and oceans apart, the job becomes much harder.

Some of the challenges facing project managers and business analysts are not unique to multi-cultural projects. However, personal agendas, conflicts about roles and priorities, and availability worsen the situation. In addition, recent studies have shown that almost half of the typical project budget is spent reworking requirements defects. While there are many underlying reasons for this rework, dealing with a group of multi-cultural business customers and/or project team members can create significant hurdles.

The Challenges

Physical Distance of Stakeholders

Although many of the challenges exist even when the team and business customers are located on the same floor in the same building, the difficulties in dealing with them increase with physical distance. Time zones make meetings hard to schedule. Business analysts on today’s global projects have learned that the standard eight-hour work day doesn’t exist. If we are truly customer-focused and interested in building relationships to capture requirements, we schedule meetings at a time convenient to our customers, not to us.

Few meetings on global projects are face-to-face, making the assessment of non-verbal communication nearly impossible. Since most business analysts pay a great deal of attention to non-verbals as part of the elicitation process, not being able to see them diminishes the communication and therefore the ability to capture requirements. Finally, although there are alternatives to face-to-face meetings, neither video conferencing nor “net” meetings is ideal. Video conferences usually lack some spontaneity and the audio lag can be distracting. Facilitating large groups over a video conference is quite challenging, since multiple conversations, dominance of one group or individual, and other facilitation difficulties abound. With both video-conferencing and net meetings, there are often equipment issues which hinder the requirements elicitation.

Roles and Responsibilities

Unclear roles and responsibilities can be the bane of project mangers and business analysts everywhere. When they are unclear, tasks invariably fall through the cracks and finger-pointing ensues. Unfortunately when stakeholders are removed from each other, it takes longer to find omissions and the resulting errors are harder to correct. Trouble usually occurs if a business analyst expects the business client to define the requirements, but the business client thinks they have already provided the solution and the rest is up to the business analyst. With differing cultural attitudes towards conflict, it can take even longer to perceive that there is a difference of opinion, let alone resolve it.

Language

Language barriers across cultures are numerous. The difficulties caused by differences in languages and even pronunciation among the stakeholders is well-known. In addition, most people have different levels of understanding and expressing both written and oral languages that are not in their tongue. For example, some people can understand another language when spoken, but have difficulty writing it. Others can understand better than they speak and write better than they understand. In order to elicit the requirements, project managers and business analysts need to work with business customers whose language differs from theirs to assess the comfort with both written and oral communications.

Finally, we need to consider the use of TLAs (three-letter acronyms), humor, euphemisms (powder room, passed away, downsizing), and sports analogies (ballpark estimate, coming out of left field, long shot) that can cause confusion and misunderstanding.

The Cultural Landscape

Another barrier is assuming that all team members, whether or not they are collocated, approach the project with the same cultural perspective. For example, I was managing a project that included a male team member who appeared uncomfortable taking direction from a woman. The more I discussed the importance of meeting deadlines, communicating status, and teamwork, the more uncommunicative and uncooperative he became. Finally I realized that the real problem was that I had done nothing to build trust and a strong relationship with him. His cultural work ethic dictated the importance of relationships. Therefore, he completed tasks because of the relationship, not because tasks appeared on a work breakdown structure.

Tips and Techniques for Making it Work

As organizations take on more global projects or projects that include a diverse set of business customers, they need to establish a corporate mindset of acceptance, inclusion, and learning that crosses borders. In addition, the project team needs to understand its inter-dependency in order to have project success. Synergy between the business customers and the project manager or business analyst is required to ensure that the end product is successful. Therefore, each party, the project manager, business analyst, sponsor, and all the business customers have an obligation and a stake in making this cultural diversity work. Without the project manager, the organization will spend more time and money on failed projects. Without the business analyst, the end product will not be usable. Without strong sponsorship and actively engaged business clients, the true requirements will not be discovered, and the end product will not be viable.

Although each party has its responsibility for making the project and end product successful, there are some things that the project manager and business analyst can do that help bridge the cultural gap.

Build Relationships and Trust

Building relationships and trust is important on all projects. There are a myriad of ways business customers can sabotage a project if they are afraid that the end result will jeopardize or dramatically change their jobs, or when the local requirements are not taken into account. With good relationships, issues surface more easily and can be resolved quicker.

The different requirements elicitation venues promote team-building to a greater or lesser degree.

For example, the use of surveys does little to promote mutual understanding.
Facilitated sessions (which may have to be net meetings on global projects) can help build teamwork, but it could take weeks or months for a virtual team to solidify.
One-on-ones serve to build relationships and help navigate the political and cultural landscape. By meeting individually, the project manager or business analyst can assess commitment to the project, discuss individual concerns, gather requirements from those who may not speak up in meetings, and gather requirements related to local needs of the global business experts. One-on-ones can also more easily promote understanding of team members from various cultural backgrounds, because language differences are the least problematic and personal stories and experiences can be more easily shared.

Define Roles and Responsibilities Using a Matrix

One technique that can aid in avoiding the pitfalls of unclear roles and responsibilities is to document them using some form of matrix, such as the Responsibility Assignment Matrix or the RACI chart. These tools use minimal text, so they are easier to understand than textual descriptions. In addition, in order to complete them, valuable discussion needs to occur. By facilitating this discussion, the project manager can help ensure that the fine distinctions between such things as a role and responsibility can be cleared up earlier rather than later in the project.

Example RACI Chart

(Responsibility for doing the work, Accountability for decisions, Consult with on the work, Inform that the work has completed)

Task/Phase	R	A	C	I
Project Plan	Martha	Mary	PMO	Team
Requirements List	Martha	Client	Requirements Consultant	Team Client’s Staff
Modeling (Process, Use Case, and Data)	Ying, Susan, David	Mary	DBA	Team
User Interface Requirements/Prototyping	Martha, David	Mary	Usability Lab	Team
Programming	Sunil, Shashi	Mary	All BAs	Team
User Acceptance Testing	Martha	Client	Sunil, Shashi

Model the Requirements

One of the best ways to elicit requirements is to use various models to represent the requirements. Models, such as process models, usage models, and prototypes can provide a structure that encourages asking questions to find hidden requirements and more quickly document a complete set of requirements. Models have a number of advantages in general, and for cross-cultural projects in particular:

Models have the advantage of needing few words, so the language issues can be more easily overcome. They also have the advantage of promoting a two-way translation of requirements, from business customer to the model and back to the business customer, again with a great deal of structure and a minimum use of words. Models should be created so that they are clear and for the most part understood and used by the business clients.
Models are the most effective way to avoid having different members of the group have different mental pictures of the requirements. They are, for the most part, culturally independent. They can be created using several of the requirements venues including facilitated sessions, one-on-ones, and observation.
Models can help traverse the cultural landscape because they produce unambiguous requirements. That is, there is little room for misinterpreting them. Regardless of the birth countries of the business customers, business analyst, and team, cultural interpretations of the requirements are minimized by using pictures instead of text.
Finally models can be used whether or not the business customers are local or dispersed. Technology now permits models to be easily shared in-person, by email, with video-conferencing, and with net meetings. Because models can be viewed by all, there is less chance for miscommunication of requirements.

Summary

A large, multi-national U.S.-based pharmaceutical client of ours regularly experiences the challenge of cross-cultural requirements gathering. The following are some anecdotes to summarize a few of the key points in this article.

A conference call with a Tokyo client took twice as long to review a process flow as with domestic clients. The analyst kept asking “is there anything else” because of not wanting to omit something important. (Conclusion: plan for extra time when working cross-culturally.)
A similar group of Japanese clients insist on spending time at the beginning of a project getting to know their IT counterparts. They frequently and repeatedly ask that the IT staff come over to Japan to meet and visit with them. When the groups do meet in person, each meeting ends with a glass of sake to celebrate. (Conclusion: relationships are more important than the work in some cultures than others, even to the extent of delaying work. Projects will be stalled until relationships are established, and trust may be even more difficult to establish.)
A cross-cultural team of American, French, and British clients spent two hours talking about an industry term that the three groups swore had three different meanings. They later discovered the terms were really the same and then had to agree on which one to adopt. (Conclusion: language differences will be a challenge, so take the time to define key terms and record them in a glossary during projects.).
A project manager made an onsite visit to a client from Latin America on a project. The project manager had written in an email that he had found a restaurant to go to, but you had to BYOB. The client was confused and asked when they got together: “who is ‘bee-yob’?” (Conclusion: be careful with and define all acronyms!)

In sum, gathering requirements on a multi-cultural project has numerous challenges. To avoid or lessen the affects of these pitfalls, project managers and business analysts should spend time developing relationships, clarify roles and responsibilities in a chart format to ensure understanding by all, use terms and language carefully, and model the requirements to help ask questions. The ultimate goal is to uncover requirements in a way that is easier for all stakeholders, regardless of their language and culture.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. 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. Attendees immediately learn the retainable real-world skills necessary to produce enduring results. Between them they have presented workshops, seminars, and training classes on three different continents to over 15,000 attendees. Their speaking history includes repeat appearances at Project Management Institute (PMI®) North American, European, and Asia-Pacific Congresses, and at Business Analyst World conferences around North America. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP®) 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 of the section on collecting requirements in the upcoming 4th edition of the Project Management Body of Knowledge (PMBOK®).

Requirements ATTACK!

Written by Keith Ellis on August 11, 2009. Posted in Articles.

In my job, I get to hang out with a lot of very senior people and talk with them about requirements and business analysts. The one complaint I hear over and over: “Our BAs are not proactive”. Maybe some in the organization are being a bit passive, but the executives I talk with are most concerned that the BAs are order takers, rather than being seen by the business as really driving the process. You need to ATTACK requirements. Be proactive! And, know the right questions to ask to motivate stakeholders to get you the right kinds of information. Here’s the problem – many analysts get in the way of their own success.

Remove the Barriers

It’s easy to fall into the role of order taker and think the customer can drive the requirements process; particularly in the face of an assertive executive with a fairly clear vision of what they want. I humbly submit, if you roll-over and become an order taker, you’re dead. The requirements on the project will likely be incomplete with significant functional areas missing, and there is likely to be no consensus between executives in the areas of interdependency. Think value-add! The analyst is the one that needs to fill the gap between what the business can articulate for itself, and what the technology department needs as input for successful development. Get people on board with the idea that there is a gap in content that needs to be filled, and remove both the barriers to participation and the barrier to being proactive. If you show you can add value to articulating business needs, you are taking the bull by the horns and being proactive.

Have a ‘Go To’ Process that Always Works

Analysts get caught up in self-flagellation because they have no personal expertise in the business process they are reviewing. Get over it! You cannot possibly be expert in every process and system in the company. Candidly, it’s a fool’s game to try! Even the SVP operating the division must rely on their experts running the subcomponents of the business, as these in turn rely on their subordinates. How can an analyst portray themselves as more expert in every area of operation of the company than these executives without annoying their stakeholders with their arrogance? The analyst is not there to define optimal business practices for the business. The analyst is there to optimize the process used by business leaders to achieve consensus in their practices. The analyst also knows how to take concepts from high level understanding, to clear, accurate and complete documentation.

Before everyone gets angry at me…you absolutely can be expert at doing requirements and getting executives to consensus without being a business area subject expert. Analysts can absolutely be successful where they have a ‘go-to’ process for eliciting business requirements that is easy for participants, and adds value to their thinking process.

First and foremost you cannot get hung up on problem definition. You can do all the problem definition, analysis of issues and look-back reviews in the world and still have massive problems articulating a solution, especially when dealing with something complex. Watch out for the trap people fall into all the time! You cannot consistently jump from problem to solution so spending too much time on getting better resolution on the problem will not get the business closer to solution.

Situation or problem definition can be insightful, but only in so far as it helps bring clarity to the correct needs, objectives and goals. With a solid understanding of objectives and goals, it is not a large step forward to ask: “To achieve these objectives and goals, how must the business process change?” Discovering, eliciting, and describing the processes that change in response to meeting an objective business is the goal of an analyst. The ability to be a great analyst is to have the right kit bag of techniques to draw on to help the business articulate these changes in a systematic, clear, accurate and complete way.

ATTACK the Detail

There are lots of ways to break down projects into reasonable chunks using scenarios, user stories, use cases, or any number of techniques. These only get the surface information. To be a proactive analyst, you need to attack the detail and ask the questions that proactively pulls this information out of stakeholders. To attack the detail, think SIPOC (SIPOC stands for suppliers, inputs, process, outputs, customers). It’s a concept the six sigma folks hijacked, but it’s a great tool for business analysts when you use it to describe how information moves in the business process:

For the scenario “price an order” (starts with confirm item details, and ends with provide quote to customer) ask SIPOC in this order:

Input: What information do you need to know to be able to price an order so you can provide a quote to a customer?
Process: What do you do with that information?
Output: What typically happens once you’ve priced the order?
Customer: Does anyone else need to know about the priced order?
Supplier: Is all of this information coming from you, or do you need input from someone else?

Uncovering how information needs to move to support the business process and ultimate business objectives motivating change is the detail an analyst needs in order to get clear, accurate and complete business requirements. We’re in information technology remember!

Ponder Points

Here are some closing thoughts to consider – or maybe comment on – as you get back to the daily grind:

As the analyst, YOU are accountable for the process of getting the requirements. If you are accountable for anything, it is to be proactive.
Being proactive doesn’t require you to be an expert at all things business. It does mean knowing techniques that add value and can take you from problem to solution.
There are a lot of blind alleys out there! Be sure to that you select and adopt techniques that accelerate you along the path from problem to solution in incremental steps, rather than requiring you to take giant leaps from problem to solution.

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

Gathering Requirements; Go Away Please!

Written by Elizabeth Larson on July 21, 2009. Posted in Articles.

Co-author Richard Larson

One of the most difficult phases of a project is gathering business requirements from stakeholders. Under the best circumstances requirements are often vague, because it is difficult for customers to articulate their needs before they see the end product. In addition, some customers have personal agendas, which make identifying the true needs difficult. When the business customers and project team have a relationship built on trust, they can more quickly work together to produce a product of value to the organization.

Go Away, Please!

What happens, though, when that trust factor is missing? Sometimes the clients’ resentment manifests itself openly. If you’ve ever heard the following in response to setting up requirements meetings, you have probably encountered open resistance:

“We’ve always done it this way”
“If it ain’t broke, don’t fix it”
“The tool or technique that I’m using now works just fine, thank you”
“I’m busy right now. Go away please!”

All of these responses imply not only that things are working well as is, but that the change is less than welcome. Because the change is not apt to be readily accepted, resistance to it can contribute to an undesirable project outcome. The underlying cause of resistance will be discussed later in the paper.

Resistance is not always evident to the project manager and/or business analyst. It can be couched in friendly terms. If you’ve encountered the following, you may have run into what we call the “Missing Trust Factor.”

“Did I tell you that last week? I’m terribly sorry but that was wrong.”
“Boy, I sure don’t remember telling you that.”
“Oh, I’m so sorry, but I forgot to tell you…”
“There is no way I ever said that,” when trust is really absent

Overt resistance is easier to handle than behavior that appears to be cooperative, but which prevents the project from moving forward. This article focuses on resistance to business requirements elicitation and discusses how building relationships and trust can help overcome it.

What are Business Requirements?

To understand why it is difficult to get business requirements, particularly when stakeholder relationships are weak or absent, it is necessary to define the term. A business requirement is a description of the features and functions of a product (something you will deliver) that satisfies a want or need enabling people to do, know, operate, or have something new or in a new way. This description usually is in the form of text, but could be documented in a graphical model. The features of the product describe characteristics and functions describe what the product needs to do.

Marketing Example:
The new brochure will include:

Features
Company name and tag line
Company branding and identity
New program
Related products
Benefits
Customer testimonials

Functions
Introduce company to new customers
Provide credibility to new customers
Provide a consistent message and image
Provide speaking points during customer visits and presentations

System Example:
The new order system will include:

Features
Reports rolled up by:
Customer, product ordered, date
Product, price, cost
Discounts
Special promotions

Functions
The system shall:
Adjust suggested retail for profitable customers
Apply discounts by dollar amount or percent off
Allow for specific sale price to be entered

Requirements Solve Business Problems

Before the formal requirements gathering begins, it is important to discuss the business context of the project with the sponsor. Requirements need to be gathered and managed in relation to the organization’s vision and strategic direction. They need to link to business goals and objectives. When requirements do not have this linkage, which we call upwards traceability, there is a high likelihood that customers will request features and functions that are not only out-of-scope, but may also promote their own personal agendas.

In addition to meeting business objectives, requirements usually work together to solve business problems. One of the most common complaints from business analysts and project managers who gather requirements is that their customers often bring them solutions. The underlying need for the solution, however, is neglected, often resulting in a product or service that goes unused. Some questions to ask to uncover this business problem are:

What is the problem and the resulting business pain?
What is currently limiting you?
What were some things that made you realize the status quo wasn’t good enough?
What opportunity arose?
What compliance or regulatory requirement is this project addressing?

Initial meetings with the sponsor to discuss the business and project vision, as well as the business problem(s) can be a helpful way to establish rapport and begin to build trust. When sponsors and business experts realize that the project manager is going to help them reduce the pain in their current environment, acceptance can begin. Focusing on the business need and vision also demonstrates business acumen, which in turn builds respect, and leads to trust.

Once the business problem, project objectives, and deliverables are documented, we can begin to gather our high-level requirements.

Trust and How Requirements are Gathered

Facilitated Sessions

There are a variety of techniques that are typically used in requirements elicitation. One of the most common is the facilitated session, in which a facilitator encourages key stakeholders to articulate their requirements in a formal meeting session. This approach has many advantages, including using the synergy of the group to help build relationships and trust.

On the other hand, the dynamics of the attendees can have a significant effect on the facilitator’s ability to elicit requirements, as well as the group’s ability to provide the information sought. The following are just a few behaviors that can contribute to an unsafe environment, thus impairing the group’s effectiveness in articulating their requirements:

Dominant participants, particularly when they have more positional power than others in the group
Lack of respect on the part of participants towards other participants and/or the facilitator
Unclear roles and responsibilities related to the session. The most common issue is having the facilitator, such as the project manager, also be responsible for the outcome of the meeting, This important topic of separating the meeting results from the meeting process is widely misunderstood. Not clearly separating these two important responsibilities often creates an uncomfortable environment, which can stifle requirements elicitation and often skews the results.
Unclear ground (meeting) rules, which guide the group’s behavior. Unless each participant actively agrees to each ground rule, there is the risk that a variety of dysfunctional behaviors will prevent the group from reaching its desired outcome and, in the process, create an unsafe environment.

One-on-Ones

Another common technique is the “one-on-one.” This technique is a way for business analysts and project managers to meet individually with stakeholders. Through these individual meetings trust can be built in several ways:

Assess commitment. Some stakeholders do not like to make decisions or agree to decisions in meetings. One-on-ones provide a safer venue to discuss real needs behind the stated-and unstated-needs.
Address individual concerns. Some individuals are more inclined to reveal their true concerns about the project and the other project stakeholders in one-on-ones, rather than in large groups. When elicitation is limited to facilitated sessions, these concerns go largely unaddressed.
Address negative behavior. Sometimes stakeholders either dominate meetings or demonstrate various types of behavior that negatively impact the group. By meeting individually, analysts and project managers can focus on the behavior and, together with the individual, determine ways to reduce its impact.
Recognize individual achievement. There are individuals who are not comfortable with public recognition. With these stakeholders, individual accomplishments are better recognized in private.

Each of these individual meetings is a chance to establish rapport and ultimately build relationships and trust.

Barriers to Elicitation

There are many barriers to effective elicitation, including (just a few):

Distance of stakeholders. Ideally all key stakeholders would be collocated, that is, officed on the same floor or in the same building. The further removed the business experts and sponsor are from the analyst and project manager, the more difficult requirements elicitation will be. Each of the most commonly used technologies for elicitation, teleconferencing, video conferencing, and net meetings presents significant challenges which can be overcome, but which make the process cumbersome.
Inadequate discovery time. Whether we want to acknowledge it or not, it takes time for business experts to discover their requirements, particularly the details of those requirements. For example, homeowners can discuss certain aspects of the house they want to build, but rarely can they articulate all their detailed requirements at the first meeting with the architect and builder. This is true for all business requirements, regardless of the project size. Complexities arise when different stakeholders have different requirements that must be reconciled and finalized.
Having a project and product requirements that don’t fit into the organization’s goals and objectives. When this happens, stakeholder availability tends to evaporate. Poor or late attendance at meetings, coming to meetings unprepared and unanswered voice and emails are all symptoms.
Not understanding the political “landscape.” Analysts and project managers who begin projects without having a clear picture of any politics involved will struggle, and the project is likely to take longer than expected.
Reluctant or even hostile participants. If a project is meant to automate, streamline, or downsize an operation, people often fear losing their jobs. Trust is difficult to establish and complete requirements are hard to gather when providing the details may cost someone their job.

The Most Difficult Barrier – Distrust

Perhaps the most difficult barrier to overcome is stakeholder distrust of the people, project, or end product. There are many reasons why key stakeholders may not want the end product, and they may try any number of sabotage techniques. Analysts and project managers need to understand the fundamental association between the ability to gather requirements and the relationship with the stakeholders who have the requirements.

The most common reason for stakeholder caution and concern is distrust, caused by one or more of the following:

Fear that the end product, such as a new system, will dramatically change or eliminate their jobs
Fear that the end product will impede or slow their workflow in the name of trying to improve it
Fear that familiar software (existing system or Excel spreadsheets) will be incomplete, inaccurate, or difficult to learn
Fear of loss of value or stature in the organization. A new process may be less cumbersome than the old. A new system may be faster and may provide more information. And, a new product may be enormously valuable for the company. Despite all this, an individual’s business process will change, and the affected employee will have that uncomfortable lack of familiarity. Stakeholders are usually reluctant to relinquish their knowledge and expertise in an organization, and distrustful of those they perceive as taking it from them (project managers and business analysts).

Without an established relationship and trust, it will be very difficult for analysts and project managers to elicit the necessary requirements.

Risky Business

What happens to the when trust has not been established? The risk of having a less than positive outcome greatly increases. Some possible impacts include:

Unhappy sponsors. Sponsors do not usually like having their client representatives or project managers make a habit of asking for additional time and/or funds. They also are not fond of hearing their staff complain about unsatisfactory products. When requirements are not clear from the beginning of the project, both tend to occur. An effective partnership between sponsor and project manager is the best way to address these possibilities. And the most important component of an effective partnership is trust.
Added scope. Business clients and sponsors will figure out a way to get the features and functions they want and expect, even when they have never articulated them.

Sometimes this additional work is authorized, but more often business clients put .

Schedule delays. It will almost always take longer to gather requirements when relationships have not been established. Each time that requirements are given to sponsors and business clients to review, more time is needed for turnaround and approval. There will most likely be more time required for revisions, as well.
Team issues. It is easy to fall into “blame mode” when new requirements surface late in the project. Imagine this conversation:

Project manager: “This widget was not part of the approved project scope.”
Business client: “Yes it was. Right here where it says provide all necessary widgets.”
Project manager: “But you never specified this particular widget. You said all necessary widgets. This seems more like a want than a need.”
Business client: “Well, I need to have it because I’ll have to create workarounds without it.
…

What is Trust?

Trust can be thought of as “acceptable uncertainty,” and has been said to be “the big issue of the 21^st century,”). A recent survey (Golan/Harris Trust Survey, February, 2002). found that 69 percent of Americans say “I just don’t know whom to trust anymore.” Yet trust is the foundation of effective partnerships and collaboration. Building trust requires acting consistently and with integrity over time. According to the Golin/Harris Trust Survey, the top things organizations can do to build trust are:

Be open and honest
Communicate more openly, honestly, and straightforwardly

In addition, for parties to trust each other, each must:

Communicate bad news as needed
Act with integrity and honesty
Acknowledge mistakes
Give credit where credit is due
Value each other’s input
Make and meet commitments
Be competent within the domain of expertise

Trust usually takes time to develop. We may initially trust or not trust those involved on our projects, based on past experience, personal filters, culture (organizational, geographical, and otherwise), and a wide variety of factors that can influence our judgments. Analysts and project managers don’t always have or take time to let relationships develop, so here are some things that can be done to build trust quickly:

Discuss the project objectives openly. For example, if reducing headcount is a business objective and the project in question may contribute to meeting that objective, the project manager or analyst needs to communicate the possibility to the stakeholders if asked. Trust will not be built by avoiding the conversation or asking the stakeholders to discuss it with their bosses. Such an open conversation can lead to one about the advantages to the employee of actively participating to help the organization meet its goals.
Communicate bad news. If the project is behind schedule or needs more resources or if lack of stakeholder participation is slowing the project, it is important for project managers and analysts to address these issues with the sponsor and other appropriate team members.
Encourage laughter. There is a strong correlation between laughter and trust. Having fun in meetings and laughing appropriately (not hurtfully) builds a sense of team and a desire to work together towards a positive project outcome.
Define clear roles and responsibilities. When not defined, not only do tasks overlap, but more commonly fall through the cracks, which invariably leads to finger-pointing, blame, and lowered morale. Clear definition helps prevent territorial squabbling and decreases the chance of misunderstanding and the resulting project delays.
Deliver on what is promised. As the saying goes, “talk is cheap,” but trust is built on delivering what was promised and agreed on. Since trust is about expectations, find some “quick hits” you can deliver on quickly. It will help build trust for the outcomes that take longer to deliver on.

Maintaining Trust over Time

Once trust is established, it can lead the team members through project difficulties. However, once broken, it cannot easily be regained. Some things that are guaranteed to break the trust are:

Disclosing confidential information. While we do want to encourage open communications, we cannot disclose information given to us and accepted in confidence. It is acceptable to tell the inquirer that the information is confidential. It is also acceptable to set up initial communications guidelines, such as if the information is confidential, you will say so.
Creating a competitive environment. Competition by its very nature produces winners and losers. While some stakeholders can be positively charged by competition, for others it can be viewed negatively, with resentment and even anger, leading to a weaker relationship.
Communicating within a hierarchy, rather than having team-based communications. When we keep the entire team informed, we reduce the likelihood of gossip, speculation, and low morale.
Micromanaging. Hovering in its various forms can give the impression that the micromanager does not trust the “trustee.” In turn the person being micromanaged will also develop a mistrust of the micromanager.
Not making decisions. Being indecisive can be destructive to the team looking for leadership. Being decisive does not mean making all the decisions or being authoritarian. It does mean taking appropriate action to resolve real issues, remove project barriers, and move the project forward.

Summary

In conclusion, requirements elicitation requires building relationships and trust among the project stakeholders. When trust is absent, the requirements elicitation process will take longer, be incomplete, and lead to lower morale. Although building relationships takes time and effort, it can actually shorten project time and result in improved project performance. Finally, a good relationship between project manager and sponsor, built on trust, goes a long way to resolve the inevitable project issues that surface and help ensure positive project results.

References:
Golan/Harris Trust Survey (February, 2002). Retrieved 14/03/05 from http:/www.golanharris.com. O’Hara, K. (2004) Trust from Socrates to Spin Icon Books Ltd, retrieved on 06/07/05 from http://www.trustenablement.com
Trust Enabling Strategies, retrieved on 06/07/05, from www. http://www.trustenablement.com

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals of Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.