44 PM NETWORK NOVEMBER 2015 WWW.PMI.ORG NOVEMBER 2015 PM NETWORK 45

By understanding their respective strengths, project managers and business analysts can deliver better project results.BY AMY MERRICKILLUSTRATION BY ANGELA RIO

AlliedProject managers and business analysts don’t

always see eye to eye. Project managers focus on delivering a defined scope on schedule

and budget, while business analysts look to set the right requirements and improve the end results. Where a business analyst sees a profitable opportunity for a project to pivot, the project manager might see the risk involved with making changes mid-stream.

Although these different skills complement each other and lead to impressive project outcomes, competing priorities can cause problems. Nearly 70 percent of organizations report that collaboration between project managers and business analysts is essential for project success—but only 46 percent believe the two groups currently collaborate well, according to PMI’s 2014 Pulse of the Profession®: Requirements Management—A Core Competency for Project and Program Success.

Forces

NOVEMBER 2015 PM NETWORK 47

And the need to build a productive relationship will only grow stronger. More than half of organiza-tions will have an increased demand for business analysts over the next three to five years, according to the Pulse report.

“A mutual respect is really important,” says Alan Chute, PMP, a former business analyst who now is a project manager at the Insolvency Service in Dublin, Ireland. “It’s important that each person understands the role and the constraints that the other person is working within.”

Divide and ConquerBusiness analysts are responsible for defining require-ments and deliverables, which often leads to a laser focus on meeting stakeholder expectations. Project managers, on the other hand, must manage expecta-tions so that their projects don’t go off the rails, says Maksym Ovsianikov, PMI-PBA, PMP, lead technical business analyst, EPAM Systems, Mountain View, California, USA.

“Project managers concentrate their efforts more on the overall scope of the project, because they are constrained by the timeline, quality and other proj-ect requirements,” Mr. Ovsianikov says.

But both parties must get into lockstep to keep initiatives on track. Only 30 percent of low-per-forming organizations (organizations that complete 60 percent or fewer projects on time, on budget and meeting original goals) saw effective collaboration between project managers and business analysts—or the person performing requirements manage-ment—according to the Pulse report. It leaps to 67 percent for high-performing organizations—those that complete 80 percent or more of projects on time, on budget and meeting original goals.

Having clearly defined roles helps build a solid working relationship between business analysts and project managers, says Dwayne Wright, PMI-ACP, PMI-PBA, PMP, senior business analyst, Alaska Airlines, Seattle, Washington, USA.

When sharing his expertise on a project, he acknowledges where his responsibilities end and the project manager’s begin. At Alaska Airlines, he also takes the initiative to run high-quality requirement workshops and structured walkthroughs for project deliverables to make sure everyone stays on the same page. To keep collaborative relationships productive, he advises: “Support in public. Disagree in private.”

Developing a deep understanding of each other’s

roles and responsibilities can create a stronger working relationship—which often means more satisfied clients, says Odette-Simone Smolicz, PMP, project management office director, enterprise transformation, CRM Loyalty, Sydney, Australia.

“The project manager looks inward toward the solution team to make sure the solution is being built right, while the business analyst looks outward to the customer and organization to ensure that the right solution is being built,” Ms. Smolicz says. “The proj-ect manager also must look outward to the organiza-tion to ensure alignment of deliverables and solution to the strategic objectives. Through the project man-ager, the business analyst understands the challenges and issues and is able to relay those challenges [to customers] and facilitate decision making.”

Diplomatic RelationsFostering a truly collaborative relationship starts by building trust and opening the lines of com-munication, says Mr. Wright. He finds it helpful when project managers follow a schedule for shar-ing information and insights. These regular updates make it less likely that changes will fall through the cracks as the project evolves.

Only 30%

“Project managers concentrate their efforts more on the overall scope of the project, because they are constrained by the timeline, quality and other project requirements.” —Maksym Ovsianikov, PMI-PBA, PMP, EPAM Systems, Mountain View, California, USA

of low-performing organizations* saw effective collaboration between

project managers and business analysts—or the person performing

requirements management.*Organizations that complete 60 percent or fewer projects on

time, on budget and meeting original goals

for high-performing organizations.**

It leaps to

67%**Organizations that complete 80 percent or more of projects on time, on budget and meeting original goals.

Source: PMI’s 2014 Pulse of the Profession®: Requirements Management—A Core Competency for Project and Program Success.

48 PM NETWORK NOVEMBER 2015 WWW.PMI.ORG

ple, business analysts can fall into a pattern of play-ing it safe, says Mr. Ovsianikov. And if analysts don’t speak up to identify project shortfalls, that can lead to dissatisfied stakeholders.

Mr. Ovsianikov has worked as both a project manager and a business analyst. When serving as a project manager, he learned to give the business analyst leeway to propose creative ways to deliver a project’s technical requirements. He recently man-aged a team that increased from 10 members to 35 members during development of a new software product. Rather than microman-aging the user interface, he let his busi-ness analyst partner and user experience information architect take the concept and create wireframes, a type of sche-matic that shows how users would interact with the system. As a result, it helped his team to understand the product from the customers’ perspec-tive.

Although project managers need to verify that business analysts stay within cost, schedule and resource parameters, they also need to be flexible when it feels as if the analyst is pressing too hard to change the project scope, says Ms. Smolicz.

While project managers must critically asses each change that is recommended—and analyze the dependencies each change will affect—they must also make sure the end result will meet the stakeholders’ high priority demands, she says. “The business analyst must ensure the project manager does not sacrifice the solution in response to the demands of schedule or budget.” PM

Too Many HatsAt some organizations, project managers also play the role of business analyst. How-ever, multitasking and the inherent chal-lenge of using different skills for each role can become a risk factor when the project is too big for one person to handle both roles. When the burden gets too heavy, it’s best to split up responsibilities to keep the project on the right path.

For instance, Maksym Ovsianikov, PMI-PBA, PMP, senior technical business analyst, EPAM Systems, Mountain View, California, USA, recalls a software project in which he initially performed both roles on a 10-member team. But in a short time, the project had expanded to 35 team members in different locations—with a short timeline, large scope and a high number of requirements. Mr. Ovsianikov began to spend a huge amount of time simply developing schedules, organizing meetings and creating minutes. He realized he needed help.

Because Mr. Ovsianikov knew the product well, he chose to focus on business analyst responsibilities and asked another person to become the project manager. “We agreed who would cover what, who would handle which tasks and how we would effectively collaborate,” he says.

The new project manager focused on communication, project planning and solv-ing issues within the team. Mr. Ovsianikov, meanwhile, remained the primary point of contact for the customer, eliciting and translating requirements and the vision of the product to the software development team. “It was a really good decision—our customer was really satisfied,” he says.

“The project manager looks inward toward the solution team to make sure the solution is being built right, while the bu siness analyst looks outward to the customer and organization to ensure th at the right solution is being built.”

—Odette-Simone Smolicz, PMP, CRM Loyalty, Sydney, Australia

NOVEMBER 2015 PM NETWORK 49

Inviting business analysts to planning sessions or other project management meetings also helps them get a front-row view of the pressures that project managers face on a daily basis, says Michael Brown, senior technical writer, Lockheed Martin, Raleigh, North Carolina, USA. Mr. Brown’s role encompasses many of the responsibilities often handled by a business analyst.

“Techniques are great, but understanding is always better,” Mr. Brown says. “Because once the project manager understands the problem the busi-ness analyst is trying to solve, and once the business analyst understands the project manager’s decisions are driven by pressures out of their control, then more appropriate techniques can be created or applied.”

But the relationship shouldn’t be all business. Lunch meetings or other social activities, such as playing a sport together, allow the project manager and business analyst to develop a personal bond that can ease professional tensions.

“This helps the working relationship, because you can push the boundaries and challenge each other,” Mr. Chute says. “That’s not the case with strangers or even acquaintances. You may have a very different view than that person, but you wouldn’t challenge that view as strongly as with somebody you know.”

From Both FlanksBy playing to each other’s strengths—and compen-sating for each other’s weaknesses—project manag-ers and business analysts can produce better results. But if one party steamrolls the other, the project outcome will most likely suffer.

When project constraints are too rigid, for exam-