The PM-BA Connection

I recently caught myself falling into a bad work habit, and quickly took corrective action to stay out of trouble.  Later I reflected on the impulse that dragged me into this habit, which led me to an introspective look-back on my tenure as a business analyst prior to becoming a project manager.  When we work in a PMO, we are expected to adhere to standards and use the templates provided to demonstrate consistency to our stakeholders.  Yet when these standards and templates are lacking, the well-seasoned project manager will reach into his/her bag of tricks and pull out what worked from prior experience.  If templates are available via the PMO, it’s hard to resist the temptation to use what worked for us in the past, but we see the greater good of consistency that a PMO brings and use the templates.

Yet it’s hard for some of us to accept this, and let’s consider the possibility that our prior BA experience contributes to this hardship.  First of all, standards and commonly-used templates are newer developments in the BA world, whereas PMI standards have been around for decades.  Common BA artifacts like requirement and workflow templates either don’t exist in an organization or exist in such an abstract format that they have to be customized for every project.  The core value-add that a BA brings is not filling in headings in a template, but instead capturing disparate inputs and applying them into a framework that everybody understands, especially the sponsor who has to provide sign-off and the builder who has to create the solution.  The compelling need for this uniformity of understanding outweighs any benefits of standardization.  Hence the BA-turned-PM naturally gravitates towards a communication framework that caters to the uniqueness of the project, despite any deviation from corporate standards.  If there’s a framework that’s readily available from past experience vs. a one-size-fits-all template, which do you think the BA-turned-PM will feel compelled to use?

Moreover, BAs are superior at working independently to get the answers they need.  If the organization is lacking in communication and training protocols and/or lax in sharing common practices, proliferation is a natural tendency in the drive to deliver.  I’m sure many a BA has faced lack of documentation and abundant knowledge residing in an uncomfortably few number of busy heads.  Such BAs learn to “blood-hound” to get the answers needed to document the requirements, much like a trained dog with a keen sense of smell will hunt for evidence.  When the BA becomes a PM and is handed a loosely-defined project – scope not clear, some work started, roles a mystery, dates being tossed about – what is the natural tendency?   Ignore the templates, dig out the answers, apply a custom framework of understanding, communicate it and march forward! 

I truly believe that my prior BA experience has made me more effective as a project manager.  I would just caution anyone who has a similar career path to resist the urges I faced as above, which sometimes lead me to a sub-conscious dismissal of corporate standards.  This is not good for a project manager’s reputation, as I’ve personally experienced.  So savor your time as a BA, but recognize that as a PM it behooves you to adhere to standards and use the corporate templates.  By doing this you demonstrate the greater good of consistency to the organization, which far outweighs any customization needed from your BA days.

Having some background doing business or systems analysis work, I find myself using my prior BA skills all the time as a project manager.  I’ve also seen project managers who are highly efficient because they demonstrate BA skills in nearly everything they do.  PMs have a core duty to communicate understanding, and I’ve found the best examples of this involve taking disparate inputs, categorizing the inputs into a framework, building a visual of this framework, and socializing the visual in advance of formal presentation.  The ability to do this comes from a PM’s business analysis roots, which boil down to the following core skills:

Progressive elaboration:  Being assigned a new project can feel like initiating a “study”.  PMs seldom get handed a project at just the right time with just the right inputs.  We normally get fragments of progress when first assigned a project:  work that is partially complete, work that is complete but didn’t need to be complete, work that’s yet to be started but needed to start, etc.  Assembling these fragments into a framework of planning can feel like we are on a treasure hunt.  We peel back layers of the onion to come up with the proper sequence of work to be performed, decisions yet to be made, dependencies on other projects, scope to be defined and stakeholder confusion to clarify.  By undergoing this “study” as a BA would, we feel like we are in the military service:  we get paid to learn!

Analytical skills/critical thinking:  There is some level of analysis needed in putting all the pieces into a plan.  Task pre-requisites need to be sanity-checked and confirmed.  Items that need to be researched early in the project must be driven to resolution.  There’s the ever-present responsibility of due diligence.  The best of BAs do not just record requirements like a court stenographer, but instead apply some degree of analysis and application to a framework.  As PMs we don’t just capture tasks to type into our plans.  The high-stakes environment in which we perform projects today mandates some level of critical thinking and active analysis in everything we do.

Visualization:  This is the ability to take the results of our elaboration, analysis and planning and build visuals, so all stakeholders have a detailed understanding of the plans and any hindrances to the plan.  How many project meetings have you attended where the bulk of time is spent understanding the plan vs. evaluating the plan?  With effective visuals and explanations, the PM can quickly achieve universal understanding, and move the meeting’s focus to what truly needs dialogue:  validation and critique.  BAs are superior at visualization, as are professional trainers and teachers.  And since our world has moved away from paper and pencil, the best visualizers I know are highly PC literate.  For visualization, you can get a lot of mileage out the simplest of Microsoft tools that you likely have on your PC right now:  Excel and Powerpoint.  I use MS Project for predecessor management and calculations, but I always find myself building Gantt charts in Excel.  I’m sure MS Project has great reporting features, but creating bars over merged cells and color-coding them affords me the flexibility to communicate the exact message, with pinpoint accuracy and universality of understanding.

If you’ve never been a BA, no worries.  Even performing the basics of elaborating, analyzing and visualizing will make you a more effective project manager, and indeed a better general manager as well!

Has this ever happened to you?  Say you’ve been assigned a project in a subject matter with which you are not familiar.  You listen to your SMEs in meetings, take diligent notes, and quietly pull a SME aside and ask the questions you were afraid to ask after the meetings.  You read whatever documentation exists, which is often scattered bits and pieces of the subject matter like pieces of a jigsaw puzzle.  There are so many pieces missing, and no majority of pieces that you can cobble together to see what the end product looks like.  Surely you threw away the puzzle box!  Well, your core duties are scope, schedule and budget, so you show your true colors as a project manager and focus on that.

Fast forward to the end of the project, and through the trials and tribulations of scope changes, technical issues, requirements clarifications and testing, something magical happens.  You go back to your original notes and whatever had been documented, and surprisingly, it all makes sense now!  You understand the decisions made, any documented debate that lead to the decisions, and past e-mail threads that advocated the decision.  Is it just the passage of time that suddenly gains you this wisdom?  Did you undertake some sort of “practicum” in the subject matter of the project?  Did you undergo what felt like a full blown “night school” effort to learn the subject matter after hours?

Likely not.  Sub-consciously the vocabulary and concepts collect in our brains just by managing the project day in and day out.  Much like a new job in a new industry, “something” makes you much more competent 9 months after working in that industry – “something” for which you could have never prepared without immersing yourself in it by working in that field.  Just by being “present” to the project – attending meetings, actively listening to the resources, handling their issues, clearing their barriers – you pick up a vernacular.  Additionally, by doing your core function as a project manager – capturing tasks, vetting the plan, validating assumptions and documenting next steps – you can’t help but absorb the lexicon of your project’s subject.  Should we call this “osmosis”?  Yes, but for us project managers, who hold ourselves accountable to the results of the project, osmosis not only happens but is accelerated in that we actively listen for risks and clarity on next actions to keep the progress.  This responsibility forces us to learn the subject matter of the project.  There is no way around it.  One of my favorite quotes is “90% of life is showing up.”, by Woody Allen.  By accepting a project and doing the usual blocking-and-tackling, you’ll be surprised how much you’ll feel like a subject matter expert at project’s end.