Should RACI be part of a Project Management App?

The RACI model gives a decision making process for assigning roles on a project, responsible for doing the work, accountability for the work and stakeholders that you consult and inform. How should this be recorded and then communicated to the people affected by the project?

Does the FinStarty project tool give you adequate functionality to perform these actions? Not yet.

Project Structure & Accountability

FinStarty has a hierarchical structure of parent and child projects, which can have as many levels and pathways as needed. For example, this blog sits under Marketing, Blogs & Content, and Main Content Focus. You can assign a "Marketing" project to the Head of Marketing, "Blogs & Content" to the Content Lead and the "Blog Article" to the Writer. In this example, the Writer is responsible for the blog, and the assigned status set to them. But would they be accountable for any outcomes?

Consulted

There is currently no structure to log stakeholders that should be on the Consulted list. When contacting consultants you should know what you are going to ask in advance, have an open mind, and give them notice so they can have a bit of think beforehand. Prior awareness of the detail required will help them too, will a conversation be needed or will a short & simple email suffice? You could add team members to the project, however that might give them a sense that more is required of them than is needed. Having them assigned as a consultant on the blog requesting information makes your intent and their role clearer.

Supporting Persons?

Support, RA"S"CI the extra "S" is sometimes added to the model to support the project's responsible persons. They could also be referred to as project sponsors. These could be needed in some situations to "encourage" interdepartmental collaboration and gain appropriate resources.

How to Inform

Inform people that you are writing a blog. Your social media manager for example. They can promote the blog through their channel fitting in with their publishing calendar.

Generate an "inform list" so as the project owner you can alert these stakeholders appropriately. Your business blogs may only need you to inform on completion others may have editorial deadlines to work to. You may have to set milestones triggering communication to this list.

RACI flaws in Management or Model

RASCI has some issues, namely, it doesn't designate decision-making. I have to decide on the fly to include a section about DARE in this blog, do I as the responsible person for writing the blog have to go and ask the accountable person, "If that's OK?" A "DARE" is a model that specifically calls out the Decision Makers, or does that model Define the problem depending on the source, DARE has different meanings.

Mckinsey (says Decision Makers) asks the right questions of the RACI model, and without more structure, could have too many stakeholders in the decision making process. Management that has assigned a person a task has to be involved at too granular a level causing delays, confusion and frustration. Taking your bigger projects and splitting them off into smaller parts is a very agreeable solution, but as the McKinsey article points say you have to give that smaller project to that person and allow them to make decisions, trust that they will consult and inform as appropriate.

The Head of Marketing (HoM) will not write the content plan; the Content Lead will, and they will create projects and tasks to fulfil that plan. Now the content plan may depend on the marketing plan done by the HoM and that should also be recorded. However, the Content Lead would have overall Responsibility & Accountability for the content plan and how successfully that supports the marketing plan.

Decision Makers Clearly Defined

Overall, the R&A of RACI is sufficiently covered by the assigned user and project team function. "Correctly" set projects & sub-projects assigned to the delegated responsibility of a project. If you are Assigned to a project you are accountable and responsible for it, a team can also be responsible for the work. You should be able to make decisions and be accountable for those decisions on your projects. Decisions can be added to the RAID log and revisited should the need arise.

The more I reflect on the "RA" in RACI rejecting the separation, I realise that it's difficult to be responsible for decisions without being accountable for them. Similarly, one cannot be accountable if they haven't made the decisions. Project brief & hierarchy should restrict the choices available to a supporting project; the key point is that the tasks are completed and adequately support the primary project.

Those defined as Consulted, Informed or Supporting need to be clear that they are not decision makers on the project, even if they are the ones who created and assigned the project to one of their team. They have delegated. Well done.

Adding to FinStarty

Creating an informed person list is a reasonable takeaway for development considerations for FinStarty, as well as a method for consulting someone when needing information.

The informed person part of the project tool will take the shape of a simple table with a repeating form, name, email and reason. The informed people should probably be inherited from parent projects. Sub projects can act as milestones, these lists of informed may also come from dependant or supporting projects.

The consulted persons are similar but require an initial question you would like answered or the purpose for consulting with them.

Any tools created to facilitate project management still need to be actively used. Finstarty's primary goal is to address the underlying communication between teams and departments in organisations. RACI alone doesn't address this. Having project requirements and decisions in one place, with supporting and dependable projects recognised gives the team a good chance of collaboration.

Watch this space for product plans.