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.

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.

Project Management Software: Help or Hindrance?

I was recently checking out a project management software package and looked at reviews to see how this application compared to others.  What I found was that on the day that I checked, there were 460 software applications that were advertising themselves as project management software.  That is a lot of choices!

It brought me back to a question that I have often been asked, “Do we need project management software?”  I have come to the conclusion that for most projects and project teams the answer is, “No.” 

The Purpose of Project Management Software

Let’s step back and consider the purpose of project management software.  The software is to assist the project manager and project team with planning and tracking of project progress.  If it doesn’t provide timely and accurate information, it is not meeting its purpose.

When project management software is being used correctly it is great.  It is a consolidate repository of project information.  Depending upon the software application, it can analyse the project plan from a cost or schedule perspective.  It often can be used to do “what if” sensitivity studies of various project scenarios and options.  It will generate reports and analysis on a variety of important project attributes.  It can be emailed or shared with team members anywhere around the world and instantaneously updated to show current status.  Good grief, what’s not to like?

Well, all of this capability comes with a burden on the project team.  They must actually use the software for it to do any of those things.  And that is the problem.  Despite the claims of the software developers and their marketing organizations, most of these applications are not so intuitive that you can just immediately start using it with no training or orientation.  And the more powerful the software, the more training it takes to know how to use it well.

The Burden of Project Management Software

That is where the problem comes in.  The software must be used by everyone on the project.  Team members must use the features correctly and they must be disciplined enough to use it continuously for the information in the software to be complete and accurate.  If the team members do not keep the information current, or worse yet, don’t even initialize a project plan with an accurate representation of all the activities, the information coming out of the software will be worthless.  In fact, making decisions based upon what is in the software will often create project problems that would not have otherwise existed.

So why doesn’t the project manager mandate that everyone use the software?  The characteristics of a project and project team make that a virtually impossible task.  A project is a temporary endeavour.  Many project team members are not permanently assigned to a project team; rather they are working part-time on the project with responsibilities in other areas.  Even if they go to the training program for the project management software, they will only use the software with a portion of their day-to-day work and only for a short time.  Within a few months they have probably forgotten almost all of the training.  So when assigned to another project, it is back through training again.  This takes time and money.

In addition, for most team members, maintaining the project information in the software is not seen as being value-added effort.  As far as they can see, it is only used to make pretty charts for management.  The time they spend keeping the information in the software current is time they do not have available to do the actual project work.

The bottom line for many team members is that working with the software is difficult, awkward, unfamiliar and a waste of time.   And it only takes one team member that does not keep the information accurate and current to destroy the validity of the entire project plan and status.

How to Use Project Management Software

So what is the answer?  I believe that there are actually two answers; based upon the characteristics of the project. 

On large complex projects, the project management software is an absolute necessity.  I managed large complex defense projects thirty years ago.  Back then I needed a project management team of five to eight individuals just to keep track of what was happening, maintaining the budgets, tracking the schedules, doing risk analysis, and preparing project status reports.  Today, all of that could be done in the software.

This is a tremendous savings in effort and improvement in accuracy.  And the benefits grow with the project complexity. The key is that all the project information is accurately entered and maintained in the software.  Therefore, I recommend that on large complex projects, the project manager, and maybe one or two others on the core team, should be trained and competent users of the software.  But don’t annoy and irritate the rest of the team.  Many project management software programs have excellent import functions to bring information into the project file.  Give your project team simple forms or templates and have them use those.  Then import the information.  The project file will be much more accurate.  Yes, it is a little more work for the project manager, but accuracy and completeness is well worth the extra effort.

For small simple projects, don’t waste everyone’s time trying to get things into project management software.   Otherwise you soon find that maintaining the software is a bigger project than the actual project work.  Run your projects with post-it notes on a whiteboard (similar to an Agile Scrum Board) or with a simple spread sheet being used as a repository of project information. A project manager on a small project is free to use a software application.  But don’t burden the rest of the team with it.  They have lots of other work and learning a new software application is low on their priority list.   

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.

Is It Time To Dump The Gantt Chart?

The most common project scheduling format is the Gantt Chart format.  It is easy to understand.  It is great for visualizing a project plan.  It clearly communicates what activities the project team should be working on each day of the project.  So what is the problem?  There are several.  The Gantt Chart relies on two demonstrably false assumptions with respect to development projects.  Added to that, once a Gantt Chart is in place, it often creates an environment of frustration, obfuscation, and team dysfunction.

Actually the correct title is the Bar Chart.  This chart is in the form of a calendar across the horizontal axis.  The project tasks are placed on the calendar with each task represented by a bar that begins on the task start date and ends on the task completion date.  The length of the bar then represents the length of the task.

Henry Gantt’s Chart

The chart became popular following the publication of a book, “Organizing for Work,” by Henry Gantt in 1919.  Gantt had worked for Fredrick Taylor before becoming an independent consultant and was an advocate of Taylor’s scientific management principles.  The Gantt Chart was developed for use in a manufacturing setting as a means to communicate to the factory supervisor what they should have the men working on next.

This leads to the inappropriate assumptions for a typical project application of the Gantt Chart.  The first assumption is that every activity that is in the project is identified and included on the chart.  This is a valid assumption for a manufacturing environment with defined process steps, well-defined tools and equipment, and the experience of having already done the activity numerous times.  The second assumption in the Gantt Chart is that the estimate for each activity is precisely accurate with little or no uncertainty.  Again, this was a valid assumption for a manufacturing operation that had embraced Taylor’s scientific management philosophy.  An operations manager would be measuring everything, collecting data, and monitoring performance.

Assumption #1: Every Task Is On The Gantt Chart

The assumption that every project task is on the Gantt Chart is invalid for most development projects.  Whether it is product development, system development, software development, or process development, the development environment is a discovery environment.  While experienced stakeholders and team members can forecast the likely chain of events there will inevitably be some activities that are discovered along the way.  These will not be in the Gantt Chart.

Further, a best practice touted by Cooperand Edgett is to use spiral development.  I have used the approach and I love it.  But it cannot be accurately represented on a Gantt Chart.  First, we don’t know how many spirals it will take to get the desired performance.  Even if we do guess right on the number of spirals, the activities in each spiral will change based upon the results of the test and analysis done on the previous spiral.  So the project management has two options.  He or she can guess what activities might be required in each spiral and probably guess some right and some wrong.  Or they just show the spiral with high level summary tasks that provide no useful information on what the team should actually be doing.

Assumption #2: Every Estimate Is Precisely Accurate

The second demonstrably false assumption is that every task duration estimate is precisely accurate.  The task will start precisely on the designated day and end precisely on the designated day.  This assumption is probably valid for some project tasks, but it is definitely not valid for many of the development tasks which have uncertainty embedded in them.  There is uncertainty with respect to the performance of the new technology.  Often there is uncertainty in the duration of the task because of the experience of new team members.  They must learn while doing, which depending upon their learning capacity and the level of instruction available to them, create more uncertainty in task duration. 

Add to this that many of the tasks are linked together either through task completion artifacts or project personnel availability.  As one task is delayed, it creates delays in other tasks and the impact can snowball through the project resulting in a Gantt Chart that is totally inaccurate.

Environment of Frustration, Denial, and Team Dysfunction

The impact of the two invalid assumptions is that a development project  Gantt Chart quickly becomes wrong.   The project manager may try to correct the chart but before he or she is able to incorporate the revisions and update the rest of the project management information, the Gantt Chart has changed again.  Eventually the project manager becomes so frustrated trying to keep it current that they just stop processing the day –to-day changes and wait to do a massive update at a major milestone or gate review.

But this now leads to a problem for team communication and progress reporting.  The team is tracking progress on a Gantt Chart that everyone knows is wrong.  Some of the team members will use the erroneous Gantt Chart as an excuse to ignore or avoid all project management activities and reports.  Others will try to twist what they are actually doing into the context of the erroneous Gantt Chart.  This leads to confusion and obfuscation of what is actually happening.

Finally the team ends up in a situation where the project manager is asking for status against a plan that the whole team knows is wrong.  This undermines the project manager’s credibility with the team.  Some team members refuse to even participate in a schedule status meeting.  They are now viewed as not being team players.  Others are twisting what they are doing into something to fit the erroneous Gantt Chart, but everyone knows that what they are reporting is not what they are doing.  Soon the other team members begin to suspect they may be lying about other aspects of the project.  By this time the team is totally dysfunctional.

The Alternative

So what should we do?  I recommend either switching to Milestone Charts and Network Diagrams or PERT Charts for large system development projects or using a Kanban chart with Milestone Reliease planning for smaller projects.   Milestone Charts can be used for tracking against calendar dates.  The Network Diagram or PERT Chart can be used for tracking activity sequence and monitoring  progress.  Kanban simplifies the project planning and tracking tasks for projects with low project management complexity. 

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.

Project Dashboards

Thanks to the growth of Business Intelligence, dashboards are proliferating in companies today.  Dashboards are providing real-time, or near real-time, information to managers and supervisors on virtually every business process and every product offering.  The use of dashboards by project managers is becoming common, yet there is not a corresponding improvement in project management and execution.

So why are dashboards often ineffective as a project management tool?  Is there too much information, not enough information, or the wrong information?  Do project managers lack the skills to read and understand what the dashboard is telling them, or do they lack the confidence that they can trust what the dashboard says?  Are dashboards an appropriate tool for managing projects?

To answer these questions we need to understand what a dashboard can do well and what it cannot do well.  Then we can consider how to best use it in the project environment.  Finally, we need to determine how to prepare and equip our project managers to use a dashboard.

Dashboards

A business dashboard is an information management tool used to track key business metrics and other data relevant to managing a business unit, department or process.  Often dashboard use data visualization tools to display the metrics in charts and graphs and allow drill down to underlying detail data elements. 

The dashboard metaphor is very applicable.  The driver of a vehicle does not drive by looking solely at their dashboard; rather they are watching the road and frequently glancing at the dashboard to determine if everything is operating as expected.  If the dashboard shows they are going to fast or slow they change their speed.  If it shows that they are low on fuel, they stop for a fill-up.  If the warning lights are on or a gauge is in the “red zone” it indicates a problem and they begin to take preventive and corrective action to restore the vehicle to a proper operating condition.  The same is true with business dashboards only instead of a vehicle it is a business unit, department or process. 

Think about your dashboard for a moment.  It requires real-time information to be helpful.  Showing the speed that we were traveling yesterday is meaningless.  Showing the fuel level of the vehicle from a month ago is useless information.  Likewise, the dashboard must provide information about key performance indicators to be helpful.  For instance, providing the temperature reading of the outside air temperature does not tell me if the engine is running hot.  Measuring the acceleration time from 0 to 60 mph may give you bragging rights at the drag strip, but that measure is irrelevant if I am driving across town to visit relatives.  So instead my dashboard shows fuel consumption and if I entered the address in the GPS, it shows time and mileage to my destination which are far more practical.

Project Dashboards

So what is the implication for project management?  First, the project dashboard must have real-time information.  That means we can’t wait for a weekly or monthly team meeting to update the dashboard.  Don’t get me wrong.  Those meetings can be very useful team integration and team decision-making.  But waiting for a week or a month to find there is a problem with the activities on the critical path is unacceptable.  This means that either the project team must gather at least daily to update status or there must be some other system measurement that is collected frequently and can be used to track project performance. 

Agile/Scrum projects use the first approach.  They gather every day, sometimes more often, for a scrum meeting to update their Scrum Board and Burndown Chart – which are two dashboard views for an Agile/Scrum project.  Some collaborative project management software attempts to provide real-time information through daily status reporting of project tasks by all project team members.  

When properly implemented both of these systems can work well.  However, not every project is suited to Agile/Scrum (see Blog post “Choosing the Best Project Management Methodology”).  For the other approach, setting up the baseline project plan in the project management software can be very time consuming and frequent changes are almost impossible to maintain.  Not to mention, now all the project team must be trained and disciplined to provide status on project tasks.

So what is the answer?  Forget about project dashboards?  Add people to the project team that spend all their time creating and maintain dashboard data?  How about create a pretty chart with random data we can easily measure, give it to the PMO and hope they leave us alone?  Of course none of these are palatable.  Instead, we must find a way to simplify the dashboard so it can be easily created and maintained, but still have useful information.    

Project Dashboard Metrics

Where do we start, start with the risk register.  Think about your automobile dashboard again.  If your vehicle was built during the last 30 years, it has tons of sensors embedded in it.  All of that information does not get displayed on the dashboard, only information useful to the driver while driving.  In particular, information that tells the driver if there is a problem.  So your project dashboard should provide meaningful real-time information about project risks.  Now there may not be a direct measure of risks, but often there is an indirect measure or leading indicator of a risk.

Let’s say you have resource availability as a major risk on your project.  Track the number of hours spent on project tasks by all project team members each day.  You don’t need a breakdown by task and by minute where they spent their time; just determine if they were available.  Or let’s say that a major risk is the late delivery of an item from a vendor.  Request weekly status reports until within one month, then daily status reports of the vendor’s schedule progress.  You don’t need a full vendor audit each time, just a schedule update (which you should periodically validate).  This provides an early warning of a potential delay and gives you a chance to take corrective or preventive action. 

Conclusion

The point is to determine the simplest way to get real-time data about the risk condition and place that on your dashboard.  This doesn’t overwhelm the project team with unnecessary reporting about low risk, routine activities.  Yet it provides valuable insight about the things that the project manager should be most focused upon.  Remember you are not driving the vehicle by only watching the dashboard; rather you use the dashboard to confirm that all is running well or to take corrective and preventive action.