Skip to main content

Is Your Project Manager-Business Analyst Collaboration a Pressure Cooker?

Is your project’s red-yellow-green status for requirements based on percentage complete of the requirements document?  

Or percentage complete of the JIRA stories documented?

Maybe this is why requirements are taking so long!

Is the focus on the status of the document or the progress toward shared understanding of the problem and solution?


{module ad 300×100 Large mobile}


It is important to honor the priorities of both the project manager and the business analyst. One can’t win out over the other or the end users might suffer. So, how do we find the right balance? How do PMs and BAs come together to support each other while standing up for the essence and integrity of their roles?

  • Project Managers – Do you know what it takes to collaborate with BAs to get great project results? Are you encouraging BAs to be leaders of their domain?
  • Business Analysts – Do you understand the value of the BA role and how the PM can support and enhance your practice?

Tight timelines and fixed solutions apply tremendous pressure to interactions between PMs and BAs. The pressure triggers negative PM and BA behaviors. I’ll highlight some of these behaviors below and offer insight to inspire better collaboration.

Pressure #1: Tight Timelines

Tight timelines put pressure on the entire project team. When documents like BRDs are tied to unreasonable durations in the project plan, BAs feel like document dispensers:

tighttimelines

Tight Timelines Mindset to Change – Get documents done NOW!

What does the “Get Documents done NOW” mindset look like:

  • The PM lets the BA know timelines are really tight.
  • The PM asks the BA to draft documents ASAP.
  • BAs start filling out templates and then use the review process as an elicitation technique to get them reviewed approved “quickly.” (FYI-It’s not faster! It’s actually a long, painful process that stakeholders loathe, BUT…)
  • Stakeholders get used to reviewing text-based documents and tolerate the process because it’s the only process they know.

Tight Timelines – A Collaborative Alternative

Modern PMs and BAs understand the drawbacks of the “write-review-repeat” cycle—it actually takes longer and produces unstable, ever-changing requirements.

Related Article: A Collaborative Stakeholder Process

Why? Well, because the team never gets a chance to collaborate and develop a shared understanding of the big picture and the real problem the team is trying to solve. They only understand their piece of the puzzle and cannot see connections or gaps that may have prevented defects or maximized the value of the solution.

Instead of forcing text-based document review from day one, the team should support a requirements process that includes dialog and analysis with stakeholders. The BA should be using elicitation and modeling techniques to facilitate structured conversation with stakeholders about the current state, future state, people impacted, process, data, rules, etc.

Once there is a shared understanding, document writing, review and approval move along quickly. Overall, this collaborative approach is faster and yields higher quality requirements.

Tight Timelines Mindset to Change – Minimal BA Planning

What does the “Minimal BA Planning” mindset look like:

  • The PM owns the project plan. (What BA plan?)
  • The PM sets a milestone for requirements sign-off or sprint commitment on the plan.
  • The PM focuses on the date/deadline and the document (or tool) vs. the quality of the requirements process.
  • BAs may or may not have experience or training in creating BA plans and a quality requirements process. Either way, they may follow the PMs plan without discussion or negotiation.

Tight Timelines – A Collaborative Alternative

PMs should encourage BAs to design their own approach. PMs and BAs should collaborate on the plan, timelines, who is involved, and what is truly needed to get to good requirements. The team should meet with the sponsor and get agreement on the quality expected and plan for requirements accordingly.

Tight deadlines may be ok if time and cost are the drivers of the project. Rework and quality issues might be worth the pain to get it done by a date. But, if quality, user experience, data integrity and getting users to love the solution are the drivers, then speeding up requirements and focusing on deadlines and documents will spell disaster.

Pressure #2: Fixed Solution

It’s always surprising to me how common it is for project teams to start their work wearing the blinders of an assumed solution. BAs are basically asked to reverse engineer requirements for a solution that floats down from above:

fixedsolution

Solutions tossed down to the BA, before analysis, tend to promote the following behaviors:

Fixed Solution Mindset to Change – Don’t Ask Questions!

What does the “Don’t Ask Questions” mindset look like:

  • The stakeholders communicate their want (not their true needs).
  • The stakeholders (sometimes on their own) identify a solution, and it is rarely a complete solution that is analyzed and well thought out.
  • The PM and the stakeholders pressure the BA to crank out a requirements document.
  • No one explores the true needs of the end-user and, therefore, no one knows if the predefined solution meets the true needs of the end-user or the organization.
  • Gaps/issues are ignored, placed in a parking lot, or found along the way or after go live, creating a long backlog of enhancements.

Fixed Solution – – A Collaborative Alternative

In my experience, stakeholders rarely ask for the right solutions. There is always more—a twist and a turn that yields a different solution than requested. Rushing a solution that was never really vetted, yields endless scope changes, increased defects, and unhappy users.

That’s why, as tough as it is, BAs need to appropriately challenge predetermined solutions and help their stakeholders think.

PMs need to support the BAs, even under tight deadlines, to explore true needs and generate options/alternatives. The PM and BA should work together to help the sponsor understand the risks of moving forward without analysis.

Fixed Solution Mindset to Change – Deep Rooted Bias

What does the “Deep Rooted Bias” mindset look like:

  • Everyone (PMs, testers, developers, product owners, end-users, etc.) is aware of the solution at the beginning of the project.
  • The sponsor and the stakeholders agree to validate the solution.
  • The awareness of the predefined, but not yet analyzed solution creates bias that limits the team’s ability or motivation to see/identify alternatives.
  • The BA doesn’t push for deeper discussion because the team is ready to move forward with the stakeholders’ plan.

Fixed Solution – A Collaborative Alternative

The BA’s primary role is to advocate for value! This should be a ruthless focus—much more important than the perfect document. BAs need to courageously ask the PM and the team for time to make sure the solution is value-oriented, not just first-idea-oriented.

Easing the Pressure

A collaborative partnership between PMs and BAs requires:

• PMs and BAs who understand their role and are leaders of their domain.

• PMs and BAs who can clearly communicate and advocate their perspectives and priorities.

• A shared understanding that trust and teamwork will maximize solution value.

How do you build bridges between business analysis and project management in your organization? Please leave your comments below.

easingpressure