As a current job hunter for business analysis positions, I am a bit surprised by how many blended roles there are available. I can hardly find a job that does not also want me to be a programmer, or a project manager, do a bit of SQL for some data analysis, or end-to-end testing. This seems to be a bit more prevalent than in previous searches. I have attributed it mainly to the flailing economy and IT managers looking to economize on technology investments by filling multiple hats with one person.
This leads me to the question, are organizations willingly sacrificing the quality of deep expertise in order to fill multiple hats with one head count? What are the risks to this? A few weeks ago, a guest author Adriana Beal, made some salient points on this topic in her post on managing business analysts for success.
In many organizations the business analyst role is assigned to an individual playing another role, such as project manager or tech lead. … a dual role will bring unnecessary challenges to the project, often generating conflicting responsibilities and uneven results due to the distinct skill sets required by the differing roles. IT managers should pay close attention to the situations in which business analysis work is assigned to an individual with other responsibilities in a project, taking into account the reality that combining roles is likely to result in loss of quality.
Small teams or small companies can clearly make a case for multiple hats where the projects tend to be smaller and potentially less complex. But some of these companies advertising combined roles employ hundreds if not thousands of people indicating the manager is actively choosing to combine the BA role with other roles when specialization is an option.
Back when I was a full-time manager in a technology team, I had this same choice. I was responsible for requirements, project management, quality, and information architecture across multiple business units. In the beginning, my team was 3 people: One QA, one PM, and one BA. As the team grew, we selectively blended a few roles around the talents of specific individuals or individual career paths, an option I discuss for transitioning into a business analyst role in my eBook How to Start a Business Analyst Career. But by-and-large, we brought people into the organization who excelled at their specific role.
Not that I really considered blended roles, but if I had it would have created some not-so-positive impacts from the perspective I had as an IT manager:
Lack of balance.
By blending multiple roles into one person you sacrifice the balancing forces within a project team. Think scope vs. schedule. Requirements vs. tests. Requirements vs. implementation. The team can balance these potential conflicts better than a single individual responsible for it all or multiple pieces. As a manager balancing forces within the team helps you stay more hands off of individual projects. Less worries about single points of failure, hidden agendas, and rabbit holes.
Lack of expertise.
Blended roles require a broad skill set instead of expertise. By separating the roles early, I was able to bring in top notch individual contributors with deep experience in a particular role. They hit the ground running and brought focus and quality to their particular function on the team.
Lack of scalability.
As our technology organization grew and the pressures mounted we were challenged get projects done faster with say, 2-3 QA engineers on a project instead of only 1. If we had not already separated out these roles, we would have been looking to scale 1 position into 5 or 6. Over the course of 2 years we grew from 3 to 15 members strong, the benefits of specialization were apparent in the ability to scale the organization.
What do you think?
Adriana and I would be interested in hearing your experiences with blends on the IT team, either as a hiring manager or as an individual contributor. My suspicion is that some individuals among us are uniquely suited to blended roles and multiple hats while others would see their quality of work fade quickly as a result of multiple hats. I also sense that there has got to be another justification besides head count at work here. Efficiency? Reduced overhead? Consistent resource allocation? Opportunity to have deeper project knowledge?
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 19 comments… read them below or add one }
The mixing of BA/PM/Test duties is something that I am dealing with right now. It’s definitely an after effect of the economic downturn, but I don’t think that this is the only reason for the phenomena.
Several years ago, when I started as a technical writer/help developer, there came a time when those roles were rolled up into the business analyst role. Little did we know then that HR and Tech Mgmt would know as little about what a BA is/does as they do now. So, I think this may be the other part of what is occurring. The ignorance of the responsibilities of the position make it a natural target for consolidation of duties. This can occur either by natural happenstance, since the BA is typically EVERYWHERE, or by more direct decision making.
To your request for feedback on whether this is a smart idea, I’d have to say NO. When one looks at the role of the BA and PM alone, there are multiple levels of granularity and task responsibility. I know there are many companies that combine these roles, but I have to wonder at the value and quality of the output from either when the same person is tasked with doing both. That’s just a work productivity issue. What about the intangible effects of not having what you referred to as a separation of duties? This is an important aspect of having the two separate roles, where each ensures the other is performing appropriately and coordinating actions with different project team stakeholders and participants.
Add to this mix the role of tester, then where are the checks and balances that need to be in place in order to deliver a high-quality deliverable?
I don’t imagine that our arguments will change anyone’s minds in the interim, but I do think that down the road when the powers that be begin to wonder what the heck happened with requirements engineering and management, there will be a turn-around.
meanwhile, I’m doing whatever I can to argue against going down this road here at home.
DougGtheBA
Hi, …if you can identify that there are separate roles to begin with, it means it is likely that one role can fully occupy one person. So, asking someone to take on two (or more!) roles is going to be unique to each person.
Of course, many companies do include responsibilities of other roles in their BA job descriptions, the most common one being QA/testing. I may be an extreme case, but I have worked on projects as a BA for over 25 years and have never dome any testing; the most common reason is that the companies I worked for all had separate QA roles/teams. I am a strong believer that testing skills are quite different than BA/requirements skills. Still, I wonder if I should have done some over the years.
The other favourite add-on is the PM role. BAs often know a lot about PM because we are involved in projects up-front and do planning and such. However, once underway, combining the two roles will result in a person’s brain exploding as one half tries to get the project done on time and budget and the other tries to get the project to deliver the right thing. That conflict inherent in all projects should be worked out by two separate people working together.
As for programming skills, that’s just bad job definition, HR gone wild.
Other roles that get buried in a BA job title: someone doing BI and reporting. I think this is actually the most meaningful use of the title, and I don’t know what else to call this.
Also, someone with specific software experience: Oracle financials or SAP modules. That job is usually about configuring s/w to meet requirements defined by real BAs. I call these people Application Analysts, and is probably a good career niche if you pick up that kind of experience.
I’ve seen this come up a lot at places with a waterfall or pseudo-waterfall approach. It’s because the PMs want to keep the BA around to deal with issues, but once the “analysis phase” is over there’s not much for the BA to do. Having them take on other roles keeps the person occupied and justifies having them stay on the project.
Laura – excellent points, as always.
DougGtheBA, when you say:
“The ignorance of the responsibilities of the position make it a natural target for consolidation of duties”,
I have found this is frequently the case. I’ve seen hiring managers in IT departments of Fortune 100 companies display a very limited understanding of what is the business analyst role. If a manager doesn’t understand the complexity and extent of the work a BA does, it’s much more likely that s/he will feel justified in combining the role with another one.
Kevin, I don’t see any problem with a BA taking on other roles as the amount of business analysis work on a project dwindles. The issue happens when the BA is required to also manage the project from start to end, or to divide the time between QA/UAT for a project and business analysis for another. Under these circumstances, unless the project is really small, the analyst faces a high risk of producing defective requirements, which in turn may result in extensive and expensive rework that could be easily avoided by having separate roles.
Kevin: Yes you’d be right about the multiple roles occurring much on waterfall type projects. the motivation might be to keep the BA around and billable, but the real danger comes with resource management and capacity planning. Once the BA assumes the other role, that person is no longer capable of rolling off the project to focus on primary analyst responsibilities for another project…not until the original project ends. Of course, this is on top of all the problems discussed above.
David Wright’s comment above regarding the separation of skills is also important. I rely on a tester’s skills to keep me straight and my deliverables sharp. I simply don’t have or want the skills to look at everything backwards and sideways like a tester does. Same for a PM. Their interaction is too high-level and cost oriented to jive with the way I view a project.
I think this post reflects a larger discussion on the nature of the Business Analysis: Is it a profession that provides an independent business level value proposition or is it a craft/specialized skill set required within the IT function? Is it either or both?
The net of the discussion below is that I think the BA role is in transition, both internally and externally, and that driving toward professionalization is essential. Internally, the work of the IIBA is crucial to driving visibility of the skill set and regularization of the terms. This is necessary but not sufficient for professionalization. Externally, the role of IT development is shifting (perhaps shifted) from internal development to implementation of commercial packages. Although it seems crucial, exactly how the BA fits into this is not well articulated, imho.
The distinction I’m making is between ’skill set’ and ‘value proposition’ descriptions of a role. In BA language, this amounts to focusing either on the solution space or the problem space.
Focus on skill set is appropriate when the skill supports particular activities that must be combined in a larger process to deliver recognizable value .
Employees that specialize as one cog have difficulty in alternate machines that use a slightly different cog. Employers are encouraged to look for ways to optimize skill capacity requirements against employee skill sets. Only occasional SQL capacity needed? Perhaps it doesn’t need a world class guru.
Focus on value proposition is appropriate when the role is responsible for business recognizable value. Interfaces are specified, but internal details of how the value is created, the skill set, is less important. More importantly, situational specialization involving significantly different skill sets within a profession becomes possible. E.g., lawyers may specialize in property or criminal law yet still be in the same profession. In the value delivery model, the employee needs a broad, adaptable, and flexible skill set to cope with local variations in both the required value proposition and interface requirements.
In the article example, it is the manager who holds the value delivery responsibility, so defines the type and interaction of the cogs like the BA. Factory like separation of skills is one approach. An alternative I’ve generally taken is to look for people with broader skills, assign responsibility for work that require some subset, and expect them to collaborate and support each other in accomplishing the project goals, without locally optimizing for the visibility of their particular skills. Personal style, inherited style, or project scale influence the choice. But it is a choice. but the BA is a cog in the former.
If there are economic effects (some empirical data would be great) optimization by skill instead of skill set is plausible. However, I think a larger trend that produces the same blending effect is fewer and fewer large development projects compared to large COTS customization and deployment projects. The consequence of this shift is that IT is that responsibility for the application value proposition has moved outside the business. The crucial responsibility that remains is ensuring that the outside technology is both strategically and tactically responsive to the business need.
One professional role available to the BA is becoming the interface layer encapsulating and interfacing the business to the technology. In this case, for small projects the BA may be the PM, the script writer, or the ad-hoc report creator (i.e. SQL writer). For larger projects they may be the business manager hiring application specific PM’s and labor from third party providers. Mostly the same skills, but with lots of blending based on the business value proposition.
Another professional role is the ‘product manager’, on the application provider side. The challenge here is to identify ‘market’ requirements and their trends. Again, a blending or enhancement of BA and other skills based on business value proposition.
To summarize, I think the mixed skill jobs out there may have more to do with the need to identify and sell the implied BA business value proposition rather than a restricted skill set. Communally embracing the blends in language that emphasized the professional value may be of long term benefit.
(sorry for the long comment … honest, it’s been brutally edited. Hopefully past the point of unreadable and not to the point of inchoherence:)
Oh, and to answer the original question:
Blended roles are just fine — if they make local sense.
My focus has always been on the business value proposition in both leadership and individual contributor positions. The objective is to ‘make it work’, applying, learning, or finding whatever skills that takes.
Something like “coordinate and align information and communication technologies with business need and enhance business value.”
As a manager, I have forced people into skill based roles they, umm, might not have chosen. But they made major contribution to team success, learned they were capable of a lot more then they thought they were, learned more by observation and interaction about their preferred skill then they would have by doing, and thanked me — later.
I’ve also managed and worked with people who announced day 1 what their ‘job’, i.e. comfortable skills, were. Great people if you had the exact slot. If not they became bored, dissatisfied with the lack of interaction/recognition and wandered off.
People to Skills/Roles/Jobs… it is really a sorting mechanism, useful if it helps, a hindrance to people it does not help. I always wish I had more skills at any one time than I do, but I also really wish I could play the piano. I also now have different skills today than I did 10 to 20 years ago, as the need for some declined and new ones to learn were made available…still can’t play the piano, though.
David (and all), when discussing how to distribute roles in a project, I think that it is important not to focus only on skill set, at the expense of examining how much a single person can tackle, and in which areas, to avoid conflicting duties and uneven results.
I often say that I’ve met skilled developers and project managers that could also perform very well as business analysts, but rarely saw a situation in which a dual role had a positive impact on the project.
I think Laura did a great job in separating the issues of balance, scalability and expertise. Whether the person has the skills to perform a role is just one of the aspects to be considered when deciding whether to blend roles.
I do believe to be important for a BA to at least have some knowledge on different areas, as development or testing. In my short experience as BA, this knowledge made it easier to act as a business representative among IT, especially when the analysis phase has passed and the project is moving forward.
I’ve seen some BAs being carried way by developer’s explanations on why something couldn’t be done, when it could. It was just a matter of approaching the problem from a different angle.
So, instead of wearing different hats, the BA should wear different eye glasses, so he/she could see the problem from a different perspective, understand the reasons behind some claims, help keeping the communication flowing among the different teams/persons of a project, and ensuring the objectives defined are being met.
In other words, in the course of the project, the BA makes a transition from project’s BA to a project’s facilitator (SME?).
Blending roles might cause some (or all) of the issues Laura pointed out. I can’t see how a BA could do a good job having to worry about budget and time constraints, and making the project moving forward, as a PM must do.
Anytime I saw blended roles, the reason behind was cost constraints.
BA’s perform a variety of roles in a business organization. They need not necessarily be in IT group. In my many years as a requirements analyst, I discovered that the problem really lies in business operations group where their processes are not well defined, there are gaps and overlaps and above all there was no connection to the strategic objectives of the business. This led to continuous revisions of business processes, and subsequently, computer systems. I was able to convince this point of view to superiors and got transferred to the business operations group, where I was able to do a tremendous job in process improvements, define and use business metrics to find areas needing most improvements.
The only skills needed were a little SQL to check raw data, and then a little visio to graphically clarify relationships of various entities (not necessarily, just data entities, but process entities as well) . This part requires a good domain knowledge.
Above all, the BA must be totally organized in their thinking. The implementation of their findings can be easily transferred to data bases, or visio, with a little help from others.
I agree with Klaus Paul’s comments. It’s important for the BA to see the different perspectives of the project team members in order to best assess how to handle the hurdles that come up in the course of the project. Balancing the business side with the tech side is one of the keys to a successful project.
Having come from the user/business world into a BA position within an IS department, I’ve built a better understanding of the hows and whys from a technical perspective, but am by no means an expert on the technical side.
A previous manager shared some good words for a BA to live by: Business Analysis is an art– not a science. The “art skills” of a BA become key to a project when dealing with users and defining the business requirements. Ability to see the problem(s) from the users’ perspective and speak the “tongue” of the business users, assists in giving credibility to the entire BA and technical team. When the users feel you understand their situation and genuinely care, they have more faith in the project development process.
As far as blending roles, there are some individuals that can carry off the mixed responsibilties of both the tech side and the business analysis side. I would say that it is dependent on each person’s skill set and personality (personality does play a role in it!). It is also dependent on the size of the company, the company culture, the type/complexity of the project, and the personality of the involved users.
Sometimes more players involved doesn’t necessarily create a better outcome. It’s important to tailor the team structure to that of the specific project.
If you have a project where the team of business users easily relate to developers in a more technical sense, then you may be able to deliver that particular project with the developer being the lead resource (both from an analysis and tech perspective).
On the other hand, if you have a project team whose eyes glaze over when they know they are talking to a tech-related person, it’s best to pair them up with a BA as a lead resource– or at least a team member who can best relate to them and speak their language.
Some developers don’t build a comfort level in dealing directly with users on a project, but they are excellent in what they do.
In summary, I believe, blending roles in some business cultures can work– especially in some smaller sized businesses where a lot of formal structure seems to be paralyzing.
I wonder if there aren’t two, perhaps more, roles named ‘business analyst’ in circulation.
1. the project based, elicitation role associated with business or IT system analysis and
2. an operational role focused on various levels of report generation and data analysis associated with operational analysis.
As has been suggested above, project management, technical skills, and testing aren’t unreasonable extensions to Type 1 BA, depending on scale, method, and available resources.
The tell for Type 2 BA seems to be “some [advanced] knowledge of SQL and experience with CrystalReports [or ...]“
Good point, Nathan – it is common to see different interpretation of what a BA is.
In my work as a consultant, definition #1 is the prevalent one. And definitely, project management, technical skills and testing are frequently part of the business analyst work. I don’t even see that as “blended roles” because it is naturally part of the activities of a BA, at least in my experience.
But at the same time, in all complex projects I worked, my project management duties were related to identifying the critical path, managing risks to time and schedule, helping the PM structure the work etc., and the testing duties were related to creating test cases and working with the QA team to define the test plan. There were still other members of the project team designated as the official project manage (responsible for administrative stuff such as weekly updating the project plan, scheduling meetings, etc.), and QA team (running regression tests, automating test scripts, etc.).
I wouldn’t be comfortable with one person trying to perform all these tasks in a project, unless it was a very small one.
This is a very interesting discussion that should continue ….with management teams, HR teams and others who do recryuitment of BAs.
There are several valid reasons why a BA gets involved in other roles and they could be meaningful utilization of the resource in many projects as has been commented already.
But this is not always the case.
There is a thorough mis-understandig what a BA role means and I have even seen expectation for the BA playing the Technical Architect role. And most of the times, when someone says BA they actually mean a pure PM!
I think the reason is that the BA role is always more associated with soft skills as compared to a developer who need Java experience or a DBA who is an expert on specic databases.
It is actually frustrating as a BA when expertise with specific tools becomes the most important criteria.
I agree with the second para in Charu’s writing.
Whether higher ups are knowledgeable about different roles such as BA/PM/ QA/TA, or not. the business situation at hand, compels the high level managers to ask BAs to do these roles from time to time, sometimes for a good length of time.
In my more than 15 years of consulting experience in a large corporation, I have performed all these roles. This happened because, at a given time, I had to do either that or quit, or uproot my home and family fron NJ to Utah or Montana, and I had no desire to do that.
I took job to earn a living and enrich my knowledge and experience. So starting from a Fortran/COBOL programmer to being a ‘Guru’ (Pre 1989!) in Unix and communications, to being a long time BA (where I simultaneously did some PM, BI, reporting etc.)
I feel so much eriched with all that knowledge and experience! I wish someone hires me and asks me to do all of that. I am so sure I can handle it all!
As others and I have said before, we are not dogs and therefore contrary to the old dog/new tricks paradigm, the old BA/PM can learn new tricks that much faster!
Anand,
I definitely agree with your thoughts on how taking different roles can help enrich your professional experience. As a consultant my BA role is many times expanded into information architect, user experience specialist, developer of prototypes, product manager, etc., and I both enjoy and learn from the variety of experiences.
On the other hand, the thing I tried to warn IT management against in my article (quoted by Laura) is the danger associated with asking a person to fill multiple roles simultaneously. As skilled an individual might be in different areas, if you look at the number of activities that a business analyst may be required to perform in the course of a project (from planning the business analysis approach to conducting multiple elicitation activities, defining scope, prioritizing requirements, vetting the new requirements that surface during UAT, etc., etc.), unless we are talking about very simple projects with little change in requirements throughout the development cycle, I don’t believe a single person can perform all these tasks well and in parallel manage the project or be responsible for other activities, like programming or testing the solution.
In my opinion, it’s simply too much for a single person to take care of with the level of attention and detail that most IT projects require to succeed, even for an extremely talented professional. “IT managers looking to economize on technology investments by filling multiple hats with one person”, as Laura describes, may be very well be setting themselves up to feed the statistics of IT project failure that we all know are extremely high.
” I don’t believe a single person can perform all these tasks well and in parallel ”
Of course. I agree. Not in parallel. Only sometimes, you have become ’sooo goood’ a worker, everybody wants your participation in their projects. Then it is up to you to manage your time, decide if participating is worthwhile to you from any perspective at all.
What can I say, I just enjoy attention and like to be busy!
Hi Anand,
I do applaud your enthusiasm and I think it’s your kind of attitude that helps individuals advance in their careers. 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”.