Tag: Business Analysis

Process Approach to Requirements Gathering

Written by Mani Ramasarma on May 4, 2015. Posted in Articles.

This blog was supposed to be on requirements elicitation techniques, but it ended up being an example of what peer review does. I finished my blog and handed it over to my colleague for feedback. He pointed out that I assumed people knew how to gather requirements for them to start using the techniques mentioned in the blog. In other words, the blog on techniques was a step ahead, and I should first explain the approach. Ouch! The bump on my head still hurts. So, here we go.

I interview many candidates. Whenever I ask “How do you approach requirements session?” the answers invariably include something akin to “I use JAD session” or “I shadow users”. JAD (Joint Application Design), shadowing, interviewing, and brainstorming are techniques used AFTER you have an approach. Think of it this way. You decide to go on a vacation. How do you approach it? You don’t start with “I will drive” or “I will fly”. These are ways (techniques) by which you reach the destination. The first thing you need to do is decide where to go, when to go, and how to go (approach). The series of steps you take (approach) has to precede the decision to drive or fly (technique). There is a very fine difference.

So, how do we plan an approach to a requirements gathering session? Do we call for a meeting and ask the business user “ok, so what do you want?” or “I am ready, go ahead and list your requirements?” Don’t be surprised if you get a very lengthy grocery list! To avoid such mishaps here is a process-based approach to requirements gathering.

The first point in my last blog was “Do your homework”. The first step as part of homework is to understand the organization and the unit. This understanding provides the big picture so that the goals of the requirements that are to be gathered align with the goals of the organization and unit. Next is to understand the business under consideration, and the scope of the system being worked upon. There are many avenues to it. One of them is to get hold of an AS-IS process diagram.

Start from a high-level process. Some call it “Level 0” or “L0.” Drill down from here to the lowest level possible – L1, L2, L3 and so on (do not confuse this with support levels). Normally you would achieve this by L3 or L4. If AS-IS diagrams don’t exist, your task is to create them.

A mature organization typically has all the “as is” processes documented. Go over it. Go over any other document related to the system that may be available – business bequirements focuments (BRD), functional specifications documents (FSD), user manuals, data flow diagrams (DFD), entity relationship diagrams (ERD), and DDD (sorry, I just created that one!). Get access to the test system and play around in the sandbox – see what it does, see what it doesn’t do. Talk to the technical people. Sometimes they know more about the business than the business users themselves. Ask for a walk-through by technical and/or business folks. If you have a knowledgeable lead, talk to them. By now you should have a good understanding of the way business is conducted. As you assimilate information, note things that don’t seem right. Always remember your title – Business Analyst – so make sure that you are always trying to analyze as you proceed.

Armed with enough knowledge, proceed to capture the “to be” process. Remember, you are documenting only the “to be” process and not the requirements. A common pitfall is to embed requirements in process documents. Be sure to avoid it.

Make a copy of the “as is” process and mark bottlenecks, pain points, workaround’s, manual processes, and non-value add processes. See if you can measure lead and lag times between points in the process. All the current weaknesses should be resolved in the “to be” process in addition to any new functionality or change in the process itself. Beware not to resolve a process inefficiency by automating it. You will be automating inefficiency.

Again start from Level 0 or L0. Make necessary changes. Each of the tasks define your high-level requirements. Here is an example of a L0 procurement process in a bureaucratic organization

Use the gathered requirements to prepare your high-level BRD.

Each of the boxes can further be broken down into next level processes. For example, the first task can be decomposed into

Again, each of the tasks can further be elaborated (here is a buzzword for the interviews – Functional Decomposition). Here is what it may look like, assuming that we go all the way to the lowest level possible (do not magnify the picture. It is there for illustrative purpose only):

At each level look for opportunities to eliminate both the deficiencies (what is missing) and the inefficiencies (what isn’t needed) in the current process. Keep this maxim in mind while redesigning processes – the shortest distance between two points is a straight line. A straight line is not always practical or feasible, but use it as a guideline to streamline the processes. Even if you manage to eliminate or refine one or two steps, it can result in significant time and cost savings.

The hazy little light blue rectangles in the diagram above specify the system that performs that particular task. The diagram also includes manual tasks, reports, and emails. Check if you can automate manual tasks, and whether consecutive manual tasks can be replaced by a workflow. Again, do not automate inefficient processes. Deal with reports separately. Once the “to be” process is documented, have it validated by the business users. Validation is mandatory. It is so mandatory that I will say it again – it is mandatory to have these “to be” processes validated and approved by the business users. What you are left with is a bunch of tasks at the lowest functional level. It is for these that you need to gather functional requirements.

There is one more step you need to do before diving into the requirements gathering process – organize a requirements elicitation kick-off session. Invite business users and the technical team members. Highlight the importance of requirements, characteristics of a good requirement, what has been achieved so far, next steps, and the need for continued user participation and cooperation. The most important component is listing and explaining a good requirement. What are the characteristics? Here is a website that explains it really well. (The next blog will address this and requirements gathering techniques). There are some good examples on the website of how not to write a requirement, which is equal in importance to how it shall be written (a touch of BA humor there!).

The following diagram summarizes the approach

We are ready to launch into the requirements gathering process. That bump on my head is now better.

Don’t forget to leave your comments below.

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.

Can You Develop Standards That Embrace Both Agile and Traditional Approaches?

Written by Angela Wick on April 28, 2015. Posted in Articles. 2 Comments on Can You Develop Standards That Embrace Both Agile and Traditional Approaches?

In recent years, we’ve seen even the most conservative, tightly-structured organizations begin to experiment with agile and hybrid approaches. These organizations have a long and comfortable relationship with the traditional waterfall approach, but their curiosity leads them to dabble in agile. Where does this leave their well-defined and well-protected organizational templates, standards, and best practices?

When these traditionally waterfall organizations add agile teams or transition to an agile approach, interesting things happen. I have seen and heard all of the following:

Teams say, “We don’t need templates because we are agile.”
Team leaders say, “We just need a waiver for agile projects to skip the templates.”
PMO Leaders say, “But we need standards and consistency!”
BAs are confused about their role and responsibilities!
Traditional BAs start projects with standard templates and then re-shape details into user stories.
Agile BAs build story maps and user stories with the team and then re-shape details into traditional requirements templates.

The confusion about governance, templates, standards, best practices, roles, etc. turns most agile teams into castaways, isolated from the rest of the organization or PMO like this:

Or they get chucked out in the rain like this:

The move to agile causes everyone to question the importance of standards, templates, and project processes. Are they still relevant? If we don’t use templates, where do we document details? Do we need to document? Can we have the same standards for all project approaches?

I realize some people think the words agile and standards should never be written in the same sentence. Standards may seem completely antithetical to the agile mindset. However, we need to consider the purpose of standards and challenge how they evolved to become so rigid and ill-suited for most projects.

We know that appropriate standards provide many benefits to organizations including:

efficiency, consistency, quality
a common path to shared understanding
shared lessons-learned and best practices
strengthened corporate culture and values
reduced legal and regulatory risks

So, how can we bring agile to the mainland? How can we get agile out of the rain? Many people would assume that agile projects need their own standards:

But why would we build, manage, track and apply two completely different sets of standards for requirements, especially considering it’s rare that modern-day projects align 100% with any one methodology? In fact, most projects exist in some type of limbo-hybrid, where each part of the project team does what makes the most sense, or more commonly, what they perceive as most comfortable. (We’ll save this topic for a future blog!)

Some will question if it’s okay to have a hybrid model. Is that really following agile? Are we getting the benefits if we are not really 100% agile? What is 100% agile? Manifesto, Principles, or following an agile methodology? Can we follow agile principles and uphold standard governance all at the same time? Is there a middle ground where we can leverage the best of multiple approaches while balancing organizational culture, risk, value and pace?

So here’s the challenge: Can we work toward a single set of organizational standards for requirements?

Can we build requirements standards that apply to all projects regardless of methodology? Yes and yes!

If we elevate our standards, we can identify core components for every project. Here are a few suggestions:

Identify universal truths. Elevate your standards by stripping away the details related to methodology and focusing on the purpose and goals of your solution development process. Review your current standards and templates and understand their function and value. What risk do they minimize? What regulatory requirement or corporate policy do they satisfy? Is the policy needed? Consider corporate culture and core values and how your requirement process should support them, accept what the cultural limitations are, and yet push the organization where it can be pushed for positive change. Look at the timing and detail required: question if they matter based on purpose and goals.
Identify universal constraints. Regardless of approach or methodology, every organization operates under at least a few widely accepted constraints. What are your financial, physical, political, cultural, regulatory constraints? Are they real or assumed, temporary or long-term? Use the real, long-term constraints to elevate your standards above the details related to methodology.
Decouple. Standards may not include details related to format and timing. Let go of standard assumptions about when and how tasks need to be completed. Remove standards that require specific deliverable created in a specific format or tool. Also, look at timing and stage gates. Stage gates are typically about a certain document, and perhaps level of detail, at a certain time. Stage gates could be about shared understanding and other attributes of decision making. Challenge what we currently view as the purpose of the stage gates and what is really needed to make good decisions. Good decisions are based on shared goals, shared understanding, and understood risk; they are not based on fear of something not getting done or someone not following through.
Redefine good requirements. Focus on quality, value, and purpose. Any requirements properly decomposed, organized, and elaborated can work. Good requirements communicate the context in terms of users, processes, and data. Standards should not define how and when requirements are written, instead standards should focus on users impacted, user goals, and decomposition of detail. Agile and waterfall requirements seem so different, but good requirements are fundamentally the same regardless of approach and methodology. Teams can deliver good requirements in many formats, and different levels of detail at different times. The more complex the projects and solutions are, the more adaptable we need our requirements process and standards to be.
Share techniques and tools. Don’t put limits on techniques and tools. Don’t categorize them by methodology. Be open to using the appropriate technique or tool needed to meet the needs or address the risks for each project. Story maps and user stories can be used for agile or traditional projects, and process modeling may be needed for both types of projects too. It’s only the timing and format that are different. Many traditional BA techniques (process modeling, scope modeling, etc . . .) need to be used in agile approaches as well. The timing, detail, and collaboration looks different, but the same technique in concept is used.

We use techniques and models in both waterfall and agile projects, but not at the same time or at the same level of detail. Though agile projects might present requirements in the form of sticky notes, whiteboards, a tool, or a SharePoint library of user stories, does that really require a unique set of standards vs. the waterfall word templates? The approaches seem so different, but fundamentally, the standards are the same.

So, what do you think?

Can you envision useful standards that apply regardless of methodology?
Do you think requirement standards are still relevant and important for organizations?
What are the consequences when we allow projects to operate outside of standards?

As always, please share your thoughts in the comments below!

Don’t forget to leave your comments below.

Business Analyst Skills – Overview

Written by Mani Ramasarma on April 20, 2015. Posted in Articles.

In my previous post I promised to list the skills a Business Analyst must have. While there are many qualities/skills required I list only those that are critical. After all, there is no “ideal” BA!! Before I do that let me briefly discuss the types of BA’s as the skills differ slightly for each.

BA’s can be classified into 4 types – Operational, Project, Enterprise, and Strategic. An operational BA is responsible for one or more systems that are currently in use. This person analyzes issues, prioritizes them with business users, coordinates with the technical team and ensures the issue is fixed. The original BRD/FS is appropriately updated. A project BA, as the name suggests, is part of the project team to build or implement a new system. An enterprise BA has a cross-functional view of the organization. A “go-to” person when the project cuts across multiple business units or functions. A strategic BA is more of an advisor/consultant interacting with the business constantly and guiding them in making long-term decisions related to business processes or systems. What skills must a BA in general possess?

Google for BA skills and you will find plenty of them – “4 key skill sets for a seasoned BA”, “8 BA skills for success”, “The Top ten skill sets for a BA” and so on. I listed some of the skills in my previous blog, which I repeat here in greater detail. A few more skills are also added to the list. Again, these are based on my past experience and are common to most situations. Additional skills will be required for different situations.

Active listening. It is a communication technique used in counseling, training and conflict resolution, which requires the listener to feed back what they hear to the speaker, by way of re-stating or paraphrasing what they have heard in their own words, to confirm what they have heard and moreover, to confirm the understanding of both parties . Communication is incomplete if the listener does not comprehend what is being said. Re-stating and paraphrasing is an effective way to understand what the other person is saying. While doing so do not miss out on important facts. Watch for body language too. It provides clues to the importance of the requirement as well as UI design. For example, while discussing a requirement the users may gesture a drop down or a click without verbally stating it. Note them down.
Patience. It’s a virtue that all BA’s must have. First, not everyone has clarity of thought. Second, business users do their job really well but may not be articulate enough. Third, they may not have the patience to sit and explain fundamental things to you. It’s like being in a relationship. Two impatient people make the situation quite explosive. This attribute is something to be cultivated. If you have not read Dale Carnegie’s book “How to Win Friends and Influence People” please do so. There are many examples in there that show how patience can get what you want.
Persistence. You have to strike the right balance. Extreme persistence will annoy people. Extreme non-persistence will result in inadequate requirements. Walk the thin line. Persevere until you get the information required without annoying the business users. Patience and humor are important tools here. Yet another approach is to understand the mental makeup, idiosyncrasies, likes and dislikes, interest, hobbies of the person you will be dealing with. How to get this information? Have an informal chat, coffee, lunch with the person/s before setting off on the formal process of requirements elicitation. Here is a cue from Dale Carnegie – people love to talk about their experience. Once you establish a personal connection, not much of effort is required on the persistence front. Remember, nothing comes easy.
Documentation. Translating requirements as communicated by the users and as understood by you into a BRD/FS requires a good command over written English. Ability to document in a lucid way without diluting the essence of the user needs is a necessity every BA must possess. Supporting user needs with examples in a clear, concise manner ensures the business users and the technical team understand the requirements in a consistent fashion. The key word here is “consistent”. Business users and the technical team must comprehend it the same way. Writing need not be Shakespearean. Simple, grammatically correct sentences are good enough. Where do you start?
1. Review some of the existing documents. Do they appeal to you? Do they grab your attention? How would you revise it to make it more appealing? Are they clear? If not, what is missing? Remember to try to add those missing ingredients to your documents.
2. Rewrite some of the documents, if not the whole, at least the portion that is dowdy.
3. Do not use words where the reader has to refer a dictionary (dowdy is a good example, it means dull, unattractive).
4. Peer review is yet another way to improve your documentation skills. Some people are very good with punctuation (my weak point). Some are good with word choice and some are good with spelling (my strong point). (I had this document peer-reviewed too).
5. Use Microsoft Word’s built-in, rudimentary spell check and grammar check. You can ward off some of the basic problems.
6. Some of the fundamental writing mistakes to avoid – mixing up tenses, switching between first, second and third persons, verb-number disagreement.
7. Write in active tone.
  Keep in mind that a poorly worded document is rarely read to completion. Also keep in mind that a BRD or FS will be a live document as long as the system exists. So, get the documentation right.
Analytical skills. The bread and butter of a BA. Ability to dissect a requirement, understand its need, study its impact on upstream and downstream systems, and comprehend its role in the grand scheme of things (seeing the forest AND the trees) is absolutely essential. This website lists areas where analytical skills are required and is not restricted to BA’s. I have seen some amazing young BA’s with excellent analytical skills too as well as some experienced ones with waning analytical abilities. How to improve analytical skills? (the assumption here is you already have a level of analytical skills) There are many tools to help you, like Fishbone diagram, 5-why methodology, and much more. Playing Sudoku (not during office hours) helps a great deal in improving analytical abilities. How much to analyze? Enough to implement the requirement and avoid analysis-paralysis. Here are some points to bear in mind:
1. Always keep the objective in mind.
2. Establish a time limit to conclude your analysis process.
3. Perfection is not the criteria, adequacy is.
4. Check with a senior colleague.
5. Go with your gut feel.
Conflict management. Conflict is common place in the life of a BA, while gathering requirements, analyzing, communicating to technical team, and testing. Some of the skills mentioned in my earlier blog will definitely help manage these conflicts. Eliyahu Goldratt in his book Theory of Constraints (TOC) provides a methodical way of resolving conflicts. He calls it the “evaporating cloud” . It is a logical and graphical way to resolving conflicts. The diagram must be viewed from right to left (like Arabic). Yet another method is to follow the 2-minute rule. If a resolution is not found within 2 minutes, keep it aside and table it later. Never get into an argument. You may win it but you will lose the goodwill of the person.
Be aware of the escalation process too. Do not escalate at the drop of a hat. Tact is absolutely essential so as not to mess up the relationship with the business.
Communication. Here is a high-level list of things to do:
1. Have an agenda for each meeting and share it before hand.
2. Follow up each meeting with a written communication of what was discussed and provide readers with a timeframe by when they should confirm.
3. Keep the communication channel with the business users open. There is a general tendency to switch it off once requirements are gathered till UAT. In the interim keep the users updated of the progress being made.
4. Have walk-through sessions with the technical team to explain the requirements.
5. Document all explanations and clarifications provided. This will help avoid a ‘you-said-she-said’ situation.
6. Communication must be clear, concise and correct. Use bullets instead of paragraphs where possible.
7. If you are not sure how your message will be understood, save the communication as draft. Revisit it a day or two later and if it still sounds good send it.
8. Spell check and grammar check before sending out the communication. When in doubt, ask someone else to read it.

The list is by no means complete. Different situations demand diverse skills. Some can be acquired while others come through experience. In my next blog I will discuss the techniques available to a BA for eliciting requirements but before that let me acquire some more of the below skills myself !!!

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.