Skip to main content

Tag: Business Analysis

Why Are We Still Talking About PM vs BA?

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.

kupe April13 01Figure 1: Team built based on roles or titles
kupe April13 02Figure 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,

Don’t forget to leave your comments below.

5 Ways to Find Missing Requirements

Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been on enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.

In this article, we’ll look at 5 practices we employ as business analysts to discover hidden requirements, and how organizational pressures, project circumstances, and business analysis processes can negatively impact the outcomes of those techniques, leading to the costly reality of overlooking requirements.

Practice #1 – Requirements Reviews and Buy-In

It is not uncommon to discover dozens of requirements during the final requirements review stage. Walking through a requirements specification, or a portion of a requirements specification, with the goal of being sure everything necessary has been included, almost necessarily uncovers additional information.

When you are getting ready to approve, finalize, or simply be done with a requirement, your stakeholders tend to invest a little extra time and energy in being sure it is right.

But the review process only works if you establish the importance of the review, making it very clear that once we review this document, development will begin based on what is inside it, and that means the cost of change starts to go up.

This stage of the process can go wrong if stakeholders do not show up to requirements meetings, do not understand the enormity of what approval means, or do not feel bought into the project in the first place. It also does not work if a critical stakeholder is not invited in the first place, which leads us to the next way to find missing requirements.

Practice #2 – Include All Possible Stakeholders

While it is never a great idea to invite dozens of people to a single requirements meeting, good business analysts ensure that all relevant stakeholders are looped into the project and given the opportunity to share their concerns, needs, and expectations. If you are consistently neglecting requirements in a particular area, identify a new stakeholder from that area to include on your project teams.

This part of the process can go wrong when business analysts are assigned to specific areas of the business and projects are assumed to only impact that area. It can also go wrong when managers assign uninformed stakeholders to projects or refuse to assign stakeholders at all. Organizational politics can also be a factor, say, if a business sponsor purposely excludes one or more stakeholders from the project.

Practice #3 – Apply Analysis Techniques

While stakeholders are the source of many requirements, other requirements are discovered by analyzing the stakeholder needs and discovering implications. The result of good business analysis is a complete view of the solution. For example, every field on a report must be entered into the system at some point, whether directly by a user or by some sort of data feed.

Unfortunately, well-intentioned templates can negatively impact the analysis process. When you are capturing requirements in long lists, it is difficult to make all of the necessary links between requirements. As luck would have it, the same is true if you are capturing requirements in a substantial product backlog. You need analysis models, such as business processes, use cases, or data models, to help you discover the missing connections.

What’s more, a large template can give the false sense of security. Just because you have filled out a 30 page template with twice as many sections does not necessarily mean that you have discovered all of the requirements!

Practice #4 – Invest (Just) Enough Time

Good requirements take time from stakeholders, from technical experts, and from someone performing business analysis activities. Part of being a business analyst is putting together a reasonable plan that explains the steps you will go through to elicit, analyze, and confirm the requirements, identify who needs to be involved in each step, and about how long each step will take.

While it might seem counter-intuitive, more time is not always better. Business and technology contexts change quickly. Investing too much time in the requirements process can mean that your early requirements become stale before they are even ready to be implemented. Minimizing missed requirements comes from crafting a plan that secures just enough time to discover the best possible requirements given the project goals and constraints.

However, it is not uncommon for a business analyst to be assigned a mere week or two to finish requirements before development on a sizable project is targeted to start. When organizations shrink project timelines, or the time dedicated to the requirements aspect of the project, without also shrinking the scope of the business analysis effort, then we nearly guarantee we will miss requirements.

Practice #5 – Start at the Beginning

You cannot solve a problem that you do not understand. You cannot address a business need that has not been defined. You cannot sell a product that the customer does not want.

Business analysts understand the big picture of the project, which includes why the organization is investing in the project and the over-arching goal to be accomplished.

I would venture to say that the vast majority of missing requirements are actually missed at the very beginning of the project. If no one inside the project compels the business community to be clear about exactly what problem needs to be solved, or if a business sponsor resists a business analyst’s typical “why” line of questioning, the entire team is working like a ship without a rudder. You run the risk of chasing rabbits down holes and discovering a lot of requirements that are irrelevant, while overlooking the big important requirements that should be staring you right in the face.

Create More Positive Outcomes

As business analysts, we can expect to face circumstances that, if left unchecked, will cause us to miss requirements. It is up to us to clarify the conditions under which we can do our best work and improve our contexts so we can improve our requirements.

Don’t forget to leave your comments below.

The Pros and Cons of Using a Smart Pen for Business Analysis

For those that aren’t in the know, a digital pen (also known as a smart pen) allows you to capture what you are writing in an electronic format.

These pens use a variety of techniques to do this ranging from using a camera, to being connected to a computing device. Some also allow you to record a conversation taking place while you are writing notes.

I have used a digital pen in a lot of elicitation situations and, in this article, I would like to describe some of the lessons learned.


I use a camera-based pen. It is slightly larger than a normal pen and contains a small camera and a microphone. By using digital paper, the pen can track what is being written and store it. At the same time, it can synchronise the audio being recorded with what is being written. At a later stage, you can press the pen anywhere on the page (on which you have written your notes) and play back the conversation that was taking place at that particular time.


In any elicitation situation where I was taking notes, I would use the pen to keep a record of the actual conversation taking place. At the same time, I would take be taking notes.

After the session I would play back the conversation at various points to confirm that my notes were correct, or to expand on what I had written (you know that written notes don’t always capture everything that was discussed).

Using the an associated computer application, I was able to convert my written notes into a dynamic PDF that could be archived or distributed to others in the team. This PDF had the audio embedded, and the reader could click on any word to playback the discussion taking place at that time.


Often when you are running an elicitation workshop, you are up in front of everyone leading discussions, asking questions, prompting and encouraging responses. You can’t do this and write everything down. In this case, there is usually someone else who assigned this task (the scribe).

When I was in this situation, I was still able to use the smart pen. Whenever there was a change in the discussion, or a particular point that could be summarised in a word, I would write that on the special dot paper. After the session, I could still playback what was said at that point.


Using a smart pen has a lot going for it:

  • You can capture the whole discussion and tie it in with your notes.
  • The audio is synchronised to the written notes, so you can play back the conversation that was taking place at specific points.
  • You can share the notes with audio with other members of the team, or with the stakeholders (if desired), as part of your Work Product.
  • You are confident that you can go back over the audio to pick up things that were said, but not written down.


Using the pen has been very handy, but it also has its downsides. What follows are some of the lessons learned.


Before using the pen during any elicitation event where there are other people involved (workshops, interviews, active observation, etc.) ask if it is OK to record the conversation. Usually, people are pretty good about this and don’t mind.

However, it is important to reassure participants that you are using the pen merely as a tool to support the notes you are taking. And as a professional BA, you need to remember that.


Use the pen to capture the conversation, but don’t be lazy. You still need to listen actively, and write down the important points from the conversation.


You still need to validate that the stated requirements match the stakeholder’s understanding of the problem and their needs even though you have an audio record of the conversations. What is written, and what was said still might not be what was meant.


As I mention above, in a workshop situation you might just write a word of two and let the pen capture the conversation.

I’ve had situations where, after a series of seven one-hour workshops I’ve gone back over my notes and haven’t been able to work out which part of the workshop the squiggle on the page or that strange sentence I wrote (which meant something to me at the time – three days earlier) referred to.

When you are writing headings to describe certain parts of a conversation or discussion, write something meaningful so that, five days later it will still be clear to you. The discussions in workshops, or interviews, don’t always take place in nicely defined sub-sections.


This is a classic newbie mistake and relates to something I wrote above, Never, ever, just record the elicitation session with the intention of writing up the notes later on. You might have a three day workshop in between the time you recorded the notes and when you get to write. Remember – when you playback the audio, it will take three days to listen to it! (And this includes all those side-conversations, jokes, and irrelevant comments that get made.)


This is related to Ask Permission above.

Regardless of whether you have been given the OK by the session participants to record what is being said, be aware that a lot of things said during the workshop/interview/active observation session might not be relevant or are off-record. It may not be your intent, but you don’t want a situation where something someone says is used against that person later.


The pen can be used for several hours, but it won’t last forever. With the smart pen I used, I could plug a USB cable into it, and plug that into my PC, allowing the pen to always be charged while I writing notes. Useful, but it was not very handy.


The smart pen uses paper with microdots on it. This allows the pen to be able to map what is being written, and the location on the page.

Often this paper is sold in the form of notebooks, etc. Ensure that you have an extra notebook with you. You might never use it, but, then again, you might. (In my situation, I could print out the microdot paper myself, but read the next Lesson

Learned for more on this.)


Each page in the notebook has a unique, sequential, ID. This way, the pen can keep all the pages in the correct order. Don’t write your notes on random pages. It makes it difficult when it comes to working with the notes and audio when you are back at your computer.


As mentioned above, you can print out the microdot paper yourself. If you do this, you will have several loose sheets. These are handy if you want to put the sheets in a ring binder, but be aware that, as with the notebooks, each page is in sequential order. Keep them in the correct order (the page number is printed on each). This saves a lot of pain when exporting to a PDF.


The pen is an incredibly handy tool (with the later version offering even more functionality, as well as looking like a real pen).

However, for the purposes of Business Analysis I would not recommend using it.


As I alluded to in some of the Lessons Learned, being able to record the conversation taking place is valuable. But it also makes you relax.

It’s easy to think “Oh I won’t write that down – I’ll go back over the audio later.” WRONG! The idea of the elicitation session is to capture the main points actively, in real-time.

That’s part of being a good BA. Active listening, and active note taking. You are in the elicitation session to understand the message that the stakeholders are communicating. And you need to make sure that you have captured it properly.
Going back over a recording of a session, in my opinion, is of little value. The real value should be in your notes. If they need expanding upon or clarifying, that is something that needs to be done directly, with the appropriate stakeholder.

I’m not saying that a smartpen is worthless. But if you think about it, BAs have been taking notes as part of the elicitation process for years. How many have recorded the session?


My conclusion above is how I feel about it. For you, fellow BA, it might be a different situation.

In fact, someone pointed out to me that their handwriting is terrible, and they often can’t read their notes. Having the pen would mean that they could, indeed, dive into what was being said at the time the notes were made.

I can’t argue with this reasoning…


Have you ever used a smart pen? In what situations have you used it? What are thoughts on it? Do you think that I am wrong in not recommending it for BA work? Feel free to let me know in the comments.

Don’t forget to leave your comments below.

BA-elzebubs Glossary Four – The ‘B’s

My brilliant readers know this piece of fun. Get credit in my next blog by offering more “B”s (and “C’s”) in the comments at bottom.

BA: See Business Analysis or Business Analyst.

Baseline: 1. A method of slowing progress to fit communal bandwidth; for example, the monthly rhythm of a change control board. 2. A clear, consistent, concise definition of feasible requirements suitable for: a) ruining with last minute executive confusion and “demand” deliverables; or b) for improving with carefully considered change management.

BB: Profession following BA.

BC: See BB.

Benchmark: 1. The mark made on the bench by project teams that watch what others do, similar in value and concept to the “hashmark”. 2. Solution speed comparison tests, as in “Wow, Amazon’s on-line store put us out of business in less than 10 years.”

Benefit: 1. Value that a solution might provide if implemented successfully; 2. The source of stakeholder fear of a solution. Example: “Digital blueprints mean that we don’t have to drive all over the county fetching and delivering blueprints, but driving around is more fun than actually supervising sewer work, on-site, most of the day.”

Best Practice: NOT what you are doing. Believe it. Diagnose it. Now change it. Repeat. Now you’re getting it – oops, not quite! Keep trying.

Beta Test: Formal term describing a solution that is not ready for commercial release, but is released to a limited number of users who help by giving feedback to the developers. Apple modernized this practice by releasing to all users while dropping the “beta” designation and using the word “free” instead. Microsoft is fighting back by moving to alpha releases but continuing to charge money, giving the illusion of product maturity.

Bit: 1. An information technology word never to be discussed with a business stakeholder. 2. A canned response to common stakeholder concerns. Example: “When the stakeholder objected to the process model, the BA bit them in the ear and the stakeholder dropped the objection”.

Box: A polite word for those in an organization who write the checks for “change consultants”. They do this for their own protection. Example: “He wanted Org X to get out of the box, so he hired the change consultant, but it turned out that he WAS the box, so he fired the change consultant!”

BPMN: 1. A notation for modeling a business process domain for stakeholders who can’t pretend to read but have no trouble pretending to understand a picture. 2. An alternative to sticking with text rendered so large that it can be confused with a picture. See PowerPoint discussion by Edward Tufte.

Brief: A highly compensated, highly expensive way of communicating. The most successful executives are brief in their communications (“of course this will be everything you want”) and in their tenures (“good luck, it was nice working at you”).

BS: Business Synthesis. What did YOU think?

Bug: A critical yet unexpected system feature from a developer. These (widely misunderstood) features help ensure that the developer’s software gets tested thoroughly once it is already released. Testing before release is optional – see “Baseline”).

Business: None of yours, hopeful elicitor :).

Business Analysis: The precursor to Business Synthesis.

Business Analyst: Anyone precursing Business Synthesis.

Business, Monkey: 1. The illegal trade in endangered primates. 2. Any decision made in the “C” suite without any sense of the impact on end users.

Business Requirement: 1. As commonly practiced by business executives, a business requirement is any requirement promoted by a “business” person in the organization, suiting the “business ego” needs of that stakeholder, in direct contradiction to BABOK. Example: “When this is over, we will still be a Microsoft shop, won’t we”? * 2. As defined by the BABOK, a business requirement describes the needs of the organization as a whole, and not groups of stakeholders within it. Example: “When this project is initiated, existing systems must continue to operate without additional downtime, as measured by existing availability reports.”

Business Rules: 1. Code buried deep where no businessperson can find it, known only to programmers, who can’t explain it. 2. Arbitrary wants that are un-code-able, as they cannot be explained. Example: “The system should automatically pick the best employee for promotion.” 3. Actual policies that govern transactions and entity relations of great value. These policies are typically kept out of code so they can be modified on the fly by spontaneous human judgment. Example: “No insurance company should carry more than 33% of all liability” is easily modified to add the phrase “unless the insurance company is run by people who assure us that all is OK and besides they are our friends.”

Button: The solution to everything. Examples: “Can’t we just add a button”? or “Can’t the system just push the button for us”?

Enjoy! And give BA-elzebub (not me!) some “C’s” below (Cache, Cynicism, Customer, Cost-Benefit, Critical-Path more) should your Cranium Crave Creative Comprehensibility by Chuckling Colleagues 🙂

Don’t forget to leave your comments below.

The Challenge of Challenging Appropriately

register nowSee Bob Prentiss Live in Washington May 4th – 6th at 
Project Summit Business Analyst World Washington!

You want to make progress. You know that you are an innovator for your organization. You simply want people to listen to you, yet your voice and any challenge you put forth to do the right thing seems to go unheard or unrecognized. You need to ask yourself “why?” I get it, it can be very frustrating when you probably have the answer to a problem and are trying to prevent your company from settling for the status quo. So how can you get your voice heard? Let me ask you this: “Do you think you have been challenging appropriately?” Now “appropriately” sounds like I am just talking about being “nice”. It is actually much, much, more than that, which is why challenging appropriately is in fact, a challenge. For some of us, the answer is intelligent disobedience, but for some of us, it is learning how to challenge appropriately.

There are many barriers to challenging successfully. I often joke that the root cause of these barriers is that people suck! Now I mean this in the nicest possible way, I love people – I really do! I am first and foremost a people person, however, I know that people want what they want, when they want it. People are different: personalities, needs, desires, goals, experiences, and more. People are just hard to figure out. What we think is obvious and should be acknowledged, another thinks is ludicrous and walks away. Add to it the complexity of communication and you run into many more barriers like: wrong place, wrong time, wrong person, wrong facts, wrong approach, not enough alternatives, budget, resources, personal pride, personal agendas, positional authority, your dog ate your homework… well, there is simply a lot that can get in your way.

What does it mean to challenge appropriately? I think there are many things that make up the definition. My personal definition is:

“An individual or group, who works with other individuals, groups or organizational structures in a collaborative fashion, challenging the status quo to achieve a common purpose or goal for the greater good of the people, project, or the organization.”

This is all well and good as a definition, but it still does not tell us how to challenge properly. It would be great if we could first all agree that we should have the ability and right to challenge as part of collaboration to ensure we meet the goals appropriately, but all of those “barriers” come creeping in quickly. So what can you do?

There are 100’s of ideas that I am sure everyone has, so I hope that everyone chimes in with their favourite ways of increasing the chances of challenging successfully. Certainly there are some basic rules that we should all abide by when challenging – mutual respect, being nice, honest, positive, seeking to understand, critically thinking and not rushing to judge, open minded, and being flexible and adaptable.

Here are 6 tips that have helped me for over the years successfully challenge for the greater good.

  1. Know thyself. It is advice I have given for years. As I have worked with people from all walks of life, I have found that those who are able to challenge appropriately are those that have a strong sense of who they are and what they want out of life. The better you know yourself, the better chance you have of dealing with other people because at the very least you have a strong center to work from. I know exactly what my strengths and weaknesses are, what type of person I am, what I want out of life. All of this gives me an opportunity to relate to people better. Think Myers-Briggs Type Indicator, Insights Discovery Personal Profile, or Strengths Finder 2.0 is beneath you? They have all been my best friends and valued tools for many years. I am happier now than I ever have been because of these tools and how they have helped me shape who I am. They have helped me know myself.
  2. Know what motivates people. What is their WIIFM factor? WIIFM – what’s in it for me? It is hard to challenge successfully unless you know what is going on in the mind of the other individual and what is motivating them. It is often impossible to influence others without understanding their motivation. And that is the whole reason for challenging, right? You are trying to influence them to another way of thinking and doing. How do you do this? Perhaps just ask! Most people will tell you. Keep it simple like “Hey Jon, help me understand…” Notice I did not put the word “you” in that question. Don’t put anyone on the defensive with the “you” trigger. A natural, organic conversation will often yield how people feel about things – their WIIFM.
  3. Know the facts. I’ll take some mastery of the facts with a side of options, please. A challenge without a mastery of the facts can be perceived as incompetence. If you talk to your boss about changing something, or complain about something that does not work, and you have not given them any options with sound facts for how it can be resolved, you will often be perceived as a whiner. Make sure you have more than just your gut feel for something. Yes, for most people, your gut is likely to be right, but many people will not proceed or agree based off a gut reaction or instinct. Details are needed. And if you do have the facts? Make sure you have a backup plan – options. Not everyone is going to respond to your first option. Always have a backup. Even if your goal is to show them the backup so that they realize the first option is the best way to go.
  4. Time and location. If you challenge at the wrong time or in the wrong location you might as well have not tried at all. Understand the implications of the when and where. Once upon a time I tried to challenge something early in the morning. I am not a morning person. I am often incoherent until after 9 a.m. Okay, maybe 11 a.m. if I am honest. Although I had my facts, I was not articulating them well. Although never formally diagnosed, I sometimes speak my words backwards – a form of dyslexia. After making my case, people just stared at me and then continued in a conversation like I was not there. When I am focused and alert it does not happen. I also do not drink coffee, so good mornings for me are generally dependent on good sleep. I also once tried to challenge something in the office of a Senior VP. Well, let’s just say that I was not given the time of day as he paid attention to his computer and everything else in his office. I had the “when” right but not the “where”. Your strategy of when and where can make all the difference in your results.
  5. Coalitions. I do not often challenge alone – I find strength in numbers. A coalition is a group of like-minded people that share your vision. People in your coalition may have strengths that you do not (of course you need to know what those are first). When I challenge, I am keenly aware that I do not always need to be the frontrunner for the challenge. I am okay if there is someone else better suited to do so. It is the end goal we need to get to and my ego is checked at the door.
  6. Know how often to challenge. Challenge, and then challenge again! I often talk to people about how they challenge. The story usually goes something like “I brought it up to them that it was not going to work, I offered a solution and they just ignored me!” Well, that is not really a full challenge. That is an attempt. A challenge is something that often needs to be sustained or repeated. You must be willing to go back to the well if you believe in your cause. For most things I use the approach of: “Two toots and a salute!” This is the idea that you challenge once, and when no movement or resolution comes forth, challenge again in a different way through coalition members, other creative options, or new facts. Still no movement? Then it is time for “Yes, sir!” “Yes, ma’am!” You must be aware that pushing too hard can result in a CLM (career limiting move). Figure out both what the individual and organizational tolerance is for challenge so that you can adjust your strategy accordingly. There are definitely times I will challenge three or four times if the tolerance is there, especially when I have the facts and the support.

At the end of the day you want to help move your organization forward. You want people to listen to you. You want to do the right thing. I believe that when we challenge appropriately it helps to build relationships and foster better collaboration. Intelligent disobedience works too, but a balance between these two things is even better. So where have you had success with challenging appropriately? What is your strategy to remove the “challenge” from challenging?

register now

See Bob Prentiss Live in Washington May 4th – 6th at 
Project Summit Business Analyst World Washington!

Don’t forget to leave your comments below.