Product Owner Role – What Scrum Leaves Out

The Product Owner role in Scrum is a well-defined description of how a single person who represents the business interacts with a Scrum team to get software or products implemented that the business wants or needs.

This is in no way a complete description of what the business has to do to reach that point, nor is it intended to be.  But too many Scrum teams think that the description of Product Owner is a complete description of the business role and do not recognize why the person they think should be in the role is seldom the right person.

So what does “the business” do?  First, we have to identify what “the business” means. In this context “the business” is how the company makes money. It can be for example a product, product family, business line, or service unit.  Sometimes “the business” is an internal unit of the company, such as accounting, that supplies necessary services to the corporation. Someone is responsible for that business, typically someone who is reporting directly to the CEO or COO of the company.

What is that business owner responsible for? This person is responsible for knowing everything that could impact business including the market, the users, the regulatory environment, and the competition. This is the person who decides when to pivot, what to do about disruptive technology, when to enhance a product, or when to remove a product from the market. The business owner makes suggestions to the C-executives about budgets and is responsible for the Return on Investment (ROI) for their business. For overhead units (those that do not make money), the business owner is responsible for providing the services in the most cost-effective manner.

Unless the business is tiny, this is not a job for one person. The ultimate business owner has a team of people who work to collect information, create reports, suggest work to be done, suggest budgets and so on. The staff working for the business owners are experts in their own areas. All of this information is reviewed by the business owner and is the input to his or her own decision making processes.

While the business owner is ultimately responsible for the business, this person is rarely involved in the details of the work to run the business. That is why they have staff to do that work. For any particular project that needs to be done, it is seldom the case that the business owner is the one who knows the details of that work, and so that person makes a poor choice to be Product Owner to the Scrum team.  Yes, this person is ultimately responsible for the vision and return on investment of the business, but that does not mean the business owner wants or needs to be responsible for the vision and return on investment of a particular initiative, nor do they have the time to do so.

So who will take on the Product Owner role for the duration of a particular initiative?  The person who is the Product Owner will be someone who has the knowledge of what needs to be done and the trust of the ultimate business owner to deliver the required ROI. This person is trusted to balance the needs of the users, the needs of the business, and what is technically possible in order to achieve the best overall result.

While the Product Owner will usually be able to make the day-to-day decisions, there may be times when he or she needs to discuss questions with the ultimate business owner. Some complex situations may be beyond the ability of any one person to handle, and so the person who is the Product Owner may sometimes need to get a team of people together to work out the best thing to do. This should never be because the person with the Product Owner role is too junior, but should be due to the size or complexity of the work.

Business owners make a big mistake when assigning very junior people to the Product Owner role. This is a role for a person with deep knowledge and understanding of the business vision and the market (or of a specific supporting domain such as accounting), and the the ability to deliver on the required ROI. People like this are very valuable to the business and cannot be converted to Product Owner as their full-time job.  Instead, they should be assigned to a specific initiative which they are best suited to guide. The work of Product Owner should take only part of their time, since they need to also spend time continuing to keep track of what may be changing that impacts their business and the specific initiative they are guiding as Product Owner.

For business units that make money for the company, the Product Owner will often have job titles such as Product Manager, Marketing Engineer, Marketing Visionary, Business Analyst (on the business side, not from IT), Solution Anthropologist, User Experience expert, and possibly even Head of Sales.  For overhead departments you might have a Lead Accountant, Statistician, Big Data Guru, Lawyer, Operations Manager, or Head of Customer Support.

Scrum teams should always keep in mind that to get someone with the knowledge and authority to be responsible for the vision and ROI, they will have Product Owners who have jobs that go far beyond the Product Owner role. The Product Owner role only describes the interaction of the business with the Scrum team, which should rarely be a full-time job (and then only for brief periods).

Using Kanban to Organize Your Work

A lot of our Business Analysis work is very much the same from one project to another. Because we do the same tasks over and over, it can be useful to organize the work on a Kanban board.

A Kanban board is used to control the amount of work you have in progress at any particular point in time. It also shows the status of the work and how you have it prioritized. It is an excellent way to communicate with your manager and your team exactly what you are working on. At the same time, it is very simple to create, maintain, and review.

First describe a sequence of work. For example, if I were writing user stories for a project, once I have identified a set of user stories my sequence of work might look like this:

  1. Generate ideas
  2. Write the basic user story
  3. Write the acceptance criteria
  4. Review the user story with the product owner and set its priority
  5. Review the user story with the project team and get a size estimate
  6. Review the user story with a test professional and write scenarios
  7. Review the user story with a UI designer and create mockups

Each item on the list will become a column on my Kanban board.


Next, think about how much work in progress makes sense for each column. The idea column can probably be unlimited. How many ideas do you want to work on at the same time to write user stories for them? How many user stories do you want to work on at the same time to write acceptance criteria? What you will do with these numbers is control how many user stories you are working on at the same time. For the columns you want to limit, add that number to the column. I have big numbers for the Product Owner and Team reviews because those reviews are comparing a set of user stories to each other and so they work better with a large number of user stories. I have a small number from idea to user story because I have found that most of the time one idea turns into many user stories.


Finally, use the Kanban board. I have purchased 3-sided presentation boards from an office supply story and put the kanban labels across the top. Then I use sticky notes for the items in the column. I can set the presentation board on the end of my desk where I can see it and I can easily take it to meetings to share with others.

I start with generate ideas. I will use whatever techniques make sense to come up with a list of ideas of what to do in the project. I write each one on a sticky and put them on the board under generate ideas column.


Then I pick one that looks important and move it into the Write User Story column. This shows I am working on turning that idea into some number of user stories.


I write each user story on an index card styled sticky note. I can post them under the idea in the write user story column.


I will move no more than 5 of those user stories into the Write Acceptance Criteria column because that is the next thing to do and I will work on no more than 5 at a time. If there were more than 5 user stories, the rest wait in the previous column. They are on hold until I get the first 5 done. Also, I move fewer than 5 user stories. 5 is the maximum I set on the column.


Some people like to use red colored dots to put on items that are waiting, and sometimes make a note about what they are waiting for. This can be very useful when you are waiting for someone else to do something. You can show that your work is blocked and it is obvious to everyone.

Why Business Analysts should write User Stories for Agile teams

I have seen so many Agile teams struggle with requirements. They do not want big documents, they think they do not need a Business Analyst. In fact, they think they will just grab the Project Sponsor and have that person sit with the team to tell them what to do.

This has not been working out so well. Except in a small number of situations, it is not going to work out very well. The reasons have to do with the environment where Agile is designed to work. If your teams are not working in the right kind of environment, then the Agile team has to adapt how they work.

Let’s look at what that environment is supposed to be, where it breaks down, and what you as a Business Analyst can do to make it work better.

How Agile is Designed to Work

If you look closely at the Agile Manifesto, Extreme Programming, and Scrum they all are based on a particular work environment. If you can set up that specific work environment, then the practices work fairly well for the programmers. There are still some missing pieces and
possible problem areas for the business, which I will discuss at another time, but the development team is very effective.

What does that work environment look like? It is really pretty simple. You have:

* a team of 10 or fewer development professionals
* the team can do all the work; specifically they do not need to get a database person, security person, tester, or ops person, they do all the work themselves
* the team is seated together in the same physical location typically with lots of white boards available
* the team works the same days and hours
* the customer (Project Sponsor) sits full-time with the team
* the same team is typically kept together over a period of years

In this environment, user stories are written by the Project Sponsor. These user stories are placeholders for conversations that will occur between the development team and the Project Sponsor. They are not themselves requirements.

When the time comes to implement a user story, the team and Sponsor talk about the user story and how they will know it is complete. They will write up scenarios that describe what will happen. The developers estimate how much effort it will take to code the user story and decide if it will fit in the next iteration. If not, the user story will be split into smaller pieces. If it does fit and there is room for more work, the team repeats the process with the next user story.

Now the day comes to actually work on the user story. The team will get more details from the sponsor. They may white board a flow chart of the process, do some quick sketches of screen mockups, or make a list of business rules that need to be implemented. As the team works on writing the code they may go back to the whiteboard to discuss design issues or flow chart the flow through the code. Finally the code is complete, they test it, and release it.


It is easy to see that in this work environment, developing the requirements through conversations and white board sketches can work out (assuming the Project Sponsor actually knows the requirements).

But …. Does this description match what you see at work? Is the work environment described above anything like what you see at work?

My experience is that this kind of work environment is quite rare and in most companies it is not actually achievable overall. It would require a massive overhaul of the company, which would actually not be worth any benefits they might achieve. Instead, you might see this kind of work environment in small, well-defined areas of the company.


How is this model typically broken, and what are the consequences for requirements work?

These are the primary reasons the model breaks:
* The Project Sponsor does not have the time or the knowledge to sit with the development team and give them the requirements
* Your company is structured as silos and centers of excellence so there will be outside people, such as database, security, ops, and testing, that will be required to work with the team to complete all the work
* The team is distributed over distance and time – they cannot all work together at the same time
* There are a lot of users impacted by the work and all of them have to be considered when developing the requirements, not just what the Project Sponsor thinks needs to be done

What all of these things lead us to is the need for a requirements professional to elicit the requirements and document them in the best way to share that knowledge with people who are not physically present. For the vast majority of us, we need to document requirements because we cannot share them through conversation and white board sketches alone.

I do not mean to suggest that you have to produce big documents, nor do I think you should write all the requirements once at the start of the work effort.


There has been some fascinating research about the brain in recent years. What it tells us is that we as humans are genetically designed to respond to the present moment. We are not good at remembering things once the moment has passed, nor are we good at thinking of future impacts. Now clearly some people are good at those things, but most people are not.

Think about the last meeting you attended. If you did not take notes, how long did it take before you forgot what was discussed and what the action items were? Science tells us that as people leave the meeting, their brain drops a significant percentage of short term memory to leave room in short term memory for what they will be doing next.

This is why taking notes at a meeting is so important!

So even in an environment where everyone is together and having conversations, it is important to make notes of at least the decisions that were made and the action items that need to be addressed.

This is even more important when the team cannot sit together having conversations all day long. Any of the team members who are having discussions have to make notes to share with the rest of the team. Even if they can talk with the other people by overlapping work schedules, if they do not make notes for themselves, they will forget information that needs to be shared.


So what is the answer? I think we still need people who are trained in requirements elicitation, analysis, and a variety of ways to document information.

Here is an outline of an approach I have seen work really well:
1. The Business Analyst meets periodically with the person who is paying for the work. This might be a Project
Sponsor or a Product Manager.
2. The Business Analyst works with that person to determine the scope of the work – what are they paying for?
3. Based on that information, the Business Analyst determines what needs to be done to elicit the user stories. It might be working with the Project Sponsor or Product Manager. It might be working with various SME’s. It might be working directly with end users.
4. Before a new iteration of work, the Business Analyst works with the people who know the requirements (and often a testing professional) to develop the scenarios of a small number of user stories that will be implemented next.
5. This information is provided to the sponsor and the development team so they can determine what work will be done in the coming iteration.
6. The Business Analyst sits with the development team and determines what they need to know in terms of detailed requirements. The Business Analyst brings the right people to the team to discuss detailed requirements. In the situation where this is a lot of people, the Business Analyst may need to start work one iteration ahead of the development team, working on the detailed requirements to have them ready when the team is ready to implement them. In that case, the Business Analyst is the person that the team talks to in order to discover the requirements.
7. The Business Analyst creates just the right documentation to share the information with team members who are not local. This may be as simple as photographing sketches on a white board and posting the photos on the team’s online page.

The goal here is for the Business Analyst to work with the Project Sponsor ahead of the development team to be sure work is continuously streaming to the team. The idea is not to produce documents because some process said that every project has to have exactly those documents. Instead, you determine based on your particular situation what provides the most value.


It all starts with writing user stories and producing scenarios for them. Most likely the Project Sponsor will also want to collaborate with you to manage the user stories. And you, the Business Analyst, are the right person to determine how much and what kinds of documentation are needed to coordinate the work of your team.

Writing the Project Purpose

Have you been on a project where people just argue all the time about the features or the scope? Or a couple of the developers come up with software that contradict each other? Or no one seems to know what they are doing? Or maybe the team questions why this project is being done at all?

I have come across these kinds of things in a lot of projects. Let’s take a look at a real world example and show what you can do to fix these kind of problems.

No one knows what the project is about
One year into a 4 year project, I was invited to take over as Senior Business Analyst and Assistant Project Manager. The team had really been struggling with determining which requirements were part of the scope of this project and which were not. There were a lot of arguments going on between the Project Sponsor and the various stakeholders about what the project was supposed to deliver. The project should have been much further along after one year, but it kept being delayed while everyone tried to figure out what they were supposed to be doing.

Whenever I hear something like that, it is obvious to me that there is some problem with the project vision. Either it has not been shared with everyone, it is poorly described, or possibly some of the stakeholders disagree with it.

In this kind of situation, the first thing I want to look at is the project purpose or project vision to see if it is well written. Then I will interview key people in the project to see if they agree with the project purpose. I use this approach to discover what the problem is – a problem with the vision, with communication, or with lack of agreement.

Have you experienced something like that on your projects? I find it really frustrating to watch a team not making progress due to lack of direction and I just can not stop myself from trying to fix it.

Even though the project was already one year old, I went back to the original project documentation to discover what the project was supposed to be about. I also interviewed the Project Sponsor, Project Manager, and the key stakeholders of the project to discover what they thought the project was about.

I had the perfect excuse to do all that – I was new to the project so it was reasonable for me to ask what it was about.

I discovered that there were two, closely related projects, both of the vision documents were poorly written and confusing, and there was some of the same information describing the purpose and scope of each project. No wonder everyone was confused! Not only was the scope not clear on this project, but it was related to scope that was not clear on a second project!

In this situation where the two scopes were closely intertwined, I got permission from the Project Manager and Stakeholders to put both project visions together and rewrite them as if there were just one project. I analyzed the new vision, made sure it was clear and easy to understand, and got it approved by the Project Manager and the Stakeholders.

Once everyone understood the whole thing, they were able to divide the vision up into independent pieces. They actually redefined this as five new projects, each of which was well-defined and independent. That meant that instead of doing the projects one after the other, they could do all five at the same time.

We went from having one large confused team to having five small focused teams. There were no more arguments about which requirements were in scope or out of scope, no question about what was the most important thing to work on next, and the stakeholders were much more confident that they were getting what they needed.

What other approach might I have taken? Project 2 had not started yet, so what I had initially considered was just looking for related scope items and putting them all together in either project 1 or project 2, being careful to balance how much work was in each one based on their projected size.

In my particular situation this did not work for two reasons. First, there was a lot of overlap between the projects, so it was much easier to just put the whole set together to review. Second, the scope items were written so poorly that it was not clear which ones were related.

Before writing the project vision, I had to go back to the sponsor and stakeholders to find out what was intended by each scope item and rewrite a new set of scope items based on what was really meant. If the scope items had been well written, then it would have been easier to just move scope items between projects to remove dependencies and overlap.

In general, how do you fix problems with the project vision or project purpose? The basic approach is this:

  1. Review any written documentation
  2. Interview the Project Sponsor and key stakeholders
  3. Put together all the information you have learned and if there are any inconsistencies or areas that do not make sense, review the information with the Project Sponsor and together write something that does make sense.
  4. Analyze what you have written to be sure it is sensible and complete, do more research if you need to, rewrite the project vision if necessary, then verify it again with the Project Sponsor.
  5. I like to put the information into a formal statement or document so everyone gets the information the same way. This does not have to be a big document. I have worked on projects were 3 goal statements of one sentence each were enough to describe the project.
  6. Be sure to share this with everyone on the team. You will not remove the confusion unless everyone knows what the project is about.

Usually it is not much work to write a good project vision or project purpose. When it is a lot of work, that means it is even more important to do it right.


When it is a lot of work to write the project vision or purpose that is because there is a lot of uncertainty and misunderstanding. It can be a lot of work to resolve the issues and gain clarity.

Why is this important?

My project that was behind schedule after a year not only made up time, but finished early once everyone knew exactly what they were supposed to be delivering.

I see this every time that the project purpose, vision, or scope is poorly described – the team wastes a lot of time trying to figure out what they are supposed to be doing. If you spend a relatively small amount of time making sure the purpose of the project is clear, you save a lot of time for all the team.

Why is Software so Awful to Use? A Case Study and Call to Action.

Why are apps, websites, software, and other products still not very nice to use? We’ve spent more than a decade as an industry focusing on user experience, and yet I consistently find myself frustrated with the miserable experiences I have doing the simplest things on websites, in apps, in other software, and using a variety of consumer products.

I just went through a miserable experience trying to update an airline reservation. I won’t mention which airline because despite their really awful website (let me fix it, please, please, please) I love the company and in real life (not the web) my interactions with them are superior. Bear with me as I describe my experience (or see my conclusion at the bottom).

I found my reservation easily enough and found the button to change just one leg. That was nice. I wouldn’t have to worry about accidentally changing the other leg. On clicking the button, I expected to see details about that leg, but instead I got a choice of four buttons: change cities, change dates, change times, change seats. Ummm, I’m changing all of them. So what should I pick? I choose change cities and assume the rest will be changeable as well (this turned out to be a correct assumption).

I see my current flight information across the top. That is nice. It verifies what I am changing. It turns out having that information was REALLY IMPORTANT. There are 3 radio buttons: round trip, one-way, multi-city. Round trip is already selected. Wait, I’m changing only one-way. Why is round trip selected? The whole trip is round trip, but I’m only changing one part. What to choose? I left it alone because surely they would have defaulted to the right choice. Being skeptical I scrolled down the page and saw they wanted me to select travel in two directions. So they didn’t default to the right choice. I scroll back to the top and select the one-way radio button.

I had to wait for the page to refresh. When it refreshed the page now showed select a date. Wait, I haven’t changed my city yet! I scroll back to the top to pick a city. The departure city is fine, I select the destination. The screen refreshes back to select a flight and the departure city is not the one I selected. What? I did not change the departure city and I have yet to select the date. Scroll back to the top and select the correct departure city. Which changed the destination too, so I had to reselect that.

Wait for the screen to refresh. Again. It refreshes at select a flight. Thankfully it now has the right cities, but I have not yet selected a date. Scroll back up to select a date. The screen refreshes back to select a flight, but the date has not changed. Scroll back up and see that the correct date is selected. Re-clicking it does nothing, so I select a different date. The screen refreshes at select a flight and it does have the date I just selected (which is not the date I actually want). I scroll back up and select the date I really want. The screen refreshes again at the point to select a flight.

At least now I have the right type of flight (one-way), the right cities, and the right date. Now I select a flight. I get a banner saying the change is being processed, then a message that said something went wrong, try again, or call us.

I just wanted to cry from frustration at that point.

This whole process took me far longer to do than it took you to read about it, and they are asking me to start over. They even provided a helpful start over button!

Sadly, my experience that day was far from unique. That is crazy. We humans should not have to work so hard to do simple things with a computer.

I want to do something to make things better. This is what gets me so excited about Solution Anthropology.

Solution Anthropology blends practices from Business Analysis, User Experience, Solution Design, and Anthropology for the purpose of creating solutions that delight the users. It is a user advocacy role and a terrific way for Business Analysts to grow their knowledge in a way that expands career opportunities. Solution Anthropologists work in companies of all sizes from major corporations to startups and work on solutions in areas such as software, business process improvement, branding and imaging, mobile, and product development.

I am working with my clients to incorporate Solution Anthropology practices into their projects, whether Agile, Waterfall, or other. Everyone is happier when we do. And maybe someday I’ll get my favorite airline to apply Solution Anthropology to their website!


New BA Video Tips

I have set up a video channel for Business Analyst tips on YouTube.
There are 15 videos there at present including:

  • 5 steps to better use cases – parts 1 and 2
  • Business rules versus Technical Constraints
  • Use Stories versus User Cases
  • Business Analyst Career Paths
  • and 10 videos on how a BA would start to work on a project
  • There are 10 different project types, so 10 different videos

I’ll be adding more over time, so let me know if there is something you want me to make a video about!

Here is the link again:

Pass on the link to other BA’s you know.

Thinking about your BA Career

In the early part of each year, I often get a flurry of people writing to me to ask for career advice. I get questions such as:

  • Is Business Analyst a good career?
  • Which job is better, XXX or Business Analyst?
  • I have been a Business Analyst for XXX years, what can I do now?

I cannot really answer these questions because the answer depends on what you want for yourself. My answers are always suggestions of things to think about, so that you can find the best answer for you.  The suggestions are generally about career planning.

You need to spend some time thinking about what you want from your career. You can change your mind later, but you need to have some kind of career goal, or you have no basis for answering these kinds of questions.

I made a video that goes through quite a bit of information on common career paths. It gives you a lot to think about, so that you can choose what appeals to you in terms of a career goal.  You can find that video on Wyyzzk’s YouTube channel:

Once you know what you want, the answers about whether or not to pursue a BA role or what you can do next become obvious.

The video does not cover every possibility and individual people have had some very different career paths. I have focused on careers within the corporate environment, because that is generally where you find BA positions. Of course there are exceptions – I know many people (including myself) who work as BA consultants and contractors. But that number is far smaller than the number of people working within corporations.

Managing Up

I was pleased when Geri asked me to write a guest post about managing up. I think it is an important skill that everyone should cultivate, regardless of job level or industry. The following post skims the surface–I look forward to any questions or comments you may have so we can expand the conversation.  -Jen

One of the most important skills any professional can have is that of “managing up,” or Managing Your Manager. While the idea of managing the person who is supposed to manage you may sound contrary, you can also think of it as a beneficial outcome to communication, demonstrated professional integrity, and good consulting skills.

Managing up also is a form of visibility, or presence. As workplaces and teams span locations and more of us work remotely, it is important to remain visible in a positive way. Being top of mind (and showing how responsible, consistent, and good your communication skills are) is a great way to get considered for successively more interesting or challenging projects. Plus, you’re helping to ensure that your manager isn’t caught off-guard when it comes to you or your projects, and that often translates to more latitude (or less micro-managing).

What is it, really?

Managing up will sound like your boss is going to get more out of it than you will. In the short term, that’s probably true. A big part of managing up is to help your manager look good by keeping him apprised of what’s going on with you, your projects, and the team. The benefit to you is that people appreciate it when their staff–or teammates–help them look good. You get the benefit of people wanting you on their teams and the good professional reputation you’ll build in the process.

  • It is a tangible demonstration of your professional integrity. In his book “Selling the Invisible: A Field Guide to Modern Marketing”, author Harry Beckwith states, “Invest in and religiously preach integrity. It is the heart of your brand. The heart of a service brand – the element without which the brand cannot live – is the integrity of the company and its employees. The value of any brand rises or falls with each demonstration of the company’s integrity.” (p. 155). In this case, rather than thinking of the “company” brand, think of it as your personal brand–the value of your brand rises or falls with each demonstration of your integrity. Giving your boss a heads-up when something didn’t go well, reporting what you have been and will be working on (without it being required), and telling the truth are all demonstrations of personal integrity.
  • Your manager should always be able to answer the question, “What is Judy/the team/the department working on?”. By proactively providing this information, you are helping your manager to look good to his/her peers or boss – and that’s always a good thing.
  • Your manager should never be caught off guard by hearing project news from someone else. Especially if it’s bad news! If something transpires that may result in a call to your boss, make sure he or she hears about it first from you, and not when they are cornered in the company cafeteria or restroom. It may be very uncomfortable to deliver bad news to your boss, but it’s guaranteed to be even less comfortable if they hear about it from someone else–and look uninformed or not in control of their staff/team in the process. By hearing about it before having to have a conversation, they can be better informed and prepared for any conversations that may arise–or have the opportunity to be proactive and nip a potential issue in the bud.
  • Managing up isn’t just for the little guys. This is one skill you’ll always need – everybody has a boss, even if it’s the Board of Directors.

How do I do it?

You might be wondering how this managing-up thing works and how it’s accomplished. Here are a few suggestions based on my own time-tested practices:

  • Provide a weekly status report, even if one isn’t required. Especially, in fact, if one isn’t required. It can be a simple email or one-page document that lists:

– What you accomplished that week

– Any issues or roadblocks

– What you’re working on in the coming week

  • Provide an as-needed update, especially if something significant happens relative to a project. If good or bad news comes up for a project, let them know right away–no need to wait for your weekly status report.
  • Keep it short. The point isn’t to over-burden your managers with minutia. If they want more information, they’ll ask for it.
  • Keep your tone professional. Managing up isn’t about competing with others, it’s about being professional and helping your boss to look good.

Here are a few examples from my own experience and that of friends:

  • “Hey, Jane–I just had a meeting with the stakeholders from Underwriting. They were not happy with the process we’re suggesting for (whatever).” (As business analysts, this will happen, probably more than we’d like it to.)
  • “Hey, Jane–I just met with Customer Service – they were really pleased with ….” (Stop in and deliver some good news, too – especially if something goes better than expected.)
  • “Hi, Stan, here’s some info you’re going to need. You don’t need to go over it now, but you’ll want to have it on hand.” (This was from a friend who works in a contentious engineering environment. After a meeting, he dropped off crucial numbers at his supervisor’s desk. His supervisor was then prepared to deal with the irate visitor he had thirty minutes later.)
  • “Do you have a minute? I was just in a meeting with Art from Accounting and I really lost my patience with him. I want to let you know before you get a phone call.” (Awkward? You bet. But not as awkward as getting called into your boss’s office after s/he gets a phone call from Art or Art’s manager. For best results, be sure you take responsibility for your actions, and let your manager know what you plan to do to remedy the situation. Or, ask for suggestions on the best way to deal with the individual. No matter what sort of jerk the other person may be, you will always look good by taking responsibility for yourself and behaving professionally, which is to say, not whining or blaming.)

Managing up takes some discipline and some courage. You will find that it improves your personal brand and over time is well worth the effort. This is a long-term career investment; get started today!

Becoming a Business Analyst

Author: Geri Schneider Winters

Many people contact me because they want to be a Business Analyst. They are often in another job currently and want to change roles. They want to know “What do I need to do to be considered for a Business Analyst position?”.

A good starting point is to look over the IIBA BABOK to see how the BA role is defined. What is a BA? What does a BA do? What skills is a BA expected to have?

Then review your own experience, compare it to the skills in the BABOK and make an inventory of the work you have done that is also Business Analyst work. Have you elicited requirements, managed information, facilitated meetings, or used tools such as requirements management, version control, or UML modeling tools? Do you analyze information in your current position?

You will use this information to tune your resume, highlighting your experience that is applicable to a Business Analyst role.

You will also use this information to find gaps in your knowledge. What are some basic skills you need that you may not have gained from experience?

You can study books and online material for the information you lack. A better idea is to take a course for Business Analysts with a teacher experienced in the BA role.  Not only will you gain the knowledge, but the teacher will give you work to do and evaluate that work, so you gain some experience as well.

Finally, look at the IIBA certifications for CCBA and CBAP. You may find that you qualify for one of those certifications. Completing the certification process shows you have a certain level of knowledge and experience as a BA, and shows that you are serious about your career.