Tag: Skills

Use Case Preconditions: A Best-Kept Secret?

Written by Willem Van Galen on October 16, 2012. Posted in Articles.

Introduction

Alistair Cockburn opened my eyes to the essence, elegance and effectiveness of use case preconditions. In [1], he discusses preconditions in just a dozen paragraphs, but these contain two statements that revolutionized my understanding of preconditions and their counterpart, postconditions.

This article starts with those statements, illustrates what I believe they imply, outlines key fundamentals, discusses how preconditions and postconditions reflect sequential use case dependencies and promote loose coupling between use cases, and ends with a reflection on enforcing preconditions.

Based on personal experience, as well as a cursory check of the Internet, use case preconditions still seem to be a best-kept secret. This article is intended to help change that.

Bless you, Alistair

Odd as it seems in retrospect, until I read Alistair Cockburn’s inspiring book [1], use case preconditions were in my blind spot. That changed with two statements at the start of the book’s chapter 6:

“[A use case’s preconditions indicate] what the system will ensure is true before letting the use case start.”*
“Generally, a precondition indicates that some other use case has already run to set it up.”

After reading these two statements, the clouds parted, an angelic chorus hummed a mystical chord, and a bright eco-friendly light bulb appeared above my head; I had discovered a nugget in Alistair’s gold mine of a book.

* A use case’s postconditions indicate what will be true after the use case finishes.

A picture tells the story

The next diagram illustrates the use of preconditions, using a simplified example.

This diagram reflects the preceding two statements in that:

A user can only initiate a use case when the system has concluded that the use case’s preconditions are true.
A use case’s preconditions result from executing one or more other use cases.

If we imagine a corresponding user interface, the function button that corresponds to a particular use case is enabled (a user can click on it) when the use case’s preconditions are all true, and disabled (grayed out) when at least one of the preconditions is false.

Another way to view this is as part of a “no false hope” strategy. A user is not given the impression that he can complete a certain function use case he can’t (i.e., if the conditions had been enforced as part of the use case instead of as preconditions, and at least one turned out to be false).

Some fundamentals

This section is based on [1] and on personal experience.

A use case’s preconditions can only exist within the system

Since a use case’s preconditions are enforced by “the system,” they can only exist within that system, which wouldn’t be able to detect them otherwise. A use case precondition cannot refer to a condition in the physical world that isn’t represented within the system.

The reflection at the end of this article shows that when it comes to enforcing preconditions, “the system” in its broadest sense refers to “the systems environment.”

A use case’s preconditions are the same for all its scenarios

Since a use case’s preconditions are true before the use case starts, it follows that they apply to whatever scenario* unfolds during an execution of the use case. This is one reason for not bundling multiple user functions into one use case (e.g., bundling Create, Read, Update and Delete functions into a Maintain use case), for they typically have different preconditions (and postconditions).**

* A scenario is a possible path through a use case.

** Moreover, it’s impossible to show in a use case diagram differences in user authorization; if one role (actor) is authorized to initiate one set of the bundled functions and another role (actor) is authorized to initiate a different set.

A use case doesn’t check its preconditions

Since a use case’s preconditions are “enforced by the system and known to be true” by the time the system allows the use case to start, they are “not checked again during the use case’s execution.” This is why:

Preconditions are also called assumptions (a use case assumes they’re true).
There is no need to write use case steps that check preconditions (doing so would miss the point of using preconditions).

Being mindful of these fundamentals yields clear preconditions and use case flows.

Of use case dependencies

Sequential dependencies

A use case precondition reflects a sequential dependency between use cases.

Use case B with precondition C can only start after use case A has produced C as a postcondition.
Use case B is executed after use case A; their connection is asynchronous.

Functional dependencies

In contrast, an include relationship (and a directed association as well) reflects a functional dependency between use cases.

When use case A has an include relationship (or a directed association) to use case B, it means that the functionality of use case B is part of the overall functionality of use case A.
Use case B is executed as part of use case A; their connection is synchronous.

Impact on use case models

This difference means it’s incorrect to use a functional relationship to represent a sequential dependency between two use cases—instead, use postconditions and preconditions. This is summarized in the diagram below for include relationships, using a simplified example.

Conditions enable loosely coupled use cases

What is loose coupling again?

Two use cases are loosely coupled when:

The execution of the first enables the execution of the second.
Neither has any knowledge of the other.

Kinds of loose coupling

One kind of loose coupling—between publisher and subscriber use cases connected via event objects and an event manager — is outlined in [2].

A different kind of loose coupling—between upstream and downstream use cases connected via conditions and user actions — is addressed in this section.

Point 1: Function use cases enable function use cases

In the above diagrams, postconditions produced by the execution of one or more upstream use cases enable the execution of one or more downstream use cases.

As soon as a downstream use case’s preconditions are all true (i.e., they reflect postconditions produced by the execution of one or more upstream use cases), a user can initiate the downstream use case.

Point 2: Function use cases don’t know each other

In the above diagrams, upstream and downstream use cases don’t know each other.

An upstream use case doesn’t know which downstream use cases a user can initiate next. It doesn’t pass control to any of them. It only produces certain postconditions.
A downstream use case doesn’t know which upstream use cases a user initiated previously. It doesn’t accept control from any of them. If initiated by the user, it trusts that its preconditions are true, no matter which use cases produced them.

Actions outside function use cases

As noted earlier, in a use case model the system is understood to take actions outside use cases, for example by ensuring that a use case’s preconditions are true before allowing the use case to start. Similarly, a user can take actions outside function use cases, for example by selecting an object from a list before initiating another use case.

As setup for an example of the latter, assume that:

The personal banking website from the first diagram also has function use cases View Accounts Summary, View Account Transactions, View Account Details and Change Account Details.
The postcondition of the customer-centric View Accounts Summary use case is “The user is presented with a summary of the customer’s accounts.”
A precondition of the three account-centric use cases is “The account has been identified.”

An implied user action is the selection of an account from the list of accounts presented by the View Accounts Summary use case. This selection, not the use case, creates the precondition for the three account-centric use cases.

This user action is implied because it is not part of any of the use cases.

Adding it as the final step of the View Accounts Summary use case would make the use case overshoot the user’s goal, which is to view the accounts summary.
Adding it as the first step of the account-centric use cases would make using the above precondition impossible and thus undermine the loose coupling between these use cases and the customer-centric one.

The implied system and user actions must be accommodated in the user interface derived from the use case model.

Tip: Don’t state who (an actor) or what (a use case) produced a precondition.

Stating an actor introduces irrelevant, distracting and potentially misleading assumptions (what if the use case model is enhanced with a new actor who can also produce the precondition?)
Stating a use case violates the principle that loosely coupled use cases don’t know about each other (and what if the use case model is enhanced with a new use case that can also produce the precondition?).

The condition is what matters, not how it came to be.

Benefits

Loose coupling between use cases in general:

Inherently leads to use case models that are easy to create, understand and evolve.

Loose coupling between function use cases in particular:

Enables analysts to produce use case models without built-in assumptions about the corresponding user interface (e.g., the sequence in which functions get presented).
Gives user interface designers the greatest freedom in designing that user interface (e.g., a given function may be launched from multiple screens that each in its own way ensures that the preconditions of the corresponding function use case are met).
Allows user interface designers to restructure an existing user interface without the need to change the corresponding use case model (e.g., moving function buttons around but adding no new functions).

Using conditions and user actions to model loosely coupled function use cases results in a highly modularized use case model whose function use cases are:

Context-aware (aware of their preconditions, but not of other use cases).
Single-purpose (because defining one set of preconditions for multiple purposes usually doesn’t work).
Lean (because they are single-purpose and their preconditions are assumed).

When a system is modeled like this, it truly reflects the notion that the use cases represent the system’s operations, as mentioned in [3], because each use case represents a distinct capability the system provides to its users.

Preconditions for other use case types

The preceding deals with function use cases, but preconditions and postconditions can be used for the following use case types as well.

Batch process (<>) use case. As for a function use case, the preconditions reflect the use case’s sequential dependency on one or more other use cases.
Subscriber service (<>) use case. As outlined in [2], use cases of this type are inherently modeled to be initiated by the event manager, and so they assume the event manager as their context. This means they have a standard set of preconditions (see [2]).

What enforces use case preconditions?

It’s one thing to state that the system ensures a use case’s preconditions are true before allowing the use case to start, but in a logical use case model it is typically implied that the controller is part of the system.

For a comprehensive understanding of controllers, we have to consider the physical implementation realm as well. The following table summarizes typical controllers and, relating the physical to the logical, the types of use case they control.

This summary shows that the enforcer of a use case’s preconditions isn’t necessarily part of the system to which the use case applies, so in the broadest sense “the system” means the systems environment when it comes to enforcing preconditions.

In conclusion

If you’re new to use case preconditions, I hope this article has whetted your appetite for them. If you’ve used preconditions before, I trust this article reconfirmed their usefulness and maybe even added a new angle. Preconditions certainly aren’t the only gold nugget in [1], and perhaps there’ll be opportunity to reflect on others.

Don’t forget to leave your comments below.

References

[1] Alistair Cockburn, Writing Effective Use Cases, 12^th Printing, November 2004.

[2] Willem Van Galen, Modeling Loosely Coupled Use Cases, 30 April 2012, http://www.batimes.com/articles/modeling-loosely-coupled-use-cases.html.

[3] Willem Van Galen, The System: Don’t Model A Use Case Without It!, 11 September 2012, http://www.batimes.com/articles/the-system-dont-model-a-use-case-without-it.html.

The Structure of Business Analysis Documents

Written by Sergey Korban on May 7, 2012. Posted in Articles. 74 Comments on The Structure of Business Analysis Documents

The structure of business analysis documents isn’t a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.

These are the main documents produced by a BA over the course of a project:

Current state analysis document
Project vision document
Solution vision document
Business requirements document
Business process design document
Use case model document
Use case specification document
System-wide requirements document
Solution glossary

The diagram below shows the attributes common to all documents:

Current State Analysis

Once a project has been mandated and the Project Initiation document (PID) is drafted, a business analyst can start to work on requirements gathering. In my experience the best way to tackle this task is to start from current state analysis. It helps understand the business need, primary pain points, business processes affected, the stakeholders involved in these processes, and so on.

The area of the current state analysis is illustrated below:

The main purpose of the analysis is to present the “AS IS” state: the existing business context, background, business functions and existing business processes, and finally stakeholders involved in these business processes. Depending on the project nature, some components of the underlying infrastructure can be included in the document as well.

A Current State Analysis document lists the key pain points within the identified business processes and tasks within them, and highlights the areas where a change is expected.

The last section of the document is about presenting recommendations. It recaps the key findings and lists the key changes expected. Any caveats should be presented here as well.

The content structure of the Current State Analysis document is presented below:

This document serves as a foundation or a reference point for other artifacts produced by a business analyst. The other documents will be discussed in the following articles.

Project Vision

The Project Vision is a document which is shared by a project manager and business analyst. They work together to outline the problem statement, determine the desired state, describe the criteria of business acceptance of the deliverables and how project success will be measured. The document contains a section with stakeholder analysis which shows all the parties involved along with their responsibilities and needs:

The business analyst adds the high level requirements which are within the scope of the project, and marks each requirement as compulsory or optional. To clearly define the project scope and avoid ambiguity, all out-of-scope requirements are also listed at the end of the section.

Based on the results of the current state analysis the business analyst describes the current business context, the key business processes and services used to support them. After that the required changes are mapped to the current business context. It can be a good idea to present this mapping as a diagram for easy communication of the proposed changes to the business stakeholders.

Solution Vision

Once the Project Vision document is approved, the preparation of the Solution Vision document starts.

First, the business analyst recaps the problem statement from the Project Vision artifact. The solution statement describes the target audience of the solution, what will be satisfied by the solution and what the key benefits will be. The statement of differentiation of the solution from possible alternative options is added as a conclusive point in positioning of the solution.

The document describes stakeholders within the target audience along with their roles using a RACI matrix.

The main part of a Solution Vision is a detailed section devoted to the solution capabilities comprised of both functional and non-functional features, with priorities given by the business stakeholders.

The next section presents the business context in its future “to be” state. It’s a good idea to include a a diagram illustrating the key changes and additions to the existing state, as well as a brief narrative to clarify the proposed changes.

Similarly to the Project Vision document, the features that are out of scope are clearly listedin the last section to make sure everyone is on the same page with regards to what will be implemented.

Business Requirements

This document focuses on providing details about the current processes and gives enough information to describe the business problem and how it fits into the scope of the project. This section reiterates the findings of the Current State Analysis document, however here they are aligned with the project objectives.

The business requirements that are going to be fulfilled by the solution are listed in the “In Scope” section. Business rules that apply to the described requirements are presented in a separate section. This approach simplifies the confirmation of the rules with business stakeholders.
Any assumptions and dependencies identified in relation to the business requirements are to be listed in the appropriate section.
The proposed changes to stakeholder roles, new or modified business processes and business services that support them are presented in the last section.

Business Process Design

This document focuses on the scope of changes to business processes, providing details about the current business context, existing business processes, and stakeholders involved in these business processes.

It also describes the future state: the proposed business processes and the “to be” information environment. The new processes are accompanied with narratives to facilitate communication of the proposed changes to stakeholders and business end users. This “as is” section reiterates the findings of the Current State Analysis document, however here they are aligned with the changes to supporting business services.
Any assumptions and dependencies identified in relation to changes to the business processes are listed in the appropriate section.

Use Case Model

The Use Case Model lists all the scenarios for using the solution required by the business stakeholders. It is useful to describe the solution as a set of functional areas and group the scenarios per functional area. Such an approach allows to use this document more efficiently in communication with the business stakeholders as they can easily refer to the sections of their interest.

The model lists all possible scenarios in scope, their brief summary, actors involved in each scenario, frequency of use, triggering events and the two possible outcomes – success and failure.
One of the key attributes of the scenarios is a reference to the high-level requirements and required capabilities which allows to establish traceability.
Note: when making changes to Use Case Specifications, do not forget to update the Use Case Model document accordingly.

Use Case Specification

A Use Case Specification document presents more detailed information about the use cases in the Use Case Model document.

Each specification includes:

Brief use case overview
Reference to the functional area
Preconditions
Actors involved
Main flow
Alternative flows
Exception handling flows
Functional requirements for the solution
Traceability to the business requirements
Market or business rules applicable to the scenario
User interface, controls and data

System-Wide Requirements

This document is prepared when the Business Requirements, Use Case Model and Use Case Specifications are complete. The main purpose of the document is to present a “qualitative” side of the solution.

The “Load patterns” section is the most interesting as it illustrates how the solution is expected to be used during a business day. This information gives good insight into business requirements from the “non-functional” perspective and helps clarify the business requirements where required.As solutions are often based on information technology, some attention should be given to solution resilience. Disaster mitigation approaches and solution recovery requirements play a major role here.It is a rare case nowadays that a solution is completely new. The common practice is to integrate the solution into the existing business environment. The system-wide requirements document describes the interfaces with internal and external systems and solutions, the data flowing between them, its formats and data elements. Where the solution should interface with external systems, samples of data must be presented in appendices.Apart from business reporting capabilities, the solution must provide reporting capabilities for monitoring how the solution operates. These reports are listed in the last section of the document.

Solution Glossary

Business stakeholders often use terms and jargon in their communication. To get up to speed with this terminology (you can be quite new to it), the Solution Glossary document is used. It helps establish common terminology for the project team and key stakeholders, and for use within the solution. The structure of this document is simple:

It’s a good practice to divide the solution into functional areas. These functional areas serve as small knowledge domains for the stakeholders involved in the project. This document serves as a reference point for all the previously discussed documents.

Don’t forget to add your comments below.

Five Ways to Know When You’re Done with What You’re Doing

Written by Jason Womack on March 26, 2012. Posted in Articles.

If you often feel like you’ve barely skimmed the surface of what you should have accomplished on a given workday, I have a secret for you. When you learn to “know when you’re done” with projects, tasks and everything the workday throws at you, you’ll free up a lot more time to focus on those things that truly matter.

The curse for many of us modern-day movers and shakers is that we never seem to have enough time to do everything that needs doing. There simply aren’t enough hours in the workday (or even the work week!) to accomplish everything on our to-do lists. Worse yet, when we finally do get on a productivity roll, there always seems to be a distraction (or two, or three) waiting in the wings to throw us off course. But the reality is that we could actually accomplish a lot more each day if we would just learn to recognize and acknowledge when we’re done with what we’re doing.

One of the biggest time wasters we all face is spending too much time on those things that don’t require it. When we do so, we lose the time we actually should be spending on more difficult or time-intensive tasks. But when you learn to recognize when you’re done with a task, you’ll have valuable minutes and maybe even hours added back into your day.

It often seems that we put off the most important things on our to-do lists until we feel like we have the ‘time’ to work on them. When you learn to recognize when you’re done with projects, big and small, you’ll immediately find that you have a lot more time than you thought you did. Time you can use to focus on those things that truly matter. Read on to learn more about how to know when you’re done:

Stop majoring in the minors. Many of us spend a lot of time on those projects and tasks that are easy for us. Then we convince ourselves that we “just didn’t have enough time” to get to the harder stuff. But when it comes to knowing when you’re done and freeing up time during your day, completing these easy tasks quickly and efficiently is essential.

Before you start your workday, think about what your high-leverage activities are and what your low-leverage activities are. For the low-leverage activities, force yourself to move through them as quickly as possible. With these tasks — for example, writing an email to a colleague — perfection isn’t necessary, and there’s no need to waste time wringing your hands over every word. When you can accomplish these minor tasks more efficiently, you’ll have the time you need to do those major tasks justice.

Don’t overwrite emails. Much of your time — probably too much — each day gets eaten up by email. Make a conscious effort to keep your emails as short and sweet as possible. Get to the point quickly and use action verbs in subject lines so that both you and the recipient know what needs to happen before the email is even opened. And while long emails waste the time it takes you to write them, keep in mind that the person receiving the email doesn’t want to have to spend so much time reading it either. Chances are your boss doesn’t want or need a three-paragraph rundown of how your client meeting went. He just wants to know if the client is happy and continuing business with you.

Quit over-staying at meetings and on conference calls. Often, meetings and conference calls will take as long as you’ve allotted for them. Set an hour for a meeting and you’re sure to go the full hour. Pay close attention to how much of your meeting is actually spent focused on the important stuff. If you spend 15 to 20 minutes at the beginning or end of the meeting discussing your coworker’s golf game, then next time reduce the amount of time allotted for the meeting. And always know the meeting’s or call’s objectives before you begin. That way you can get to them right away.

Set your own deadlines and stick to them. It’s very easy to get distracted or sidetracked by things you think you should do or things others think you should do. Having a self-imposed deadline will help you ignore those distractions. If a colleague calls you about a non-urgent task, you can let him know you’ve got a 3:00 p.m. deadline that you have to meet. There’s no need for him to know that it’s self-imposed! And then as 3:00 p.m. draws near, start wrapping up that particular task.

Know when it’s time to ask for help. Have you ever been stumped by a certain project or task? Did you walk away from it for a while and then come back to it hoping you’d suddenly know what to do? Sometimes knowing when you’re done is knowing when you, specifically, can’t take a project any further. You simply might not have the right expertise to finish a certain project completely. And that’s okay. Wasting time on something you’re never going to be able to figure out is much worse than asking for help!

When you put in place steps to help you know when you’re done, you’ll be surprised and pleased with how much, well, you can get done. It will truly free up time in your day that you can use to focus on areas where it’s really needed. As a result, you’ll have a more gratifying workday and you’ll be happier overall.

Don’t forget to leave your comments below.

Jason W. Womack, MEd, MA, provides practical methods to maximize tools, systems and processes to achieve quality work/life balance. He has worked with leaders and executives for over 16 years in the business and education sectors. His focus is on creating ideas that matter and implementing solutions that are valuable to organizations and the individuals in those organizations.

Author of Your Best Just Got Better: Work Smarter, Think Bigger, Make More, Jason shows that working longer hours doesn’t make up for a flawed approach to productivity and performance. Entrepreneurs need to clarify their habits, build mindset-based strategies and be proactive. Womack’s signature workplace performance techniques offer specific strategies to improve performance consistently and incrementally.

The Missing Link to BA Competency Development

Written by Angela Wick on March 19, 2012. Posted in Articles. 1 Comment on The Missing Link to BA Competency Development

When I think about what it takes for BAs to be successful, it always comes down to the same thing: Using hard skills and soft skills together strategically to get results and engagement from stakeholders. When I think about what it takes to execute on any BA activity or technique and to be good at it, it is rare to find a scenario when both hard skills and soft skills are not needed. This may not be new to anyone as underlying competencies (many of which are soft skills) are foundational to performing the various BA tasks. Where we fall down on this is in executing this concept well in a variety of situations and complexity levels and showing the path to truly deepen these competencies.

Why is it that we rarely look at the path to developing skills in underlying competencies in the context of BA tasks and techniques? Or when they require an elevated and advanced level of complexity to execute well?

I would like to look more closely at these skills in additional dimensions.

For example: It is easy for someone to say they have been trained in facilitation, and may have some successes and good experiences in facilitation, and therefore they feel they are a great facilitator. But what does it really mean to be a great facilitator? Are those learned skills and experiences really enough to succeed in new and more complex situations? Would they really be successful in facilitating a highly complex topic while working to build consensus with a group of executives?

A BA organizes and facilitates a meeting with a group of stakeholders to review the future state of a business process. The process flow being reviewed was technically correct and the facilitation methods, tone and techniques were flawlessly used. However, the meeting still failed to achieve a desired goal of reaching consensus from a group of executives on the future vision of the business process.

What happened?

This was an opportunity to strategically use the skills of facilitation and process modelling together aligned to the purpose of the meeting. In this example, what gets missed is thinking about the goals and purpose of the meeting as well as the audience, and thinking about how to use these hard and soft skills strategically for the purpose. In many cases like the scenario above, the process flow and meeting planning were thought of as needed together, but not strategically planned and executed together; they were performed as separate tasks in the same meeting. There is an opportunity for the meeting goals, agenda, and expected participation to drive the level of detail that the process flow is presented at. The review and discussion, along with expectation setting with the participants on the level of detail is critical to the success of the meeting. This was a missed opportunity to engage executives in the facilitation techniques used by modelling at a higher level appropriate to the ways they engage.

The soft skills needed to be a great business analyst are difficult to develop. It is hard to find resources, mentoring, etc. that really help develop these skills in the context of being a BA in a variety of contexts, situations and different stakeholder groups.

We hear from our leaders about how important soft skills are, and are usually trained on them separately from BA tasks, activities and techniques. It can be a challenge to apply what is learned to the BA context. Rarely do we discuss or hear about leveraging them together. This makes it difficult to grow and apply the skills and build awareness of when to use soft skills. Some would say it is intuition, and either you have it or you don’t. I believe there is some truth to that, but that much can be learned through developing experience and awareness.

My callout to the leaders of BAs:

Give mentoring and feedback that shows the context and linkage of soft skills and hard skills together to your BAs in the context of business analysis. Help your BAs build an awareness of situational complexities.

My callout to BAs:

Seek feedback in specific situations on a variety of soft skills and how the situation and tactical activity could be improved through soft skills.

Focus more on developing these skills together and seeking feedback on how we use these skills together.

Truly bringing tactical and influence skills together by thinking differently about how we plan and execute our BA activities and technique usage is key to developing strong competencies as a BA.

What are your thoughts and examples of how BAs can leverage tactical hard skills with influential soft skills?

Don’t forget to leave your comments below.

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.