I’m a big believer in accountability. I also believe that, in teams, responsibility and authority go hand in hand. If you’re responsible for a task or project, then you should have the authority to make things happen. You are going to be held accountable for the results.
RACI stands for who is Responsible, who is Accountable, who should Consult and who should Inform. According to Wikipedia, here’s how the individual roles are defined:
Responsible represents the people who are doing the work. Now I understand not everyone working on a project is hands on, so I’m assuming this is focused on the hands on, in the trenches work to be done. I’d also like to think that being responsible doesn’t absolve you from being held accountable for completing the work.
Accountability in this context means the person who ultimately will be labeled a success or failure based upon the outcome of the project. It might be the project manager or the person who championed the project in the first place. They also may or may not be doing some of the hands on work.
Consult (or Counsel) are the subject matter expertswhose expertise is needed to complete the project. Depending upon the project scope, they might have a regular role within the project team or maybe they are consulted if a specific problem occurs. I could also see this role not being confined to internal resources. Maybe the SME is an external consultant or contractor.
Inform includes the person(s) who are sponsoring the project. Every project has a sponsor that helps the team obtain resources and buy-in. The sponsors must be kept in the loop about the project status. Often this can be done with written reports and occasional one-on-one meetings, but it’s a critical piece of the project.
RACI intrigued me because I wonder how many teams actually spend time discussing roles as part of a project plan. I don’t recall ever being on a team where we had a deliberate conversation about this. And I wonder if teams spent more time on this aspect, if it would help the group reach their goals faster and with fewer setbacks. Each person knows their role, can operate effectively, and conflict is reduced.
Business professionals can benefit from project management tools in their daily interactions. Acronyms like RACI can add a level of clarity to the project…and to the outcome. Maybe it’s time for business pros to start reading project management blogs and keeping a PM book on the bookshelf. It could come in handy.
Decisions, decisions—we all have to make them. When a business makes the wrong decision it can be a costly mistake resulting in financial loss, poor use of resources, and negative impact on a company’s image. Thankfully, a decision tree diagram can help. While it’s not a crystal ball, it can provide some valuable insight that can steer you in the right direction. One of the biggest benefits of a decision tree is that it can take emotions out of the equation.
Decision tree diagrams are often used by businesses to plan a strategy, analyze research, and come to conclusions. Lenders and banks use decision trees to calculate the riskiness of loans and investment opportunities. They are also a popular choice for infographics, often appearing in magazines or shared on social media. The point is that decision trees can be used to evaluate just about any question or concern and visualize possible outcomes.
One of the nice things about a Decision Tree Diagram is that there aren’t a lot of elements. The key elements are called nodes, and appear as a square or circle with branches (lines) connecting them until a result is reached. Squares represent decisions, while circles are for uncertain outcomes.
Nodes have a minimum of two branches extending from them. On each line write a possible solution and connect it to the next node. Continue to do this until you reach the end of possibilities and then draw a triangle, signifying the outcome.
Once you’ve got the basic layout of a decision tree complete, you can add values to each line to garner more intelligence. Here’s how to do it:
1. Look at each line and add an amount to each.
2. To analyze your options numerically, add an estimate for the probability of each outcome. Note: When adding percentages all the lines from a single node need to equal 100, if you’re using fractions they need to add up to 1.
3. Assign a possible amount to each triangle at the end of the branches.
4. Calculate the results by multiplying the result by the percentage probability for each end branch in that outcome and subtract the cost of that course of action. You’ll end up with an estimate of what that particular outcome could yield.
Here’s an example:
Note: If you have a large tree with many branches, calculate the numbers for each square or circle and record the results to get the value of that decision. Start on the right side of the tree and work towards the left
It doesn’t matter where the tool comes from – what matters is solving the problem!
An Enterprise Process Architecture Model provides a high-level, structured overview of an organisation’s set of business processes. It enables you also to identify candidate processes subject to business process change.
When initiating such a business process change project consider creating a Scope Diagram to analyse how a business process-in-scope interacts with its environment.
The main purpose of a scope diagram is to define and agree on the boundaries of a process. It is also an ideal tool for enhancing the communication to the stakeholders.
As a business process practitioner, you can choose between different types of scope diagrams. An overview.
An IDEF0 model represents how process activities interrelate, how resources are used by an activity, and what the result or output of each activity is. The model consists of simple box and arrow graphics and associated text supporting the graphics.
The essence of an IDEF0 model is that it allows you to to focus on how the process interfaces with its environment. An IDEF0 model describes four types of interfaces:
A variation of IDEF0, is the IGOE diagram. The acronym IGOE stands for Input-Guides-Outputs-Enablers.
The model is used to define the scope of a process including the types of problems one might face in the analysis of the process-in-scope. Besides the relationships between the process-in-scope, upstream or downstream processes, relevant documents, stakeholders etc this diagram focuses also on issues like:
This framework could be used for capturing and documenting the IGOE’s of what an organisation does.
A popular scoping technique with (Lean) Six Sigma practitioners is the SIPOC diagram. It represents a high-level view of a process. It shows the Suppliers, Inputs, Process, Outputs and Customers.
SIPOC diagrams are useful for focusing a discussion and helping project team members agree upon a common language and understanding of a process for continuous process improvement. In Six Sigma, SIPOC is often used during the “define” phase of the DMAIC improvement steps.
The purpose of a Business Interaction Model (BIM) is to provide a helicopter view of the business interactions between identified actors that play a role in the business domain-in-scope.
A common development approach is as follows:
Like a Rummler-Brache Relationship Map this diagram provides a convenient way to graphically establish boundaries on the processes to be considered for further examination.
The common characteristics of the presented scope diagrams are that they all try to get a better understanding of the business process-in-scope and enhance the communication to the stakeholders.
Undoubtedly it is a very useful but underestimated modelling technique among business process practitioners. Indeed, ideally, ‘scoping’ should be done first before embarking on extensive process mapping initiatives.