Print
Close

To BA or Not to BA: What’s a PM to Do?

November 1, 2016

It is encouraging to see a formal recognition of two vital professions today—project management and business analysis. It seems like every project management job has some degree of “other duties as assigned,” and outside of coordinating war rooms and ordering pizza during crunch time, many of these duties fall into the realm of business analysis.

And why not the project manager? Who is more skilled at eliciting, progressively elaborating, baselining understanding, communicating and documenting than a project manager? The most well-tooled PMs I’ve encountered have experience as business analysts, whether previously titled or not. Outside of developing a deep understanding of the project domain, PMs by default take on writing requirements, building forms for user input, capturing and documenting workflow, and drafting system diagrams where none exist.

Why do we PMs so willingly take on this work? Consider these dynamics in the business analysis arena:

• Role gaps: The BA role may or may not be explicit in the organization. Without a titled BA on the project team, someone will have to elicit knowledge from the subject matter experts and transform this into requirements. We think that just by bringing the SMEs and the technical experts together at the table, the deep mutual understanding necessary to build the result will magically happen. As the project progresses, the sponsor or an outsider senses we are getting into trouble without written requirements, and “poof,” the PM is accordingly tasked. It is difficult to see a BA role gap and justify filling it. If you are missing a DBA on the project, it is very clear to everyone. It is a harder sell to request a BA to remedy a “softer” gap such as mutual understanding not happening.
• Internal shortage of BAs: Every BA that I’ve encountered is on multiple projects and is pulled in a plethora of competing directions. The BA role requires deep, intense focus on the subject matter, and when a BA juggles multiple subject matters, how can they give focus to your project with the sliver of allocation granted to you?
• They come and go: There is a healthy industry of contract BAs today. The typical scenario is an organization embarks on a 12-18 month project starting with heavy requirements gathering from the SMEs. The organization contracts with BAs to come in and perform their trade, and as a result they gain deep subject matter expertise and also fill that organization gap of understanding all points of integration between disparate functions and systems. This latter duty makes them the project manager’s best friend on the project. When requirements are done, they’ll stick around for testing and other smaller projects. Yet when the large project is done, the BAs leave, taking their heads with them! All that intellectual capital so needed for future projects walks right out the door. Organizations need to carefully consider their BA staffing strategies, with the long term in mind.

Hopefully you can see the inertia toward the project manager doing business analysis work on his/her project. Some of us have had project management gigs where we are explicitly told we will do business analysis work, and time was carved out for us to do this.

I’ve had that experience, and honestly found it enjoyable. In one such role, I had to gather, analyze and document requirements for a large-scale science search engine, in addition to managing the usual development lifecycle for the same scope. Playing the PM and BA at the same time brought my project the following advantages:

• All of the ills expressed above disappeared. I didn’t have to chase down my BA, because I was the BA!
• I could jump in and help when we were short. For example, because I knew the requirements I could help out with testing.
• I was more effective in describing my project scope. If there were requirement clarifications needed or scope changes, I could describe them with ease, right there in my status meetings. This also helped when managing future projects with similar scope.
• I felt more ownership of the end-product. To me, the importance of delivering “to spec” and with quality was equal to or exceeded the need to deliver on time and on budget.
• I was more change control-friendly. As above, I could advocate the merits of the change and justify why we needed to alter our well-vetted, baselined plan to accommodate the change.

That last point turns the conversation to the downside of playing both roles. Who is responsible for all the work in creating and vetting a baselined plan? You can’t help but see why there’s a sense of schizophrenia when the PM does BA work. If you are put into this situation, beware the following:

• Inherent conflict of interest: The BA is motivated to deliver the highest value-add functionality and quality, whereas the PM is motivated by delivering on time, on budget and to a baselined specification. If there’s ever a scope versus schedule tradeoff, can the PM and BA be unbiased if they are the same person? It has been said that the BA always has one more question to ask, whereas the PM seeks to avoid “analysis paralysis” by reminding everyone that the time for asking questions has passed.
• Conflicting division of duties: By playing the BA role, the project manager diverts time and attention away from core PM duties. It is easier to forecast PM effort on a project instead of BA effort because of the many variables entailed in requirement work (e.g., availability of end users, time it takes to flesh out the details, finding all the SMEs, etc.). Moreover, some PMs feel a false need to have a SME’s understanding of their project scope. A project’s subject matter indeed can be very enticing to the PM, seducing the PM away from the core blocking and tackling of project management.
• Improper management of corporate knowledge: While the project is in progress, it will benefit from the deep subject matter expertise that the PM has acquired. Yet projects end, and PMs move on to bigger and better things, leaving others behind to use their expertise to run operations. Like the contract BA who walks out the door, the organization may find it difficult to let the PM leave the domain, given the vast knowledge acquired. Unless “recipient heads” are left behind to house the knowledge needed to run operations, the PM playing the BA role will find it difficult to transition off the project.
• Downplaying of accountability: Some PMs have done the jobs of the resources on their projects. Yet they’ve learned that to be fully accountable for the success of their projects, they have to push that accountability down to their team members. Team members are held accountable for using their expertise to deliver, meet deadlines and meet the goals of the project. By playing the role of the BA, the PM will face a strong urge to “jump in and do” versus hold someone else accountable for doing, especially given the broad nature of the BA role. As PMs, we have the responsibility to stay at arm’s length with our team members, entrusting them to handle the minutia of their jobs. We are simply to hold them accountable, and playing the BA role works against this basic responsibility.

So what is the answer to the question “To BA or not to BA?” as the project manager? It really depends upon the organization, but by following some simple tips you’ll know what level of business analysis you’ll need to account for in your next project.

• First, determine all roles up-front. Take inventory of the roles of the entire team and what the expectations are of the project manager. Consider building a RACI not just for the deliverables and tasks of the project, but who has what knowledge and is therefore best positioned to leverage their knowledge in completing the tasks of the project.
• Secondly, take inventory of all artifacts the project will produce, and confirm who is best qualified to produce these artifacts based on their knowledge. As a project manager, you will assign accountability to each author in producing the artifact, but don’t let your responsibility stop there. You as the project manager have a duty to inspect and “sanity check” each artifact, if anything as a third-party objective reviewer if you aren’t familiar with the subject matter. The author will appreciate a second set of eyes on the artifact.
• Finally, be firm on establishing and holding people accountable for what they know. Gone are the days of the “know-it-all”; to achieve project success, you have to rely on the application of knowledge that resides in multiple heads. Your core responsibility is to understand your project’s scope, and that can be a head-full right there. In simpler terms, know enough to be dangerous, and hold others accountable for their knowledge and the application of that knowledge to your unique project situation. In this fashion, business analysis can be part of your role, but you can keep it manageable to ensure you stay true to your core project management duties.