By Adriana Beal – Apr 2015
In his recent article called Why are we still talking about PM vs. BA?, Kupe Kupersmith wrote:
Does a CIO or the business leaders you work with care that independently you have a good BAs or good PMs? No way. They want teams to deliver outcomes that help move the business in the direction they want. You need to consider yourself a team member first. This means you will do what is necessary for team success. Second, think about how you can best help the team succeed. What skills do you bring to the table? Don’t think in terms of I am a Business Analyst and I have a job description listing 15 tasks so that’s what I can bring to the team. Work hard and work unselfishly.
To me, this paragraph is conflating two different things that should be treated separately.
Fact #1: Business leaders and CIOs don’t care about how tasks are allocated among team members, as long as projects achieve the desired outcomes.
In that aspect I’m in total agreement with Kupe. As long as the desired results are achieved, no sane manager is going to care about team configuration and distribution of responsibilities. I’ve worked in highly successful projects whose teams had wildly different team configurations, and am in favor of adaptability and doing what works best for each team.
On the other hand, it shouldn’t follow from this fact that people should just gladly accept any assignments that align with their capabilities, regardless of their interests or what they originally signed up for when they took the job.
Fact #2: Just because a person is capable of performing a task, it doesn’t mean it’s a good idea to make him or her responsible for it.
There are two problems with thinking in terms of capabilities rather than roles when deciding who does what in a project:
First, many organizations don’t understand the contributions business analysts are supposed to bring to the table, and thus expect their analysts to be available to perform a variety of technical and non-technical tasks throughout their projects based on their skill set, often in detriment of the quality of their core deliverables. I’ve lost count of how many BAs came to me to ask for advice on how to prevent the project failure they just experienced from happening again. Invariably, when those BAs describe their failed project, it becomes clear that the analyst was being spread too thin, with insufficient time to dedicate to understanding the business need before being asked to “jump into solution mode” and help with all sorts of project tasks, from identifying data sources to coordinating cross-functional metings.
I firmly believe that a clear, BABOK-like job description for the business analyst role helps avoid this type of problem. Now, there’s nothing wrong with expecting people to pitch in as needed. However, in the absence of a well-defined job description, organizations tend to develop unrealistic expectations of how much time will be required for the business analysis activities to be completed, and fail to allocate additional resources to other project tasks, making the assumption that the BA will have plenty of time to take care of those tasks. Inexperienced BAs often find it difficult to express why they need more time to finish the analysis for their project when a manager insists “the requirements have already been provided by the stakeholders, and you should be free now to help with project execution”. Having a solid job description reduces the need for BAs to constantly having to educate business and technical stakeholders regarding their responsibilities, and defend the amount of time required to perform critical tasks such as understanding business problems, scoping the needs of users, identifying dependencies between requirements, and so forth.
Second, besides the need to consider the impact that additional tasks can have in the quality of a BA’s core deliverables, it’s important to check whether the person would be happy tackling the work. The best BAs I know enjoy the activities related to figuring out “the right thing to build” but are not interested in doing project management, data analysis, coding, quality assurance, and so forth — even when they are the most qualified person on the team in those areas. And this is something that smart organizations know about talent retention: there has to be a balance between organizational mission and self-interest.
At the beginning of my career, I worked for a solution provider as a BA consultant. My job was to go to a client organization and perform business analysis for one or more projects, clarifying business goals and project objectives, identifying business stakeholders, modeling business processes, defining and getting sign off for solution requirements. Nobody expected me to be responsible for project management or QA activities, which kept me happy and focused on delivering value on what I did best. Because there was a clear delineation of what my job was and wasn’t, the team was structured in a way that didn’t have to rely on me doing non-BA activities I was qualified for, such as reporting on development progress or performing quality assurance testing.
Granted, it’s much easier to delineate the type of work you’re going to do for your team in a project-based consulting arrangement. But that’s precisely why job titles and descriptions are important to communicate expectations. In the past, when I was applying to a full time BA job, knowing whether QA or project management was part of the role helped me self-select out of a job, saving future headaches for the hiring manager and myself. Based on skill set alone, I’m perfectly capable of being a project manager, or a QA professional. If I weren’t upfront about disliking the types of tasks associated with these roles, I’d have found myself in situations in which the natural arrangement would be for me to take on those kinds of responsibilities as the project evolved, because it would have been easier than recruiting additional team members. Either the team would resent the fact that I refused to take care of these tasks, or I’d resent accepting it, and would start looking for a transition out. By clarifying role expectations early on, and being honest about the type of contribution I’m capable of and willing to provide for my teams, I’ve helped managers understand resource availability and create structures and accountability systems that allowed me to remain 100% busy with value-adding activities without being required to perform tasks that didn’t align with my career goals.
I disagree with the statement “to assume someone with a title of Project Manager does certain tasks and a person with the Business Analyst title does other tasks is just crazy”. Clearly, I’m not saying employers should treat employees as “rats in a box”, or employees should refuse to help out because a task is not in their job description. But in my experience, self-organization works best when you respect the boundaries of what people are signing up to do for their employer. Otherwise, a talented BA who also is good at data modeling could get “stuck” with doing data mapping work she’s not happy with just because it’s the easiest way for the team to fill the capability gap.
I’m all for going the extra mile for the good of the team, department, or company. But star BAs have enough career capital to be able to successfully control their careers. It’s one thing to expect them to take initiative and move out of their protective job descriptions to cover “white spaces” and reach goals that benefits everyone. It’s another thing to expect them to overcommit, or “work hard and unselfishly” on something they dislike doing just because it’s more convenient for the organization than to find and assign the appropriate team members.
Choosing jobs with descriptions that didn’t include activities I dislike doing on a regular basis didn’t mean I wouldn’t volunteer to do some of these tasks when the situation required. It meant, though, that my employer and I had similar expectations about what type of contribution I was signing up for, and that nobody would be disappointed if I didn’t volunteer to help with testing or progress tracking when I was busy designing business models or managing system requirements for my projects.
What about you? Do you agree with the importance of job descriptions, or are in the camp of ignoring job titles to focus on the skills each team member brings to the table?