PM-Foundations – Why Manage a Project?

The other day I was at a client participating in a discussion on strengthening the portfolio management processes, when someone asked the question, “Do we understand what a project is?” This question made me smile. After all of this discussion, we don’t know what a project is, really? From my perspective it is best to keep the definition of a project very straightforward. A project is an effort to achieve a specific goal that has a definitive beginning and end.

 

When you break down this statement, the following are the important elements:

  • Effort – Projects require resources to complete. These resources generally include money and people. Therefore events that “just happen” are not considered projects (many refer to these as Acts of God).
  • Goal – The goal represents the desired outcome that the project is attempting to achieve. The goal is what defines the end of the project.
  • Beginning and End – The most important element of the definition of a project is that it is a temporary endeavor. Projects always have a beginning and an end (even if the end does not represent a successful outcome). The fact that a project is a temporary endeavor is what differentiates it from an operational process. Operational processes are repeated on a day to day basis to perform on-going business functions.

While most people can quickly agree upon the definition of a project, I think the more important question in the context of portfolio management is, “Which efforts should be purposefully and formally managed as projects?” Many project management enthusiasts would respond to this question with a passionate, “Everything, of course!” I would counter that projects can be managed as actions planned and executed within the context of operational processes. For example, I have seen many continuous improvement type initiatives successfully run “in-line” with the completion of operational work. From my perspective, the organization needs to define the efforts that should be separated from operational work, and managed as part of the project portfolio. This approach allows organizations to focus on achieving successful outcomes on the efforts that directly align with business strategies / priorities. Projects that do not fit in the project portfolio are either thrown out, or completed as part of performing normal business operations.

5 Guidelines for When to Manage an Effort as a Project

Below are my top 5 reasons to formalize an effort as a project, and manage it within the project portfolio.

1. Strategic Initiative – If an effort is tied directly to one of the organization’s key strategies or top priorities, it must be formalized as a project. These efforts need the visibility and rigor that a project provides to ensure the organization is demonstrating and communicating progress on its key strategies.

2. Requires Funding – Efforts that require additional funding / resources are difficult to run “under the radar”. The project initiation process facilitates the justification and approval of funds for these efforts. This process ensures that the organization is investing in the “right” initiatives.

3. Involves Opportunity Cost – An initiative may not require incremental funds, but involves a decision to reassign resources from another effort to initiate this effort. There is an opportunity cost related to stopping or slowing the other effort. Again, the project initiation process facilitates making decisions of this nature, and ensures that resources are working on the “right” initiatives.

4. Cross-Functional – Many efforts require facilitation of decisions and coordination of resources across different areas within the organization. Formalizing the effort as a project enables the level of coordination required to ensure its success.

5. Something New – When an effort is introducing something new to the organization (e.g., process, product, or technology) the effort needs a higher level of visibility to ensure the organization is prepared to accept and effectively leverage the new capability. Formalizing the effort as a project provides this increased level of visibility.

When do you need a project manager?

I feel obligated to discuss a related and somewhat controversial question within the project management community. When should a project manager be assigned to manage a project? From my perspective, all projects must have someone who performs the role of the project manager. I do not believe that projects will be consistently successful without someone that is formally responsible and accountable for what is delivered, when, and how much it costs. The question then becomes, when should the project manager assigned be a dedicated and fully qualified project manager, rather than a person that is performing the role as part of another role on the team (e.g., team lead)? Although I am of the belief that projects are generally more successful with a dedicated and fully qualified project manager performing the role, I do think there are projects and situations that can be successful without one. It is important to understand the project and situation when making the determination of who will perform the project manager role on the team. Here are some things to consider when selecting the project manager for your project.

  • Strategic – Is a key priority or strategy of the organization tied to the success of the project? If the answer to this question is “yes”, you should have a “real” project manager assigned to manage the project. It is common sense that a competent project manager will significantly reduce the risk of a challenged or failed project. Why put a key company priority at risk by cutting a corner on the project manager role?
  • Size & Complexity – As the number of deliverables and activities grows on an effort, so does the need for a qualified project manager on the project. The best indicator of complexity is the number and type of dependencies (both internal to the project, as well as dependencies on external activities or projects). An experienced project manager is going to do a much better job managing a large and complex project schedule, than someone who is performing the function as part of another role. In addition, an experienced project manager will more effectively manage the increased level of change that comes with larger and more complex projects.
  • Resources – Is the core team and stakeholder community cross-functional? Diversity on project teams helps drive better project outcomes, but also introduces challenges in terms of leading and controlling the project. An experienced project manager will more effectively establish and manage expectations on the cross functional core team and within the overall stakeholder community.
  • Cost – Is the cost of the project material to the organization (based upon impact on the investment portfolio or operating results)? Effectively managing a project budget is one of the most common areas that trips up an inexperienced project manager. Experienced project managers understand how to prepare a budget, forecast variances, and as required, implement corrective actions.

 

 

 

 

Advertisements

PM-Foundations on Project Churn

I often discuss with my colleagues that I have witnessed so much churn over the years that I could write the “Book of Churn”. Okay, so this is just a blog post, but I feel obligated to share my knowledge on the topic of churn. In the workplace, churn represents the counterproductive discussions, emails, and actions that create a “drag” on generating positive business results. In the context of project delivery, churn represents the “negative energy” within the team and the overall project environment that prevents your project from progressing at the planned rate, or successfully completing project milestones. Churn is manifested in a stakeholder’s negative communication, a team member’s non-productive actions, or project delivery processes that are slow or ineffective. At its worst, project churn can paralyze a project team, and overwhelm a project. You will find project churn at the heart of many challenged or failed projects.

The phrase, “one step forward, and two steps back” is a perfect visual for the impact of churn on your project. To help you put project churn in the right perspective, here are a few “real life” examples:

“The meeting after the meeting” – After a rather uneventful core team meeting, you see a group of team members talking outside the conference room. As you walk by you overhear, “I am not sure why we say we are on-schedule. The current design is going to take us at least 3 weeks longer than the plan reflects”. Shouldn’t that have been something we talked about in the core team meeting? Churn.

“The grenade” – The Steering Committee generated good discussion about the current plans and upcoming milestones. The team agreed that the right corrective actions are in place to successfully roll-out the new web site within two weeks of the original baseline milestone date. At the end of the meeting, when you ask “are there any other comments or concerns?”, the VP of Sales (who rarely attends the Steering Committee) raises his hand and says, “The way this system is being rolled out is going to be highly disruptive to field associates.” Shouldn’t this risk have been raised a little earlier in the project? Churn.

“I am waiting” – When you visit one of your developers to discuss why he is two weeks late starting a particular task. He says, “The integration work packages must be completed before I can start my development effort.” When you point out that the integration work packages are not reflected as a dependency in the schedule for his work, he says, “We are not using the project schedule to determine what we are working on. The project schedule is for the project manager, not the development team.” The project schedule is only for the benefit of the project manager? Churn.

“I think this is still an issue” – There is an open issue that is delaying the start of User Acceptance Testing. Every day it is not resolved has a direct impact on the “go live” date. When it seems that all of the decisions have been made and actions taken to close the issue, one team member speaks up in the core team meeting, “I think this is still an issue. I think we need more analysis and input.” Don’t you share my sense of urgency to resolve this issue? Churn.

Many times project churn shows up in very subtle and somewhat innocent ways on the project, but the cumulative impact of project churn can be devastating to project results. Below I describe 6 types of churn that I have witnessed on projects, and some of the impacts of this churn.

6 Types of Project Churn

1. Ineffective Meetings – Do your project meetings have a regular cadence (timing, content, and attendance)? Do the project meetings have an established purpose and objectives? Do the meetings drive positive project outcomes in terms of information sharing, problem resolution, and tracking and planning of work? Are action items regularly captured, and follow-up actions proactively initiated and tracked? If the answer is “no” to several of these questions, your project meetings may be a source of project churn. Project meetings that create churn ramble on, and provide limited benefit to the project team. In many cases, ineffective project meetings will actually be the source of confusion and misunderstandings on the team. It is a strong indication that your project meetings might be creating churn if you discuss the same issues/problems meeting after meeting, and team members become disengaged in the conversations — or do not show up at all. Another sign of meeting related project churn is if your meetings result in more meetings – “we will need another meeting to resolve this issue.” Communications within the project team, the ability to remove roadblocks, and the tracking and prioritization of project work are all negatively impacted by meeting related project churn.

2. Uncontrolled Change – I have been exposed to plenty of projects where team members state, “This project would be doing okay if it was not for all of the changes.” When you ask the team members what they mean by that statement, they often struggle to provide specifics about the changes that have impacted the project. Whether this is a factual statement, or just the perception of the team member, the fact that people talk about change that has not been managed through a change control process results in project churn. This type of churn can be highly disruptive on a project team because it can create contentious discussions between stakeholders when there is a disagreement between what represents change vs. elaboration or clarification. The key to reducing the impact of change related project churn is to establish the appropriate change control processes, and transform observations and perceptions of change into fact based change control related discussions and decisions.

3. Not Working to the Plan – The example above of the developer who says he is not performing project work based upon the priorities and timing established in the project schedule happens more than we would like to admit. This schedule related churn can start when the work is broken down and organized in the WBS in a manner that is not meaningful or logical to the team members that will be performing the work. The schedule that is generated out of this process may not reflect the right level of detail, durations, work effort, or sequencing, and therefore it creates churn because team members do not believe it reflects the “true” plan. Other projects start execution with a strong schedule that is well understood by the team. As project work is elaborated, or schedule related changes occur, the schedule is not appropriately updated, and the schedule starts to diverge from reality — and chaos ensues. The bottom line is if the schedule is not planned and progressed in a manner that is consistent with the way actual work is completed, you will be constantly battling schedule related churn. The analogy I like best that represents this type of churn is “pushing a rope uphill”.

4. Issues That Do Not Close – One of the easiest ways to monitor churn is to track how effectively the project team identifies and closes issues. Significant issue related churn is generally due to the project team not having the appropriate focus or urgency required to close issues. In some situations the team is not empowered to take actions or make decisions required to close issues. In either case, issues that do not close create “baggage” for the team, and eventually create roadblocks or challenges for the project. Issue related project churn also includes issues that are re-opened. This means the appropriate actions or decisions were not completed to correctly close the issue. I have seen many examples of issues that caused huge impacts (delays, rework, or defects) because they were left to linger and create issue related churn throughout the project life cycle.

5. Inappropriately Sized Processes – Project delivery processes are intended to improve the efficiency and effectiveness of the project team. However, often times project delivery processes are not appropriately established based upon the size and complexity of the project. If the processes are too “heavy”, teams get bogged down with the constraints associated with the processes. These “heavy” processes are often confusing to team members, and cause churn to figure out how to complete routine project delivery tasks. If the processes are too “light”, there can be too much deviation in the way project delivery activities are executed (some processes are invented on the fly). In these cases, the processes drive churn because the team is busy cleaning up the fallout from team members performing project delivery processes in an ad hoc manner. Process related churn is a perfect example of “one step forward, and two steps back” – either it is way harder to get things done than it needs to be (too heavy), or there are wildly different outcomes depending on the person performing the process (too light).

6. Disconnected Stakeholders – One of the most disturbing types of project churn is stakeholder related churn. This churn occurs when individuals or groups of individuals become disconnected from the project goals and activities, either due to lack of engagement or difference of opinions. Sources of stakeholder related churn can include core team members, the project sponsors & steering committee, and other stakeholders that directly impact or influence project outcomes. Sources of churn outside of these groups generally can be rationalized as irrelevant to the project. There is expected to be some churn when project teams are forming and storming, but at some point the “noise” should dissipate and the teams begin working well together to accomplish common goals. In some circumstances, negative energy from stakeholder related churn will work itself out, but in most cases it requires focused “intervention” to understand the core issues and establish the next steps required to smooth out the team dynamics.

What Should I Do?

Some project managers take on the persona of a “victim” and accept or escalate project churn. The reality is that as a member of the project team, the project manager is in some way part of the project churn. The project manager is in the best position to directly impact, or significantly influence, the level of project churn. Project churn can be directly impacted by adjusting project delivery process (e.g., change control, issues management), updating the project schedule in a manner that is more meaningful to team members, or enhancing project meetings and other team communications. Project managers can influence project churn by utilizing their soft skills to lead cohesive and productive project teams. The project manager’s soft skills are also leveraged to build and manage strong relationships with key stakeholders.

I obviously have a lot of opinions and perspective on the topic of project churn. I view managing project churn as a rewarding challenge, and not a burden or problem. I sincerely believe that turning negative energy (churn) into positive project outcomes is one of the most satisfying elements of being a project manager.

PM Foundations – Managing Supplier Performance

How you work with and manage a supplier on your project is directly related to the type of products and services you are purchasing from the supplier. These products and services may be resources performing specific services/roles, purchase of tangible off-the-shelf products (i.e., infrastructure, software licenses), or built to order products (e.g., custom software applications). In general, the larger and more complex the purchase, the more time and effort you will invest in the supplier management plan. In addition, the greater the dependence of the project’s success is on the supplier the more focused you will be on building a good working relationship with the supplier. In these cases, your goal is to transition from a pure customer-supplier relationship to a true partnership, where both parties have something to gain from the successful project outcomes.

Supplier Management Approach

Again, the supplier management approach will vary based upon the types of products and services purchased for the project. The following outlines the type of project related purchases, and the different supplier management approaches.

Resource Purchase – The supplier is providing resources to fulfill specific roles on your team for specified periods of time (or to complete specific deliverables). The following are the key elements of the supplier management approach for a resource purchase:

  • Resource(s) are on-boarded as any other team member, with a defined role on the team and a related set of expectations/deliverables.
  • Supplier performance is directly tied to the performance of the resources assigned to the team.

Product Purchase – The supplier is providing a standard product has been selected to meet specific needs of the project. The following are the key elements of the supplier management approach for a product purchase:

  • The product is purchased for a pre-defined price.
  • The product is delivered/installed based upon an agreed upon delivery schedule.
  • The project team validates that the product works as advertised (based upon commitments during the purchase cycle).

Make to Order – Fixed Price: The supplier is delivering a product/solution that will be customized to meet the needs of the project at a fixed price (based upon a common understanding of the product requirements). The following are the key elements of the supplier management approach for a make to order purchase with a fixed price contract:

  • The supplier commits to the timing of the delivery of a set of deliverables, including the final product, for a predefined price.
  • The project team validates that the final product delivered meets the specifications defined in the contract.
  • Any changes to the original specifications must be managed on a case by case basis.

Make to Order – Time & Material: The suppler is delivering a product/solution that will be customized to meet the needs of the project, and the purchase price will be based upon the actual time and materials required to deliver the custom solution. In most cases, the cost of the solution is estimated at the beginning of the project, but the final price is directly tied to the actual effort and resources required to complete the work. The following are the key elements of the supplier management approach for a make to order purchase with a time and materials agreement:

  • The supplier commits to the timing of the delivery of a set of deliverables, including the final product.
  • The project team validates that the final product delivered meets the specifications defined in the contract.
  • Any changes to the original specifications must be managed on a case by case basis.
  • The project team manages the effort and cost associated with the delivery of the product / solution (against the estimated cost/effort provide by the supplier).

The chart below summarizes the different supplier management approaches for each of the different types of purchases.

Project Management Approach

As the project manager you play a major role in supplier management. In the same manner the supplier management approach is aligned with the type of product and services purchased, the project management approach must be adjusted appropriately. The following outlines the key elements of the project management approach for each purchase type.

Resource Purchase:

  • Supplier resources are managed in the same manner as other resources on the team. It is important to define roles, and establish accountability for deliverables/assignments. On an on-going basis progress and completion of deliverables are managed based upon established expectations of the role.
  • Ensure that billings are accurate based upon the rate established in the statement of work, and the time reported.

Product Purchase:

  • Ensure that product is received on-schedule.
  • Ensure that the appropriate product validation is completed (the timing of this validation is managed based upon dependencies in the schedule for the product delivery/installation).
  • Ensure that the amount billed is consistent with the contract/purchase order.

Make to Order – Fixed Price:

  • Monitor progress of interim deliverables, tied to delivery of the custom product/solution. Key supplier milestones are built into the schedule, and tied to dependent deliverables.
  • Ensure appropriate product validation is completed (against product specifications). Product validation deliverables are built into the project schedule.
  • Changes to the product specifications, or the timing or cost of delivering the product, are managed using the change control process established for the project team.
  • Ensure that the amount and timing of billings is consistent with the contract / purchase order.

Make to Order – Time & Material:

  • Monitor progress of interim deliverables, tied to delivery of the custom product / solution. At a minimum, key supplier milestones are built into the schedule, and tied to dependent deliverables.
  • Ensure appropriate product validation is completed (against product specifications). Product validation deliverables are built into the project schedule.
  • Changes to the product specifications, or the timing or cost of delivering the product, are managed using the change control process established for the project team.
  • The supplier effort and costs must be monitored and controlled on a regular interval. Earned value is a very effective metric for monitoring time & material contracts (effort vs. progress).

The chart below highlights the key elements of the project management approach for each of the different types of purchases.

Supplier Management Best Practices

Best practices associated with managing supplier performance include the following:

  • Make sure that supplier work and deliverables are clearly identified in the project plans (project management plan, schedule, and project budget). This includes:
    • Supplier deliverables are clearly identified as sections of the WBS.
    • An alternative to creating separate sections in the WBS for the supplier is to identify the vendor deliverables/activities with a separate activity code in the project schedule (preferably using a field that can be filtered to provide a view of supplier deliverables/activities).
    • Often supplier deliverables and activities are not reflected in as much detail in the project schedule, because the supplier is managing this work in a separate project schedule (this is particularly true if the work is performed off-site at a supplier location).
    • Generally, a separate cost category is created in the project budget (or a sub-category – line item) for each supplier. On the monthly cost updates, supplier costs are grouped together, and compared to the amount budgeted for the supplier.
  • The approach and process for managing each supplier is clearly defined in the project management plan. This approach is mutually agreed upon with each supplier. In addition, the supplier is provided “the big picture” associated with the project, and how they fit into the project plans. Many of these expectations will be defined in the supplier agreement or statement of work. This includes:
    • Other project deliverables that supplier deliverables are dependent upon
    • Supplier deliverables that other project deliverables are dependent upon
    • Success factors associated with the supplier products and services
    • Acceptance criteria for the supplier products and services
    • Other project related processes that the supplier must comply with (status reporting, time reporting, financial reporting)
  • Establish one change management process that is utilized for the entire project. Unnecessary confusion is introduced by establishing processes that are unique to suppliers.
  • Product validation is reflected in the project schedule, with the appropriate level of detail. It is important that the supplier understands the timing of the product validation activities, in case they need to respond to any issues identified during this process.

Using SharePoint to Manage Project Meetings

In one of my previous blogs I talk about establishing rhythm on your project. Rhythm is a best practice area that ensures your team works together in a consistent, cohesive, and collaborative manner throughout the project life cycle. Rhythm involves three important elements of effective project execution:

 

  • Teamwork – People on the project are working together to accomplish a common goal.
  • Cadence – Work is getting done on-time, and in the sequence that it should.
  • Communication – People are informed and engaged at the right time about relevant topics.

Why is project rhythm so important?

The project team works more efficiently and effectively with a common understanding of the goals and the plan to “get there”.

  • Team members are more likely to be well-informed, and actively participate in decision making when strong communication and collaboration processes and tools are established.
  • Team dynamics & satisfaction are improved on a team that understands what progress looks like.
  • Bottom line: Good project rhythm improves project delivery outcomes.

SharePoint provides many features to help enhance the team’s rhythm. One of the most valuable of these features involves management of key team meeting. Efficient and effective meetings improve the interaction amongst team members, and confirm that the appropriate follow-through is executed after the meeting. The use of the Meeting Workspace within your project site helps make certain that the right people show up and are prepared to actively engage in key discussion topics.

The Meeting Workspace is a site template pre-configured to manage key elements of your team meetings:

  • Meeting Objectives
  • Attendees
  • Agenda
  • Pre-read materials
  • Minutes
  • Action items

The Meeting Workspace provides a self-contained and easy to access location for team members to better prepare for team discussions, and continue to collaborate on relevant topics after the meeting. I continue the description of the use of the Meeting Workspace to improve project rhythm context of two types meetings — recurring team meetings (e.g., core team and steering committee meetings) and one-time events (e.g., deliverable and milestone reviews).

Recurring Project Meetings

The project manager is responsible for ensuring that both the core team and steering committee are fully engaged throughout the project life cycle. The Meeting Workspace represents an excellent tool to help engage these teams in important project related discussions. The Meeting Workspace makes sure team members are better prepared for the meeting:

  • Objectives of the meeting are well understood
  • Meeting attendance is up-to-date
  • The agenda is published in advance of the meeting
  • Status of follow-up actions from previous meetings is maintained on an on-going basis
  • Pre-read materials for the meeting are available on the Meeting Workspace site (or links are provided to other locations on the project site)

In addition, the Meeting Workspace is used to continue collaboration on follow-up actions after the meeting:

  • Minutes are published that summarize key discussion topics, and more importantly decisions made during the meeting. How many times have you left a meeting wondering what was really accomplished or decided? Use of the Meeting Workspace to reenforce good meeting related processes helps upgrade the efficiency and effectiveness of your team meetings.
  • Action items are maintained in a list, including person responsible, target date, and current status of the action item. Collaboration continues on this list until actions are closed.

Below is an example of the Meeting Workspace for a Steering Committee.

Milestone / Review Meetings

The Meeting Workspace is also a very effective tool to manage significant team events, such as milestone or deliverable review sessions. These type of sessions are very important to the success of the project, because they are utilized to obtain feedback from key stakeholders and make strategic decisions about the both the project and the product. In addition, these meetings are generally expensive to conduct due to the length of the session and the number of people involved. The Meeting Workspace helps ensure that these sessions are as efficient and effective as possible:

  • Stakeholders understand the objectives of the session
  • An agenda is established that outlines what will be reviewed / discussed, and who is facilitating each discussion topic
  • Documents to be reviewed are available within the Meeting Workspace (or links to other locations on the project site are provided)
  • Decisions made about the milestone or deliverable are recorded
  • Follow-up tasks to complete the review, or make a final decision, are captured and continued to be updated until all open tasks are closed and the review is considered complete.

Below is an example of a Meeting Workspace for a milestone review session.

Integration with Outlook

One of the questions I frequently get asked when talking about using the Meeting Workspace to improve project delivery is, “Isn’t there additional effort to keep the information on the Meeting Workspace in sync with calendars in Outlook?” The answer to this question is that there is excellent integration between Outlook and SharePoint for scheduling the meetings, and managing attendees. Therefore there is no additional effort required to keep your Meeting Workspace and Outlook calendars up to date. When setting up a new meeting on your Outlook calendar, you can link an existing Meeting Workspace or create a new Meeting Workspace using the Meeting Workspace icon (see the icon circled in the screenshot below).

The link to the Meeting Workspace is saved in the body of the meeting notice in Outlook (see below). This makes it easy for team members to access the pre-read materials and other information about the meeting right from their Outlook calendar.

5 Benefits of Using SharePoint to Manage Team Meetings

  1. Establishes structure & organization – We know the right things to do for effective meeting management (agenda, minutes, action items), but we do not always do them consistently. Using the Meeting Workspace to manage meetings helps re-enforce team meeting related best practices and establishes good structure and organization for your team meetings.
  2. Easy access to pre-read materials – From the Meeting Workspace, team members can easily find the information and materials required to prepare for the meeting. These materials can be maintained in a document library on the Meeting Workspace, or provided as a link in the Meeting Workspace.
  3. Integration with Outlook – Using the Meeting Workspace icon when setting up a meeting in Outlook, you can link to an existing Meeting Workspace, or create a new Meeting Workspace within your project site. The link to the Meeting Workspace is maintained within your Outlook meeting notice to provide easy access to additional information about the meeting.
  4. Documents do not get lost in Project Artifacts – Meeting minutes and other key meeting artifacts are maintained in a self-contained document library tied to other information about the meeting (agenda, action items, attendees). These documents often get lost when they are maintained in the project deliverable library.
  5. Collaboration after the meeting – The use of the Meeting Workspace encourages on-going collaboration around key discussion topics, after the meeting is conducted. This collaboration ensures that all team members understand the decisions that have been made, and proactively perform the follow-up actions that were assigned.

PM Foundations – Managing Schedule Performance

Project success is highly dependent on understanding actual progress compared to planned progress, and making the appropriate adjustments throughout project execution. Based upon my experience, the project schedule represents the single most important source of information to assess and manage project performance. The project schedule provides information related timing, work effort, and resource utilization – all important elements of identifying variances, performing root cause analysis, and implementing corrective actions.

Assessing Schedule Performance

Effectively managing schedule performance starts with performing regular analysis of the schedule to identify potential problems or opportunities in the schedule. Begin the analysis at a high level by looking at key summary tasks and milestones.

Look for areas that the planned dates are not tracking with the baseline dates:

  • Finish variances indicate tasks or milestones that will either complete early or late.
  • Start variance indicate tasks or milestones that will either start early or late.

In addition, examine the % Complete:

  • Do you have gaps between the duration that is completed and the work that has been completed? These gaps point to areas where progress is largely tied to non-resourced tasks, and “real work” may be “hidden” by this progress.
  • Do you think it is reasonable to complete the remaining work in the days remaining for the task (or series of tasks)? To answer this question, you may need to take a closer look at the detailed tasks below the summary task, or the tasks tied to the milestone.

Performing Root Cause Analysis

Once you have identified that a summary task or milestone is potentially slipping, you must identify the source of the potential problems. Look deeper into the schedule to identify the task or group of tasks that are driving the variance.

Examine the tasks to determine the specific cause of the variance:

  • The duration was adjusted, moving the end date out (likely because the task is late getting started).
  • The work effort and duration were adjusted, moving the end date out (likely because the effort is greater than planned).
  • The end date for a dependent task moved, impacting this task.
  • New tasks were inserted into the schedule that this task is now dependent upon.

Generally, the next step in the process is to talk to team members to find out the reason these changes were made. Many times you, as the project manager, were the one that made the change so you already know the answer to these questions. Look for the “rest of the story” associated with this variance:

  • Why is the task late getting started or finished? Is it related to resources? Resources have not been available to start/finish the task, or the resources are struggling with the tasks?
  • The work effort has turned out to be greater than originally planned. Is this because scope has been added, or potentially with more information (clarification) it has turned out to be something different than first planned?
  • Are there open issues associated with the task that are preventing progress (the task is “stuck” awaiting resolution of issues). The issue tracking log is a good source of information for this type of problem.
  • Are there assumptions that were made during the planning process that have turned out to be false (or not 100% true). During the schedule analysis process, it is extremely helpful if the assumptions were documented “in-line” within the schedule (in the notes field of the project schedule).

Note: This same thought process should be utilized for analyzing positive variances in the schedule. Analysis of positive variances helps you understand if you may have opportunities to improve the delivery date of key milestones, or at a minimum offset other negative variances.

Implementing Corrective Actions

Now that you have identified a potential problem in the schedule, and determined a reasonable explanation for the source of the variance, you need to decide on the appropriate next steps. The real decision you need to make is whether or not the variance should be formalized as a project impact (managed through the change control process). Considerations to help make this decision include:

  • Is this variance permanent (the time lost will not be recovered), or temporary (it is a timing issue that will be recovered at some point in the future)? Generally, timing issues are not formalized as project impacts.
  • Is the variance material? This is generally determined based upon whether or not it has an impact on a milestone that would be significant to the project sponsor or another stakeholder.
  • Are there other actions or adjustments to the schedule that could be implemented to recover the time associated with the variance on this task? If with other actions this variance could be recovered, it would be treated in the same manner as timing variance.
  • Will the variance have a direct impact on the milestone date, or is the milestone date “buffered” with a schedule reserve. If the milestone has a schedule reserve, you may decide to use all or part of the reserve to offset the variance (rather than formalizing it as a project impact). If you feel there is still significant risk associated with the milestone, it would probably be wise to formalize this project impact, and leave the schedule reserve “as is”.

If the decision has been made to formalize the variance as a project impact, you would initiate the change control as described in my blogs on Managing Change. After the project impact has been approved, you would likely re-baseline these tasks, establishing new dates, and eliminating the variance.

If the decision has been made not to formalize the variance as a project impact, you would document the explanation for the variance and the planned next steps associated with the variance. The best practice is to use the Notes field within the project schedule to document this type of analysis. During on-going schedule analysis you would continue to monitor the variance and explanation to ensure that the original decision not to formalize it as a project impact is still appropriate.

Schedule Performance Reporting

Schedule performance is a metric that is reported on a regular basis to the project sponsor and key stakeholders. In many cases it is incorporated into project status reports. In most cases it is a discussion topic during Project Steering Committee updates. For each of the summary tasks (project phases) or key milestones reported, the following information is provided on a regular basis:

  • Planned (Baseline) vs. Projected (Current) Finish Date – Both of these data points are obtained directly from the schedule for the summary task or milestone.
  • Variance – It is helpful to report the variance in terms of both days, and as a percentage of the total duration for the summary task or milestone. The variance is also obtained directly from the project schedule, and the variance percent is calculated based by dividing the variance by the total duration.
  • Trend – Comparison of the variance to previous reporting periods. Is the metric trending positively, negatively, or holding steady?
  • Comments – Explanation of the variance, and the next steps that are planned to monitor / manage the variance (including project impacts that have been initiated)

The information reported may be a summarization of several variance explanations documented during the schedule analysis process. Make sure the level of information is appropriate to the audience you are reporting it to. If a variance is formalized as a project impact, it would by default be reported to the project sponsors through the normal change control process.

Schedule Performance – Critical Success Factors

The accuracy and credibility of the schedule metrics and project performance management process are highly dependent on the following critical success factors:

  1. The first success factor is fairly obvious, but nonetheless the most important. The original baseline created, approved and saved in the project management tool, must be solid. If the baseline is not strong, comparisons to actual results will be difficult to explain and manage throughout the entire project life cycle.
  2. As project impacts are approved and implemented, the project schedule (or the portions impacted) must be re-baselined. If you do not re-baseline the schedule, the original variance will still be included in with any new variances that occur (confusing the on-going schedule analysis and reporting process).
  3. Another obvious success factor, and equally important, is that the schedule performance analysis is only as good as the schedule you are analyzing – the current schedule must reflect the current “reality” of the project. Therefore the schedule must be maintained and managed in a manner that keeps it in synch with the way that work is being performed by the team. This success factor includes:
  • Timely and accurate progress updates (updating based upon the 25, 50, 75, 100 rule will be give you a good picture of progress on the project).
  • Material changes to durations and work estimates should be adjusted within the schedule. These adjustments should be what moves task start and finish dates. Try to avoid manually adjusting dates (this will result in building unnecessary constraints into the project schedule).
  • Make other adjustments required to keep the schedule in synch with the work to be performed (e.g., new tasks, changes in task sequence, and resource assignments).

PM Foundations – Project Closure Feedback Survey

When project managers discuss project closure, the primary best practice that they focus on is the lessons learned process. Although I agree that lessons learned represents an integral best practice area performed during project closure, I do not believe it represents the “only” best practice for gathering stakeholder feedback. The project closure feedback survey represents a “safe” vehicle for project stakeholders to provide thoughtful input. People that may not speak up during a lessons learned discussion are more likely to provide valuable feedback on a project closure survey. The project closure feedback also provides the ability to capture project closure metrics (in addition to “free form” comments and ideas). In addition, performing the project closure feedback survey process provides the ability to bring a little more structure to the lessons learned session. Rather than starting from a “blank sheet of paper”, the lessons learned discussion can be organized around the major themes / observations captured in the project closure feedback survey.

Survey Content

The project closure feedback survey should be focused on gathering input from the stakeholders in two areas:

  • Does the product delivered meet the stakeholder’s expectations?
  • Did the processes associated with completing the project work meet the stakeholder’s expectations?

The following represent key topics covered within the survey:

  • Business results – Has the project/product enabled the anticipated business results/benefits?
  • Expectation / requirements – Were the expectations and requirements of the project / product well defined and understood on the project team? Were the requirements effectively implemented? Were the expectations met?
  • Communications – Was communications about the project effective and timely? Were the appropriate communications vehicles utilized? Did communications include the appropriate content?
  • Project Execution – How effective were the process and tools to complete project work? Were the appropriate plans in place to properly guide the project team throughout the project life cycle?
  • Overall – Overall rating of the success of the project (both what was delivered, and how it was delivered).
  • Comments – Blank area for stakeholders to provide feedback about things that were done well on the project, and areas for improvement.

Below is the project closure survey that I frequently utilize to capture feedback from stakeholders.

This sample survey highlights some of the best practices associated with capturing feedback about the project:

  • The survey should include a limited number of questions. If there are too many questions, people will not take the time to complete it.
  • Provide space for comments after each question. This encourages people to provide explanations for their score (particularly for high or low scores).
  • At the end of the survey provide an area to capture general comments. What are the things done well? What are the areas for improvement? These comments often help to identify “themes” for the lessons learned discussions.

Survey Distribution

Feedback should be solicited from key project stakeholders:

  • People that participated in completing the project deliverables (anyone whose name is on the project schedule). You need to decide if the person’s role is significant enough for them to have feedback about the project (error on the side of being inclusive).
  • People that participated in oversight of the project (steering committee, project sponsors)
  • People that provided input from the business areas that are impacted by the project (key end-users or subject matter experts).

If you think feedback may vary based upon the groups completing the survey, you may want to capture some demographics related information (e.g., business vs. IT, management vs. team member). The demographic information is especially relevant if you think it may influence the follow-up actions (e.g., end-users are not happy with the product delivered, IT feels the scope was constantly changing).

Collaboration tools such as SharePoint provide the capability to conduct the survey within the team’s project site. There are also other survey tools that may be available at a client. The easier it is for the stakeholder to open and complete the survey, the more likely they will take the time to do it. Do not underestimate this fact.

Summarizing Survey Results

It is important to give the stakeholders a deadline to complete the survey, and then summarize and provide the results in a timely manner. The information provided in the survey is generally a good starting point for the lessons learned discussions. Therefore the survey deadline, publishing survey results, and scheduling the lessons learned session are best planned and communicated at the same time, when the project closeout process is initiated.

The following activities are included in the process of summarizing survey results:

  • Compute the survey metrics. What is the average score? What is the distribution/deviation from the average score (e.g., number of high or low scores)?
  • Summarize comments for the rating. Highlight/summarize the comments for questions that provide insights in terms of why people feel the way they did when providing the rating.
  • Using demographics to explain results. The demographics data may assist in providing insights around the results (e.g., IT was not happy with the way the work was estimated)?
  • Grouping Comments. You are looking for common themes about things that went well or could be improved. Grouping the comments into the common themes provides potential topics to launch discussions during the lessons learned session. Some guidelines on the defining the themes:

Will the theme be understood by the stakeholders (e.g., not too general)

Look for areas that you are likely to get consensus (not just one person’s opinion)

Is the theme likely to lead to something actionable (capitalizing on something done well, or implementation of improvement)

Stakeholder Feedback Best Practices

In my experience the following are the key best practices associated with capturing project closure feedback, and communicating survey results:

  • Solicit and communicate feedback in a timely manner – Try to complete the project closure feedback process before most people transition out of their role on the project. It is important that the project is “fresh in their minds” when they are providing feedback. In addition, do not wait too long after the survey is conducted to communicate the results.
  • Keep the survey simple – The survey must be easy to access, and not too time consuming to complete.
  • Target the right people – Make sure you distribute the survey to people that were involved enough in the project to provide valuable insights. However, error on the side of being inclusive in the survey process.
  • Does not need to be conducted just at the end of the project – You do not need to wait until the end of the project to capture feedback. It is often helpful to capture feedback at key milestones also. This gives you an opportunity to make “course corrections” for the next phase of the project.
  • Do something with the information captured – Make sure that the appropriate next steps are initiated after the survey is completed. The most common next step for this process is to set up the lessons learned session to elaborate on the feedback, and formalize the action items / assignments.

PM Foundations – Project Assumptions

You have probably heard the saying, “Be careful when you assume something. It will end up making an Ass of U and ME.” From a project management perspective, assumptions are your friend. Assumptions are things that you believe to be true which may not be true. Assumptions help you clarify the thought process behind project plans. They also make it possible to get beyond seemingly impenetrable roadblocks during the planning process. Every project has a certain number of unknowns. If we waited until everything was known, a project would never get started.

 

Examples of Assumptions

  • Benefits associated with the project – When building a business case, you often need to make assumptions about what impact (hopefully positive) the project will have after it is completed. You can gather information (e.g., time studies) to refine the assumptions, but there will still be unknowns until the new processes and systems are in place and fully operational.
  • The way things will work within the product – You do not know exactly how something is going to work until you start to define and build it. This means that during the planning process you probably need to make some assumptions about what “it” is. These assumptions will impact the planned effort and duration of the project.
  • Things you can leverage to develop the product – Often times you are not starting from scratch. There are assets from previous efforts that can be reused, but you may not know exactly to what extent. Another good example of when to create an assumption.
  • Resources you will use to build the product – The number and types of resources will definitely have an impact on the timing and quality of your efforts. At the time you are planning the project you may or may not have all the exact resources in place – this includes the partners that you may hire to help with the effort. The assumptions in this area also include things like: Do I need to include time and costs for training? Do I have the facilities and computers available to support these resources?
  • Dependencies and lead times – What needs to be completed to start working on specific activities? If you wait for all the answers to these questions, you will never complete the project schedule.
  • Cost of developing the product – You may not have all of the exact cost estimates, but you need a project budget. Again, you can gather information (e.g., costs from similar projects) to refine the assumptions, but you may still have some unknowns associated with the cost / pricing for specific components of the effort. Insert an assumption.

When do you make assumptions?

  • Developing the business case – As I mentioned in the examples, during project initiation, when you are developing the justification for the project, there will be a ton of unknowns and assumptions help construct the initial business case for the project.
  • Developing the project plan – Throughout the planning process (defining the product and project scope, creating the project schedule, and developing the project budget) there will be things you will not know until you get to that point in the project.
  • Managing change – As project changes occur you may not know the exact impact of the change on the project or product. This is a good example of why assumptions must be managed throughout the project life cycle.
  • Managing risks – Just by the very nature of a risk, assessing the probability or impact of a risk may require some assumptions (e.g., if this risk occurs it will delay the project by 2 weeks). Try and get your mind wrapped around that one – unknowns related to the unknowns.

Best practices associated with assumptions

  • Do not use assumptions to CYA – be specific, and you must believe them to be true – I hate it when I run across assumptions like: We have enough resources to complete the project. –or- The client will be available to approve the deliverables. These assumptions are either added because of a CYA mentality or because they are believed to be untrue. Assumptions need to be specific and manageable, and most importantly you need to believe they are true at the time you identify them – if not, they are just “noise” in your project plans
  • Make sure they are documented – When you identify an assumption, document it, either in the project management plan or in a separate list of assumptions that are maintained and managed. Some assumptions seem innocent enough, but I have had plenty of times when we have had to revisit the rationale behind the plan because we did not document the assumptions well enough.
  • Assumptions need to be managed throughout the project life cycle – On an on-going basis you need to review and test your assumptions, particularly the ones that are critical to your plan (scope, timing, or cost). Assumptions can be deleted from the list as work is completed and they are OBE (overcome by events).
  • Focus on the key assumptions – Over time you tend to accumulate a lot of assumptions. Make sure that you have established a mechanism to focus on the critical assumptions (based upon the timing of the project activities, and the nature of the assumption).
  • Assumption management is tied to the risk management process – As discussed above, managing assumptions is directly tied to managing risks because they both relate to unknowns. It is a best practice to perform a quick review of key assumptions at the same time you are updating the risks. Think of it in the same way as changing the batteries in your smoke detector when you change your clocks for daylight savings time.

PM Foundations – The Change Control Process

I recently blogged about managing changes to your project this post discussed the definition of change, sources of change, early warning signs, the change control process, and measuring change. In this post I am going to focus in on the 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. The change control process enables proactive identification and management of change, in a manner that keeps the project moving in the right direction, towards successful completion/delivery. Effective change control processes maintains the appropriate balance between control/discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. In the spirit of not overcomplicating the process, the basic steps associated with the change control process are pretty straightforward (depicted in the graphic below).

Identify Change

Changes may be identified while updating and evaluating schedule progress, performing project budget updates and analysis, assessing on-going project risks, performing quality control activities, and engaging with project stakeholders (e.g., project team, project sponsors) via normal project communication channels.

Here are some examples of how you may identify change in your project:

  • While comparing the work results to the plan (part of monitoring and controlling project work), you realize that testing activities are taking twice as much work effort to complete based on original estimates.
  • A risk is identified that a key resource will be taking a leave of absence during a critical month of the project.
  • You are updating the project budget and identify that consultant rates are consistently tracking 10-12% higher than originally planned.
  • You are managing a project for the introduction of a new product. The company finds out that a competitor is developing a similar new product, and something will need to be done in order to be competitive. This is brought up at a project sponsor update meeting, and requires follow-up actions.
  • During load testing, the team realizes that the technology architecture is unable to handle the necessary volume. This started as a project risk, and is now a project issue.

During the process of identifying the change, the project manager will refer to the guidelines established in the Project Management Plan to determine if this is a change that should be managed utilize through the formal project change control process. Factors such as the following are utilized to determine which changes should be formally documented and managed:

  • The impact of the change represents a permanent change to the project baseline (not a timing related change)
  • The change has a significant impact on the project baseline (above the materiality threshold established for the project)
  • The change represents something that is new or different than what was utilized to establish the baseline plan. Clarifications or more detailed definition of planning components (progressive elaboration) generally are not handled as project changes. This is a point that is often contentious from a customer relationship perspective.

Changes should be documented in detail using a project impact report (PIR) for each individual change. The project impact report should include the following information based on the assessment (at a minimum):

  • Change Header Information
    • Project Name
    • Project Impact Number (reference number assigned for the change)
    • Date (date the project impact report was created)
    • Project Manager
    • Project Sponsor (who is accountable for the project)
  • Description of change and how it impacts the project
    • Checkbox for areas impacted by the change (scope, schedule, cost, quality, risk)
    • Background (includes information like why or how the change was identified, reason for change, benefits of implementing change, and/or risks associated with not implementing change)
    • Impact Descriptions (description of how the change impacts each of the project areas identified as impacted in the checkbox)


All changes should be added to a change control log in order to track the status of the change. The change control log should include the following information (at a minimum):

  • Unique tracking # assigned on the project impact report
  • Title (one line summary description of the change)
  • Date Created (date the change was formalized utilizing the PIR)
  • Cost Impact – in dollars (quantification of the cost impact of the change)
  • Schedule Impact – in days (quantification of the schedule impact of the change)
  • Scope Impact (quantification of the scope impact of the change)
  • Status – indicate where the change is in the change control processes (Assess, Approval, Approved, Implemented, Complete, Rejected)
  • Status Comments – provide more details about the status and history moving through the change control processes

The change control log is the place that any project team member can go to see all of the changes that have been identified and the current status of all of those changes.


Assess Change

Once a change is identified, it needs to be assessed for impacts. The following dimensions of the project could be impacted: scope, schedule, cost, risk and quality.

  • Is the current baseline scope going to be impacted and how? Is the current baseline schedule going to be impacted? Is the current baseline budget going to be impacted? Is the agreed upon quality of deliverables and/ or product going to be impacted? Is the change going to impact the assessment of project risk?
  • The impacts could be positive or negative.
  • As the project manager, you are managing expectations. Establishing a baseline helps manage expectations among stakeholders and commitments to the customer/ end users. If that baseline will be impacted by a change, that needs to be examined.

It is important to quantify the impacts of a change. If the impacts are not clear, it is difficult to make an appropriate decision about whether or not to approve and implement a change to the project.

  • When possible, impacts should be quantified by indicating cost impacts in dollars, schedule impacts in work-days, resource impacts in hours effort, risk impact in terms of the risk assessment (before and after implementation of the change), and quality in terms of impact on open defects / issues.
  • For example, there is a change request to add functionality to a system, and development has already been started. The assessment should identify what activities are required to add that functionality, including the additional hours of work and cost of that labor, and the resulting schedule impacts of doing that work. When considering what activities are required to add the functionality, you have to consider the fact that the system requirements, system design, and test plan will all most likely need to be revised. Also consider any re-work that may have to be done for parts of the system that have already been developed. It may also be possible to quantify the increase in user satisfaction by adding the functionality to the system.

It is important to involve the appropriate project team members in describing and assessing the change so that impacts are accurately assessed and quantified. It is usually members of the core project team that assess changes. Each core project team members should be able to speak to the impacts specific to their area of expertise or their group. The impact of the change is documented on the project impact report:

  • Impact Estimate (quantification of how the change impacts each of the project areas, including the assumptions associated with the impact estimates)
    • Product Scope – Number of features changed / added
    • Project Scope – Number of deliverables changed / added
    • Schedule – Days impact on key milestones, hours impact on resource estimates
    • Cost – Dollar impact by cost category
    • Quality – Change in open defects / incidents
    • Risk – Change in risk severity or probability estimates

Approve Change

The Project Management Plan establishes the change review and approval process (you do not want to be in a position where the process is “invented” in response to the first change).

The following describes the key guidelines associated with review of changes:

  • Generally, projects establish a regular timing for submitting / reviewing changes (e.g., change control board meets every other Wed., and changes must be submitted by EOD Monday)
  • In addition, a process must be established to accommodate review/approval of “rush” changes. These are the changes that have a time constraint for associated with making a decision about the change and/or have an extremely high impact on the project.
  • At a minimum, the project impact report is submitted for review / approval. Some changes will require additional supporting documentation to better describe / explain the change or impact of the change. For higher priority or high impact changes, it is generally best to provide a face to face explanation.

The following describes the key guidelines associated with the approval process:

  • The core team (or select members of the core team) approve all changes. This confirms that the core team agrees with the assessment, and the implementation approach for the change.
  • The project sponsor or project steering committee approves changes that are over a specific impact threshold (e.g., two weeks, 40 hours, $2,500, new feature).
  • The customer’s environment (compliance requirements) generally establishes the process associated with documentation of the approval (email, collaboration tool, verbal, signed copy of the PIR).
  • The timing of the approval process is established to ensure that the impact does not become larger, due to delays in the approval process.

Note: The review / approval process should occur BEFORE the actual change has occurred, and the corrective action has been implemented. This allows the reviewers/approvers to make decisions associated with changes to the project, and the change implementation approach.


Implement Change

The same level of rigor is required to plan changes to the baseline plans, as were required to develop the baseline plan originally. This is an area that many teams fall short – they often behave like change is complete at the time it is approved (contrary to popular opinion, changes do not implement themselves).

In addition, it is important to adjust the planning artifacts to reflect the most current “version” of the plans:

  • Project Management Plan – Project description is updated to reflect adjustments to the product and/or project scope
  • Project Schedule – Deliverables, activities, dependencies, and milestones are updated to reflect the impact of the change on the project schedule. In addition, the schedule baseline is adjusted (using “set baseline” in MS Project) to reflect the impact of the approved change on the project timeline.
  • Project Budget – Planned and forecasted amounts are adjusted to reflect the impact of the approved change on the project budget
  • Risk Log – Risk ratings (probability and/or impact) are adjusted based upon approval and implementation of the change. In addition, the risk log is updated to reflect new risks introduced with implementation of the change.
  • Project files – Change control documents (project impact reports, and change control tracking summary) are maintained in the project files (e.g., team collaboration site)

Communication of the approved changes is an important element of effective change control:

  • All core team members and key stakeholders are aware of the approved change, and the impact of the change on the project baseline
  • Team members are on-board with adjustments to their assignments, based upon the implementation of the approved change

Follow-up

The final step in the change control process is to perform follow-up on the implementation of the change:

  • Verify that the action items identified to implement the change (documented on the project impact report) have been completed.
  • Based upon implementation of the follow-up actions, re-assess the impact of the change and adjust the impact estimates (if required).
  • Update the status of the change (on the change control summary log) to reflect that it has been fully implemented (and closed).


Change Control Best Practices

Be proactive. The cost of implementing change increases later in the project/ product lifecycle. Utilize key 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 (number activities, cost budget, number of resources), complexity (number and types of dependencies), and risk profile (number and distribution across project activities of high priority risks) are evaluated to adapt the change control processes to the project.
  • If changes often have very different impacts (e.g. much higher cost or schedule impacts) when they are implemented, 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 to ensure 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.

Ensuring that the change is implemented appropriately is critical because all of the effort that goes into analyzing and making decisions does not matter if the change is not actually implemented fully and correctly.

  • There should be follow-up to confirm the implementation steps have been completed.
  • Actual results should be captured to the planned impact of the change

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