Skip to main content

Author: Kent McDonald

How to Discover Useful Requirements for Business Intelligence

“My users are asking for a report, but how do I make sure I truly understand their needs and properly convey that to the rest of the delivery team?”

Asking for a report is great, but it is a loaded word. People use the word “report” to mean many different things.

A report is a solution in search of a problem. You may know what your stakeholders want on the report, but until you identify why they want the report, you enable their solution seeking.

When you want to understand a stakeholder’s business intelligence needs completely, the following steps often prove very helpful:

  • Start with the questions stakeholders want to answer and decisions they want to make
  • Focus on value and feasibility to determine what to do next
  • Dive into detail only when you need to

Start with Questions and Decisions

When your stakeholders ask for a report, you want to know why they want that report, but you do not want to ask why. Why not?

Asking “why do you need a report?” is not going to provide you with the key insights and information you need and may make your stakeholders think you do not believe they have a need at all.

To avoid that uncomfortable situation, I have found that Socratic Questioning is a good route to go. The question I like to start off with is “What questions are you trying to answer or what decisions are you trying to make?”

When your stakeholders describe the questions/decisions, listen for phrases such as:

  • I want to know…
  • I want to decide…
  • I want to determine…

These help to identify the initial big chunks of value you can deliver in your business intelligence efforts.

Say you are working on a product to allow the audience at Olympic events to vote on the competition – say platform diving – and your stakeholders want to incorporate reporting into that product.

You talk with your stakeholders and find out that they want to know how votes can vary depending on characteristics of the audience or the competitors. That may result in the following things that you want to explore:

  • I want to know if audience members vote differently based on their gender
  • I want to know if audience members favor athletes from their country
  • I want to know if audience members evaluate athletic performances the same as judges
  • I want to know if audience member age impacts how they evaluate performances.

You can easily capture these in a user story, job story, or another template of your choice. The key is that you know what your stakeholders hope to accomplish with the reports, so you can guide the discussion to find out what your stakeholders hope to accomplish.

When you have those conversations, listen for nouns. They represent the pieces of information you need to know. Also listen for phrases such as “by gender” or by country They indicate how to organize the data, including what dimensions you may need.

In our examples above, the nouns you will most likely pick up on are audience members, athletes, and judges. The dimensions then may be audience member gender, audience country, athlete country, and audience member age.

Focus on Value and Feasibility

Once you have identified what you want to work on, you need to decide the order in which you work on it.

Start by prioritizing the questions and decisions your stakeholders are interested in based on value. Which of those questions and decisions are most vital to your stakeholders’ objectives? It may be the question/decision that provides your stakeholders the biggest lift or is most critical to address other questions and decisions.

Then, consider feasibility. Feasibility focuses on whether the data you need to address the questions and decisions is availability and organization of the available information. If the information is not readily available, consider alternative methods and their difficulty in obtaining that information.

Some pieces of data may present some substantial risks from the perspective of whether you will be able to get that data. If that data is critical to some of the more important questions/decisions, you may decide you need to tackle that data first.

Feasibility also drives the order in which your team delivers the data for a specific question/decision. As a result, you may provide overall prioritization of which questions/decisions to address in what order, and then leave it to your team to decide the order of the smaller bits of work necessary to deliver the ability to answer a given question or make a specific decision.

Dependencies play a part in considerations of feasibility. Often the answer to one question becomes an input to answer another question, so you have to consider those interdependencies when you decide the order of the questions you tackle.

Prioritization is most effective when it is a team discussion. Start with which questions you want to answer or decisions you want to make first, but then revise that order based on the feasibility involved in getting the data necessary for those questions or decisions.

Only Dive Into Detail When Needed

I noted above that you want to listen for nouns and pointers to possible dimensions. Noting what comes up during the normal course of conversation is ok, just avoid the temptation to dig too deep too soon.

You do not know which stories you are going to need to do, so you do not want to expend too much effort fully understanding stories you are not going to do. When do you dig into the details?

When you have initial conversations with your stakeholders to understand the information they seek, you may sketch out a very rudimentary report during the conversation to make sure you understand what they are asking for. Stop when you have enough information to determine what order you want to deliver those questions and decisions.

In some cases, you may need to dig a little bit if you identify a piece of data which may prove a somewhat difficult to obtain.

Wait to delve into all the details of the data (definitions, transformation rules, valid values, or other factors) until you are preparing information for a team to deliver the necessary data to answer a question or make a decision.

Business Intelligence Can Be Done Iteratively

It is possible to deliver data warehouses in an iterative, incremental fashion. The key to making that happen and work is to organize your increments around questions your stakeholders want to answer or decisions they want to make. Then consider value and feasibility to prioritize those questions/decisions, and avoid the temptation to dive too deep too soon.

What experiences do you have working on business intelligence projects? Leave your thoughts in the comments.

7 Things Business Analysts Need to Know About Agile

1. Agile is Not a Methodology. It is a mindset.

Agile has reached and frankly blazed past buzzword stage. It is also no longer new (the term being applied to software development over 16 years ago). As people become familiar with it for the first time, it is frequently referred to as a software development methodology or a project management methodology.

It is neither of those things or anything. It is a way of looking at and thinking about how to approach knowledge work. Instead of a noun, it is an adjective.

Alistair Cockburn described it best on his blog. The essential part of his argument is that methodology is a set of conventions the team agrees to follow. Scrum, Kanban, XP, SAFe, etc. are frameworks that teams use as a starting point for creating their methodology to fit their context. (Some people in the Scrum and SAFe worlds forget that).

The agile mindset provides some guidance that teams can follow when creating their methodology, including the idea that teams should create their methodology in the first place. I have my own way of viewing the agile mindset, and I like the description that Joshua Kerievsky has championed recently:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

2. There’s More to Agile Than Just Scrum

The Scrum framework has won the market share wars as the most commonly used framework when organizations adopt agile. That leads many people to conclude that agile = scrum. In reality, Scrum is only one of many frameworks that you can use as a starting point to approach work in an agile fashion. I like to use an analogy here: Scrum is to agile as Kleenex is to facial tissue.

Why is that important? Because Scrum is only one way to approach living agile values and principles, it is not appropriate in every situation, and it is not a complete solution. If people think that they have to do scrum to be agile, they also conclude they have to have sprints, even when the nature of work lends itself to reprioritizing and deploying much more frequently than once every two weeks. It also leads them to ignore the excellent technical practices found in extreme programming.

Corollary: Scrum is not an acronym. It is a term borrowed from rugby.

3. Analysis is Still Relevant

Just because most of the frameworks do not mention business analysts does not mean that business analysis is still not necessary. The frameworks are not intended to be all-encompassing.

The agile frameworks were created by software developers to solve problems that software developers face. They all have a role that is responsible for determining the right thing for the team to work on. In Scrum, that is the product owner. In XP, that is the onsite customer. Most of those frameworks do not say how that is done.

That is where analysis comes in. Analysis techniques are still useful, but you will find that how and when you use them changes. You perform small amounts of analysis more frequently to aid communication and build a shared understanding rather than do all of your analysis at once to produce the only means of communicating.

4) Agile Alone Will Not Get You Better, Faster, Cheaper

Teams and organizations can also use analysis to determine the right things to deliver, and the things not to deliver. Because most of the agile frameworks do not mention this, they defer that responsibility to a specific role, without much insight into how to do it.

When organizations adopt agile in their IT and development organizations and do not make corresponding changes in how they manage their portfolio of work, they soon find that they have become more efficient at producing the wrong things.

When organizations combine proper decision making and a focus on outcomes with well-functioning development teams that build quality into what they build do they truly realize the benefits of an agile mindset.

5) Writing and Slicing User Stories Is Not The Whole Story

Business analysis does not exist to elicit, document, and manage requirements. It exists to “enable change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.” Requirements are only a means to those ends.

Along those same lines, there’s much more to analysis with an agile mindset than writing user stories and slicing them down to a certain size. Those are just a couple of mechanisms that you can use to help build a shared understanding with your team about the problem and the solution. Many other techniques are helpful to have in your toolkit such as job stories, specification by example, story mapping, context diagrams, process decomposition, mockups, wireframes, and a host of others.

The next time you get obsessed with how you write user stories, remember what Jeff Patton says “Stories get their name from how they should be used, not what should be written.”

6. Business Analysts Can Be Product Owners

Product ownership boils down to three things:

  • Focus everyone on outcome over output.
  • Build and maintain shared understanding
  • Make decisions.

As I describe in a series of posts on product ownership models, there are several circumstances where business analysts perform product ownership and do those three things. To make that happen a business analyst needs to be able to make decisions. Good BA’s should already do the other two things as a matter of course.

In some cases business analysts do not make the decisions themselves. This occurs when they are dealing with several stakeholders who do not own the internal product but have a considerable say in what it looks like. In those situations, the business analyst may still be a product owner, but the third item is more appropriately worded “Make sure decisions get made.” If the business analyst does her job right, the development team will not experience a difference. They will not experience interruptions due to delays in decision making. They just may not have insight into how those decisions got made.

7. Business Analysis Does Not Have to Be Product Owners

If a business analyst is not a product owner that does not mean there is no place for them in an agile setting. A common model is where there is both a product owner and business analyst work on the same team. This model often occurs where the product owner makes decisions, and the business analyst focuses on building and maintaining shared understanding. This model is also prevalent when there are multiple teams working on a complicated product.

I have also seen business analysts slide into the role of coach (scrum master) because they have excellent facilitation skills and can work through team dynamics issues. This situation is a good indication that people should fill the roles that their experiences and expertise prepare them for, not solely based on their job title.

Did I Miss Anything?

I would like to hear your thoughts. Is there something I missed that business analysts need to know about agile? Do you have questions about anything I listed?

Let me know in the comments.

The Product Manager Role That Is on the Business Analysis Career Ladder

A while back I got involved in a conversation about whether Business Analysis is a stepping stone for project management.

I recorded my full thoughts about the topic on my blog. The short answer is “not necessarily”.

I do think that there is a Project Management role that does make a natural rung on the Business Analysis career ladder, though not a mandatory one. That role is Product Management.

What is Product Management?

There are many different descriptions of what a Product Manager is. I think Melissa Perri’s description from her Product Institute online course sums it up best:

A Product Manager effectively solves problems for users while achieving business goals.

Product Managers sit in the intersection of business, technology, and user experience, which is verily similar to where many people see Business Analysts, with the possible exception of including user experience.

The Product Management role is most prevalent in a product development context where they seek to understand the needs of their organization’s customers and make decisions regarding what solution would best satisfy those needs. As a result of these responsibilities they need to be both outward facing, being concerned about things such as pricing, profitability, and distribution. At the same time they also need to be concerned with getting the solution they identify built, and so are concerned about things such as personas, requirements, use scenarios, and stakeholder communications. It’s in this area primarily that the activities of a Product Manager overlap that of Business Analyst.

Why does Product Management fit on the Business Analysis career ladder?

If you look at a common definition of Business Analyst and Business Analysis from the Guide to the Business Analysis Body of Knowledge:

Business Analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business Analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.

A Business Analyst is anyone who performs Business Analysis and more precisely (again from the BABOK v3):

Business Analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The Business Analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes. Business Analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders.

Business Analysts tend to focus on needs of businesses and stakeholders. They primarily elicit, analyze and document requirements to find answers to known problems and deal with complicated systems.

Business Analysts are usually found in organizations that develop products for internal use, IT organizations, or process improvement organizations. In other words there are two key differences between Product Management and Business Analysis:

1. Product Managers seek to solve problems for people outside the organization. Business Analysts seek to solve problems for people inside their organization.

The techniques to do this are very similar, although Product Managers face the situation where their customers have a choice whether to use their solutions. Business Analysts typically work in a situation where their stakeholders don’t have a choice, or explicitly requested the solution. Product Managers have to figure out if a problem even exists and whether it’s worth solving whereas Business Analysts know a problem exists, they need to figure out what it is (and they still should figure out whether it’s worth solving)

2. Product Managers are responsible for making decisions. Business Analysts are responsible for making sure decisions get made.

Product Management includes a majority of Business Analysis activities, but involves many other activities, including decision making. Based on the premise that a position that involves decision making represents a step up from a position that does not have broad decision making responsibilities, Product Management could be considered a step on the Business Analyst career ladder.

Product Management certainly has a better alignment with Business Analysis in terms of techniques and perspective than project management does. In addition, Product Management is still relevant as organizations adopt agile, whereas project management tends to disappear at the team level even though it is still relevant at the enterprise level.

Product Management is not the only path you could take in your Business Analysis career. In fact, it could represent a split in the path between leading products, leading people (Business Analyst Manager / IT Management) or being an individual contributor at the enterprise level (Business Architect).

How Can a Business Analyst Become a Product Manager?

There are a variety of ways that you can put yourself in position to become a Product Manager.

Look for Product Owner opportunities, especially those with decision making responsibility. Product ownership is also a subset of Product Management, very similar to Business Analysis with the important addition of decision making responsibilities. This route is especially helpful if you are working in IT inside of an organization. Taking on Product Owner roles on internal products can often be a good place to get familiar with most of the aspects of Product Management.

Start a side hustle where you create your own product or service. The side hustle can be as simple as starting a website that focuses on an area of particular interest for you. This gives you an opportunity to practice the market focused skills that you may not use as a Business Analyst working on internal IT projects. Another option here is to volunteer with a nonprofit or small business to help them introduce or improve a product or service. This is the route I took that eventually led to my current gig as Product Owner for the Agile Alliance.

If you think you’d like to get into Product Management at a tech company, a good introduction is to take part in a Startup Weekend in your area. Startup weekends are a weekend long experience where people, technical and non-technical alike, get together to get a condensed experience of what it’s like being in a startup. Participant form teams, often with people they didn’t know before, identify a project, research the idea, build a minimum viable product, and pitch their idea at the end of the weekend. Even if you don’t want to really work in a startup this can be a great introduction to what product focused Product Management can be.

Learn more about Product Management through blogs, books and courses. I keep my eye on a small set of blogs and newsletters that always provide up to date insights on the world of Product Management. I also found the Product Management class at Product Institute to be very helpful.

What Do You Think?

I’ve found moving from Business Analysis to Product Management to be a very logical transition, where I can apply almost everything I learned as a Business Analyst and pick up new skills along the way. I’d like to hear your thoughts. Do you have a similar experience? Do you have questions about making this sort of move? Either way, leave your thoughts in the comments.

Why You Don’t Need A Certification to be An Effective Business Analyst

A recurring conversation in the business analysis community is whether you should get a certification and if so which one(s) you should get

. The arguments for why you should get a certification tends to be some combination of these three ideas:

  • Studying for a certification helps you learn a lot about business analysis.
  • Acquiring a certification shows that you are dedicated to business analysis.
  • Certifications are useful filters in hiring or promotion decisions.

Certifications aren’t all they are cracked up to be, and most of the arguments for them are based on questionable assumptions. I’d like to look at these three arguments and suggest some different perspectives. As a result, you’ll see that while certifications may have their place they are neither necessary nor sufficient, to ensure that you will be an effective business analyst.

Is Studying for a certification (test) the best way to learn?

A common question I see from people new to business analysis is “I want to become a business analyst, what certification should I get?” There’s an assumption underlying this question that a certification is the best way to break into the field of business analysis.

A better question to ask is how I can learn business analysis?

My answer, born out of my experience, is to find ways to start practicing it in your current situation. You don’t have to have the title business analyst to start using the techniques, and while studying for a test may be one way to learn information, it’s probably not the best. Stop and think about how much you remember from your high school geometry class. I’m willing to bet unless you use geometry on a regular basis, you don’t remember that much. And therein lies the difficulty in the argument that studying for a certification test is going to help you to learn and retain knowledge about business analysis on an ongoing basis.

You can organize learning into two forms: Just in Time, and Just in Case. Studying for a test is the classic example of Just in Case learning. You learn some piece of information just in case you’ll need to know that information sometime in the distant future, and you hope you can recall it.

Except you rarely do.

Just in Time learning is when you come across a specific situation and dig deep into a subject at that point because it’s immediately relevant.

Both forms of learning are helpful and require different depths of exploration. The “Just in Case” is good to build awareness that a concept exists, but there’s no point in digging too deep into that topic. If you aren’t going to use it, you aren’t going to remember it. You then switch to Just in Time learning when that topic becomes relevant.

Studying for certification exams requires you to do deep dives on topics that you may never use in your actual work. You study enough to pass the test, then immediately forget it. Sure, you get the benefit of being aware of the concept, but you also end up wasting an awful lot of time and brain cycles remembering this information, potentially useless in your given situation, to pass a test.

A better use of time is getting very effective at Just in Time learning when the need arises, mixed in with Just in Case learning at a very high level.

The best way to learn something is to use it or try to teach it someone else. In my post How to Learn New Techniques, I describe The Feynman Technique which describes how you can go about learning thoroughly by teaching it to someone else.

Do you have to have a certification to show dedication?

When people acquire a certification, they are showing dedication to something – their career. There’s absolutely nothing wrong with that, but don’t confuse taking steps to advance your own career (I talk more about that below) with showing dedication to an entire profession.

Yes, many people who get certified are also heavily involved in the professional community. I’d be hard pressed to show a causal relationship between acquiring a certification and professional involvement.

There are also just as many people who aren’t certified who are also involved in a professional community and are dedicated to their careers and the profession. I’d count myself in this group.

You show dedication to business analysis when you help out with IIBA or a similar professional association at the local, national, or international level.

You show dedication to business analysis when you share your successes and your lessons learned, either via speaking or writing.

You show dedication to business analysis when you help those who are trying to start practicing business analysis.

You show dedication to your profession when you apply business analysis practices to help your team and your organization be more effective.

To paraphrase Marcus Aurelius, a famous stoic and Roman emperor: Waste no more time arguing what a good Business Analyst should be. Be one.

Are Certifications a Good Filter for Hiring and Promotion decisions?

When organizations use certifications as a filter for hiring decisions there’s an implication that certifications indicate how well you can do the given thing that you are certified in. They don’t. What the certifications do show is that someone met the requirements of the certification which in most cases are not tied to ability.

Several organizations also expect that consultants or contractors they bring in have a certification in a specific framework they would like to implement. Those organizations have bought into the same line of thinking that organizations that use certifications for hiring decisions have accepted. It’s as unreliable in the case of consultants as it is for full-time employees.

Many organizations require their employees to get a certification within a certain time, give raises, or promotions to those that do. Their reason for doing that is generally one or both reasons I described above.

While I don’t agree with the reasons, many organizations have chosen to tie hiring or promotion decisions to whether you have a certification. The pragmatist in me advises you if there is a job out there that you’re interested in and it requires a certification, then it’s probably worth it to get the certification. If your current employer gives people raises or promotions when they get a certification, then it’s probably worth it to get the certification. Just be honest with yourself as to why you’re getting the certification.

A Pragmatic View of Certifications.

I have chosen to learn business analysis by practicing it and helping others learn it. I’ve shown my dedication to business analysis through involvement with the IIBA at a variety of levels and through sharing my ideas via my blog and at conferences. I have chosen not to get a CBAP or the PMI-ACP because I don’t believe they are helpful to my career.

I have acquired a couple of framework based certifications, but there were very specific reasons. In 2005, I got my Certified Scrum Master (CSM) because I took a 2-day class. I didn’t do it for the certification; I did it because, at that time, the class was a great introduction to Scrum. I also got my SAFe Program Consultant (SPC) certification a couple of years ago because my clients required people who worked with them to have it.

While you don’t need a certification to be an effective business analyst, you may find that having one may be helpful to your career in some situations. It’s important to know the difference.

For those of you without a certification, do you think you’ve been negatively impacted? For those of you with a certification, why did you choose to get it? Leave your thoughts in the comments.

How to Demonstrate Your Value as a Business Analyst

The fifth thing I wish I knew when first starting out was people do not want you on their team just because you are a business analyst.

Many organizations have rules in place that every project has to have certain roles assigned, and many people in the business analysis community suggest those kinds of rules should exist.

That can only get you so far.

Having those rules in place may help a Business Analyst get on a project, but unless you can demonstrate the value you add to a team, you stand a good chance of getting sidelined, and not invited back to the next project.

Here are some ways I have found to demonstrate my value to teams and organizations.

Build a Shared Understanding

In the article Your Job is Not to Elicit and Document Requirements I discussed a few lessons I have learned when working with teams. The times that I have had the best relationship with a team is when I follow those lessons. I do not view requirements as my ultimate deliverable, rather I see them as a means to the end of building a shared understanding. Everyone on the team knows what need we are trying to satisfy and the solution we are building to satisfy it.

What I am doing is managing risk – primarily the risk that the team forgets about key stakeholders or overlooks some important data or process relevant for the solution. If you keep your team informed about important data and process, communicate that information in an easy to consume way and help your team maintain their pace they will want to work with you again.

Point Back to the Need You’re Satisfying

You need to keep the team and your stakeholders focused on why you are doing the project. When you start a project, suggest the problem statement exercise I described in the article Projects Tend to Be Described in Terms of Solutions or some other technique to make sure you drive back to the real need you are trying to satisfy and how you’ll know when you’ve met that. Then take the output of that exercise and post it where everyone can see it. Then take the output of that exercise and post it where everyone can see it. Then, we you find yourself involved in the inevitable discussion (argument) about whether some feature should be included, or how to go about doing it, point to the problem statement and ask “will what we are talking about help us do that?” Decision Filters can provide the same type of guiding star.

When you are in the process of creating a backlog, do not just dive in and brainstorm a bunch of things to do, but start with your outcome – the need you are trying to satisfy, and then identify what specific things will position you best to reach that outcome. This is the general idea behind feature injection, and a helpful technique for structuring that conversation is Impact Mapping.

If you are in the midst of a project and you sense that the team does not all share the same understanding of the need you are trying to satisfy, or realize you are trying to satisfy a need, suggest that you stop for an hour and create a problem statement. The goal is not necessarily the problem statement itself, but the conversation that comes with it.

Remember that other members of the team are focused on other aspects of the project:

  • How will we build it? (developers)
  • What happens in this case? (testers)

While they all may have the reason for doing the project in the back of their heads (and the good ones can hold multiple concerns front of mind at the same time) they are also probably subconsciously counting on you to keep an eye on those things.

They may act annoyed when you bring these questions up, but trust me, in the immortal words of Col Jessup (A Few Good Men) “…because deep down in places you do not talk about at parties, you want me on that wall, you need me on that wall…”

Drive Decision Making

I was talking to a friend the other day about her day at work. She had a rather stern conversation with her client because the project she was working on was falling behind; not due to a capacity issue on the team, but rather an inability of the client to make and stick to decisions. To make matters worse, the client frequently hid behind process (oh, well if we have not made those decisions yet it must be because the due dates on the decision log are wrong) rather than taking steps to get decisions made.

She faced a situation that many BA’s face – you do not directly make decisions, but you are certainly impacted when those who are supposed to make decisions do not.

If you want to be in high demand, even if you are not the real decision maker, take it upon yourself to be the person to make sure those decisions get made. There’s a variety of ways to do this. For those of you who like to look at things in terms of a process, here are the key steps in the decision-making process:

  • Determine the decision maker. Before decisions need to be made, encourage your team to discuss who is going to make what type of decisions. It is often helpful to adopt a RACI matrix to remember what you discussed. Having this discussion before the decisions have to be made will increase the chances that decision making is distributed to the people who will have sufficient information to make that decision.
  • Select a decision mechanism Each decider is going to have their preferred decision approach. Know what those are, and also know which situations are better suited for one mechanism over another. Help the decider determine that mechanism.
  • Determine what information is needed. When a decision comes up, ask the decider what information she needs to make that decision, then pull that information together for her. You can have a lot of influence in the way you pull this information together, so be aware of cognitive biases.
  • Make a timely decision. Discuss when the decision needs to be made making sure you are not deciding too early without a good reason or procrastinating too long without a good reason.
  • Build support with peers/ stakeholders. Sometimes the choice of decision mechanism can help build support – the more collaborative the decision mechanism, the more likely you will build support in the process of making the decision.
  • Communicate the decision. Help the decider spread the word about what she decided.
  • Enact the decision. Help the decider determine the most effective way to enact the decision.

If you follow those proactive steps and still don’t see timely decisions happening, you can always revert to polite nagging backed up with a clear explanation of the consequences of a delayed decision. Sometimes people delay making decisions because they do not realize the consequences of not deciding in a timely fashion.

Be a Good Team Member

As I mentioned in my last post How To Learn New Techniques, you often get the opportunity to expand your toolkit by helping your team members out when they get overloaded or hit a bottleneck. Ask “how can I help” more often and try to eliminate the phrase “that’s not my job” from your vocabulary. Keep in mind that anyone can be the bottleneck at any given time. Sometimes you help someone else out, and sometimes you are the one who needs help. Part of being a good team member is admitting when you need help and helping your team members help you by coaching them in analysis skills when they pitch in.

Another aspect of being a good team member especially applicable to BA’s is do not make commitments for your team.

We have all run into this. You are in a meeting with stakeholders, the rest of your team is busy developing and testing, and you get asked: “When will this be done?” Unless your team has already plotted that out, resist the urge to make a commitment to your team.

Wait, you may be thinking, what if you say “well I think we can get that done this week” surely the stakeholders will realize that is just your guess and will treat it with the proper grain of salt. They will not. The minute you, as the team’s representative, indicate any time frame, it is viewed as a commitment, whether you intended it that way or not. It is perfectly fine to say “let me check with the team and get back to you.”

How Do You Show Your Value?

Those are some of the ways I have found useful for demonstrating my value. What have you found that works? Leave your experiences in the comments.

  • 1
  • 2