Roles That Dictate Project Pace
Even with an excellent architect, an experienced development team, and a well-organized project manager, a Salesforce project can fall behind schedule. The common reason isn't the pace of building but the pace of decision-making. Development waits for a decision, the decision waits for a meeting, and the meeting waits for a calendar slot.
Therefore, the most effective division of roles isn't about who does what, but rather who decides what and with what response time. A review of the stages where each role is required can be found in the Salesforce Implementation Guide.
Nine Roles and Each Mandate
Executive Sponsor — Resolves inter-departmental conflicts, approves scope deviations, and protects project priority against competing pressures. If they lack budget authority, they are a representative, not a Sponsor.
Process Owner — Defines how work will actually be performed after the change, and confirms that the built process aligns with reality. One for each core process, not a committee.
Product Owner / CRM Manager — Manages backlog priorities, resolves conflicting requests, and maintains the connection between requirements and value.
Project Manager — Schedule, dependencies, risks, vendor coordination, and reporting.
Solution Architect — Makes decisions on the data model, permissions, system boundaries, and implementation approach; responsible for documenting considered alternatives.
Salesforce Admin — Configuration, environments, user management, and ongoing maintenance post-launch.
Developer — Custom logic, integrations, automated testing.
Data Owner — Determines the source of truth, what constitutes a valid record, and who approves data loads.
Adoption & Training Leader — Communication, role-based training, change resistance management, and usage measurement.
In a small project, one person might hold two roles, but there are two pairs that should not be combined: Architect and Project Manager (conflict between thoroughness and speed), and Process Owner and Test Lead (testing one's own work).
Who Must Be Internal
| Role | Can be External | Explanation |
|---|---|---|
| Executive Sponsor | No | Requires organizational authority |
| Process Owner | No | Requires ownership of actual work |
| Data Owner | No | Requires regulatory and business accountability |
| Product Owner | Partially | Guidance is possible, but not replacement |
| Project Manager | Yes | Common and acceptable |
| Solution Architect | Yes | Preferably with internal knowledge guidance |
| Admin | Yes, temporarily | Better to transition to internal before Go Live |
| Developer | Yes | Standard |
| Adoption Leader | Partially | Internal messaging must come from the organization |
RACI Matrix for Key Decision Points
| Decision | Accountable | Consulted | Required Response Time |
|---|---|---|---|
| Data Model Structure | Architect | Process Owner, Data Owner | Up to one week |
| Scope Change | Sponsor | Product Owner, Project Manager | Up to one week |
| Backlog Priorities | Product Owner | Process Owners | Up to two days |
| Required Field Definition | Process Owner | Admin | Up to two days |
| Data Load Approval | Data Owner | Architect | Up to three days |
| Production Release Approval | Sponsor | Project Manager, Process Owner | Per defined gate |
| Critical Issue Resolution | Project Manager | Architect, Admin | Same day |
The response time column is the interesting part of the table. A RACI without an SLA for decisions is a nice description that doesn't change the pace.
Realistic Availability — A Common Planning Error
| Role | Discovery | Build | Testing | Go Live & Weeks After |
|---|---|---|---|---|
| Sponsor | Low, consistent | Low | Medium | Medium |
| Process Owner | High | Medium | Very High | High |
| Product Owner | High | High | High | Medium |
| Admin | Medium | High | High | Very High |
| Data Owner | Medium | Low | High | Medium |
| Adoption Leader | Low | Medium | Medium | Very High |
A common planning error is assuming the Process Owner's workload decreases after discovery. In reality, it rises again during the testing phase, precisely when the employee returns to their routine work.
Illustrative Example: Academic College
This scenario is hypothetical and for illustrative purposes. A college implemented a system for managing applicants. The team was properly defined on paper, but the "Process Owner" was the head of the admissions department who could only dedicate two hours per week to the project. Every question about applicant status awaited until Tuesday morning.
After two months, it was measured that the cumulative delay waiting for decisions exceeded the delay from all other reasons combined. The solution wasn't to hire more developers. The college appointed a deputy who received an explicit mandate to make daily decisions up to a defined impact level, leaving only policy-changing decisions to the department head. Development pace increased without changing the vendor team's size.
Working Model with the Vendor
Three mechanisms are sufficient for most projects:
- Shared Decision Log — Every decision with date, accountable person, rationale, and rejected alternatives. This is also the only documentation that remains useful two years later.
- Single Point of Contact on Both Sides — Multiple direct inquiries from various participants to developers are a sure way to lose track.
- Regular Demo Cycle — The Process Owner sees a working product, not a presentation. A gap between expectation and reality is discovered within two weeks instead of two months.
In large organizations, an additional layer of governance between business units is required, as described in the Enterprise Salesforce Implementation Guide.
Intersections with Other Stages
Team composition is directly derived from two things: the deliverables required in the discovery phase, detailed in the CRM Discovery Guide, and the scope of the first wave, determined by the rules in the Salesforce MVP Scope Guide. A narrow first wave requires fewer concurrent Process Owners, which is an independent reason to limit breadth.
Quick Check Before Starting a Project
Answer four questions using first and last names, not department names: Who decides when Sales and Operations disagree; Who confirms that the built process aligns with reality; Who determines which data is reliable; and Who will maintain the system in a year. A missing answer to any of these is the biggest project risk, and it's also the only one that isn't solved with money.