Today, I was randomly exploring project management concepts, when I came across an interesting tool -
Responsibility Assignment Matrix.
Specifically, I had landed on the
RACI model (Responsible, Accountable, Consulted, Informed) to manage projects.
The textbook definition of a a project is any temporary or time bound organization of resources, which helps in delivering one or more business objectives. In reality, most of the work that one does at a startup could be thought of as a project - if you are fixing issues for a group of stakeholder, with interaction from other teams, which involves doing things that are not part of day to day job, then you are working on a project.
Every project has 3 key roles(s) without fail - the project manager, the project sponsor, and the project stakeholders. While there may be multiple sponsors and stakeholders, the boundaries between them are usually virtual, and overlap of roles is possible (persons playing them) is possible in reality.
Every project can be broken down into sets of tasks. But herein lies the root of the problem - defining who is responsible for what within a project is a hard task in itself. One solution to this problem is the responsibility assignment matrix, and the prominent industry way of doing it is via the RACI matrix.
A role is not the same as a person - instead, it is a collection of tasks and responsibilities that a group of people can do, and roles may even have overlaps amongst themselves. Everyone should know who is R responsible (R) for doing every task - the foot soldier, who is accountable (A) for ensuring that the task is done right, who needs to be consulted (C), and who all need to be informed (I).
The Standard way of doing this is:
Projects can come in different flavors, and while RACI may be suitable for some projects, there are other ways of doing the responsibility assignment as well - for example:
Thus, depending on the project at hand, the ideal responsibility assignment matrix can be picked up, to make everyone's life easier at the end of the day.
You get a matrix like below at the end, which keeps everyone in the team aligned on who is contributing where. In my opinion, it doesn't matter who you are interacting with, this kind of matrix would always help you with the "non-developer" stuff that you can take care of as a developer, so as to maintain your visibility and keep everyone around you happy. I also helps you be selective in who you can be proactive with, and at what stages, so that you are in everyone's good books - something that should help in longevity at any organization :)
The textbook definition of a a project is any temporary or time bound organization of resources, which helps in delivering one or more business objectives. In reality, most of the work that one does at a startup could be thought of as a project - if you are fixing issues for a group of stakeholder, with interaction from other teams, which involves doing things that are not part of day to day job, then you are working on a project.
Every project has 3 key roles(s) without fail - the project manager, the project sponsor, and the project stakeholders. While there may be multiple sponsors and stakeholders, the boundaries between them are usually virtual, and overlap of roles is possible (persons playing them) is possible in reality.
Every project can be broken down into sets of tasks. But herein lies the root of the problem - defining who is responsible for what within a project is a hard task in itself. One solution to this problem is the responsibility assignment matrix, and the prominent industry way of doing it is via the RACI matrix.
A role is not the same as a person - instead, it is a collection of tasks and responsibilities that a group of people can do, and roles may even have overlaps amongst themselves. Everyone should know who is R responsible (R) for doing every task - the foot soldier, who is accountable (A) for ensuring that the task is done right, who needs to be consulted (C), and who all need to be informed (I).
The Standard way of doing this is:
- Identify all required tasks and activities
- Find out the different roles (Emphasis roles and not person)
- Now assign the RACI code, who will be accountable, responsible, consulted, or informed
- One role can have one or more amongst RACI
- Identify what the gaps are - only one role can have A accountability, every task must at least have one R and one A, you can’t have too many C for one task, and low number of C and I on chart means low communication between team members
- Make improvements as a team, and get alignment on each of the steps, to minimize overheads
Projects can come in different flavors, and while RACI may be suitable for some projects, there are other ways of doing the responsibility assignment as well - for example:
- RAPID (Recommend, Agree, Perform, Input, Decide) created by and trademark of Bain & Company
- RACI-VS (Verifier, Signatory) - expanded version of RACI with acceptance criteria
- PACSI (Perform, Accountable, Control, Suggest, Informed) - useful to organizations where the output can be reviewed and vetoed by multiple stakeholders
- and so on..
Thus, depending on the project at hand, the ideal responsibility assignment matrix can be picked up, to make everyone's life easier at the end of the day.
You get a matrix like below at the end, which keeps everyone in the team aligned on who is contributing where. In my opinion, it doesn't matter who you are interacting with, this kind of matrix would always help you with the "non-developer" stuff that you can take care of as a developer, so as to maintain your visibility and keep everyone around you happy. I also helps you be selective in who you can be proactive with, and at what stages, so that you are in everyone's good books - something that should help in longevity at any organization :)
No comments:
Post a Comment