The BA, PM, and Architect Walk Into a Project…

There’s a version of project delivery mythology that suggests successful implementations happen because someone had a brilliant idea. Requirements are gathered. Solution gets designed. Team builds. Users adopt. Everything moves neatly from one phase into the next.

That version has always felt incomplete to me.

After more than a decade working across technology delivery, I’ve started to believe that successful implementations rarely happen because of individual brilliance. More often, they happen because different disciplines challenge each other at the right moments.

The Business Analyst. The Project Manager. The Architect.

Three roles that often get treated as adjacent functions. But in practice, I’ve found they act more like a balancing system. Each one protects against a different kind of failure.

One of the clearest examples of this for me came during a Salesforce Public Sector Solutions Grants Management implementation circa 2023.

At the time, the Grants Management package itself was still relatively new within the ecosystem, and we launched within roughly a month of its availability. Looking back, it sounds exciting to say we were implementing early. At the time, though, it felt less like being ahead of the curve and more like standing on quicksand. Every decision felt consequential, and there was a constant awareness that a wrong assumption, rushed configuration, or overlooked dependency could pull the entire effort off course.

There’s a particular kind of uncertainty that comes with building on technology that is still evolving - where documentation exists, but not always for the scenario directly in front of you, and where decisions feel higher stakes because there are fewer examples to validate whether you’re moving in the right direction.

What made the work even more complex was that grants management is difficult long before technology enters the conversation. Grant administration has become complex enough that entire software markets have emerged to support it. In 2024 alone, the global grant management software market was estimated at approximately $2.66 billion, while government-focused grant management platforms represented an additional $2.1–2.4 billion market, driven largely by modernization efforts, compliance expectations, audit requirements, and increasing pressure around accountability and transparency.

Those numbers exist because grants rarely behave like a single business process. A grant program is usually less of a workflow and more of an ecosystem. A single grant can involve intake and application management, eligibility determination, review and scoring, award decisions, contracting, financial disbursement, reimbursements, reporting obligations, amendments, documentation, audit readiness, and closeout activities. Each stage introduces different stakeholders, different controls, and different definitions of success.

That complexity becomes even more visible in public sector environments. Grants are ultimately vehicles for stewardship of public funds, which means decisions that seem operational often carry financial, regulatory, and public accountability implications. Program teams optimize for service delivery. Finance teams optimize for controls. Leadership optimizes for visibility and reporting. Technology teams are left with the challenge of creating a system flexible enough to support all of those realities without becoming impossible to maintain.

Which is why implementing Grants Management never felt like implementing software. It felt like translating an operating model. Because Salesforce's Public Sector Solutions itself was still evolving, OmniScripts were relatively new to our team, and implementation patterns were still emerging, there were very few examples available to tell us whether we were approaching things the “right” way. Documentation existed. But not always for the exact scenario in front of us. At some point, I realized we had stopped implementing from a playbook and had started helping write one.

That experience changed the way I think about project roles. On paper, the structure looked straightforward: project management, business analysis, architecture, configuration, delivery. Everyone had a lane. Everyone had responsibilities. Yet once the complexity increased, those boundaries became less useful than I expected. What emerged instead was something more collaborative, and honestly, more human.

There were moments where the architect proposed solutions that made complete technical sense but didn’t fully reflect operational reality. The BA would step in—not to oppose the design, but to surface process nuance, policy implications, stakeholder context, or edge cases that changed how we thought about the solution.

Other times, business requests sounded reasonable until architecture exposed the downstream complexity they would create.

And then there was my role. I found myself less focused on maintaining plans and more focused on helping the conversation move forward. Sometimes that meant translating business language into technical implications. Sometimes it meant pushing discussions deeper. Sometimes it meant pulling people back up and asking whether we were solving for the actual problem or becoming attached to a particular solution.

Without realizing it, we formed our own little triad. The BA became the guardian of intent. The architect became the guardian of sustainability. And I, as the PM, became responsible for maintaining movement between the two.

What made it work wasn’t agreement. In fact, some of our best decisions came from disagreement. The BA corrected assumptions. The architect challenged requirements. I pushed for clarity and decisions. Nobody was trying to do someone else’s job. We were trying to understand enough of each other’s world to prevent the project from failing in ours.

That’s the part of delivery I think gets missed. People talk about alignment as if it means consensus. But alignment isn’t agreement. Alignment is allowing different disciplines to challenge each other without becoming territorial.

Looking back, I don’t think the success of that implementation came from individuals performing their jobs exceptionally well in isolation. I think it came from people being willing to temporarily step outside of their roles while still respecting each other’s expertise. Not specialists operating independently. But specialists overlapping intentionally.

There were conversations where I stepped into what looked much more like a functional consultant role than a traditional PM role. I sat in requirements sessions not only to understand scope and timelines, but to understand policy intent and process decisions as they were forming. I worked closely with both the architect and the BA during brainstorming sessions.

We analyzed licenses. We walked through workflows. We debated future-state process design. We pressure-tested edge cases. We asked questions that extended beyond our job descriptions because the project required us to.

What stood out to me most was watching assumptions get challenged in real time.

Stay in the Loop

Occasional thoughts on Salesforce, delivery, books, and opinions.