Tag: Competencies

Use This Simple Technique to Quickly Understand an Organization

Written by Clarence Worrell on August 20, 2015. Posted in Articles.

As a Business Analyst, your work is generally concerned with developing an understanding of an organization, and then communicating that understanding in ways that are efficient and actionable. Use this simple technique, outlined below, to quickly understand the aspects of an organization that are typically of interest to a BA.

MODEL OF AN ORGANIZATION

The technique assumes the following model of an organization:

The organization is engaged in a business
The organization offers products
Product development, production, sales, delivery, maintenance, etc. are accomplished through processes
Processes may include tools, techniques, and deliverables
Processes may be supported by technology

The figure below that illustrates this model:

Using the example of a city public library, let’s examine the model in more detail.

ORGANIZATION PERSPECTIVE

The model is general and applies to organizations at all levels. For example, it can apply equally to any of the following:

A city public library
A branch of the library
The library’s payroll department
The library’s IT department
The IT department’s database team

Each of these organizations is engaged in a different business. For instance:

The city public library is in the business of providing library and information services to residents of the city.
The branch library is in the business of providing a subset of these services to a community within the city.
The payroll department is in the business of issuing paycheques to library employees.
The IT department is in the business of building, operating, and maintaining technology for the library. This technology supports processes (like inventory), tools (like employee email), techniques (like Dewey Decimal System cataloging), and deliverables (like employee paycheques).
The database team is in the business of building, operating, and maintaining databases for the library. For example, it might currently be working on an upgrade to the library’s DBMS.

PRODUCT PERSPECTIVE

One organization’s product can be another organization’s process. Or tool. Or technique, deliverable, or technology.

For instance, the library might purchase new bar code scanners for its inventory management system. From the library’s perspective, the scanners are tools. But from the scanner company’s perspective, the scanners are products.

The scanner company likely has processes for development, production, sales, delivery, and maintenance of bar code devices. For instance, one of its tools might be an automated order entry system.

Let’s say that the scanner company has engaged a consultant to help improve its order entry process. From the scanner company’s perspective, the order entry process is, unsurprisingly, a process. From the consultant’s perspective, the order entry process is a product. And so on.

THE TECHNIQUE

The technique is this – Make a table using the following template, which is based on the organization model. Fill it in with information about the organization. Discover this information using whatever techniques are at your disposal (observing operations within the organization, conducting interviews with employees of the organization, studying documentation, etc.). This may or may not be easy to do, but the “doing” is the most important part; it is where you will organize and clarify your thinking about the organization. (However, the resulting artifact may itself be useful, as described later on.)

Following is a partially completed table based on the public library example:

SOME USES OF THE TABLE

Scenarios in which this technique could be useful to you, as a BA, include:

You are starting a new job, either with your current employer or with a new employer: Use this technique to assess what you need to know in your new position.
You are assigned as a consultant to a new client: Use this technique to develop a high-level summary of the client’s “as is” organization.
You have just hired on with an IT startup: Use this technique to identify what processes, tools, and technologies are currently in place, and which ones need to be defined.
You are job hunting: Use this technique to define the gap between an advertised position and your own competencies; this is a variation of assessing training needs.
You are asked to assess the training needs of your team. Use this technique to define the gap between team member competencies with respect to your team’s products, processes, tools, etc. Simply expand the table to include columns for each team member. Enter an assessment of each team member’s competencies and clearly assess where the training needs are.

An example of a training needs assessment, using our library example, could like like this:

From the training assessment table, we can surmise the following:

Arjun has the greatest training needs. It looks like he may be new to library work. It also looks like he is new to Scrum.
Anna has need of training in the Conference Room Reservation System (maybe she has previously specialized in the Inventory Management System).
All three team members are in need of training in use case modelling.

THAT’S IT!

The model and technique are pretty straightforward. I’ve found it useful in various settings but also have gotten into seemingly circular arguments about it. For example: “Why isn’t there an arrow from Technology to Products? Technology supports Products, right?”
If you find that the additional arrow helps, by all means use it. In my thinking, though, each Product is ultimately a Deliverable of some Process. Since Deliverables are supported by the Technology, no arrow is needed.

In any case, I’d like to hear your comments about (and criticisms of) the model and the technique! I hope you find it useful.

Business Analysis According to Sherlock Holmes

Written by Steve Blais on April 28, 2015. Posted in Articles. 1 Comment on Business Analysis According to Sherlock Holmes

I have been reading and rereading Arthur Conan Doyle’s stories and novels about the brilliant detective Sherlock Holmes for years. With the possible exception of Edgar Allen Poe’s lesser known Auguste Dupin (see The Murders on the Rue Morgue), Holmes stands as the pre-eminent and archetypical critical thinker and detective of all time. Sherlock Holmes provides the model for all the genius eccentric crime solvers who occupy the books, airwaves, and movie theaters of today. Holmes has a lot to say about how to analyze information and evidence and deduce the best solution or the perpetrator of the crime.

Sherlock Holmes is one of the charter members of the Business Analysis Hall of Fame. He has left a vast legacy of advice and counsel to business analysts of all ages. Herewith, direct from 221B Baker Street, are the words of wisdom from Sherlock Holmes.

“Approach the case with an absolutely blank mind, which is always an advantage. That way you formed no theories. You are simply there to observe and to draw inferences from your observations.” (Adventure of the Cardboard Box)

The business analyst needs to be objective. The business analyst cannot have preconceived notions, including those foisted on them by the customer, sponsor, or subject matter expert. When eliciting information the business analyst listens naively and asks questions without prejudice (see the series “How to Ask the Right Questions”, especially part 4: “Asking the Naked Question” for more information about listening naively). When the business analyst comes to an interview with a solution in mind, for example, one proposed to them by the sponsor or another stakeholder with political clout, the business analyst will tend to ask questions and hear the answers that support the solution and ignore or discount any information that may cast doubt on the solution. This is called confirmation bias. Sherlock Holmes cautions us against such behavior if we want to be top notch business analysts.

“It is a capital mistake to theorize before one has data. One begins to twist facts to suit theories, instead of theories to suit facts.” (A Scandal in Bohemia)

This is Holmes’ way of saying “Don’t jump to solutions.” A business analyst should look for more than one solution to a business problem. Once a solution has been established, ask “is there any other way to solve this problem?” In that way we keep ourselves from accepting the first, and not perhaps the best, solution that comes to mind. Looking for that second or third solution also forces us to seek out more information, some of which might invalidate the original solution (that is also a reason for not seeking additional information: it might prove our initial solution wrong, and who wants to be proven wrong?)

“Nothing clears up a case so much as stating it to another person.” (The Silver Blaze)

The Silver Blaze was a race horse and presented a challenging puzzle for Holmes. At one point he asks Watson to listen to him while he “enumerates over the facts of the case.” He knows that verbalizing what is in our heads forces us to focus on what we are saying and how we are saying it. We are trying to get the pictures and concepts in our brains into the brain of someone else and will tend to make those concepts simpler and clearer. And so he does. And so should we. Before conducting an information gathering session, perhaps it is a good idea to ask another business analyst the questions you plan to ask the subject matter expert or another stakeholder. Hearing the questions aloud might cause you to restate a question or two, or not ask them at all. You might also verbally walk through your solution, or your requirements, with another business analyst before committing the solution to a formal document for submission. And if you are creating user stories in an agile environment, reading them aloud is not just a good idea according to Sherlock Holmes, but also from others including the “inventor” of user stories, Ron Jeffries.

“There is nothing more deceptive than an obvious fact.” (The Bascombe Valley Mystery)

There are “facts” that everybody thinks they know. One of the more common is “It’s done this way because it’s always been done this way. It’s the only way to do it.” The business analyst is aware of the ‘fact” that cannot be proven, but must be taken as truth. In The Bascombe Valley Mystery, Holmes is responding to Watson’s claim that the evidence as reported is somewhat condemning to their client. Holmes points out that evidence, especially circumstantial, points in one direction, but with a little shift in your point of view, you may be looking at something completely different. It is similar in business analysis in the pursuit of a solution. The solution that everyone seems to agree to may not be the best solution when all the facts are in, including those facts not in play at the moment. In theory, those thinking the solution is best assume that all the facts are known.

“When you have eliminated the impossible whatever remains, HOWEVER IMPROBABLE, must be the truth.” (A Study in Scarlet)

“It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth.” (The Beryl Coronet)

“We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth.” (The Adventure of the Bruce-Partington Plans)

These similar quotes refer to the method that Sherlock Holmes uses to solve a mystery. He begins to construct theories based on the data that he has in front of him. He is creating alternate solutions to the problem (the problem, of course, is to figure out who committed the crime and how was it committed). He then looks for more data or evidence that will either further confirm or eliminate each theory. Eventually, through a logical process of elimination, Holmes has solved the mystery. As business analysts we can perform a similar process of elimination by starting with the facts, confirming those facts, and then forming potential solutions. Then our investigative job becomes one of gathering information to disprove or eliminate each solution. As solutions are eliminated based on evidence gathered, we can determine the one, best solution. (Note that if all potential solutions are eliminated, we need to go back and re-theorize.) As Holmes says:

“If the fresh facts which come to our knowledge all fit themselves into the scheme, then our hypothesis may gradually become a solution.” (The Adventure of the Wisteria Lodge)

“A further knowledge of facts is necessary before I would venture to give a final and definite opinion.” (The Adventure of the Wisteria Lodge)

In this piece of advice, Holmes is suggesting that we hold off on rendering opinions or conclusions until we have enough information to do so. In many of his adventures he had the solution to the mystery in mind (his predominant theory, for example) and refused to disclose it until he got that last piece of evidence that confirmed the theory beyond doubt. We should be as careful about advancing our solutions until we are sure of them based on the information. (Or to quote someone from a different world altogether: Davy Crockett said, “Be sure you’re right, then go ahead”)

“Education never ends, Watson. It is a series of lessons with the greatest for the last.” (The Adventure of the Red Circle)

As brilliant as Holmes was, he never stopped learning. He admitted when he made a mistake, immediately recognizing what that mistake was. You get the feeling that once admitted he would never make that same mistake again, or perhaps not make even a similar mistake. For example, in “The Adventure of the Stock Broker’s Clerk”, Holmes and Watson enter a room to confront their suspect who is sitting at a table reading a newspaper. Upon seeing them, the suspect races into the next room and attempts to hang himself. Holmes is at first mystified that the fellow would attempt suicide at their appearance. Later when the man is revived, the motive for the suicide becomes apparent. It was something he read in the paper. Holmes then exclaims, “The paper! Of course! Idiot that I was! I thought so much of our visit that the paper never entered my head for an instant.”

Sherlock Holmes had a lot more to say that still resonates across the decades to us, advice that can be applied to our day-to-day work as business analysts and critical thinkers.

If we could all be like Sherlock Holmes, Conan Doyle’s protagonist would never have achieved the publishing success and lasting fame that Holmes has enjoyed for over a century now. We don’t have his remarkable ability to eradicate the emotional, eliminate the irrelevant, and focus with laser-like intensity on the given problem. We don’t have Holmes’ amazing powers of observation. (He could distinguish 75 different perfumes (The Hound of the Baskervilles) showing that he even brought his sense of smell into his observations). However, we can learn to better examine the information we receive with more critical thinking and withhold our judgment longer when evaluating that information. We can learn to restrict our observations more to the evidence that exists rather than what we think exists, or what we have been told.

While we are pursuing the best solution to the business problem and endeavoring to add value to the business through improving processes and solving problems, we might find we are doing a better job of it if we remember and apply the acronym WWSHD: “What would Sherlock Holmes do?”

Don’t forget to leave your comments below.

Why Are We Still Talking About PM vs BA?

Written by Kupe Kupersmith on April 13, 2015. Posted in Articles.

12 years ago when the IIBA began to form, many debates were had over what the project manager did on the team vs. the business analyst. I am sure the conversations were around before then. And I am shocked there is the same amount of discussions still going on today. It may be because I have a heightened awareness, but I dare to say there are more conversations happening today. Here are some examples of recent activities that sparked this blog.

I recently participated in a LinkedIn Group discussion where people debated the role of a Project Manager and Business Analyst. A majority of the group felt there should be two distinct roles and most had definitive answers on what a PM does and what a BA does. And there were differences in opinion. Another LinkedIn discussion was started by a question, “Should BAs be a little data scientist?” The poster went on to ask “Isn’t it about time that BAs should upgrade their skills to be associate data scientists?” Some respondents felt a strong need to clarify what a Business Analyst does.

The problem is the focus is incorrect in discussions about what a PM and BA should do on a project. It causes people to think in terms of absolutes. Unnecessary and unhelpful debates are had about the roles and people begin defending and protecting titles and job descriptions. Why is this mindset a problem? Very little, if anything, is accomplished by having the debate. The goal for teams is better outcomes to improve the business for which you work. Each individual on the team should have the same goal. In addition, people in the PM and BA field are not robots. All people have different strengths and weaknesses. To assume someone with a title of Project Manager does certain tasks and a person with the Business Analyst title does other tasks is just crazy. And if those conversations don’t put me over the edge, I start talking to people about what a junior analyst does vs. a senior analyst…what does a jr. PM do vs. a senior PM?

And these types of conversations don’t end with just the PM and BA. What about BAs and testers, Developers and DBAs, System Architects and Business Architects, moms and dads. At a macro scale it matters less than thinking about this at a micro scale. Talking about specific job descriptions at an industry level yields little results. At the team level, team members need to understand what capabilities they need to be effective and who on the team has those capabilities. This has to be done regardless of one’s title. Teams need to identify what capabilities they are lacking and fill the gap. That can be done through training and/or bringing in new team members.

What it boils down to is the focus should be on collaboration. Don’t think about your team in terms of roles, think in terms of capabilities. The focus needs to be on capabilities of a team, of an organization, not specific capabilities of a title. These two pictures created by my colleague, Kent McDonald, illustrate what I mean. Don’t create and assign tasks based on what is shown in Figure 1. Be more like figure 2.

Figure 1: Team built based on roles or titles

Figure 2: Team built based on capabilities

Does a CIO or the business leaders you work with care that independently you have a good BAs or good PMs? No way. They want teams to deliver outcomes that help move the business in the direction they want. You need to consider yourself a team member first. This means you will do what is necessary for team success. Second, think about how you can best help the team succeed. What skills do you bring to the table? Don’t think in terms of I am a Business Analyst and I have a job description listing 15 tasks so that’s what I can bring to the team. Work hard and work unselfishly.

All the best,
Kupe

Don’t forget to leave your comments below.

4 Key Skillsets of Seasoned Business Analysts

Written by Deepak Singh on June 23, 2014. Posted in Articles. 1 Comment on 4 Key Skillsets of Seasoned Business Analysts

Why are some business analysts better than others? Is it only experience that sets the best apart from the rest or there are some other qualities that separate the “men from the boys”? How do the most successful analysts implement the necessary changes in an organization and make it a habit to recommend solutions that deliver incremental value to all stakeholders of the business?

The answer to all these question lies in some of the core skillsets these analysts bring to table. Let’s take a closer look at 5 competencies that drive the ability of these business analysts to provide results driven answers to organizational problems.

1. The Ability Ask Questions and Getting the Right Answers

Questions are all about eliciting requirements from the users.

These requirements include functionalities, knowledge of products and/or services, market conditions or any other business activity that has the potential to propel growth. These requirements are tied in to the needs of the business, primarily the need of the business to grow and prosper. The job of a business analyst is to identify what the business wants to achieve; and for that to happen they must be able to gather the necessary requirements to get a deeper understanding of a problem/s holding back the business from achieving its goals or a growth opportunity that the business wants to explore. This allows them to get hands on all the data required to thoroughly make sense of a particular problem and suggest the right solution for it.

This is where the core competency of an analyst kicks into play a role – it is called ‘elicitation’. The best analysts don’t just elicit information using a variety of techniques but they also anticipate, quantify and resolve problems with these requirements. They blend risk management with their penetrative elicitation techniques ensuring they have a clear idea of the fallacies, if any, regarding the requirements on hand.

So, at the end of the day, what they’ve in their hands is the right information that is at the very top of the priority matrix and which has been vetted for accuracy.

2. They are Active Listeners

The process of elicitation involves business analysts asking relevant questions. You might be saying to yourselves, “but I also ask questions”; good, but do you listen to answers, that is really listen to answers? You will have to be an active listener if you want to be a good business analyst. These are the kind of listeners who pay attention and also ensure people know they are listening. They avoid being distracted and take in everything a person is saying without missing a beat; at the same time they provide the necessary encouragement to a person to speak his/her mind. Active listening skills are right up there in the armory of the best business analysts. This allows them to get a truckload of information out of project/business stakeholders.

3. They Don’t Shy Away from Doing the Hard Yards – Documentation

Once you get a truckload of data that covers all the requirements of a business, you need to set about preparing a business requirements document (BRD). Here’s a secret – Even the most experienced business analysts shy away from this task. But they got to do it and many do it in a halfhearted manner. That is not to say that they don’t produce a comprehensive BRD but there is marked difference in output if you have a degree of interest in the job you are doing.

The really successful business analysts consider BRD an integral document in the process of business analysis and make every effort to prepare it to the best of their ability. Each and every aspect of the requirements whether it is functional, non-functional, regulatory or user driven is covered in its deepest detail in this document. Think of this doc as the ready reckoner of a business’s intrinsic requirements and something that offers you clearer insights on what the business wants to achieve and how to go about achieving these goals.

A comprehensive BRD brings the following benefits to the table:

It tells the organization that the business analysts have a very clear idea of the requirements.
It acts as a guide for systems professionals to create the necessary solution that satisfying these requirements.
It identifies the customer/business needs that will be satisfied with a solution for the same.
It allows the different stakeholders of the business to get a detailed overview of the requirements cutting across the organization, allowing them to get their bearing rights about where they want the business to go.

4. Technically Astute

There is a raging debate whether business analysts need technical fluency. The fact is no knowledge technical or otherwise can ever be enough for a business analyst. They need to keep adding new skillsets to their armory which can help them become better at their jobs. The top business analysts are where they are because for them learning never stops and it’s a continuous process. This allows them to learn new tools of the trade; this includes the necessary IT knowledge that allows them to better analyze organizational requirements. This is necessary because most organizations today cannot survive without a robust IT infrastructure in place and many of its requirements can only be satisfied by facilitating specific IT upgrades.

But what if a business analyst has very little technical proficiency? Interesting question and it can’t be answered with a “don’t worry” or “that’s not an option”. The degree of technical proficiency, whether IT or any other, required from business analysts is dependent on the industry vertical that they are working within. If it’s an IT organization, a business analyst’s lack of knowledge about the industry in general and inability to understand the workings of the organization’s products and services will be laid bared during his analysis. In such cases, a degree of fluency in IT is a must.

But this is not really an absolute necessity. If you are able to define the various resources that will help you not only identify but also authenticate requirements and specifications related to a particular project, you’ve done your job. Understanding the technical aspects that are driving the business is a huge bonus. But hey, if you want to be really good at what you do, no harm in getting a bit of technical knowledge under your belt is there?

Conclusion

Seasoned business analysts don’t do anything different; they just do what they must with sufficient passion and enthusiasm. They are detail oriented and are committed towards offering the best possible services to an organization. This, at the end of the day, is what makes them so effective.

Don’t forget to leave your comments below.

7 Habits of Highly Effective Business Analysts

Written by Angela Wick on June 9, 2014. Posted in Articles.

Highly effective BAs, regardless of their skill level or years of experience, consistently hone their craft. Guided by curiosity and passion, great BAs are always on the lookout for growth opportunities—ways to strengthen and sharpen their skills.

This focus on continuous professional improvement goes far beyond attending an annual conference or workshop. Instead, effective BAs develop daily habits that demonstrate leadership and expertise.

So, I’ll borrow Stephen Covey’s popular “seven habits” framework to discuss the recurrent behaviors that support excellence in the business analysis profession.

Although I refer to these as BA habits, they can be applied to most professions. So, whether you are a project manager, a tester, a techie or a trainer, think about how these habits can help you become a leader in your organization.

Habit #1: Effective BAs engage stakeholders.

BAs need information, cooperation and trust from their stakeholders. Skilled BAs get what they need by building strong relationships. They engage stakeholders in a way that inspires engagement, creativity, collaboration and innovation.

How do you know if your stakeholders are engaged? Well, these are common issues on teams with weak stakeholder engagement:

Strongly conflicting requirements between stakeholders.
Stakeholders are silent; roll their eyes, sigh or multi-task during meetings.
Stakeholders do not contribute to the project. They don’t return phone calls, do not reply to emails, do not review project documents, provide resources, etc.
Stakeholders show up late for meetings, leave meetings early or skip meetings.
Disparate groups do not understand other stakeholder’s needs and benefits from the project.
Progress is slow.
Discussions loop in circles.
Decisions are difficult to obtain.

Do you see any of those things happening consistently in your organization? Effective BAs use their influence to create an environment that looks more like this:

Stakeholders have a shared vision and can communicate the vision to their team/s.
Stakeholders understand their connection to each other.
Stakeholders trust each other and the BA.
Stakeholders enthusiastically participate in meetings.
Stakeholders make themselves and their resources available to the BA as needed.
Questions, discussion and meaningful debates.
Proactive, 2-way communication

Habit #2: Effective BAs research new techniques.

Great BAs love discovering new tools that make work efficient, valuable and maybe even fun. Experts estimate there are more than 500+ BA techniques in use today—literally lurking around every corner. Here are a few ways to find them:

Read the BABoK! The IIBA’s comprehensive handbook describes 40 of the most common and useful BA techniques. Current IIBA members can get a sneak peak at BABoK 3.0 by participating in the public review process.
Attend industry conferences and workshops. Full-day or multi-day training sessions give BAs exposure to a variety of new techniques, trends, and methodologies. Many training companies and universities offer BA training. IIBA and PMI sponsor events across the world.
Network. Connect regularly with other BAs. Ask them about new techniques. Find out what works on their projects. Solicit advice when you hit road blocks.
Observe others. Find a mentor. Watch your peers. Which techniques do they use regularly? Are they working? Why or why not? How could you make them better?
Borrow from other industries and professions. The most obvious example may be the lean processes project teams have borrowed from manufacturing. Are there techniques you could borrow from an elementary school teacher, a farmer, a scientist or an actor? Definitely!

Habit #3: Effective BAs experiment with new techniques.

Now, it’s time to put those new techniques to work! Stagnation and boredom are the enemy of an effective BA. Applying new techniques keeps BAs motivated, engaged and inspired.

Experimentation often invites risk, but there are many ways to contain possible fallout:

Start small. Try a new techniques on small, low risk projects. Apply the new technique to a small part of a big project.
Break it down. Find a way to break the new technique in pieces. Try one piece on an analysis or elicitation effort to see if it is works. Then get feedback and adjust course if needed.
Find your friendlies. Use a new technique with a small, friendly group of co-workers. Encourage them to give you honest feedback.
Set expectations. Let stakeholders know why you are trying the new technique.
Ponder plan b. Courage to try new things includes the possibility of failure. Think about the worst case scenario. What’s your plan b if the new technique fails?

Habit #4: Effective BAs plan to re-plan.

I run into so many BAs that get stressed out by estimating requirement deliverables. They often ask, “How can I estimate when I don’t have any requirements yet?” My answer: “We plan to re-plan!”

As the project needs and scope evolve, effective BAs revisit their estimates—they reevaluate and adjust as the project moves forward.

Every BA leader and PM I have talked to about this agrees. It’s totally fine to change the estimate and re-plan, just not at the last hour!

So, set expectations and share them.

Make sure the PM and other leaders understand that this is your best estimate based on the current state of the project.
Help them understand which factors will increase or decrease estimates.
Plan resources: What can you do in the early stages of the project to anticipate estimate changes? Who can you pull in if you get behind? What tools can you use to be more efficient? How can you manage busy SMEs to get good requirements?
Look at the value and risk of scope items and adjust the plan accordingly to spend more time on high value and high risk items.
If your incentives are based on estimation accuracy, then talk to your leader about re-planning and how it fits in the incentive plan.

Effective BAs know that re-planning will be required to protect the project value. They look at the tasks and deliverables like puzzle pieces that need to be flipped, turned, and shuffled until they all come together in their proper place.

Habit #5: Effective BAs use visuals, often.

In most cases, visual communication is more effective than text-heavy documents or verbal descriptions—humans process visual information more quickly and completely. Effective BAs understand the importance and efficiency of visual communication. They always look for new and improved ways to use visuals in their meetings, presentations and documentation.

Skilled visual communicators:

Create high-level conceptual visuals, low-level detailed visuals and everything in between.
Tailor their visuals to meet the needs of their audience. Does a CEO want to review a 20-page process model? Does a group of SMEs want to focus on the whole organization or just their piece of the pie?
Draw spontaneously on white boards when discussions start spinning.
Use visuals in virtual meetings too. They use virtual whiteboards, post-it notes, flow charts, etc.
Know that visuals do not need to be perfect. You don’t need to be an artist. You don’t need 100% accuracy on day one. A flawed visual is so much better than starting with a blank page.

Habit #6: Effective BAs develop Underlying Competencies.

Obviously, BAs need techniques and tools to complete their practical tasks, but they also rely on underlying competencies. The techniques are like the tools in the tool box, but underlying competencies (UCs) influence how the tools are used and how the techniques are applied. UCs are the artistry, the finesse, or the soft skills.

Effective BAs continuously refine their UCs in many of the same ways they develop techniques: research, training, observation, experimentation, etc.

Effective BAs maintain dozens of UCs, but here are a few of the most important:

Critical thinking and Problem Solving
Teaching
Leadership and Influence
Facilitation and Negotiation
Personal integrity
Organizational Knowledge

Habit #7: Effective BAs consider politics.

Politics exist in every organization.

In project work, politics usually play out during prioritization efforts: which work will get funding, whose projects fit into an implementation, which requirements get cut.

Skilled BAs don’t ignore politics, but they avoid playing. They work around and within them.

How do effective BAs walk this fine political line? How do they understand and manage politics without getting involved? Good questions. Here are a few ideas:

Build wide support to eliminate politics as a factor.
Always redirect the team back to the project value. Which requirements, timelines, bug fixes, testing strategies, etc. best support the goals of the project and value to the organization?
Gather data. In many cases, good data can tell as story that transcends politics and makes the right answer obvious.
Lead with empathy. Understand what each stakeholder is seeing, hearing, thinking, feeling. Use these insights to help you influence each stakeholder.
Understand the definition of success for each stakeholder.

Which habits make you a highly effective project professional?

Don’t forget to leave your comments below.