The Problem with RACI

While the Project Management Body of Knowledge (PMBOK Guide®) may refer to it as a Responsibility Accountability Matrix, everyone I know calls it a RACI Matrix. It is supposed to clarify roles and responsibilities, yet it often creates more confusion that it clarifies.  So let’s look at this tool, the benefits and the pitfalls that create the problems.

Assigning responsibility for work is an age-old principle.  Even in early civilization, some people were designated to have certain responsibilities. The ancient kings had cupbearer, chariot drivers, shield-bearers, and ministers of all types.  These individuals had specific responsibilities and if they didn’t perform the punishment was often sharp and swift.  In more modern times, thanks to Fredrick Winslow Taylor and scientific management theory, everyone in business has a designated role or position and they are expected to become expert at the responsibilities associated with that role.

But projects are a little different.  They don’t always lend themselves to scientific management principles. Projects are temporary endeavours undertaken to create a unique result.  Individuals on the project team are temporarily assigned to work on project activities, and some of those activities may not be well defined.  Because of the unique nature of projects, a pattern may not already exist.  Roles, responsibilities, authority, and accountability need to be assigned to prevent duplication or work or missing work.  Which brings us to the RACI matrix.

RACI Matrix

The RACI matrix is the most common tool for assigning roles and responsibility to project team members.  The matrix is structured by placing the project tasks on one side of the matrix, normally the vertical axis; and the project team members on the other side of the matrix, normally the horizontal axis.  The role of each individual with respect to each task is then noted in the matrix as either R – Responsible, A – Accountable, C – Consulted, I –Informed, or left blank if the individual has no role.

The RACI matrix assigns a role to each individual, but it does not clarify what they are supposed to do.  And that is what leads to the confusion.  Who plans the task – the “Accountable” person or the “Responsible” person?  I have seen it explained both ways.  Does the “Consulted” person only participate when asked, or are they expected to engage and ensure their perspective is included?  Again I have heard it described both ways.  And then there is the question, “How can someone be accountable but not responsible, or responsible but not accountable?” 

Questions like these and others have led to a plethora of variations on the RACI matrix.  The fact that there are so many variations is an indication that there is a major flaw with the RACI approach.  If it was working well, people wouldn’t be trying so hard to improve it.   Let me list a few of the alternate approaches.

Alternate Responsibility Matrix Approaches

• ARCI – rearranging the letters because Accountable is more important than Responsible.
• RASI – Responsible, Accountable, Support, and Informed attempts to better define the original Consult role by now calling it Support.
• RACIQ – Responsible, Accountable, Consulted, Informed, Quality reviewer – this adds a role for review and approval.
• RACIO – Responsible, Accountable, Consulted, Informed, Omitted – this approach is meant to ensure that some individuals do not engage on a task and tamper with what is happening.
• RATSI – Responsibility, Authority, Task, Support, Informed – a slightly different segmentation of roles meant to clarify the differences as compared to the original RACI.
• RAPID – Recommend, Agree, Perform, Input, Decide – a variation that focuses on decision making authority rather than on the actual task activity.
• PACSI – Perform, Accountable, Control, Support and Informed – a variation that identifies some activities that must be done in addition to roles.
• DACI – Drivers, Approvers, Contributors, Informed – a variation that focuses on the type of activity that the person does rather than their role.
• CLAM – Contributes, Leads, Approves, Monitors – another variation that focuses on the type of activity rather than roles.

There are probably more, these are just the ones that I am aware of. 

The Problem

So what is the fundamental problem with RACI?  I believe it is that while defining roles, it does not clarify actions.  But clear actions are what a project needs.  As a retrospective tool to look back on a situation, RACI is effective.  It can determine who was responsible for success or failure?  Who was accountable for ensuring the task was completed?  Who was consulted along the way and how effective was their input?  And who was or was not informed and what impact did that have on the project?  Great questions when doing a post-mortem on a project; but not very helpful for proactive project management.

 When planning and executing a project, the project team members need to know who is doing what.  A matrix focused on actions associated with each task is much more beneficial to the team.  Who is planning the work?  Who will be helping on the task?  Who are the stakeholders that have to approve or sign off on the results of the task?  With these answers, the project leader and project team can manage their resources, coordinate the schedule, and ensure that risk mitigation plans are being executed in a proactive manner.  They don’t have to wait for success or failure and they try to understand what happened.

Recommendation: DACI or CLAM

For that reason, I recommend the use of either the DACI or CLAM approach.  These are activity-based matrices.  I have found that the level of confusion concerning who is doing what is significantly reduced when these are used in project planning and execution.  

Project Kanban – Integrating Scope, Schedule, and Resources

One of the latest techniques in project management is to use a Kanban approach to project scheduling.  Those advocating for this scheduling tool highlight the characteristics of blending resource allocation with schedule and scope management.  Some even go so far as to say that it is more than a tool; it is a brand new methodology.  Let’s look at it in more detail.

This approach is often tied to Agile methodologies, but it has actually been around far longer.  I was using a modified Kanban project scheduling tool in the 1980’s.   The tool shows the relationship between scope schedule and resources.  Like the Gantt chart, it is very effective for managing the day-to-day status and tracking.  And also, like the Gantt chart, it is a tool that can be used with many different project management methodologies. 

This tool works best for those projects where many different deliverables go through similar steps or activities.  The Kanban schedule is set up as a matrix.  The vertical side of the matrix is the list of project deliverables.  The horizontal side is the steps or activities in the project.  Normally, at the top of the matrix, the level of resources available for each step is listed either in terms of the number of individuals or the number of deliverables that can be actively worked at one time.  See the diagram below.

Kanban Principles

Kanban scheduling relies on two important principles.  The first is that it is “pull” scheduling, not “push” scheduling.  This means that a deliverable does not move to the next step until there is a resource available to work on it.  As soon as the resource completes a deliverable, it pulls the next deliverable from the preceding step.  That way a step does not become glutted with many deliverables all hung up at a bottleneck.  

The second principle is that it is a “visual” scheduling tool.  The “pull” indicator is visual and the status of how many items being worked on at one time is also visual on the matrix.  In addition, I normally will change the cell color of the deliverable and the step to show what is being worked on and what is completed.   Visual control normally leads to improved project team communication because it is simple to understand.

Kanban Weaknesses

There are two weaknesses with using Kanban scheduling.  The first is that it is difficult to translate the schedule to a calendar.  The Kanban schedule is a matrix.  Often the matrix will have dates for each step of each deliverable, but it is difficult to take a table of dates and picture what is happening on a calendar.  That is why I normally will also use a calendar-based Milestone chart when using a Kanban schedule. 

The second weakness is that it is very difficult to track inter-relationships between deliverables.   If the deliverables are separable that is not a problem.  If there are numerous points of interaction between deliverables, the ability to pull can be confused.  In that case, the network diagram is a better scheduling tool because it shows those relationships and allows the project team to calculate a critical path.

Planning with Kanban

So let’s talk through how a project plan would be represented using a Kanban schedule.  First create the list of deliverables – this is usually derived from the scope statement or project contract.  Then determine the categories of activities that must be accomplished on each of the deliverables.  This is the same type of activity you would do when developing a work breakdown structure.  With these two pieces you can build the matrix.  Next, determine the resources capacity you have for each activity type.  Finally, estimate the amount of time required for each deliverable and estimate the dates when each activity will end for each deliverable.  Place that date in the appropriate cell of the matrix.  See the diagram below.

Managing Project Progress with Kanban

The Kanban tool is an excellent tool for managing day-to-day project activities.  Thanks to the visual control aspect, it is easy to see what is underway, what is complete, and what is coming up next.  Because I use cell colors to indicate activity status, the current project status is easy to see.  Also, problem deliverables or problem steps will quickly “jump out” from a review of the matrix. 

In the diagram below it, the present date is July 25.  It is easy to see that Deliverable #7 is behind schedule.  This is a major issue on the project and should be receiving the project manager’s focused attention.  In addition, the “Update/Debug” step is becoming a bottleneck.  There are five deliverables that could in process at that step, #3, #4, #6, #10, and #11.  However, the capacity is only to work on three, so deliverables #4 and #11 are not being worked on by anyone at this time.  So far it is not a major bottleneck, but deliverables #2, #8, #12, and #13 are in work in the previous activity and could be turned over to the update/debug queue soon.   

The Kanban schedule tool can be very useful for some types of projects.  It combines scope, schedule and resources into one easy to read visual display.  If this tool is not currently in your project management toolbox, you should consider adding it.

De-mystifying Earned Value – Cost Account Manager

In many cases, tell a project manager they must use earned value analysis on a project and you will hear a groan.  Earned Value Management has been tainted with an aura of overwhelming bureaucracy and incomprehensible numbers and ratios.  While some organizations may have done their best to confuse and confound project managers and project teams with Earned Value Management – it is really a very basic and easy to use set of project analytics.  This blog post will explain the role of the Cost Account Manager.  To learn more about de-mystifying earned value, download my ebook on the topic which can be found at the end of this blog.

Cost Account Manager

A common question when an organization embraces earned value management is, “Who does the earned value analysis?”  Earned value is usually a shared responsibility between the Finance, the project manager, and the Cost Account Manager (CAM).  Finance does the system work and prepares the formal report.  The project manager and CAM do the project level work and interpret the analytics.  On small projects, there may only be a few cost accounts and the project manager will normally act as the CAM for the entire project.  On large projects there can be dozens or even hundreds of cost accounts.  On those projects, CAMs will be assigned to each cost account and the project manager analyses earned value metrics at the project level.  Often I find that one CAM will have responsibility for several accounts.

Budgeting

The CAM’s responsibility starts at the time of project budgeting.  The CAM should either create the estimate for the work in their accounts, or review the estimates being created by others to ensure accuracy.  There are four areas of particular concern that a CAM must closely review:

• A clear definition of the end of the task – the definition of done – and any assumptions associated with the work are validated with the rest of the project team and stakeholders.
• The expected start and finish date of the task are based upon the final project schedule.  Schedules often are developed iteratively and the dates for activities may change several times in the planning stages of the project.
• The estimates for all resources that will be involved on an activity are included.  Task leaders have a tendency to under-estimate or forget about other resources required to accomplish a task.  Therefore the total estimates they provide are too low.  Validate that all organizations and individuals who must work on the task are included in the estimate.
• What allowance for risk, if any, has been made in the cost or schedule estimates?   This question must be negotiated with the individuals on the task and the project manager.  If the task is a high risk task, either the task estimate should include risk mitigation resources or the project leader should be aware of the risk and have a contingency plan. 

If the task estimators have done a good job, the CAM will only need to spend a few minutes to budget each account and set the Planned Value (PV).  The CAM should strive to get the PV as accurate as possible.  Errors in the PV will lead to variances and variance reporting.  It is easier to take a few minutes up front and get an accurate PV than to write variance reports every month.

Project Execution

The CAM must track project execution and make an Earned Value (EV) estimate for every open task at least once a month.  This normally does not take long.  For tasks that have not started, the EV is zero – no value has been earned.  For tasks that are complete, the EV is the value of the PV – all value has been earned.  So the only tasks requiring any effort for estimating EV are the tasks that are underway during a given month.  For many of those tasks the EV can be set using the 0-100 or 30-70 rules that were discussed in the Variance blog post.  Again, this takes very little time.  The only difficult tasks are those assessing progress at the micro-task level.  If the project was planned at the micro-task level, this is still easy – take credit for all the completed micro-tasks. 

The difficulty is determining the amount of EV for a long complex task that was not planned at a micro-task level.  The common phenomena is that the task stays on schedule until the EV gets to 90% complete, and then it hangs-up at 90% complete for month after month as the project team members try to complete that task.  Be wary of “percent complete” from individuals doing task activities.  Some project team members may tell the CAM what they think the CAM wants to hear in order to avoid conflict and confrontation.   If task leaders are claiming a high percentage complete, the CAM should ask what gives them the confidence to make that assessment.  If they have a good answer, trust their assessment.  If they become evasive or can’t provide any support for their assessment, dig deeper.  In that case, the CAM may need to make their own independent assessment.

A CAM should strive to make the EV as accurate as practical.  An inaccurate EV will lead to errors in the earned value metrics of SV, CV, SPI, and CPI.  When a CAM develops a reputation for always being wrong on their EV, their credibility with Finance, the project manager and stakeholders will suffer.  If any of these believe that the CAM is intentionally providing a wrong EV (to avoid variance reports for instance), the CAM’s integrity and credibility is ruined.  This can destroy the CAM’s career.

Analyzing the Earned Value Metrics      

The CAM is the individual who prepares the variance report and often the CAM will determine which method to use for creating a project or cost account forecast which were discussed in the blog post on Forecasting.  Since the CAM created the PV at the time of project budgeting and provides the EV on a monthly basis, they are usually the most knowledgeable person about the costs and schedule of the tasks in the cost account.  The calculations for variance, performance indices and forecasts are very easy and straightforward.  Therefore the role of the CAM is not primarily one of doing math; rather it is interpreting the values and providing insight to the project manager, project team and stakeholders.  This insight should lead to improved project performance, realistic expectations, and lessons learned that can be used on the next project.  

Ten Steps for Project Estimating

Project estimating is challenging.  Since a project is a temporary endeavour, the specific project activities are often done infrequently.  The company is not able to rely upon a statistically significant set of projects to create estimating standards.  Most projects rely heavily on analogous estimates that are set by team members.  However, analogous estimates depend upon project team member’s experience which is significantly different for each person.  In this environment, estimating is difficult.  So here are ten steps for creating project estimates . 

1. Divide the project into tasks and activities.  It is easier to estimate small “bite-sized” chunks of project work than to estimate large complex activities with many moving parts.   The project leader and the core team members should start with the project goal and deliverables and create a list of tasks and activities necessary to accomplish the goal and complete the deliverables.   


2. Estimate effort first; then convert it to duration.  Estimate the amount of work in each task or activity – not the duration of the activity.  Duration estimates are far more inaccurate than the actual work estimates.  Start with effort.  These estimates will typically be created with the units of hours or days of effort.  


3. Estimate the tasks you know.  The project leader should go through the list of activities and tasks and identify those for which a reliable estimate can be created.  For those cases where standards exist or for which the project management office has a parametric estimating algorithm, the estimate is created.   


4. Estimate the tasks the project leader and core team members know.  Of the remaining tasks, the project leader and each core team member should review them to identify ones for which they can create a reliable estimate based upon their personal experience on other projects.  


5. Make “reasonable” assumptions.  Of the remaining tasks, determine which ones are dependent tasks.  By dependent task, I mean a task for which the effort estimate is highly dependent upon some factor that is not known with certainty at the beginning of the project.  For the tasks that fit that category, make a reasonable assumption about project conditions, and create an estimate based upon that assumption.  The assumption should be added to the risk register.  


6. Assume 75% condition for remaining tasks. For the remaining tasks, the project leader and project team should create a best case and worst case effort estimate for each task.  These may be wild guesses, but they form the starting point for setting the effort estimate.  At this time I average the best case and worst case estimates; then select a value at the 75% point.  These tasks should also be added to the risk register. 


7. Add “unknown” tasks.  If there are any aspects of the project for which the project leader and core team members have no experience, this will be a high risk area for both estimates and execution and should be prominent on the risk register.  Several tasks or task groups are placed into the project in these areas.  These tasks are “place-holders” to ensure that resources and time are allocated to these areas.  Check online sources or other networks to create an effort estimate for these tasks.  The values will probably be wrong, but they at least ensure that the high-risk area is recognized. 


8. Create a network diagram.  It is finally time to convert the effort estimates into duration estimates.  A network diagram or flowchart of the tasks and activities is created.  The network diagram is needed to determine sequence of activities and to identify potential parallel paths of project work that could shorten the overall project duration without reducing the duration estimate of any individual task or activity.  If there are numerous parallel paths, use the critical path analysis method to determine the longest and monitor it closely.  I often will place any tasks on the critical path that have uncertain estimates onto the risk register.   


9. Assign resources to determine duration estimate.  Assign resources based upon resource availability.  Start with the most constrained resource and assign that resource first to the tasks and activities where the resource is required.  Then work through the remaining resources from most constrained to least constrained, assigning them to tasks based upon the network diagram and resource availability.  Based upon the skill set of the resources that are actually assigned to each task, the effort estimate may need to be modified.   Once the assignments are complete, the task duration estimates and project duration estimate is easy to calculate. 


10. Calculate the cost estimate.  Use the cost rate of each resource and the assignment of the resources to the tasks to determine the cost for each task and activity.  Ensure that any other cost factors that must be applied are included.  Also, include the estimated costs of any purchased tasks or activities.   Include a management reserve cost estimate based upon the number and severity of risks on the risk register.

The Curse of the Project Manager

The curse of the project manager is: “Scope, schedule, budget – pick two.” 

Project managers often talk about the triple constraint or scope, schedule and resources/budget.  A project has goals, deliverables and activities that must be performed for it to be successful.  That is the scope constraint.  A project has a defined start and end date in which all activities must be accomplished.  That is the schedule constraint.  A project has limited amount of resources based upon the budget at its disposal.  That is the resource/budget constraint. 

A project manager and the project team create a project plan that makes the best use of the available resources within the project time constraints to complete all the activities of the project scope.  And then reality happens.  Something unexpected occurs that impacts a portion of the project requiring more work than was planned – and it must be done immediately.  Now the project manager is faced with a dilemma.

The project manager can refuse to do the work and maintain the original scope, schedule and budget.  But then the project is considered to be a failure because the delivered scope is inadequate for what is really needed.  The project manager can do the extra work and bring on extra resources to complete it within the original schedule.  But the project is considered to be a failure because it is overrun.  The project manager can do the extra work with the existing resources by delaying some of the planned tasks.  But the project is considered to be a failure because it missed the scheduled completion. 

So the project will be considered a failure.  The project manager must determine what type of failure they want to have, a scope failure, a budget failure, or a schedule failure.  They can pick two, but they will miss one – and probably miss it badly. 

Research Shows ...

This is not a hypothetical situation.  A 2014 report published by Standish Group concerning project failure rates found that for IT projects in large corporations, only 9% finished on time and on budget.  But though the project manager picked those two constraints, they missed scope.  Those projects  finished with results that had only 42% of the originally proposed features and functions.  Small companies did somewhat better.  A whopping 16% of their projects completed on time and on budget. 

Over half the time, the project managers picked scope and schedule.  But then projects were overrun and the overrun percentage was 189% of the original budget.  When projects were delayed, the average delay was 222%.  Fully 31% of the projects were so bad that they were just cancelled.

A Case Study

How do projects get into such death spirals? Let me illustrate with a project on which I had experience.  This was a large defense development project with new technology and an aggressive schedule.  During the development, unexpected problems popped up with the technology.  The project manager was adamant that the schedule and budget must be maintained, so the project team members kept going with the planned project tasks, even though everyone knew that there were unresolved technical problems.  These problems kept growing in their magnitude and impact until finally a spectacular test failure occurred (the fireball was awesome!).  By this time the project was also several months behind schedule and about 10% overrun.  The project manager was fired and I was appointed the new project manager.

When I was assigned to the project, I asked senior management what the goals were.  And their response was to find out what was wrong and fix it.  They also told me if I needed something, come back and ask for it.  Beyond that they had no specific guidance.  In my first meeting with the team, it was obvious that they were demoralized and scared.  I asked which of the three constraints, scope, schedule, or resources/budget was most important and which was the least important.  The team’s response was that everything was of the highest importance.  They had to deliver all the features and functionality, they had to do it on time, and they had to do it within budget.  When I pointed out that they were currently failing all three aspects, their comment was they just needed to try harder.  Yet I could see in their eyes that everyone felt the project was doomed (and so were they).

In this case, I didn’t even think I had an opportunity to pick two of the constraints; I had to just pick one.  Based upon the nature of this project and the overall organizational strategic goals, I picked the scope constraint.  I directed the team that we would fix the technical problems.  No matter what it cost or how long it took, we would make sure this thing worked, and worked well.  With that single-minded focus, we went to work and in a few months we had fixed the technical problems.  I then refocused the project team to recover the schedule.  We worked our critical path closely and aggressively went down the other paths.  A year later we finished the project on time with full functionality.  And we were about 25% overrun.   I picked two – scope and schedule – but missed the third.

That project was considered a success by the organization because it had recovered from a disastrous state.  The overrun was covered by senior management from a reserve fund, and the system was deployed to our military troops on-time and worked well. 

So What Constraint Is Most Important?

The correct answer is not always to overrun.  When we built the house we are living in, we had a few unexpected problems that caused extra expenses.  We did not want to go back to the bank for more money, so we choose to reduce the amount of landscaping.  In this case I picked schedule and resources/budget and descoped the project.  

As another example, I am in the process of doing an overhaul and update of my company website.  The work was started.  A new design was established and the resources identified.  But then I was pulled into a big project requiring most of my time.  I put the website update on hold.  Rather than change the scope, or switch to more expensive resources, I decided to delay the project.

Ideally projects complete on-time, on budget, with all of the requested scope.  But the Standish research shows we should be prepared for the fact that the project may not.  A project manager should work with their stakeholders to determine which two of the constraints they will meet, and which one they will miss.  Yes, project managers are cursed.  But they do get to pick which curse.

New Fed Guidelines: Many Independent Contractors on Projects are Now Employees

Companies often use independent contractors to supplement their project teams – I know I did when running projects at GE.  These individuals often provide specialized skills that are required for project activities.  The US Department of Labor issued an Administrator’s Interpretation last month (July 15, 2015) that is likely to impact many projects that rely on independent contractors.  Based upon my reading, many of these individuals will now be considered employees.

The Department of Labor has indicated that they are cracking down on the mis-classification of employees under the Fair Labor Standards Act (FSLA).  The FSLA definition of an employer-employee relationship is for the company to, “suffer or permits to work.”  A set of “economic reality factors” is used to determine if an individual is an employee under this definition of the FSLA or an independent contractor.  This recent Interpretation changes how these factors are to be considered.

The economic reality factors used by the Department of Labor and the Courts are: “(A) the extent to which the work performed is an integral part of the employer’s business; (B) the worker’s opportunity for profit or loss depending on his or her managerial skill; (C) the extent of the relative investments of the employer and the worker; (D) whether the work performed requires special skills and initiative; (E) the permanency of the relationship; and (F) the degree of control exercised or retained by the employer.”

According to the Interpretation, “The factors should not be applied as a checklist, but rather the outcome must be determined by a qualitative rather than a quantitative analysis.”  That sounds flexible, but whenever bureaucrats and courts get involved, it is likely to turn into a checklist.   Therefore, unless a person meets at least four of these factors; they will likely be considered an employee instead of an independent contractor.   Let’s examine each of the six factors from a project perspective.

Integral Part of the Business

The key to understanding this factor is that what is integral is the type of work, not the worker.  The “integral work” is work that is at the core of what the business does. So for instance, a person on the phone in a call center is doing work that is an integral part of the business, even though that individual may be one of hundreds doing the same work.  They are an employee.  Whereas, an individual who is upgrading the payroll system at the call center is not performing a task that is integral to the nature of the business.  They could be an independent contractor. That is not to say that a payroll system is not an integral part of the business, but it is not the type of work that the business performs.

The implication for projects is that if the business primarily performs project work – such as a construction firm or consulting firm – then everyone on those projects will likely be considered employees.  However, independent contractors can do work on projects that change the business systems, processes, or facilities.

Worker’s Opportunity for Profit or Loss Depends on His or Her Managerial Skill

This factor deals with the control or influence of economic risk on the part of the worker.  If the worker is negotiating contracts and prices, advertising and marketing their services, and selecting/prioritizing customers, then their managerial skill will impact profit and loss.  They are considered independent contractors.   However, if the worker is working from a standard price set by others and the only impact they have on their profit and loss is how many hours they work; they would be considered an employee.

The implication for projects is with time and material contracts.  When an individual doing project work is paid a standard rate based upon the number of hours, and the number of hours is determined by the project manager and the needs of the project; that person will likely be considered an employee.  A person who negotiates a fixed price contract for a project deliverable will likely be considered an independent contractor.  

Extent of Relative Investments

The key on this factor is the “relative” investment made by both the company and the individual.  To be considered an independent contractor, an individual may have made a significant investment in themselves or the “tools of the trade.”  This is in comparison to the investment that the company would make on behalf of the individual to do the work.  Examples of things that an independent contractor would invest in are tools, equipment, rent, insurance, and certification.  A company may subsidize one or two of these, but the preponderance must be provided by the independent contractor.

For many in-house corporate projects, this is a difficult factor to overcome.  Often the nature of the project work means that the company has made the major investment.  This is especially true if the individual works on site where they are given an office, a computer, or access to systems and equipment.  Project work that is done off-site or remotely, either at the individual’s facility or at a job site where the individual must bring in their own equipment is more likely to lead to an individual being considered an independent contractor.

Special Skills and Initiative

The key to this factor is the word, “initiative.”  Special technical skills do not automatically lead to independent contractor status (although the lack of any special skills will mean that the individual does not meet this factor).  Employees also have specialized technical skills also, in fact that is often the lead item in a job description.  This factor is based upon the individual applying their technical skills in some business initiative beyond the technical work specified by the company. 

Project work can again create problems for this factor.  Generally, individuals are hired on projects for one of two reasons.  In one instance, more “arms and legs” are needed to do some project work – in which case there are often no special skills so they are employees.  The other instance is when the project plan specifically calls out what the individual is supposed to do.  This may require special skills, but there is no initiative required so again they are employees.   To meet this factor, the independent contractor must independently manage a portion of the project and that portion must require some special skills.  

Permanency of the Relationship

This is probably the easiest factor to understand, but there are some nuances.  If an individual consistently and primarily works for just one company, even though it may be on a variety of projects, they are an employee.  The relationship is seen as a permanent one.  This can be true even if the work is part-time or seasonal in nature.  If an individual consistently works for only one employer, it is viewed as a permanent relationship, not an indefinite relationship.  An independent contractor will have multiple customers/clients.

The problem for projects is if the same individual is used again and again by a company on multiple projects.  That individual must have other clients and they must do a significant amount of work with them to be considered an individual contractor.

Degree of Control Exercised by Employer

This used to be an easy factor to analyse.  If the person was on-site the degree of control was high and if off-site it was low.  However, with the technology available today, the location of the worker is of minimal importance.  What is crucial in this factor is the assignment of tasks, the setting of schedules, and oversight on the quality of the work performance.  If the company manages those, the individual is an employee; if the individual manages those, they are likely an independent contractor.

The concern for projects is based upon the nature of project work.  The project plan often specifies what must be done, when it must be done, and even how it must be done.  So even though the individual is working from home, if they are working on a highly specified project activity, they will likely be considered employees.  Independent contractors would be given an end date and deliverable and they would then determine how they would perform the work to meet these goals.

As you can tell from this assessment, many “independent contractors” working on projects will now be considered employees.  This has significant financial implications for the business.  Not the least of which is that small companies may suddenly find that they have over 50 employees and now fall within the Obamacare provisions.  PMOs and project managers need to review these with their HR department and establish their new guidelines for use of independent contractors on projects.

This blog is not legal advice.  It is a personal assessment about the application of the DOL Administrator’s Interpretation.  You should consult with a lawyer about individual actions or grievances.

Projects: The Financial System Relief Valve

Your project is going well.  You are mostly on schedule and on budget.  There have been a few minor problems, but your risk plan anticipated them, so you were able to quickly react and recover.  This project is headed for success.  Then the edict comes down.

“No travel between now and the end of the fiscal year.  Delay deliveries of all equipment and supplies until next fiscal year.  Exceptions must be approved by the CFO.”

What are they thinking! You have a major review at a vendor scheduled for next week! If you postpone that, it will set your project back at least a month!!  And your major supplier on the critical path is scheduled to ship in two weeks!!  This will cause havoc with the schedule!!!  It will create extra costs for delays and expedites!!! THOSE IDIOTS!!!!

Stop, take a deep breath. Don’t take this personally. (Unless you backed into the CFO’s car in the parking lot last week – then it might be personal.) In all likelihood the business is doing some “financial engineering” as it prepares to close out the fiscal year.

Transaction: Amount and Timing

Every financial transaction in business has two equally important attributes – the amount and the timing.  The date of the transaction is as important as the amount when it comes to preparing financial reports.

Financial reports are either for a period of time, such as the Earnings Statement which is for a quarter or fiscal year; or for an instant in time, such as the Balance Sheet which is for a specific date.  When the transaction occurs will determine which report the transaction is recorded in. 

It is often much easier change the date of a transaction than it is to change the amount of the transaction.  I have often been asked to delay expenses near the end of a quarter or year.  I have also been asked at times to accelerate expenses into the quarter or year.  In both cases, we are managing the date of the transaction, not the amount of the transaction.

One other point about timing.  The date for a transaction can be set either using the cash basis or accrual basis.  The cash basis sets the date when the money changes hands.  The accrual basis sets the date when the responsibility for what the transaction represents is transferred – such as the product is shipped or the material is received.  Most businesses use the accrual basis.  That way, if cash payments are hung up for some reason, the sales and costs are still recorded and a true reflection of the business activity will be shown in the report.  The differences between the cash and accrual basis can be reconciled by analyzing the Cash Flow Statement.

Projects: The Financial System Relief Valve

Senior management must often forecast what they think will be the profit for the upcoming quarter or year.  If the actual amount is significantly different, the owners and investors begin to worry that management doesn’t know what is happening.  Therefore, senior management carefully considers the forecast they provide and they attempt to manage the business so as to meet the forecast.

But life happens.  Inevitably something occurs to cause the numbers to be different than expected.  There is an unexpected economic downturn.  Competition surprises the market with a new product.  The cost of raw material is higher, or lower, than expected.  

Let’s look at the major elements of the Earnings Statement, which shows the profit earned during a time period.  We want to see what can be done to influence profit as we approach the end of the fiscal year.  We will assume that Finance has done a preliminary analysis and determined that the company may miss its profit forecast and is trying to find a way to increase profit.  Our timing is set using the accrual basis.

• Revenue: This is sales in the marketplace.  A company can increase sales near the year end through a promotion. But that may take time to set up and often results in less profit because of the cost of the promotion or discount. So that doesn’t help to increase profit in the short term.
• COGS: The Cost of Goods Sold is the variable cost associated with the product.  It is the raw material and labor required to make product, or deliver the service.  There are two things that contribute to this cost, volume and design.  With respect to volume, if we sell more we must make more, if we sell less, we don’t need to make as many.  However, in the short term, we must follow the sales orders.  With respect to design, we could redesign for lower material costs or less labor, but that will take time to do the redesign, and if we are one month away from the end of the fiscal year, there is little that can be changed.  So this doesn’t help us increase profit in the short term either.
• Fixed and Overhead Cost:  When we consider the operating expenses of the business, we find that they behave in several ways. One is as fixed and overhead costs.  These are costs that are required to run or sustain the business.  They will not change based upon the day-to-day business activity.  For instance items like rent, insurance, debt payments, or business license are typically based upon contracts or regulations.  And business overhead functions such as the HR department, the IT department, the mail room, or the security guard are required to be at work whenever we open the doors.  These can only be changed through business restructuring, which again cannot be done in the short term.
• Project and Program Cost: Which brings us to the last category, projects and programs.  These are the expenses required to complete project and programs.  These are normally scheduled based upon the project schedule, not the fiscal calendar.  The fiscal calendar is something that management can’t change.  However, a project schedule can be changed with a phone call from the project sponsor to the project manager.  These are the only costs that can be changed in the short term.

So when Finance determines that the company needs more profit to meet its forecast, it is projects that get the call to stop spending.  Projects are the financial relief valve for the business as it nears the end of a fiscal quarter or year.  And if the year is going better than expected, the projects may be asked to accelerate spending.  Yes it impacts the project schedule, but the project is sacrificed for the greater good of the business.

De-mystifying Earned Value – Forecasts

In many cases, tell a project manager they must use earned value analysis on a project and you will hear a groan.  Earned Value Management has been tainted with an aura of overwhelming bureaucracy and incomprehensible numbers and ratios.  While some organizations may have done their best to confuse and confound project managers and project teams with Earned Value Management – it is really a very basic and easy to use set of project analytics.  This blog post will explain the earned value project forecasting analysis and other blog posts will discuss project baselines, variance analysis, and cost account managers.  Or get everything in one ebook that can be ordered below..

Earned Value Management

Earned value management is an analytical approach for determining the current cost and schedule status of a project and for forecasting the final cost of a project.  It combines scope, schedule and resource management into one set of measurements.  When used properly it will simplify and reduce the effort needed to provide effective project management control.

Earned Value Management is based upon the comparison of three different perspectives on a project.  The first perspective is the project planned value (PV) which is the estimated cost of each activity time phased according to the project schedule.  The next baseline is the earned value (EV) which is the estimated cost of the project activities that have been completed.  The final baseline is the actual cost (AC) which is the amount of money spent completing the work that has been done on the project.  These baselines are discussed in more detail in the blog post, “Demystifying Earned Value – theBaselines."

Forecasts

On the one had we could say the original baseline project plan is a forecast.  However, in project management terms, forecasting is normally providing an updated estimate from the original plan.  I recommend that this be done at the beginning of each phase.  It may also be done following a major high risk milestone.  I recommend starting the forecasting when the project is 20% complete.  By that time several significant items should be completed on the project and enough work is done so that a small underrun or overrun is not magnified out of proportion.  Prior to that time, the baseline plan is the forecast.

Throughout the lifecycle of the project, the project manager is often asked to provide a forecast for the final cost of the project which is referred to as the Estimate at Completion (EAC).   As the project gets underway, real costs occur and now actual costs can be used instead of budget estimates for the completed tasks.  The EAC is then the sum of the Actual Costs (AC) plus an estimate of what the costs will be to complete the remainder of the project.  This estimate for the remaining work is the Estimate to Completion (ETC).  This can be expressed with this formula:

EAC = AC + ETC 

The key then to effective forecasting is to be able to calculate a realistic ETC (since AC is already occurred and cannot be affected).

Forecasting Indices with Earned Value

To assist the project manager in the calculation of ETC, the Earned Value Management methodology creates several performance indices.  These indices consider what has happened on the project since its start.  There are two indices, a Cost Performance Index (CPI) and Schedule Performance Index (SPI).  

The CPI is a ratio of the earned value (EV) divided by the actual costs (AC).   Since the EV is the estimated cost of the work completed and the AC is the actual cost, the CPI is a ratio of underrun or overrun for the work completed.  The index can be calculated for the entire project or for a subset of tasks, such as all of Phase 3, or all the tasks performed by the IT organization.  

CPI = EV / AC

The SPI is a ratio of earned value (EV) divided by the planned value (PV).   Since the EV is the estimate for the work completed and the PV is the estimate for the work that was planned to have been completed, it is a ratio of ahead or behind schedule.  Again the index can be calculated for the entire project or a subset of the project tasks.

SPI = EV / PV

Earned Value Forecasting Methods

There are four methods for forecasting the ETC:  

• The first method is to create a new estimate.  In this case, the project manager and core team create a new estimate for all uncompleted work.  This often done if there is a major scope change to the project.  I also will use this approach when near the very end of the project because I normally have an excellent understanding of what is left to be done.  The formula for the project estimate is: EAC = AC + (new estimate for remaining work).


• The second method is to stick with the original estimate. In this case the ETC is the originally budgeted estimate for the remaining work. This is a good approach to use when any underruns or overruns that have occurred were due to unique or isolated events and are not likely to be repeated on the project. This is calculated as the Budget at Completion (BAC) which was the total for the planned value and therefore the original estimate of all work, minus the EV (original estimate of the work that has completed). The formula for the estimate of the remaining work is:  ETC = (BAC – EV).  The formula for the total project estimate is then:  EAC = AC + (BAC – EV).


• The third estimating method is used when established trends on the project will continue. This method requires the use of the CPI performance index. It assumes that any pattern of cost overruns or underruns that has been occurring on the project will continue to occur at the same rate. It can be applied to just a subset of tasks, or the entire project. The estimate created in this method will take the originally estimated value of the remaining work (BAC – EV) and divide that by the CPI. This has the effect of increasing or decreasing that value of the remaining work by the same ratio that it has been increasing or decreasing. The formula for the remaining work is: ETC = (BAC – EV) / CPI. The formula for the total project estimate is then: EAC = AC + (BAC – EV) / CPI.


• The fourth method is used with projects that are behind schedule and must be accelerated. It requires both of the earned value performance indices, CPI and SPI. This method assumes that the underrun or overrun pattern will continue and that an effort will be made to finish the project on the original date, so increased costs will occur to accelerate the remaining work. To create the acceleration effect, the estimated cost of the remaining work (BAC – EV) must be divided by the SPI. The ETC in this case then must include an effect for both cost and schedule. The estimate for the remaining work is: ETC = (BAC – EV) / (SPI * CPI). The estimate for the total project becomes: EAC = AC + (BAC – EV) / (SPI * CPI).

Which method you use will depend upon the project conditions. However, in each case the math is straightforward if you have the earned value metrics.  If you want to learn more about earned value, order my ebook below.

De-mystifying Earned Value – Variance

In many cases, tell a project manager they must use earned value analysis on a project and you will hear a groan.  Earned Value Management has been tainted with an aura of overwhelming bureaucracy and incomprehensible numbers and ratios.  While some organizations may have done their best to confuse and confound project managers and project teams with Earned Value Management – it is really a very basic and easy to use set of project analytics.  This blog post will explain the earned value variance analysis and other blog posts will discuss project baselines, project forecasting, and the role of the cost Account Manager.  Or get everything together in the ebook found at the end of this post.

Earned Value Management

Earned value management is an analytical approach for determining the current cost and schedule status of a project and for forecasting the final cost of a project.  It combines scope, schedule and resource management into one set of measurements.  When used properly it will simplify and reduce the effort needed to provide effective project management control.

Earned Value Management is based upon the comparison of three different perspectives on a project.  The first perspective is the project planned value (PV) which is the estimated cost of each activity time phased according to the project schedule.  The next baseline is the earned value (EV) which is the estimated cost of the project activities that have been completed.  The final baseline is the actual cost (AC) which is the amount of money spent completing the work that has been done on the project.  These baselines are discussed in more detail in the blog post, “Demystifying Earned Value – the Baselines.”

Variance

Projects hardly ever go exactly according to plan (at least I have never had one that went exactly to plan).  Some things go better than expected, some go worse. Some tasks start early, some late, and some are just different. Variance occurs when the actual situation is different from the planned or expected situation.  In projects, variance analysis applies to schedule variance and cost variance.   Variance analysis helps the project team understand why things are different than expected, and more importantly, what they should do about it, if anything.

Variance is always backward looking.  It analyses what has happened.  (We will cover forecasting in another blog.) We typically are concerned with two different time horizons when determining project variance.  One is the variance since the start of the project, known as cumulative variance.  This variance will be focused on trends.  The second is the variance in the current month or week.  This is focused on recent occurrences.  Most earned value reports will show both variances.

Cost Variance

Cost variance is the under-run or over-run of actual costs (AC) as compared to the estimated project costs of the work that has been completed (EV).  When evaluating project cost variance, it is important to exclude the effect of tasks that are ahead or behind schedule, which is why EV is used instead of PV.  The PV has embedded schedule assumptions for which tasks will occur in which months.  If a task is not worked on during a month because of a schedule delay, that could appear to be an under-run to the project for that month if we use PV.  However, if the task is accomplished the following month, it would appear to be an over-run for that month since the cost occurred in that month without any planned cost for that task occurring in that month.  The Earned Value Management approach allows us to eliminate the schedule impact on cost variance by using EV for the baseline cost instead of PV.  The EV represents the planned or budgeted cost for the work that has actually been performed.  The AC is the total costs associated with doing that work. 

Cost variance that is calculated using EV and AC from the beginning of the project is the cumulative variance.  It is an excellent indication of trends and helps to predict what will likely continue on the project unless changes are made.  However, the amount of the cumulative cost variance – either under-run or over-run – is typically unchangeable.  Most of those tasks are completed and the variance cannot be impacted.  The current period cost variance analysis will provide insight as to whether the tasks that are currently underway are over-running or under-running.  These are indications of immediate risks and opportunities that the project manager should investigate.  

The cost variance is calculated as the difference between EV and AC.  A positive cost variance is an under-run and a negative cost variance is an over-run.

Cost Variance = EV – AC

Current period cost variance uses the EV and AC for the current month.  Cumulative cost variance uses the EV and AC since the project has started.

Schedule Variance

Schedule variance is the ahead of schedule or behind schedule position of the project as compared to the schedule found in the project plan (PV).  Normally project managers present schedule variance in terms of time (days or weeks) ahead of or behind schedule.  However, since all earned value analysis baselines are expressed using money; the schedule variance in earned value analysis is also denominated in money.  (Hey – time is money, right?)  

The earned value analysis schedule variance is the estimated cost of the work that has not been done according to the project schedule plan.  For work that is accomplished earlier than scheduled, this would be a positive value representing the estimate of the work accomplished early.  For work that was late this is a negative value representing the estimated cost of the work that was not done when scheduled.  The schedule variance is then the difference between the EV, which is the estimated or budgeted cost of the work that has been performed and the PV which is estimated or budgeted cost of the work that should have been performed according to the project plan.

The primary concern for a project manager is negative schedule variance.  This is cost that will need to occur at some time on the project when those project activities finally occur.  This becomes important near the end of a fiscal year when the business is trying to plan the costs that will occur in both the current year and the following year.  Keep your finance people informed if you have large earned value schedule variances.

Schedule Variance = EV – PV

Just as with cost variance, this can be calculated both for the current month and for the entire project since its start.

Variance analysis is easily calculated using earned value management and the three earned value baselines.  Forecasting using earned value will be discussed in another blog.  If you would like to find out more about earned value management, order this ebook.

De-mystifying Earned Value – the Baselines

In many cases, tell a project manager they must use earned value analysis on a project and you will hear a groan.  Earned Value Management has been tainted with an aura of overwhelming bureaucracy and incomprehensible numbers and ratios.  While some organizations may have done their best to confuse and confound project managers and project teams with Earned Value Management – it is really a very basic and easy to use set of project analytics.  This blog post will explain the earned value baselines and future blog posts will discuss variance analysis, project forecasting, and the role of the cost account manager.  Or you can get everything in one document by ordering the ebook at the end of this post.

Earned Value Management

Earned value management is an analytical approach for determining the current cost and schedule status of a project and for forecasting the final cost of a project.  It combines scope, schedule and resource management into one set of measurements.  When used properly it will simplify and reduce the effort needed to provide effective project management control.

Earned Value Management is based upon the comparison of three different perspectives on a project.  The first perspective is the project plan – to include which tasks will be completed on which dates and how much they are estimated to cost.   Earned Value Management calls this the Planned Value (PV).  The second perspective is the current project schedule achievement – which is an assessment of which tasks are started; which tasks are completed; and the level of progress for those that are underway. Earned Value Management calls this the Earned Value (EV).  The third perspective is the current project spending – which is how much money has been spent on the project since it started.  Earned Value Management calls this the Actual Cost (AC).  The project manager should be managing all three of those perspectives regardless of whether Earned Value Management is being used.  

Earned Value Planning – Setting the PV

The PV is created using the Work Breakdown Structure (WBS), the project schedule, and the task estimates.  Every task in the WBS is assigned a separate account number in the financial system.  The cost estimate for every WBS task is then spread over the time periods (normally months) associated with the project schedule for that WBS task.  Those cost amounts are placed in the WBS account for the appropriate periods to create a time-phased task-level budget estimate.  This is the task PV.  Once all of the task PVs are complete, they can be summed into a project PV.

When spreading the task estimate across multiple time periods, one of two techniques is used.  The cost can be “level loaded.”  This means the costs are spread evenly across the time periods in which the task is scheduled to be accomplished.  The other approach to spreading the cost is “event loaded.”  In this case, the WBS task is planned at a micro-level (daily or weekly) and the cost associated with the work for each micro-time period is assigned to that period and then summed to the time periods used in the financial system (normally monthly). 

PV is expressed either as “Current PV” which is the PV that is planned for a particular month, or “Cumulative PV” which is the PV from the beginning of the project to the point in time under consideration (normally the current date). The final value of PV – that is the total PV for the project – is the Budget at Completion (BAC).

Setting Earned Value (EV)

Earned Value (EV) is a judgement call by the project manager and the project team concerning how much of a task has been completed.  The total possible earned value for a task is based upon the original budget estimate for that task, which is the task Planned Value (PV).  The percentage of a task that is completed is the percentage of value that has been “earned.”  If a task is 50% complete, the task has “earned” 50% of the planned value – regardless of the cost required to get to that point.  Before a task is started, its EV is 0 since none of the planned value has been earned yet.  When a task is complete, it has “earned” all of the value for that task, so the EV = PV.  EV for a task can never exceed the PV for a task, regardless of how much has been spent.  Nor can EV ever be negative.

A risk with earned value is that someone will claim that much of the value for a task has been earned, when in reality very little progress has been made.   To avoid this problem, many organizations adopt rules or practices for how earned value is to be credited.  This list is the most commonly used ones in my experience

• Earned value amount is based upon the number of micro-tasks associated with a task that have been completed.  This requires detailed task planning at the micro-activity level.  This will be the most accurate, but it also takes the most work.  I normally use this approach for tasks that take longer than 2 months to complete.
• 0-100: The earned value amount is zero until the task is complete, then the EV is 100%.of the PV.  This is easy to use and focuses team members on getting things done.  However, they are likely to start and do the easy tasks first and save the long and hard tasks for last.  It is best used with tasks of one week or less duration.
• 30-70:  The earned value is set at 30% of the PV when the task starts and the additional 70% is credited when the task is completed.  This approach is easy to calculate.  It is not quite so harsh as the 0-100 approaches.  I normally use this for tasks that are longer than a week in duration but less than 2 months.

Determining Actual Cost (AC)

The AC element of Earned Value Management is the easiest for the project manager.  The business financial system collects costs.  As long as the project earned value cost accounts are created when the project PV baseline is set and the financial system can record costs by those account numbers, the AC will be automatically collected from the finance system.

With these three project perspectives, PV, EV, and AC, the project manager can determine the underlying causes of cost and schedule variances and forecast project completion.  These topics will be discussed in future blog posts.  If you would like to find out even more about earned value management, purchase this ebook.