Using SharePoint to Manage Roles & Responsibilities (RACI)

The other day I noticed that someone searched my blog for “using SharePoint to create a RACI”. I had not really thought about it before, but the RACI is a perfect tool to incorporate into your SharePoint project environment. I bounced the idea off of a couple of my colleagues and they agreed, so I went to work creating a prototype of the RACI in my project site template.

About the RACI

The RACI Chart is an effective tool for the team to define and communicate roles and responsibilities throughout the project life cycle (in the context of specific project deliverables). For each of the key deliverables and team roles (not necessarily ALL deliverables and roles) the RACI defines:

  • R (Responsible) – The person or role with primary responsibility for the deliverable (person that is going to manage the work associated with the deliverable)
  • A (Accountable) – The person or role that is accountable for the deliverable (the single throat to choke if there is a problem with the deliverable)
  • C (Contributor) – The persons or roles that will actively contribute to the deliverable (either as participants in sessions, or by completing specific activities that contribute to the final deliverable)
  • I (Informed) – The persons or roles that receive the deliverable for information purposes only. This information is useful when creating the communication plan.

This tool is a best practice area that removes ambiguity and confusion associated with who is responsible for what on the team. It is critical during team formation, but is an excellent point of reference throughout the project life cycle (and worth the investment to keep current). Below is an example of the RACI spreadsheet template that I use to manage project team roles and responsibilities. The Excel based RACI is a great tool, but sometimes a bit cumbersome to update as roles or deliverables are expanded / modified. In addition, it does not have an easy mechanism to filter the information based upon specific project phases or roles.


Creating the RACI in SharePoint

I used a custom list to create the RACI in my project site. First thing I decided to do was reverse the definition of X and Y axis from my Excel template. It is more logical to add project deliverables to the list, and then assign the roles / people in the supporting columns. I added the following columns to define the RACI in the custom list:

  • Deliverable: Title field for the name of the deliverable. Again, you will add key deliverables or groups of deliverables to the RACI chart (particularly large and complex deliverables).
  • Project Phase: Major phases of the project, defined as you tailor the list for your project. For purposes of the prototype, I put a number in front of the phase to facilitate sorting of the deliverables by project phase.
  • Resp-Role: Role on the team responsible for the deliverable. This is a look-up field to select a role from the Project Roles list.
  • Resp-Assigned to: Person assigned to be responsible for the deliverable. This is a look-up field to select a person from the Team Roster list.
  • Acct-Role: Role on the team accountable for the deliverable. This column is set-up the same as the Resp-Role column.
  • Acct-Assigned to: Person assigned to be accountable for the deliverable. This column is set-up the same as the Resp-Assigned to column.
  • Contr-Role: Roles on the team that contribute to the deliverable. This look-up field allows the user to select multiple roles from the Project Roles list.
  • Contr-Assigned to: Persons assigned to contribute to the deliverable. This look-up field allows the user to select multiple persons from the Team Roster list.
  • Inform-Role: Roles to be informed about the deliverable. This column is set-up the same as the Contr-Role columns.
  • Inform-Assigned to: Persons to be informed about the deliverable. This column is set-up the same as the Contr-Assigned to column.
  • Comments: Used to capture assumptions or open issues related to the roles and responsibilities for the deliverable.

Below is an illustration of the columns associated with the RACI Chart list.


Below is an example of the Deliverable input form for the RACI list. Using the look-up feature enables easy assignment of roles and persons to the deliverable.


Using SharePoint Views to Manage the RACI

I find it helpful to set-up different views in SharePoint to display the information appropriate to the project related process or audience.

The RACI Summary view displays the roles assigned for each deliverable (without people assignments). This is the view that will be referenced in your Project Management Plan.

The Responsible and Accountable view displays the responsible and accountable roles and assignments for the project deliverables. These are the most critical roles established in the RACI and this view helps identify gaps/problems with role or people assignments. In addition, you can easily filter the list to display deliverables associated with specific roles or people.


The Contributor and Informed view displays the roles and people contributing to or informed about project deliverables. This view will be helpful when loading resources into the project schedule (contributor), and creating the communications plan (informed).

Top 7 Benefits of Managing the RACI in SharePoint

The RACI Chart is a great best practice area to build into your project environment for improved collaboration and communications associated with project roles and responsibilities. The following are the top benefits associated with maintaining your RACI Chart in SharePoint:

  1. Easy to add new deliverables to the RACI
  2. Sort the deliverables by project phase, tailored to reflect your project phases
  3. Easy to assign roles and people to the deliverable using the look-up feature (roles from the Project Roles list, and people from the Project Team Roster)
  4. Use the Responsible and Accountable view to highlight “gaps” associated with role or people assignments
  5. Use the Contributor and Informed view to enhance the information available for the communication plan
  6. Ability to filter information to display deliverables assigned to specific roles or people
  7. Use comments to capture open assumptions or issues associated with specific deliverables or assignments


     

Advertisements

PM Foundations – Managing Change

In my experience as a project manager, I have found one of the most critical best practice areas during the project execution phase to be the ability to effectively manage change. Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager effectively manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. Nobody wants to be “that” project manager that leads a project that delivers on-time and under budget, but still has an unhappy customer. Below I describe in more detail the following aspects of managing change:

  • What defines a change in the context of your project
  • What are the sources of change
  • What are the early warning signs of change
  • Establishing a process to manage change
  • Measuring the cumulative impact of change

What Defines Change

By the end of the planning phase, the project baseline is established and approved by the project sponsor and project core team. Project scope, schedule, and cost are all part of the project baseline plan. A change represents a permanent deviation from this baseline plan. The term ‘permanent’ is important. It is possible that there is a deviation from the baseline plan that will be self-correcting and is really only a deviation due to timing (when something has occurred vs. when it was planned to occur).

  • Example of a timing deviation: A deliverable that was completed a week late because the sequence was switched with another deliverable.
  • Example of a permanent deviation: A deliverable that was completed a week late, because it took a week longer than anticipated to be completed (and that week cannot be recovered).

Change is identified and measured based upon the impact on the baseline plan:

  • Scope – Additions/reductions in scope can be either in terms of scope of the product or project – in both cases they change the deliverables articulated in the WBS.
  • Schedule – Planned timing of activities and/or deliverables. In most cases, changes to the schedule are only identified / managed if they impact the project end date or a major milestone.
  • Cost – Addition/reduction to the cost of the project (permanent variance of actual/projected costs vs. planned/budgeted costs)


The following guidelines associated with changes to the project are detailed in the Project Management Plan:

  • There is not one standard definition of a change. Change must be articulated in the context of the specifics of the project. It is important to distinguish between a change and a clarification of expectations.
  • Only changes that have material impacts to the baseline plan will be formalized and managed (the Project Management Plan defines materiality).
  • How the change is determined to be a permanent or timing project impact.

Sources of Change

During project execution, actual events will occur differently than planned, even with the best of plans. It is up to the project manager to proactively identify and manage potential sources of change, and adjust the project plan appropriately. The sources of change generally fall into the following categories:

Customer Needs / Requirements – Adding a product requirement is a common source of change.

  • Adding or changing a product requirement during the middle of development / build / test activities can have even more impacts because of re-work and impacts to other parts of the product.
  • Often the change represents more of a clarification of the original requirement, and not a change in the intent of the requirement. The clarification could still represent more or less work to be completed to satisfy the product requirement.

Technology

  • Implementation of new technology introduces a certain amount of risk / unknowns. During project execution these unknowns may introduce real changes in the work required to complete the implementation (e.g., hardware procurement and set-up, software configuration & customization).
  • An organization’s standard technology platforms may change. If the work required to comply with the new standards is not reflected in the plan, it often represents a change to the project.

Planned vs. Actual Execution – The most common source of change is simply that work is completed in a different manner than originally estimated and planned. The following are more specific examples of this source of change.

  • Inaccurate estimates – Activities take more or less time than was estimated. This is more likely to occur if this type of work had not been done previously by the company or by the resources providing estimates.
  • Change in resources – The skill set associated with the resource completing the work is different that the skill set the estimates were based upon. Changes in resources in the middle of the project introduce factors like ramp-up time, the skill level of the new resource, availability of the new resource, the billing rate of the new resource.
  • Change in deliverables / activities – The addition of or removal of deliverables from the WBS can impact timelines, costs, and quality (e.g. adding training materials). Also, there could just be a process / methodology change that requires new tasks or a change to a task even though there is not a new deliverable. For example, if quality standards change, that could increase the time it takes to perform some tasks.
  • Sequence of work completed (project dependencies) – New or different project dependencies are identified during the project execution that could permanent delays in subsequent activities / milestones.

External Influences – Factors outside the control of the project team often drive changes to the project. Examples of this include:

  • Changes in regulatory or other compliance requirements
  • Changes in other systems / environments that impact the current project
  • Changes in dependent projects
  • Changes in the business environment or economy (e.g., introducing new funding constraints)
  • Reorganizations that drive changes in team members or key stakeholders (this would never happen, right?)

Early Warning Signs

In addition to understanding the potential sources of change for your project, it is also important to understand and monitor key project metrics that help identify potential (or real changes) early on (early warning signs). It is fairly intuitive that the further the project is in the project life cycle the more costly and impactful the change is to the project.


Some early warning signs of change include the following:

Schedule slippage

  • Tasks not started on-time
  • Tasks not completed on-time
  • Tasks with less progress than planned (particularly on larger effort or longer duration tasks)

Variance Trends (Cost / Schedule / Risk / Scope / Quality)

  • Consistent cost variance trends (overall or on specific cost types / categories)
  • Consistent schedule variance trends (overall or on specific project phases / milestones)
  • Actual work effort (or duration to complete) to complete tasks is consistently higher (or takes longer) than planned
  • New tasks or deliverables are identified throughout the project life cycle (pointing to gaps in the planning process)
  • Overall project risk (overall assessment of number, severity, and probability of risks)
  • Defects are identified at a higher than planned rate, or the closure rate is slower than planned

Open Risks and Issues

  • An increase in the number of risks and issues, particularly if they are focused in a specific project area, is a good indication of a potential change / adjustment required
  • Issues that are not closed sometimes point to a project change that is required to close the issue

Change Control Process

The overall goal of change control is to prevent changes from overwhelming a project or taking the project unnecessarily off track. The goal of change control is NOT to prevent all change. Change control enables proactive identification and management of change, in a manner that keeps the project moving in the right direction, towards successful completion/delivery.

The following represent the key processes involved in managing changes to the project:

  1. Identify Change: Either the project manager identifies, or is made aware of a change. Based upon guidelines established in the Project Management Plan (permanent vs. timing, and materiality), the project manager determines whether or not the change should be formalized and assessed.
  2. Assess the Impact: Once the change is identified and it is determined the team needs to assess the impact of the change on the project, the assessment is documented, using a change control tool (i.e., a project impact report).
  3. Review and Approval: Once information about the impacts of the change have been documented, the change should be reviewed by a Change Control Board and either approved or rejected.
  4. Implementation and Verification: Planning and execution of the actions required to implement the change. Implementation includes adjustment to planning artifacts to accurately reflect the new scope, schedule, and budget based upon approved change. Implementation of the change effectively establishes a new baseline for the project.
  5. Follow-up Verification: Perform a follow-up review to confirm that the appropriate actions were completed to implement the change (corrective actions), and that the change had the anticipated impact on the project (time, cost, scope, quality, risk).

Remember that change is inevitable and oftentimes necessary. However, it is important to control change so that changes are properly assessed and only approved changes are implemented within the project.

Assessing the Cumulative Impact of Change

It is important to understand the cumulative impact of changes on a project with regards to the scope, schedule, and cost/ budget. Throughout the life of a project, there will be changes. The project core team, project sponsor, and steering committee members should be aware of the cumulative impact of changes (comparing actual project performance to the original expectations established in the baseline plan).

The project manager is ultimately responsible for project execution against the baseline plans. The project manager should be able to explain the evolution of that plan from the original baseline to the current baseline, including all approved changes that have been implemented. Project managers often will fall back on the excuse that the project is over budget or late because there were project changes, but they cannot quickly explain the changes that account for the primary deviations from the original plan. Effective use of the change control log (see my blog post on Using SharePoint to Manage Change Requests) provides a tool to track and reconcile changes to the baseline schedule and budget.

Reconciling the actual project performance (schedule & cost) to the original baseline plan helps understand the “unexplained” variances. An unexplained variance is the difference between the total schedule or cost variance and the approved project changes / impacts. A project with too high a percentage of unexplained variances is usually an indication of a project with inadequate attention to change control processes. These projects have too many changes that are “flying under the radar”. I am a not a big fan of the term “scope creep” because it represents an excuse vs. an explanation. Good projects managers can pretty precisely describe the difference between the original baseline and the actual results – strive to be a good project manager.

Characteristics of Effective Change Control

Be proactive. The cost of implementing change increases later in the project lifecycle. Utilize project metrics to monitor trends and identify potential changes.

The level of control and rigor around analyzing and approving changes should be appropriately “sized” to both the organization and the project.

  • Project size, complexity, and risk profile are evaluated to adapt the change control processes to the project.
  • If changes have different impacts when they are implemented (higher actual cost or schedule impact), maybe there is not enough rigor involved with the change analysis process.
  • Projects that place more importance on schedules and/or cost constraints tend to require more control around analysis and approval processes.
  • Another consideration associated with change control processes is the visibility / strategic importance associated with the project.

Provide visibility of the change request throughout the change control process. This ensures that everyone involved with the project can easily find out the current status of any changes in the process, as well as the reasons for approving or rejecting specific changes.

Focus on the making sure the change gets appropriately implemented. Project teams often spend all of their time and energy on analysis and approval, and forget to adjust project deliverables to reflect the change.

  • Follow-up to confirm the implementation steps have been completed.
  • Compare the actual impact on the cost and schedule to the estimated project impact.

PM Foundations – Performing Resource Analysis & Creating the Resource Plan

In a previous blog post, I talked about resource loading your project schedule (estimating the resource needs, and loading resource estimates into your project schedule). Before you call your project schedule “complete”, it is a best practice to perform resource analysis & leveling, and create the resource plan. The resource plan is utilized to confirm the project resource assignments with resource managers, and it is a direct input to creating the labor component of the project budget.

Again the best practices areas associated with resource planning are:

  • How to estimate the resource requirements for schedule activities
  • How to load the resource assignments and work effort estimates into the project schedule
  • How to perform resource usage analysis, and resource leveling techniques
  • How to create the resource plan utilized to finalize resource assignments, and provide a key input to create the project budget

This blog post is focused on the last two – performing resource analysis & creating the resource plan

Resource Analysis & Leveling

The first decision to make when performing resource analysis is what is the proper time period to use for resource usage optimization. In other words, is it at the level of days, weeks or months that you need to make sure you have the right resources assigned to support planned project activities. For projects 3 months or greater, I find that it is most appropriate to perform resource analysis and leveling to the “month level” of precision. Attempting to level resources to a more granular level is not necessary to create a “workable” project schedule.

To start the resource analysis process, access the Resource View in your project management tool, and change the timescale to “months”. This view provides the number of planned hours for a resource for each month. Based upon this information, and the percentage each resource is allocated to the project, you have the information required to identify months in which resources are under or over allocated to project activities. Just because a resource (or a month) is highlighted in RED does not mean you have a resource usage problem. It may just mean that a day or week is over allocated, and that does not necessarily represent a problem that requires adjustments to the schedule.

The following represents the best practices for resolving resource issues:

  • Look at the detail activities within the resource usage view for the period that is over or under loaded in the schedule
  • Challenge the resource hours (or resource % allocations) on specific activities
  • Look for opportunities to assign other resources
  • Look for opportunities to move activities up or back (pay attention to how resources are loaded in preceding and subsequent periods). Use dependencies to move the activities around (you are changing the soft dependency logic to level the resource loading).

Below is an example of the resource usage summary and detail views utilized to analyze and level resources.


Before making adjustments to the project schedule, it is recommended to save a “back-up” version of the project schedule (in case you do not like the results of the adjustments). Make the appropriate changes, and then review the impact on resource usage and key milestone dates. Based upon the impact of the changes, you may need to challenge specific assumptions to improve the milestone dates (e.g., durations, dependencies, resource availability).

Note: I do not recommend using the “Level Resources” function within the project management tool to perform resource leveling. This function attempts to automate the decision making process described above (with the default of moving dates based upon resource availability). Reworking the result of this automated process is generally more work (not to mention more frustrating) than manually reviewing and adjusting the schedule.

The Resource Graph (below) is another tool available within the project management tool that provides an excellent summary of resource utilization for each resource. This view provides a quick preview of the impact of schedule adjustments on resource utilization. It is also a valuable way to demonstrate the impact of alternative schedule solutions (“what if” scenarios) on resource utilization. Snapshots of this view are often utilized within core team or sponsor review sessions to communicate resourcing opportunities or challenges within the project schedule. Make sure you are solving resource issues based upon the “materiality threshold” established in the schedule management plan. Things are going to change throughout the project life cycle, therefore you are trying to get the resources leveled to a reasonable level – your goal is to arrive at a reasonable schedule (not the perfect schedule).


Creating the Resource Plan

Once you are satisfied with the reasonableness of the project schedule (timing of both key milestones and resource utilization), it is time to create a first cut of the resource plan. The resource plan provides a summary of the resource hours required to complete the project. The resource plan is used for the following:

  1. Confirm resource allocations with resource providers
  2. Key input to the labor component of the project budget

Steps to create the resource plan:

  1. Create a list of the resources, sorted / grouped appropriately (e.g., by type of resource, internal vs. external) within the resource plan worksheet.
  2. Cut and paste in the hours from the resource usage view (in the project management tool) into the spreadsheet.
  3. “Adjust” the project hours to add in indirect project hours (activities that are not helpful to load directly into the project schedule). The hours for each resource in the Resource Plan should be compared to what is going to be “charged” to the project (% the resource is allocated to the project each month).
  4. Review the plan for reasonableness. Reconcile/resolve significant differences between the Resource Plan and the Resource Usage view from your project schedule.


Note: The resource plan represents a worksheet built into the Project Budget Workbook. This approach enables pointing calculations directly to the planned hours in the resource plan to drive cost estimates on the labor budget worksheet. A copy of the Project Budget workbook is available within the Templates page on www.pm-foundations.com).

 

Resource Planning Best Practices

In summary, the following are the best practices associated with the resource planning processes:

  • Do not add “noise” into the schedule by attempting to account for all hours expended on the project (activities in the project schedule should be limited to “direct” project activities). The hours reflected in the resource plan can be adjusted (generally increased) to account for indirect project hours. The resource plan should represent the hours that will be “charged” to the project by each resource (vs. the direct project activities planned in the project schedule for each resource).
  • Do not attempt to over-engineer the resource leveling process. The objective of the resource leveling process is to “smooth” the resource usage reflected in the project schedule, reducing the over and under allocation situations. Change is inevitable throughout the project life cycle, therefore your goal is to create a project schedule that can be effectively monitored and managed throughout the execution phase of the project – reasonableness, not perfection.
  • Plan to the appropriate time windows. Understanding the resource usage on a monthly basis is normally good enough to create a “workable” project schedule. In the context of this blog post, the term “workable” means a schedule that supports a timeline and budget that is understandable and defensible.