Skip to main content

Tag: Communication

Problem Solvers and Fixing the Corporate Order

In companies that are obsessed with politics and intrigue, problem solvers rarely fix issues and are more likely to spawn new problems that weigh heavily on the organization’s ability to serve customers and respond to market trends. This is because most problem solvers in such organizations avoid thinking about the political dimension of problems. For them problem solving is apolitical and necessitates issues to be understood and analyzed, root causes identified and validated, and initiatives developed and implemented that eventually result in workable solutions. The solutions— by and large—are delivered in the form of processes and governance models, roles and responsibilities, training, automation etc. Problem solving in this manner always conforms to the politics of the company or what I like to call the “corporate order”.

No matter how hard problem solvers try to fix problems, the corporate order always ensures that facets of the solution they deem threaten their interests are either lobbied away or sufficiently diluted before the green light is given for implementation. Even the implementation of the solution is not secure from the prying eyes and ears of the corporate order. If they discover that red flags can expose their incompetence or heap embarrassment upon them, project and operational reports are skillfully manipulated to steer initiatives into paralysis or the initiative is given a death blow.

In such environments problem fixers— executives, program directors, project managers, line managers etc— quickly learn to mould their thinking to accommodate the interests of the corporate order, even if it is detrimental to the corporate interests. Subsequently problem fixers spend huge amounts of intellectual capital, invest considerable money and exert much effort in producing and delivering solutions that are fundamentally flawed both in scope and application. From the outset the purpose of such solutions is to maintain the status quo i.e. keeps the executives that preside over the corporate order in power. Problem fixers are only permitted to solve those problems that enable the custodians of the corporate order to meet their performance targets and maintain good relations with the board.

Problem solvers who adhere to the purity of their thinking and are sincere to the corporate interests find it extremely difficult to conceal their frustrations in such working environments. They often clash with the interests of the corporate order—many do so with a poor understanding of the political situation. In the end—depending upon the level of seniority and political influence—they are either brow beaten into submission, contained but isolated or their employment is terminated. This usually happens after a lengthy war of attrition—often disguised in business jargon, so that unaware employees do not become suspicious and can be used as pawns in the ensuing power play—and the company’s resources, money and time are wasted in such pursuits.

Those problem fixers that survive the onslaught are intellectually scarred and find it difficult to even attempt to solve future problems. They procrastinate fearful that their solutions will be rejected by other employees who work under the shadow of the corporate order. Such problem fixers very quickly lose credibility and relegate themselves to problems they cannot solve.

If problems solvers truly want to solve problems in politically charged companies, then they must frame the problems in the context of the corporate order. But to do so, they must excel in three areas.

First, develop a firm understanding of the corporate order and its political influence on the entire company.

Second, learn to think politically and not intellectually. Unlike intellectual thinking, political thinking has no rules. Its source is the statements and deeds of those who engage in politics at work. Techniques such as generalization, modeling and analogies rarely work to uncover or counter the motives and plans of the corporate order. Conversely, the corporate order is apt at exploiting such techniques to imprison problem solvers in their thinking thereby rendering them impotent. Hence, it is incumbent upon the problem solver to build a profound understanding of all the major players at work, their domains of influence and how they maneuver politically to safeguard their interests. In sum the problem solver needs to possess a crystal clear picture regarding their personal political plans and actions.

Third, the problem solver must have the courage to challenge the existing corporate order. Challenge here should not be confused with mere confrontation with the guardians of the corporate order that ultimately yields a compromise—this will never lead to proper change. At best the problem solver’s concerns will be accommodated by the corporate order, but at the mercy of their terms and conditions. Moreover the problem solver will be regarded by other employees as a lapdog of those executives under whose control the corporate order thrives. To produce effective change the problem solver must expand the support base to include other executives willing to spearhead the cause, and then challenge the corporate order until it is reformed or reconstructed. This is a high risk strategy—failure will certainly be a career-ending move for the problem solver, but success will usher in an era of genuine problem solving and propel the company to new heights.

Don’t forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programmes and projects. His experience has been gained in industries as varied as utilities, telecoms, financial services, transport, and education, working for several blue chip companies such as Centrica, London Underground, British Telecom, Oracle, Enron, Logica, and Wateen. Currently he is working as a director of corporate programmes for a leading teleco operator in the MENA region.

Does Your Language Make People Nervous?

Last week my wife and I attended my cousin’s wedding in the Dominican Republic.  It was at a beach resort filled with tourists from around the world.  The ceremony was right on the beach…beautiful!  After the sun went down many of us stayed on the beach to celebrate with the bride and groom.  At some point the biggest man I ever saw in my life decided to join the party.  He was not with our group and stumbled upon us as he was walking the beach.  He appeared to be in a good mood and was speaking loudly in a language I did not understand.  He came up to me and in a fun way slapped me on the back.  The pain was so intense; I thought he separated my shoulder.  As his backslapping and booming voice continued, I started getting very nervous. I was not sure what was going to happen.  Could the biggest man in the world turn on us?  At one point I started to think about what I would do if he got mad and came after us.  I decided I would go for the ankles.  Trying to hit him would leave me with a broken hand.  He eventually moved on without incident and the celebration continued. 

Later I did some self analysis to try and determine what made me so nervous.  It all had to do with me not understanding what he was saying, and he could not understand us.  In addition, the fact that he was the biggest man alive, there was the risk of him doing physical damage. 

So, does your language make your business stakeholders or your team nervous?  In our profession we have to communicate with many people speaking different “languages”. Like the guy on the beach your intention is most likely not to make the people you work with nervous. But, if you are not speaking their language there is a good chance you do make them nervous.  If you speak to technical to your business stakeholders or not technical enough to your development team, you may be making them nervous.  If you communicate in too much detail to your management or not enough detail to your quality assurance team, you may be making them nervous.  These are obviously stereotypes as you know some managers want all the detail.  The fact is if you are making the person you are communicating with uncomfortable, they are not hearing you.  They are thinking about ways to protect themselves. 

You have to determine and be aware of what language the people you are communicating with speak.  To progress in your career you have to become multi-lingual. 

Cheers (Salud, A La Votre, Na zdorovie, L’chaim, Kan-pie…),

Kupe

Don’t forget to leave your comments below.

Lost in Translation

What does the phrase, ‘Lost in Translation’ mean?

It refers to the situation when you try to translate something and the original meaning can not be directly translated into the secondary language.  In these cases it must be rephrased or restated in a different way.  The result is that some things are never able to be translated properly.  That is especially the case when attempting to tell a joke to a foreign audience! – Don’t attempt.

How does this apply to a Business Analyst (BA) whose role is to define requirements?

When my children were young and they asked “what do you do?” – I would try to explain that my job was to translate.  I had to understand the language used by the business and translate that into the language used by the IT developers.  Having spent time both in IT as well as business functional areas we understood a little of both “languages”.

The BA has to translate the business goals, objectives, rules, processes and data into business requirements that all stakeholders can understand and agree upon.  Often the BA has to rephrase, restate or “translate” the meaning of the business requirements into words that can be understood by all.  A good Business Requirements Document (BRD) fosters communications between the business people and IT developers by enabling them to share the common vision that will be translated into a technical solution as part of implementation. It is critical to capture a clear understanding to ensure the “system” meets the expectations of the business people.  Problems often occur when the BA has to communicate across multiple business functional areas.  It can all go horribly wrong if the business people were unable to completely understand what was written in the BRD (especially if it was written with more “techie” terms) – or they never read or approved of the document in the first place.  If the final result of the “system” does not meet the expectations of the business stakeholders – the blame is usually placed squarely on the shoulders of the BA.

Most BAs or their organizations have standardized and streamlined their BRDs and Use Cases so they look familiar, and can easily be interpreted by the developers.  If the developers are able to read and understand the BRD – can the business users?  Often these BRDs are written in more technical terms rather than in business terms with the BA spending more time facing towards IT.  But more often the real question is — “does the BA really understand the business?”  Is what has been written in the BRD captured the real requirements – with the translation having been done correctly?

Rather than facing the developer when creating the BRD, a thorough understanding of the business requirements will help ensure a better result.  There are various characteristics of business people that need to be understood.  They all come in a variety of flavors:  Some are very academic and intelligent while others are very down to earth.  They definitely are not “standardized.”  Often the stakeholders assigned to the project have no prior project experience and therefore no clue of what is expected of them.  Business management often feels that it is the BA’s responsibility to get the correct requirements – not the business team members.  As a result it is important that these team members are continually involved in the BRD process.  In order to understand, verify and help make adjustments where necessary, the process of developing, as well as the final BRD document, should be oriented to the business understanding.  It is a good idea to “walk through” various portions of the document with the appropriate stakeholders as often as possible before finalizing the entire document.  Some of my business stakeholders have said to me through this review process “You wrote what I said, not what I meant to say,” “Did I really say that?” or “I couldn’t have said that – I need to rethink this point.”  I am sure that you have heard similar comments on numerous occasions.

Elicitation

Let’s take a look at the problem of interviewing business stakeholders during elicitation.  The BA asks questions and takes notes that are later translated into the BRD – which is usually written at a basic high-school level (or below).  The BRD usually contains the requirements gathered from multiple stakeholders compiled after many reviews and corrections being made.  I have been amazed at how many business stakeholders only casually read the BRD, if they even read it at all.  When I start to work for the first time with a business stakeholder, I will deliberately include a few minor errors to see if they are caught by the reader.  I realize that some BAs object to such actions because it might reflect poorly on them, but we all need to feel comfortable that the business stakeholders are fully involved in the review process.  We need the appropriate involvement to help us feel comfortable that the requirements that we are developing will result in the proper outcome.  We definitely don’t want to discover the errors at the time of implementation.  There are a few stakeholders who find all our punctuation, spelling and grammar errors – and thoroughly enjoy this level of scrutiny.  Those types of reviews don’t really bother me; at least they are reading it.  I just wish they would also respond to questions and omissions on content – not like my high school English teacher.

My favorite elicitation technique (and one that I personally feel results in the most thorough BRD), is facilitated sessions.  In order to discover and document “group memory,” business stakeholders are gathered and whiteboards, flipcharts, projectors and screen are used to record the results of the discussions.  Since this information is gathered during the session, and remains visible to all attendees, reviews and approvals can be initiated on the spot.  This continual review process is especially helpful when the stakeholders are from different functional areas and have different points of view that require compromises.  You as the facilitator have to be aware of which participants are right-brain (work best with pictures and/or diagrams) and which participants are left-brain (work best with detail written documents).  Often the combination of both types of techniques is needed to gain the necessary group consensus.  After the session has been completed, the results need to be documented and sent back to the participants for future review, as well as providing a starting point for the next session, when needed.  Use of facilitation techniques is very helpful in “translating” the process being analyzed and produces a BRD that is more accurate.

One additional thought – If any stakeholder is replaced, or a new individual added to the team, you can be assured that the business requirements will change.  Even when you have three stakeholders from a single functional area, there will often be three different sets of business requirements.  These three sets are compromised into a single document that is acceptable to all.  Just about the time you feel comfortable that a set of requirements have been completed, a change to the makeup of the team occurs.  Now you will have to go back and gain acceptance of the requirements from all the members of the new team.  If you don’t take the time to review with the new team you run the risk of not meeting the stakeholder’s expectation of the final result.

In summary you have to understand each of the tools and techniques available to a BA for understanding and documenting the requirements effort.  You also have to understand how the final documentation needs to be tailored to each individual stakeholder in order to maximize the understanding of the content.  Only in this attention to detail within the final deliverable can you feel comfortable so ensure that the requirements have not been lost in translation.

Don’t forget to leave your comments below.


Steve Blash is an experienced IT professional consultant providing business and technology leadership, mentoring and vision. His areas of experience include business process improvement, business analysis, business intelligence, data analytics, project and IT management.

Rethinking Asking the Stupid Question

Business Analysts ask questions; that’s what we are paid to do. We are encouraged to be inquisitive, “there are no stupid questions.” We are taught to ask “why” five times to get to the root of the motivation. Most of the time we feel good about asking questions – we’re prepared, we know what topics we want to cover and we know we are talking to the right person. And yet sometimes we realize that no matter how we twist our brain around, what we are hearing doesn’t make sense. It could be as simple as an acronym we haven’t heard before, or as complex as a decision that is so wrong-headed we can’t believe everyone just agreed to it.

What do you do when you have to ask a question you wish you didn’t have to ask? I have seen good business analysts unwittingly shoot themselves in the foot by using this common wishy washy preface.

“This might sound stupid, but…”, or “This might be a stupid question, but …”

Why do we undermine ourselves by prefacing our question or remarks with wishy washy language? The preface says essentially, “I’m insecure about asking this question and I’m expecting you to make me feel bad for asking.” Yes, that’s a harsh assessment – but I’m trying to make a point. You might think that because you are going to interrupt the discussion, the preface is a way of being polite. Is it? Putting the idea into people’s head that you are asking a stupid question nearly guarantees it, which is counterproductive to the importance of your question. Also, you want to save your “stupid” question prefaces for sneak attacks.

There are exceptions to all rules, including the “don’t ever say, “This might sound stupid, but…” rule.  In some situations the clever BA will want to launch a sneak attack by asking “crazy as a fox” question, for example, you perceive that people are going along with a line of thought that doesn’t make sense, and you’re about to bring them to their senses with cogent questions that cut to the heart of the matter. In this case, the wishy-washy preface telegraphs to the group that you’re about to pounce. Telegraphing your intent is a viable strategy to get people to pay attention.

We’ll leave the exception aside, and focus on a better approach to asking clarifying questions that require you to interrupt. In general, say what’s on your mind. It reinforces your credibility to present your ideas with confidence. Instead of flogging ourselves with the idea that “I should know this”, try adopting the Generous Listening attitude. What is a generous listening attitude? It’s the view that we Business Analysts are there to hear the essence of the other person is saying, and to it reflect back so they can hear themselves more clearly. It’s not merely replying “So what I hear you saying is …”, and it’s not asking a bunch of questions to further clarify what they are saying so we understand perfectly what they mean. Generous Listening is listening in a frame of mind that helps a person understand what they have conveyed to you and the group.

On the surface, the Generous Listening paradigm’s advice seems contrary to what we business analysts are told to do; Generous Listening advises us to avoid the questions “How?” and “Why?” questions. Before you dismiss this advice, consider creating a space in your toolkit for new questioning strategies. “How” and “Why” are great questions when appropriate, but they can shut down conversation instantly when you’d rather keep the conversation flowing and growing, and when you are interrupting for a clarifying question, usually all you want to do is get your answer, and let the discussion resume. As we BAs know, asking “How?” when a person does not yet know “What” results in mere speculation.  

Think about your frame of mind when you listen to a discussion. I know I’m listening for flaws in a person’s reasoning, overlooked cause-and-effect scenarios – my mindset is so tuned for critical analysis that I’ve assumed that there’s something wrong before they finish their sentence! Generous listening is the process of getting at the “what” in the other person’s mind and assuming the “what” is there even if they need help articulating it. The question “Why?” tends to spark defensiveness. Even when appropriate, it may be better to say, “Help me understand your thinking on this … “

Generous Listening recommends adding the following phrases to your toolkit to listen generously and expand a conversation:

That’s a great idea!

Please say more about that.

Interesting! What else?

What would that make possible?

What would that allow for?

Tell me more . . .

What would make that possible?

Help me understand . . .

When we ask questions such as, “What would make that possible?” instead of, “What could go wrong?” an entirely different conversation results. Try it! Incorporating these simple phrases will completely change the character of your communications.

Let’s get back to the short interrupt preface phrases.

Not great: “This may sound stupid but, have we assumed that … “

Do you really need the preface? Here are three alternatives.  

Okay: “It sounds like we have assumed that …, is that correct?”

Direct, but could put the person on the defensive: “Why have we assumed that …”

Better: “Would you say more about … , it seems that we have assumed that …”

Here are three additional phrases to use for a quick interrupt:

“I just want to make sure I understand, “DR” in this conversation means “disaster recovery, right?”

“Let me repeat what I just heard, you tell me if I got it right. …”

“Could I just verify what I’m recording for the meeting minutes / for my notes …  “

Tips for asking a question that you wish you did not have to ask:

Keep it simple.
Eliminate the preface, eliminate add-on questions. Phrase the question in words that the group will understand. By keeping questions simple, you avoid inadvertently inserting distractions into the discussion.

When we say “DR” here, are we talking about disaster recovery or a data repository or dead reckoning?”

The form of this question is “A, B or C?” The simplest form of the question is, “A?” Ideally someone will say, “disaster recovery”, you say, “Thanks” and the discussion continues smoothly. Alternatively, if you ask, “A or B”, someone might remember an issue related to the data repository and the discussion will veer off in that direction, leaving loose ends on the disaster recovery topic. Including the ludicrous possibility of dead reckoning adds a touch of humor which could be useful if you are trying to diffuse a tension-laden meeting, but it distracts people from the topic so use that gambit only when needed.

Be relaxed.
When asking a question you wish you didn’t have to ask, don’t make it worse for yourself by telegraphing your unease. Be relaxed, when you ask your question, wait for the answer, then let the discussion carry on. When you are nervous you will increase the anxiety level of the people around you, whether or not they are consciously aware of your discomfort.

Asking questions is our job! When building trust and a shared consensus of reality, making assumptions is the kiss of death. Asking questions, even a question that you are sure everyone knows the answer to except for you, shows that you are paying attention and striving for a solid understanding. Interrupting for clarification can be done without disrupting the flow of discussion and without undermining ourselves.

Don’t forget to leave your comments below.


Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times and most recently the poem, A is for Analysis. See her blog on her personal passion, motorcycle riding, at http://www.balsamfir.com/.
[email protected].

Green Eggs and Ham – a Study in Change Management

“I am Sam. Sam I am.” For those of you who are unfamiliar with the quote, it comes from the book Green Eggs and Ham, written by Dr. Seuss. According to Publisher’s Weekly in 2001, it was the fourth-most popular children’s book of all time. That would lead me to believe that most of us have either had this book read to us in our childhood or have learned to read from this book (some, like me, still read it today). We have been indoctrinated at such early ages to accept change, so why do so many of us react badly towards change? After all, Sam has a mission, and that’s to get the unnamed character to change his behavior. Perhaps, though, if Sam went about it a little differently, we would never have had the book after all.

As BAs, we are often in the middle of changes – application changes, process changes, organizational changes. Let’s see how Sam handles a case of change management, and see if we can learn from his mistakes.

1. Failure to plan the change

Human beings are complicated people (even those asexual creatures in the Dr. Seuss books). Sam barges in and starts announcing something new and expects that our friend will embrace it as much as Sam does. It’s clear that Sam wants our friend to eat the green eggs and ham, and probably thinks that eating them is great, but Sam’s expectation is that our friend will partake of the new treat. It seems that Sam’s strategy is to offer so many ways to eat green eggs and ham that our friend should just change and do it. Consider that it’s not until 7/8 of the way into the book that he finally asks if our friend would just try them. If that strategy to “just try them” was planned at the beginning, the change implementation might have gone better.

2. Failure to communicate the reasons and expectations behind the change

It’s no wonder that our friend who is having green eggs and ham is put off by Sam. He barges in with, “I am Sam. Sam I am.” but with no explanation to our friend about the change. It’s no wonder that our friend is turned off and immediately puts up a defensive wall – he clearly has no idea of what is happening. Perhaps Sam could explain the reason why he is offering the green eggs and ham. “Times are tough, the economy is strange, and the cafeteria selections have got to change. Here’s something new, a nutritious meal, it will give you low blood pressure and abs of steel.” If perhaps Sam explained it that way, our friend would have understood the reason behind the change.

3. Sam should have gotten buy-in from our friend

One of the most effective ways to change is to make the person want to change. If they want to change, they embrace the change. If they feel that they are part of the change, and had a stake in it, they will do everything that they can to see it succeed. Why? No one wants to be on the losing side, and if our friend thought that it was partly his project, he will do what it takes to make the change work. Once he feels that it’s his idea, he’ll want to push forward with the change. If Sam had played his cards right, our friend might have stated, “When we serve everyone this food, who will whine? When after all, this idea was MINE!”

4. Roll it out to the influencers

There is always a group that is highly influential in any group, and they set the trend. If you can get them on-board with the change, then the change is far more likely to happen. The fox, the mouse, and the goat didn’t really do much to help Sam and his cause. But perhaps if Sam had brought in others that our friend trusted (the influencers), they would have “sold” the idea of change as beneficial. Influencers can be at any level, and even at the same level of the people that are going to change – sometimes it helps having that peer allied with the change so it doesn’t give the impression that “big, bad, management” is forcing something upon the masses. Why are so many in the United States driving 4WD SUVs to pick up groceries and take their kids to soccer practice? GM and Ford didn’t push that change on them, influencers in society did.

5. There was nothing in it for our friend

How well did Sam communicate to our friend what the benefit was for eating the green eggs and ham? None, as I recall. Sam just prattled on and on about places to eat them and animals to eat them with, but no clear reward or benefit for our friend. When explaining change, explain how it is going to benefit those that have to make the change. How much more effective would it be if Sam had provided an incentive to eat them. Then perhaps the response would have been, “Hand over the plate, and give me a fork. I’ll proclaim their greatness to ALL of New York!” And remember, not everyone perceives the same benefit the same way – you have to figure out what motivates each team member and what each one will consider a benefit.

6. Not involving the people who were going to have to change

It was clear that Sam knew all about green eggs and ham, but how well did he involve the others in the story? Not much. He basically swept in and announced that green eggs and ham were now going to be eaten. And what is our friend’s immediate reaction? “I do not like that Sam I am” Why do you think that is his first reaction? Well, he may have heard rumors about a horrible new food being introduced, and because those involved in the change management (in this case, Sam) have not involved those who had to change, our friend had no clue what the real story was. Think of your organizational – how quickly do rumors spread when there is uncertainty? By the time that the change is announced, the rumor could be far worse than the actual change. By involving the people that are going to change, they can dispel the rumors and help with the transition.

7. Sam should have led the change, not simply ordered it

Sam was not in a position of leadership; he was more in a position of ordering, or “bossing around.” He was so busy telling our friend how many ways to eat the meal, but did not mention that he ate them himself and liked them. If he could give testimony to their quality, our friend may not be as hesitant. Sam may have said, “I had them last night, they’re quite a good meal; my wife and I loved them, and it made my kids squeal.” Or better yet, he could invite our friend to the meal, and they could all eat them together. If our friend sees Sam eating the green eggs and ham himself (thereby leading), our friend may see that the change is good, and find it easier to go along and make the change.

Obviously, Theodore Geisel (aka Dr. Seuss) had no intention of writing a book about change management, and the message really is to try something new because you might like it. But look how often we reject changes and have trouble with change, especially since many of us grew up reading this book (born after 1960, anyway). It’s not that change is bad; it’s just that it fails because of a poorly executed plan or poor communication. So, to sum up:

  1. Plan the change, and how you are going to roll it out to those that will change
  2. Clearly communicate the reasons behind the change and what the expectations are from those that are going to change
  3. Get buy-in from the people that are going to change – when they want it to succeed, they will do everything in their power to make it succeed
  4. Make sure that the influencers are on board
  5. Explain the benefits to those that are about to change
  6. Involve the people that are going to change, and make sure that they know what is happening and when so as to controls rumors and mistruths
  7. Lead the change – be the first person to change when it happens – don’t lead from behind the front lines

Don’t forget to leave your comments below.


“I am Paul. Paul I am.” Paul Mulvey is a Contract Business Analyst currently on assignment at Cushman & Wakefield. His current assignment has him commuting 4 hours daily on a bus from Eastern PA to NYC, and all he does is just sit, sit, sit, sit, and he does not like it, not one little bit. He can be reached at [email protected]