Author: Adriana Beal
One of the topics that appear to be on the mind of many business analysts lately is the expansion of the business analysis role. How can a BA make a difference in his/her organization, perhaps going beyond conventional analysis to become a visionary? What are the challenges a BA may need to overcome to respond to the increased expectations of companies who hire business analysts not just to manage requirements, but also to perform project management and participate on decision-making processes?
Questions like these reflect the natural desire that business analysts have to better understand their role and focus on the development of the skills that will not only support their career goals, but also generate the most value for their organization.
Obviously, there isn’t a one-size-fits-all answer, but one thing that may be helpful for BAs pondering these questions is to remember that the most value a business analyst working in the IT solution space can offer to an organization is to excel in the processes related to the discovery, analysis, negotiation, and validation of the requirements of a new or modified software system. End users, project sponsors, subject matter experts, project managers, etc., all get involved in the process of eliciting requirements, but the business analyst (regardless of the job title he or she has) “owns” the requirements processes, and is responsible for making sure that the requirements adequately and completely represent business and user needs. To be truly effective, a BA must consider the project requirements their primary concern, from the development of a product vision and scope to detailed user and software requirements specifications and the change control processes that will be used to manage requirements during the lifetime of the project.
What about blended roles, then? It’s normally hard for a single person to balance goals like getting the project done on time and budget vs. delivering the right product. In my experience as a consultant, the most successful projects typically have a business analyst and a project manager working together to accomplish project goals. Activities such as planning the work to be done, identifying and securing necessary resources, determining tasks that must be completed, assigning the tasks, delegating authority, tracking progress, etc., are the responsibility of the project manager, while the business analyst remains in charge of producing consistent, complete, feasible, truly needed, accurate, traceable and verifiable requirements.
I see the “expansion of the business analyst role” as a double-edged sword. The consequences can be favorable if the intention is, for example, to involve business analysts in enterprise-level activities related to identifying gaps in organizational capabilities, developing models to describe the desired future state of the organization, or performing other tasks that allow BAs to deepen their knowledge of business goals and contribute to the formulation of business transformation projects. If, however, instead of aiming to get more from their analysts’ skills and capabilities by extending their involvement across the enterprise, the organization is simply trying to cut costs by having the business analyst simultaneously act as project manager, tech lead, or QA tester, there’s a substantial risk that the change will result in loss of value and quality of the output provided by the analyst, which in turn may result in extensive and expensive rework, or contribute to the already high statistics of IT project failure.
While discussing the BA role in their organizations, business analysts must be ready to fight unwarranted assumptions, needless compromises, and wild guesses about the responsibilities they have and the contributions they make as part of a solution team. An experienced business analyst is typically busy throughout a software development project, bridging the gap between the business and the technology teams, determining changes in processes and operations that need to take place as a consequence of the new system, investigating and advising on the project’s impact on other systems and initiatives across the enterprise, and so on. While BAs working for smaller organizations (or dedicated to smaller projects) may be able to successfully wear multiple hats, the acceptance of additional responsibilities, particularly when in conflict with business analysis core responsibilities, can have devastating consequences for both the organization and the analysts–a few of whom may even find themselves victims of the infamous Peter Principle.
To borrow the words of Laura Brandenburg,
I do think we need to balance our desire to help with an understanding of what it takes (in terms of time, effort, and focus) to be the best at what our core responsibilities are. It can be tricky… but sometimes it is better to “just say no”.
Pingback: BA and UX specialist: A winning combination for superior results in software projects | MarkjOwen's Blog
Hi,
Please help me with the explanation to the below Qustions.
What is the role of BA in an Agile methodolody development Environment?
What will the next generation of BA’s look like
Ack, the comments system deleted my quotations from what you said. Here they are:
First,
“I didn’t mean that the business analyst moving into the deep carpet offices would still be doing investigating, analysis, documentation, and solution confirmation herself. I am suggesting that possession of these skills and the knowledge of their use will enhance any executive’s performance”
Second,
“Business analysts do not need authority. Those that find out they really want a position in which they are responsible for decisions that affect the lives of hundreds of people and financial institutions and the organization as a whole can gravitate toward the CxO positions.”
Steve,
<>
Oh, we definitely agree on that. I think the skills you listed are extremely valuable and can’t hurt someone in a C-level position.
<>
Well put, and again I agree.
I’m glad we were able to clarify our positions–clearly we all share the same opinions here.
I didn’t mean that the business analyst moving into the deep carpet offices would still be doing investigating, analysis, documentation, and solution confirmation herself. I am suggesting that possession of these skills and the knowledge of their use will enhance any executive’s performance even when the actual execution of the activities is done by someone else, typically as you suggest, a business analyst. I have a chapter in my book on the BA as decision support analyst in the organization. The real neat aspect of this is the respect business analysts will get in an organization helmed by a former business analyst. Currently it seems like the sales organizations get all the respect, and it is clear why that is the case, as Nathan pointed out several posts ago.
I see the difference between those who opt for the three-martini lunches and the golf course meetings and those who continue to provide the information and analysis to those who opt for the three-martini… as being mostly one of authority and responsibility. Business analysts in general do not have authority except, in cases of business analyst teams, over other business analysts. The project manager has the authority over the execution of the project; the business management has authority over what is being done for the business and its eventual implementation; upper level management has authority over everything else. Lack of authority for business analysts is not a complaint or a problem. It is good. The business analyst can use influence and information, conclusions and collaboration to get what she wants. Business analysts do not need authority. Those that find out they really want a position in which they are responsible for decisions that affect the lives of hundreds of people and financial institutions and the organization as a whole can gravitate toward the CxO positions. Of course, that business analyst would generally have to move to a mid-to-high level position to prove her ability to delegate, lead, and make those tough decisions. Those that get the kick from champagne, er, rather, solving business problems and letting someone else make the decisions (and take the glory if that’s part of the equation) will retire as business analysts emeritus, comfortable with their contributions.
Does that make sense?
Nathan, we seem to have a similar view in this subject. (Also in the matter of an “Edit” option available for a limited amount of time to allow us to fix typos and other mistakes, which would be great. I’ll see with Laura if there’s an easy way to providing that here. ;-).
Drucker (Inc. 1985) also contends that entrepreneurial work and managerial work are not the same, and I think that Steve will agree that that analytical work and entreprenerial or management work are of different natures as well. That is why I mentioned in my article The Peter Principle – I can see it being applicable to the case of business analysts the same way as in the example given in Wikipedia to describe the principle that “In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence.”:
“For example, a factory worker’s excellence in his job can earn him promotion to manager, at which point the skills that earned him his promotion no longer apply to his job.”
I have no doubt that being promoted from “adviser to CIOs” to CIO (or any managerial position, for that matter), would definitely cause me to become a victim of the Peter Principle…
I see that I missed a great discussion here in my recent absence. Although I have not been a “CxO” I have been in middle-management. Some of my BA attributes benefited me strongly, others I had to leave behind as I practiced managing, motivating, and other middle-manager type responsibilities. I will just add, you can tell a CxO who has a BA mindset (favoring informed, analysis-supported decision making) vs. one who has a sales-mindset. I would find it interesting to understand the balance between the two types of leaders and the success of their respective organizations.
I will look into the edit feature. I have the ability on the back-end to edit and will take care of the few typos mentioned.
Laura
see Adriana said about the same thing a few minutes earlier, with focus on refining the details as opposed to the systemic view. Yup … both are essential.
Also, second to last paragraph in my comment may make more sense by adding a ‘not’, as in “may *not* be a good candidate”.
The linkedin ‘edit’ function is a pretty nice feature.
I’d agree with Adriana that CxO and BA roles draw from different populations. It may be helpful to distinguish entrepreneurs from professional managers since in my experience the former are ‘born’, organizing strings of lemonade stands by age 5. They start to be pushed down (or out) of firms around the $20M scale where the CxO operational activity becomes effectively allocating resources rather than great product/market ideas (see Mintzberg).
Since allocating an abstract resource, money, is the the essence of finance, there is a certain natural progression to managing the allocation of people, capital equipment, and real estate as well.
The requirements engineer vision of the BA, that refines and details what the stake holder set says, is a rather different perspective and therefore a much less likely transition. At the most basic level there is a difference between capture-refine and create-solution.
That said, there is a common systemic view that would be extremely helpful to the executive allocation operation where resource allocations, i.e. investments, aren’t independent. This is the same skill that adds value to the BA role in going beyond requirements gathering to process and operational integration, coordination, and internal improvement. Here the entities are different, but the conceptual perspective the same.
It is my experience that while ‘the BA’ may not be a good candidate to turn into a CxO, there is a really good reason to have an ‘extended BA’ on staff.
Oh, and they should be paid more than the CxO. That would be the great part. 🙂
Steve,
I am currently writing a book chapter (for a bigger project with other authors involved) that reflects exactly what you said about BAs “viewing the larger issues rather than focusing on a point solution”, and feel the need to clarify something.
When you say “I understand that many business analysts might prefer not to be involved at a higher level and tackle larger problems and issues, preferring rather to stay at the “local” level and solve problems for which there is a more immediate payback”, that’s now what I meant by drawing a line between BA work and top management work.
A lot of more experienced BAs (and I’m lucky to be in this group) do get involved in larger issues, helping, for example, establish focus areas and decompose strategic goals into more descriptive, granular and specific objectives at the enterprise level.
The difference here is between being an analyst (albeit at a higher, strategic level) and being an executive — a person performing the duties involved in running an organization. I talk to CEOs and CIOs all the time, and they are unanimous in saying that they rely on analysts to get them the reports and advice they need to be able to make their decisions. If a business analyst wants to become a C-level executive, that’s fine, but it would be unrealistic to expect that he/she would still be able to perform tasks such as “investigating a problem thoroughly to determine the real problem and conditions causing the problem before determining solutions” as you described in the list of BA abilities.
So, clearly someone with an analytical profile could also have the right profile to direct and control an organization, but I think it’s important to keep in mind the differences between the two roles, and how shifting from one to another definitely changes the nature of one’s activities on the job.
Consider the abilities of the experienced business analyst:
– viewing the larger issues rather than focusing on a point solution
– identifying and considering alternate solutions before deciding on the best course of action
– investigating a problem thoroughly to determine the real problem and conditions causing the problem before determining solutions
– analyzing the available information completely to ensure the best solution to the problem
– communicating and collaborating with all parties to the problem and solution to arrive at the best solution for everyone involved
– testing and confirming the solution when ready for implementation to ensure it solves the original problem
– assisting the business to transition into the new solution
– evaluating the business processes to discover more areas of improvement.
I have the feeling that were more of our CxOs in organizations, especially in financial and banking, not to mention manufacturing, possessed of these abilities, a lot of the issues we are facing today might have been avoided.
I understand that many business analysts might prefer not to be involved at a higher level and tackle larger problems and issues, preferring rather to stay at the “local” level and solve problems for which there is a more immediate payback. I sincerely hope that some will take on the challenge and take over senior management positions with the same alacrity and insight that they solved problems for the business.
Steve wrote: “I’ve often said, somewhat whimsically and with a deal of serious prognostication, that the next generation of business leaders, CEOs and the like, will come from the ranks of business analysts.”
Steve, I’d say that one reason this isn’t happening more frequently is that not all BAs (like some people I know, including myself) want to jump into an executive career.
As soon as someone takes a C-level position, his/her ability to focus on specific business needs and develop solutions drops drastically (this is what I hear from all executives I know – it’s impossible to devote enough time to gain in-depth knowledge about specific business needs, and have the satisfaction of envisioning really smart systems to fulfill those needs, when you are in a top-level position).
The type of problem you need to focus on as a CXO is of a very different nature, and not all of us BAs are interested in making that jump (or have the right skills, for that matter). Having said that, I do hope that more and more BAs with the talent to set the direction and oversee the operations of an organization, and the ambition to lead a business, get the chance to do so. That, like Nathan says, would be great.
Steve — Wow! That would be Great! My guess is it will be the BA’s focused on sales and finance though. 🙂
I’ve often said, somewhat whimsically and with a deal of serious prognostication, that the next generation of business leaders, CEOs and the like, will come from the ranks of business analysts. After all who in the company has a wider view of business processes as well as an understanding of the IT systems that drive those processes? That takes the business analyst role to the extreme of expansion.
Pingback: 2wtx Mastering Business Analysis » Arquivo » Expanding the business analyst role–good or bad?
Thank you, David and Nathan, for your thoughtful comments! I hope you stick around as more comments arrive, to continue to provide your valuable insights.
Pingback: Tweets that mention Business Analyst Role: What responsibilities should we take -- Topsy.com
Great post. The good news is that the notion of BA as a profession has reached a point where this is an important question. The bad that it isn’t and perhaps can’t be answered yet.
I think there may be two thoughts here: how do *I* succeed as a BA and how does BA as a profession succeed.
Individual Success___
Individual success is pretty well tied to doing the job you are being paid for. “[C]onsider[ing] the project requirements their primary concern” is darn good advice. It allows for individual success with some degree of isolation from business result of the project.
The difficulty of balancing different goals or shifting between conceptual frameworks is also very real and a good reason to “just say no”. The caveat I would add is that given a goal, say ‘excellent requirements’, involvement over multiple phases can be very helpful in building context. RUP does a good job of encouraging this in a productive way. Similarly, for smaller projects one person who sequentially occupies roles, say from BA to PM when the development scales out then back to tester for acceptance may be appropriate.
From this perspective, the ‘blended role’ is a characteristic of the job, not one of it’s included roles. A focused BA or broad role capability strategy probably depends on consultant vs full time job, and if full time on the organizational scale.
Profession Success____
To establish a profession i think there needs to be a clear value proposition, and some associated individual accountability, at the larger business level. This differentiates the professional from the technician who writes a SQL update that exactly matches the spec, but breaks the system.
One such value proposition is a dramatic increase in project success.
The key challenge is that the BA role doesn’t produce an end product. It is a coordinating role providing a liaison to bridge between business and IT. What is required of the role depends on existing capabilities at the end points. And both recognition and substance of those capabilities will evolve over time. The BA profession is obviously positioned to be a key driver of those capabilities. But it exercises a strongly systemic influence that will simultaneously evolve the BA role.
My observation is that emphasizing more rigor in modeling, system thinking, and operational clarity on the business side, starting the chain from a solid base, has the most impact. Extending the profession to provide better input directly impacts the project success value proposition.
Another direction is to include requirements for resources other than IT. I don’t think I’ve ever worked a project where the outcome didn’t depend on organizational structural or conceptual change as well. Integrating liaison with org change or outsourcing or facility specialists on equal footing with IT architects would promote the overall value proposition.
Note that like all other professions, there may be sub-specialties which may or may not be appropriate for specific projects. But each benefits from the structure and value proposition of the whole profession.
As a final note, the whole profession and specific roles may evolve over time. Actually impacting the project success rate would likely kick off a cycle of incremental improvement that found a new set of optimum specialties and job roles.
Well said… Expanding the role “upwards” into an enterprise role is the best idea, and I have done it to a certain extent over the years. This does lead to yet another “role” or discipline, that of the Enterprise Architect. I have found that EA has the hardest time trying to explain itself to others, so perhaps we BAs can help with that…