Author: Steve Blais

It’s the End of the Business Analysis World as We Know It

Written by Steve Blais on April 16, 2013. Posted in Articles. 3 Comments on It’s the End of the Business Analysis World as We Know It

Where Does the Business Analyst Go From Here?

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Chapter 1 How it began

Now he was concerned. Brian had weathered pretty much everything the organization could throw at a business analyst from the early days when he had to fight just to make the role a viable position in the organization to the past few years when he was under constant pressure to take over project management jobs in addition to his business analyst work. Brian was flattered that they felt that he had the capability to do both jobs simultaneously, but his heart was in business analysis and he was afraid that if he diluted his efforts by also managing he would seriously impair the enterprise level project he was on. Besides he had already done the project management thing. It was interesting and challenging, but it wasn’t what he wanted.

Now things were changing once again. The project he was on was a long term, several year reconstruction of one of the primary internal systems. It was one of the first systems the company had built to provide internal control over sales, marketing, order processing and just about everything associated with the organization’s backbone. The system was the pride and joy of the CIO, Carl, who was on the team that developed the system twenty years ago and it took some convincing, and a bit of arm turning, for the CIO to finally admit that the system needed an overhaul. Since he identified so closely with the system, it was as though he himself needed an overhaul. As a result, Carl also looked at the way the organization had been developing software over the years and despite a highly successful record of on-time delivery, at least on the internal mainframe based systems, the CIO decided that perhaps the organization should segue into agile.

The web site maintenance had converted to an agile approach to software development a few years back and been successful after some bumps. There were some teams here and there on the periphery of the internal systems that were run with an agile approach, mostly in maintenance activities. But the primary systems, based on the trusty IBM computers and written in Good Old COBOL, with a smattering of Assembler Language Code, were still maintained in a structured software development approach patterned after the linear, waterfall, model. Major new efforts, like the overhaul of the purchase order system which took two years was also done the traditional way.

Since the entire backbone system of the organization was going to be rewritten – code, databases, architecture, even some new networks – Carl had decided that everything might as well get more “modern’ as well. They were even relocating various offices and departments.

So Brian was worried. He and Ann were the lead business analysts in the organization and from his understanding of agile and its mystiques; he was looking at the end of his career as a business analyst in the organization. Neither he nor Ann wanted to leave. Their roots ran deep in the organization. But Ken, the leading Scrum advocate, who had led successful Scrum teams and Theresa, the technical lead, who was a staunch Extreme Programming (XP) advocate, were both onboard with the software development conversion and had advised Brian and Ann independently that the services of the business analyst were no longer required in the New World.

It wasn’t pretty. Brian still shuddered when remembering the show down meeting when the CIO decided to give the green light to the New Order of Development. What was ironic was that Brian had been a vocal proponent of the overhaul of the old system and was instrumental in influencing the CIO and executive committee to launch the new program that appeared to signal the death of his own job. Brian in fact, with Ann’s help, had written the successful business case!

Brian, of course, protested loudly in front of Carl, Vince, the Vice President of Marketing and heir apparent to the CEO’s job, and Olivia the Vice President of Operations, asking how the teams were going to determine what they had to do for the new system.

“Do any of your programmers have experience with inventory turns or balancing a cash receipts journal?” Brian had taken accounting courses and even a CPA overview from the state CPA association to keep up to date on accounting.

“They don’t have to be experts,” Ken countered. “We have the experts in the business who can tell the developers (he emphasized the word to remind Brian how out of touch he had become) what needs to be done. It’s not a problem. It’s time the developers and the business cut out the middle man, er, person (acknowledging Ann) and let the solution meet the problem directly.”

Ann spoke up. ”I’ve spent years with both the developers and business people. I don’t think the developers care to sit in long meetings and discuss the intricacies and ambiguities of supply chains and customer service. They have always preferred to just get the facts: what they have to do to solve the problem.”

Ken responded before Ann could finish. “This is the New Order, Ann. The developers are going to get with it and learn about the business. They are going to learn negotiation and interaction. Things are changing. We’re taking the developers out of their development hovels and moving them across the aisle.”

“Even if they don’t want to go? Even if they prefer just to code?” Brian asked remembering the days when he started out as a programmer and worked with many peers who really didn’t want to talk to anyone in the business.

“Yes,” replied Ken. “That is the Way of Agile.” He said it with a slight reverence as though talking about an Eastern Philosophy like Zen. Brian thought he saw Ken put his hands in front of his stomach and bow slightly with a Yin and Yang symbol hovering over his head.

Ann recovered the floor. “And I have not seen many of the business people who will jump at the chance to spend all their time with the developers and sacrifice their daily jobs. They don’t understand how the developers need to hear the specifications. They don’t understand how to specify requirements.”

Ken, in his enthusiasm, jumped in again, “They don’t specify requirements. Requirements are dead.” Brian thought he heard an underlying meaning in that statement: “Business analysts are dead along with the requirements.”

Ken explained, “We use user stories now. We don’t do requirements. Not only are requirements inefficient, tedious, generally unworkable, and unreliable, they are also boring. User stories are easy enough even users can do them. And we are also making the whole burdensome change management system that has infiltrated everything in our culture obsolete. No more green and pink forms, no cumbersome on line system that people forget to update, no endless change management meetings with the CCB that doesn’t want to be there in the first place, no politics,” Ken’s voice was raising, sounding like a politician in front of a Labor Day political rally crowd. “There will be no more risk management exercises with a Risk Register maintained by a Project Administrator, no Earned Value graphs and charts and reports, and, consider this, sir,” he said addressing Vince, “no more project managers or PMO.”

Ken, and everyone on the table, knew that the PMO and to a large degree the whole project management structure of the organization had been a thorn in Vince’s side for years. Vince hated the paperwork and time consuming processes that the PMO had established to provide some semblance of control and prioritizing of the projects in the organization. Vince was known to protest loudly to anyone who would listen, especially his golfing buddy, Charles Evans, the CEO, “We’re losing ground to the new and faster and more agile competitors out there. They get to market much faster than we do. They have a more agile approach to product development. When we come in with a change, it’s either in response to a competitor’s move or to market demand. If we don’t act fast we lose market share (market share was an important issue to Charles). If I have to go through all this paperwork and committee approval and business analysis and requirements and stuff…it takes longer to get something approved than to just get it done!” And unfortunately, Brian knew that was true to a large degree, but he was also around in the old days when everyone in Management Information Systems (MIS), as it was called then, seemed to be working on the demand du jour with no order or priority or sense. Efforts were introduced and dropped, replaced by other initiatives from executives with higher political clout, or urgency, and then brought back out of their hiatus with the admonition that they should already have been done. It was chaos. Projects failed not because they were mismanaged but because of the conflicting priorities and the disorder in the assignment of resources and the frenetic communications channels. Everyone in the organization could talk to any programmer at any time to get anything done. Brian was somewhat proud of the work he and Ann had done in bringing order to the business process of managing organizational change. He never took Vince’s complaints too seriously because the system was working fine for the rest of the organization.

It was then that Brian realized that Ken was in cahoots with Vince and had Vince’s complete support for the New Order. And Vince, as the next CEO, had the political clout. It looked like the Organizational Change Management system that had run successfully for these many years was as doomed as well.

“And as for the business people, they will love being able to get their needs met immediately in the order that they want them met. They will be able to change their mind, change their needs, change their approach, try new things and then try something else without the imprimatur of fighting the system to get things done. We see a major increase in innovation because the barriers to creative failure will be removed.”

Brian wondered where Ken had picked up the phrase “creative failure”. He knew it won points with Vince.

Brian and Ann fought to hold down their frustration. They lodged all the objections they could muster, but to no avail. The New Order was coming to the Organization. And that meant that there was no place in the New Order of Things for either of them or any of their cohorts on the Business Analyst Team that he and Ann had struggled so long to set up.

Brian’s thought, unexpressed to Ann who was lost in her own downtrodden thoughts, was “I’m way too young to retire, and way too old to start over again in a different organization or a different career. Besides, I really, really, really love being a business analyst.”

Brian was now being summoned into Pauline’s office. Pauline was the head of the PMO to which the Business Analyst Team reported. As he walked down the corridor which seemed a lot longer this morning than ever before, feeling like he was walking to his own execution, he was wondering, “what happens now? Is there no place for a business analyst in the New Order of Agile?”

With a shudder, Brian gathered himself together and opened the door to Pauline’s office.

“Ah, Brian,” said Pauline, not really smiling. “We have to talk. I’ll be talking to Ann next.”

What is going to happen to Brian facing the Perils of Pauline? Will the Business Analysis Team and the Change Management System survive? What about Ann and the rest of the business analysts in the organization? Join Brian, Ann and the rest of the Business Analyst Team in the next episode of Brian and Ann and the New Order of Agile next month.

Don’t forget to leave your comments below.

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Satisfying the Customer – An Example

Written by Steve Blais on March 26, 2013. Posted in Articles.

This is an example linking back to my last article – “Satisfying the Customer… Satisfying Who?”

The question of the customer is one that apparently deserves a little more attention. Let’s move away from theory and principle to practical application of the principle set forth in the last article: the customer is the purchaser of your organization’s goods and/or services.

Let’s look at a fairly typical example in today’s web infused business environment.

The organization sets up a website to sell its products or services to the public. The website works. There is a checkout facility reminiscent of a grocery store shopping cart. The user experience folks have given it their blessing and the site is up and running. After a while the site begins to attract a steady stream of visitors and buyers.

The request comes down from on high for a new feature: registration of all the visitors to the site.

There are several constituents who are affected or impacted by this initiative.

The Marketing Department wants registration so that it can gather information on people visiting the site to correlate with other information that they have collected, do analysis and studies to see what kind of people by what items, and to add to their large mailing list of current and potential purchasers. Marketing sees this as a way of achieving several of its goals, such as increasing the number of entries in their marketing mailing list and measuring the market penetration of the website in social media such as Facebook and Twitter.

The Sales Department is behind the idea. They see sales increasing to meet their goal if they can focus the marketing while the person is buying. They view the registration as a way of creating a candy and magazine display at the checkout counter, where they can increase sales through impulse buying. They wish to use the buying habits and personal information of a registered buyer to suggest additional items to be purchased at checkout now or in the future.

Customer Service supports the initiative. They see it as a way of anticipating problems, delivering more focused and immediate solutions to customers’ issues, and providing a more personal service to the customers, which may increase the customers’ loyalty. All this together will help them achieve their goal of reducing the time per customer service call and eventually perhaps the overall cost of customer service.

Security says that they will feel a lot more comfortable about the general public using the website if security knows who those people are at all times. Security is always in favor of increased information on everyone.

And the Legal Department is pushing for this feature because they feel that the registration process can include certain contractual language and disclaimer information so that the visitors to the website cannot hold the organization accountable for errors and omissions that may occur while using the website.

So everyone is in favor of the registration process and each constituent has something to gain by a successful initiative. Marketing wants registration as soon as someone lands on the website home page to increase the number of people who will register, Marketing’s proposal is that no one can get the benefit of the information on the website or see the products that are available without registering. Sales and Customer Service hold for a registration prior to purchasing something so that visitors can come to the website unregistered and possibly see something to buy. Then, since they want to buy something they will be more inclined to register.

You are assigned to be the business analyst on this initiative. Your job ostensibly is to determine what needs to be done to implement a registration process on the organization’s website.

You gather information from the various constituents and since the initiative is being managed or driven by marketing, you set about to define the requirements necessary to capture the registration when people come to the website. You define what information is necessary, how the registration process will take place (as a pop up box, new page, etc.), where and when the visitors to the site will be required to register, what they can do without registering, and the general language that will be presented to the visitors. You as business analyst gather the information, define the requirements, work with the solution team to produce the final registration feature, and oversee the implementation.

You also spend time for discussions with sales and customer service, legal and security because they have a vested interest in the outcome of the initiative. But each department has its own vested interest. The Sales department is only interested in getting registrations for customers who actually buy products. In fact they are insistent on it. And now you have a situation: do you define a solution as marketing, the department ostensibly paying for the software or sales who is claiming a loss of sales to the organization if you adopt Marketing’s solution?

We might consider each of the departments as our customer insofar as the initiative is concerned. If Marketing is paying for the changes, then Marketing might be considered our customer just because they are paying for it. However, in the course of preparing the definition of the solution we may talk about each of the constituents being our ‘customer”. Each has to be satisfied. What happens if Security wants additional information on customers and Sales considers the information intrusive, and legal is concerned about privacy issues?

Perhaps there is another customer that the business analyst should consider? Those who will actually be using the web site: the customer of the organization.

Each of the departments reviewing the initiative does take the customer into account, but each sees the customer from a different perspective. Legal sees the customer as a lawsuit; customer service sees the customer as a question or complaint; security sees the customer as a threat; sales and marketing see the customer as numbers. Suppose you decide to view the customer as a person using the web site and you assume a goal that you want that person to be a purchaser of the organization’s products now and in the future.

Let’s consider the results if you investigate consumer reactions to a registration process, or even think about your own reactions to a registration process. You determine that those who register will be getting emails and other marketing materials automatically, and they will have to opt out of each individual marketing program. You do some surveys and discover that people who are required to register before looking at goods and services will likely leave the website and go to another competitor who allows viewing of the goods and services without registering. Or perhaps you check out the competitors’ similar websites and note that the more successful sites offer an incentive for registration such as ten percent off the sale and that the sites offer registration at several points during the shopping and buying process.

In other words, focusing on the real customer of the initiative, the real customer of the organization will generate new and different perspectives which will add value to the organization over and above those solutions suggested by the internal departments, including IT.

It should be noted that a business analyst who might attempt such a departure from the expected might have some difficulty with the project manager and others from IT who are working for their “customer” who in this case might be the Marketing department. In other words, the standard line in IT seems to be to “keep the (internal) customer satisfied” even when that customer may be wrong. As one senior developer working in an agile environment told me, “If it’s on the product backlog, we do it”.

Now this particular conundrum might not occur in your world. However, it is not a made up example. The end result of the initiative was a successful registration process that did not follow marketing’s recommendation to force registration, and did not even require registration to purchase goods as was insisted on by sales, but the end result satisfied the web consumers and built up a repository of positive registrants with a low opt-out ratio and a high repeat sales ratio. The success was due to a focus on the real customer instead of what was Oh, and the business analyst did have to withstand a lot of pressure from the project manager and team (not to mention marketing) for not paying attention to what “the requirements” of the initiative were.

We talk a lot in these pages about the business analyst being an agent of the business for the solution team, or the business facing member of the solution team. And we generally assume that ‘business’ refers to the people who run the business: the purchase order managers, the order entry clerks, the marketing people, the inventory people and so forth. But what we really should do is consider what business the organization is in. Then we can define the ‘business’ aspect of the business analyst. The business analyst focuses on the business of the organization not the business people in the organization, and that means those who keep the organization in business.

Don’t forget to leave your comments below.

Satisfying the Customer… Satisfying Who?

Written by Steve Blais on March 4, 2013. Posted in Articles. 1 Comment on Satisfying the Customer… Satisfying Who?

In our continuing effort to create a specific and relatively unambiguous vocabulary for business analysis, we come across the term “customer”. As business analysts we are constantly beset with the term couched in phrases like, “keep the customer satisfied”, “the customer is always right”, “we have to be customer-centric”, and so forth. The dictionary definition of “customer” is “a person who purchases goods or services from another; buyer”. Unfortunately, this definition does not fit all the varying roles who are designated customer, especially in an IT sense. For years, IT has had the business operations as its customer because IT was viewed as a service organization to the business. Now as IT becomes more entrenched and integrated with the business strategies and operations of the organization, the term has evolved and morphed so that sometimes when the business analyst is sent out to “work with the customer to define the solution” the definition of the solution is easier to comprehend than the definition of the customer.

Just who is our customer? This is not a frivolous question. About 15 years ago I was working for an automobile manufacturer and the executives were struggling with that very question. Who was their primary customer, the one that they needed to focus on? Since they owned a variety of other companies producing products not related to automobile manufacturing, their customer could be any one of the consumers of any one of their other products. For example, the company made diesel engines for locomotives and that would make train companies their customers. They also made engines in one of their subsidiaries for jet engines in airplanes. Since the jet engines were designed for commercial aircraft as well as fighter planes, the customers could be foreign governments or commercial airlines, and these were customer with large pocketbooks. It turns out that in the United States, this automobile manufacturer could not sell directly to the public, but only to dealerships who then sold to the public. This meant that the customer of the automobile manufacturer was not the driver of the automobile, but the dealership who sold the automobile. And as with any of the major automobile manufacturers, they had their own financing company, and it was this financing company who finance the cars that you and I buy, making us the customer, but not the customer of a car, we were the customer of a financial institution. So which one of these should be the customer of the organization? The discussion went on for quite a while, and I left before I learned what the answer finally was.

Why was it important to the company? Because knowing who your real customer is basically defines what business you are in. Based on subsequent business decisions and economic climate, it looks like there definition of customer has likely changed over the years.

So as a business analyst who is your customer? And, like the automobile manufacturer described above, does your customer define the business you are doing? How can you satisfy your customer if you are not sure who your customer is, or the definition of ‘customer’ keeps changing? How can you satisfy your customer if you have many customers who may have different and conflicting satisfaction demands? One approach that is sometimes touted is for the business analyst to define the customer of an individual project when the project begins. However, that person might be different depending on our definition of customer. I have been in situations where different people on the project responded to different people outside the project as “customer”. When that happens we get into the Orwellian concept that “all customer are equal, just some customer are more equal” and the business analyst has to sort out the inequalities.

Let’s start our sorting process with the usual suspects. Which of the following do you see as your “customer”? Who do you keep “satisfied”?

The Sponsor

Perhaps the most common definition of customer (especially to IT) is the one who pays the bills. The definition does match the dictionary definition of “purchases goods or services”. The first issue we have is with another common role, the sponsor. Many organizations tag the one who pays the bills as the ‘sponsor’. If that is the case, who is the customer?

Even when the bill payer is called the customer, there is a problem. Many times, the customer or sponsor has absolutely nothing to do with the project itself. For example, in the United States Federal Government, there are senior people who fill the roles of Contracting Officer. To keep the procurement and contracting process objective and as free of graft and manipulation as possible, the regulations state that I, as a staff member of a consulting firm bidding to Federal Government agencies, am prohibited from dirtect intercourse with the Contracting Officer and so I would rarely meet and talk to the Contracting Officer assigned to my contract. Those of us working on the projects for the Federal Government talked to someone called the Contracting Officers Technical Representative (COTR). The COTR had no control or authority over the contract and was not the person who paid the bills. The Contracting Officer did that. The contracting officer’s primary concerns were that all paperwork was filed correctly, all financial matters are handled successfully, and the COTR affirmed that we had done our job so that we could get paid. In this particular arrangement, the customer might well be the COTR as opposed to the contracting officer who paid the bills. After all, we could have some input and influence on satisfying the COTR.

So we might be digging ourselves a hole if we attempt to satisfy the person who pays the bills when the person who pays the bills in not really concerned with what we are doing. If you are working on modifications to the organization’s financial systems under the direction of the Chief Financial Officer (CFO), even though she might be the ultimate customer in your lexicon, your real customer might be someone closer to the project, and it is that person you would need to keep satisfied.

The Problem Owner

Every project solves a business problem. And every business problem must have a problem owner. So perhaps the “customer” of the business analyst and the project team is the problem owner. After all, the problem owner would be the one who determines whether the problem has been solved or not. However, in the world of corporate politics, finding someone who will admit to owning a problem is somewhat difficult. Ferreting out who the problem owner is one of the techniques business analysts use to establish the real problem to be solved, so that the team solves the right problem. However, that task is not easy. You either have no one stepping forward to address the real problem and own it, or you have several who want to own it so that they can put their mark or spin on the problem. There have been many times when, as the business analyst defining the real problem the organization must solve (as opposed to the ‘problems’ that business people present which are usually symptoms), I have become the ‘problem owner’, the one that upper level management expects to take charge and solve the problem. It may be a subtle transference of responsibility to hand over the ownership of the problem to the business analyst but it happens. And then who is your customer? Do you become your own customer? Are you then the customer of the solution team?

Again, it will be difficult if we state categorically that the ‘customer’ is “the one who owns the problem”. Ideally this might be true, but in reality it does not seem to work all that well, and leads to the Multiple Customer Syndrome.

The Business Manager

It might seem natural and logical that the business manager would be considered to be the customer. After all, the business manager has the authority to approve or disapprove the results that we produce from the project and the business manager is usually a lot closer to the action than the Sponsor. This does present some interesting situations, such as one I ran into five years ago or so when a manager gave us the specifications for a particular financial transaction that was being rewritten for his company. He was the subject matter expert, having worked on that particular financial transaction for years before being promoted to his position of management several years prior to our engagement. We were instructed not to talk to the users because he didn’t want us taking the time away from their productivity and he figured that he was expert enough in the process to provide us with all the information we needed to change the system. However, for a number of various reasons, we decided to run the user interfaces past the users and figured a single meeting with them would not cause too much productivity disruption. The users were united in their dislike of the new process that the manager had laid out for us, pointing out that they no longer performed the process the way he described and had not for a number of years. They told us how they did it today and made suggestions as to how to improve it for the upgrade. This of course put us in a quandary. If we satisfy the users we draw the enmity of the manager, if we satisfy the manager, we produce a system that may not be used. Which one is the customer? Which one do we satisfy?

Assuming the business manager to be the customer might result in inefficient systems that may not be used to their greatest effectiveness. And, again, you face the Multiple Customer Syndrome when there are several business managers all of whom stake out their claim to the overall solution.

The Users

In the end, perhaps the ones we have to satisfy most are those who are using the system. After all, they have to use it day in day out and if they are not satisfied with it they won’t use it. And the problem for which the system was written to solve will not get solved. However, if we think of the users as the customer, we run into the issue of which user is the Real Customer? Users may represent a wide range of both organizational hierarchy and business area penetration and as often as not have conflicting requirements and views of the solution. Now we have the Multiple Customer Syndrome to the maximum. Another issue with defining the ‘customer’ as the user is that the term ‘user’ itself is vague and ambiguous. What precisely is a ‘user’? If we are not sure who the ‘user’ is, how can the ‘user’ be the ‘customer’?

If the user is the customer and we are to ‘satisfy the customer’, which one do we satisfy?

The Organization’s Customers

Perhaps we might possibly consider defining our customer in the same way the organization defines its customers. Instead of talking about internal customers which are satisfied by IT and external customers who are satisfied by the organization, we define one customer: the one (individual, organization, group) who buys our goods or uses our services and keeps our organization in operation.

In the bigger picture everything we do in IT or as a business analyst should be working with the business to satisfy the same customer. And in the end, if we satisfy the organization’s customers, we should satisfy all those we would consider “customers” of IT at the same time. And truly, we have to accept the fact that the consumers of the organization’s goods and services are really the only ones who need to be satisfied.

Why is it Important?

Because there are views of an organization’s ‘customer’ that are both positive and negative. Customers may be extremely frustrating, they may be overly demanding, they are rarely appreciative of the work that we do for them, they are hard to say “no” to, some believe they are always right, and they are always necessary to keep the organization in existence. By calling the people that you work with internally to solve the business problem a “customer” you are visiting upon them all of the characteristics of all customers, and this certainly is not conducive to a successful working partnership.

If we can start evaluating every system we define, every change that we make, every problem we solve with the question: “will this satisfy the customer of my organization?” we will likely be on target with the recommendations we make and all our changes and solutions will be aligned with the overall organizational goals and mission.

The problem then becomes: what do we call all those others whom we previously called ‘customer’ (after all we come from IT and therefore have to either label or make an acronym out of everything). . “Partner” might be a good term for those in IT to call those in the business. How about ‘teammate’, as in member of the solution team?

There is much talk today of convergence, bringing the business and IT closer together as partners. That is one of the precepts of agile no one in between the customer and the solution team. If you want the business to be a ‘customer’ with all the trappings of a customer (think of yourself as a customer in a store) and therefore be on the other side of the table in a negotiating position, then call them ‘customer’. If you want business and IT to be partners, work together and sit on the same side of the table opposite the organization’s real customers, then perhaps you should call them ‘partners’.

People will tend to meet the expectations of the label you give them.

Don’t forget to leave your comments below.

Want to Improve? Don’t Make Resolutions. Play Games and Keep Score!

Written by Steve Blais on January 29, 2013. Posted in Articles. 1 Comment on Want to Improve? Don’t Make Resolutions. Play Games and Keep Score!

It’s the New Year. And everybody decides to start a new year with resolutions, resolving to change their behavior for the better. They are going to lose weight and exercise more. They’re going to spend more time with their family, instead of work; they’re going to read more and watch less television; and so forth. And as we find every year: we just can’t keep to our resolutions. Here’s an idea to help you achieve the behavior you would like: instead of making resolutions, play games and keep score.

Playing the Game

Last year I had a couple of engagements in Phoenix, Arizona with the same company at the end of June and early July and talked to two different groups of business analysts, software developers, testers, and so forth. In the first session, a young man asked how he could become “spontaneous”. I asked what that meant, and he said that he wanted to be able to contribute in meetings and gatherings instead of remaining quiet and in the background. He wanted to be able to give voice to his thoughts and opinions. In the second meeting, a young fellow asked how he could become less “shy” in business settings. What they wanted was some kind of magic phrase from me or timeless advice that would change their perspective and suddenly make them more loquacious and outgoing. Unfortunately I didn’t have such a magic phrase.

What I did have was a program of practice. I thought up a game they could play that would do the trick painlessly. I suggested that they make a commitment to making one statement and asking one question in each meeting they attend. Any question and any statement would be acceptable. A question such as “would you mind repeating that, I didn’t hear you?”, and a statement such as “I agree with that” would be allowed. I told them to create a spreadsheet, and keep score of the number of times they made a statement and asked the question in a meeting. The spreadsheet is for keeping score: the Rows would be the meetings and the columns would say how many questions they asked and how many statements they made. “Do this for about three months,” I told each of them, “and if you find that you are routinely meeting your quota of questions and statements, increase your quota”.

Why it Works

The magic of this particular game is twofold. First of all, of course, they would overcome their fear of speaking in front of a group and give them the mindset that what they have to say is just as important and interesting as what anyone else has to say. The second bit of magic is that over time, there will be natural positive feedback from others in the groups or meetings. People might say “yes, I’m glad you asked that; I didn’t hear either”, or “thank you for agreeing with me”. Even a nod or smile will serve as positive feedback and help overcome the fear (the fear that is based on rejection or disapproval from others) so that the game player will be encouraged to do more.

One of the fellows, the second one, wrote me an email in August telling me that it was working. He found it much easier and comfortable even to talk in front of a group of people and he mentioned anecdotally that it gave him confidence he didn’t know he had which was helping in other aspects of his life as well.

The reason this game works is misdirection. Your focus in the game is not on learning how to talk in crowds or overcoming fears; your focus is on getting your quota per meeting. As you look at your spreadsheet and see zeros you will resolve to eliminate those zeros in the next meetings simply to win the game. It becomes more of a scorekeeping exercise than a behavior modification exercise. Can I go for three months coming up with at least one thing to say and one question asked in each meeting, business or social? Without being aware of it, you will find that whatever the behavior you wish to change – whether it is to add a new behavior, alter an existing behavior, or remove a behavior you’d rather do without – will be changed and new habits developed. And usually, you won’t even know it happened until you look back at where you were when you started the game.

Another Good Example

Late last year a fellow down in Austin, Texas, by the name of Jia Jiang, decided to overcome his fear of rejection and his emotional and even physical reaction to rejection. He decided to play a game in which every day he would purposefully make a request of someone for something which he knew would be rejected once a day for one hundred days. He videotaped each encounter. He asked an editor at Bloomberg BusinessWeek if he could write articles for the magazine even though he had no experience; he asked a professor at the University of Texas in Austin if he could teach one of the professor’s classes; he asked the flight attendant on a Southwest Airline flight if he could give the preflight safety announcements; he asked a Domino’s employee if he could deliver pizzas. He asked a stranger to lend him $100, and another stranger online for a Black Friday sales event if he could cut in front of him. He received negative responses in all cases. In the beginning it was difficult, even when he knew he was going to be told, “No”. As he proceeded through his hundred days, he found it becoming easier and easier to accept rejection. And as usually happens with games of this type, when the targeted specific behavior changes other behaviors also change. In the case of Jia, he found that he was more able to ask for even preposterous things. His confidence increased to such a degree that an increasing number of requests toward the end of his hundred days, the person being asked did not say “No”.

How it’s done

So what does that mean to you? As with anything a business analyst does, you first understand the as-is situation which means an honest self-appraisal and self-assessment. You may not need one, but it’s good to do one anyway. You can do this in a number of different ways. The least painful is to identify people that you would wish to emulate, people you admire –people who are alive now, people who have lived sometime in history, people you know, people you don’t know, even fictitious people. Then identify the characteristics of those people that you admire. For example, if you want to be a better business analyst look around to those who seem in your eyes to have it together as a business analyst: people in your organization, people in your professional groups, people you know only online or through conferences. Define why you think they are a top business analyst. (Note that there is no finite definition of a top business analyst. What we are talking about is what you think the characteristics of a top business analyst are).

Once you have determined those characteristics that you find admirable and that you wish to emulate, make a list of them, prioritize them and pick one, just one, of the characteristics, or behaviors. Then make a game of challenging yourself to do something that will overcome whatever obstacle you have to achieving that behavior or characteristic. Set a timetable for performing the game and the important thing is to keep score. Without the scorekeeping and the daily revisiting of the score pad to update the score, the behavior modification becomes a simple matter of willpower and that does not always work. Keeping score gives us a constant reminder and places us in a competitive situation and that will provide the motivation to keep you true to your goal.

The Hard Part

The hard part isn’t really doing the assessment, although some will people find it difficult, and the hard part isn’t really deciding on which characteristic of behavior you would like to adopt. In the end it really makes no difference because when you have adopted one behavior you go back to the list and pick the next one until you are satisfied that you are a top business analyst or whatever you want to be. The hard part is coming up with a relatively nonintrusive, challenging, and achievable game for which you can keep score. But there usually is at least one game for every behavior you would like to modify. To back up that statement I will offer the following: if you determine behavior you want to change and cannot come up with a game to play, drop me a line and likely I can give you one. And I’d love to hear about your successes.

So play the game, keep the score, change your behaviors without pain, and as the U S military outfit says, in 2013, “be the best you can be”.

Don’t forget to leave your comments below.

The Business Analyst as Therapist

Written by Steve Blais on December 18, 2012. Posted in Articles. 1 Comment on The Business Analyst as Therapist

One of the common roles in which a business analyst is cast is that of the go-between. This go-between may be disguised as a bridge (between the business community and the IT project team), a translator (to decipher the business and technical jargon both sides tend to throw at each other), or a referee (whistle and flag optional).

Blaming the traditional lack of communication between the “nerds” and the “suits” on jargon or lack of understanding ignores some basic cognitive differences between the two groups.

Developers who are untrained in psychology or cognitive behavior often miss the psychological factor in their relationships with the business community. That is why the intervention of a business analyst is helpful, if not necessary, to connect the two. It isn’t really in the terminology that each “side” uses, which is the basis for management depicting a business analyst as a “translator.” Learning different terms for things is not difficult if a person wants to do it. For example, I think it’s important for developers to take the time to learn the business they are writing software for. However, there are some who disdain the business and anything else that is not rationally based on a binary system of evaluation.

Even if the developers learn business-speak, as should be the case in agile, according to the adherents, there is still the issue of understanding cognitive biases, emotional influences and irrational human behavior. Simply, people do not always decide or act rationally. Their actions and reactions are governed as much by emotion as by reason. Daniel Kahneman, a Nobel Prize winner, calls this fast and slow thinking. Fast thinking is our default, knee-jerk, emotional reaction, and it is governed by the amygdala. Meanwhile, slow thinking is the rational, reasonable thinking that takes place in the frontal cortex.

Those who spend their careers, and in some cases lives, dealing with the absolute rationality of digital bits and unemotional computers (I am one of those) may not be able to make the leap into irrational human thinking. Computers don’t provide physical cues as to their thinking, so a technologist may not pick up the true meaning in something that’s said that anyone else would understand inherently. The developer is just looking to find out what is necessary to write code. The rest is noise. And there is nothing wrong with that. The issue is that business people do not think or operate at that level. Business people deal in ambiguities and feelings, and are not used to reducing things into binary equivalents. Business people like “may” and “depends” and abstracts while a technologist prefers “must” and “only” and concretes. It is more than just the language. It is really about the concepts, ambiguities, relationships and psychology.

When dealing with the dissonance between the user community and the IT solution team, a business analyst has to be well aware of psychological differences and not blindly focus on the facts. For example, business stakeholders may have a number of unstated expectations about the solution that live on throughout the project and only surface near the end when they see the final product in operation. That is when you hear “Well, this meets the requirements, but it is not what I want.” The developers have issues with this reaction, as well they should. When business stakeholders are broached with the question, “Why didn’t you tell us about this?” the stakeholders respond, “You didn’t ask!” Extracting these unstated expectations from the stakeholders’ heads requires skills usually possessed by psychologists, namely careful and complete elicitation, empathy, understanding and listening.

Business analysts need to have at least a bit of psychologist in their approach to do their job successfully.

The idea of business analyst as psychologist is not far-fetched. Sometimes as a business analyst, you spend a lot of your time just listening, much like a psychiatrist, to complaints, gripes, fears of impending change, protests against impending change, fantasies about how the work should flow or the system should operate, as well as business workers’ problems with IT folks and IT folks’ problems with “stupid users.” There are also problems with managers, management, vendors, off-shore teams and probably co-workers. It is easy for both the BA and the person talking to get a sense of a therapy session. The business analyst is someone who is outside the responder’s business area and who comes in with the express purpose of making a change. And of course psychologists and therapists are all about making changes in a patient. Even though the business analyst is making a change to the organization, that change may affect the responder. Since the business analyst possesses the skills of elicitation, empathy and listening, the responder may open up about more than their idea for a new screen design.

There is also much psychology involved in negotiation, mediation and applying influence, all of which business analysts generally do in the normal course of their work. Each of these communication practices requires the ability to get to the real intent behind the positions, and to identify hidden agendas and deal with them effectively. The intent is often driven by emotional or psychological motives rather than rational business factors. And this is where the business analyst needs to understand human motivation, cognitive biases and emotional stances.

A psychologist or therapist might make a good business analyst, but considering the vast differences in pay scale, perhaps I should say the good business analyst might make a good psychologist or therapist.

Don’t forget to leave your comments below.