Tag: Team

The Lexicon of Solutions – Down with the Customer

Written by Steve Blais on March 13, 2012. Posted in Articles.

Well, no not really. Not the customer him or herself, although I’m sure there have been many times when that phrase was uttered in frustration within the comfy confines of the war room. No, I’m talking about the label “customer” that we might want to consider eliminating as it refers to the internal organization people we in IT work with.

Back in the day (I won’t get into exactly when in modern history the phrase “back in the day” refers to), the customer was the one who paid for the software development regardless of whether the customer was involved in what was requested. The “customer” was clearly distinguished from the sponsor, or the users, or the other stakeholders. After all, the definition of a customer is “a person who purchases goods or services from another.” (Note that a colloquial meaning of customer is “a person one has to deal with: a tough customer.” This may more accurately reflect some people’s concept of customer.)

Nowadays the customer refers to anyone who has a request, and/or the primary point of contact, and/or people who use the system, and/or just about anyone in the business community who is involved with the project. We’ve probably all worked with projects that have had several “customers,” most of whom better fit the colloquial definition above. Some IT departments tend to reference anyone in the business as their “customer.” And this is OK since from some perspectives everyone requiring services from IT, whether it be resetting passwords or developing a brand new accounts payable system, meets the colloquial criteria that defines a customer.

Back in the day (same timeframe), no one outside the organization, certainly none of the organization’s customers, saw the results of IT projects. This meant that confusion about the customer was minimal. IT’s customers were internal and those customers provided a barrier between IT and the “real” customers of the organization.

However, today, since a much greater percentage of our systems are aimed externally, the term “customer” brings about confusion. Suppose we have a project that creates a new portal to increase our online sales. Our “customer” is marketing who is defining the content, functionality and appearance of the portal, but we are creating the portal for existing and potential customers of the organization. You see the issue. Which customer has precedence? Are we satisfying the internal “customer” or the external “customer”? (Of course one would assume that by satisfying the internal customer we automatically satisfy the external customer. But then, ignoring the cases where that is not true, why have two “customers”? Why not have everyone focus on the external?)

So I’m thinking that it is time we retired the term “customer” from our IT vocabulary at least as it refers to someone in the business and reserve it specifically for those to whom the organization provides goods and services.

In essence, there are four reasons to stop using the term “customer”:

“Customer” is ambiguous. To some in IT, the customer is the person in the business who has the problem they are solving while to others that is an SME. To some the customer is the one who pays the bills and everyone else is a user. Even within a single company the meaning can change project to project and person to person. The term can also get personal and possessive when business analysts and others refer to “my customer.” (At times I wonder about the connotation of that possession. Does it mean the same as “my client,” or perhaps “my spouse” or maybe “my pet dog, Jackson.”) And then you get into conflicts between or among customers for various projects.
“Customer” is no longer truly applicable. At one time we could call the business person with the problem a customer and there would be no confusion with the organization’s customers. We simply did not do systems that involved people outside the company. Those customers, the ones who bought our products and used our services, were a distance away from the accounts receivable, and inventory control and accounting systems we were creating and maintaining.

Nowadays, most of our systems are externally visible to the real organization’s customer. It is probably time to start focusing on the organization’s customers. We all serve the same customer: the person who buys our products and services and keeps the organization alive.

The term continues the chasm between IT and business. Customers are always on the other side of the counter, usually separated by money from the person waiting on them. It is hard to imagine full collaboration with a customer (the kind of collaboration we would like to have) who is paying the bills and has the power to pull the plug. Moreover, the term perpetuates the barrier between IT and the organization’s real customers by continuing the belief that the people we have to satisfy are those within the organization as opposed to those who are supplying the revenue to keep the organization going. Focusing only on one “customer” means that the business and IT can forge a collaborative relationship to enhance the experience of the organization’s customers.
Customers can go elsewhere and buy their desired goods and services from another source, say a different store or supplier. Internal customers are stuck with us. We have a monopoly for the most part on their IT service needs.

What term to use instead of customer? “Partner” might be applicable since the goal would be to partner with the business person to develop systems that better serve the organization’s customers. But “partner” is already reserved for the organization’s compatriots and supply chain members. Besides, there is an implication of lawyers, which we don’t want to get into.

How about “problem owner”? They are coming to us with a problem and we are helping them solve it. They must stay in the loop and collaborate with us to make sure their problem truly gets solved. Together we can solve the problem. It may be an accurate term, but it sure sounds negative and ominous. There are probably many people who would not want to be labeled a “problem owner” even in a friendly way.

One alternative to “customer” is “product stakeholder.” The “product stakeholder” refers to anyone who has a stake in the result of the project — the product. So anyone making requests of the product might be termed “product stakeholder” rather than customer. We can then separate product stakeholders into those affected by the problem and those impacted by the solution for purposes of elicitation and delivery.

What do we call the upper-level manager who controls the purse strings? How about the old stand-by sponsor? Or if the purse string controller is actively involved in the project, how about the Project or Product Champion? These are older terms that may be worthwhile to recycle for clarification. (Note that the definition of “champion” in days gone by identified the person from the business community who most wanted the product implemented, for whatever positive or personal reason.)

There may be a better appellation for IT “customer” that removes the ambiguity and confusion and describes the collaborative partner we want the business to be. Do you have a suggestion?

Don’t forget to leave your comments below.

Meet Your Business Analysis Influencer

Written by Kupe Kupersmith on March 6, 2012. Posted in Articles. 1 Comment on Meet Your Business Analysis Influencer

My goal in life is to meet everyone in the world. I know that goal is not SMART (specific, realistic, etc.). It is not reaching the goal that is important; it is the effort I go through to try and meet the goal that counts. The goal goes deeper than just “meeting” people. I try to meet everyone I can and establish a relationship. Building strong relationships is a constant, consistent goal of mine. Some grow deeper than others, but I don’t discriminate. I meet and engage with people sometimes without knowing how I will add value to that person or how they will add value to me. For some this is a hard concept to grasp. Some feel so busy and can’t fathom spending time getting to know someone new without knowing why you should get to know them.
We work in a highly collaborative work environment. You don’t have to do everything on your own. If you build strong relationship people are more willing to help you. So if you are too busy to build relationships it is because you are not building relationships.

If you still need some convincing regarding building relationships, here is one big reason you should bother. Build relationships to ensure your message is delivered. This thought popped into my head after seeing an interview with Bono, lead singer of U2. He is a huge advocate to reduce or eliminate the AIDS virus. He has helped raise money and awareness that is dramatically helping the cause. But Bono is not a doctor. He does not work for the Center of Disease Control. He is not trained to do the research, administer tests or provide medicine to patients. What he does do is use his influence to help raise money to support the cause. He uses his influence to convince lawmakers they should allocate funds and resources to support the cause. He delivers the message.

I speak with many BA professionals that get frustrated when they can’t convince their management that they need more focus on the BA practice. I speak with many BA professionals that realize projects are not going well, but are not sure how to get their message to the right person. Sometimes you don’t have the influence necessary to get your message across. Does that mean you should stop? Of course not. You need to detach the message from the delivery of the message. The point is not who delivers the message; the point is that the message gets delivered.

Most likely Bono won’t be stopping by your office anytime soon trying to convince your management that they need to fund your effort to start a Business Analysis Community of Practice. Go out and meet some new people in your company at all levels. Who knows, maybe they’ll be delivering a message for you.

Don’t forget to leave your comments below.

The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

Written by Karl Wiegers on February 21, 2012. Posted in Articles. 2 Comments on The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than whyand means essentially the same thing, but it has a more collaborative feel to it.

When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:

The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
Asking why can reveal implicit requirements that no one thought to mention yet.
The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.

When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.

A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.

(adapted from More about Software Requirements by Karl Wiegers)

Don’t forget to add your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons. Karl produced this article for Enfocussolutions.

The Big BA Picture; A Landscape Without Limits

Written by Mindy Duvernet on November 21, 2011. Posted in Articles. 1 Comment on The Big BA Picture; A Landscape Without Limits

Over the last thirty years the role of the business analyst has become more and more important. While the Project Manager ensures progress, it is the analyst that has been hired to assist with the necessary thinking on behalf of management. Managers have plenty to think about regarding all the projects and goals that affect the business bottom line and their customers. The primary focus of the analyst is to know the business processes and identify possible improvements.

The fact is that while the PMI (Project Management Institute) was founded in 1969 and has more than half a million members worldwide, spanning 185 countries, the IIBA (International Institute of Business Analysis) was established in 2003 and has about 22,000 members worldwide, with chapters in Africa, Asia/Pacific, Canada, Europe/Middle East, Latin American, Caribbean, and the United States. The comparison is telling as the role of the analyst has evolved out of the overwhelming amount of work the Project Manager saw as critical to project success. For the role of the Project Manager is centralized around managing time, budget, and scope. The role of the Business Analyst fills the organization’s need to know and identify goals, objectives, value-adds and measurements for the success of their projects.

The Business Analyst landscape is populated with every kind of business analyst you can imagine. There are:

Business Systems Analysts
Financial Analysts
Enterprise Analysts
IT Coordinator Analysts
Security Analysts
Technical Analysts
Research Analysts
And more

Each industry has its own flavor of analyst. Plus, every company has its own culture with variations of the usual artifacts that their analysts are hired to produce. The uniqueness does not stop there, as every civilization in the world has its own language. As some of us have observed, the non-verbal communication of shaking the head to indicate “Yes” or “No” means one thing in the United States and something else in India.

The entire landscape of analysts is very board. It stretches the breadth of the list of worldwide industries. There is Accidental & Health Insurance, Advertising Agencies, Aerospace/Defense, Agricultural, Air Delivery and Freight Services, Asset Management, Auto Manufacturing and Parts, and that is just the As. Other industries include Biotechology, Broadcasting (TV and Radio), Construction, Computers, Electronics, Energy, Fashion, Finance, Government, Hotel, Internet, Investment, Law Enforcement, Legal, Marketing, Medical, Music, Natural Metals & Materials, Oil & Gas, Pharmaceuticals, Publishing, Research, Retail (Food, Clothes, Toys, Furniture, Appliances), Services, Software, Sports, Wholesale, Wireless, and more. Of all of these industries the three highest profits earners are Money Centers and Banks, Drug Manufacturers, and Oil and Gas industries.

For financial management companies, like Amerprise, there are analysts on both the business side and on the technology side. Like all analysts, these thinkers leverage the organization’s methodologies and frameworks to determine what to utilize in creating the necessary deliverables. It is through thoughtful communication with the project stakeholders that an approach is formed to set the groundwork for accomplishing the results. Alignment with business processes, policies, and procedures is the analyst’s primary concern in the beginning stages of any project.

The next step requires that the analyst talk to all the subject matter experts about goals and objectives. If there is an IT aspect, there would be an analyst from the IT side to discuss automation opportunities based on their knowledge of the software and the technical experts who maintain the systems. The functional solution requirements then begin to take shape as these conversations occur and more information is evoked from the business-side stakeholders. The BA works to identify these IT capabilities and software/web functionality aspects to ensure a common understanding and set expectations.

Independent of organization or culture there is the expectation that the analyst knows the best ways to evoke the value-adds and basic benefits a project will create. Whether that analyst is strictly on the business side and has no interaction with technology, or whether they are a hybrid and have ideas related to technology, these competency distinctions are important to recognize. As many times the problems an analyst often walks into is the result of a business owner purchasing a software package for millions of users without first of all talking to the technology leaders who know their systems.

Recognizing these competencies are key to project success and that is why every team goes through a discussion about roles. On large projects a clear division of who is a business resource analyst and who is the technology resource analyst can help to clarify who has that expert knowledge. These roles are very important to ensure project progress and management when it comes to making decisions.

In this day and age, every company is on the Internet. Internet companies are largely about supply and demand, whether it is “Business to Business”, or “Business to Consumer” these companies employ analysts. Some are Inventory Analysts, others are E-Commerce Analysts, and then there are the Web Analysts that track the Internet activity based on “hits” from endless marketing and advertising efforts. In the Sports industry there is even a new job description known as a Player Analyst; an analyst that looks at athletic statistics of many talented athletes and creates teams based on the players strengths.

Regardless of which side the Business Analyst resides on, both sides are in a continual dialogue about process improvements and new ideas for creating value for their customers. These new ideas then have to be analyzed as part of a business case and then further defined to determine the size of the investment and the risks involved.

Sometimes analysts are instrumental in creating the business case. But, sometimes the analyst is engaged midway on a project or even after the first attempt has failed. If the idea is deemed feasible and the proof-of-concept portrays how the concept will satisfy more customers, which in turn shows the value that will grow the business, then the team is half way there.

An Inquiry, Not an Inquisition

Written by Karl Wiegers on September 27, 2011. Posted in Articles.

The Business Analyst as Explorer, Part 1 of 6 by Karl Wiegers

Many years ago, my manager, Jerry, sat in on a discussion I had with a customer named Steve to explore his requirements for a new application. After the meeting, Jerry pointed out that I had been rather aggressive in my questioning of Steve. He was right. I hadn’t realized how hard I’d been pressing Steve to make up his mind on certain points and tell me exactly what he wanted. Fortunately, when I contacted Steve to apologize, it was clear that he wasn’t offended. Nonetheless, our discussion probably felt like an inquisition to Steve, rather than an inquiry into what he was asking us to build. Not the best strategy for a business analyst to take.

Another extreme approach to requirements elicitation is for the BA simply to record whatever the customer says and pass that information on to the developers. This doesn’t work very well, either. As with most things in life, the appropriate behavior lies in between the possible extremes.

Requirements elicitation is a process of exploration and discovery, not just collection (which is why I don’t talk about “gathering requirements”), and the BA is the guide. BAs need to recognize that customers won’t be able to present all their requirements in a single workshop or discussion. They probably don’t even know what their real requirements are yet. Elicitation requires multiple cycles of refinement, clarification, and adjustment as the participants move back and forth between high-level concepts and specific details.

But First, Some Questions to Avoid

The worst question you can ask during a requirements discussion is “What do you want?” The second-worst question is “What are your requirements?” No one knows quite how to answer these questions. Customers and other elicitation participants might not share the BA’s understanding of what the word “requirement” even means. When customers attempt to answer these questions in good faith, they typically generate a large number of random—yet important—thoughts.

I’ve observed this in some of my training classes, in which small groups of students conduct a practice requirements elicitation workshop on a sample project called the Cafeteria Ordering System. The groups are trying to learn how to employ use cases to explore user requirements. One member of each group plays the role of a user who would employ this system to order meals. Some groups begin by asking this student, “What do you want?” because this is how they’re accustomed to launching requirements discussions. They typically get responses such as:

I need to be able to pay by either credit card or payroll deduction.
I want to be able to order group meals for lunch meetings.
The system has to be available from home as well as from work.
I’ll have to submit delivery instructions for my meals.
I shouldn’t have to pay any delivery charges.
Can contractors order meals or just employees?
I want to be able to order meals at least a week in advance.
It would be nice if I could easily reorder the same meal I ordered sometime in the past.
Could I get nutrition information for a whole meal?

These are unquestionably important thoughts and ideas. However, when asked “What do you want?” the workshop participants tend to spew out these thoughts in a random sequence with no organizing structure. This makes it hard for both the BA and the customers to know what the information means, what to do with it, where to store it, and what to discuss next. The student groups who take this approach invariably flounder in the sea of random input. In contrast, those groups that grasp the use case approach early on make much faster progress. An important BA skill is to structure the dialogue and ask questions that will guide elicitation participants through progressive layers of refinement in an organized fashion.

The BA should remember his role as a neutral facilitator. We all filter what we hear through our own biases, preferences, experiences, and hot button issues. Avoid asking leading questions that steer customers to agree with your own intentions. Also avoid overruling a customer’s idea just because it doesn’t agree with your own point of view. I once observed a 60-participant “voice-of-the-customer” workshop that one of my consulting clients conducted to explore requirements for a major new product. The workshop facilitator was the senior manager responsible for the product. He had strong opinions about the project’s direction and didn’t hesitate to steer the discussion toward his predetermined outcomes. This is discouraging for participants, who will feel that they’re wasting their time if the facilitator already knows what the answers will be.

In the next installment in this series, I’ll explore some questions that are helpful for eliciting business requirements. These requirements define the organization’s business objectives for undertaking the project, define the product vision, and enable scope definition and management.

This series of articles describes some questions a BA might consider asking during elicitation discussions—as well as some to avoid. The articles are adapted from my book More about Software Requirements: Thorny Issues and Practical Advice (Microsoft Press, 2006). A classic resource of good questions for discussing requirements for any type of project is Exploring Requirements: Quality Before Design by Donald Gause and Gerald Weinberg (Dorset House, 1989). Roxanne Miller also suggests hundreds of questions to help the BA with requirements elicitation in her book The Quest for Software Requirements (MavenMark Books, 2009).

Don’t forget to leave your comments below.