jump to navigation

RACI Chart May 20, 2008

Posted by Coolguy in Business Analysis.
Tags: ,
1 comment so far

RACI Chart describes roles and responsibilities of various people involved in a project. The acronym RACI stands for:

Responsible : Resources who complete the task

Accountable : Person responsible for completion of the task. Also called as Approver.

Consulted : People whose inputs are sought during the process of completing the task

Informed : People who are kept up-to-date on the progress of the task.

This tool is along with stakeholder matrices to identify all the stakeholders in a project and define a communication plan that is appropriate for them.

Stakeholder Analysis and Stakeholder Management August 31, 2005

Posted by Coolguy in Business Analysis.
  • Stakeholder management is critical to the success of every project in every organization
  • By engaging the right people in the right way in your project, you can make a big difference to its success… and to your career
  • Stakeholder Management is an important discipline that successful people use to win support from others.
  • Stakeholder Analysis is the technique used to identify the key people who have to be won over
  • You then use Stakeholder Planning to build the support that helps you succeed.
  • The benefits of using a stakeholder-based approach are that
  • You can use the opinions of the most powerful stakeholders to shape your projects at an early stage. Not only does this make it more likely that they will support you, their input can also improve the quality of your project
  • Gaining support from powerful stakeholders can help you to win more resources – this makes it more likely that your projects will be successful
  • By communicating with stakeholders early and frequently, you can ensure that they fully understand what you are doing and understand the benefits of your project – this means they can support you actively when necessary
  • You can anticipate what people’s reaction to your project may be, and build into your plan the actions that will win people’s support.

What is a Stakeholder?

  • Stakeholder is anyone whose jobs will be altered, who supplies or gains information from it, or whose power or influence within the organisation will increase or decrease.
  • Categories of stakeholder include
  • End-users,
  • Managers and others involved in the organisational processes
  • Engineers responsible for system development and maintenance,
  • Customers of the organisation who will use the system
  • External bodies such as regulators, domain experts, and so on.
  • They will each have different goals, and will try to satisfy their own without recourse to others.
  • Stakeholders might be in one of three categories:
  • Internal to the project team;
    External to the project team, but internal to the organisation;
    External to both the project team and the organisation.
  • Different division: into those who will use the system directly or indirectly, and those who will be involved in developing the system
  • Four categories of stakeholder in any computer system:
  • 1. Those responsible for design and development;
    2. Those with a financial interest, responsible for its sale or purchase;
    3. Those responsible for introduction and maintenance;
    4. Those that have an interest in its use.

    Stakeholder Analysis

  • The first step in Stakeholder Analysis is to identify who your stakeholders are.
  • The next step is to work out their power, influence and interest, so you know who you should focus on.
  • The final step is to develop a good understanding of the most important stakeholders so that you know how they are likely to respond, and so that you can work out how to win their support – you can record this analysis on a stakeholder map
  • The steps of Stakeholder Analysis are:
  • 1. Identifying Your Stakeholders
    2. Prioritize Your Stakeholders
    3. Understanding your key stakeholders

    1. Identifying Your Stakeholders
  • Successful exploration and specification of software and information systems requirements relies on adequate identification of stakeholders
  • Stakeholders are related to each other and interact with each other
  • Interactions between them include: exchanging information, products, or instructions, or providing supporting tasks.
  • Information about the stakeholders and the nature of their relationships and interactions needs to be identified and recorded.
  • Dimensions of importance are: relationships between stakeholders, the relationship of each stakeholder to the system, and the priority to be given to each stakeholder’s view
  • Our starting point is a set of stakeholders that we refer to as baseline stakeholders.
  • From these, we can recognise supplier stakeholders and client stakeholders
  • The first step in your stakeholder analysis is to brainstorm who your stakeholders are. As part of this, think of all the people who are affected by your work, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion

Baseline stakeholders

  • They provide information or supporting tasks to the baseline,
  • Four groups of baseline stakeholders:
  • Users


  • Three categories of user: primary, secondary and tertiary.
  • Primary users are those likely to be frequent hands-on users of the system
  • Secondary users are occasional users or those who use the system through an intermediary;
  • Tertiary users are those affected by the introduction of the system, or who will influence its purchase.
  • Assume that users are the people, groups or companies who will interact with the software and control it directly, and those who will use the products (information, results etc) of the system.


  • The developers of the system are stakeholders in the RE process, but their stake in the final requirements specification, or indeed in the system itself,


  • Professional bodies, government agencies, trade unions, legal representatives, safety executives, quality assurance auditors and so on may produce guidelines for operation that will affect the development and/or operation of the system.
  • Some of these will be local to the domain, others will be national or international; others will be local to the organisation.


  • Within the development organisation and the user organisation, there will be decision-making structures that relate to the system under development.
  • The kinds of stakeholder here would include managers of the development team, user managers and financial controllers in both the developer and the user organisation.

Exploring the network of stakeholders around the baseline

  • Identify all specific roles within the baseline stakeholder group;
  • Identify supplier stakeholders for each baseline role;
  • Identify client stakeholders for each baseline role;
  • Identify satellite stakeholders for each baseline role;


  • The roles within the developer baseline group could include analysts, designers, programmers, testers, quality assurance representatives, maintainers, trainers, project managers and so on.


  • Identify legislator roles and the remit they have, i.e. do they cover the operation of the system such as data protection legislation, or the development of the system, e.g. defence standards.


  • A good starting point for this group is the stakeholder in the user organisation responsible for commissioning the system. Identify decision-makers within the development organisation and the user organisation (which may be the same, or different) who have any power over the decision to build the system, or over any processes, people or standards identified in earlier stakeholder enquiries.

2. Prioritize Your Stakeholders

  • Map out your stakeholders using the Power/Interest Grid
  • Classify them by their power over your work and by their interest in your work.
  • Someone’s position on the grid shows you the actions you have to take with them:
  • High power, interested people: these are the people you must fully engage and make the greatest efforts to satisfy.
  • High power, less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message.
  • Low power, interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the detail of your project.
  • Low power, less interested people: again, monitor these people, but do not bore them with excessive communication

3. Understanding your key stakeholders

  • Key questions that can help you understand your stakeholders are:
  • What financial or emotional interest do they have in the outcome of your work? Is it positive or negative?
  • What motivates them most of all?
  • What information do they want from you?
  • How do they want to receive information from you? What is the best way of communicating your message to them?
  • What is their current opinion of your work? Is it based on good information?
  • Who influences their opinions generally, and who influences their opinion of you? Do some of these influencers therefore become important stakeholders in their own right?
  • If they are not likely to be positive, what will win them around to support your project?
  • If you don’t think you will be able to win them around, how will you manage their opposition?
  • Who else might be influenced by their opinions? Do these people become stakeholders in their own right?
  • You can summarize the understanding you have gained on the stakeholder map, so that you can easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters or your project. A good way of doing this is by color coding: showing advocates and supporters in green, blockers and critics in red, and others who are neutral in orange