Skip to main content

Author: Cecilie Hoffman

The Bad Ass BA Observes the “Hunt for the Right BA”, Part 2

In the January article, I talked about the job seeker’s difficulty sorting through job descriptions for business analysts. In Part 2, I want to turn it around and look at the “specialist” vs. “generalist” question that we face as we create our resumes – how do we position ourselves as we respond to job postings?

In the Feb 2011 IIBA Newsletter, Laura Brandenburg, IIBA Career Center Product Manager, said, in her article, “5 Steps to Becoming a Business Analyst”

Although IIBA® holds us business analysts together under a unified understanding of business analysis, the real world of business analyst job roles is often messy and difficult. BA roles, as we learn in the competency model, fall into three main buckets:

  • Generalists, who perform a wide variety of business analysis activities
  • Specialists, who use a limited set of techniques or a single methodology
  • Hybrids, who do business analysis within another job role

I think there’s a little more to consider. We have to put the generalist vs. specialist discussion in the context of the course of our careers, entry-level, mid-career, experienced-and-having-too-much-fun-to-retire. Here are three typical patterns:


In Pattern 1 you began your career doing software testing in under watchful supervision. Your manager was pleased with your instinctive planning and thoroughness and arranged for formal training in quality assurance. Along the way you discovered use cases and the iterative development. You became a QA generalist for software products, often requested by product managers for “dot oh” releases. Over time, your role evolved into a business analyst role with a specialization in testing activities.

In Pattern 2, you were hired as a business analyst because that’s the title all straight-out-of-college entry-level technical people were given until the manager figured out what you were good at. You had no clue what the BA role was or how to do it. You were given all kinds of work to do, and by asking questions you just figured it out. Because you were able to establish a good working relationship with Group X, you became the go-to person for their application, helping them map their business processes, determining their requirements, designing the user acceptance tests, often coding the changes and jacking the new code into the release environment. A larger company that has better software deployment practices bought out your company; you are no longer allowed to hot swap modules into the production environment. Instead, thanks to your new ITIL Foundations certificate, you became the BA manager for the new group that absorbed Group X.

In Pattern 3, the specialist pattern, you came out of school with a strong database background. You hired into a company that was transitioning from an in-house built HR system to PeopleSoft and became a data migration SME in no time flat. Because you showed that unusual combination of communication and analysis skills, your role shifted from database developer to functional requirements specialist to HRIS business analyst. Over the years your knowledge of PeopleSoft has become greater, both in depth (the integration of PeopleSoft to the company’s ERP system) and breadth (all the different business teams that use PeopleSoft and their wide variety of needs). You started speaking at conferences and writing articles for trade journals. Eventually, you started your own consulting company and now you are traveling the world, helping other companies with their PeopleSoft projects.

There are risks and benefits to both being a generalist and a specialist by the time you are at mid-career. In a nutshell, the risk to being a specialist is that you may become so narrowly focused as to limit your career growth options. The risk of being a generalist is that you may be lacking in-depth knowledge that would make you instantly useful to a hiring manager. The benefit of being a specialist is that if you have the high-demand skills, the likelihood of spending much time on unemployment goes down. The benefit of being a generalist is that you see the patterns across organizations and industries – your big picture view can make you extremely valuable to the right employer. Moreover, an employer who is looking for a generalist is likely to have an expectation of teaming you with subject matter experts.

How can an IT BA become a generalist? In the world of IT, Business Analysts tend to cluster in one of four areas, infrastructure, applications, operations and project management.


Project Management. Glenn Brulé coined the term “PooMBA”, a person who is paid one salary to do two jobs. In some back water IT environments, BAs are still “junior PMs”. There are also BAs who are acquiring and refining their project management skills by voluntarily taking on these types of responsibilities.

Infrastructure. The business analyst who has a lot of infrastructure experience may have a specialist title, e.g., network specialist or security specialist. While their job description lists all the technical expertise they are expected to have, the description may gloss over the crucial role they play in communicating with other technical teams. Middleware specialists e.g., TIBCO developers often have an Applications Developer title. While their focus may be on the low level functional requirements, the knowledge and skills of requirements analysis, management and communication are still critical to the success of the projects.

Operations. In the world of Operations, business analysts are often found juggling change requests, release schedules, quarterly freeze exception requests with one hand, and SOx guidelines with the other. Their managers may not think of them as business analysts, but the knowledge area of business analysis planning and monitoring applies directly.

Applications. Business and technical applications are as plentiful as mosquitoes at your picnic at dusk. A ridiculously over-simplified view of the world would put business-level applications in one bucket, and everything else in the other bucket. By business-level applications I mean those in the class of Enterprise Relationship Management systems, e.g., Oracle, or Human Resource management systems, e.g., PeopleSoft, or Supply Chain management systems, e.g., SAP, or Customer Relationship management systems, e.g., Sales Force, and … those applications that support a business function that is specific to the type of organization, for example, many city governments use Azteca’s Cityworks. Many Business Analysts spend their entire career in one application!

Let’s look at Petra’s situation. Her most recent experience is five years of experience doing release management. Prior to that she had two years of application change request management as an entry level BA. She has been the release management team lead for the past year and after that very long year the job is no longer an interesting challenge. Petra is worried that she has become pigeon-holed in her job, that is, her manager assumes she’ll do release management forever. Petra knows the operations angle of her job very well, but she hasn’t ever worked on a business case, she has never done a solution assessment, let alone worked on a cross-functional strategic initiative.  She’s really good at release management and she knows these skills would transfer well to another company. Should she branch out or should she stay focused in this one area?

She looks at her company’s job postings and sees one in the Network operations group. They need a business analyst with requirements management skills and some PM experience. She has no infrastructure experience at this point in her career, should she apply for the job?

There’s no right answer – only more questions to be asked – chief among them is whether she is interested enough to explore this new area. Some companies have good Human Resource staff that can ask her questions to help her make a decision. Petra can also talk to her manager about career development – a good manager is willing to help. She could also talk to the manager of the network project to find out if she might be a good fit. Maybe this isn’t the right project, but there will be others. And, it will give her current manager time to plan a transition. Talking to her colleagues can also be helpful – they may know of even better opportunities for what they perceive her strengths and interests to be.

Truth be told, I have a bias towards developing a broad base, I think that a wide range of experience gives a BA a qualitatively better perspective to assess risk and benefit. You could argue that while I’m a generalist business analyst, that is, I have no expertise in any applications or infrastructure technologies; I have also specialized in being a generalist. In the same breath, I could argue that a Finance BA who systematically becomes proficient with every module in Oracle ERP is a person who has generalized specialist skills in a single application.

There’s plenty of wiggle room in the specialist – hybrid – generalist model, which is one of the beauties and aggravations of Business Analyst position. There’s more to job-hunting than just responding to job postings and shaking down your LinkedIn network for leads. Think about what you want from your career, what you are curious about, what skills and experience you want to acquire to make yourself the right BA for the jobs that interest you as well as the right BA that the hiring manager is hunting for.  

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times and most recently the poem, A is for Analysis. See her blog on her personal passion, motorcycle riding, at [email protected]

The Bad Ass BA Observes the Hunt for the Right Business Analyst

cecilie_Feature_CroppedLike so many other people, I’m job-hunting. Job-hunting is never easy, even when you are doing it from the relative safety of having a job, but one that you would like to leave. In this era of the robo-online job postings, job-hunting feels particularly demoralizing because most companies do not provide any form of closure on your application. You apply, you get a robo-acknowledgement of your application and then you hear nothing for weeks and months. In four months of searching I have received exactly one email, machine-generated, that thanked me for my application and informed that the position had been filled. That organization went to the top of my list for, “keep an eye on them – they would be good to work for” because of the implication that someone had written a requirement to actually close the loop with applicants!

There are some good job postings out there, jobs that describe a position with required skills, experience and responsibilities that make sense for a business analyst. There are also a plethora of weird job postings wherein the job described seems either too narrow or too broad or suffering from role confusion. I’m seeing pattern in these less-than-optimal job postings. It seems that every company has their own definition of the role of the Business Analyst. From where I sit it is going to take more than a grass roots effort from the BA community to bring together the HR / hiring manager view of the BA and the IIBA’s vision of the BA. Here are four patterns in the job postings that cause me the most consternation:

Pattern #1: The “Bird in a Cage” model

Requirements jockey – We need you to handle proposal requests. You will write the BRD and throw it over the wall to the outsourced development team.

Requirements change control czar – “We need a patient, detail oriented, people-oriented person with excellent documentation skills.” Translation: you will be in the person that everyone complains to. The users and their managers will always be escalating; the development team will always be exhausted, and the auditors will always be looking for something to be wrong with the record keeping.

Pattern #2: The “Two for One” model

System Analyst / Business Analyst – “The successful BSA will drive end user experience innovation. Must have professional software development experience with front end web development (JavaScript, HTML, CSS, AJAX) and the ability collect requirements from stakeholders.”

Quality Assurance Analyst / Business Analyst – “You are the right person if you can model business processes, facilitate discussions and write detailed business requirements and use cases, facilitate walkthroughs of detailed business requirements and use cases, and perform functional tests.”

Project Manager / Business Analyst – “You are the right person if you can compartmentalize the perspectives and responsibilities of a PM and BA for a business owner who dithers. The last BA hired was great at dealing with the project stakeholders musing about changing direction, but her head exploded when she put on her PM hat and considered the ramifications to the project.”

Pattern #3: The “All in One” model

“You are the right BA for this company if your background includes an MBA, and MA in Information Science, and you have managed projects, and you have both IT and product development experience, and you have worked with marketing and sales teams and you are fluent in Mandarin Chinese, Russian, and Portuguese. 50% travel.”

Pattern #4: The “clone the 25-year veteran who just retired” model

“The right BA for us has experience in our customized PeopleSoft modules, can modify Business Intelligence reports, is familiar with SFDC, can do a mind meld with stakeholders, can hold the requirements traceability matrix in their head and can mentor junior business analysts.”

The IIBA is already working with PMI so that there will be a better understanding of the contributions of the two roles to future projects. Perhaps the IIBA might consider an initiative to work with Human Resources professional organizations as well. In my humble opinion more could be done to educate HR staff and hiring managers about the role of the BA. In many companies, “job reqs” (job requisitions) are drafted by the hiring manager and completed by an HR staff member. If that HR staff member were more familiar with the envisioned industry standard BA role, we might see fewer job postings like the ones above. In my ideal world, there would more consensus amongst companies about the role and value of the business analyst. Moreover that consensus would be in alignment with the IIBA vision, and we wouldn’t see job postings that leave us scratching our heads in bemused consternation.

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times and most recently the poem, A is for Analysis. See her blog on her personal passion, motorcycle riding, at [email protected].

The Bad Ass BA Returns in Didactic Pentameter

The first annual IIBA conference, was conducted in Alexandria, Virginia in October 2010, entitled Building Business Capability (BBC). The conference was a collaboration between the Rules Forum, the Business Forum and the Analysis Forum (the IIBA). A collaboration – how perfect for a business analysis conference. Attendees were encouraged to visit talks in all three tracks and I feasted! I came to this conference in need of perspective, validation, encouragement, enthusiasm and vision, and came away with all that and more. For me it felt like someone had opened up a fire hydrant and unleashed a high pressure stream of quotable phrases and ideas.

The poem below is a distillation of the business analysis track of the conference. My apologies to people who are skillful in this art of iambic and dactylic meters (da dah vs. da dah dah). Read the poem out loud for the best result.

A is for Analysis

A is for analysis – differentiate and abstract,
yields requirements and rules from science inexact.

B is for business, whose capability we improve.
Maximize throughput? Just a step in our groove.

C is for change, for better for worse,

D is for decisions, or leaderless we curse.

E is for elicit, requirements fall not from trees!

F is for functional, remember non-functional, please.

G is for goals, stakeholders have their own,
non-overlapping, we lament and bemoan.

H is for how, counterpart of what,
a distinction so simple yet a knot hard to cut.

I is for iterative, cyclic nature pervades all,
yet management grips tightly to venerable waterfall.

J is our judgment project managers fear,
twin loyalties to business and to projects dear.

K is for knowledge we continuously accrue,

L is for listening which we actively do.

M is for metric, the chestnut is true,
that which we measure can be improved, can you?

N is for negotiate, can everyone agree?
Cross-functional monkey rodeo, that’s no way to be.

O is final outcome, our striving to delight
the blessed product champion who was our guiding light.

P is for process leaving nothing undone,
identifying hidden handoffs, one by one.

Q is for questions we have license to ask.
Assail those assumptions, take them to task!

R is for requirements, our stock in trade.
Oft mistaken for specification, please hand me a blade.

S is for scope, that game of ping pong,
one stakeholder to go,will the decision last long?

T is for trust, partner of integrity.
Armed with the pair, analysis proceeds intrepidly.

U is for users whose lives we make better,
improving usability or efficiency unfetter.

V is for validate and verify, they are different you know,
but it’s value, true value that analysis shows.

W is for who, what, when, why and where, the pentagonal key
that unlocks preconception setting ideas free.

X is for executive whose sponsorship we seek,
facilitating these folks is not for the meek.

Y is for yes, magic word of approval.
Can it be heard without a tribunal?

Z is for zilch, either missing or unknown,
the truth will emerge once the seeds have been sown.

* * *

But what about all the other words I could have chosen? I’m so glad you asked! Here’s the lexicon I started with; I challenge all of you to write your own poem and have fun!  I would love to see what you come up with.

A agility, action, automate, analysis

B business

C constraint, committee, consistent, compliance, communication, change

D data, deliverable, decision

E efficient, effective, elicit

F functional, non-functional, facilitate

G governance, gathering, goal

H how

I issue, IT, impact, implement, initiative, influence, iterative

J judgment

K knowledge

L list, leverage, listen

M manage, methodology, metric, missing, measure

N negotiate

O operations, objective, organization, outcome

P production, project, product, process

Q quality, questions

R risk, rule, research, record, ROI, relationship, requirement

S success, structure, support, SME, sign-off, supplier, solution, system, specification, scope

T tools, training, terminology, test, TBD, trust

U understanding, use case, unknown, user

V voice of the customer/data/IT, version, vocabulary, verification, validation, visible, value

W work breakdown structure, who-what-when-why-where

X execute, excellence, executive (cut me some slack)

Y you, yes

Z zero, zilch

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times. See her blog on her personal passion, motorcycle riding, at[email protected].

Launching Fledgling Business Analysts

launchingfledglingA fledgling is a bird that is out of the nest but still dependent on its parents for food and care. Recently I was contacted by a technical support/system administrator in my company who wanted to know more about this profession called “business analysis”. This young man, let’s call him Brandon, had been singled out both by his peers and his manager to be the person to talk to internal customers. Brandon had shown a talent for engaging with the customers to find out if what they asked for was what they really needed. (ding!)

Brandon hasn’t written formal requirements and he hasn’t done work on a project that has lasted for more than two weeks. He has experienced customers changing their minds half way through the delivery of the service. He has realized that he is the only one in his peer group who can “speak geek” and in the next breath “speak manager” and not break a sweat. (Ding ding!)

I gave him a whirlwind tour of business analysis by introducing him to the IIBA website and giving him a “tips of the waves” tour of the Knowledge Areas in the BA BoK. Unfortunately the corporate training for business analysis skills section that used to be in place is on hold for a while.

Other than suggesting he join the IIBA, download the BA BoK and find a local chapter to join, I couldn’t really offer him much more personal support for learning about the BA profession because of the geographic separation between us. Brandon asked if I knew any BAs in his location whom he could job shadow. “Job shadowing” is a way for a person, typically a student or intern, to learn about a day in the life of a professional by following the professional around for a day. To my delight, one of the senior BAs that I contacted, let’s call him Steve, responded with “yes, I’ll set up some time with Brandon”. Steve deserves a halo and wings.

Steve’s generosity made me think about what I would do if Brandon were to shadow me. What exactly could a senior BA invite a fledgling BA to watch or listen to?

Traditionally job shadowing is done all in one day. Given that Brandon is working a full time job, I had suggested that he consider having Brandon shadow him in a few two-hour sessions over a couple of weeks, or some similar arrangement. Here’s a list of seven suggestions for job shadowing activities where the senior BA spends several increments of time with the fledgling.

Bring the fledgling with you when

  1. You are collecting information from stakeholders for the business case.
    Give the fledgling the business case template or the work-in-progress business case so they have something to ground the information that will be swirling around.
  2. You are eliciting requirements from, or reviewing a use case with the stakeholders. If more than one session is planned, it would be great to have the fledgling observe a sequence of elicitation sessions. 
  3. You participate in a requirements document peer review. If you want to make a huge impression, pick a peer review that has one of your BRDs on the agenda. Give the fledgling the business case and the BRD to review a couple of days in advance – whatever they can soak up is fine.
  4. You discuss the requirements with the architects, infrastructure people, or user interface advisors, for the purpose of articulating a design.
  5. You and the project team discuss the scope changes requested by the customer.
  6. You and the PM discuss the plans for a User Acceptance Test.
  7. You conduct the daily review of the UAT progress with the stakeholders.

It’s okay if any of the above interactions don’t go as smoothly as you might have liked. It is important to model patience, resilience and perseverance. It is important to model “leaving your ego at the door”.

If you’re thinking to yourself, “Well, I’m not so sure I’d be a good person to shadow, I spend a lot of time just typing at my computer”, read the suggestions again. What do they have in common? You got it, “interacting with other people”. I can’t think of anything more boring than watching someone else type.

Many years ago I participated in the Expanding Your Horizons (EYH) conferences. EYH is a program designed to encourage girls in grade school through high school to take classes in math and science. A young lady came up to me after my talk; she seemed vaguely familiar. She had attended my EYH presentation two years previously as a junior in high school. My heart soared when she said she had changed her original college plans and was attending Carnegie Mellon University in the Artificial Intelligence/ Computer Science program. She was having a blast in school and had just stopped by to say hello during Spring break.

Going back to Brandon’s situation – he is lucky! Brandon’s manager recognized a diamond in the rough and suggested that he look into business analysis as a career path. Brandon had the wherewithal to follow through and find a senior BA to talk to. (ding ding ding!) And, true to the nature of “being the bridge”, Steve, the heaven-sent senior BA, decided to check out the raw talent and stepped up to the task letting Brandon job-shadow him. Maybe in six months I’ll get an email from Steve, “Hey, remember that guy Brandon? He has been re-assigned to my team as the junior business analyst.”

Don’t forget to leave your comments below

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding, at She can be reached at [email protected].

What is the Future for Senior Business Analysts?

futureforsenior2Now that you are recognized as a senior business analyst, what can you look forward to in your professional future?

BAs who have ten or more years of experience often feel “topped out” in their career path because most companies assume that senior BAs will develop into something else, such as a project manager or product manager. If a business analyst wants to extend herself beyond a single business function or provide more consultative guidance to her business unit, she typically has to change roles and embark on a different career path. Once a BA’s head has hit the company’s career path ceiling, there is often no place to go but to another company for advancement. Even so, most companies do not have a growth path for a business analyst who is already senior.

In this article, we will look at options for our professional future and talk about ways to extend ourselves professionally.

Where BAs Come From

Many of us came to have the business analyst title through roles such as

  • Power User
  • Developer (or “Programmer”, or “Systems Analyst” to use the old-fashioned terms)
  • Quality Assurance Analyst
  • Database Administrator
  • Technical Support, Customer Support specialist
  • Infrastructure (IT) specialist

Managers recognized that in addition to our remarkable analytical skills we had special qualities, such as our ability to ask questions about the big picture, or our ability to be the communications bridge between a customer and the technical team, or be the communications “hub” for the entire technical team. We found ourselves playing the role of the business (systems) analyst whether or not we had the title.

Currently the typical growth path for a senior BA is to become a

  • Project Manager
  • Product Manager
  • Account Manager (internal customers)

In some companies, a senior BA can add the following titles to their list of possibilities:

  • Architect
  • Business Process Analyst

In my humble opinion, one of the best things a BA can do for him/herself is to get savvy about process analysis. If your current position keeps you focused on the details, consider coming up for some air, learn to analyze the processes that are generating the details and the predictable system failures that you are drowning in. Maybe the root of the problem is not in the data itself but in the processes around the data.

Maybe you are already spending a lot of time with the system architects in IT, and the business architects on the business side of your company. Architecture is the art and science of designing structures whether they are physical or logical. With all of your experience, you may be at a point in your career where you’re ready to focus on design.

Jonathan Kupersmith’s blog article, “What?! You Don’t Want to Be a Project Manager” summed up the BA to PM transition controversy quite nicely. Product manager and account manager both have the word “manager” in the title; some people assume that becoming a manager of some sort is the only way to show that you have achieved success. Let’s say that you are an iconoclast, not driven by what other people think or the strictures of your country’s norms – you don’t want to be a manager, you want to be recognized as a senior business analyst and you want career growth. Is that so much to ask?

What Does it Mean to be Senior?

Being senior is more than just “years on the job”. Being a senior BA implies:

  • Mastery of core business analysis competencies and corresponding skills
  • Both breadth and depth of knowledge and experience
  • Knowledge of business processes
  • Leadership

The IIBA identifies these categories of core competencies, called underlying competencies in the BA Body of Knowledge (BABoK):

  • Analytical Thinking and Problem Solving
  • Behavioral Characteristics
  • Business Knowledge
  • Communication Skills
  • Interaction Skills
  • Software Applications

These competencies have nothing to do with domain knowledge; these are the competencies a BA brings to every job assignment. The skills that correspond to these competencies are:

  • Facilitation
  • Requirements Elicitation
  • Modeling
  • Negotiation
  • [Process] Change Leadership
  • Requirements Planning & management
  • Stakeholder Management
  • Verbal Communications and Presence
  • Written Communications and Documentation
  • Technology Understanding and Application

As a senior BA, you may or may not have equal levels of mastery of these skills. The three aspects of being a leader as BA that I want to call out are, being an agent of change, being a speaker of truth, and being a role model. These three aspects are key for senior BAs to set their sights on what the BA Body of Knowledge calls “Enterprise Analysis”.

Being acknowledged as the “go to” person in your group can feel great because you can share your experience and knowledge with others. Being senior can also bring on an empty feeling. Most BAs need new challenges; we need to keep learning; we can’t survive on the same old problems. No one wants to live with an old leaky faucet; not only does the dripping sound drive us crazy at night but knowing that water is being wasted without taking action is morally wrong. We BAs need to find satisfying ways to apply our brain power.

Kathleen Hass has written a wonderful book, From Analyst to Leader – Elevating the Role of the Business Analyst. I recommend this book both to business analysts and managers of business analysts because Ms. Haas and her contributors have accomplished an impossible task, they have articulated in just 120 pages what leadership means for a BA in the two overall contexts that a BA may work in: a project, and a business solution life cycle. Moreover, there is a chapter on establishing a Business Analysis Center of Excellence.

Next Steps

As a senior BA who is feeling that the ceiling is coming closer and closer to the top of your head, how do you extend your knowledge and experience range? Think about this in terms of how big a step you want to take, a small step, a mid-sized leap, or a big leap.

  • Small step

Stay within your general domain (or business process) but add a new, closely-related sub-domain (or business process) to complement your existing specialty area.

  • Mid-sized leap

Extend your activities into a new domain within your current business unit, so that you can take advantage of the trust-based relationships you have with senior and executive managers.

  • Big Leap

Extend your activities into an unrelated domain where you will have to build new relationships with managers and single contributors. This kind of leap is not for the faint of heart.

Let’s look at an example.


A small step would be working in Finance where you are a Senior BA in sub-domain F1.2, and taking on activities or responsibilities for closely-related sub-domain F1.1.

A mid-sized leap would be working in Finance where you are a Senior BA in sub-domain F1.1 and taking on activities or responsibilities in related sub-domain F3.1.

A big leap would be working in Finance and taking on activities where you must learn about the IT infrastructure that supports the business applications used in Finance.

Here’s what you need to think about as you decide how much you want to start extending yourself:

  • What is your risk tolerance?
  • Do you trust your command of the core competencies?
  • How fast do you absorb new information?
  • How fast do you build allies?
  • How badly do you want to influence improvement?

As a senior BA, you are a subject matter expert. Do you remember what it feels like to “not know”? What is your tolerance for “not knowing”? What is your tolerance for not having allies? Will your ego allow you play the “I’m new, please forgive me if I don’t know how this works and I have to ask a lot of questions” card. If you dive in and the waters are too deep, will it be okay for you to take a step back? The more comfortable you are with “not knowing”, learning new information fast, building new allies quickly, the bigger the leap you can take.

When you have answered these questions for yourself, determine how to frame your request to expand your activities in a manner that shows your manager that you are thinking about the benefit to the company, not just your career path. As a senior BA you are probably quite well aware of where there are needs in your company.

Enterprise Analysis

Defining a business need and making the business case for finding a solution to meet that need is heart of the BA BoK knowledge area called Enterprise Analysis. The tasks involved in this knowledge area are defining the business need, assessing the capability gap, determining a solution (high-level) approach, defining the solution scope (high-level), and defining the business case. The IIBA identifies the following skills for this knowledge area:

  • Benchmarking
  • Brainstorming
  • Business Rules Analysis
  • Decision Analysis
  • Document Analysis
  • Estimation
  • Feasibility Analysis
  • Focus Groups
  • Functional Decomposition
  • Interface Analysis
  • Metrics and KPI
  • Problem or Vision Statement
  • Risk Analysis
  • Root Cause Analysis
  • Scope Modeling
  • Strengths, Weaknesses, Opportunities, Threats (SWOT) Analysis
  • User Stories
  • Vendor Assessment

I would add “writing a business case” to the list of skills as a business case is a well-understood documentation artifact that has a commonly understood structure and content. Typically, senior BAs have competence in some but not all of these skills. Senior BAs take note – when you are thinking about where you want to expand your knowledge and experience, think about the skill development you will need. Just like changing the batteries in the smoke detector in your home when we switch to daylight savings time, the beginning of the year is a good time to update your professional development plan – what do you want to accomplish this year? Your manager may not be able to respond immediately to your request with a new assignment, but your manager may be able to approve training for you in anticipation of helping you take on a bigger challenge.


We started with the question, “What is the Future for Senior Business Analysts?” We made the assumption that you don’t want to be a manager, and you are perfectly happy being included in architectural discussions but you like being a business analyst. There are two issues here, the first is your skill set, the second is your title. With respect to your skill set, think about adding or improving the Enterprise Analysis skills listed above. Also think about adding process analysis and process engineering to your tool kit.

The thornier topic is your title because job titles are defined by your company’s Human Resources group. Enlist your manager’s help – ask to see the job descriptions for business analyst positions for all grades. If you are truly “topped out” in your grade level, ask If there is job structure for another role that could be used to create a career growth path for senior BAs. For example, what is the highest position that a single contributor in the engineering organization can achieve? Could that model apply to the business analysts? It may take some time and considerable energy from your manager to help HR understand the need to create “head room” for a job family that was not envisioned to support senior contributors. We senior BAs need to influence this change both for ourselves and for the BAs who are going to be turbo-charged in their development, thanks to existence of the BA BoK. The next ten years will do more than set precedent; the next ten years will establish a standard practice of cultivating talented, battle-hardened and business-savvy BAs to share their knowledge and experience with the entire enterprise.

Don’t wait for the business analyst job structure to catch up. Get out there and be the role model for what you believe a senior BA can do. Take it one step or one leap at a time.

Don’t forget to leave your comments below

Cecilie Hoffman is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding, at [email protected].