Skip to main content

Author: Steve Blais

Down with the Customer

Written by Steve Blais on . Posted in Articles. 1 Comment on Down with the Customer

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”:

  1. “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.
  2. “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.

  1. 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.
  2. 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.

The Human Aspect: A Business Analyst Question

Written by Steve Blais on . Posted in Articles. 1 Comment on The Human Aspect: A Business Analyst Question

There is much to be said about the human element in business success. I’m not referring to the organization and appearance of the user interface or ergonomics designed to make the human being function better with the computer and software systems. I’m referring to the human being as an individual part of the overall business process and how that human being fits into the business, as opposed to fitting into the “system.” There are many ways of describing the human element, most of which seem to emanate from the Human Resources department: morale, fulfillment, self-actualization in one’s employment, work/life balance, and so forth.

Those of us who have spent years in the IT trenches are familiar with the concepts of the “stupid user,” “user error,” “they don’t know what they want,” and the overall consideration that anyone on the other side of the computer terminal is basically nothing more than an extension of the software system we are implementing. Their function is to put data into and extract data from our databases. They are also always a source of unreasonable demands to make the interface easier to use. Fortunately, there is a shift, somewhat prompted by the agile concept of the development team working directly with users, in which the user of the computer systems developed in IT is considered to be more of a human being rather than a functionary in the business organization who needs our technology to do his or her job. When your new system is a website that may be used by the whole world instead of a client server system that is used only by accounts payable, your concept of the user changes dramatically.

So here is my question for business analysts: what is our responsibility toward the human being? Our primary purpose in an organization is to add value to that organization. Business analysts solve problems to improve business processes – increase sales, reduce costs, comply with regulations, increase customer satisfaction with the organization’s products, and so forth. Should we be concerned with how the employee feels about his or her work or how he or she feels about the process? Are we concerned about the employee’s loyalty to the organization? Or is that something that is only the purview of HR?

Is it a function of the business analyst to analyze the work conditions of employees and suggest improvements? If employees are more satisfied with their working conditions and the job they are doing, won’t the organization benefit? Can the business analyst define ways of measuring the increased enjoyment of work or correlating it with increased sales or more efficient processing in the organization? Is part of a process improvement exercise examining the impact process improvement changes have on the individual employee? Should the business analyst evaluate the impact on individuals and suggest alternate courses of action based on that evaluation? Should employees’ health, welfare, happiness, or mental and emotional well-being on the job be of any concern to us while we are defining new systems and solutions?

If a business analyst proposes alterations to the workflow that increase the satisfaction of workers in a business process, won’t the organization benefit from higher productivity? If a business analyst through observation and analysis suggests ways to increase staff’s loyalty to the organization, won’t that increase sales or improve the quality of the organization’s products? Is a happier employee a more productive employee? If the business analyst increases job satisfaction and staff morale, does that not increase the value of the organization, which is the business analyst’s goal?

Considering that business analysts are expert communicators who are able to read body language, apply tact and diplomacy to situations of conflict, negotiate and mediate to successful conclusions, analyze the most difficult situations, think critically about processes and conditions, and apply systems thinking to all aspects of the organization, are we not the best candidates to provide assistance in improving the workplace for individual workers? We are in the workplace gathering information to define requirements for new and improved systems. We view the staff performing their jobs. We hear the complaints and horror stories. We understand the business processes and workflows. Should we also factor in the human elements as we improve the software? Is it untoward or politically threatening for us to recommend changes in the business environment that will improve the employees’ situation?

Or is the business analyst an extension of IT and thus consigned to making improvements in the computer systems and leaving the human concerns to HR?

What do you think? Is it extending the business analyst’s purview too much if we delve into the area of improving the human conditions of the process workers in the organization? Or is observing, analyzing and suggesting human condition improvements a natural progression of the business analyst profession?

The Human Aspect: a Business Analyst Question

Written by Steve Blais on . Posted in Articles.

There is much to be said about the human element in business success. I’m not referring to the organization and appearance of the user interface or ergonomics designed to make the human being function better with the computer and software systems. I’m referring to the human being as an individual part of the overall business processes and how that human being fits into the business, as opposed to fitting into the “system”. There are many ways of describing the human element, most of which seem to emanate from the Human Resources department: morale, fulfillment, self-actualization in one’s employment, work life balance, and so forth.

Those of us who come from years in the IT trenches are familiar with the concepts of “stupid user”, “user error”, “they don’t know what they want”, and the overall consideration that anyone on the other side of the computer terminal is basically an nothing more than an extension of the software system we are implementing. Their function is to put data in and extract data from our databases. And they are always the source of unreasonable demands to make the interface easier to use. Fortunately there is a shift, somewhat prompted by the agile concept of the development team working directly with the users, in which the user of the computer systems we develop in IT, is considered to be more of a human being rather than a functionary in the business organization who needs our technology to do his or her job. When your new system is a website that may be used by the whole world instead of a client server system used only by accounts payable, your concept of the user changes dramatically.

So here is my question for business analysts: what is our responsibility toward the human being in the job?  Our primary purpose in the organization is to add value to that organization. We business analysts solve problems to improve business processes – increase sales, reduce costs, comply with regulations, increase customer satisfaction with the organization’s products, and so forth.  Should we be concerned with how the employee feels about his or her work or how he or she feels about the process? Are we concerned about the employee’s loyalty to the organization?  Or is that something that is only the purview of HR?

Is it a function of the business analyst to analyze the work conditions of the employees and suggest improvements? If employees are more satisfied with their working conditions and the job they are doing will not the organization benefit?  Can the business analyst define ways of measuring or correlating the increased enjoyment of the work with increased sales or more efficient processing in the organization?

Is part of a process improvement exercise the impact the process improvement changes have on the individual employee? Should the business analyst evaluate the impacts on the individuals and suggest alternate courses of action based on that evaluation?  Should the employee’s health, welfare, happiness, or mental and emotional well being on the job be of any concern to us while we are defining new systems and solutions?

If a business analyst proposes alterations to the workflow that increase the satisfaction of the workers in a business process won’t the organization benefit with higher productivity? If a business analyst through observation and analysis suggests ways to increase the loyalty of the staff to the organization won’t that increase sales or improve the quality of the organization’s products?  Is a happier employee a more productive employee? If the business analyst is increasing job satisfaction and staff morale, is that not increasing the value of the organization, the business analyst’s goal?

Considering that business analysts are expert communicators, able to read body language, apply tact and diplomacy to situations of conflict, negotiate and mediate to successful conclusions, analyze the most difficult situations, think critically about processes and conditions and apply systems thinking to all aspects of the organization, are we not the best candidates to provide assistance in improving the workplace for the individual workers?  We are in the workplace gathering information to define requirements for new and improved systems. We view the staff performing their jobs. We hear the complaints and horror stories.  We understand the business processes and workflows.  Should we also factor in the human elements as we improve the software?  Is it untoward or politically threatening for us to recommend changed in the business environment that will improve the lot of the employee?

Or is the business analyst an extension of IT and consigned to making improvements in the computer systems and leaving the human concerns to HR?

What do you think?  Is it extending the business analyst’s purview too much if we delve into the area of improving the human conditions of the process workers in the organization? Or is observing, analyzing and suggesting human condition improvements a natural progression of the business analyst profession?

Don’t forget to leave your comments below.

 

The Lexicon of Solutions

Written by Steve Blais on . Posted in Articles. 1 Comment on The Lexicon of Solutions

My contention that a business analyst produces a solution in the form of a set of requirements or product backlog or user stories has met with some resistance. Not with the concept, but with the word. I’ve even taken to labeling any description of what needs to be done – business requirements document, set of use cases., desk of user stories, items on a product backlog, etc., a “solution document” as a catch-all phrase to suggest that all forms of rendering produce the same results.  Apparently many feel that there is only one solution and that is the implemented software delivered into production, and any suggestion that a business analyst might be creating a “solution” will be met with rancor and ridicule from the technical forces that produce the implemented solution.

Having been there (on both sides) I agree that stepping across that technical boundary is risky for a business analyst.  That boundary exists at the meeting of the What Domain and the How Domain.  Business analysts, even though a great many of them come from the ranks of system analysts and other technical roles, are not supposed to know or care how the solution is implemented. And, again, I agree with that.  Worrying about the technical implementation tends to skew a valid business solution in the wrong way.

However, back to the word.  Does the business analyst produce a solution?  Well, let’s look at the definition: “The act of solving a problem or question”.  Certainly a business analyst solves the business problem presented; however, there is still the question of whether a document is a solution.  So how about another two definitions: “a particular instance or method of solving”, or “a specific answer or way of answer a problem”. The business analyst does produce a solution according to either definition.   So while choice of word might be correct, there is the issue of conflict with the solution team who may claim sole possession of the solution.

The word is not important. What is important is the concept that the business analyst delivers a whole response to the business problem. I believe that all sides of the discussion agree that the business analyst must define the real problem and make sure that everyone is in agreement with the problem statement.  This is not always done and many times when the business analyst does define the problem, the results are set aside as part of some early document like a business case or project charter and assumed to have existed solely to get the project going. After that the only thing that matters is the requirements. And this is where the trouble starts.

Many times the business analyst does a fine job of eliciting the needs, wants, and BS (Blue Sky) from the customers, users, and other stakeholders. The business analyst concocts a fine list of these requirements, perhaps even prioritized.  The list is confirmed and verified by the stakeholders and passed on to the solution team. Only when the solution is near implementation, or even after implementation, is there a concern with whether all the actionable elements of the list add up to a valid, complete, accurate and usable solution to the stated problem.

I’m suggesting that there is a word, perhaps other than “solution” that will remind the business analyst that their goal is to solve the business problem, and the requirements documents the solution as much as an architect’s models and renderings document the architect’s solution to a home owner’s desires.

I considered “diagnosis”, which I mention in an earlier blog posting on BA Times, since the definition of diagnosis is “a determining or analysis of the cause or nature of a problem or situation”, or “an answer or solution to a problematic situation”.  While the definitions fit, the common interpretation of “diagnosis” is associated with medical procedures so it doesn’t extend very well to business problems.

Another possible metaphor for the requirements that I’ve heard is blueprint.  In addition to its definition as a mechanical drawing device the definition of blueprint also is “an original plan or prototype that influences subsequent design or practice”. Again the definition fits what we business analysts are trying to do, but the inference drawn from the word is much more technical than may be acceptable, especially to the solution team.

So, if we are going to have a problem with the word solution, then what word can we use to more accurately describe what it is that a business analyst produces, if not a business solution to the business problem?  Any ideas?

Don’t forget to leave your comments below.

Stop Gathering Requirements

Written by Steve Blais on . Posted in Articles. 1 Comment on Stop Gathering Requirements

The common response by a business analyst when asked to describe his or her primary activity is “I gather requirements”.  Management tells business analysts when assigning them the next problem to solve:  “Go gather the requirements”.  This is unfortunate.  Let’s examine what one would do if one were truly to “gather requirements”.

As a business analyst gathering requirements, I grab a basket or some suitable container in which to place the requirements I gather (one needs a basket to put things that are gathered).  I go to the business community and ask them to give us the requirements.  I collect the requirements and then transcribe them as carefully as possible, recording them word for word, onto the organization-prescribed template – a Requirements Document.  I then take the Requirements Document back to the stakeholders to make sure we transcribed the requirements correctly.  The stakeholders may add some new requirements or change some of those they had previously given us which I dutifully transcribe into the Requirements Document.  Then I take the Requirements Document to an authority that approves it.  Having obtained the approval, I turn the Requirements Document over to the solution team and my job is done.

The concept of “gathering requirements” comes from a basic premise:  there are requirements out there someplace that the business analyst has to find.  This means that users or stakeholders have the requirements to be gathered in the first place.  Do users or stakeholders really have requirements?

Users Don’t Have Requirements

That’s right, users don’t have requirements.  Nor do stakeholders.  Nor does anyone in the business.

The job of the user is not to create requirements for us.  The job of users of a system is to sell more product, book orders, enter payables vouchers, or produce payroll.  Even if they were assigned by their manager to take a few weeks off the production line and write up some requirements, they are not trained or skilled in the job of writing requirements.  However, the business analyst is.

Some organizations attempt to make defining requirements the job of the business.  Here are reasons why that approach won’t necessarily work:

  • Users are focused on their own jobs.  They see the business, problem and solution from the perspective of their part of the business process.
  • The best user for the job of explaining issues may not be the one given the assignment to write requirements.
  • Users don’t know what IT wants – they don’t know what requirements are.  For example, they may not know what non-functional requirements are and/or how to express them.
  • Users may not want to commit to a specific requirement or set of requirements for fear they will be held responsible for those requirements and may give us vague or ambiguous statements if anything at all.
  • Users don’t know what is available technologically.
  • Users may not be able to visualize the solution because they are too close to the problem or simply cannot see it.
  • Users are not aware of the overall implications of what they ask for and are likely to specify requirements that conflict.
  • When asked for their requirements, users feel obligated to specify something whether it is pertinent, useful, required, incidental or non-germane.

So where do requirements come from?  They are analyzed into existence.  Requirements are defined or created by the business analyst.  The business analyst’s job is to define the solution to a business problem.  The requirements document is the representation of the complete and accurate statement of what must be done to solve the business problem.  Requirements are a business analyst’s job, not to gather, but to create.

Gather Information, Not Requirements

So if users don’t have requirements, what do they have?  They have information.  They provide us with relevant information:  how they do their job, what they would like to work differently, what a solution may look like, why they perceive there is a problem, what a solution will mean to them, who else may be impacted by the problem or solution.  They can describe the business problem, define the problem domain, identify conditions that cause the problem, and tell us which solutions are preferable.

What do we gather?  Not requirements.  We gather information.

It is from this skillfully elicited information that we, the business analysts, derive and define the solution to the business problem and we write this solution as a set of requirements.  These requirements state completely and accurately what must be done to solve the problem.  We analyze the information to deduce the solution.

The goal of the elicitation phase of the business analyst solution cycle is to gather information, not requirements.  Whoever gathers the most information wins.

What’s in a Word?

There is more to this than just changing our language and using a new catch phrase.  We also change our expectations by doing so.  We assume users really don’t know what they want and make it our job to help them determine the solution to their business problem.  As Steve McConnell says, “The most difficult part of requirements gathering is not the act of recording what users want; it is helping users figure out what they want.”

The interesting aspect of this change to our vocabulary is that we improve our ability to elicit pertinent information, information that will lead us to the solution.  When we expect users to have requirements, we ask questions focused on “What do you want (or need)?”

When we assume users do not have requirements and defining requirements is our responsibility not theirs, we begin to realize that we need a bigger and better view of the problem:  a domain view, one that allows us to gain business insight and knowledge of what is going on with the business process.  At that point, our line of questioning changes to:

  • “How do you do what you do?” How do you perform your tasks?
  • “What information do you need to do your job?  Where do you get it? What do you do with it?”
  • “What don’t you like about the current process?”
  • “How do you know…?”
  • “Where does the information you use come from, and where does it go when you finish with it?”
  • “What happens if we don’t solve this problem?”

We will also find that we might expand our elicitation focus away from the one Subject Matter Expert (SME) who “has the requirements” to a number of stakeholders who work in the business process so that we can confirm the information we have received and so that we can get different perspectives.  We might also find we want to spend some time observing the business process to further understand what is needed and what conditions exist that are causing the problem, in other words, what must be changed to solve the problem.

And when we are not collecting requirements from stakeholders, we are forced to do the job we are being paid to do:  analyze.  When requirements are only the result of analysis, we are not tempted to simply copy requirements statements received from stakeholders into our requirements document.  We are more likely to spend time verifying information, distilling it down to its essence, eliminating requests that do not contribute to the solution, identifying additional questions that need to be asked of stakeholders, reconciling conflicting information, and so forth.

Though we are defining requirements, the business community still has to agree to the solution.  Stakeholders are going to be using the solution in their day-to-day operations long after we have gone on to solve other problems.  As we are defining their solution we are going to confirm requirements with those who are affected by the changes in their processes.  We inculcate a partnership with stakeholders:  they provide the information; we do the analysis and produce a solution; they confirm the solution will work for them (or provide additional or revised information so we can come up with a new solution).  It is an iterative process that requires the business analyst to establish a good relationship with the user community so that there is no problem when the business analyst shows up in user’s office for the seventh time, Columbo style, to ask just one more question.

Removing the Obstacles

Will changing our thinking about gathering requirements really improve our requirements process?  Consider that if users don’t have requirements, they can’t change requirements.  They can only change information.  I don’t think anyone would have a problem with changing information.

When users don’t have requirements, then there is no single user we have to find to give us requirements.  We are no longer subject to locating “the right person with the right requirements”.  We can focus on information rather than individuals.

When all users have is information, then they are not giving us solutions, they are giving us information that we may or may not use to define the requirements.

“Changing customers and users” means only that the information changes not requirements (unless you choose to alter them).  We do not need to have “technically sophisticated users” when users are not supplying us with requirements.  We do not need users to “articulate their requirements”, just what they need to make their jobs easier or better.  We do not need users to “understand the big picture”; it is our job to put together the big picture from the information users give us.

Get the facts first.  You can distort them later – Mark Twain

There’s another subtle benefit when you gather information instead of requirements:  increased confidence and better relationships with the business community.  Users may have trouble defining requirements for you because of the criticality that such definitions have.  No one has trouble describing what they do for a living.  Users can identify what they like and do not like about the current process.  And, as they describe the current process and what they would like to see to make it better, they will gain confidence in you because you are listening to them.  You understand their situation first, then you analyze the information and come back with the solution.  When you return for their confirmation, they realize that you are listening to them and are truly interested in solving their problem.

Here’s one last tip.  As business analyst you are defining the solution to the problem as a set of requirements.  Basically you own the requirements.  That is, you are fully responsible for their accuracy and currency.  It is your job to make sure you have not included your own assumptions and so forth.  However, throughout the process refer to the solution as theirs.  Requirements define the solution to the business’ problem.  The requirements document that describes the solution belongs to the business analyst; the solution belongs to the business.  When you refer to the solution as belonging to the business community, they will take possession of it and participate more fully in its development.

Changes in Platitudes, Changes in Attitudes

It is not only a matter of changing a word or two in our process definition:  it is a matter of changing how we go about our job, too.  As Dr. Stephen Covey says, “Seek first to understand, then to be understood.”  Gather information and analyze that information into requirements.  The more information you get, the better your analysis will be.  The better your analysis, the better your solution will be.  And when we change our expectations and attitude, the stakeholders change theirs as well.

It is a good feeling to end an information gathering session with a group of stakeholders and have them say to you “Good session.  When will you be back with our requirements?”  And even better to have them say, “When you do what you have described in these requirements, our problem will be solved.  Thank you!”

Don’t forget to leave your comments below.