Skip to main content

Author: Steve Blais

Managing Expectations: The Politics of Success Factors

Written by Steve Blais on . Posted in Articles.

Blais FeatureArticle Nov27Critical Success Factors (CSFs) are those outcomes that the project needs to deliver so that everyone appraising the project will agree that it is successful, at least in terms of delivery. (A critical success factor may be the time of delivery.) We define the primary critical success factors by defining the real problem, the vision, and the acceptance criteria.

There are also those aspects of the project that are assessed by individuals or groups within the stakeholder community. These individual stakeholder expectations, which may be concerned with a part of the outcome, how the product is developed, or even how the project is executed, will lead the affected stakeholder to consider the project less than successful regardless of the overall success of the deliverable. These aspects are called Political Success Factors (PSFs). You can solve the problem perfectly well without satisfying these factors, however, the stakeholder will not deem the result successful in his or her eyes.

While you must meet all Critical Success Factors as a business analyst or project manager, Political Success Factors are optional, usually based on the political clout of the individual voicing that factor. 

The project manager has two challenges regarding political success factors: determining which of the project constraints are Critical Success Factors and which are Political Success Factors, and then deciding whether to satisfy the Political Success Factor. The business analyst can lend invaluable assistance to the project manager in managing expectations by identifying the political success factors as early as they are voiced or suggested.

The business analyst may pick up the PSFs during problem investigation. When stakeholders suggest (or demand) a particular solution, they are expressing expectations, and more importantly, their success factors. If you are unable to disabuse them of their infatuation with a particular solution, they will expect their solution to be used regardless of the success of the product when another solution it used (one way to remove the expectation of a single solution is to offer alternate solutions until the stakeholder agrees that there may be other ways to solve the business problem). The project manager should be informed and a decision made as to what solution to execute. It is entirely possible that the Director of Marketing might actually have the best solution to the business problem. If not, then the Director’s expectations need to be managed and the earlier you manage those expectations, the better. 

The longer an expectation remains unaddressed, the more solidified and real it becomes until it is no longer an expectation, but a demand.

The political success factor may not be the entire solution but a part of the solution, an item at the edge of scope, or a request that would normally be taken out of “Needs” or “Wants” and placed in the BS category (BS stands for ‘Blue Sky’), but without which the entire solution is considered less than successful by the requestor. Then the decision is whether to include the requested element or not.

Many times the PSF conflicts with the CSF and the decision is easy. When the VP Marketing wants pictures on the website, but in doing so the download time exceeds the maximum acceptable for the product, pictures are not included. However, this will not make the VP Marketing happy and she might think the project is less than successful. On the other hand, taking an extra week to write more code might get the pictures down in a reasonable time. If the deadline is not a CSF, the project manager might consider including the pictures. Then, of course, there might be an issue with the VP Sales who wanted the website up a week earlier to boost sales figures for the month. Now the VP Sales does not think the project is that successful. We are, after all, talking politics here.

In all cases with PSFs, you need to make a decision whether to include the requested element in the final solution. You may decide that the solution you define is best for the organization, and you are willing to live with the political fallout. You may determine that the requester simply does not have enough political clout and you can ignore him. Or you may put the extra time and effort in to include the request in the solution.

Managing PSFs is a critical part of managing expectations. Remember that the primary PSF is the same as the primacy Critical Success Factor: solving the business problem. Regardless of the importance a businessperson or problem owner puts on a particular PSF, it is still negotiable. Some PSFs are simply not reasonable or feasible. You cannot implement a completely brand new business process without incurring some transitional loss of productivity. In the end, the tradeoff for the stakeholder may be to solve the problem completely and correctly, or include that particular personal PSF. Determine this as early in the solution life cycle as possible so that the appropriate decisions can be made and expectations managed.

Don’t forget to leave your comments below.

The Risk of Documentation Risk Tolerance

Written by Steve Blais on . Posted in Articles.

This is an open semi-serious response to Mark Monteleone’s article “As a Project Sponsor, What Is Your Risk Tolerance?”

We open with paraphrased lines from Hamlet: Speak the risk, I pray you, as I documented it to you, trippingly on the tongue. But if you ignore it, as many of our players do, I would gladly have the developers and groundlings make it up as they go.

Risk is uncertainty. If we are certain about something, there is no risk. We are certain the sun will rise during the day so there is little to no risk that we will have to endure total darkness. On the other hand, there would be a high risk of personal damage if we were to run blindfolded into a traffic-filled street. If we were sure we would get hit by a vehicle, it also would not be a risk but a certainty. However, we know that it is possible to race blindly into a line of fast-moving cars without injury because we see it happen all the time in the movies! (Do not try this at home. These are professional jaywalkers.)
There are few products that can be defined to one hundred per cent certainty. A space shot comes close because we are certain about the force of gravity, the amount of fuel to escape the pull of gravity, the weight of the rocket to carry that fuel, etc. There might be some uncertainties because we may have never done it before, but some laws of physics are immutable and therefore certain.

When it comes to business, uncertainty reigns. We may only be sure of one thing: we have a business problem. Hopefully we can be absolutely certain that we have the problem clearly defined, but many times that is not even a sure thing. The requirements document, in any form (use cases, user stories, backlog items or a requirements document) states the solution to that problem in greater or lesser detail. That solution is then elaborated or detailed into greater specifications until the solution team can implement it. As the solution is elaborated, we become more certain of what we are doing and the applicability of our solution to solve the problem, and therefore we remove risk.

While there is always a risk that we are not solving the right problem or that we have not defined the problem well, as business analysts we can remove a lot of risk by making sure the problem is not only defined but agreed to by the business community.

When we define the proposed solution, we also remove some risk—we have an approach to solving the problem so the risk of the problem lasting beyond a specific date is now reduced.

A signatory of a requirements document must understand that there is risk inherent in the document. Whether they are actually aware of this is another matter. In my experience, many signatories have not read the document and will never read the document. And regardless, they assume the document assures them that the risk a problem poses to the organization has been removed or at least will be. The larger the document is, the more assurance they feel that the risks are minimized and that the problem is going to be solved. This ties in with lower risk tolerance for larger budgeted projects; the expectation is that a larger budget buys a bigger requirements document. Just as the quality of the document is judged by its weight (the heavier the better), risk reduction is likely also measured in the same way. Can you imagine the response of that $10M project sponsor receiving a couple dozen index cards that describe the solution and being asked to approve them? Consider: “As an astronaut, I want to pilot the space ship to the moon and return safely to the earth within the decade so that I can get a ticker tape parade down Fifth Avenue in New York”. (This is not a knock against user stories, but rather a comment on evaluating risk by document, which as Mark suggests is often done).

However, in business requirements, a signature should only mean, “I agree that this proposed solution will solve the problem. It is the best of the possible solutions we can come up with and I authorize you to proceed with this solution”. To assume that the document itself, no matter how well written, can reduce the risk may be overreaching and giving the document too much credit. Even with all the best practices Mark lists, which should be followed by all definers of business requirements, there is still going to be much more than a ten percent risk that the solution will succeed as defined. The English language has over a quarter million words (according to the OED) and almost each one has multiple meanings. A requirements document, no matter how carefully constructed, will be fraught with ambiguity. That alone creates a high level of risk.

The biggest source of risk is uncertainty. Even if we spend twice the time we asked for to create the requirements document (and we are usually given half the time we ask for, or less), the document would still contain uncertainties. As we gather information to remove uncertainties, additional uncertainties will arise. We are subject to the basic truth of life: the uncertainty of time. We simply do not know what will happen tomorrow.

I think that Mark’s risk tolerance graph is a great guideline to remind us that we can reduce uncertainty by performing the best practices Mark has noted. However, I am uncertain about the percentages Mark assigns, and business analysts can argue forever about what best practices are and what they accomplish. It’s always good to try to simplify a very complex process into some hard-and-fast rules. Human beings like that kind of insulation from uncertainty. Unfortunately, claiming that nine out of ten projects that assiduously follow the best practices listed in the article will be successful is a terribly uncertain and therefore a very risky thing to say. In other words, the model Mark presents has its own risk.

I say this ironically, not negatively. Because Mark has brought up the issue (and the risk) that those reading about risk may decide to reduce the uncertainty of their own requirement documents by following the best practices Mark enumerates and by gathering more information. And that reduces risk. The real question may be whether the project sponsor knows that the extra time (and money) spent performing those practices correlates directly to risk reduction. We are uncertain that the project sponsor has such knowledge, and as Hamlet would say, “Ay, there’s the rub!” Or perhaps, there’s the risk!

Don’t forget to leave your comments below.

The Magic Bus or Bustrophobia

Written by Steve Blais on . Posted in Articles. 2 Comments on The Magic Bus or Bustrophobia

Back in the day, The Who, a British Rock group consisting of Roger Daltrey, John Entwistle, Pete Townshend and Keith Moon wrote and sang about a Magic Bus that would carry the singer to his girlfriend’s house. The Beatles another British Rock group of the time also sang of a bus on which a Magical Mystery Tour would roll on. And Paul Simon sang of looking for America on a cross country Bus. Ken Kesey took his Merry Pranksters across the United States on a Magic Bus and Tom Wolfe described the bus and tour in The Electric Kool Aid Acid Test. During the days of the nineteen sixties and seventies the bus metaphor was a positive thing.
Nowadays it is not the case, at least not in the IT world.

Today we have a Mysterious Bus that seems to prowl the roadways of IT searching to run over the best and brightest of IT workers. In project risk identification the bus reappears as an apparently valid concern as someone will ask, “What if our lead analyst were run over by a Bus?” It appears to be the same Bus that runs over these people regardless of where the project takes place. It’s a Bus that really gets around, targeting the more experienced members of the team or the members who have a specialized and usually irreplaceable skill. The Bus seems to be quite finicky as well, since it never takes after anyone but IT people. 

In the agile world this Bus has earned a different status: the Bus Ratio. The Bus Ratio measures the number of people on your team who could be wiped out by that Menacing Bus without seriously damaging the project. The higher the ratio, the better. In other words, when a team has a high Bus Ratio knowledge and skill are shared among the team so that each team member backs up the others and is similarly backed up. In many traditional teams, the Bus Ratio is low signifying a tendency toward job security over team sharing such that if one person got hit by The Bus there would be a significant loss of organizational memory and skill set requiring a retooling of the team and an immediate call to the recruiters. The message of the Bus Ratio is clear whether you are agile oriented or not: share the ride. 

What is interesting about the Bus Ratio is its application solely to the development team. The same team that is concerned about a high Bus Ratio among the team members, is adamant about maintaining only “One neck to wring” on the business side meaning one and only one Product Owner. The Bus has special radar that searches only for developers. There seems to be no concern that a Wandering Bus might happen to wipe out a Product Owner as collateral damage while hitting a developer head on. Either the agile community values the developers much more than the Product Owner, or they assume that the Product Owner’s knowledge is so common that anyone else from the business can step in after the Bus takes its toll.

That Bus is also apparently on call for the politicians on our teams and in our offices. When things start to go wrong, or “Go South” as the phrase is stated – which brings up another question: why would heading in a southerly direction indicate one is having problems? – someone decides to duck the blame or responsibility by throwing someone else “under the Bus”. The Terrorizing Bus will always happen to show up just in time for someone to be thrown under it. The assumption seems to be that once the unwilling team member is thrown under said Bus that person is not heard from again, lost perhaps in some metaphysical science fantasy plot wherein they become the Bus driver and seek other Bus victims. 

Of course the one ducking the responsibility and throwing a compatriot under this Busy Bus might get caught and in that case the person is Bus-ted, an appropriate phrase all things considered.

So it is not surprising when a colleague in a agile team coaching role was recently met with silent stares when she used the phrase “we all need to get on the team bus”. She was referring to a sports team bus traveling to away games, especially in High School and College. The analogy was that if you want to play you have to get on the Bus; otherwise you are not on the team. A good analogy as long as the team members do not suffer from bustrophobia. (I did not make this word up. It is in the annals of psychology and relates to a perceived loss of control). It is hard to get people on a Bus when that Bus has been known to be cruising the streets waiting to run you down.

I should put in a bit of a disclaimer. Due to increasing pressure from those among us who feel that the Bus Metaphor is too negative – referencing violent death, for example – and the protests from the Bus Driver’s Union and various cities Public Transportation Departments who claim that Busses in general have a bad enough reputation, the new replacement metaphor to be politically correct is the lottery. The ratio becomes the Lottery Ratio which asks the question how many people on your team can win the Lottery and the team will still function? Of course this assumes that anyone winning the Lottery would quit their job and that the odds would allow for multiple Lottery winners. Then again, other than disallowing team members to cross the street there is no way to prevent the Itinerant Bus from striking the unsuspecting developer, but the organization can prohibit the purchase of Lottery tickets by members of the same team to reduce the risk of the Lottery Ratio. Of course I’m not sure if throwing someone under the Lottery makes sense to avoid blame, so another metaphor will be in order. Then again, when Gamblers anonymous hears about the Lottery Ratio, we will have to come up with another politically correct metaphor. 

So the message is clear: to avoid bustrophobia keep BUSy, follow the syllaBUS, do roBUSt work, avoid aBUSive people, learn everyone else’s BUSiness for backup purposes, don’t combine comBUStible components, and most importantly: look both ways before crossing the street. 

Don’t forget to leave your comments below.

The Lexicon of the Solution: Eliminate the User

Written by Steve Blais on . Posted in Articles.

We talked about getting rid of the customer in the last episode, which got a couple of people riled up thinking that I was actually advocating the removal of the role of the customer. I was simply wondering whether we should still be using the term “customer” in the same way we have used it in the past. Now I’d like to go a bit further in our war on words that have lost their meaning and talk about the term “user.” When addressing the issue of the customer, I admit that I don’t have an alternative term in mind, only that the term “customer” has become ambiguous and can tend to establish the wrong relationship nowadays. I have more concrete suggestions when it comes to the word “user.”
The basic problem with the word is that it has been overused to the point of no longer having any specific meaning. “The dictionary’s first meaning is ‘the exercise of a right to the enjoyment of property’ (it’s a legal term). Also there is the meaning understood in the IT world: ‘a person or thing that uses [italics mine].’ I wonder how many of us perceive a ‘user’ in non-human form? And then there is the definition from Dave Barry, the humorist: ‘User, n. The word computer professionals use when they mean “idiot.”’ Putting aside the non-common use of the word, using the term ‘user’ conveys no specific, concrete, consistent usefulness to either the business community or the developers; we’ve just become used to the term ‘user’” [repetitive use of the word is intentional].

The term user refers to a vague, undefined, amorphous something that is interacting with our computer systems or our processes. In other words, specifying a “user” in our documentation does not really specify anything. The individual members of the business community define user to mean how they specifically use the system, and the developers just think, “idiot.”

Start with “User”

When we are starting out defining a system or the problem domain or a business process which we are going to improve everyone on the business side is either a stakeholder or a user. And that is all right. The term can be used as a placeholder until more information is available. But only at the beginning. If we are still referring to users in our final requirements we are essentially admitting we still don’t really know what the users use the system for.

Process Worker

We can start by separating the users, those who physically lay hands on the system, from those who work in the business process but don’t happen to sit at the monitor or interact in other ways with the system under consideration. As business analysts, we should be concerned with the entire business process in which the system under consideration plays a part, rather than just the system itself. We should identify the information that is entered into the system, of course, but also where that information comes from: when, where and how is that information created, and the processes the information goes through before being entered into our system. And, of course, where does information extracted from the system go, what is the final resting place for the information and what steps does it go through to get there? To help us remember the whole picture, the bigger system that our digital part fits into, we call anyone involved Process Workers. This helps us remember that in any business process there are more than users involved: there are customers (the organization’s customers), customer relations agents, salespeople, marketers, managers, mailroom workers, factory line workers, inventory control people, engineers and so forth, all of whom contribute to the overall business process but may not be users. Any changes we make to the “system” may cause a positive or negative impact on any of those process workers. As business analysts we must keep all the workers in mind when we are solving a problem or when our point of contact says “I need….” Remember that the point of contact or product owner is focused on his or her specific area of the overall process; we need to look at the bigger picture.

Consider a requirement that incorporates the term “user”:

“The user enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

(Note that the requirement is purposefully not complete.)

Position

As we begin to gather more information about the business process, the users or process workers become more specific. Instead of a user, the person is an Account Representative, or a Customer Relations Specialist, or some other position in the company. Typically when asked “What do you do?” the responder will start by saying, “I’m a [title of position] and I …” At this point we replace “user” with that position in our notes and conversations. No longer is that person a “user” to be clumped in with all the other “users” of the system, but is now a more specific “user,” one who performs specific tasks and functions with the system. At this point your terminology changes and you make a specific effort to eliminate “user.” Assume that wherever you have the term “user” you are missing information. 

When you replace “user” with the position — and replace the term everywhere, in your use cases, in diagrams, in documentation and in conversation — you informally categorize your requirements and make things easier. For example, when it comes time for review, those sections of the requirements in which Account Representative appears are the sections that will be reviewed by the Account Representatives and the Account Representatives only. You can have shorter, more effective review meetings when you are meeting with only those who have something to contribute about their process.

The agile concept of user stories emphasizes the use of positions or roles. The format of the user story is, “As a [specify role], I want to [specify function] so that I can [specify reason].”

Bottom line: “user” should not appear in your finished set of requirements or any diagram or reference to the requirements. Changing the example requirement above yields the following:

“The Account Representative enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

Personal

But, you say, Steve, what about those people who use the system that we really don’t know anything about, who don’t have a title or position, like people using our websites? For years, the user-experience analysts have known that it is better to personify those who we expect to use our websites rather than refer to them as generic users. They create “personas.” The persona is a fictional creation that embodies all the characteristics of a typical member of the target audience for the website. The persona has a name, demographic description, and typical style and motivation of use. Personas are used not just by user-experience analysts to help define the look and feel of the web pages, but also by marketing to assist in creating the content.

As human beings, we react better to personalization than to generalization. The developers can design a better website for Rita the 67-year-old grandmother interested in buying gifts for her eight grandchildren online instead of fighting the crowds at the mall, or Tommy, the tech-savvy graduate student in Computer Science who needs more information about Predictive Analytics than for some gray ghost of an anonymous user out there.

We may not want to go as far as specifying the persona name in the requirements, but we certainly can specify the target user, by description, that we expect to be using each function.

Performer

Now I’m going to get real picky. In the name of precision and better technical communication, I suggest going one step further. Let’s not stop at the corporate position, let’s move on to the role.

Every position in the organization plays multiple roles during a given workday. Part of our analysis is to identify these roles, especially those played in the business process we are focusing on, and more especially the system. An Account Representative may enter customer information, add a new sale, create a contract, review a sales order, inquire into previous sales information, review new product information, and so forth. When Account Representatives do each of these functions, they are playing different roles. And these roles are ultimately what we want to capture for the developers. 

The system, and the code we are putting into the system, cannot distinguish between Tommy or the Account Representative. (You might suggest that by virtue of the Login Process the system knows who is using the system at any given point. But consider this: Alan, the Account Representative, logs on to the system and then leaves the computer to go to a meeting. Anyone else can sit at Alan’s computer and enter data or perform any function. How is the system going to know that the person pressing the keys is not Alan?) The system knows that a button is pushed, or a mouse click has taken place. Regardless of who pushed the button or what caused the mouse to click, the system must respond in the predetermined way. 

This approach now lines up with the concept of roles in use cases. The role of “adding an account” can be played by anyone with authorization to add an account. That role might be called “Account Adder.” Should we wish to specify this in a set of requirements we might say:

“The Account Adder enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

Note the similarity in wording to that of a use case description Main Success Scenario.

You might think that writing requirements in this fashion perhaps seems a little silly. 

But wait, as they say in the infomercials, there’s more. We have one more step in our elimination of the user.

Gone

We’ve gone from totally abstract and generic wording, “user,” to totally specific wording “the account adder.” And since we really don’t care who is actually performing the function, perhaps we should go back to the term “user” instead of a silly moniker like “account adder,” which might sound like a poisonous snake with glasses. 

Rather than return to “user,” for purposes of clarity and specification to the developers, who have to analyze the requirements to produce the software, let’s go one step further and remove the user completely from the requirements. 

All the words about “user,” “Account Representative,” “Tommy” or “Account Adder” are meaningless to the developer writing the code to add a new account, and even less meaningful to the computer, which has to perform the function. Suppose in the requirements we state just what happens rather than who does it.

“When the name and address are entered and ‘Submit’ is pressed, the system validates the name and address and assigns a unique account number…”

When implemented, the code based on this requirement will execute the same as that of any of the previous requirement statements. However, with this stated requirement there is no uncertainty or questions about use.

Requirements are about specificity, preciseness, lack of ambiguity. We all agree that most of the communication problems we encounter that end up with contention on delivery are the result of vagueness and intentional or unintentional ambiguity. By changing a few words and phrases here and there, words we have used for so many years, they no longer have any real meaning, we can eliminate obfuscation and write better requirements, not to mention have more understandable conversations.

Don’t forget to leave your comments below

The Lexicon of Solutions – Down with the Customer

Written by Steve Blais on . 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”:

  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.