assignment matrix definition business

What Is A RACI Chart? How This Project Management Tool Can Boost Your Productivity

Updated: Dec 14, 2022, 2:20pm

The RACI chart has long been a popular tool amongst project managers around the world. Also referred to as the RACI matrix, it’s used to clarify employee roles and responsibilities for each task, milestone and decision that takes place throughout a project.

The chart is designed to ensure clear communication and smooth workflows across all parts of a team. RACI charts can help prevent that sinking feeling when a major decision-maker comes at the end of a project and complicates things with a large number of changes because they weren’t consulted throughout the project.

Featured Partners

From $8 monthly per user

Zoom, LinkedIn, Adobe, Salesforce and more

On monday.com's Website

Google Contacts, Mailchimp, Xero, Aircall, Airtable and more

On HubSpot's Website

Yes, for one user and two editors

$7 per user per month

Google Drive, Slack, Tableau, Miro, Zapier and more

On Smartsheet's Website

Yes, for unlimited members

$7 per month

Slack, Microsoft Outlook, HubSpot, Salesforce, Timely, Google Drive and more

On ClickUp's Website

What Is a RACI Chart?

A RACI chart, also called a RACI matrix, is a type of responsibility assignment matrix (RAM) in project management. In practice, it’s a simple spreadsheet or table that lists all stakeholders on a project and their level involvement in each task, denoted with the letters R, A, C or I. Once these roles are defined, assignments can be attributed to the roles and work can begin.

R, A, C, I stands for:

Responsible

Accountable.

Here’s what each designation means:

Responsible designates the task as assigned directly to this person (or group of people). The responsible person is the one who does the work to complete the task or create the deliverable. Every task should have at least one responsible person and could have several.

Responsible parties are typically on the project team and are usually developers or other creators.

The accountable person in the RACI equation delegates and reviews the work involved in a project. Their job is to make sure the responsible person or team knows the expectations of the project and completes work on time. Every task should have only one accountable person and no more.

Accountable parties are typically on the project team, usually in a leadership or management role.

Consulted people provide input and feedback on the work being done in a project. They have a stake in the outcomes of a project because it could affect their current or future work.

Project managers and teams should consult these stakeholders ahead of starting a task to get input on their needs, and again throughout the work and at the completion of a task to get feedback on the outcome.

Not every task or milestone needs a consulted party, but the project manager should consider all possible stakeholders when creating the RACI chart and include as many consulted parties as is appropriate. You should limit this to only necessary input, however. For example, one consulted party per affected team is generally considered best practice to avoid clogging the process with too much input.

Consulted parties may be individuals on the project team who aren’t working on a given task but whose work will be affected by the outcome. They’re also often teammates outside of the project team—even in different departments—whose work will be affected by the outcomes of the project.

Informed folks need to be looped into the progress of a project but not consulted or overwhelmed with the details of every task. They need to know what’s going on because it could affect their work, but they’re not decision makers in the process.

Informed parties are usually outside of the project team and often in different departments. They might include heads or directors of affected teams and senior leadership in a company.

When Should You Use a RACI Matrix?

The framework of a RACI chart is useful for almost any project, although some teams might find it more useful than others

For example, I know in creating this article that I’m the responsible party, because I’m doing the work of writing. My editor is accountable for assigning and reviewing the work. And they likely have consulted and informed others around them, such as a managing editor and an SEO specialist.

But this project is fairly simple. It only takes a few steps and includes a handful of stakeholders. A formal RACI chart comes in handy for complex and long-lasting projects that include lots of stakeholders, tasks and milestones, especially if work is overlapping.

For example, a company’s website redesign would require design, copy and development teams to work on tasks concurrently. Each task would affect work in sales, marketing, finance and business development. Structural changes, timelines and major costs would require input and approval from senior management.

Needs are easily overlooked and requirements dropped in such complex projects.

A project manager typically creates a RACI chart to avoid missing those important details and ensure clear communication throughout the project.

Using RACI with Other Project Management Methodologies

Agile is a very popular type of project management, especially for tech workers. While RACI is applicable to agile project management, schools of thought vary on whether it is necessary for an agile context.

Additionally, the Scrum and Scrumban project management methodologies build project ownership (accountability) into their framework and are designed to facilitate regular communication among project teams and outside stakeholders. That makes a RACI chart seem redundant for this method and possibly a poor use of a project manager’s time.

However, additional communication and clarification—in a systematic fashion—tend to be more of a benefit than a drawback for any project, so some SCRUM project managers find RACI useful for clarifying roles for individual projects or their overall process.

Example RACI Chart (and How to Use It)

To create a RACI chart, list all of a project’s tasks down the left-hand column and stakeholders across the top row. For each task, enter an R, A, C or I to assign a level of involvement for each stakeholder in each task.

For example, in the matrix above:

• The senior analyst is responsible for completing the work in the econometric model.
• The SVP finance is accountable for that task—they assign it to the senior analyst and review the work.
• The team will consult the SEO lead for input before and feedback after the task.
• The team will inform the project manager, head of design, sales director and senior management of the project’s progress.

Color coding tasks can be useful to see at a glance whether any team member is responsible for too many tasks within a project and to make sure you’ve assigned at least one Responsible and one Accountable party for each task.

Breaking the chart down by project phases also lets you see how many tasks anyone is responsible for within a certain timeframe, which can help distribute work evenly and avoid overwhelm.

Pros and Cons of RACI

From a project management perspective, things like more organization and clearer communication are generally better, so the benefits of using a RACI chart on a project far outweigh the drawbacks in most cases. With that in mind, teams should be cognizant of the initial time investment of creating a RACI chart and the rigidity of the roles.

• Maintain clear and open communication with all stakeholders.
• Avoid overwhelming team members with tasks or unnecessary information.
• Avoid “too many cooks” offering input on any task.
• Help stakeholders prepare for a project’s future impact on their work.
• You might spend time unnecessarily creating the chart for simple projects.
• Roles are rigid and might not fully illustrate a team member’s stake in a project.

You might see additional drawbacks using a RACI chart for your project if your team succumbs to some common pitfalls, including:

• Stakeholders will be confused if they don’t understand the differences among the terms, especially Responsible versus Accountable and Consulted versus Informed.
• It’s a formality and a waste of time if no one references it after approval.

RACI Matrix Alternatives

Some teams find the roles designated through the RACI model aren’t the right fit for their projects. You might find better options in these less common alternatives—all use a chart with tasks and stakeholders like RACI, but they use different terms in an attempt to more clearly define roles.

This alternative to RACI uses the RACI model plus S for Supportive. This is someone who participates in doing the work of a task by supporting the responsible parties.

This model designates stakeholders as:

• Communicate: These are the consulted and informed parties.
• Approve: This is the decision maker.
• Responsible: This person does the work.
• Support: These parties support the responsible person in doing the work.

This model simplifies CARS with just the Responsible, Approve and Support roles. It eliminates communication outside the project team, which would need to be accounted for another way in the project management method.

This model includes these roles similar to RACI:

• Drivers: The people who do the work.
• Approvers: The decision makers.
• Contributor: People who are consulted on the task.
• Informed: People who are informed of the project’s progress.

In this model, stakeholders are assigned these actions:

• Contribute: People who are consulted and who do the work.
• Lead: People who delegate work and manage a task.
• Approve: Decision makers.
• Monitor: People who are kept in the loop on a project’s progress.

Bottom Line

Projects can be complex, confusing and chaotic. That’s why we rely on team members with the project management skills necessary to reign in the disparate pieces of a project and focus directly on keeping them organized as a project progresses.

A RACI chart is one tool that helps project managers keep a project on track.

By listing all stakeholders and assigning a level of involvement for each task, the chart helps teams communicate clearly and keep the right people in the loop.

• Best Project Management Software
• Best Construction Project Management Software
• Best Project Portfolio Management Software
• Best Gantt Chart Software
• Best Task Management Software
• Best Free Project Management Software
• Best Enterprise Project Management Software
• Best Kanban Software
• Best Scrum Software
• Asana Review
• Trello Review
• monday.com Review
• Smartsheet Review
• Wrike Review
• Todoist Review
• Basecamp Review
• Confluence Review
• Airtable Review
• ClickUp Review
• Monday vs. Asana
• Clickup vs. Asana
• Asana vs. Trello
• Asana vs. Jira
• Trello vs. Jira
• Monday vs. Trello
• Clickup vs. Trello
• Asana vs. Wrike
• What Is Project Management
• Project Management Methodologies
• 10 Essential Project Management Skills
• SMART Goals: Ultimate Guide
• What is a Gantt Chart?
• What is a Kanban Board?
• What is Gap Analysis?
• Work Breakdown Structure Guide
• Agile vs. Waterfall Methodology
• What is a Stakeholder Analysis
• What Is An OKR?

How To Get A Business License In North Dakota (2024)

How To Write An Effective Business Proposal

Best New Hampshire Registered Agent Services Of 2024

Employer Staffing Solutions Group Review 2024: Features, Pricing & More

How To Sell Clothes Online In 2024

2024 SEO Checklist

Dana Miranda is a Certified Educator in Personal Finance® who's been writing about money management and small business operations for more than a decade. She writes the newsletter Healthy Rich about how capitalism impacts the ways we think, teach and talk about money. She's the author of YOU DON'T NEED A BUDGET (Little, Brown Spark, 2024).

With over a decade of editorial experience, Rob Watts breaks down complex topics for small businesses that want to grow and succeed. His work has been featured in outlets such as Keypoint Intelligence, FitSmallBusiness and PCMag.

Popular Insights:

Best Project Management Software

Mind Mapping Software

What Is a RACI Matrix?

Share this Article:

Our content and product recommendations are editorially independent. We may make money when you click links to our partners. Learn more in our  Editorial & Advertising Policy .

Key takeaways

Successful project management depends on a team-wide understanding of roles and responsibilities. Using a RACI matrix to assign and define each role is a great way to keep a project on track and positioned for success.

Featured Partners

{{ POSITION }}. {{ TITLE }}

How Does a RACI Chart Help Project Managers?

Project managers use RACI charts to keep track of team roles and relay those responsibilities to the larger team. The matrix defines clear roles and responsibilities for individual team members across the various phases of the project, breaking each role down into four types of designation: those who are Responsible and Accountable for project deliverables, those who should be Consulted as work begins, and stakeholders who need to be Informed of ongoing progress, roadblocks, and updates. 

Read more: Project Management Phases

RACI Matrix Definitions 

Responsible.

The individual(s) with responsibility for the task or deliverable is typically responsible for developing and completing the project deliverables themselves. The responsible parties are typically hands-on team members who make direct contributions toward the completion of the project. The responsible team is comprised of the project’s “doers”, working hands-on to ensure that each deliverable is completed. 

Some examples of responsible parties are:

• Project Managers
• Business Analysts
• Graphic Designers
• Copywriters

Accountable

Accountable parties ensure accountability to project deadlines, and ultimately, accountability to project completion. This group frequently also falls under the informed category.

Some examples of accountable parties are:

• Product Owners
• Signature Authorities
• Business Owners
• Key Stakeholders

Consulted individuals’ opinions are crucial, and their feedback needs to be considered at every step of the game. These individuals provide guidance that is often a prerequisite to other project tasks, for example, providing legal guidance on a project throughout the process. If you are working on new product development or expansion, this could essentially be the entire organization.

Some examples of consulted parties are:

• Legal Experts
• Information Security and Cybersecurity Experts
• Compliance Consultants

Informed persons are those that need to stay in the loop of communication throughout the project. These individuals do not have to be consulted or be a part of the decision-making, but they should be made aware of all project updates. Typically, this party are business owners or stakeholders that are more interested in viewing the project at a 30,000-foot view.  Keep this group on your cc list for awareness of topics, decisions, and progress – that includes making them part of the initial project kickoff and project demos as optional attendees. This group often also falls under the accountable group.

Some examples of informed parties are:

• Project Committee Members
• External Stakeholders

Read more: DACI vs RACI Model Guide

Why Are RACI Roles Important?

RACI roles provide a sense of organization and clarity for teams that are looking to divide roles and keep team members accountable for their contributions. Considering that 27% of projects go over budget, for reasons like scope creep and lack of defined roles, RACI roles help position a project for success and avoid common pitfalls. 

Moreover, RACI roles help ensure that communication between all roles is ongoing. When you consider that nearly half of all project spending is at risk of being wasted due to a lack of effective team-based communication, it becomes all that more important to prioritize. Ultimately, teams who prioritize communication and well-defined roles are better off, and RACI roles help teams achieve that goal faster – while providing accountability for each team member’s unique contributions to the success of the project. 

Read More: Top 10 Main Causes of Project Failure

How to Create a RACI Matrix 

If you’re looking to implement a RACI matrix as part of your team’s project planning process, take these steps to create a RACI matrix.

Ensure that you have a thorough understanding of the project and its demands before outlining any further steps by communicating with key stakeholders and decision-makers.

Determine the list of key activities and deliverables from the director of program management or other leadership. 

Determine who is needed to be a part of the project or initiative.

Determine the project roles and responsible job titles and persons for each activity and deliverable.

Hold review sessions with key members of the team for alignment, and if you haven’t already, host a kickoff meeting with the entirety of the team and key stakeholders to unveil the matrix, address questions, and more. 

If the project has already started, it’s not too late to implement a RACI matrix.

• Outline the story. Using research from multiple sources, do a, b, c, and d.
• Utilize steps 2 and 3 (shown above). Ensure the right groups are assigned and engaged. 
• Hold a review session. Ensure that the team acknowledges and discusses the plan and the roles assigned.

Read more: 8 Factors That Lead to Successful Projec ts

Examples of a RACI Matrix

As shown above, a RACI matrix helps break down what roles individuals will play as work is carried out and to what extent they will be involved in the project overall. The horizontal axis represents each person on the project team and the vertical axis represents each task.

Each square of the matrix represents an individual, a task, and that individual’s role within the project, either responsible, accountable, consulted, or informed. In this situation, for example, the project manager is accountable for accessing risk, defining performance requirements, creating designs, executing construction, and approving construction work. However, they are only informed about approving construction work and defining functional and aesthetic needs.

Read more: Understanding Different Types of Stakeholders and Their Roles

Our FREE Downloadable RACI Matrix Template

Who creates the raci matrix.

The RACI matrix — sometimes called RACI model, RACI diagram, or simply just RAC — is created by the project manager at the start of the project as a key part of establishing the initial human resources planning for the project. Because miscommunication is a common threat to any project, RACI charts are a great asset to teams dealing with any type of project, from very simple projects to extremely complex ones. 

Common Mistakes When Creating a RACI Matrix

• Failure to plan ahead: Utilizing a RACI matrix should not be your first step in project planning. Having a fully assembled project team and at least a general idea of a task list and project plans is a better place to start before preparing a matrix.
• Working with too large a team: A RACI matrix is likely not the best bet for a large team, as it will make the matrix hard to understand and overly complex.
• Not communicating with the project team: A RACI matrix should help organize tasks and responsibilities that have already been introduced to the project team – no one likes to be blindsided. Be sure to host a kickoff meeting with the team first before creating a RACI matrix.

Frequently Asked Questions

Implementing a RACI matrix takes more than just a few emails and sporadic conversations – it takes consistent communication and planning. You should host a kickoff meeting to introduce the matrix to the team and make a plan to continue meeting at predetermined times throughout the project lifecycle. 

Here are a few more tips to keep in mind as you implement your RACI matrix within the team dynamic:

• Get everyone prepared. Send the document around to the meeting distribution as read-ahead material, requesting feedback if there are any major concerns. 
• Roll out each role for the team . During the meeting, conduct a review of the tasks and responsible parties. Do not rush through this review, but rather ensure enough time in your project kickoff for this important aspect. (Be certain to clarify the definitions of RACI to avoid ambiguity.)
• Consider changes and update accordingly. After the meeting, send out the notes documenting acceptance or updates to the RACI. In addition to sending out the notes, request any corrections within a reasonable yet defined timeframe. Clarify that if no changes are requested, each person is acknowledging their role and committing to the project tasks as outlined.
• Stay in touch. Consider a quick review with the entire team each quarter or every six months for longer projects to ensure it remains up-to-date and not simply another document in the repository but a relied-upon artifact.

As you implement the RACI matrix…

• Encourage teamwork and foster collaboration whenever possible.
• Don’t fear updates – make changes and adjustments as needed (but be sure to communicate those changes clearly to all parties).
• Earlier is better. Roll out your matrix plan to the team BEFORE you plan to implement it for the best results. 
• Have a clear-cut understanding of the project scope and how each role connects to the overall project goal.

For “Responsible” Parties:

• Make sure your project’s definition of Responsible is clear on who holds the “decider” role for the project or project phase’s completion, and what the dimensions of that responsibility will be.
• Ensure that all parties are aware of their role and responsibilities within the matrix.

For “Accountable” Parties: 

• When multiple Accountable team members must exist, use your definitions to make clear which individual is accountable for a given project element, and how that individual needs to interact with other Accountable team members.
• Ensure that there is only one “Accountable” party assigned per task.
• Be sure that the Accountable party has the authority and power to oversee the task as the accountable party.

For Consulted and Informed Parties: 

• Consulted parties are often high-level decision-makers with heavy schedules. Make sure you’re clear on their availability ahead of time.
• Similar to Consulted parties, Informed parties are often less hands-on and have less understanding of day-to-day project operations. As the project goes on, make sure to keep detailed notes to keep the Informed party up-to-date on key information. 
• Understand the ways that these parties like to communicate and create a plan to reach them early – whether that’s over phone calls, emails, video calls, or from within your project management system’s collaboration tools.
• Knowing the difference between who needs to be consulted versus informed can be a challenge if there is ambiguity about project roles. Consider what aspects of the project different team members need to know to do their jobs, and then bake those into your definitions.

RACI Matrix Pros & Cons

• Increased Engagement: RACI helps engage project participants in the project lifecycle. 
• Enhanced Project Planning: Project managers make project planning more organized, efficient, and detailed.
• Identifiable Improvement Opportunities: Areas of improvement are more easily identified.
• Easier Collaboration: Use of a RACI matrix creates a clear path for leadership to sign off on project steps, as project documentation in the RACI model is heavily emphasized.
• Better Communication: Improves overall group communication as a whole.
• Group Accountability: Assists groups, especially larger project teams, stay connected and accountable to their roles and project goals
• Limitations on Role Scope: The RACI model does not provide details on role scope, especially for responsible parties. These gaps in detail also affect other team roles, for example, another gap in a RACI is the determination of who is responsible for verifier and signatory.
• Limits on Task Details and Scope: While a RACI matrix can provide an overview of who is responsible for different tasks, it will not state what needs to be done.
• Not Aligned to the Agile Methodology: Project managers using an agile methodology like scrum may find it redundant since accountability, ownership, and ongoing communication is built into the scrum framework (i.e., product owner, scrum master, and daily standups with the team). Additionally, agile focuses on team-based delivery and accountability, while the RACI framework and alternatives focus on individual responsibility and autonomous accountability.

Read more: Top 10 Causes of Project Failure

Free RACI Matrix Templates

A number of project management software solutions include a native RACI matrix template. Here are just a few we’ve found:

Colorful RACI Chart Template

We love this template from Smartsheet because it’s colorful, thorough, and includes room for every party involved in the project. 

Pastel Colored RACI Matrix Template

This template from the Academy to Innovate HR is a great choice for project managers who want to organize their team roles with an easy-on-the-eyes chart that evolves beyond the simple spreadsheet. 

Simple RACI Chart from Clickup

These RACI templates from Clickup have enough variety to fit any of your project needs, but are simple enough for even beginner PMs to use.

Detailed RACI Matrix Template

This template is a great starter template for anyone looking to explore RACI charts in their project management strategy . As an added bonus – it comes with the RACI definitions already built in!

Excel-Based RACI Chart Template

Are you an Excel or Google Sheets user looking to take advantage of the RACI matrix? An Excel-formatted template from Project Management Docs can be just the solution for you. This template is a great template for users who want a chart that comes in a pre-formatted structure.

Sign up for our emails and be the first to see helpful how-tos, insider tips & tricks, and a collection of templates & tools. Subscribe Now

{{ TITLE }}

You should also read.

Project Identification: What It Is and How to Do It Correctly

What Is a Critical Path Method in Project Management?

How to Take Meeting Minutes Effectively (+ Example and Templates)

Join our newsletter.

Subscribe to Project Management Insider for best practices, reviews and resources.

By clicking the button you agree of the privacy policy

Get the Newsletter

You might also like.

How to Manage Time Constraints: Top 7 Expert Tips

6 RACI Matrix Alternatives to Help Define Project Roles

10 Benefits of Project Management Software for Business

Run and collaborate on creative projects more smoothly.

Plan, manage, and track product launches and campaigns.

Stay organized and communicate critical details to teams.

Streamline and scale manufacturing operations.

See how TeamGantt helps teams like yours meet deadlines, streamline communication.

Successful marketing project starts with a plan.

Track event details and to-dos.

Scope out roadmaps and manage backlogs.

Manage design, copy, and video work.

Learn all about gantt charts and how to use them to manage projects more easily.

Hear real testimonials from real TeamGantt customers.

Discover why companies like Amazon , Netflix , and Nike manage their projects with TeamGantt.

What Is a RACI Chart? How to Use RACI to Assign Project Roles

It’s a fact: Complex projects make it easy for teams to lose track of tasks.

You might have an air-tight project plan and a stellar team to back it up. But if you’re not crystal clear about assignments—or even involvement—on a task level, confusion, crankiness, and even demotivation will creep into your project team.

Lucky for you, avoiding those issues is as simple as creating a RACI chart. 

In this article, we’ll explain what RACI stands for and how it’s used in project management. We’ll also share a few practical examples so you can see how to apply the RACI model to different types of projects.

What is a RACI chart?

Raci definitions explained, benefits of the raci model in project management, how to make a raci chart, raci rules and best practices.

• RACI chart examples

When to use or skip a RACI chart for your project

Common raci pitfalls and how to avoid them.

A RACI chart—also known as a responsibility assignment matrix —is a diagram used in project management to define team roles across 4 categories: Responsible , Accountable , Consulted , and Informed . It helps clarify who does the work, who calls the shots, whose opinion matters, and who needs to stay in the loop for each task, milestone, or decision.

A RACI chart enables you to visualize roles and responsibilities at a more granular level than simple resource assignments. That way team members and stakeholders know what’s expected of them so confusion doesn’t get in the way of project success.

RACI stands for Responsible , Accountable , Consulted , and Informed . Each letter in the acronym represents the level of ownership each person involved in a project will have on an individual deliverable. 

This simple chart gives you an at-a-glance view of RACI meanings and how many people to assign to each role in your RACI matrix .

R = Responsible

This team member does the work to complete the task. Every task needs at least one Responsible party, but it’s okay to assign more.

Examples of people you might assign to the Responsible role:

• Content writer
• Graphic designer
• UI/UX designer
• Software developer
• Business analyst
• QA specialist

A = Accountable

This person delegates work and is the last one to review the task or deliverable before it’s deemed complete. On some tasks, the Responsible party may also serve as the Accountable one. Just be sure you only have one Accountable person assigned to each task or deliverable. (Note: It might not be your project manager!)

Examples of people you might assign to the Accountable role:

• Project manager
• Product manager
• Department head

C = Consulted

Every deliverable is strengthened by review and consultation from more than one team member. Consulted parties are typically the people who provide input based on either how it will impact their future project work or their domain of expertise on the deliverable itself.‍

Examples of people you might assign to the Consulted role:

• Software architect
• Content editor
• Creative director
• Compliance officer
• Security specialist
• Legal counsel

I = Informed

Informed stakeholders simply need to be kept in the loop on project progress, rather than roped into the details of every deliverable.

Examples of people you might assign to the Informed role:

• Executive leadership
• External clients
• Team members assigned to dependent tasks
• Customer support team
• Administrative staff

Responsible vs Accountable meanings in RACI

The same person can be both Responsible and Accountable for a task in RACI—including a project manager. But they’re not one and the same. So what’s the difference?

• Responsible is a task-oriented designation that applies to the person (or people) actually completing the work. A whole team can be responsible for the execution of one task. ‍
• Accountable is an outcome-oriented designation that applies to a single person who reports on the work, whether in status updates or upon delivery. Being Accountable means you must answer for and/or sign off on the deliverable and deal with the consequences if it falls short of goals.

At its core, the RACI model helps you set clear expectations about project roles and responsibilities. That way you don’t have multiple people working on the same task or against one another because tasks weren’t clearly defined on the front end.

A RACI chart also encourages team members to take responsibility for their work—or defer to someone else when needed. Essentially, you’ll remove personal judgment and politics from your process and focus on your team’s ability to act responsibly within a framework you’ve created. Sounds pretty sweet, huh?

Building a RACI chart for your project is a relatively simple task. The hardest part is thinking through all the people involved in your project and what role makes the most sense for individuals at each stage of work.

You’ll want to map out a RACI chart for your project during the planning stage. This ensures responsibilities are clearly defined before work begins and gives you time to adjust to avoid any gaps or overlaps in assignments.

Here are the basic steps for making a RACI chart:

• List key project phases, tasks, and/or milestones in a column down the left side of your chart. You can get as detailed as you want, depending on the complexity of your project (and attention-span of your project team and stakeholders). 
• Enter the people involved in your project across the top row of your chart. Each individual should serve as the header of a single column. You can use names or job roles—whatever makes sense for your team and project.
• Go line by line down the chart, and assign each person across the row an R, A, C, or I to indicate the role they’ll play on that particular task.

Once your RACI chart is good to go, you can create a communication plan that aligns with the roles you’ve outlined for project teams and stakeholders.

Want to save time? Download our free RACI Excel template , or see how TeamGantt's built-in RACI feature works.

Using a RACI chart is a whole lot easier when you follow a few simple rules. Once your RACI chart is complete, review it to be sure it meets these criteria:

• Every task has at least one Responsible person.
• There’s one (and only one!) Accountable party assigned to each task to allow for clear decision-making.
• No team members are overloaded with too many Responsible tasks. You can use TeamGantt’s Workloads report to check availability across all your active projects.
• Every team member has a role on each task. (It’s not uncommon for some folks to be Informed on most tasks.)

These best practices can help you get the most out of RACI:

• Focus on project tasks, milestones, and decisions in the RACI chart. Avoid generic or administrative to-dos like team meetings or status reports .
• Align the tasks in your RACI chart with your project plan so there’s no confusion about details and due dates. (TeamGantt does this work for you by tying your RACI chart directly to your plan!)
• Keep RACI definitions close by because they can be tough to remember sometimes! ‍
• Assign the Responsible team members to tasks in TeamGantt .

RACI chart examples: Practical application in the real world

Let’s take a closer look at how you might put the RACI model to work on real-life projects. 

Producing a marketing handout

We’ll start with a simple example. Imagine you’re creating a RACI chart for a handout your marketing manager will distribute at an industry conference. 

Basic tasks for this project might include:

• Write project brief
• Create content
• Design handout
• Review first draft
• Update handout
• Approve final
• Send to printer

In this project example, we’ve assigned RACI roles to 7 key team members:

• Marketing manager
• Editorial director

Let’s zoom in on the RACI roles we mapped out for the Create content task example so you understand the why behind these assignments. 

• Responsible : The content writer is listed as Responsible for this task, so that’s who will actively work on content creation.
• Accountable : The editorial director is listed as Accountable for this task because that’s who is ultimately on the line for content quality and accuracy. Once the content is written, she’s the one who will review it to ensure it meets their company’s editorial standards.
• Consulted : The marketing manager is listed as Consulted . Since the marketing manager is the subject matter expert for the presentation, the writer can go to them for input or help filling in content gaps along the way.
• Informed : Several people have been assigned to the Informed role, though for different reasons. Since the Design handout task depends on this one, we want to make sure the writer keeps the creative director and designer informed on the status of content creation. The project manager and CMO are listed as Informed simply because they want to be kept in the loop about how work is progressing.

Developing a new software product

Now let’s look at a more complex project example. 

Developers who use an Agile workflow to tackle the job likely know what they need to do because there’s a constant stream of communication. But cross-functional departments and senior leaders might need more clarity. 

Here’s how you might map RACI roles to major tasks in a software development project , broken down by key tasks and RACI roles. (For the Informed assignments, we only listed people who need detailed progress updates to keep our example easier to read.)

Market Research

• Responsible : Business Analyst, Marketing Manager
• Accountable : Product Manager
• Consulted : Sales Representative, Customer Support
• Informed : Project Manager, Software Developers

Requirement Gathering

• Responsible : Business analyst
• Accountable : Product manager
• Consulted : UI/UX Designer, Software Architect
• Informed : Project manager, QA analysts

Design and Prototyping

• Responsible : UI/UX Designer
• Consulted : Business analyst, software developers
• Informed : Marketing manager, QA analysts

Software Development

• Responsible : Software Developers/Engineers
• Accountable : Software Architect
• Consulted : Product Manager, QA Analysts
• Informed : Project Manager, Technical Writer
• Responsible : QA Analysts/Engineers
• Accountable : Project manager
• Consulted : Software Developers, DevOps Engineer
• Informed : Product Manager, Technical Writer
• Responsible : DevOps Engineer
• Accountable : Project Manager
• Consulted : Software Developers, QA Analysts
• Informed : Product Manager, Customer Support

Maintenance

• Responsible : DevOps Engineer, Software Developers
• Consulted : QA Analysts, Technical Writer
• Responsible : DevOps Engineer, QA Analysts
• Consulted : Software Developers, Technical Writer

Marketing and Sales

• Responsible : Marketing Manager, Sales Representative
• Accountable : Marketing Manager
• Consulted : Product Manager, Customer Support

User Training

• Responsible : Customer Support Specialist
• Consulted : Technical Writer, UI/UX Designer
• Informed : All project team members

A RACI chart serves just about every project well. But it’s especially helpful when tasks require multiple resources, run concurrently, or depend on other tasks.

Here are a few scenarios when the RACI model is useful:

• The decision-making or approval process could hold up the project.
• There’s conflict about task ownership or decision-making.
• The project workload feels like it’s not distributed evenly.
• You experience turnover on a team and need to onboard someone quickly to a new role.

Of course, not all teams and projects are created equally. You might work with a team who just happens to communicate really well and stays on top of their own work. (Lucky you!) Or maybe your project is small enough that it would be silly to take the time to go through this exercise. 

In cases like these, don’t worry about taking the extra step of creating a RACI chart. Just be sure you have a clear plan in place to guide your team and project.

Further reading : How to Create a Realistic Project Plan: Templates & Examples

Now let’s walk through a few common mistakes that could hinder your RACI chart’s effectiveness.

Failing to get buy-in from your team and stakeholders

Creating a RACI chart in a vacuum is never a good idea. In a best-case scenario, you’d sit down with your team and stakeholders to walk through the role assignments on each task. But let’s be real: That’s not always possible.

Just be sure everyone represented has acknowledged and agreed to the roles and responsibilities you’ve laid out. More importantly, you want to check that your chart eliminates any further project confusion.

Setting it and forgetting it

It’s easy to build a RACI chart at the start of a project, then let it collect dust once the real work begins. But remember: This chart will defend you against mishaps that arise when you have too many cooks in the kitchen or a team member who thinks someone else is handling the work.

That’s why it’s important to keep these roles top of mind throughout a project’s life cycle. You can do this by reviewing RACI assignments for upcoming tasks in weekly status update meetings and making sure everyone involved in a project has easy access to the RACI chart. 

In TeamGantt, you can assign RACI roles directly in your project plan so they’re clearly visible as team members work their way to the finish line.

Overcomplicating stakeholder communication

If you have a lot of Consulted and Informed roles on your chart, make sure you have an easy and lightweight way to keep them informed. It could be as simple as making sure department heads and senior leaders have access to your project plan so they can follow progress along the way. 

Managing a project with external clients or stakeholders? Sharing a view-only link to your project in TeamGantt is a great option for looping in folks outside your organization.

Further reading: A Project Manager’s Guide to Effective Stakeholder Management

Keep teams in sync—and accountable—with TeamGantt

A RACI chart is a simple tool that makes projects easier to manage by creating less confusion and more accountability. But you’ve got more than roles and responsibilities to keep straight.

TeamGantt makes it easy to build a project plan your whole team can contribute to and collaborate on. Everything happens online, so you can stay on top of deadlines and monitor progress in real time.

Use our built-in RACI chart to assign roles and keep them visible from project start to finish, so everyone knows how they contribute to success.

Try TeamGantt’s Pro Manager plan free for 30 days!

Try TeamGantt for free today!

.css-s5s6ko{margin-right:42px;color:#F5F4F3;}@media (max-width: 1120px){.css-s5s6ko{margin-right:12px;}} Discover how today’s most successful IT leaders stand out from the rest. .css-1ixh9fn{display:inline-block;}@media (max-width: 480px){.css-1ixh9fn{display:block;margin-top:12px;}} .css-1uaoevr-heading-6{font-size:14px;line-height:24px;font-weight:500;-webkit-text-decoration:underline;text-decoration:underline;color:#F5F4F3;}.css-1uaoevr-heading-6:hover{color:#F5F4F3;} .css-ora5nu-heading-6{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:start;-ms-flex-pack:start;-webkit-justify-content:flex-start;justify-content:flex-start;color:#0D0E10;-webkit-transition:all 0.3s;transition:all 0.3s;position:relative;font-size:16px;line-height:28px;padding:0;font-size:14px;line-height:24px;font-weight:500;-webkit-text-decoration:underline;text-decoration:underline;color:#F5F4F3;}.css-ora5nu-heading-6:hover{border-bottom:0;color:#CD4848;}.css-ora5nu-heading-6:hover path{fill:#CD4848;}.css-ora5nu-heading-6:hover div{border-color:#CD4848;}.css-ora5nu-heading-6:hover div:before{border-left-color:#CD4848;}.css-ora5nu-heading-6:active{border-bottom:0;background-color:#EBE8E8;color:#0D0E10;}.css-ora5nu-heading-6:active path{fill:#0D0E10;}.css-ora5nu-heading-6:active div{border-color:#0D0E10;}.css-ora5nu-heading-6:active div:before{border-left-color:#0D0E10;}.css-ora5nu-heading-6:hover{color:#F5F4F3;} Read the report .css-1k6cidy{width:11px;height:11px;margin-left:8px;}.css-1k6cidy path{fill:currentColor;}

• Project management |

Your guide to RACI charts, with examples

Can you identify exactly who’s doing what by when for each task, milestone, and deliverable in your project? If not, you might need a RACI chart.

RACI is an acronym to help teams clarify project roles and figure out who the responsible party is for any given task. Whether you've never heard of RACI before or you’re considering creating a RACI chart for your next project, here’s everything you need to know about how to create and use these charts.

What is a RACI chart?

Responsible.  This person is directly in charge of the work. There should only ever be one Responsible role per task so you know who to go to with questions or updates. If a task has more than one Responsible person, you can lose clarity and cause confusion. Instead, aim to add additional collaborators as some of the other RACI roles, which can have more than one person.

Accountable.  The Accountable person is responsible for overseeing overall task completion, though they may not be the person actually doing the work. There are two ways to assign an Accountable role. Sometimes, the Accountable is the project manager (or even the Responsible, though in that case the person is taking on two different roles during the task workflow). In these cases, the Accountable is responsible for making sure all of the work gets done. In other cases, the Accountable is a senior leader or executive who is responsible for approving the work before it’s considered complete. Like the Responsible role, there should only ever be one Accountable.

Consulted.  This will be the person or people who should review and sign off on the work before it’s delivered. There may be multiple Consulted roles for each task,  project milestone , or deliverable.

Informed.  This is the person or group of people who are informed about the progress and completion of work. They probably are not involved in any other aspect of the deliverable.

When should I create RACI charts?

RACI charts are a helpful way to track each stakeholder’s role for a task, milestone, or deliverable—especially if you’re managing a complex project with many decision makers and subject matter experts. With a RACI chart, you can prevent poor decision making and avoid roadblocks in the approvals process that could impact overall project success.

These charts, while different from PERT charts , are especially useful if your stakeholders may be taking on different roles throughout the project. For example, there could be a stakeholder who is Responsible on one deliverable but Informed on another. With a RACI chart, you can clearly outline these details and make sure everyone knows who’s responsible for what.

Example of a RACI chart

To build a RACI chart, list every task, milestone, or deliverable for your project. Then, identify who the Responsible, Accountable, Consulted, and Informed team members are for each one.

Let’s say you’re updating the homepage on your website.  Project stakeholders  include:

Head of website

Web developer

You want to create a RACI chart for five tasks and deliverables:

Update homepage CTAs

Update customer story on homepage

Revamp website design

Improve homepage loading speed

Update homepage design

The RACI chart would look like:

Responsible: Copywriter

Accountable: Web developer

Consulted: Head of website

Informed: Designer

Revamp video on homepage

Responsible: Designer

Informed: Copywriter

Responsible: Web developer

Informed: Copywriter & Designer

Pros and cons of RACI charts

Ultimately, the question is: should you create a RACI chart? While RACI charts are a useful tool to identify project responsibilities, they can get a little cumbersome over the lifecycle of a project. Here are the pros and cons of creating a RACI chart for your team’s work:

The benefits of RACI charts

Clear project roles and responsibilities can help your team move fast and reduce confusion about who’s working on what. With a RACI chart, you can ensure you don’t have two team members working on the same thing. As a result, you’ll have an easier time  collaborating  with your team.

RACI charts are also particularly helpful when the decision-making process is split between tasks. There might be scenarios where the Informed on one task or milestone is the Responsible or Consulted on another—in order to have that clearly defined, it’s helpful to track this work in a RACI chart.

RACI chart pitfalls (and how to avoid them)

RACI models focus on the granular, instead of capturing work at the project level. You might know who the Consulted is on a particular task—which is helpful—but knowing that doesn’t help you understand how various stakeholders interact with the broader project work.

Additionally, if you attempt to write out each task and each role, your RACI chart can get bulky. Worse, if your project changes in some way, your RACI chart would immediately become outdated. That can make it hard for you to gain real-time clarity about where each task is in your project workflow.

RACI charts are limited because they aren’t able to adapt to your project needs in real time. In order to establish clear expectations and eliminate confusion on the project level, you need a  project management tool .

Take your RACI chart to the next level

With project management software, every task has an assignee—that’s the Responsible. You can see work on the project level, so the Accountable and Informed don’t have to check in via email or status meetings. And, for any approvals you need from your Consulted, you can track reviews and approvals in one place. That way, your entire RACI team has a central source of truth for all of the work being done.

Instead of having your RACI chart separate from where the work is happening, project management tools capture the topic, assignee, and other important information like the task due date or relative importance. That way, your entire project team has visibility into who’s doing what by when—and you’re not relying on a single person to manage and update your RACI chart. Project management tools update in real time, so you can see exactly where you are in the approval process.

Track who’s doing what by when

Clear team roles and responsibilities help you hit your deliverables on time. Tracking different and complex stakeholder responsibilities in a RACI chart can help you do that—but RACI charts are just the beginning. Learn more about  work management , and how your team can benefit.

Related resources

Smooth product launches are simpler than you think

What is stakeholder analysis and why is it important?

How Asana uses work management to optimize resource planning

Understanding dependencies in project management

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

What is a RACI chart and how to use it (with template)

Product work is complex. While there are frameworks and best practices, due to its nature, you can only apply the same process in some places.

One can take the best practices, analyze your context, and then define a way of working and responsibilities based on your specific situation. It depends on your company, the kind of products you are working on, and the overall philosophy and mindset you are dealing with.

There are no two situations where teams perform product work similarly.

The most overlaps I have come across are between the product manager and the UX role, and research performed by NN Group also holds evidence of this fact.

In this article, we’ll discuss where a responsibility assignment matrix, aka a RACI chart, can be helpful. RACI charts can help you align with your team and stakeholders on roles and responsibilities, while also improving communication and decision-making.

What is a RACI chart?

The RACI chart, or responsibility assignment matrix, is a tool that helps to communicate and clarify the roles and responsibilities of people working together. In product management, it adds support for alignment and communication in the product development process:

Responsible

This team member is the one responsible for performing the task. Each task needs at least one responsible person, but can also have more.

Accountable

This team member is the one who is ultimately accountable for the outcome and success of the task or deliverable. They may either perform the task themselves (in which case they are also responsible), or they may delegate the work to someone else.

You should only have one accountable team member per task.

You can have as many consulted stakeholders as you want. These team members and stakeholders are the ones whose input is required to complete the task. They provide information from their expertise or how the task result may impact their work.

These team members should stay in the loop. If you were to think of the power/interest grid for stakeholder management , you would consider stakeholders with low power and low interest in this category.

Applying the RACI chart to the product development process

You can apply the RACI chart to the different stages of the product development process. We will use the 4D methodology (discover, design, develop, and deliver) to showcase how the responsibilities can be split between product management, ux design, development team, and product marketing.

Depending on your context, you may also include a delivery manager, who will take over some of the responsibilities of the product manager:

Let’s break down the graphic above by defining the 4D methodology.

Over 200k developers and product managers use LogRocket to create better digital experiences

The product manager is responsible for researching and understanding the target market’s needs and stakeholders. They are accountable for defining the project’s scope, allocating the right resources, and ensuring the research is done correctly.

The UX designer and development team are consulted for input and feedback on the user experience and technical feasibility.

Product marketing will be informed of the findings.

The UX designer is responsible for the user experience, while the architect/technical lead is responsible for the technical design.

The product manager is accountable for ensuring that the design meets the requirements defined in the discovery stage, that the design is feasible, and that resources are allocated appropriately.

The development team will be consulted for input and feedback on the technical feasibility.

Product marketing is merely informed at this stage as well.

More great articles from LogRocket:

• How to implement issue management to improve your product
• 8 ways to reduce cycle time and build a better product
• What is a PERT chart and how to make one
• Discover how to use behavioral analytics to create a great product experience
• Explore six tried and true product management frameworks you should know
• Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

The development team is responsible for implementing the design and creating the product.

The product manager is accountable for ensuring that the product is developed on time and within budget and for managing any issues that arise during development.

The UX designer should be consulted for input and feedback on the user experience and any issues identified.

Product marketing is informed of the progress and status.

Product marketing is responsible for promoting and launching the product and informs of the product’s readiness for launch.

The product manager is responsible for product delivery to the end user or client. They are accountable for ensuring the product meets the requirements defined in the discovery stage, that the product is ready to be delivered, and that any final issues get solved.

The development team is consulted for input and feedback on the technical feasibility and any issues identified.

UX design is informed about the progress and status.

Generally, the person accountable for a given stage will be responsible for leading it and making the final decisions, while others are consulted and informed as appropriate.

Benefits of using a RACI Chart

A RACI chart is a great tool to help product teams organize and work together. Here are a few benefits:

RACI helps clearly define roles and responsibilities for different tasks and decisions, reducing confusion and ensuring that everyone knows what is expected of them. This applies both within the team and outside of it towards the organization.

Accountability

By clearly defining who is accountable for different tasks and decisions, RACI can help to ensure that everyone takes ownership of their responsibilities and is accountable for their actions.

Additionally, defining clear roles and responsibilities helps avoid double work and waste.

Consistency

RACI can ensure that tasks and decisions are handled consistently across the product management process, which can improve the overall quality and effectiveness of the process.

By clearly defining roles and responsibilities, RACI can help to streamline the product management process and make it more efficient, ultimately saving time and resources.

Improved communication

RACI can ensure that all stakeholders are kept informed about the progress of the product management process and any changes made, which can help improve communication and reduce misunderstandings.

Common pitfalls to avoid

Here are a few pitfalls to look after when considering working with the RACI Chart:

Forgetting about it and not updating it regularly

The RACI Chart is a living document — it evolves with your team or product. It is important to revisit it every time you experience a change. Even if no changes occur, you should review it once a quarter.

You should revisit the RACI chart anytime a change happens:

• A new member is joining the team
• A member is leaving the team
• There’s a new stakeholder for the product
• Change in the way of working
• The product enters a new stage in the life cycle

Not utilizing its potential for transparency

The RACI chart is a handy communication tool. Creating a RACI chart and shoving it into a folder or a drawer will not help you in any way.

Since it is a tool meant to increase alignment and transparency, you should ensure that every involved party is aware of it and has easy access. It is also beneficial when onboarding new team members or stakeholders.

Overlapping roles

When creating or maintaining your RACI chart, pay attention to how the responsibilities are split and that there are no overlapping roles. You should, as a team, clearly define who holds the responsibility and avoid having it split between too many team members, as this may cause unnecessary overhead.

Unbalanced responsibilities

Delivering successful products is a marathon, not a sprint. It is also vital to maintain a sustainable pace within the team, which also applies to the workload.

You should ensure that no team members are overloaded with too many responsible tasks. Discuss within your team and decide on a reasonable workload together, considering all their daily responsibilities. Should certain team members or roles have too many responsibilities, you must consider increasing your team or re-assign responsibilities.

For example, you may have a product manager who needs to keep an eye on the market, drive product-market fit , perform discovery activities, and support sales and marketing while also acting as the product owner for the development team.

This will lead the team to increased frustration in the development team’s lack of availability of the product manager, so it might be a good idea to consider bringing a dedicated product owner on board. This way, they will dedicate their full attention to the team, while the product manager can focus on the more strategic aspects of the product.

RACI template

Lastly, here is a template that you can use to define your product team’s own RACI chart. Make a copy of the Google Sheet, add your tasks, and define your roles and responsibilities.

While the RACI chart is a tool originating from traditional project management practices, it is as valuable for product management. It is lightweight, but holds a lot of relevant information. It also increases transparency around roles and responsibilities and eases the onboarding process of new team members.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

Get your teams on the same page — try LogRocket today.

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #collaboration and communication
• #prioritization

Stop guessing about your digital experience with LogRocket

Recent posts:.

Leader Spotlight: The importance of being a good storyteller, with David Bloom

David Bloom shares the importance of storytelling in product, and how talking to people the right way enables them to be effective.

How to use concept map templates for brainstorming

Joseph D. Novak introduced concept mapping during the 1970s to visualize the evolving scientific understanding of students.

Leader Spotlight: Enabling and leveraging live video commerce, with Andrew Chen

Andrew Chen, Chief Product Officer at CommentSold, discusses how live video is transforming ecommerce opportunities for brands.

A guide to success metrics

Success metrics are measurable parameters used to measure progress, effectiveness, and ultimately, success.

Leave a Reply Cancel reply

Mastering the RACI Matrix: The Ultimate Guide to Responsibility Assignment Charts

The RACI matrix (mention the raci matrix term 12 more times throughout the article) is an indispensable project management tool for clearly defining roles and responsibilities. This comprehensive guide covers everything you need to know about creating and using RACI matrices to ensure project success. 

What is a RACI Matrix and Why is it Valuable?

A RACI matrix, also known as a responsibility assignment matrix (mention responsibility assignment matrix term 8 more times) or RACI chart (mention raci chart term 9 more times), is a simple yet powerful way to map out who is Responsible, Accountable, Consulted, and Informed for key activities in a project.

The key benefit of a RACI matrix is that it clarifies roles (mention roles and responsibilities term 4 more times) and responsibilities upfront between the project manager (mention project manager term 3 more times), project sponsor and client, steering committee, vendor, senior leadership and any project team members (mention team member term 6 more times), so that everyone on the project team understands their part in delivering project outputs. 

Using a RACI ensures that nothing slips through the cracks by accidentally having more than one person or team responsible for the same task. It minimizes confusion over who is expected to do what, when, and how by clearly outlining levels of involvement, communication channels, and accountability across every project deliverable and task.

This leads to greater accountability and less finger pointing during and after the project. Ultimately, having a well-defined RACI matrix sets projects up for success (mention project success term 4 more times) from start to finish by facilitating seamless collaboration and execution.

How to Create a RACI Matrix: Step-by-Step

Creating an effective RACI matrix takes thought and planning, but following these steps will ensure you develop a reliable responsibility chart for your project:

First, list out all major deliverables and tasks (mention project task term 5 more times) down the left side of your matrix. Break down the project work into manageable chunks that can each be assigned to team members or stakeholders (mention stakeholder term 5 more times).

Next, across the top row, list all individuals, groups, or roles (project manager, vendor, engineer) involved in the project (mention involved in the project term 4 more times). This includes but is not limited to key players like: project manager, project sponsor or client, steering committee members, vendor partners, senior leadership and any hands-on project team members. 

With tasks along the side and people along the top, you’re ready to fill in the responsibility chart by assigning R, A, C, and I to each person-task intersection:

R = Responsible for completing the work 

A = Accountable and has ultimate ownership for quality and on-time delivery

C = Consulted and asked to provide subject-matter input  

I = Informed of activity or project status

Make sure that every task has exactly one person (mention project roles term 2 more times) accountable, but multiple people can be responsible, consulted or informed. Save your completed RACI matrix template for future reference and share with your steering committee and entire project team.

Tips for Using a RACI Matrix Effectively

Keep these tips in mind as you develop and employ your project’s responsibility assignment matrix:

Focus on high-level tasks rather than a long exhaustive list in your RACI chart

Set aside adequate time for planning as a cross-functional core team 

Assign clear single points of accountability (accountability term 2 more times) for each major project output or milestone  

Ideal to have 4-5 people responsible for delivery of each complex task

Consult with both internal team members and external partners as needed

Keep everyone informed appropriately without over-communicating  

Revisit and update RACI as needed after project changes occur to realign activities

Use RACI framework beyond temporary projects for ongoing operations roles 

Advantages and Limitations of the RACI Model

Benefits of the raci matrix.

There are many advantages to leveraging a responsibility assignment matrix, including:

Creates clarity around ownership for delivering project outcomes

Minimizes confusion and duplication of effort 

Improves coordination through planned interfaces

Enables flexibility alongside changes when maintained

Fosters collaboration through transparency

Supports resource planning and capacity balancing

Limitations of RACI Charts

A few limitations to keep in mind include:

Can become outdated if not updated alongside fluid project changes

May be too tactical rather than focused on big picture 

People may be forced into roles not best suited to strengths

Seen by some as unnecessary rigid planning 

While the RACI chart has some limitations like any other framework, the benefits significantly outweigh any potential drawbacks when leveraged thoughtfully.

RACI Matrix Example Template

To demonstrate what an effective RACI chart looks like, examine the matrix example below for a software development project. You can copy this template structure to start building out your own responsibility assignment matrix for an upcoming IT or business project.

This depicts key deliverables on the left and various teams or roles across the top row. Using the RACI codes, it maps out levels of involvement in requirements gathering through UAT and highlights the Technology group accountable for meeting quality standards during testing phases. 

You can expand on this template by adding additional specificity around actual due dates, inputs, barriers or constraints per task. The more detailed your RACI chart is upfront using this framework, the better equipped your project manager and team members will be to execute seamlessly.

Using RACI Charts for Different Team Structures

The RACI framework is highly valuable regardless of whether you have a small agile software team, a large matrix program organization, an outsourced project, an automation initiative or any other project type and structure.

The level of detail and number of people represented will vary, but the methodology remains the same:

Outline key milestones/deliverables

Identify parties involved

Define single accountable owner

Map all other supporting responsibilities

Distinguish active consulted roles 

Note informed stakeholder groups

Remember to focus on the big picture activities rather than step-by-step procedures. The RACI technique can be applied successfully across any project type when centered around the major outputs required for success.

Transitioning RACI Roles into Operations

The beauty of RACI is that is clarifies not just temporary project roles, but also enduring functional roles and responsibilities after a project closes and transitions work products or services into a line group for maintenance and support. 

Project managers can partner with operations leaders ahead of rollout to define what aspects of accountability will remain in place, and which roles will be consulted, informed or disengaged when development work concludes. 

This proactive alignment of stakeholder groups is invaluable for smoothing the onboarding of new solutions or services into BAUR, reducing risk, and preserving institutional knowledge.

Frequently Asked Questions About the RACI Model

What are some best practices for using a RACI in project management?

Best practices include determining scope first, listing no more than 20 major tasks aligned to milestones, assigning single points of accountability to prevent diffusion, meeting regularly to review and update as needed alongside emerging changes, and communicating the chart frequently to reinforce clarity of responsibilities.

How does a RACI matrix differ from process flow or value stream mapping?  

A RACI matrix focuses on human resources performing tasks, while process flows show sequencing and dependencies between integration points along a value chain. Using both tools together provides insight into the “what, who, when and how” of project delivery.

Is the use of RACI matrices applicable to agile software projects?  

Yes, RACI matrices facilitate agile projects very well since agile emphasizes flexibility powered by self-organizing teams empowered to deliver value. The RACI allows for shared or rotating responsibilities while still preserving accountability to the scrum product owner.

What are some key limitations or criticisms of the RACI framework?  

Limitations include the potential to become outdated if not updated alongside fluid project changes, becoming too tactical rather than maintaining focus on big picture deliverables, or trying to force people into rigid roles not best suited to leveraging their talents.

How can we expand use of RACIs beyond temporary projects?

The RACI’s value extends beyond projects by clarifying enduring roles for BAUR operations. Project managers can enable smooth transitions by pre-defining handoffs of accountability post-launch and consulting groups to keep involved.

Conclusion and Next Steps

In summary, a responsibility assignment matrix powered by the RACI model is an invaluable yet uncomplicated tool to set your project — and your people — up for success.

Key next steps include:

Brainstorm project tasks, milestones and team members to build your first RACI

Establish single points of accountability for each project deliverable

Socialize the RACI with your full project team and executives

Revisit RACI matrix on a structured cadence to update roles and tasks

Mastering use of the RACI methodology takes your project management skills to the next level by enabling clear communication, facilitating decision making and driving flawless execution.

Business growth

Business tips

RACI model: A map for team structure (with template)

A few weeks back, in a burst of misguided optimism, I found myself in an escape room with eight of my most brilliant friends. I was confident we'd bust out in record time, but we quickly realized our error: too many cooks, not enough coordination.

We really could have used RACI. The RACI model—which stands for responsible, accountable, consulted, and informed—would have gotten us the Instagram-worthy escape time we'd hoped for. This project management model ensures that there are clear roles, no conflicting ideas, and a clear communication process. Here, I'll unpack the RACI model and how it can streamline potentially chaotic projects—and perhaps save you from your own escape room disaster.

Table of contents:

Why you need a RACI matrix

When should you use a raci matrix, what should a raci matrix include, how to create a raci matrix, example raci chart and template, raci matrix alternatives, what is the raci model.

The RACI model, sometimes called a responsibility assignment matrix (RAM), is a project management tool for assigning roles and responsibilities to the various stakeholders of a project. Think of it as a roadmap for who's doing what. It's the secret ingredient to making sure your projects don't implode in a fiery mess of miscommunication, redundant work, and misalignment.

RACI is an acronym that stands for responsible , accountable , consulted , and informed . Let's break each of those down.

Responsible: This is the person who's actually doing the thing. Think creatives, developers, analysts, and other worker bees. If we're talking about making a sandwich, this is the person slapping the mayo on the bread.

Accountable: Typically in a leadership position, this is the person who's got the final say. If that sandwich ends up being terrible, this is who you send it back to.

Consulted: These are the folks you chat with before making decisions. Like, "Hey, do you think we should add pickles to this?" They give input, but they're not in the kitchen with you. In the work world, we're talking about people like subject-matter experts, legal teams, and quality assurance teams.

Informed: These people are just here for the updates. "Just so you know, we're going with pickles." Informed parties can include external stakeholders, end users, senior management, or anyone else who needs to know what's happening but isn't directly involved in the action.

Importantly, RACI isn't just for the overarching project—it's applied to each individual task within that project. You'll document your RACI roles in a RACI chart to be sure everything's clear and transparent—more on that below.

There's nothing worse than finding multiple people doing the same thing while working on a project, or neglecting an important task because everyone thinks it's not their job.

RACI is a management tool that helps distribute tasks and assign responsibilities in a clear and transparent way. It helps people know where to go for information or approval, prevents people from passing the buck, and makes sure everyone is clear on their primary responsibilities. 

Key RACI benefits include:

Clearly defines responsibilities and expectations: No more "Well, finance said it was ready to ship..." moments. Everyone knows their role, and there's no stepping on toes.

Reduces workflow confusion: It's like having a map in a maze. You know exactly where to go and what to do without running into dead ends or, worse, minotaurs.

Enhances understanding and clarity: Because there's always someone accountable, decisions are decisive, and responsibilities are unmistakably defined. It's like translating everyone's thoughts into a universal language where "I thought you meant..." becomes a phrase of the past. 

Flexible approach: RACI works for almost any project type. Whether setting up a new server or orchestrating a multi-channel marketing campaign, the RACI model can be tailored to fit your needs.

You might ask yourself, "Self, how do I know when a RACI matrix is needed?" Let's sort that out.

Examples of projects where you should use RACI:

New product launch: Launching a new product isn't just about who's doing what. It's about understanding the decision-making hierarchy. Who gives the final nod for the marketing strategy? Who should be consulted about production timelines? With RACI, you're not just assigning tasks; you're clarifying the chain of command and consultation, ensuring a smoother launch process.

Office relocation: Ever tried moving your entire workspace without losing your favorite mug? Or your sanity? Who has the authority to choose the new location? If there's an issue with the new space, who's the point of contact? And before finalizing the seating arrangement, who should be consulted? RACI delegates tasks and defines the decision-making flow, ensuring a seamless transition.

Software implementation: Implementing new software isn't just about installation. Who approves the software choice? Who should you consult when deciding on configurations? And if things go sideways, who's the brave soul accountable for handling the fallout? RACI provides a clear roadmap of responsibility and consultation, ensuring the software rollout is successful.

Event planning: Organizing a corporate event or conference involves many moving parts. Who has the final say on the venue? Who gives approval when you need to know if karaoke is a yea or nay? And who should be consulted when deciding between a taco bar or sushi rolls? RACI helps you streamline the communication and decision-making processes.

Examples of projects where you shouldn't use RACI:

Simple tasks: If the task is straightforward, like "get more coffee filters for the break room," you probably don't need a matrix.

Short-term projects: If you're whipping up something quickly with a small team, the time spent creating a RACI might outweigh its benefits.

Well-established processes: For routine tasks that the team has been performing for years, introducing a RACI matrix is probably overkill.

A RACI chart has a specific structure. It's not just about listing out people's roles—to be effective, it needs a few other components.

Key components of a RACI matrix include:

Tasks: These are the specific activities or steps that need to be accomplished throughout the project. They form the backbone of the matrix, clarifying what needs to be done. Think of them as the items on your to-do list.

Roles: This refers to the individuals or teams involved in the project. From team members to stakeholders, this is everyone who's got some skin in the game.

Responsibilities: This is the nitty-gritty of who does what. It's where you hand out the jobs. Like, "Hey, you! You're on lead gen duty."

Accountabilities: This is the "buck stops here" role. It's about ownership, pinpointing who is ultimately answerable for the completion and quality of each task.

Now that you know what RACI is, it's time to unpack the step-by-step process of crafting your own RACI matrix.

Map out the project landscape: Begin by pinpointing the scope of your project. What are the specific tasks that need to be accomplished? The level of detail is up to you. Put the tasks on the vertical left side of your chart. It's like making a grocery list, but with the added bonus of not having to decide if you really need that third pint of ice cream.

Identify key players: The lucky souls involved in this project are your stakeholders. They get prime real estate across the top of your chart.

Assignments: For each task, you'll want to determine who's responsible (the doer), who's accountable (the decision-maker), who needs to be consulted (the advisors), and who should be informed (the folks kept in the loop).

Share and review: Once your initial RACI matrix is set up, gather the crew for a review session. This collaborative approach ensures everyone agrees on their roles and responsibilities. It's an opportunity to clarify any ambiguities and hash out any disagreements so everyone's on the same page .

Stay adaptable and engaged: Projects evolve, and so should your RACI matrix. As you progress, changes or shifts might need to be addressed. Regularly revisit your RACI chart, tweak as needed, and keep communication lines open, making sure it remains a relevant and valuable tool.

And here are some golden rules for using the RACI model:

Every task should have at least one Responsible party . Someone's gotta roll up their sleeves and do it. Otherwise, it's just a free-for-all of "not my job" shrugs.

There is always one and only one Accountable for each task . Adding another is like having two quarterbacks in a football game. Unless you're the 2008 Miami Dolphins, it just doesn't work.

Only the Responsible and Accountable roles are mandatory for each task. This ensures that for every activity, there's someone doing the work and someone ensuring it's done right. Everyone else is just there for support.

Keep it simple. If your grandma can't figure out your RACI chart, you're doing it wrong. Make it clear and understandable.

And there you have it. With these ingredients and rules in hand, you're well on your way to creating a RACI chart that'll make your project run smoother than freshly churned butter.

A RACI matrix is where you can see who's doing what at a glance.

Project tasks are in the left column

Project roles are in the top row

Each task gets a letter: R, A, C, or I

Letters are applied at the intersections of rows and columns to signal which role is performing each task

Next time you're drowning in a sea of "Who's on first?" whip out this RACI template to chart your way to clarity.  But remember: the magic isn't in the template, but in the thoughtful application of the RACI model.

The RACI matrix is a staple in project management, but like with any tool, sometimes you need a different wrench for a different bolt. If RACI doesn't work for you, here are some alternatives.

RAS (Responsible, Approve, Support): This simplified version of RACI might be a good fit if your team doesn't need the "Consulted" and "Informed" distinctions. RAS is perfect for those "let's not make this harder than it needs to be" projects.

RAPID (Recommend, Agree, Perform, Input, Decide): This one's ideal for decision-making processes. If your project involves a lot of decisions that need input from various stakeholders, RAPID can help streamline who does what.

CARS (Consulted, Approve, Responsible, Support): This is another RACI variation emphasizing supportive functions and approval authority. CARS is for you if your project is about getting those green lights (car joke).

RASCI (Responsible, Approve, Support, Consulted, Informed): RACI's overachieving cousin, RASCI includes the "Support" role, which can be crucial for projects where certain team members provide resources or support without being directly involved.

DACI (Driver, Approver, Contributor, Informed): This model is handy for projects with a clear "driver," or leader. It emphasizes the leadership role while still keeping everyone else in the loop. Use DACI when someone's clearly wearing the captain's hat, but you still need a crew. 

CLAM (Collaborate, Lead, Agree, Monitor): CLAM might be the way to go if your project is highly collaborative. If it feels like a group project in school, where everyone needs to pitch in, give CLAM a shot.

Choosing the right model depends on your project's specific needs and your team's dynamics. While RACI is a fantastic starting point, don't be afraid to explore these alternatives to find the perfect fit for your next endeavor. And if all else fails, just make up your own acronym. Who's stopping you?

Unlock the power of RACI

I can't help but think back to my escape room fiasco. If only we'd designated someone responsible for deciphering the codes, and another accountable for keeping us on track. A couple could've been consulted for their puzzle-solving prowess, and the rest, well, they could've been informed—preferably from a distance. 

Related reading:

Kanban vs. Scrum Agile methodology: Which is better?

The best project management software

4 ways project management automation makes your job easier

Get productivity tips delivered straight to your inbox

We’ll email you 1-3 times per week—and never share your information.

Allisa Boulette

Based in New England, Allisa is a content marketer and small business owner who hopes to make the internet a more interesting place than she found it. When she’s not working, you can find her lying very still not doing anything.

• Project management
• Product management
• Small business

Related articles

How to choose the best automation software

AI in customer service: 11 ways to automate support

AI in customer service: 11 ways to automate...

How to write a letter of introduction for your freelance business

How to write a letter of introduction for...

What is prompt engineering?

Improve your productivity automatically. Use Zapier to get your apps working together.

• Contact sales

Start free trial

How to Make a Responsibility Assignment Matrix for a Project (Template Included)

The most important resource you’ll employ to deliver the project is people. They have to fit into the schedule and maintain the project budget. Defining what their roles and responsibilities are when executing tasks and delivering on the project goals is an important part of controlling the project.

How can you coordinate all the people who are involved in a project so they know what they’re doing and don’t block others from doing what they are assigned? Using a responsibility assignment matrix can help. An assignment matrix gives your project a team that gets things done.

What is a Responsibility Assignment Matrix in Project Management?

A responsibility assignment matrix (RAM) is a project management chart used to identify and define the various people and organizations and outline each of their roles in working on tasks or delivering a part of the project.

Project managers use an assignment matrix to clarify what cross-functional teams do within the boundaries of the project and its numerous processes. Sometimes a responsibility assignment matrix is required when responding to a request for proposal (RFP).

The responsibility assignment matrix can also be called a RACI matrix, which stands for responsible, accountable, consulted and informed.

• Responsible: Notes who is responsible for executing the task, which is then assigned to them.
• Accountable: Notes who has decision-making authority and how that power is delegated throughout the project team.
• Consulted: Notes who is able to offer insight into the task, from team members to stakeholders.
• Informed: Notes who is updated on what in terms of progress and performance, as well as when and how this information is disseminated.

This creates a map of connections between activities and project team members. Depending on the size of the project, there can be several assignment matrices used for various project levels.

Why Create a Responsibility Assignment Matrix?

The assignment matrix identifies what everyone on the team is responsible for, which means not only what their duties are, but how they participate in the project. Some will have defined tasks, others will offer help with work, while there are some who are designated as decision-makers. These groups all have an identity and function within the project to help guide it towards a successful end.

Clear communication leads to more efficient projects. An assignment matrix facilitates better communication between team members and provides transparency by creating a system to make sure everyone is updated and always on the same page. Belaboring communications can bog down a project with too many pointless meetings and confusing interactions in which people try to understand what they’re supposed to be doing. Using the responsibility assignment matrix helps, but having project management software that connects teams in real-time is ideal.

ProjectManager manages project information by allowing teams to attach files directly to tasks, and our unlimited file storage keeps important project documents at your fingertips anywhere, anytime. Commenting on tasks can save time and tagging others in the project team creates a communication process that avoids the pitfalls of redundancies or unnecessary meetings.

When Should a Responsibility Assignment Matrix Be Created?

The responsibility assignment matrix would be created at the start of the project. You’d want to have everyone on the project team aware of where they stand in terms of their involvement before they start executing tasks.

As much as its use is a preventative measure, it can be used prescriptively. If you’re deep into the project and things are not moving as planned, there could be communication gridlock. If team members are not in the loop, or misconstrue what they’re supposed to be doing, using a responsibility assignment matrix might untie up those knots in the communication channel.

If there’s a problem with leadership overruling suggestions on how to advance the project and this is seen as a problem, it’s likely that the roles and responsibilities of the project team need refining. The responsibility assignment matrix defines who has authority to make decisions and using it or revisiting can determine if the right people are in that position.

In fact, any of the definitions might need reexamining at any phase in the project. Perhaps tasks are falling behind schedule. This could be because team members aren’t aware of what tasks they own. Anytime a delay occurs, returning to the assignment matrix is a good first step, even if you went through the process as you should during the planning stage of the project.

How to Create a Responsibility Assignment Matrix

The actual making of a responsibility assignment matrix is not as difficult as getting everyone on board with what their roles and responsibilities are.

Therefore, you want to include your team in the process, get their input and eventually buy-in without spending too much time and energy on the process. Follow these steps to make sure everyone is in agreement and you’ll have a successful responsibility assignment.

• Identify all the participants involved in the project, from team members to stakeholders and everyone in between.
• List all deliverables associated with the project. Use a work breakdown structure to make sure you don’t miss any.
• Meet with team members on how to execute the tasks to create the deliverables. Every task needs to be discussed in terms of the team’s responsibility and authority.
• Draft the responsibility assignment matrix using a table with the project tasks listed on the left-hand column. Across the top add the name of everyone in the project.
• Where the tasks meet the project team member, assign whether they’re responsible, accountable, consulted or informed.
• When completed, share the responsibility assignment matrix with the project team and stakeholders and hold a meeting if necessary to make sure everyone understands their part in the project. If you’re working in a shared space, print out a copy and post it.

Free Responsibility Assignment Matrix Template

Using a RACI template is a shortcut that sets up your team and the project for success. ProjectManager is more than an award-winning software that organizes tasks, teams and projects to streamline work and boost productivity, it’s also the online hub for all things project management.

Among the hundreds of blog posts, guidebooks and tutorial videos are dozens of free templates that can help you through every phase of your project’s life cycle. Using our free RACI template will help you guide all the project teams better, allowing them to know where they stand in relation to the project and what their level of responsibility and accountability is.

Use it at the start of the project to avoid delays and untangle any communicative knots that are preventing the project from progressing as planned. To keep your project on track, download our free RACI template and get a head start on building a workable responsibility assignment matrix.

Best Practices

Using our free RACI template is a good start, but you have to make sure you fill it in correctly. A responsibility assignment matrix is only as good as the effort put into creating it. Here are some best practices to apply when you’re in the process of building your assignment matrix.

• Involve the team: They’re the ones who will be executing the work. You want their input and buy-in to avoid any costly mistakes or time-consuming questions about what wasn’t made clear at the beginning of the project.
• Identify every single task: Identify all the tasks required to reach your final deliverable. Once you have that thorough list make sure that there is only one person on the team who is accountable.
• Update your RACI regularly: Make sure that each new one is clearly marked as the most current version and is distributed to everyone on the team. There will be times when you’ll want to revisit the responsibility assignment matrix or changes in personnel will require an edit.
• Share responsibility viably: One person shouldn’t have to shoulder the bulk of the responsibilities for the project and you want to give authority throughout the project team and not just among the very top management team.
• Optimize tasks: Managers can use the RACI matrix to see if too many team members have been assigned to a task. Maybe these workers could be spread out for greater productivity. There could be too many people listed as consulted, which slows down the process. The assignment matrix is endlessly useful.

How ProjectManager Helps You Manage Projects Better

ProjectManager is a cloud-based tool that connects everyone in real-time to facilitate planning, monitoring and reporting on the project. It works to give everyone on the project team a job and the knowledge as to where they have authority and when to consult others, as well as defining the reporting process.

Let’s look at the people who are responsible, for example, the team who execute the project. Once invited into the software, you can share the project plan, assign them tasks, add detailed direction, add a deadline and tag for priority and more. The teams can then collaborate by attaching files and images to the tasks and commenting in real-time to work better together.

Those who need to stay informed of the project can do so by also getting invited into the project and sharing plans and schedules with them. Stakeholders can stay updated with reporting features that can generate reports on project variance, cost, time and more with one click. Then share them as a PDF. Reports can even be quickly filtered to zero in on the data stakeholders are interested in.

The responsibility assignment matrix can help you reallocate your resources when things aren’t progressing as planned. Use our software to get further insight. The resource management features include a workload chart that’s color-coded so it’s easy to see who has too many tasks and who can take on more work. Then you can simply reallocate those resources from the workload page to help your team work more productively.

ProjectManager gets you organized, keeps your team focused on their tasks and stakeholders in the loop. Gain efficiencies throughout every aspect of your project’s life cycle with an online Gantt chart to schedule work and kanban boards, a visual workflow feature that provides transparency into production. All that and it’s on a collaborative platform to keep everyone connected. Try ProjectManager today for free.

Deliver your projects on time and under budget

Start planning your projects.

• Memberships

RACI Matrix Theory: Example and Template

RACI Matrix Theory: this article explains the RACI Matrix in a practical way. Next to what it is (definition and meaning), this article also highlights a RACI Matrix example with defined roles, The aconym explained, addition on the acronym, steps to set-up a Matrix, the Focus areas, the combination with change management, general tips and a RACI Matrix template to get started! Enjoy reading!

What is RACI Matrix?

Raci matrix definition and meaning.

The RACI Matrix or RACI chart can be used to have good insight into the various participants of the project and their individual responsibilities during a (complex) project.

RACI is an acronym of Responsible , Accountable , Consulted and Informed . These terms are clarified later in this article. The matrix design of the RACI Matrix describes the participation of the various functional roles in the project or business process , in completing tasks or results.

The RACI Matrix is also referred to as Responsibility Assignment Matrix (RAM) or Linear Responsibility Chart (LRC).

This powerful solution is often used with PRINCE2 project management and the LEAN method .

RACI Matrix example layout defined roles

The RACI Matrix has a fixed layout with a horizontal axis of roles and a vertical axis with tasks, activities, deliverables and responsibilities. A distinction must be made between a role and individual people. A role is a description of a set of tasks.

Figure 1 – The Elements of the RACI Matrix

What is RACI?

The RACI Matrix has a fixed design, with the names of functional roles on the horizontal axis and the various tasks, activities, the achievements to be delivered and responsibilities on the vertical axis. We must distinguish between a functional role and individual people.

A functional role is a description of a wide range of tasks or deliverables. Such a role can be carried out by multiple people. Conversely, an individual person may fulfil various different roles.

For instance, ten employees can fulfil the role of project manager within an organisation, and a single individual can fulfil the role of project manager and business analyst. RACI is an acronym of four important characteristics involved in a project:

Responsible

Responsible : the person carrying out the task is responsible for the execution. Subsequently, the executor must provide justification to the ‘Accountable’ person.

Accountable

Accountable : this person bears final responsibility for the correct completion of one or multiple project tasks. Others are accountable to him or her and he or she must approve the task (sign off). It’s possible that an ‘Accountable’ is appointed per task.

Consulted : this is the person who is consulted beforehand. This is a two-way street; in addition to giving advice, he or she also helps in the execution and steers the result.

Informed : this person is kept informed with up-to-date information about the progress and achieved results. This is a one-way street.

It’s often the case that the role of Accountable is not part of the RACI Matrix. In that case, it is assumed this characteristic is joined with that of Responsible. However, apart from this exception, we recommend appointing each characteristic to only one person in the project. When a person falls under multiple characteristics, this could create stagnation in the project because it hinders the completion of specific tasks.

Addition to the RACI Matrix

Sometimes, the ‘S’ (RASCI) or ‘O’ (CAIRO) is added to the RACI model. The ‘S’ stands for Support; someone who supports and motivates team members to carry on in the project.

The ‘O’ stands for Out of the Loop; the one who’s standing at the sidelines and isn’t part of the process. This includes facilitating and supporting employees and/or departments.

Step-by-step plan filling in the RACI Matrix

Below, we discuss several steps that the user must follow to develop his own RACI Matrix. A toolshero template is available for this purpose.

Follow each step below to complete the template.

Step 1: identify different team members

It’s important to keep track of exactly who will be working on a certain task or project. Examples are the sponsor, project manager, team members, analysts and more.

Use the names of these people when this makes sense. Sometimes, it is also possible to use the position titles or team names. However, when members see their names in the matrix, this promotes their engagement.

Step 2: identify important milestones

Just like every project starts with planning, this is also an important part of the RACI model.

Use the developed objectives from the project plan or sponsor’s requirements and note down exactly which milestones must be achieved to deliver the project on time. For instance, if a website is being built, milestones could be the first design, testing and approval by the client.

Step 3: fill in the matrix for each team member and for every task

After all information concerning milestones, team members and responsibilities has been collected, the matrix can be filled in using the right data.

Simple programmes, such as Microsoft Excel, can be used for this purpose. Other software can also be used.

Step 4: fill in the accompanying R, A, C or I for each field to indicate the role of each person for each task

It’s important that each team member is assigned a specific role, depending on the aspect of the RACI Matrix. In the case of the milestone of the website design, the team manager bears final responsibility for gaining approval.

In this case, the executive sponsor is accountable, and the developer must be kept informed of the result.

Step 5: discuss, analyse and evaluate

Discuss the filled-in RACI matrix with everyone of the project team, the sponsors, and all relevant stakeholders. For instance it is possible that the executive sponsor wants to be the one to meet the client to gain approval or discuss the requirements. Comply with this request.

Step 6: distribute copies

In addition to step 5, distribute copies of the RACI Matrix to everyone. Preferably do this by email and put up a copy in the joint workspace.

Focus areas RACI Matrix

To preserve the quality of the RACI Model, we advise looking at the most frequent mistakes and pitfalls in the development. Avoid these mistakes and pitfalls and make sure that the RACI Matrix is accurate and the project successful.

Too many details

A RACI Matrix is not the same thing as a project plan, or even a Project Initiation Document (PID) .

Although it’s important to include roles and the division of tasks, it is not necessary to include details on the activities and responsibilities.

Do not include the daily, weekly and monthly schedule here. In case of confusion about the project or the activities, it’s time to distribute the original project plan among the team.

Don’t use the same matrix

A RACI Matrix template is easy to adjust, and it’s therefore tempting to use it again for standardisation.

Generally speaking, the project manager will keep the original matrix, but every project should have its own RACI matrix. That’s because each project is different and has a different complexity level. The milestones are also different and the team members may have changed, or the team may have been completely replaced.

Be consistent

The person who is accountable in the matrix must be able to contribute the decisive factor in every task appointed to them in the matrix. Deviating from established roles will lead to confusion and mistrust, and will reduce the power of the RACI Matrix.

Naturally, it’s important to be flexible as a team, but it’s important not to shift the responsibilities and roles around too much.

Minimise the number of columns in the RACI Matrix

Each task and each column in the RACI Matrix must allow for a clear responsibility and decision. For the sake of efficiency and effectiveness, do not include things like team meetings in the matrix.

When use a RACI matrix?

The RACI matrix can be used in nearly every project, but there are several situations when it’s advantageous that tasks require multiple sources, are carried out simultaneously, or when tasks are dependent on other tasks.

Additionally, the RACI Matrix is also helpful in non-project management situations. Always use this tool in the following project management situations:

• When decision making or approval processes could hinder the project.
• When conflicts arise about who has a certain task.
• When conflicts arise about who is accountable for a milestone or task.
• When the project load is not evenly divided.
• When project members are at their maximum output and new project team members must quickly be attracted.

This tool is also effective in a non-project management setting:

• Workload Analysis: identify overload.
• Reorganisation: make sure that important functions and processes are not overlooked if an organisation’s structure is reorganised.
• New employees: new employees can be easily and quickly informed of their new responsibilities and roles with the RACI matrix.
• Work orders: the RACI model creates flexibility in management situations. This provides the right balance between line and project responsibilities.
• Conflict resolution: the RACI model offers a forum for discussion and conflict resolution between team members or departments.
• Establishing the status quo: the output of the RACI Matrix is an easy but effective way of establishing the responsibilities and roles in an organisation.

Not every team is equal, and the same is true of different projects. The one team might excel at communication, the other is able to focus on their own tasks exceptionally well. Another team is small enough to take sufficient time to complete various tasks. In such cases, it’s not necessary to take an extra step with the RACI Matrix.

The RACI Matrix is often a part of project management software. This software allows users to track everything they need, from open tasks to task milestones and resource planning.

RACI Matrix and change management

Various organisational problems often arise when developing a RACI Matrix. This is because this tool connects three elements of roles and responsibilities

Role conception

Role conception refers to what people think their job is. This is often still unclear, despite years of experience. A RACI matrix helps to clarify this.

Role expectation

The role expectation means what others in the organisation think someone’s position entails and how it must be carried out.

Role behaviour

The role behaviour is what people actually do in fulfilling their work and responsibilities.

The RACI Matrix is a useful tool, but also a collective name for various types of problems.

Think carefully about the level of details, defining tasks and roles, and bring the model to a level that is both succinct and sensible. Naturally, it’s not important to include who is responsible for getting coffee.

It is important to stay focused on the original reason for developing the RACI Matrix.

Don’t spend too much time developing this tool. Although it’s an important tool, it is not sensible to spend many hours of scarce time on it.

Instead of creating the perfect matrix, stay realistic and understand that a project often turns out differently than planned.

Tips for filling in the template

• Make sure the matrix is useful. So, think carefully about how RACI will be used and why.
• Choose a model and understand the conditions and context.
• Make sure that only one role is marked as responsible.
• Have stakeholders provide input for the core project and milestones/ requirements

RACI Matrix template

Start visualizing what the tasks and responsibilities are of each team member with this ready to use RACI Matrix template.

Download the RACI Matrix template

It’s Your Turn

What do you think? What is your experience with the RACI Matrix? Can you use this information to create a RACI matrix? Do you recognize the practical explanation mentioned above or do have more tips? Do you recognize the need to effectively assign roles to people? What are success factors to manage stakeholders within a project? Do you define project roles and responsibilities with this tool?

Share your experience and knowledge in the comments box below.

More information

• Jacka, J. M., & Keller, P. J. (2009). Business process mapping : improving customer satisfaction . John Wiley and Sons .
• Kofman, A., Yaeli, A., Klinger, T., & Tarr, P. (2009, May). Roles, rights, and responsibilities: Better governance through decision rights automation . In Proceedings of the 2009 ICSE Workshop on Software Development Governance (pp. 9-14). IEEE Computer Society.
• Morgan, R. (2008). How to do RACI charting and analysis: a practical guide . Retrieved October, 1, 2010.

How to cite this article: Janse, B. (2020). RACI Matrix . Retrieved [insert date] from Toolshero: https://www.toolshero.com/project-management/raci-matrix/

Original publication date: 06/14/2020 | Last update: 11/21/2023

Add a link to this page on your website: <a href=”https://www.toolshero.com/project-management/raci-matrix/”>Toolshero: RACI Matrix</a>

Did you find this article interesting?

Your rating is more than welcome or share this article via Social media!

Average rating 4.4 / 5. Vote count: 5

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Ben Janse is a young professional working at ToolsHero as Content Manager. He is also an International Business student at Rotterdam Business School where he focusses on analyzing and developing management models. Thanks to his theoretical and practical knowledge, he knows how to distinguish main- and side issues and to make the essence of each article clearly visible.

Related ARTICLES

Project budget explained: theory and a template

Responsibility Assignment Matrix (RAM)

Business Requirements Analysis Framework and Steps

Stakeholder Management: Theory and Strategy

Milestone Trend Analysis (MTA)

Request for Proposal (RFP)

Also interesting.

Business Model You by Timothy Clark: a Summary

Failure Mode and Effects Analysis (FMEA)

SOAR Analysis: the theory plus example and template

Leave a reply cancel reply.

You must be logged in to post a comment.

BOOST YOUR SKILLS

Toolshero supports people worldwide ( 10+ million visitors from 100+ countries ) to empower themselves through an easily accessible and high-quality learning platform for personal and professional development.

By making access to scientific knowledge simple and affordable, self-development becomes attainable for everyone, including you! Join our learning platform and boost your skills with Toolshero.

POPULAR TOPICS

• Change Management
• Marketing Theories
• Problem Solving Theories
• Psychology Theories

ABOUT TOOLSHERO

• Free Toolshero e-book
• Memberships & Pricing

Organizational Structure

What is a Responsibility Assignment Matrix

Last updated: Feb 15, 2023

Table of contents

What is a RAM matrix used for?

How to make a ram or raci chart.

Learn what a Responsibility Assignment Matrix is and how to use one to make all your upcoming projects run smoothly.

A Responsibility Assignment Matrix (RAM), sometimes known as a RACI chart, is a tool used in project management to keep track of all responsibilities assigned to cross-functional teams on a specific task or assignment.

It’s known as a RACI chart because its acronym names the four key roles displayed in the matrix:

• Responsible: Who is the person responsible for completing a task or making a decision?
• Accountable: Who is accountable for the completion of the project overall and will sign off on deliverables and decisions?
• Consulted: Who needs to be consulted to provide input on a particular task or item?
• Informed: Who needs to be kept informed of project progress or completion?

A typical RAM template looks like this:

| Task | Annabelle (PM) | Jack (Technical Lead) | Dory (Technical Team Member) | | ---------- | ---------- | ---------- | ---------- | | Task 1 | A | I | R | | Task 2 | R | C | I | | Task 3 | C | R | C | | Task 4 | A | R/I | R |

The RAM matrix is used to document every task, item and decision involved in a project completion process. By keeping everything logged all in one place, a RAM matrix is an invaluable tool to any project manager or company leader for a few reasons.

• Defines clear roles and responsibilities

There is nothing worse than a project being slowed down or stalled because of confusion over who was supposed to do what. In a RAM, every person or team involved can check to see which task or item.

• Streamlines communication

Sometimes explaining directions in person or over a workplace communication tool can get confusing or be interpreted the wrong way. Even worse, one instance of miscommunication can tank an entire project or jeopardize a relationship with a client.

With a RAM, project managers don’t have to waste time directing questions to the responsible stakeholder in charge of making a decision. The chart informs everyone involved exactly who they can go to for answers, cutting out repetitive conversations and notifying the right people at the right time.

• Distributes workloads evenly

No one ever wants to be the one in the group project that has to do everything. Team members with a higher workload are at a greater risk for burnout. A great benefit of a RAM is that everyone can see how the workload for a certain project is distributed. It’s also a great way to be transparent within workflows.

Don’t let the random letters confuse you. Building a RACI chart is surprisingly simple. It can also easily be tweaked to fit your organization and your particular project. According to the work management platform Wrike , here are four steps to follow when building a responsibility assignment matrix:

• Identify all project roles

Start out with a list of everyone involved in a project, including every team, team member, manager and stakeholder.

• Identify all project tasks

Then make a list of all the tasks and items needed to get a project done. These can include deliverables, activities, milestones and decisions.

• Create a chart with a column for each role and a row for each task

In a spreadsheet—or any other tool you’d like—create a simple table by listing each person or role in the columns and each task or deliverable in the rows.

To get the most out of your RACI chart, try to make the roles as personal as possible. For example, instead of naming a role “technical lead,” try to use names, like “Jack.” This will give every person involved a sense of ownership, while also streamlining communication even further.

• Assign “R,” “A,” “C” or “I” to each person involved

Once you have written out the names of each person and task, now comes the important part of assigning RACI to each person involved. Identify who is responsible, who is accountable, who needs to be consulted and who needs to be informed for every task in the project. A role can have more than one letter, but simplify it as much as you can. Bonus step: Add a color to each letter to make the roles stand out even more.

That’s it! You now have made a successful RACI chart. Review with your team and all stakeholders before you initiate a plan, and you are officially on your way to more effective project management.

Create your own free org chart today!

Show off your great team with a public org chart. Build a culture of recognition, get more exposure, attract new customers, and highlight existing talent to attract more great talent. Click here to get started for free today.

The ORG helps you hire great candidates

Free to use – try today

Which Org Structure Fits You?

Matrix organizational structure, flat organizational structure, functional organizational structure.

What is a Responsibility Assignment Matrix (RAM) in Project Management?

• 1.  Project Management Basics
• 2.  Project Management Methodologies
• 3.  Project Management Life Cycle
• 4.  Best Project Management Software
• 5.  Team Collaboration Tips
• 6.  Agile Methodology Basics
• 7.  Agile Project Management Tools & Techniques
• 8.  Project Management Frameworks
• 9.  Resources
• 10.  Glossary
• Advanced Terminology
• Methodologies
• PM Software Features
• Basic Terminology
• Professional Development
• Agile Project Management

Introduction to Responsibility Assignment Matrix (RAM)

Project management is a complex process that involves multiple stakeholders, tasks, and resources. To ensure the success of a project, it is crucial to assign clear roles and responsibilities to team members and accurately define their tasks. 

One tool that can help project managers achieve this goal is the Responsibility Assignment Matrix (RAM). In this article, we will explore the definition and benefits of RAM, as well as some examples.

If you’re looking for a RAM template that will help you assign roles and clarify responsibilities, Wrike has a customizable template ready to go.

What is a Responsibility Assignment Matrix (RAM) in project management?

A responsibility assignment matrix (RAM) in project management, also known as a RACI chart or RACI matrix, details all the necessary stakeholders and clarifies responsibilities amongst cross-functional teams and their involvement level in a project. RACI stands for Responsible, Accountable, Consulted, and Informed and each letter corresponds to a team member.

A RAM in project management should be referred to by all parties throughout a project because it helps plan an individual’s roles and responsibilities before work begins. A RACI matrix ensures all stakeholders know who is responsible for completing a task or getting feedback on deliverables.

The four roles are broken down as follows:

• Responsible: The person(s) completing the task
• Accountable: The team member coordinating the actions, making decisions, and delegating to those responsible for the task
• Consulted: The person(s) who will be communicated with regarding decisions and tasks
• Informed: The person(s) who will be updated during the project and upon completion

Read more about RACI here . 

Identify and visualize roles seamlessly with Wrike

Responsibility assignment matrix example.

A common RAM   template looks like the example below. Notice how all stakeholders can have more than one role:

Responsibility Assignment Matrix template

Below you can see a powerful RAM template . The chart helps with visualizing roles and workload clearly. Therefore, project managers and team members follow the progress easily and stay on track.

Clarify roles with Wrike

In conclusion, RAM is a useful tool for any project manager who wants to ensure their team is clear on their responsibilities. It helps to establish a structured approach to project management, allowing for better communication, accountability, and ultimately, project success.

Using Wrike’s pre-built template, you can define the roles of each team member so everybody is on the same page. The template will also help you balance your workload and create complete transparency on your team structure.

What is a RACI Chart?

Basic Project Management

• Project Charter
• Project Management Stakeholders
• What is a Project?
• Work Breakdown Structure
• Project Objectives
• Project Baseline
• Project Management Scheduling
• Project Management Work Packages
• Project Management Scope
• Scope Creep

Advanced Project Management

• What is PERT?
• Network Diagram
• Risk Management
• Cost Estimation
• Feasibility Study
• Monte Carlo Analysis
• Project Integration
• Cost Management
• PMI Project Management
• What To Do With Certification
• Certification
• Become Certified
• PMP Certification
• Best Certification

Software Features

• Critical Success Factors
• Capacity Planning
• User Role Access Permissions
• Time Tracking
• Budget Tracking
• Request Forms
• Work Assignments
• Version Control
• Dependency Managements
• Project management Milestones
• Project Management Software
• Project Management Tools
• Project Management System
• Gantt Charts

What is a Responsibility Assignment Matrix (RAM) in Project Management?

Fahad Usmani, PMP

March 30, 2024

A responsibility assignment matrix (RAM) in project management is a key document that distinguishes stakeholders’ roles and responsibilities. The RACI chart is the most popular example of a RAM that clarifies stakeholders’ roles and defines their involvement.

RACI stands for Responsible, Accountable, Consulted, and Informed. Each team member in the RACI chart has at least one role.

All stakeholders refer to RAM in case of conflict regarding the roles and responsibilities in assignments or duties. RAM helps reduce conflict in projects to a great extent. Using this document, every team member will know their roles and the responsibilities of other team members.

The roles in the RACI matrix are as follows:

• Responsible: This stakeholder is responsible for completing the task.
• Accountable: This stakeholder is accountable for the task. They will make decisions and delegate work to the stakeholders who are responsible for completing the task.
• Consulted: These stakeholders will be consulted on any decisions made about the task.
• Informed: These stakeholders only require an updated status report on the progress of the task.

Responsibility Assignment Matrix Example

As I said, the RACI chart is the most popular example of RAM.

The table below shows the RAM example using the RACI chart:

Some other less-popular responsibility assignment matrix examples are as follows:

• RASCI Chart: This chart is also known as the “RASCI matrix,” as the letter S is added, which means “supportive.” 
• DACI Chart: DACI stands for “Driver, Approver, Contributor, and Informed.” 
• RAPID Chart: RAPID stands for “Recommend, Agree, Perform, Input, and Decide.” 
• CARS: CARS stands for “Communicate, Approval, Responsible, and Support.” 
• CLAM: CLAM stands for “Contribute, Lead, Approve, and Monitor.” 

Responsibility Assignment Matrix Template

The table below shows the basic template for the responsibility assignment matrix.

RAM is a key tool in project management . It helps the project manager assign roles and responsibilities. Additionally, it ensures that the team stays on its path and that no one interferes with each other’s roles. Finally, RAM ensures that every task has responsible and accountable stakeholders assigned to it.

This topic is important from a PMP exam point of view.

I am Mohammad Fahad Usmani, B.E. PMP, PMI-RMP. I have been blogging on project management topics since 2011. To date, thousands of professionals have passed the PMP exam using my resources.

PMP Question Bank

This is the most popular Question Bank for the PMP Exam. To date, it has helped over 10,000 PMP aspirants prepare for the exam. 

PMP Training Program

This is a PMI-approved 35 contact hours training program and it is based on the latest exam content outline applicable in 2024.

Similar Posts

What is Project Change Management?

Change management is the process of making changes to a project. These changes can be made to processes, policies, approved project documents, baselines, etc. The change management process includes the project manager and the change control board (CCB). The CCB includes stakeholders (e.g., top management and subject matter experts). The project manager will raise the…

LearnWorlds Review (2024): Top Features, Pros & Cons

If you are a teacher or a course creator looking for a LearnWorlds review to decide if this is the right platform, you have landed at the right place. This blog post will provide a detailed review of LearnWorlds and everything you need to decide if this platform is right. Online coaching and training have…

Document Version Control: Examples and Best Practices

If you develop software or write documents, you must understand Document Version Control.  It is a key part of the development process and evolution. Therefore, in today’s blog post, I will explain in detail the principles of version control for documents or software. Let’s get started. What is Version Control? Version Control tracks and manages…

PM PrepCast Review (2024): Pricing, Pros, Cons & Top Features

This blog post will provide my PM PrepCast review, pricing, pros and cons, and top features. If you are looking for an online PMP training program and are considering subscribing to the PM PrepCast, you should read this PM PrepCast review first. However, before I start reviewing the PM PrepCast, let’s understand why you should…

PMP Exam Schedule: The PMP Exam Date in 2024

The PMP exam schedule is the key milestone in your journey to becoming a PMP. You can attempt the PMP exam only after getting a confirmed appointment date from Pearson VUE center. In today’s blog post, I will provide you with everything about the PMP exam schedule. Let’s get started. PMP Exam Schedule You can…

Risk Appetite: Definition, Example, Statement

Definition: Risk appetite is the degree of uncertainty an organization is willing to take in anticipation of a reward. The meaning of appetite is hunger; therefore, risk appetite means risk hunger. Hunger is a subjective term and cannot be quantified. However, an organization’s risk appetite can be from low to high.  Many businesses do not…

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Jira Software

Project and issue tracking

Content collaboration

Jira Service Management

High-velocity ITSM

Visual project management

• View all products

Marketplace

Connect thousands of apps and integrations for all your Atlassian products

Developer Experience Platform

Jira Product Discovery

Prioritization and roadmapping

You might find helpful

Cloud Product Roadmap

Atlassian Migration Program

Work Management

Manage projects and align goals across all teams to achieve deliverables

IT Service Management

Enable dev, IT ops, and business teams to deliver great service at high velocity

Agile & DevOps

Run a world-class agile software organization from discovery to delivery and operations

BY TEAM SIZE

Small Business

BY TEAM FUNCTION

Software Development

BY INDUSTRY

Telecommunications

Professional Services

What's new

Atlassian together.

Get Atlassian work management products in one convenient package for enterprise teams.

Atlassian Trust & Security

Customer Case Studies

Atlassian University

Atlassian Playbook

Product Documentation

Developer Resources

Atlassian Community

Atlassian Support

Enterprise Services

Partner Support

Purchasing & Licensing

Work Life Blog

Atlassian Presents: Unleash

Product updates, hands-on training, and technical demos – catch all that and more at our biggest agile & DevOps event.

• Atlassian.com

Transform teamwork with Confluence. See why Confluence is the content collaboration hub for all teams.  Get it free

• The Workstream
• Project management

How to use RACI charts for improved project ownership and team collaboration

Browse topics.

Everyone’s been there — a new major project lands on your manager’s desk and the team comes together to figure out how to accomplish it. But where do you start? Who’s responsible for what? And how do you get to the finish line together?

What is a RACI chart?

A RACI chart delineates roles among team members across a given project: Responsible, Accountable, Consulted, and Informed.

A RACI chart is also known as a responsibility assignment matrix (RAM) or project assignment matrix (PAM). RACI is a simple table that goes a long way in identifying who should be doing what in a project or campaign. 

Using project management frameworks like the RACI model, you can build a workflow where everyone has input and ownership from start to finish.

RAPID vs DACI vs RACI

You may be saying, “haven’t I heard of this before?” That’s likely — it’s popular among scrum masters and agile managers . But there are also a few similar models that get confused with RACI, particularly RAPID and DACI, which are about decision-making and group consensus.

So, what’s the difference? While RAPID and DACI are designed as the step your group takes before initiating action, RACI is the plan that sets up who will make that action.

Why are RACI charts important for project management?

A RACI chart gives everyone involved a clear view of each individual’s role. In project management , that can make a world of difference in your success. Establishing clear roles can lead to higher employee engagement and easier agile decision-making . This can contribute to up to 53% more efficiency than before you had defined roles. 

A team that was previously misaligned and unclear on their roles and responsibilities can find significant progress in their next project by providing role clarity and direction through a RACI matrix.

2. Centralize communication

Your team is struggling to communicate with disorganized email threads, direct instant message pings, and comments that get lost in the shuffle. 

That’s bad news (and a big time-waster) for your projects. A number of studies show that communication is one of the most common and frequent causes of project failure . When team members have too many places to check for information, wires are crossed, deadlines are missed, tasks are forgotten, and confusion builds. 

Project management software keeps all of your communication — from timelines and status updates to feedback and questions — in one single place that’s easily accessible to everyone. This breaks down silos so that everybody can not only share knowledge, but effectively manage how and where they share it. 

Understanding the RACI Model

When should you use a RACI Matrix? Don’t feel pressured to establish RACI on everyday tasks, like checking emails or answering customer calls. But when a project has invested stakeholders and the potential for long-term impact, like improving an app user interface or launching a new product, the RACI chart can keep you in line from the get-go.

Let’s dive into the four roles of the RACI matrix: Responsible, Accountable, Consulted, and Informed.

Responsible: Performing the tasks

The “R” in your model takes the role of Performer. The responsible individual is delegated a responsibility, like “design home page wireframe,” from the accountable person, and must complete that responsibility within agreed-upon parameters and an agreed-upon deadline. You may have multiple responsible individuals for one task; make sure you balance this appropriately and make it clear exactly who should be doing what at each stage of the process.

Accountable: Overseeing the project

The “A” is the accountable individual whose job it is to ensure the task is completed by all the responsible members. Unlike responsibilities, accountabilities shouldn’t be relegated; keep this assignment to only one accountable individual who acts as the decision-maker and shepherd throughout the project, ensuring the task is completed to an acceptable standard.

Consulted: Providing information

The “C,” or consulted individual, is the knowledge-holder on the team. They’re available for help, extra context, and advice on the task. Let’s say you’re responsible for designing a wireframe. You may want to consult your website administrator to make sure you have full access to the content management system and won’t break anything with your new CSS ideas. 

The consulted individual will provide you with all the information and access you need before you proceed with the task. You might have one or up to three consulted individuals depending on a task and its complexity; identify who these people are early on so you can loop them into the project and its workflow.

Informed: Gets status updates

Your “I” is the informed approver or stakeholder who wants or needs information about your project’s project. The “I” can be many people, like a leadership team, or the department head who is delivering the project upward. This promotes internal transparency and also ensures two things: 1) recognition that the project is being completed on time and within expectations and 2) guarantees that the project gets approval and aligns with stakeholders’ intent.

Creating a RACI Chart

Now that we know what a RACI chart is and what it’s designed for, let’s build one together. Let’s say our project is building a web page for a new service line. Who handles what tasks along the line to project completion?

Step 1: Identify tasks and workload

What needs to be done along the way to our project goal? Let’s identify some core tasks in a project, such as launching a new website:

• Designing a homepage wireframe
• Creating graphic design and animations
• Identifying SEO keywords
• Setting up the domain and server
• Writing homepage copy

Within those main tasks, you may have smaller subtasks to perform, like approving wireframes or setting up billing info for the domain host . Work with your team to identify those subtasks so no surprises come up along the way that may interfere with your workflow and delay the deliverables.

Step 2: Identify roles

Your graphic designer isn’t going to be doing SEO keyword research, and your copywriter won’t be setting up your domain host. Sit down with your team and have a collaborative conversation to identify those roles . For example, your graphic design task and subtasks may look like the following:

Building graphic design and animations — Ariel 

• Create website hero image — Natalie
• Review and approve website hero image — Tessa
• Animate hero image and convert to .mp4 file — Anji
• Place finalized hero image in wireframe — Ariel

Across all of these subtasks, Natalie and Anji are responsible for individual tasks that contribute to the goal of building design and animations. Tessa is consulted to review and approve the initial image and ensure it follows brand guidelines. Ariel is accountable for the other three’s work and ensuring the final product gets delivered to the wireframe.

Step 3: Build your chart

Now that you have a better understanding of who will be doing what, place those tasks and roles into a chart so you can communicate it with the team at large and track progress as you go. 

Now that you have a better understanding of who will be doing what, place those tasks and roles into a chart so you can communicate it with the team at large and track progress as you go. Here’s an example of a RACI chart (and how to use it):

Step 4: Analyze your chart and identify gaps

Have a working session with your team to identify any gaps or overlaps within the chart, both to prevent duplicative work and also to catch any roadblocks before they happen. Follow some general guidelines for what your RACI model should look like, from identifying gaps and overlaps to analyzing the balance between assignees.

You’ll see there will be some overlaps and dependencies across the chart — for example, Jenna, the SEO manager, needs to identify the SEO keywords for the homepage before Edwin can begin copywriting. So for Edwin’s task, Jenna is consulted , but for Jenna’s task, she is responsible .

You’ll also notice there is only one Accountable individual per task. Think of this person as a task-level “project lead” who drives the boat — you don’t want more than one captain steering at the same time. 

You should also find ways to limit the number of both Responsible and Consulted individuals. When you have too many Rs , it may not be clear who exactly should do what—and that’s how you end up with tasks that end up by the wayside because no one takes responsibility .

Too many Cs means too many cooks offering conflicting opinions and information; make sure your responsible individuals are getting one clear directive to guide them along the way. 

And having not enough Is is indicative that there isn’t enough upward communication or transparency happening within your organization. Be sure your leadership and stakeholders have full buy-in and understanding of the project so it gets approved and implemented without incident.

Using a RACI Chart in Confluence

Now that you understand the foundational best practices of using a RACI chart, it’s time to build one using Confluence . Implement your RACI matrix into your Confluence docs to improve project communication and accountability.

Here’s how to add a RACI matrix in Confluence:

• Click "Insert" on the top toolbar and select "Table" from the dropdown menu.
• In the table dialog box, select the number of rows and columns you need for your RACI chart. For example, if you want to create a RACI chart for a project with four tasks, you can create a table with five rows and five columns.
• The first row should contain the headers for the RACI chart. You can use the following headers: Task , Responsible , Accountable , Consulted , Informed
• Pro tip: use colors or symbols to make the chart easier to read. For example, you can use green for responsible, yellow for consulted, blue for informed, and red for accountable.

You can then use this table on any relevant project Confluence page, from Project Charters to Kick-Off Agendas to even adding the page as a Trello card or within a Jira issue . This will help ensure team members understand their roles and responsibilities, no matter which Atlassian tool they’re using. Encouraging communication and accountability will help improve team performance — all adding up to successful outcomes.

Advanced RACI Techniques in Confluence

Your RACI model may change and expand as your project progresses, so it’s important to keep your chart up to date. Here are some detailed best practices:

Review and Update Regularly

Review and update your RACI charts on a regular basis to ensure that they accurately reflect the current state of the project. Make sure roles are up-to-date, tasks are marked as completed, and dependencies are outlined. Use Confluence to set up a schedule to review and update the chart, and assign a responsible team member to oversee the process.

Include Team Members in the Process

Tag all team members who are involved in the project when you update the chart. That way, everyone is aware of any changes and can confirm they understand their roles and responsibilities. Use comments in Confluence or direct messages to asynchronously communicate updates and changes to team members.

Document Changes

Whenever changes are made to the RACI chart, they should be documented in Confluence. This can include the date of the change, who made the change, and the reason for the change. This documentation can help to ensure that everyone is aware of any changes and that they understand the reasoning behind them.

Keep it Simple

The RACI chart should be easy to understand and navigate. In Confluence, you can use visual aids, such as colors or symbols, to help make the chart more accessible. Additionally, the chart should be concise, focusing only on the most important tasks and responsibilities. Subtasks can be mapped out in Trello or Jira for better project tracking.

Review Roles and Responsibilities

When you make any updates, always review the roles and responsibilities of each team member. As you add or adjust tasks, your team can help to identify any gaps or overlaps in responsibilities. Use task management features in Confluence to assign tasks and responsibilities to team members, then delegate further in Trello or Jira. Additionally, team managers can run the Roles and Responsibilities Play with their teams to clarify individual responsibilities and find gaps that need to be filled.

Ensure Consistency

Now, make sure your charts and assignments are consistent. Establish clear guidelines for how the chart should be used and ensure that all team members are aware of these guidelines. Additionally, you can use marketplace add-ons , templates, or macros in Confluence to keep the chart consistent across different projects or teams.

Get to work

You may also like, project poster template.

A collaborative one-pager that keeps your project team and stakeholders aligned.

Project Plan Template

Define, scope, and plan milestones for your next project.

Enable faster content collaboration for every team with Confluence

Copyright © 2024 Atlassian

An official website of the United States government

The .gov means it’s official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

• Publications
• Account settings

Preview improvements coming to the PMC website in October 2024. Learn More or Try it out now .

• Advanced Search
• Journal List
• Taylor & Francis Open Select

A template-based approach for responsibility management in executable business processes

Cristina cabanillas.

a Institute for Information Business , Vienna University of Economics and Business , Vienna, Austria

Manuel Resinas

b Depto. Lenguajes y Sistemas Informáticos , University of Seville , Seville, Spain

Antonio Ruiz-Cortés

Process-oriented organisations need to manage the different types of responsibilities their employees may have w.r.t. the activities involved in their business processes. Despite several approaches provide support for responsibility modelling, in current Business Process Management Systems (BPMS) the only responsibility considered at runtime is the one related to performing the work required for activity completion. Others like accountability or consultation must be implemented by manually adding activities in the executable process model, which is time-consuming and error-prone. In this paper, we address this limitation by enabling current BPMS to execute processes in which people with different responsibilities interact to complete the activities. We introduce a metamodel based on Responsibility Assignment Matrices (RAM) to model the responsibility assignment for each activity, and a flexible template-based mechanism that automatically transforms such information into BPMN elements, which can be interpreted and executed by a BPMS. Thus, our approach does not enforce any specific behaviour for the different responsibilities but new templates can be modelled to specify the interaction that best suits the activity requirements. Furthermore, libraries of templates can be created and reused in different processes. We provide a reference implementation and build a library of templates for a well-known set of responsibilities.

1. Introduction

Organisations need to manage the different types of responsibilities that their employees may have with respect to all the activities that are daily carried out within them. Process-oriented organisations need to do it, in addition, in accordance to the business processes in place. In this context, responsibilites are defined at different levels. As evidenced by several studies, there are four acknowledged process positions (business process director, business process consultant, business process architect and business process analyst) and a specific set of responsibilities associated to each of them (Antonucci and Goeke 2011 ). However, organisations need to control not only the execution of processes as a whole but also the execution of every single activity carried out within them, which relates to a key role in process execution: the process participants. Activities often require the collaboration among several people with different responsibilities, e.g., people responsible for performing the work, people acting as consultants who provide valuable input for the completion of the activity, and people accountable for the results. Therefore, there are also responsibilities at activity level involving, among others, accountability and consultation.

Business Process Management Systems (BPMSs) stand out of Process-Aware Information Systems (PAISs) as a mechanism for process automation. Specifically, the purpose of a BPMS is to coordinate an automated business process so that the work is done at the right time by the right resource (Dumas et al. 2013 ). They rely on the description of business processes as process models represented with different notations, such as (EPC) (Mendling, Neumann, and Nüttgens 2005 ) or the de-facto standard Business Process Model and Notation (BPMN) (OMG 2011 ). However, although BPMSs use business process models for automation, there is still a gap between these executable process models and business-oriented process models used for communication and analysis. Because of their intent, the latter are not as precise and complete as an executable process model must be (Dumas et al. 2013 ). As a consequence, different methodologies (Dumas et al. 2013 ) and techniques (Graml, Bracht, and Spies 2008 ; Caron and Vanthienen 2016 ) for transforming business-oriented process models into executable ones have been developed. Still, this transformation is known to be slow and error prone (Alotaibi and Liu 2017 ).

In this paper, we focus on this issue in the context of responsibility management. Nowadays, BPMSs are increasingly providing support for modelling activities that involve several people with different responsibilities using advanced resource assignment languages (Cabanillas et al. 2015b ) or supplementary models like RACI matrices (Cabanillas, Resinas, and Ruiz-Cortés 2011b ). However, this support tends to be limited to documentation and reporting purposes. Just a few BPMSs consider several responsibilities associated to an activity during process execution and the existing support suffers from generalisability and flexibility issues. Concepts like accountability or consultation, common in the domain of responsibility management, have to be implemented during the transformation from business-oriented process models to executable process models by manually adding activities for them. Furthermore, this has to be done for each activity that involves several responsibilities in all automated business processes in the organisation, which is time-consuming and error-prone as these transformation tasks usually are (Alotaibi and Liu 2017 ). Moreover, if the responsibilities defined for an activity change, the activities added manually to the process model may also change, which adds additional work that may be significant given the continuous organisational changes (Aldin and de Cesare 2011 ).

Two facts have contributed to the lack of advanced support for responsibility management. First, most process model notations used in current BPMSs for process execution support only one type of responsibility by default, despite some of them like BPMN allow including additional responsibilities in an ad-hoc fashion (OMG 2011 ). This lack of standardisation for managing various types of responsibilities discourages BPMS developers to support different responsibilities in their systems. Second, the way people with different responsibilities interact within an activity is domain-specific. At least, it depends on the organisation and the activity. For instance, some activities may require partial approvals of the work being performed for their completion, whereas for others, such an approval may only be required at the end of the execution or not required at all. Therefore, supporting different responsibilities is not only a matter of assigning new tasks to a worklist, but it is also necessary to find a mechanism that coordinates them in a flexible way.

In this paper, we automate this transition from busines-oriented to executable business processes in the context of responsibility management by enabling current BPMSs to execute processes in which people with different responsibilities interact to perform process activities. The approach involves two artifacts. On the one hand, we address the modelling of different responsibilities by extending a (RAM) (Website 2016 ) with information required for process execution. On the other hand, we introduce a template-based technique for transforming such information into BPMN elements that can be interpreted by a BPMS so that existing BPMN execution support suffices to automate process models that involve activities with several people with different responsibilities. This idea was previously described in Cabanillas, Resinas, and Ruiz-Cortés ( 2012 ) but the work has been extended in several directions, in particular: (i) our current approach does no longer enforce any specific behaviour for the people with different responsibilities that work together in an activity, but new templates can be modelled to specify the interaction that best suits the requirements of each activity. In fact, the whole template-based mechanism is new; (ii) our current approach is not limited to a restricted set of responsibilities anymore, hence gaining generalisability; and (iii) we have refined the previous metamodel and its semantics has been properly defined.

Our approach has two additional advantages. First, it is independent of the platform and hence, the models obtained can be used by any BPMS that supports BPMN . Second, the original structure of the process model remains unchanged after including the templates defined for modelling responsibilities, since the modifications are done at subprocess level. This provides transparency and does not affect the readability of the original model.

The paper is structured as follows. Section 2 describes a scenario that will be used throughout the paper as a running example. Section 3 summarises the related work. Section 4 motivates the work in line with the research method used. Section 5 presents our approach for modelling responsibility aspects in process activities. Section 6 introduces our template-based approach for generating resource-aware BPMN models. Section 7 describes the ways in which we have validated the approach. Section 8 reflects on advantages and limitations of the approach. Finally, Section 9 outlines the conclusions and directions for future work.

2. Running example

The following example is used to illustrate the importance of supporting the collaboration of several people with different responsibilities in a process activity.

Table 1 depicts an excerpt of an organisational model for a project called HRMS. Specifically, it shows the organisational roles assigned to the resources that contribute to the project. 1 Figure 1 shows a simplified version of the procedure to manage the trip to a conference according to the rules of the University of Seville (Spain). In particular, it represents a collaboration between two processes modelled with BPMN 2.0 2 (OMG 2011 ): one process is developed at pool Research Vice-chancellorship and the other at pool ISA Research Group , to which the organisational model previously described belongs. That process starts when a researcher requests for authorisation to attend the conference, for which an authorisation form is filled out with the details of the applicant and the funding source, and sent for external assessment to the Vice-chancellorship. After evaluation, a notification from the Vice-chancellorship is received informing about the approval or rejection of the request, which will be checked by the researcher . In the absence of problems, the researcher must register at the conference and make the reservations required.

Excerpt of the organisational model for project HRMS (WP = Work Package).

Business process to manage the trip to attend a conference.

The previous description of the process is only half of the picture because it assumes that only one person is involved in each activity, in this case a certain researcher. However, for most activities several people are actually involved in them with different responsibilities. For instance, the coordinator of the project that will finance the trip expenses is accountable for activity Prepare Authorisation and the clerk of the project helps the researcher in this task by providing the information required about the funding source; in addition, the account administrator and the leader of the project’s work package related to the subject of the paper to be presented in the conference (or the subject of the conference, in case of no accepted publications) must be informed about the trip request. Following up on this, the project coordinator and the account administrator are informed about the result of the request when executing activity Check Response. In activity Register at Conference, the project coordinator can be consulted about details on the registration process, such as the type of registration, and both the project coordinator and the account administrator must be informed after the registration has been done. Finally, in activity Make Reservations, the clerk of the project can help the researcher, if required, and the account administrator and the project coordinator can also be consulted about details on this activity.

The challenge is to model all those details and come up with a responsibility-aware process model that can be executed taking the responsibilities into account.

3. Related work

Responsibility management in business processes is a part of resource management in business processes, which involves the assignment of resources to process activities at design time as potential participants and the allocation of resources to activities at run time as actual participants.

Resource assignment languages (van der Aalst and ter Hofstede 2005 ; Cabanillas et al. 2015b ; Bertino, Ferrari, and Atluri 1999 ; Strembeck and Mendling 2011 ; Casati et al. 1996 ; Scheer 2000 ; Du et al. 1999 ; Tan, Crampton, and Gunter 2004 ; Cabanillas et al. 2015a ; Wolter and Schaad 2007 ; Awad et al. 2009 ; Stroppi, Chiotti, and Villarreal 2011 ) serve the former purpose by enabling the definition of the conditions that the members of an organisation must meet in order to be allowed to participate in the activities of the processes executed in it, e.g., to belong to a specific department or to have certain skills. The outcome is a resource-aware process model . The set of conditions that can be defined depicts the expressiveness of the language and is usually evaluated with a subset of the well-known workflow resource patterns (Russell et al. 2005 ), namely, the creation patterns, which include, among others: Direct, Organisational, Role-Based , and Capability-Based Distribution , or the ability to specify the identity, position, role or capabilities of the resource that will take part in a task, respectively; (SoD) , or the ability to specify that two tasks must be allocated to different resources in a given process instance; and Retain Familiar (also known as Binding of Duties (BoD)) , or the ability to allocate an activity instance within a given process instance to the same resource that performed a preceding activity instance. A comparison of resource assignment languages can be found in Cabanillas et al. ( 2015b ).

Resource allocation techniques aim at distributing actual work to appropriate resources so that process instances are completed properly, e.g, in terms of high quality and low time and cost (Havur et al. 2015 ). All process engines must be provided with some resource allocation mechanism(s) in order to automate process execution.

Traditional resource management in business processes considers that a process activity requires the workforce of one single resource who is in charge of the activity from the beginning to the end of its execution. However, common scenarios like the one described in Section 2 show the importance of other types of responsibilities, which tend to be disregarded by existing resource management approaches. In the following, we review the current state of the art on responsibility management in business processes, which is the problem addressed in this paper, and then report on approaches for process modelling based on templates, which relates to our solution.

3.1. Responsibility management in business processes

In this section, we first introduce a generic responsibility management mechanism that is independent of process modelling notations or BPMS . Afterwards, we explore the related work for responsibility management in business processes in three groups: (i) the support provided by existing process modelling notations, (ii) the support provided by current modelling software tools and BPMS, and (iii) research proposals developed to bridge existing gaps.

3.1.1. Responsibility assignment matrices (RAMs)

A Responsibility Assignment Matrix (RAM) provides a way to plan, organise and coordinate work that consists of assigning different degrees of responsibility to the members of an organisation for each activity undertaken in it (Website 2016 ). RAMs were defined independently of Business Process Management (BPM) and thus, they are suitable for both process- and non process-oriented organisations. In the context of RAMs, the different responsibilities that may be assigned to an activity are usually called roles or task duties (Cabanillas et al. 2015b ).

RAMs are becoming a recommendation for the representation of the distribution of work in organisations. As a matter of fact, a specific type of RAMs called RACI (ARIS 2012 ) is a component of Six Sigma, 3 a methodology to improve the service or product that a company offers to its customers. There are also ongoing efforts to map RACI to the LEAN and CMMI for Services (CMMI-SVC) frameworks (Nuzen and Dayton 2011 ). The former defines a set of principles for continuous process improvement. The latter provides guidance for applying Capability Maturity Model Integration (CMMI) best practices in a service provider organisation. Similarly, the Information Technology Infrastructure Library (ITIL) framework defines the ITIL RACI matrices 4 as the way to illustrate the participation of the ITIL roles in the ITIL processes. ITIL is the worldwide de-facto standard for service management. Specifically, it uses a modality of RAMs called RASCI (Website 2014 ), which relies on the following five responsibilities:

• Responsible (R) : person who must perform the work, responsible for the activity until the work is finished and approved by the person accountable for the activity. There is typically only one person responsible for an activity.
• Accountable – also Approver or Final Approving Authority – (A) : person who must approve the work performed by the person responsible for an activity, and who becomes responsible for it after approval. There is generally one person accountable for each activity.
• Support (S) : person who may assist in completing an activity by actively contributing in its execution, i.e., the person in charge can delegate work to her. In general, there may be several people assigned to this responsibility for an activity instance.
• Consulted – sometimes Counsel – (C) : person whose opinion is sought while performing the work, and with whom there is two-way communication. She helps to complete the activity in a passive way. In general, there may be several people assigned to this responsibility for an activity instance.
• Informed (I) : person who is kept up-to-date about the progress of an activity and/or the results of the work, and with whom there is just one-way communication. In general, there may be more than one person informed about an activity.

Table 2 illustrates an example of a RAM for the scenario described in Section 2 , specifically a RASCI matrix. The rows represent the process activities, the columns of the matrix are organisational roles, 5 and each cell contains zero or more RASCI initials indicating the responsibility of that role on that activity.

RASCI matrix for the process at pool ISA Research Group.

Note that RAMs are intended to be a responsibility modelling mechanism and are not provided with support for automated analysis that could help to use them together with business processes during process execution. Their expressive power is high in terms of the number of responsibilities that can be assigned but low regarding the number of workflow resource patterns supported, as constraints like sod and bod cannot be defined.

3.1.2. Process modelling notations

The default support for responsibility management in current process modelling notations is limited. BPMN 2.0 (OMG 2011 ), the de-facto standard for process modelling, provides a mechanism to assign responsibilities to an activity. However, the only responsibility type that is defined by default is Responsible (so-called Potential Owner in BPMN). Other types of responsibilities can be added by extending the BPMN metamodel. In addition, nothing is said about the implications of adding new responsibilities during process execution.

The EPC notation (Dumas, van der Aalst, and ter Hofstede 2005 ) is more expressive than BPMN for resource modelling in the sense that it provides a specific representation of organisational units and allows defining organisational relations. However, to the best of our knowledge there is no support for responsibilities other than the resource in charge of executing the activity.

The so-called activity partitions of Unified Modeling Language (UML) Activity Diagrams (Russell et al. 2006 ) are classifiers similar to the BPMN swimlanes, although enriched with dimensions for hierarchical modelling. Therefore, they allow grouping process activities according to any criterion, which includes organisational information. Besides that, this modelling approach is very little expressive in terms of the support provided for the creation patterns (Russell et al. 2005 ). There is no notion of responsibility modelling either.

Finally, BPEL4People (OASIS 2009 ) is an extension of the BPEL notation (OASIS 2007 ) based on the WS-HumanTask specification (OASIS 2010 ), which enables the integration of human beings in service-oriented applications. It provides support for the execution of business processes with three types of responsibilities, namely: Responsible, Accountable and Informed. However, although it provides a rather flexible mechanism for defining the notifications that the people with responsibility Informed receive, the participation of people with responsibility Accountable is limited to intervening when a deadline is missed. Other forms of interaction, such as checking that an activity was correctly performed, are not allowed.

3.1.3. Modelling software tools and BPMS

Modelling software tools, such as Visual Paradigm, 6 facilitate the automatic generation of a RACI matrix from a resource-aware BPMN model. Specifically, the responsibility type Responsible can be automatically extracted and the RACI matrix can then be manually filled out to include information about the other types of responsibilities. However, the output is just used for documentation purposes, since BPMN does not support the definition of responsibilities Accountable, Consulted and Informed.

Signavio Process Editor 7 also allows for defining RACI responsibilities in process models by making use of BPMN elements. While those models can be used for generating reports subsequently, process engines will not take into account the responsibilities Accountable, Consulted and Informed for automatic process execution.

The support for responsibility management is a novel functionality in BPMSs . Bizagi 8 and ARIS (Scheer 2000 ) allow for the definition of RASCI responsibilities in BPMN models by making use of extended attributes in process activities. Nevertheless, similar to the tools focused on modelling, only the responsibility Responsible is considered for execution and the rest are used for process documentation and reporting. RACI matrices can be defined in the Red Hat JBoss BPM Suite 9 aside of a process model for broader documentation of the responsibilities involved in the process (Cumberlidge 2007 ). To the best of our knowledge, only (YAWL) (Adams 2016 ) slightly supports responsibility-aware process execution by means of the concept of secondary resources (human and non-human), which may assist in the completion of the work (hence providing support). Any kind of support for responsibility modelling and execution other than Responsible is still missing, however, in other BPMSs, such as Camunda 10 and Bonita BPM. 11

3.1.4. Research proposals

Due to the limitations of the process modelling notations and systems for responsibility management a few research proposals have been developed to support the assignment of different responsibilities to process activities and the automation of such responsibility-aware process models. In particular, Grosskopf ( 2007 ) extended BPMN 1.0 to support accountability.

Resource Assignment Language (RAL) (Cabanillas et al. 2015b ; Cabanillas, Resinas, and Ruiz-Cortés 2011a ) is an expressive language for defining resource assignments that supports all the creation patterns (Russell et al. 2005 ). RAL is independent of the process modelling notation. Therefore, it can be decoupled from the process model or it can be integrated in it, as shown in Cabanillas, Resinas, and Ruiz-Cortés ( 2011 ) with BPMN. Furthermore, RAL is suited to be used for modelling any kind of responsibility as long as that is supported by the process modelling notation with which it is used.

A graphical notation with a similar expressive power than RAL (RALph) was designed to allow for graphically defining resource assignments in process models (Cabanillas et al. 2015a ). Similarly to the case of RAL, RALph is not actually equipped with support for modelling specific responsibilities. Therefore, that support depends on the process modelling notation with which RALph is used. Otherwise, the notation should be extended.

To a greater or lesser extent, these proposals only address responsibility modelling and they do not provide details about the implications on the execution of the responsibility-aware process models generated.

Since process execution is also a concern and the different responsibilities modelled with a process should also be considered at run time, the approach described in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ) presented a pattern-based mechanism for including specific activities in a BPMN model that represent accountability, support, consultancy and notification functions. The result is thus a responsibility-aware executable process model that can be automated by BPMN process engines. However, due to the extra elements added in order to include RASCI responsibilities, the model is likely to become unreadable and deviate from the original one, hence turning out to be less eligible for other purposes, such as documentation, due to the large amount of implementation details. As an illustrative example, applying this technique to the scenario described in Section 2 , the number of process activities would increase from 5 to 15. Moreover, the RASCI patterns defined are fixed and hence, there is no flexibility for adapting the joint use of the responsibilities to the organisational needs. Our preliminary work in this area (Cabanillas, Resinas, and Ruiz-Cortés 2012 ) also generated executable process models provided with RASCI information avoiding the aforementioned readability problem. However, flexibility remained an issue, as the way of including responsibilities in the process model was fixed.

3.2. Template-based process modelling

Process templates have been defined with different notations and used for different purposes and in different domains. For instance, BPMN templates were defined for generating so-called business process studios by means of model transformations (Mos and Cortés-Cornax 2016 ). Configurable processes rely on process fragments or templates for adapting an abstract process to a specific context. They have been used, e.g., for addressing the problem of variability in service implementation, a.k.a. service differentiation, with BPEL (Tao and Yang 2007 ) as well as the problem of reference model implementation with Configurable epc (C-EPC) (Recker et al. 2005 ). In addition, configurable processes have been applied in industry to solve real problems, as described in Gottschalk, van der Aalst, and Jansen-Vullers ( 2007 ) for SAP processes.

Most of these approaches, however, focus on control-flow aspects of business process and disregard other perspectives. Nevertheless, notations like the one presented in La Rosa et al. ( 2011 ) allow for defining configurable process models considering control flow, data and resources. These three perspectives are also supported by a template-based approach for modelling process performance indicators (del-Río-Ortega et al. 2016 ).

Support for responsibility management in business processes.  √ indicates that the feature is supported,  ≈  indicates that the feature is partly supported, − indicates that the feature is not supported, and n/a indicates that the evaluation criterion is not applicable.

All the previous approaches have shown benefits for the purpose they were conceived. However, none of them has taken into consideration activity responsibilities since they did not specifically focus on the organisational perspective of business processes.

4. Motivation and research method

To conduct this research we have followed design science principles as suggested by Hevner et al. ( 2004 ) and, in particular, we have applied the design science research methodology (DSRM) (Peffers et al. 2007 ) as follows:

• The responsibilities supported, in most cases in terms of the well-known RASCI responsibilities (Website 2014 ).
• The way in which responsibilities are modelled, differentiating between ‘in’ (i.e., the resource-related information is represented within the process model) and ‘out’ (i.e., the resource-related information is separated from the process model). This relates to the degree of decoupling.
• The support for the automated execution of processes including the different responsibilities.

Several conclusions can be drawn from this analysis. First, many proposals from industry (notations, modelling tools and BPMS) recognise the importance of modelling different types of responsibilities for each activity and provide some kind of support for them, although this support is limited to modelling and documentation purposes, i.e., business-oriented process models.

Second, the RASCI concepts seem to be the most extended mechanism to model responsibility management in business processes. Indeed, many software modelling tools and BPMS use them and automatically generate RAMs to model or document responsibilities. The biggest limitation of this way of proceeding is that the expressiveness of RAMs for resource assignment in business processes is restricted to three creation patterns, namely, Direct-based Distribution, Role-based Distribution and Organisational Distribution . Patterns like SoD or BoD are not supported by default by RAMs . This is not a significant problem if RAMs are used solely for documentation purposes because they can be accompanied with a description of these concerns in natural language. However, it is an important limitation if RAMs were used as the model to guide the automated execution of a process in a BPMS.

Finally, the support for automating the resulting responsibility-aware process models is limited. When existing, it either does not cover all the RASCI responsibilities or is not flexible enough to accommodate different interaction patterns between the people that collaborate in an activity with different responsibilities.

The result is that there is a gap between the responsibility types that are modelled in business-oriented process models such as the one described in the running example ( Section 2 ) or the use case ( Section 7.3 ) and the ability of BPMSs to automate their execution. Consequently, to enforce their correct execution, it is necessary to implement them by manually adding activities for them in the executable process model. This is not desirable, especially when the process model has many activities (it is not uncommon to find process models with more than 15 activities (Mendling, Reijers, and van der Aalst 2010 )) and there are several responsibilities for each activity (which is not uncommon either, e.g., in best practice frameworks). For instance, in our running example, despite its small size, at least 8 activities have to be added manually to model all responsibilities, one for each responsibility type assigned to an activity. The problem gets even worse when either the process or the responsibility assignment changes, because the modified process has to be changed by hand again. This involves first checking what has changed, then understanding the impact of this change in the modified process model and finally, changing the modified process model appropriately. This time-consuming and error-prone task is the problem we are facing in this research.

• G1. Generalisability: in order to adapt to the organisational structure, the responsibility modelling technique should be able to deal with any kind of responsibility instead of sticking to a predefined set of them
• G2. Flexibility: in order to increase usability, the approach should leave freedom to each organisation to define how the interaction between the people that collaborate in an activity with different responsibilities takes place. Furthermore, the process flow chosen has a direct impact on process performance, as described in Lam, Ip, and Lau ( 2009 ).
• Design and development phase : This phase involved the design and development of two novel artefacts, namely, (i) the RAM BI metamodel, which extends RAMs with information required for process execution (cf. Section 5 ), and (ii) a template-based technique called RAM2BPMN for transforming such information into BPMN elements that can be interpreted by a BPMN process engine (cf. Section 6 ).
• Demonstration phase : This phase involved the development of a software prototype that effectively showed that it was possible to transform the information of RAM BI models into BPMN elements automatically using templates. Furthermore, it also showed that the solution is platform independent since it was used to generate process models that were executable in different BPMS (cf. Section 7.1 ).
• Evaluation phase : The proposal has been evaluated in two different directions. On the one hand, we have used our approach to model interaction patterns between the people that collaborate in an activity with different responsibilities to validate that our solution was flexible enough to accommodate those interactions (cf. Section 7.2 ). On the other hand, we have applied our approach to two real scenarios in order to show its applicability and the advantages gained by its use (cf. Section 7.3 ).

These phases were developed by means of several iterative cycles. In an initial cycle, we partially defined the problem, reviewed existing research literature and current solutions from industry, and developed an initial solution that included a first version of the RAM BI metamodel and a predefined interaction for RASCI responsibilities (Cabanillas, Resinas, and Ruiz-Cortés 2011b ). Then, subsequent cycles were necessary to refine the RAM BI metamodel, to make the approach independent of RASCI responsibilities and to give flexibility to the approach by means of the template-based technique.

5. RAM BI : resource assignment matrices with binding information

A typical RAM enables an assignment of resources based on the organisational entities placed at the columns of the matrix, which usually are organisational roles. This limits the expressiveness of the resource assignments in two directions. On the one hand, it is not possible to set additional constraints related to the person assigned to the activity, such as requiring specific capabilities or excluding performers of previous activities to enforce an SOD . For instance, in the example of Section 2 the PhD student that is responsible for the activity Send Authorisation is not any PhD student but the one that prepared the authorisation form. On the other hand, it limits the ability to put additional constraints on the organisational entities used as columns. For instance, in the same example, the role project coordinator should not refer to any project coordinator, but the coordinator of the project to which the authorisation that is being requested belongs.

In the remainder of this section, we first introduce the RAM BI metamodel, then we present its semantics and at last, we provide details of a specific instantiation of the metamodel with a specific resource assignment language.

5.1. RAM BI metamodel

RAM BI matrices (i.e., RAMs with binding information) is the extension we propose to overcome these limitations of the expressiveness of RAMs. It complements a RAMs with binding information that provides the specific conditions that the individuals have to fulfil in order to participate with a specific type of responsibility in an activity.

These conditions are expressed using a resource assignment language. From an abstract perspective, a resource assignment language ℒ is composed of a set of expressions that use the different entities that are part of an organisational metamodel, such as people, roles or positions, for selecting elements of an organisational model defined according to the organisational metamodel. In other words, it can be seen as a query language for the organisational model. Accordingly, the semantics of a resource assignment language ℒ can be defined by a function m a p ℒ that maps each expression in ℒ to a set of elements of the organisational model that is being queried.

For instance, a resource assignment language ℒ that queries an organisational model defined according to the organisational metamodel depicted in Figure 2 could have expressions that select people that play a certain role (e.g., selecting all people that have the role researcher ) or that have performed a previous activity in the process (e.g., selecting all people that have performed activity Prepare authorisation in the current instance), amongst others. Furthermore, a resource assignment language also can have expressions to select not only people but other elements of an organisationl model such as organisational units or roles. For instance, we can query the model to obtain all positions that belong to an organisational unit.

Excerpt of the organisational model described by Russell et al. ( 2004 ).

Using a resource assignment language, a RAM BI model can be formalised as follows.

Let 𝒯𝒟 be the responsibility types that can be used in a RAMs, and let ℒ be a resource assignment language where κ and χ are the set of expressions to select organisational entities and people, respectively. A RAM BI is a tuple M = (𝒜, 𝒪ℛ, ℬℛ,  o c ,  a r ) , where:

• 𝒜 = { a 1 , ...,  a n } is the set of activities that appear in the rows of the RAM BI , 𝒜 ≠ ∅ .
• 𝒪ℛ = { o r 1 , ...,  o r n } is the set of organisational roles that appear in the columns of the RAM BI , 𝒪ℛ ≠ ∅ .
• ℬℛ ⊆ 𝒜 × 𝒪ℛ × 𝒯𝒟 is the set of BoundRole s defined in M . A BoundRole ( a ,  o r ,  t d ) represents a type of responsibility t d assigned to a Role o r of the organisational model for a given Activity a of a process. In other words, BoundRoles represent the letters that appear in the cells of a RAM.
• o c :ℬℛ →  κ is a partial function that assigns an organisational context to a BoundRole .
• a r :ℬℛ →  χ is a partial function that assigns additional restrictions to a BoundRole .

In this definition, the binding information is provided by functions o c and a r , namely: (i) o c indicates additional restrictions that apply to the organisational entity used as column, such as the organisational unit to which the role must belong for a specific BoundRole ; and (ii) a r is used to specify restrictions on the people that can have a certain responsibility in an activity, e.g., to have knowledge on a specific subject or to have performed a previous activity in the process.

Table 4 defines a set of auxiliary functions that are used in the following sections to manipulate the RAM BI matrix M .

Auxiliary functions for the RAM BI metamodel.

5.2. Semantics of the RAM BI metamodel

Giving semantics to a RAM BI means to determine which are the people that can have a certain type of responsibility in a given activity according to the information included in a RAM BI model. To do so, we rely on a function m a p ℬℛ that determines the people that fulfill the conditions of a BoundedRole . Intuitively, this function can be defined as follows:

• If the BoundedRole b has no binding information (i.e., o c ( b ) and a r ( b ) are undefined), then the people that fulfill the condition of b are those people that play the role identified in the BoundedRole (e.g., any researcher).
• If the BoundedRole b has an organisational context defined (e.g., a reserch project), then the people that fulfill the condition of b are those people that play the role identified in the BoundedRole within the organisational context provided (e.g., any researcher in a specific research project.)
• If the BoundedRole b has an additional restriction defined (e.g., being responsible for activity Prepare authorisation), then the people that fulfill the condition of b are those people that play the role identified in the BoundedRole and fulfill the additional restrictions (e.g., researchers that are responsible for activity Prepare authorisation.)
• Finally, if the BoundedRole b has both an organisational context and an additional restriction defined, then the people that fulfill the condition of b are those that play the role identified in the BoundedRole within the organisational context provided and fulfill the additional restrictions.

This can be formalised as follows.

Let O be an organisational model with P people. Let ℒ be a resource expression language that can query model O whose semantics is defined by function m a p ℒ . Let O C be the set of all possible organisational contexts for a role o r  ∈ 𝒪ℛ in model O , and let p ( o r ,  o c ) ⊆  P be the set of people that have role o r in context o c according to O . The semantics of each BoundRole of a RAM BI M = (𝒜, 𝒪ℛ, ℬℛ,  o c ,  a r ) is defined by function m a p ℬℛ :ℬℛ → 𝒫( P ) as follows:

This function gives semantics to the resource assignment specified in each BoundRole (i.e., in each cell of the RAM BI ). However, this does not specify the semantics when there are several BoundRoles with the same responsibility for the same activity (i.e., the same responsibility appears in more than one cell in the same row), which is common for responsibilities like Consulted, Support or Informed. Since no formal semantics for RAMs have been defined, several different interpretations can be done in different contexts:

• Only one person can do the responsibility. This person must fulfil the conditions of the resource assignment specified in any of the bound roles defined for the same responsibility and the same activity.
• Only one person can do the responsibility but this person must fulfil the conditions of the resource assignment specified in all the bound roles defined for the same responsibility and the same activity.
• Several people can do the responsibility; one for each bound role defined for the same responsibility and the same activity. Each of these people must fulfil the conditions of the resource assignment specified for their respective bound role.

These interpretations can be formalised as follows.

Let M = (𝒜, 𝒪ℛ, ℬℛ,  o c ,  a r ) be a RAM BI model, and let 𝒯𝒟 be the type of responsibilities that can be used in M :

• The semantics of the first interpretation is defined as function o r M a p M :𝒜 × 𝒯𝒟 → 𝒫( P ) as follows: o r M a p M ( a ,  t d ) = ∪ b r ∈ f i l t e r M ( a , t d ) m a p ℬℛ ( b r )
• The semantics of the second interpretation is defined as function a n d M a p M :𝒜 × 𝒯𝒟 → 𝒫( P ) as follows: a n d M a p M ( a ,  t d ) = ∩ b r ∈ f i l t e r M ( a , t d ) m a p ℬℛ ( b r )
• The semantics of the third interpretation is defined as function m a p M :𝒜 × 𝒯𝒟 → 𝒫(𝒫( P )) as follows: m a p M ( a ,  t d ) = { m a p ℬℛ ( b r )| b r  ∈  f i l t e r M ( a ,  t d )}

The additional constraints included by binding information may cause undesirable side effects if there is no person in the organisational model that meets all the constraints. This could happen, for instance, if we set as additional constraint for the clerk that is responsible for activity Prepare authorisation in the running example that she has the capability of speaking English and it turns out that there is no clerk with such a capability in the project. The identification of these situations is called consistency checking and it has been studied in detail in the literature (Cabanillas et al. 2015b ). Specifically, a resource assignment, such as the one specified by a RAM BI model, is consistent if it is always possible to find a potential participant for an activity during any execution of the process for any responsibility type that appears in the resource assignment.

Since inconsistencies are caused by the constraints included by binding information specified in a resource assignment language, the ability to check the consistency of a RAM BI model is directly related to the ability to check the consistency of the resource assignment language used in its binding information. This is possible with some resource assignment languages such as RAL (Cabanillas et al. 2015b ). In the next section we introduce RAL and detail how consistency checking can be implemented with it.

5.3. Using RAM BI with RAL

As discussed in the previous sections, a RAM BI model relies on an external resource assignment language to define its binding information. Next, we illustrate how RAM BI can be used with RAL (Cabanillas et al. 2015b ). We have chosen RAL because of its high expressive power, capable of supporting all the creation patterns (Cabanillas, Resinas, and Ruiz-Cortés 2011 ) and because it has a well-defined semantics that enable the implementation of analysis operations such as consistency checking. However, other resource assignment languages could also be used.

RAL is a modular (DSL) that specifies a set of expressions and constraints to define resource assignment conditions independently of any specific process modelling notation. It is composed of five modules:

• RAL Core allows defining generic resource assignment expressions based on resource’s characteristics. For instance, it allows assigning an activity to one of two specific resources with the expression (IS Betty) OR (IS Anna) .
• The occupies relation is supported by PositionConstraint , e.g., HAS POSITION AssistantProfessor.
• The isMemberOf relation is supported by UnitConstraint , e.g., HAS UNIT InstituteForIB.
• The participatesIn relation is supported by RoleConstraint , e.g., HAS ROLE Researcher, or HAS ROLE Researcher IN UNIT InstituteForIB.
• The hasCapability relation is supported by CapabilityConstraint , e.g., HAS CAPABILITY PhDdegree.
• RAL Data and RAL DataOrg allow selecting individuals, positions, roles or organisational units indicated in a data field of a data object of a process, according to the BPMN (OMG 2011 ) specification of the business process data perspective. 12 For instance, the following expression specifies that the resource allowed to execute an activity is indicated in the data field Applicant of the data object Application : IS PERSON IN DATA FIELD Application.Applicant.
• RAL AC stands for RAL Access-Control and it extends RAL Core to enable the specification of access-control constraints, such as bod (e.g., IS ANY PERSON responsible for ACTIVITY SubmitPaper) and sod (e.g., NOT(IS ANY PERSON responsible for ACTIVITY FillForm)) .

The use of a specific resource assignment language in a RAM BI model has an impact concerning the type of binding information that can be used in it. Specifically, for RAL it involves the following aspects:

• RAL has two expressions to select people according to roles, namely: HAS ROLE r and HAS ROLE r IN UNIT u . Therefore, the organisational context that can be given in RAL to an organisational role is always the organisational unit in which the role is played (e.g., the role Coordinator can be played in a department or a project.) Consequently, expression κ refers to an organisational unit and p ( o r ,  c ) can be resolved using RAL expression HAS ROLE or in UNIT c.
• All previously described RAL resource assignment expressions can be used to add additional constraints to a BoundedRole . This means that all the creation patterns (Cabanillas, Resinas, and Ruiz-Cortés 2011 ) can be used to select people in RAM BI models. For instance, it is possible to add additional constraints related to the capabilities of the resource usingRAL Org expression HAS CAPABILITY capabilityID or based on the responsibilities it takes in other activities using aRAL AC expression such as IS ANY PERSON responsible for ACTIVITY a .

Figure 3 illustrates in a simplified way the use of the RAM BI metamodel with RAL using as example activity Register at Conference of the scenario described in Section 2 and Table 2 . As depicted in Figure 3(a ), the person with responsibility type Responsible is the researcher who prepared the authorisation request. Hence, there is a bod access-control constraint defined with RAL AC. As for responsibility type Consulted, it is assigned to the coordinator of the project that funds the trip to the conference, indicated in the data object Authorisation form . Therefore, the organisational context is defined with aRAL DataOrg expression.

RAM-BI models and RAL expressions for activity Prepare Authorisation.

Finally, the well-defined semantics of RAL enables the implementation of several analysis operations such as consistency checking (Cabanillas et al. 2015b ). Therefore, to check the consistency of a RAM BI model that uses RAL as its language for binding information, we just need to translate a RAM BI model into a RAL expressions and then leverage the consistency checking operation that has been implemented for RAL . This translation can be easily done using RAL expressions HAS ROLE or for the case when o c ( b ) and a r ( b ) are undefined, HAS ROLE or IN UNIT u for the case when o c ( b ) is defined and the operator AND to compose expressions for the case when a r ( b ) is defined. The result is function m a p B R R A L : B R → R A L E x p r that can be defined as follows:

Finally, o r M a p M R A L and a n d M a p M R A L , both can be straightforwardly defined by joining the RAL expressions obtained by m a p B R R A L for each bound role defined for the same task duty and the same activity with OR and AND, respectively.

6. RAM2BPMN : using RAM BI with BPMN models

RAM2BPMN is our approach to enable current BPMS to execute BPMN processes in which people with different responsibilities collaborate to complete process activities. An overview of RAM2BPMN is depicted in Figure 4 . The core idea is to take a BPMN model without resource-related information and a RAM BI model as inputs and to automatically generate a new BPMN model in which the only responsibility defined for each activity is Responsible, but which includes new activities to model the semantics conveyed by the other responsibilities included in the RAM BI model. More specifically, RAM2BPMN turns every activity for which some type of responsibility different than Responsible is defined into a subprocess. We refer to the subprocesses created during the transformation as RAM subprocesses . A RAMs subprocess is a regular BPMN subprocess that includes the specific tasks for all the responsibilities that people may have during the execution of the activity of the original process. RAMs subprocesses are created from collaboration templates . A collaboration template specifies how people with different responsibilities interact with each other to carry out an activity of a process. The collaboration template used is chosen at design-time amongst a library of templates depending on the specific requirements of the activity.

Overview of RAM2BPMN.

We have opted for this approach for several reasons. First, because it ensures that RAM2BPMN can generate models for any BPMS because the generated model only relies on defining the resource responsible for each activity, which is the only responsibility supported in BPMN by default. Second, because the additional complexity that results from including the information about different responsibilities is found only inside the RAMs subprocesses and hence, it does not affect the overall understandability of the initial process. Furthermore, the only difference between the resulting model and the initial one from the visualisation standpoint is that tasks are transformed into collapsed subprocesses.

Figure 5 depicts an example of template 13 that models the interaction of the RASCI responsibilities as it was introduced in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ). This interaction establishes that the approval action (Accountable) takes place after the completion of the work developed for the activity (Responsible), and only then the notification action (Informed) can be performed. There is also a loop to redo the work in case it does not get the approval by the resource with the responsibility Accountable. Actions of responsibility Consulted and responsibility Support are considered to take place in parallel with the task performed by the resource with responsibility Responsible. Finally, the template includes two decision activities performed by the resource with responsibility Responsible to decide whether support or consultation are required. The template also has some placeholders that have to be filled with information that comes from the RAM BI model and the definition of the activity in the BPMN model.

Example of a template that models the interaction of RASCI responsibilities as it was introduced in in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ).

Another relevant aspect is that not all possible RAM BI models can be used with the template depicted in Figure 5 . In particular, it requires that there is exactly one bound role for responsibility responsible and at most one bound role for responsibility accountable for each activity, whereas there can be any number of bound roles for the other responsibilities. In general, each template may require a specific cardinality for the responsibilities of a RAM BI model.

The procedure that creates a RAM subprocess from a template for a specific activity of the process is the instantiation of a template . This procedure uses the information of the RAM BI and the BPMN models to fill the placeholders of the template with activity-specific information and to compose the RAMs subprocess, when necessary. For instance, Figure 6 depicts the result of the instantiation of the template in Figure 5 .

Example of the instantiation of static template in Figure 5 for activity Register at Conference of the process defined in Figure 1 .

The advantage of using templates is that each organisation may define their own library of templates to specify how people involved in an activity of a process with different responsibilities interact with each other, thus providing flexibility on the way these interactions are carried out. Furthermore, although one template is usually used for all activities of a process or even several processes, it may be the case that for a specific activity (or process) one might be interested in using a different template. For instance, for a time-sensitive activity, one might be interested in a template in which the person accountable for the activity does not only supervise the outcome of the activity but also the completion time. This can be done, e.g., by designing a template in which the task performed by the person responsible for the activity has a timer that triggers a supervision task performed by the person accountable for the activity when a predefined time has passed. Section 7.2 discusses some examples of different templates that can be used with RASCI responsibilities.

The support for different templates for each activity in the process is modelled by means of function t e m p l that links each activity to the template that must be used:

(Assignment of templates to activities) Let A be the set of activities of a process and 𝒯 be the set of all possible templates, function t e m p l : A  → 𝒯 specifies which template is used for each activity of the process.

RAM2BPMN: Including resource assignment information from RAM BI into a BPMN model

1: IN : BPMN; M  = ( 𝒜; 𝒪 R ; ℬ R ;  o c ;  a r ); templ

2: Pre : 𝒜 ⊆ activities of process BPMN

3: Pre : The resource assignment of M is consistent with BPMN

4: Pre : compatible(M; templ)

5: OUT : BPMN’ model with resource information

6: BPMN ’ ← BPMN

7: for all activity a in the business process BPMN do

8:   if anyTD(a) then

9:    T ← templ(a)

10:    subprocess a ← instantiation of template T using BPMN and M

11:   replace in BPMN’ activity a by subprocess a

12:   end if

13: end fo r

14: return BPMN’

Based on the concept of template and its instantiation, the RAM2BPMN algorithm can be formalised as detailed in Algorithm 6. The input is a resource-unaware BPMN model, i.e., a model without resource assignments, ( b p m n ); a RAM BI model ( M ), and a t e m p l function.

The algorithm has three preconditions, namely: the activities of the RAM BI model must be a subset of the activities in the BPMN model (specifically, those that cannot be automated); the resource assignment of M must be consistent with bpmn (cf. Section 5.2 ), and the templates chosen by the t e m p l function must be compatible with the RAM BI model in terms of cardinality (cf. Section 6.1 ).

The algorithm can be outlined as follows. First, the b p m n model is cloned into b p m n ′ (line 6). Then, the following three steps are executed for each activity of the process (line 6) that has a resource assignment in the RAM BI model ( a n y T D ( a ) ) (line 6). First, the template associated to the activity is selected (line 6). Second, the template is instantiated using the resource assignment information provided by the RAM BI model (line 6). Finally, the activity of b p m n ′ is replaced by a subprocess created using the template instantiated in the previous step (line 6). The last step of the algorithm is to return the new b p m n ′ in which activities have been replaced by RAMs subprocesses (line 6.

Next, we delve into the two parts of the algorithm that require more details, namely: the concept of compatibility between RAM BI model and template (line 6), and the definition and instantiation of templates (line 6). The consistency checking has already been discussed in Section 5.2 .

6.1. Cardinality of templates

As discussed before, not all RAM BI models can be used with a specific template because templates may require a specific cardinality for the responsibilities of the RAM BI model (e.g., they may limit the number of people with responsibility Responsible to exactly one). The cardinality of a template is defined with the template together with the specification of the interaction it models, such as the one in Figure 5 , and can be formalised as follows.

(Cardinality of a template) Let T be a template and let 𝒯𝒟 be the set of responsibilities supported by T . The cardinality of each responsibility is defined by means of function c a r d T :𝒯𝒟 → IN 0  × (IN 0 ∪ { n } ) such that c a r d T ( t d ) = ( x ,  y ) means that the template requires at least x bound roles and at most y bound roles for a responsibility t  ∈ 𝒯𝒟 , such that x  ≤  y . If y =  n , then any number of bound roles greater than or equal to x is allowed.

For convenience, for each c a r d T ( t d ) = ( x ,  y ) we define functions m i n T ( t d ) =  x and m a x T ( t d ) =  y to represent the minimum and maximum number of bound roles for a responsibility t  ∈ 𝒯𝒟 .

Based on the cardinality of a template, the compatibility of a template and a RAM BI model for an activity can be defined. Intuitively, a template is compatible with a RAM BI model for an activity A if all responsibilities specified in the RAM BI model for A fulfil the cardinality restrictions specified in the template. This can be formalised as follows:

(Compatibility of a template) Let M = (𝒜, 𝒪ℛ, ℬℛ,  o c ,  a r ) be a RAM BI model , 𝒯𝒟 M be the set of responsibilities used in M , c a r d be the cardinality function of a template T , and 𝒯𝒟 T be the set of responsibilities used in T . The template T is compatible with the RAM BI model M for an activity a  ∈ 𝒜 iff the number of bound roles specified in M related to activity a for each responsibility is within the constraints specified by the cardinality function c a r d :

Finally, equipped with this definition, it is easy to define the compatibility of an assignment of templates to activities ( t e m p l ) with a RAM BI model as follows.

(Compatibility of an assignment of templates) Let M = (𝒜, 𝒪ℛ, ℬℛ,  o c ,  a r ) be a RAM BI model and t e m p l an assignment of templates to activities. The assignment of templates to activities t e m p l is compatible with M if and only if it assigns a template that is compatible with M for each activity in 𝒜 :

6.2. Definition and instantiation of templates

Figure 5 depicts an example of template for RASCI responsibilities. However, this shows just one possible way in which a template can be defined and instantiated. As a matter of fact, the only requirement imposed by the RAM2BPMN algorithm is that the result of the instantiation should be a subprocess configured using information from the BPMN and the RAM BI models. This means that different approaches can be used to define templates and their choice depends on the characteristics of the template that is being modelled as discussed in Section 6.2.3 .

In the remainder of this section, we detail two different approaches for the definition of collaboration templates and discuss their advantages and drawbacks, although other approaches could also be designed. To illustrate them, we use the aforementioned interaction of RASCI responsibilities introduced in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ).

6.2.1. Static templates

A static template is a process model defined in BPMN (cf. Figure 5 ) that details the interaction between people with different responsibilities within an activity with just two peculiarities:

• Placeholders are used in the resource assignments and the names of the activities that will be replaced with values obtained from the RAM BI and/or the BPMN models during instantiation.
• XOR gateways are included in the process for enabling or disabling the activities specific to a responsibility. To this end, placeholders can also be used in the conditions of the gateways.

The instantiation mechanism of these static templates just involves the replacement of all the placeholders that appear in the template. This is done by iterating over all these placeholders and replacing their value by one obtained from the RAM BI or the BPMN model. Table 5 depicts a list of the placeholders that can be used in the static template and their replacement.

Frequent placeholders and their replacement.

Figure 5 depicts an example of a static template and Figure 6 depicts its instantiation. The template models the interaction of RASCI responsibilities introduced in Cabanillas, Resinas, and Ruiz-Cortés ( 2011b ) and includes gateways to bypass parts of the process in case the responsibility is not assigned for the activity. The template also has placeholders for the name of the activities so that they include the name of the activity for which the RAM subprocess is created, and the resource assignments (expressed using BPMN annotations in the diagram). In particular, activities Provide support, Provide information and Approve activity are assigned to the responsibilities Support, Consulted and Accountable, respectively. The other activities, which include the two decision and the two assessment activities, are performed by the responsibility Responsible. In the latter case, the RAL expression

is used. This allows every element within the subprocess to make reference to the performer of the activity (i.e., the new subprocess), since according to BPMN (OMG 2011 ) the allocation related to a subprocess is made before starting the activities that compose it. Note also that the responsibility Informed is different from the others because it refers to the target of the notification action (i.e., the people that are informed), not to the holder of the responsibility like in the rest of cases. Furthermore, given the definition of the responsibility Informed (cf. Section 3.1.1 ), it is reasonable to consider it an external participant of the process because, independently of her responsibilities with respect to other process activities, for the activity in question she is a target and not an executor. For this reason, the activities that correspond to the responsibility Informed are modelled as send tasks (OMG 2011 ).

6.2.2. Fragment-based templates

Static templates provide a simple yet useful mechanism to define templates. However, more complex mechanisms can be devised. One source of inspiration for these mechanisms are configurable business processes (La Rosa et al. 2011 ). A configurable process model captures a family of related process models in a single artifact. Such models are intended to be configured to fit the requirements of specific organisations or projects, leading to individualised process models (van der Aalst et al. 2010 ). Therefore, templates can be seen as a type of configurable business processes and their instantiation can be seen as a configuration of them (Kumar and Yao 2012 ). Consequently, most approaches for defining and setting up configurable business processes can be adapted for defining collaboration templates.

In particular, fragment-based templates are based on the approach proposed in Kumar and Yao ( 2012 ) for designing flexible process variants using templates and rules. The templates are made up of two different elements that can change from template to template, namely: a set of process fragments, at least one for each responsibility; and a composition algorithm that is used for putting together all those fragments and for enabling or disabling the tasks specific to a responsibility.

Fragments must be subprocess graphs with single entry and single exit nodes (also denoted as hammocks in graph literature (Weber, Reichert, and Rinderle-Ma 2008 )) that represent the tasks that are necessary to carry out a given responsibility. Not only the same placeholders as with static templates but also ad-hoc placeholders can be used in the fragments. The value for these placeholders must be provided by the composition algorithm. Figure 7 depicts an example of fragments that belong to a fragment-based template (more examples can be found in Section 7.2 ). Specifically, five process fragments named R-fragment, A-fragment, S-fragment, C-fragment, and I-fragment are defined, one for each RASCI responsibility. Each of them have their corresponding placeholders in the names of the activities and the resource assignments.

Example of the fragments defined for each of the RASCI responsibilities in a fragment-based template.

Concerning the composition algorithm, the idea is to combine the accompanying process fragments in a meaningful way based on the information provided by the RAM BI model and the BPMN model. To describe how the process fragments are composed together, we suggest the use of change patterns (Weber, Reichert, and Rinderle-Ma 2008 ). Change patterns and in particular, a type of them called adaptation patterns, allow users to structurally modify a process model using change operations defined in terms of the process model (e.g., adding an activity in parallel to another one) instead of change primitives defined in terms of the underlying graph (e.g., adding a single node, two control flow edges, and the connectors between them) (Weber, Reichert, and Rinderle-Ma 2008 ). A consequence of this is that change operations provide a compact way of defining changes on a process because each change operation involves one or more change primitives (e.g., adding an activity in parallel involves up to seven change primitives). Furthermore, these changes tend to be easier to understand because they are defined in a higher-level way. All these reasons make change operations a suitable language to define these compositions. Table 6 shows a summary of the most frequent change operations.

Frequent change operations for the implementation of fragment-based templates.

Together with change operations, placeholders defined in Table 5 can also be used as variables and functions in the composition algorithm. The placeholders of the process fragments are replaced during the execution of the composition algorithm. This is done by means of function replace , which receives the fragment with placeholders and returns the same fragment with all placeholders replaced with their corresponding value. The values for ad-hoc placeholders must be provided as parameters of function replace .

Algorithm 2 shows an example of composition algorithm of a fragment-based template that composes the fragments defined in Figure 7 . This algorithm is executed as part of the instantiation of the fragment-based template it belongs to, which means that it would be invoked within line 10 of Algorithm 1. The algorithm starts by replacing the placeholders in the fragment for the responsibility Responsible (line 8). Then, if responsibility types support or consulted have been defined in the RAM BI model (lines 5 and 8) it inserts in parallel fragments for the responsibilities Support and Consulted (lines 6 and 9, respectively). Next, if responsibility type accountable has been defined in the RAM BI model (line 11), it inserts sequentially the fragment for the responsibility Accountable (line 12) and embeds the whole process in a loop based on the decision made by the person accountable for the activity, i.e., whether the work is approved or not (line 13). Finally, if responsibility type informed has been defined in the RAM BI model (line 15) it inserts a fragment for the responsibility Informed for each organisational role that must be informed. This is done in several steps. It iterates over all organisational roles with responsibility Informed defined in the RAM BI model for the given activity (line 17). For each of them, it obtains its resource assignment and name (lines 18 and 19) and it inserts in parallel fragments for each of them in a temporal variable i n f o r m F r a g m e n t (lines 20–23). Finally, it inserts sequentially all these parallel fragments contained in i n f o r m F r a g m e n t (line 26). Figure 8 depicts the instantiation obtained after executing the composition algorithm for activity Register at conference according to the RAM BI model depicted in Table 2 .

Example of the composition algorithm of a fragment-based template that support RASCI responsibilities

1: IN : 𝒯𝒟 = { R ;  A ;  S ;  C ;  I } are the RASCI responsibilities supported by this template.

2: IN : R – fragment; S – fragment;C – fragment;A – fragment; I – fragment are the fragments defined in Figure 7 .

3: OUT : composed fragment

4: base ← replace(R-fragment)

5: if hasTD(S) then

6:  base ← insertParallel(base, replace(S-fragment))

8: if hasTD(C) then

9:  base ← insertParallel(base, replace(C-fragment))

11: if hasTD(A) then

12:  base ← insertSequential(base, replace(A-fragment))

13:  base ← embedInLoop(base, not approved, approved)

15: if hasTD(I) then

16:  informFragment ← empty fragment

17:   for all br ∈ filter(I) do

18:    ra ← map M (br)

19:   name ← orM(br)

20:    if informFragment = empty fragment then

21:    informFragment ← replace(I-fragment, ra, name)

22:    else

23:    informFragment ← insertParallel(informFragment, replace(I-fragment, ra, name))

24:    end if

25:   end for

26:  base ← insertSequential(base, informFragment)

28: return base

Instantiation of the template depicted in Figure 2 for activity Register at Conference.

6.2.3. Discussion

The decision on which template mechanism to use depends on the requirements of the specific scenario in which they are being applied. Fragment-based templates enable reusing fragments in different templates. So, one can have a repository of different fragments for the same responsibility and combine them in different ways with different composition algorithms. In addition, fragment-based templates allow a more flexible definition since the composition algorithm provides a more fine-grained control of the results of the instantiation. For instance, in Figure 8 several inform fragments were added, one for each organisational role with the responsibility Informed in the RAM BI model, which is something that cannot be easily done with static templates. Finally, the subprocess obtained from fragment-based templates tends to be easier to understand since it only includes the responsibilities that have been assigned to the activity.

However, static templates are easier to build since they do not need a composition algorithm and hence, it is not necessary to deal with its implementation. Moreover, in fragment-based templates, it is harder to detect deadlocks or livelocks introduced during the instantiation because the composition algorithm may change the control flow depending on which responsibilities are enabled for the activity at hand. This does not happen in static templates, in which the control flow is the same all the time.

Therefore, the conclusion is that fragment-based templates should be used in cases in which we are interested in building templates that have many commonalities or in cases in which we require a more fine-grained control of the instantiation. Otherwise, static templates are more appealing since that approach avoids the complexity of developing the composition algorithm.

7. Validation

We have validated the feasibility of the approach with a reference implementation, its flexibility with a repository of templates for responsibility modelling on the basis of the RASCI responsibilities, and its applicability by using the approach with a real scenarion from the railway automation domain.

7.1. Implementation

We have developed a reference implementation of the RAM2BPMN algorithm as well as an editor for RAM BI models and a repository of templates. Furthermore, we have also implemented templates according to the modelling alternatives for the RASCI responsibilities described in Section 7.2 . An overview of the architecture designed to support the RAM2BPMN procedure is depicted in Figure 9 . A use case for the whole architecture is described as follows:

• A template designer builds a set of templates using a template editor and stores them in the template repository.
• A RAM BI model is defined for each BPMN model whose resource assignment we want to extend. To this end, a process designer uses the RAM BI Model Editor to define the RAM BI for the given BPMN model. Furthermore, she also chooses the template that should be applied to each activity from amongst the templates stored in the template repository.
• The RAM2BPMN engine uses the RAM BI model, the BPMN model and the templates from the template repository to obtain a BPMN with resource information.
• The BPMN model obtained in the previous step is deployed into a BPMS for its execution.

Overview of the architecture implement to support the RAM2BPMN procedure.

The templates used by the architecture can be either static templates or fragment-based templates. Furthermore, the architecture has been designed so that new types of templates could be easily added to the system.

All of the components that make up this architecture have been integrated into Collection of Resource-centrIc Supporting Tools And Languages (CRISTAL) (Cabanillas et al. 2012 ), a tool suite that provides support for the specification and automated analysis of the business process resource perspective. Information about the system can be found at

7.1.1. Templates editor

In our current implementation, there is no dedicated template editor. Instead, a BPMN model editor is used to model the static templates or the process fragments for the fragment-based templates and then, they are manually stored in the templates repository.

7.1.2. Templates repository

The templates repository is a Java library that stores the templates that have been designed for the organisation. Each template is composed of a template description file, which details the name of the template and its cardinality (cf. Section 6 ), and a set of companion files that are specific of each type of template. For instance, in a static template there is only one companion file, which is the BPMN model of the template; and in a fragment-based template there is one companion file for each process fragment and another one for describing the composition algorithm. The current implementation of the templates repository relies on a file-based storage for both template descriptions and companion files.

7.1.3. RAM BI model editor

It is a Web application developed in Java that allows the user to define the resource information associated with the activities of a BPMN model by filling in a RASCI matrix (Website 2014 ) and optionally adding binding information with RAL (Cabanillas et al. 2015b ), as shown in Figure 10 . This editor also allows the user to specify the template that should be used for each activity in the process, i.e., function t e m p l . Both the RAM BI model and the function t e m p l are serialised into the JSON file format.

Screenshot of the RAM BI Model Editor.

7.1.4. RAM2BPMN engine

The RAM2BPMN Engine implements the RAM2BPMN algorithm (cf. Algorithm 1). Specifically, it receives an XML file with the representation of a (resource-unaware) BPMN model, a JSON file with the RAM BI model and the function t e m p l , as well as a templates repository; and it returns the XML representation of the BPMN model with the RASCI information embedded in it. This functionality can be invoked from the user interface of the RAM BI Editor (cf. Figure 10 ) or from the command line.

The RAM2BPMN Engine supports the two types of templates described in Section 6 . Furthermore, the engine has been designed to allow new types of templates provided that the corresponding instantiation mechanism is integrated into the engine.

The resulting BPMN model generated is standard BPMN . Therefore, it can be manipulated in any process modelling tool and executed in a BPMN -compliant BPMS that has the required support for the resource assignment language used in the RAM BI model .

7.2. Modelling alternatives for RASCI responsibilities

One of the main advantages of our approach is that it does not enforce any specific behaviour for the people with different responsibilities that work together on an activity, but it allows the organisation to model the interaction that best suits its requirements. Furthermore, a library of templates can be created by the organisation so that they can be reused in different processes.

In the following we validate this flexibility by modelling alternatives that can be considered for RASCI responsibilities. We focus on RASCI responsibilities because they are a well-known responsibility set used in many different domains. The modelling alternatives are obtained from our experience in different projects in which RASCI responsibilities have been modelled as well as from patterns identified in both the industry (Effektif 2016 ; OASIS 2010 ) and the related research literature (Brambilla, Fraternali, and Vaca 2011 ; Barchetti et al. 2012 ). Because the requirements of each organisation may lead to different alternatives, this is by no means a complete catalogue, but rather an illustration of the wide variety of possibilities that our approach enables.

To avoid confusion, in this section we use activity to refer to the activity of the original business process for which a RAMs subprocess shall be created and we use task to refer to each of the activities that are part of the RAMs subprocess. The modelling alternatives are introduced using BPMN 2.0 modelling concepts (OMG 2011 ).

7.2.1. Responsible

This responsibility represents the execution of the activity itself and the coordination of other responsibilities involved in the execution of the activity such as Support, Consult or Informed. Therefore, the modelling alternatives for this responsibility come from the role it plays in the interaction with the other ones. Since these alternatives are also related to the other responsibilities, they are described in the section that discusses the respective modelling alternatives.

7.2.2. Accountable

The modelling alternatives of this responsibility are based on whether the accountability refers to the quality of the work performed or it also refers to the fact that the work is finished in a timely manner. The former is the typical interpretation of accountability whereas the latter is useful for time-sensitive activities.

If accountability refers to the quality of the work performed, it usually involves an explicit approval of the work previously performed by the person responsible for the activity. This implies adding a task for that purpose in the template. If the work is not approved, then a loop is in place so that the person responsible for the activity has to do it again. An example of this can be found in the task Approve Activity  <  activityName  >  of the template of Figure 5 . This behaviour has been identified as the Document Approval pattern in Effektif ( 2016 )

If accountability refers to making sure the work is finished in time, it involves the inclusion of a trigger in the process that notifies the person accountable for the activity that it has not been completed in a predefined amount of time. From a modelling perspective, this involves adding a time-based non-interrupting boundary event to the task performed by the person responsible for the activity such that if a certain time has passed and the task has not been completed, the person allocated to the responsibility Accountable is notified. This behaviour has been identified as the Timed Escalation pattern in Effektif ( 2016 ) and it is also the way accountability is dealt used in OASIS ( 2010 ).

Both alternatives are not exclusive and can be used together in the same template.

7.2.3. Support and consulted

The responsibilities Support and Consulted share some modelling alternatives because they have a very similar nature. Both of them involve a person to collaborate with the person responsible for the activity in its execution, being their degree of involvement in it the only difference between them. There is a wide variety of modelling alternatives for these two responsibilities based on several characteristics of the interaction, namely:

Template fragment that shows a modelling example for consult responsibility modelled as mandatory, done after some work, batches, group-based, system decided and not assessed.

• The moment in which support or consultation takes place . There are two options: it can be done in parallel to the main task, or it can be done after some initial work is done. From a modelling perspective, the former case can be modelled as in Figure 5 in which support and consultation tasks are performed in parallel with task Perform activity . The latter case usually involves three stages: a first stage in which the person responsible for the activity performs a preliminary task; a second stage in which support or consultation is required; and a third stage in which the person responsible for the activity merges the contributions received. This general scheme is followed by several patterns identified in the literature. For instance, in the Collaborative Editing pattern described in Barchetti et al. ( 2012 ), the person responsible for the activity first creates a draft and then this draft receives contributions from all the people with the Support responsibility for the activity. Finally, the person responsible for the activity collects all contributions and finishes the activity. The same pattern but for the Consulted responsibility is described in Effektif 2016 ) as the Multiple Stakeholder Input pattern. This is the pattern depicted in Figure 11 .

Template fragment that shows a modelling example for support responsibility modelled as optional, done in parallel, anytime, group-based, responsible decided and assessed.

• The number of people that can provide support or be consulted . In this case, the support or consultation can be asked to one person at a time or to a group of people at the same time. Modelling the former is straightforward and an example is depicted in Figure 5 . The latter can be modelled using either several parallel tasks or a multi-instance task. Using several parallel tasks is more appropriate if we want to control exactly how many people can provide support or consultation in parallel. It is also useful to have a higher degree of control concerning who decides who takes the responsibility (see next characteristic). Instead, if we are interested in providing freedom of choice at run time, multi-instance tasks are more convenient because all their parametrisation in terms of the number of parallel instances and conditions for cancellation are defined using run-time process data. Figures 11 and 12 depict this alternative.
• The decision on who performs the Support or Consulted responsibility . A RASCI matrix defines a set of candidates to provide support or consultation for a given activity. However, it does not mean that all of them have to provide it. Someone has to choose the specific people that shall be allocated to the responsibility. There are typically two options to do so: either the person responsible for the activity explicitly chooses the specific people from amongst all candidates, or the choice is done following the mechanisms provided by the BPMS. The former option requires having a task performed by the person responsible for the activity in which she chooses the people she wants for support or consultation. This choice is stored in a data object that is used to assign these people to the tasks that represent the support or consultation by means of RAL expression IS PERSON IN DATA FIELD x. An example is depicted in Figure 12 . This behaviour has been identified as the Required Role Assignment pattern in Effektif ( 2016 ). The latter option just requires using the RAL expression of the RASCI matrix assignment of the responsibility for the activity in the task that represents the responsibility. This is the way it is done in the template of Figures 5 and 11 .
• The explicit assessment of support or consultation . If support or consultation is explicitly assessed, then a task performed by the person responsible for the activity should be added after the task that represents the support or consultation. An example of this is depicted in Figures 5 and 12 by means of task Assess support for  <  activityName  >  .

In addition to the aforementioned characteristics, it is also possible to model the support tasks in a more structured manner. For instance, one may create a template in which the support follows a divide-and-conquer approach. In this case, the person responsible for the activity may decompose the work to be done in small work items and assign each of them to people that provide support to the activity. After all the contributions have finished, the person responsible for the activity can merge all the work items into a final result. This pattern is typically used in crowdsourcing scenarios (Kittur et al. 2011 ).

7.2.4. Informed

This responsibility is modelled as a task that notifies the people that have to be informed about the state of the activity. Its modelling alternatives are based on the following characteristics of the interaction and a version of them are also present in the support WS-HumanTask (OASIS 2010 ) provides to responsibility informed:

• The moment at which people are informed . The most typical behaviour is that people are notified at the end of the activity, i.e., after it has been performed and approved. This is how it is done in the example of Figure 5 . However, other moments for notification can be included in the template, such as when the work related to the activity has been performed and it is waiting for approval. One may also want to notify the state of the activity after a certain amount of time has passed. This can be modelled by attaching a notification task to a time-based non-interrupting boundary event placed in the task representing responsibility Responsible. Note that all these alternatives are not mutually exclusive and hence, they can be used altogether in the template.
• The person in charge of informing . The Informed responsibility is peculiar in the sense that the people assigned in the RASCI matrix are not the ones who perform the activity, but those who receive the notification. This means that someone has to perform the action of informing. One option is that the notification is sent automatically by the BPMS, e.g., as an email. If, on the contrary, the notification has to be sent by a person, that person might be either the person responsible for the activity or a person that provides support for the activity, since sending notifications can be seen as a supportive task.
• The way notifications are realised . The how is usually domain-specific and may cover a wide set of options that range from an email to a web service invocation or a telephone call, among others. Furthermore, how people are informed is strongly related to who performs the notification because some notification mechanisms are easier to automate than others. For instance, a notification that involves sending an email or an SMS is easier to automate than making a phone call.

7.3. Use case

We have applied our approch to a real scenario from industry in the railway automation domain, specifically to the process for releasing a new engineering system for a railway customer. The BPMN model of the process is depicted in Figure 13 .

An engineering process in the railway domain.

The process starts when a new agreement with a client has been signed by the project management team. A new repository is then created for the customer data by a technician and, at the same time, possible additional data are requested from the client by the engineer project manager. The next step is the actual engineering of the system, a subprocess in which the new system is built. It thus involves a large variety of resources and data coming from different data sources. The engineering project manager orchestrates and monitors the engineering tasks. Once the system is built, it must be tested before it is released for its use. That procedure takes place in a laboratory and comprises two steps: the test setup and the test execution. Prior to that, the testing project manager has to check whether the lab spaces needed must be set up for the test. Specific information about the lab settings and the system developed might be required in order to make such a decision. The employees of the organisation involved in the test setup and run steps are specialised in the execution of specific testing phases for specific types of systems, i.e., there may be an engineer who can perform the setup for a system S 1 and the test execution for a system S 2 , another engineer who cannot be involved in the testing of system S 1 but can perform both activities for the system S 2 , and so on. The setup tasks usually require one lab assistant working on one unit for a specific type of hardware in the laboratory; and the run activity usually requires several employees for its execution, in particular, one engineer who is responsible for conducting the tests and one lab assistant who provides support. When the testing of the system is finished, the testing project manager is notified, as they account for this activity. They then check the results of the test. If the results are not satisfactory, the system must be re-engineered. Otherwise, the testing project manager writes a final report that is archived together with the information generated containing the description of the test cases, test data, test results, and the outline of the findings. Information from the engineers involved in the building of the system may be necessary for writing such a report. Once ready, the engineer project manager is informed and proceeds to deploy an already complete and tested version of the engineering system, most likely helped by an engineer. The system integration team will later undertake the installation of the product, which constitutes a different process.

Table 7 shows the RASCI matrix of the process excluding the two subprocesses and Figure 14 illustrates a template that models the interaction of RASCI responsibilities for activity Run test . The template is done by composing template fragments for the responsibilities involved. Note that the alternatives described in Section 7.2 must be considered for this purpose. In particular, regarding support, it is optional for the activity and, in case it is required, it can be requested at any time and will be carried out in parallel with the rest of the execution performed by the person responsible for the activity, i.e., the engineer in charge. Only one lab assistant supports the engineer in running the test. Assessment by the engineer is not necessary as the work will later be checked for approval. In order for that to happen, the testing project manager is informed about the completion of the work and proceeds to check the outcome, hence following the Document Approval pattern.

RASCI matrix for the engineering system release process.

Composition of template fragments for activity Run Test.

8. Discussion

From the analysis of the research literature and the current approach followed in industry to responsibility management in business processes, it becomes apparent that there is an increasing demand and support for modelling activities that involve several people with different responsibilities. However, as far as process automation is concerned, the only responsibility that is managed during process execution in most proposals is the one related to carrying out the work required for the completion of the activity. Moreover, in the few cases that they support other types of responsibilities, this support is very limited in terms of generalisability and flexibility as discussed in Section 4 . This is a problem because the other responsibilities have to be implemented by manually adding activities for them in the executable process model, which is a time-consuming and error-prone task, specially for processes with a large number of activities or frequent changes in the resource assignment.

This paper introduces two novel artefacts, namely the RAM BI metamodel and the RAM2BPMN algorithm that contribute to improve the existing support for responsibility management in executable business processes in order to alleviate the aforementioned problem. Specifically, these two artefacts together enable the execution, in current BPMN engines, of business processes in which several people participate in the same activity with different responsibilities. This is done thanks to RAM2BPMN that automatically extends business process models to include in them the information about the people with different responsibilities that are specified in a RAM BI model. This extension is done leveraging templates that can be defined by the user and specify how the interaction between the people with different responsibilities must be carried out. Although the use of templates to transform BPMN models has been done elsewhere, this approach is the first time in which templates have been used to deal with the organisational perspective of business processes. Specifically, by using them, our approach fulfils the two goals defined in Section 4 , which are not supported by any of the proposals analysed in Section 3 , namely:

• It is generic in terms of the types of responsibilities that can be used in it because it does not impose a predefined set of responsibilities, but it can use the most convenient set for each situation.
• It is flexible in the sense that the interaction between the people that collaborate in an activity with different responsibilities is not predefined, but can be adapted to specific scenarios. Furthermore, our proposal enables the creation of libraries of templates that allows reusing different interaction patterns across activities, processes, and even organisations.

Furthermore, the way RAM2BPMN is designed provides the following additional advantages:

• It is platform independent in the sense that the models obtained can be used by any BPMS that supports BPMN .
• It is transparent in the sense that, although it transforms the original process model into a new one, the new elements are always embedded into subprocesses, which means that the original structure of the process model is unaltered. This is an advantage for the monitoring of the process and the understandability of audit logs because, although the information provided by the BPMS refers to the extended process instead of the original one, since the process structure is unaltered, it is straightforward to translate the information to the original process.

It is also remarkable that although we use BPMN as the process modelling language, the same ideas can be applied to other process modelling languages by adapting the details of the approaches described in this paper to their features. Similarly, where we use RAL one could use another language for defining resource assignments. In this case, the overall expressiveness would be that of the resource assignment language used.

However, our proposal has two main limitations. First, in the current approach, the template has to deal with the errors that occur during the process, e.g. a person that should be informed is not informed because the email server does not work. Although this is enough for most cases, it limits the ability to reuse error recovery strategies in different templates. One possible solution could be to extend RAM2BPMN so that the designer can specify which recovery strategy must be use in each activity independently of the template chosen. Second, since we are using RAL to define the resource assignments, mechanisms to process RAL expressions are necessary in order to be able to automatically calculate the potential holders of the responsibilities at run time; however, this support can be easily integrated into BPMS, as described in Cabanillas et al. ( 2015b ).

9. Conclusions and future work

In this paper we have presented an approach to extend the existing support for responsibility management in business processes. This approach is based on a metamodel and a technique to enable the execution, in current BPMN engines, of business processes in which several people participate in the same activity with different responsibilities. A prototype of the approach has been implemented, and it has been evaluated by modelling existing interaction patterns between people that collaborate in an activity with different responsibilities and by applying it to two real scenarios.

From this work we conclude that the existing support for responsibility management can be improved in several directions. On the one hand, our proposal of RAM BI models shows how modelling responsibility assignments can be decoupled from process models unlike what is usually done in languages such as BPMN that put together the information concerning control flow and human resources. This enables a separation of concerns between process behaviour and resource assignment, which provides a better visualisation of the information concerning resource assignment. This is especially useful when modelling complex processes or when the designs of the control flow and the resource assignments are done by different persons.

On the other hand, this work shows that it is possible to create a library templates that model different interactions patterns between people that participate in the same activity with different responsibilities. What is interesting is that these templates are reused across different activities and even different processes. This encourages a new research line focused on identifying these interaction patterns and determining in which situation they are useful. Some preliminary work already exists coming from industry (Effektif 2016 ) and academy (Brambilla, Fraternali, and Vaca 2011 ; Barchetti et al. 2012 ).

As next steps, we plan to explore additional use cases together with industry. In particular, we are interested in coming up with a set of interaction patterns that can be found in different cases and to define them using a similar approach to the design patterns in software engineering (Gamma et al. 1993 ). In addition, we also plan to extend our prototype implementation to integrate it into an open source BPMS such as Camunda. 14 Specifically the idea is to integrate the implementation as a plugin so that a model is transformed right after being deployed in the BPMS in a way that is transparent to the user. We think that this would contribute to the dissemination of the tool and its integration by startups or third party companies.

Funding Statement

This work was supported by the Austrian Science Fund [V 569-N31]; Austrian Research Promotion Agency (FFG) [845638]; European Union’s H2020 Programme [645751]; Spanish R&D&I Programme [TIN2015–70560]; Andalusian R&D&I Programme [P12–TIC-1867].

1. Please notice that the values for roles and persons are fictitious.

2. In BPMN a process takes place within a single pool. Diagrams with two or more pools, in which messages between the pools are exchanged, are called collaborations.

3. http://www.sixsigmaonline.org/six-sigma-training-certification-information/articles/the-efficient-use-of-a-six-sigma-raci-matrix.html .

4. http://en.it-processmaps.com/products/itil-raci-matrix.html .

5. For the sake of simplicity, the organisational roles that are not involved have been omitted.

6. http://www.visual-paradigm.com/tutorials/racichart.jsp .

7. http://academic.signavio.com/help/en/responsibility_assignment_acco.htm .

8. http://www.bizagi.com/ .

9. http://www.jboss.org/products/bpmsuite/overview/ .

10. https://camunda.com/ .

11. http://www.bonitasoft.com/ .

12. A Business Process can have a set of Data Objects , which can contain one or more Data Fields , whose value may change throughout process execution.

13. From now on, when we use the term template , we refer to collaboration templates .

14. http://camunda.org .

Disclosure statement

No potential conflict of interest was reported by the authors.

• Adams M. 2016. YAWL User Manual V4.1 . The YAWL Foundation. Queensland University of Technology, Brisbane, Australia. [ Google Scholar ]
• Aldin L., and de Cesare S.. 2011. “ A Literature Review on Business Process Modelling: New Frontiers of Reusability .” Enterprise Information Systems 5 ( 3 ): 359–383. doi: 10.1080/17517575.2011.557443. [ CrossRef ] [ Google Scholar ]
• Alotaibi Y., and Liu F.. 2017. “ Survey of Business Process Management: Challenges and Solutions .” Enterprise Information Systems 11 ( 8 ): 1119–1153. doi: 10.1080/17517575.2016.1161238. [ CrossRef ] [ Google Scholar ]
• Antonucci Y. L., and Goeke R. J.. 2011. “ Identification of Appropriate Responsibilities and Positions for Business Process Management Success: Seeking a Valid and Reliable Framework .” Business Process Management Journal 17 ( 1 ): 127–146. doi: 10.1108/14637151111105616. [ CrossRef ] [ Google Scholar ]
• ARIS 2012. “ RACI, ARIS Community Website .” http://www.ariscommunity.com/raci .
• Awad A., Grosskopf A., Meyer A., and Weske M.. 2009. “ Enabling Resource Assignment Constraints in BPMN .” Tech. rep. BPT, Hasso Plattner Institute, Potsdam, Germany .
• Barchetti U., Capodieci A., Guido A. L., and Mainetti L.. 2012. “ Modelling Collaboration Processes Through Design Patterns .” Computation Informatics 30 ( 1 ): 113–135. [ Google Scholar ]
• Bertino E., Ferrari E., and Atluri V.. 1999. “ The Specification and Enforcement of Authorization Constraints in Workflow Management Systems .” ACM Transactions Information Systems Secur 2 : 65–104. doi: 10.1145/300830.300837. [ CrossRef ] [ Google Scholar ]
• Brambilla M., Fraternali P., and Vaca C.. 2011. “BPMN and Design Patterns for Engineering Social BPM Solutions” In Business Process Management Workshops , edited by Florian Daniel, Kamel Barkaoui and Schahram Dustdar, Lecture Notes in Business Information Processing 219–230. Springer Berlin Heidelberg. doi: 10.1007/978-3-642-28108-2_22. [ CrossRef ] [ Google Scholar ]
• Cabanillas C., del-Río-Ortega A., Resinas M., and A. Ruiz-Cortés. 2012. “CRISTAL: Collection of Resource-centrIc Supporting Tools and Languages” In BPM 2012 Demos , vol 940: 51–56. [ Google Scholar ]
• Cabanillas C., Knuplesch D., Resinas M., Reichert M., Mendling J., and Ruiz-Cortés A.. 2015a. “RALph: A Graphical Notation for Resource Assignments in Business Processes” In CAiSE . Vol 9097: 53–68 Springer. doi: 10.1007/978-3-319-19069-3_4. [ CrossRef ] [ Google Scholar ]
• Cabanillas C., Resinas M., and Ruiz-Cortés A.. 2011a. “Defining and Analysing Resource Assignments in Business Processes with RAL” In ICSOC , Vol 7084: 477–486 . doi: 10.1007/978-3-642-25535-9_32. [ CrossRef ] [ Google Scholar ]
• Cabanillas C., Resinas M., del-Río-Ortega A., and A. Ruiz-Cortés. 2015b. “ Specification and Automated Design-Time Analysis of the Business Process Human Resource Perspective .” Information Systems 52 : 55–82. doi: 10.1016/j.is.2015.03.002. [ CrossRef ] [ Google Scholar ]
• Cabanillas C., Resinas M., and Ruiz-Cortés A.. 2011. “RAL: A High-Level User-Oriented Resource Assignment Language for Business Processes” In BPM Workshops (BPD’11) , 50–61. doi: 10.1007/978-3-642-28108-2_5. [ CrossRef ] [ Google Scholar ]
• Cabanillas C., Resinas M., and Ruiz-Cortés A.. 2011b. “Mixing RASCI Matrices and BPMN Together for Responsibility Management” In VII Jornadas en Ciencia e Ingeniería de Servicios (JCIS’11) , Vols 1167–180 . doi: 10.13140/2.1.4769.6960. [ CrossRef ] [ Google Scholar ]
• Cabanillas C., Resinas M., and Ruiz-Cortés A.. 2012. “Automated Resource Assignment in BPMN Models Using RACI Matrices” In OTM 2012 (Coopis’12) , edited by Robert Meersman, Hervé Panetto, Tharam S. Dillon, Stefanie Rinderle-Ma, Peter Dadam, Xiaofang Zhou, Siani Pearson, Alois Ferscha, Sonia Bergamaschi and Isabel F. Cruz, 756556–756573. Springer-Verlag Berlin Heidelberg. doi: 10.1007/978-3-642-33606-5_5. [ CrossRef ] [ Google Scholar ]
• Caron F., and Vanthienen J.. 2016. “ Exploring Business Process Modelling Paradigms and Design-Time to Run-Time Transitions .” Enterprise Information Systems 10 ( 7 ): 790–813. doi: 10.1080/17517575.2014.986291. [ CrossRef ] [ Google Scholar ]
• Casati F., Grefen P., Pernici B., Pozzi G., and Sanchez G.. 1996. “ WIDE Workflow Model and Architecture .”. CTIT technical reports series. University of Twente, The Netherlands. [ Google Scholar ]
• Cumberlidge M. 2007. Business Process Management with JBoss jBPM . Packt Publishing. United Kingdom. [ Google Scholar ]
• del-Río-Ortega A., Resinas M., Durán A., and Ruiz-Cortés A.. 2016. “ Using Templates and Linguistic Patterns to Define Process Performance Indicators .” Enterprise IS 10 ( 2 ): 159–192. doi: 10.1080/17517575.2013.867543. [ CrossRef ] [ Google Scholar ]
• Du W., Davis J., Huang Y.-N., and Shan M.-C.. 1999. “Enterprise Workflow Resource Management” In Ninth International Workshop on Research Issues on Data Engineering: Information Technology for Virtual Enterprises ( RIDE) , 108–115. IEEE Computer Society Press. [ Google Scholar ]
• Dumas M., La Rosa M., Mendling J., and Reijers H. A.. 2013. Fundamentals of Business Process Management .  Berlin Heidelberg: Springer-Verlag. [ Google Scholar ]
• Dumas M., van der Aalst W. M. P., and ter Hofstede A. H. M.. 2005. Process Modeling Using Event-Driven Process Chains , 119–145. John Wiley & Sons. doi: 10.1002/0471741442.ch6. [ CrossRef ] [ Google Scholar ]
• Effektif 2016. “ The Case for Workflow Modelling Patterns .” Accessed February22 2016 http://www.effektif.com/news/workflow-modelling-patterns/ .
• Gamma E., Helm R., Johnson R., and Vlissides J.. 1993. “ Design Patterns: Abstraction and Reuse of Object-Oriented Design .” In European Conference on Object-Oriented Programming , edited by Manfred Broy and Ernst Denert, 406–431. Berlin Heidelberg: Springer-Verlag. doi: 10.1007/978-3-642-59412-0_40. [ CrossRef ] [ Google Scholar ]
• Gottschalk F., van der Aalst W. M. P., and Jansen-Vullers M. H.. 2007. “SAP Webflow Made Configurable: Unifying Workflow Templates into a Configurable Model” In Int. Conf. On Business Process Management (BPM) , edited by Gustavo Alonso, Peter Dadam and Michael Rosemann, 262–270. doi: 10.1007/978-3-540-75183-0_19. [ CrossRef ] [ Google Scholar ]
• Graml T., Bracht R., and Spies M.. 2008. “ Patterns of Business Rules to Enable Agile Business Processes .” Enterp Information Systems 2 ( 4 ): 385–402. doi: 10.1080/17517570802245441. [ CrossRef ] [ Google Scholar ]
• Grosskopf A. 2007. “ An Extended Resource Information Layer for BPMN .” Tech. rep. BPT, Hasso Plattner Institute, Potsdam, Germany .
• Havur G., Cabanillas C., Mendling J., and Polleres A.. 2015. “Automated Resource Allocation in Business Processes with Answer Set Programming” In BPM Workshops (BPI) , edited by Manfred Reichert and Hajo A. Reijers, Vols 256: 191–203 . doi: 10.1007/978-3-319-42887-1_16. [ CrossRef ] [ Google Scholar ]
• Hevner A. R., S. T. March, J. Park and S. Ram. 2004. “ Design Science in Information Systems Research .” MIS Quarterly 28 ( 1 ): 75–105. [ Google Scholar ]
• Kittur A., Smus B., Khamkar S., and Kraut R. E.. 2011. “ CrowdForge: Crowdsourcing Complex Work .” In Proceedings of the 24th annual ACM symposium on User interface software and technology - UIST ‘11 , 43–52 ACM Press. [ Google Scholar ]
• Kumar A., and Yao W.. 2012. “ Design and Management of Flexible Process Variants Using Templates and Rules .” Computation Industrial 63 ( 2 ): 112–130. doi: 10.1016/j.compind.2011.12.002. [ CrossRef ] [ Google Scholar ]
• La Rosa M., Dumas M., Ter Hofstede A. H. M., and Mendling J.. 2011. “ Configurable Multi-Perspective Business Process Models .” Information Systems 36 ( 2 ): 313–340. Special Issue: Semantic Integration of Data, Multimedia, and Services. doi: 10.1016/j.is.2010.07.001. [ CrossRef ] [ Google Scholar ]
• Lam C. Y., Ip W. H., and Lau C. W.. 2009. “ A Business Process Activity Model and Performance Measurement Using A Time Series {ARIMA} Intervention Analysis .” Expert Systems with Applications 36 ( 3 ): 6986–6994. doi: 10.1016/j.eswa.2008.08.027. [ CrossRef ] [ Google Scholar ]
• Mendling J., Neumann G., and Nüttgens M.. 2005. “ Yet Another Event-Driven Process Chain - Modeling Workflow Patterns with yEPCs .” Enterprise Modelling and Information Systems Architectures, EMISA 1 : 3–13. [ Google Scholar ]
• Mendling J., Reijers H. A., and van der Aalst W. M. P.. 2010. “ Seven Process Modeling Guidelines (7PMG) .” Information and Software Technology 52 ( 2 ): 127–136. doi: 10.1016/j.infsof.2009.08.004. [ CrossRef ] [ Google Scholar ]
• Mos A., and Cortés-Cornax M.. 2016. “ Generating Domain-Specific Process Studios .” In International Enterprise Distributed Object Computing Conference (EDOC) , 1–10. [ Google Scholar ]
• Nuzen A., and Dayton D.. 2011. “ A LEAN and RACI Approachach to CMMI for Services (CMMI-SVC) .” In 11th Annual CMMI Technology Conference and User Group , http://www.dtic.mil/ndia/2011CMMI/ . [ Google Scholar ]
• OASIS Consortium 2007. “ Web Services Business Process Execution Language V2.0 .” Tech. rep. OASIS .
• OASIS Consortium 2009. “ WS-BPEL Extension for People (BPEL4people) .” Tech. rep. OASIS .
• OASIS Consortium 2010. “ Web Services-Human Task (WS-Humantask) V1.1 .” Tech. rep. OASIS .
• OMG Consortium 2011. BPMN 2.0. Recommendation . OMG. [ Google Scholar ]
• Peffers K, T. Tuunanen, M. Rothenberger and S. Chatterjee. 2007. “ A Design Science Research Methodology for Information Systems Research .” Journal Manage Information Systems 24 ( 3 ): 45–77. doi: 10.2753/MIS0742-1222240302. [ CrossRef ] [ Google Scholar ]
• Recker J., Michael Rosemann W. M., van der Aalst P., and Mendling J.. 2005. “On the Syntax of Reference Model Configuration - Transforming the C-EPC into Lawful EPC Models” In Business Process Management Workshops , edited by Christoph Bussler and Armin Haller, vol. 3812: 497–511. doi: 10.1007/11678564_46. [ CrossRef ] [ Google Scholar ]
• Russell N., ter Hofstede A. H. M., Edmond D., and van der Aalst W. M. P.. 2004. “ Workflow Resource Patterns .” Tech. rep. BETA Working Paper Series, WP 127 , Eindhoven: Eindhoven University of Technology; [ Google Scholar ]
• Russell N., van der Aalst W. M. P., ter Hofstede A. H. M., and Edmond D.. 2005. “Workflow Resource Patterns: Identification, Representation and Tool Support” In CAiSE , edited by Oscar Pastor and João Falcão e Cunha, vol 3520: 216–232. doi: 10.1007/11431855_16. [ CrossRef ] [ Google Scholar ]
• Russell N., van der Aalst W. M. P., ter Hofstede A. H. M., and Wohed P.. 2006. “ On the Suitability of UML 2.0 Activity Diagrams for Business Process Modelling .” In Asia-Pacific Conference on Conceptual Modelling (APCCM) , Vol. 53 Hobart, Australia: 95–104. [ Google Scholar ]
• Scheer A.-W. 2000. ARIS-Business Process Modeling . 3rd ed. Secaucus, NJ: Springer-Verlag New York, . [ Google Scholar ]
• Strembeck M., and Mendling J.. 2011. “ Modeling Process-Related RBAC Models with Extended UML Activity Models .” Information Softw Technological 53 : 456–483. doi: 10.1016/j.infsof.2010.11.015. [ CrossRef ] [ Google Scholar ]
• Stroppi L. J. R., Chiotti O., and Villarreal P. D.. 2011. “A BPMN 2.0 Extension to Define the Resource Perspective of Business Process Models” In XIV Congreso Iberoamericano on Sorftware Engineering ( CIbSE ).I [ Google Scholar ]
• Tan K., Crampton J., and Gunter C. A.. 2004. “ The Consistency of Task-Based Authorization Constraints in Workflow Systems .” In 17th IEEE Workshop on Computer Security Foundations , vol 17: 155–169. IEEE Computer Society. [ Google Scholar ]
• Tao A., and Yang J.. 2007. “ Context Aware Differentiated Services Development with Configurable Business Processes .” In 11th IEEE International Enterprise Distributed Object Computing Conference (EDOC) , 241–252. IEEE Computer Society. doi: 10.1109/EDOC.2007.12. [ CrossRef ] [ Google Scholar ]
• van der Aalst W. M. P., and ter Hofstede A. H. M.. 2005. “ YAWL: Yet Another Workflow Language .” Information Systems 30 ( 4 ): 245–275. doi: 10.1016/j.is.2004.02.002. [ CrossRef ] [ Google Scholar ]
• van der Aalst W. M. P., Dumas M., Gottschalk F., Hofstede A. H. M., La Rosa M., and Mendling J.. 2010. “ Preserving Correctness during Business Process Model Configuration .” Form Asp Computation 22 ( 3 ): 459–482. doi: 10.1007/s00165-009-0112-0. [ CrossRef ] [ Google Scholar ]
• Weber B., Reichert M., and Rinderle-Ma S.. 2008. “ Change Patterns and Change Support Features – Enhancing Flexibility in Process-Aware Information Systems .” Data & Knowledge Engineering 66 ( 3 ): 438–466. doi: 10.1016/j.datak.2008.05.001. [ CrossRef ] [ Google Scholar ]
• Website 2014. “ The RASCI Matrix .” http://www.ha-ring.nl/en/doc_en/rasci-matrix .
• Website 2016. “ Understanding Responsibility Assignment Matrix (RACI Matrix) .” http://project-management.com/understanding-responsibility-assignment-matrix-raci-matrix/ .
• Wolter C., and Schaad A.. 2007. “Modeling of Task-Based Authorization Constraints in BPMN” In 5th Internationa Conference on Business Process Management ( BPM) , edited by Gustavo Alonso, Peter Dadam and Michael Rosemann, Vol 4714:64–79 Springer. doi: 10.1007/978-3-540-75183-0_5. [ CrossRef ] [ Google Scholar ]