Mar 31, 2024 12 min read

Defining Roles, Driving Success: Strategies for Effective Project Teams

Does every project need defined roles and responsibilities? While the answer may lean toward “maybe”, the context in which the project operates becomes critical in answering this question.

In smaller, tightly-knit teams where collaboration flows seamlessly and tasks are accomplished collectively, formal roles and responsibilities definitions are more work than the value it provides.

However, in the face of growing organizational complexity, where clarity and cohesion are challenged, clear roles and responsibilities definitions are integral. Moreover, identifying gaps in current roles and establishing expectations for both new and existing roles become a critical exercise for team and project success.

This article will explore the following (with examples):

Why should roles and responsibilities be defined?
How should roles be defined?
- Understanding gaps within the team
- Creating role definitions
- Advocating for new and augmented roles
When should roles be defined?
Who creates and approves roles?
When should the role definitions be updated?

Why Define Roles and Responsibilities?

Roles and responsibilities communicate ownership to the team and organization. Defining roles can also bring a sense of clarity and stability to the project and its delivery team, as well as build trust with the Executive team - especially if a project is off track.

Defining roles and responsibilities should NOT make team members feel as if they are "stuck in their lanes" and cannot provide critical feedback in other areas.

As a team, success and failure are collective, so it's important to address issues and risks even if it's outside of individual roles and responsibilities. This type of thinking and culture is usually empowered and fostered by the Project Manager, Product Manager, and Exec Sponsor.

Example 1: Lack of authority leads to indecision and slow progress

I was brought into a project with an existing cross-functional product team. Development had already started, however, progress was slow because it was decision-by-consensus and there was hardly any consensus on any technical matters - so hardly anything moved forward! After researching and talking to the team to understand the gaps, one of the changes I introduced was a clear set of roles and responsibilities. Some existing roles had their role definitions augmented, like having the product manager responsible for the entire feature instead of for one piece of it (this product manager managed specific dev teams as opposed to the whole feature stack, hence only creating product requirements for that team). Furthermore, new roles were added, like the technical lead and architect roles to resolve the lack of technical architecture and provide decisive direction, accelerating the project's advancement. The team still had disagreements, but those were all weighed in and a decision was made so that we could move forward. These roles and responsibilities were one of the first steps taken to allow the project team to be set up for success.

Example 2: Empowering the team to speak up

I was working on a program and we were well into the implementation phase when someone on the lower layer of the stack said they found it very difficult to use the application. They said it wasn’t intuitive and it was a poor overall experience. This was VERY hard to hear as the Application team worked hard on it. However, we had to take it in stride.The team had to go back to the drawing board for the UX and collaborated with the person who provided us feedback to dig into their experience. Myself and Product worked hard to set the stage to encourage this kind of feedback on the team. Our team felt they could trust each other and that it was a safe space to say, “we can do better”. From my perspective, this was a huge win! This kind of empowerment was garnered as we started the program by setting up a working agreement, constantly checking in with team members as a group and individually, listening carefully to retrospectives, and just really acknowledging the wins and letting the team have their moment! This also meant we didn’t shoot down ideas in an instant or put them in an ever growing backlog to say it’s been documented and then move on. We would have discussions and talk about the pros and cons before prioritizing the issues. It took time, a lot of time, but in the end it was worth it as we were proud of the product we built and we even made friends along the way!

How Should Roles be Defined?

In this section, we explore the critical steps of defining roles effectively by identifying and addressing gaps to meet project objectives. Then we will delve into some role definitions in bullet form and as a high-level RACI.

Understanding Gaps Within the Team

While defining roles and responsibilities, understanding the gaps and providing recommendations to address them is where the value of a project manager comes into play.

Depending on the stage you’re in, here are a few questions to ask yourself and the team to surface critical information. A couple of things to note: I usually ask this on an individual basis as I’m gathering feedback around the entire project; a draft working agreement is also an output of the gap analysis (but outside of the scope of this article):

Working together
- Has the team or people on the team worked together before?
  - If so, what worked and didn’t work?
Team resourcing
- Does the team have the necessary people to complete the work within a given time constraint?
- Are skill sets lacking?
  - Are these skills needed for the entire length of the project?
  - Do they know someone with the necessary skills who can complete this work and also work for the company?
- Are more senior people required?
  - This should be considered if there are a lot of junior members on the team.
- Do we need to look into contractors? This will be a bigger discussion that needs to take place with leadership
Decision making and leadership
- How are decisions made on the team?
- Are decisions effective? Should we make any changes?
  - If this is a new team working together, then it’s important to ask how they think decisions should be made on the team.
  - This will provide a perspective on the decision making tree. It might highlight the teams that escalate quickly if they don’t get their way, or gaps in the decisions. People usually remember a decision that was different to their recommendation, and then didn’t work out the way it was supposed to go - ask about how this could have been avoided.

Creating Role Definitions

Once roles and gaps are identified, then creating concise role documents is key. A one-pager often suffices without delving into exhaustive RACI charts, which can easily overwhelm readers. If a RACI is absolutely necessary, keeping it high-level is recommended to start - a detailed RACI or role definition can have many potential drawbacks, like stifling creativity or creating bottlenecks in decision-making. Detailed RACI charts become crucial when projects demand prescriptive guidance. Finding the right balance between clarity and agility ensures effective role management within the team.

Guidance for creating RACI charts is widely available online, so I won't delve into many details here (one helpful resource is TeamGantt's blog post on RACI best practices (https://www.teamgantt.com/blog/raci-chart-definition-tips-and-example). Instead, I will provide two examples below:

High-level roles and responsibilities for key players
High-level RACI for a workstream

Example 3: High-Level Roles and Responsibilities for Core Roles

Executive Sponsor

Accountable for overall project success.
Set clear goals and desired outcomes for the project.
Ensure alignment with the organization's overall strategy.
Secure project resources.
Negotiate with upper management for resources, timelines, and budgets as needed for project success.
Champion the project at an executive level to secure buy-in.
Guide the communication strategy and ensure it reaches the necessary stakeholders.
Resolve blockers by working with the appropriate organizational leads.
Approve the schedule and make themselves available for executive-level meetings and major status meetings.

Product Manager

Create and manage requirements for the product across the entire stack in a stack-ranked priority, explaining why these are important for the appropriate release - these should also be included in the Application Lifecycle Management (ALM) tool (e.g. Jira).
Attend scrum/team meetings to unblock any product-related questions or assist with prioritization.
Approve product requirement (epic, user story) before closure, and post-QA testing.
Participate in executive meetings or presentations, providing input regarding product features.
Publish Market Requirements Document (MRD) and Product Requirements Document (PRD), providing the value of the feature to the market and company portfolio.
Work with beta/UI feedback to update requirements and prioritize them.
Set pricing and SKUs, evaluate vendors, engage in demos, and assist with GTM activities.
Assist with the client and any support-team on-boarding processes and provide necessary content from a product perspective.
Approve end-to-end (E2E) quality test requirements.

Architect (the Architect and Dev Lead might be the same person)

Create an architecture document by reviewing product and UX requirements.
Select technologies and have them approved by the Dev Lead.
Ensure critical documentation is available in a wiki/online resource for team review.
Interface with architecture committee
- Review proposals with the architecture committee, make necessary adjustments before technical requirements are created, and answer development questions.
- If major aspects of the architecture change, update the document and seek approval from the architecture committee.

Dev Lead (the Architect and Dev Lead might be the same person)

Create functional/technical requirements within the ALM tool based on product requirements and architecture.
Resolve technical disagreements within the Development team.
Attend executive meetings and review slides from a technical perspective.
Assist creating the technical portion of customer or any support-team onboarding.
Participate in initial customer onboarding meetings.
Help the product manager determine pricing based on setup/deployment/maintenance costs.
Attend stand-ups, and planning meetings, and are accountable for technical decisions within the team.
Collaborate with QA to create E2E test requirements

Project Manager

Plan the project and monitor progress.
Communicate issues, risks, mitigation plans, and status.
Manage stakeholder communication.
Define processes/governance with buy-in from the team.
Manage and communicate dependencies.

Example 4: High-Level RACI used in a Workstream Kickoff

Context: The project has completed evaluations of all vendors, and the objective of this workstream is to choose a vendor and finalize negotiations. This is a RACI that can be reviewed with the team:

Deliverables / Team	Dev	QA	Sales	Customer Success	Product	Architect	Exec Sponsor
Select two vendors	R	R	R	C	A	R	I
Negotiate with vendors			C		R	C	A
Select vendor	I	I	I	I	R	C	A

Advocating for New and Augmented Roles

With the roles and responsibilities document creation underway, there might be a combination of changes required (new roles to be created as well as changes to existing roles). Creating these role definitions and expectations will help the Exec Sponsor find the right people. If they are not fulfilled, then it is important to highlight any risks to quality, schedule, cost, and scope.

For new roles, avoid over-inflating numbers. I have seen project managers ask for people with an emphasis that they will not be able to meet any deadlines with quality if they don’t get ALL of them. This is a sign they were not set up for success in the past and think that aiming higher and negotiating down to the number they actually need will allow the project to succeed . While the project might be successful this time, a similar request for the next project will face heavy scrutiny because the project manager has lost credibility.

The approach I suggest is calling out the following:

Each role required and their expectations
- If possible, a named recommendation if one is available
The duration this person is needed for the project with a clear start date
Risks/implications of not having each person and subsequent decisions and mitigation strategies if those people are not allocated for the project

Example 5: Role Shortage

The team was asked to deliver 5 products by the end of the year. We asked for 4 additional hardware engineers to help us achieve the goal with quality but only got 2. Therefore, we went back to the Exec Sponsor and Management team and outlined that we could deliver 2 of the 5 products (with quality) and that the rest would need to be stack-ranked. After much back and forth, the Exec team provided us with this priority and assumed the outlined quality risks.

Example 6: Role Augmentation

In the “Why Should Roles and Responsibilities be Defined” example, I mentioned we had a product manager who was managing requirements for only one part of the team. This product manager was managing several applications under a dev director instead of managing features across a stack. When interviewing the team about the gaps, they mentioned that some of the lower layer features and possibilities were not even exposed at the apps layer and it can add a lot of value if we could incorporate them. I took this new role definition back to the Exec Sponsor (which was approved) and this empowered the product manager to look at the whole stack when creating requirements - it became part of their mandate. They went back and researched, had some great conversations with the team, and were able to present new useful value-added requirements.

Example 7: Role Creation

When I started working on a full-stack project, I observed the Applications team trying to make most of the technical decisions without a comprehensive grasp of hardware or firmware. This sentiment was echoed by the team during my research and data-gathering phase. We didn’t have a technical lead, but the Apps team had a lot more organization and was more vocal about issues. After having some really good conversations with them, I realized they didn’t feel we had someone qualified on the team to make those decisions, so they were making them to keep things moving. I decided to advocate for a new role of an architect/dev lead to the Exec Sponsor and that it be someone who can span the whole stack instead of on the extreme ends of the stack (i.e. hardware or apps). This request required someone to be brought in from a different team. This approach, backed by clear role descriptions provided to the Exec Sponsor, proved instrumental in the project's technical success.

When Should Roles be Defined?

Role definition usually takes place at the beginning of a project or workstream. However, if something changes in the project midstream, then the role definition should be reviewed again.

Several indicators signal the need for role definition within a project:

In a cross-functional team where members are not familiar with one another's roles and backgrounds, establishing clear roles becomes important for fostering collaboration and clarity
When operating in an environment with low levels of trust, defining roles can help mitigate misunderstandings and promote accountability
If the project team encounters challenges in decision-making, such as indecisiveness or difficulty reaching a consensus, clarifying roles can provide a better framework for decision-making (i.e. teams work together to provide recommendations for solutions, but the person who is accountable for the final decision is clearly identified in order to make the final decision).

The need for role definition doesn’t imply failure within a project team. Instead, it represents a proactive step toward improving team dynamics and driving success.

Who Creates and Approves Roles?

While anyone can define roles and responsibilities, the starting point will usually be a manager or project manager. However, this person should never be the endpoint of this process (i.e. they should not be the one who approves as well!) It should be reviewed by the people impacted and then approved by someone accountable for that person or project. In other words, for a person in a functional group, it should be approved by the manager or director, and for a project team, the executive sponsor should approve them after it has been vetted by the impacted people on the team.

For me, I usually send the core team roles and responsibilities to the Product Manager before sending it to the project team for review. If I'm running a program, I will send only the roles and responsibilities for that workstream over to the team so it's relevant to their job function. Once everyone has reviewed and provided feedback, then I have the Exec Sponsor do the same before they approve the document. This approved document is posted on the project landing page where anyone can access it.

When Should Roles be Updated?

After the roles and responsibilities are approved, it's not usually reviewed or changed again unless something changes drastically in the project. However, fostering a culture of transparency and open dialogue encourages team members to raise concerns or suggest adjustments to role definitions as needed, promoting continuous improvement and alignment.

Examples of drastic changes in a project

Roles are added or removed from the project and others need to take on different responsibilities/accountability
Tension about decisions or how things are run in the project - there might be a need to get more fine-grained roles and responsibilities
Strategic direction of the project changes (e.g. deciding to use a vendor for portions of the product instead of creating the product completely in-house)

In conclusion, role creation and definition is one step in setting up the team and the project for success. It offers clarity, stability, and alignment within the team. By understanding the gaps of existing roles and gaps where new roles need to be created, and then advocating for those roles to be filled, it shows that the project manager is listening and understands the needs of the team, the project, and the business. Roles and responsibilities are not static; they evolve with the project's needs and the team's dynamics. As you embark on your project journey, embrace the power of defined roles while remaining open to adaptation and refinement along the way. Here's to unlocking the full potential of your team and achieving project excellence!

Is there something you would do differently? What are some good insights into roles and responsibilities that have come up in your career? Leave a comment and let us know!