Earned Value Management (EVM) is the cornerstone of cost and schedule management for a project. It is used to determine how much value has been put into a project. This helps the project manager to report the progress of the project related to cost and schedule, so that adjustments can be made as needed to keep the project on track.

In order to understand earned value, think about the concept of debits and credits. For every debit to one account, there is a corresponding credit to another account. Earned value is similar to that if you spend one dollar on labor the project is “earning” a dollar’s value back into the project. Writing code, training users, writing documentation and any work you perform on the project, earn value back into the project.

Although there are many key formulas associated with EVM, I will only go through some of the more important ones.

For a project with a total budget cost of $100,000, I will go over the different values and formulas used in EVM.

Earned Value – EV

How much work was actually completed during a given period of time? This value is derived by measuring where you are in terms of work completed during the given period of time in the schedule.

Let’s say that you have delivered 25% of the project. In this case EV = 25% of $100,000 = $25,000.

Planned Value – PV

How much work should have been completed at a point in time based on the plan? This value is derived by measuring where you had planned to be in terms of work completed at a point in the schedule.

Let’s say that you planned to be 30% done resulting in a PV = $30,000.

Actual Cost – AC

This is the money spent during a given period of time (billed hours). In our example let’s say that the actual cost is $20,000.

Schedule Performance Index – SPI

SPI is the rate at which the project is meeting schedule expectations up to a point in time. In our example SPI = EV / PV = $25,000 / $30,000 = 0.83. This means that our project schedule is progressing 83% of the pace we expected, which is bad. Any number larger than 1 is desirable. Numbers less than 1 means we are behind schedule.

Cost Performance Index – CPI

CPI is the rate at which the project is meeting cost expectations up to a point in time. It’s an indicator as to how much we are getting for every dollar we spend. In our example CPI = EV / AC = $25,000 / $20,000 = 1.25 which means that we get $1.25 worth of performance for every $1.00 we expected, which is good. A CPI of 1 means that we are exactly on budget while a value of 1 or more is good, and value less than 1 is undesirable.

So for the example above, we are behind schedule since we only are progressing 83% of the pace we expected. However, we are doing fine on cost. We are getting $1.25 worth of performance for every dollar we expected.

So what can we use all these numbers for? Well, the project manager can now make the necessary adjustments to bring the schedule back on track at a point when the project is only 30% done according the plan. That’s much better than finding this out when the project is 100% done and we are late, right?

In our example the project manager can allocate more resources to the project to catch up to the schedule. That might end up costing more for a few weeks but there is room in the budget for this since we are under budget for now.

EVM is performed continuously throughout the entire project lifecycle and helps the project manager to keep the time and cost on track. It is also used in project performance reporting. Changes to the performance indexes can give early warnings allowing the project manager to make the changes needed to get the project back on track.

EVM includes many other formulas and indexes that are used during a project that I didn’t cover in this article, but I tried to cover the most important ones. If you like to know more about EVM, additional information can be found in this article on Wikipedia.

Quality Management is an important knowledge area and is concerned with “the degree to which a set of inherent characteristics fulfill requirements”. What does this mean? It means that based on the specified requirements we need to determine how well the solution fulfills these requirements.

When you are manufacturing widgets, it might be easy to set some quality standards for measurement, like diameter must have a tolerance of +-1 mm but how do you measure the quality of the deliverable of an IT project? That’s what I will try to explain in this article.

First let’s take a look at the project processes associated with the Quality Management Knowledge area.

There are three processes during a project that are concerned with quality. As with all knowledge areas, there is a planning process. Here we plan how the two remaining quality processes- quality control and quality assurance- are executed.

The most well-known quality process is to perform quality control. This is where we check if the deliverables are conforming to the quality that we expected. In IT projects where the deliverable is a software program; we have to check that each part of the total software solution is performing as expected. So how exactly can we do that? Testing, testing, testing!

In order to control the quality of a software program we have to build test cases. A test case is a procedural checklist that goes through a scenario inside the software. Let’s say we have built functionality of approval during an invoicing process. We now need to make sure that the software allows the approvals to happen correctly and does not allow invoicing until the approvals are done. We build a checklist with steps that a test person should go through in order to confirm that the functionality is performing according to the expectations. If the test case is successful, that shows the quality of this part of the software is adequate and we go on with the next test case.

In IT projects where the deliverable is software, there can be tens if not hundreds of test cases that must be performed to finally confirm the quality of the final project deliverable.

So what will happen if the quality control process approves a test case and later we find out that the software didn’t conform to quality; that the software failed to work even though the test case cleared it? Well, that’s what the last quality process is there for. It is called Quality Assurance.

Quality assurance is often confused with quality control but they are completely different. Quality assurance is part of the execution of the project and is concerned with overall process improvements. If the quality control processes are not adequate, this is where quality assurance comes in and handles the issues. So in the case where the software was cleared through quality control and later on failed is what quality assurance must deal with.

If something is not working correctly or we need to improve the quality control process, quality assurance goes in and investigates. Why did the test case not catch the issue we are now experiencing? What can we change in the control process and the test case to fix the problem in the future? Quality assurance is an ongoing process that makes the quality control process better and better. The goal is to make sure that the quality control is the best possible, and make changes as needed to ensure this throughout the project’s lifecycle.

Quality management is important because it ensures that the deliverable ultimately fulfills the project requirements and the customer’s expectations.

You may have heard about the critical path in a project and how the development of the project schedule is dependent on the critical path. As a project manager the critical path is essential to determine potential issues in our project schedule.

So what is the critical path and how do we determine it? Well, let’s first take a look at a network logic diagram for a simple sample project.

Each activity has a duration measured in weeks and the arrows show how each activity is depending on other activities to finish before they can start themselves. In the sample activity A must finish before C can start and D can only start once C has finished etc. We can also see that activity C can only start once both A and B has finished.

From the diagram we can determine three separate paths:

Start – A – C – D – Finish: 8 weeks

Start – B – C – D – Finish: 9 weeks

Start – B – E – F – Finish: 7 weeks

The critical path is defined as the longest path in the diagram and in our example it is path B-C-D that is the critical path of 9 weeks. What’s so critical about it? If one of the activities on the critical path is delayed the entire project is delayed!

If for instance activity D is delayed 1 week, the project will be delayed with 1 week.

But if activity E is delayed 1 week it will not delay the project because path E is on will just be 8 weeks and still be done one week ahead of the BCD path.

So the critical path is made up of activities that cannot be delayed without delaying the finish of the entire project.

What happens if activity E suddenly is delayed 3 weeks? In that case the B-E-F path becomes the new critical path of 10 weeks and the finish of the project is delayed. The project manager must now determine how to handle this delay or accept it as the new critical path.

Will a project only have one critical path? A project can easily have more than one critical path and in that case the project manager must know all of them.

So now that we know what the critical path is and how we determine it; how do we use it practically when managing a project?

We use it to determine if the project will be delayed if an activity is delayed. If the activity is on any critical path the answer is Yes! If not, it depends on if the delay makes the activity create a new critical path. If not, the answer is No!

A project usually have hundreds of activities and they usually have much more complex dependencies than our example, so project managers usually use software to set up the activities and dependencies and let the software calculate the critical path(s). If an activity is delayed the project manager can enter the delay in the software and see how it affects the overall finish of the project. It the project is delayed the project manager can use the software to rearrange activities, dependencies or suggest additional activities as needed to bring the project back on track.

The critical path is critical to the Time Management knowledge area. Make sure you know how to use it correctly next time you manage a project.

www.dilbert.com

Many projects fail for several reasons. One of the major reasons is “The Scope Creep”. First let me define what the scope creep is and how it can sneak in on a project.

When a project is first defined the scope is always a high-level scope as defined in the Project Charter and the Preliminary Scope Statement. The high-level scope is often accompanied by an Order of Magnitude Estimate of the cost that has a precision of -50% to 100% of the estimated cost.

As the project goes into the planning phase, the scope is defined in detail and for IT-projects it is usually established in an Enterprise Design Document (EDD). The EDD is used as a scope and cost baseline for the project. The cost estimate established as part of the EDD is usually much better than in the beginning with a precision of -10% to +15%.

So what can possibly go wrong now that the scope is well defined? More than most imagine! As the project continues into the execution phase, stakeholders change their mind about functionality, training, time lines, etc. If someone asks for changes to training requirements, functionality and time lines, they are changing the scope of the project. When that happens, it most often affects the time, cost and scope and a good project manager must execute proper change control to the project in the form of a project change request. This request must explain how the change will affect the project in regards to cost, time and sometimes also quality. The request must get formal approval from the project’s steering committee and a new cost and time baseline must be defined.

Does this sound formal and excessive? Maybe, but it’s the only way to control the scope. If the project manager just accepts the change as part of the existing baseline, the scope is different but with no changes to the project’s time and cost baselines. That’s the definition of the scope creep.

So what if we add a few hours here and there? Does it make such a big difference? Oh yes it does. If the stakeholders know they can add functionality or make changes to the time line without any repercussions, they will continue to do it. A training session is extended or postponed. Some additional functionality is added here and there. The amount of work is slowly increased and the time line is affected more and more. The scope creep is getting bigger and bigger from all these little changes that are allowed to slip through. And the result? The project is not delivered on time and within budget. The project fails.

So the application of change control makes all stakeholders aware that changes to the project may affect the time line and budget and in each individual case the steering committee must decide if they want to go forward with the change and also accept the change in cost and time. If they agree, they must formally accept the change request and the project manager will then calculate a new cost and time baseline that now becomes the current baseline for the project.

So can a project end up costing twice as much as original estimate and be delivered three months later and still be on time and budget? Yes, that’s the whole point of scope management. If the steering committee accepts changes to the project including cost and time changes, they also accept a new project baseline, thus the budget and the time line just changed for the project.

Scope Management is, in my opinion, one of the most important management tasks a project manager must do. Controlling the scope by applying vigorous change control and not accepting any changes to occur in the project without executive acceptance is crucial. If you ease up on this strict control, you risk losing control of the entire project and failure is most likely the outcome.

I wanted to let you know of a very useful tool when working with ERP systems or virtually any software programs.

I often have a table or some text that I like to export to Excel and continue to work on like a worksheet. Sometimes the software I am using will allow me to do the export but often it won’t. Especially graphical applications will have issues exporting to Excel.

The product I use is called Print2Excel and can be downloaded from http://www.print2excel.com.

Print2Excel allows any document to be exported to Microsoft Excel. It adds sophisticated functionality like printing profiles specific to each document or report, which allows you to customize how the information is presented in Microsoft Excel.

One of the great features of the software is that it will allow you to process the printout before it gets exported to Excel and allows you to strip headers, footers or specific text so you don’t get a lot of extra lines or columns that you have to delete afterward.

Since certain documents and reports require tedious data cleanup to be useful in Excel for further processing, Print2Excel introduces profiles. Profiles are a set of post processing settings, which Print2Excel can use for certain documents to quickly provide useful data in Excel. Via profiles advanced settings like removing certain data sections, blank rows and columns, apply certain text formats etc. can all be set specifically for one report or document type, so subsequent printing of these reports immediately makes the data available in Excel cleaned up and ready for the user to use.

I managed to get a promotion code that will allow you to get 10% off any number of licenses purchase through their website at http://www.print2excel.com. Use promotion code spring11 to get the 10% discount.

The cost of a project should be planned, quantified and measured. The job of the project manager is to tie the cost to activities and resources and build the estimates accordingly.

Most projects start out with a high-level budget before we know the detailed costs. The project manager often gets a budget for the project but instead of blindly accepting the budget the project manager need to review the scope of the work and the duration estimates created in the Time Management knowledge area in order to come up with a realistic budget. Budgeting by working from the detailed level is called a bottom-up approach and is much easier than working from the top down.

The overall recommended approach for detailed planning is to create the scope, then create the schedule and finally create the budget. In my opinion any other sequence will not make any sense.

This article will cover all the areas needed to successfully manage the cost of the project.

Cost Estimating
This process is part of the planning process group. This process is not only executed during the planning process but will be revisited many times during the project life cycle.
In order to be able to do any cost estimating we need to know the scope and the resource and duration estimating. Without that we won’t be able to do any cost estimations. There are many options for cost estimations.

So which one should we use to create the estimate? It all depends on the need. In the beginning where we only have a high-level scope we will only be able to do a Order of Magnitude estimate and later when the scope is more detailed we can create a Definitive or even a Control estimate. The rule of thumb is that, the closer we are to spending money for an activity the more precise the estimate will be.

In order to do the estimate we will utilize the Project Management Plan, Project Scope Statement and the Work Breakdown Structure.

Cost Budgeting
Many ask what is the difference between estimating and budgeting? Isn’t that the same? I agree that this can be confusing but a budget is also known as the cost baseline and it takes the cost estimate and maps it back to the dates on a calendar.

The cost baseline allows the customer to better plan for the expenses for this project including the cash flow. In order to be able to create the budget we must have the schedule developed and the cost estimating completed.

Most projects maintain some kind of financial reserve to protect against cost overruns. Typically projects will carry a 10-20% contingency reserve (or management reserve) that can be used for unforeseen events or risks.

Cost Control
This process is part of the Monitoring and Control process group. This process is primarily concerned with cost variance. A cost variance can either be positive (good) or negative (bad). The process ensures that the cost stays on track and that any change is detected whenever it occurs.
Like so many other processes in the process framework this process is revisited and executed many times during the project life cycle. Typically Cost Control is performed weekly during implementation where the project cost typically peak and monthly during the planning phase.
In order to determine how the project cost is performing we utilize Earned value Management. Please refer to my article on Earned Value Management for more information.

In most of my articles regarding project management I often say that the particular subject is important but Cost Management is very important simply because the customer is always very focused on price and any price increase will be very obvious to the customer unlike other project management areas.

This area deals with processes to handle procurement of goods and services that our organization can’t deliver.
The overall philosophy of procurement management is that it’s formal. This means that we are not just dealing with handshakes and a few emails back and forth; we are dealing with formal and legal contracts with our subcontractors and vendors.

There are six processes in procurement management.

Plan Purchases and Acquisitions
Here we take a look at the project and determine which components and services of the project that we can handle internally and which ones we need to outsource. This is also called and Make-or-Buy Analysis. Hereafter the project manager needs to determine what kind of contracts we need to put in place.

There are several contract types that could come into play:

Plan Contracting
In this process we create detailed documents such as Requests for Proposals or RFPs. The RFP explains what is expected of the seller in terms of what should be done, when it should be done by, cost, time and quality etc.

Request Seller Responses
This is the process where we distribute the RFPs and other procurement documents to potential sellers and have them respond to the RFP. We usually provide a deadline for all responses.

Sometimes we can also set up a bidder conference to allow sellers to ask questions. This is most often used of the requested services or goods are complex in nature and instead of answering the same questions several times in separate communications we can handle it all in one conference session.

We can also elect to advertise the bid to the public on websites or in newspapers. In some cases this could be a requirement by law, so make sure to check if this applies in each case.

Select Sellers
Now it is time to select the sellers from the received responses. The selection can be based on price, quality, delivery time etc. As the project manager it is up to you to determine which sellers are best for the project and select them accordingly.

Contract Administration
Here we review the contract and determine if the results match the contract. Were the goods and services delivered? Were they delivery on time? Were we invoiced the agreed amounts? Other contractual obligations can also be considered here.

Contract Closing
Here we are handling completing the contracts and terminating them officially. Hopefully the seller delivered according to the contract and we paid according to the contract, but contracts can unfortunately also get closed for non-delivery, non-payment etc.
One thing is for sure. Contracts must be closed one way or the other. In order to eliminate risks to both parties, closing the contract makes certain nothing else is going to be delivered or paid under the contract.

This knowledge area is primarily concerned with resources, activities and scheduling. As project managers we always want to be in control of the schedule and not the other way around.
Using the scope baseline we build the schedule from the ground up.

The key input to the knowledge area is the Work Breakdown Structure or WBS. There are six processes in this knowledge area of which five is in the planning process group and one is in the monitoring and control group.

Activity Definition
Based on the scope baseline and the WBS we break each work package into all the activities needed to deliver the particular package. This is also called activity decomposition and involves breaking down the package into activities that may involve multiple groups of people. From here we can now derive an activity list that can be used by the next three planning processes.

Activity Sequencing
We will use the activity list derived from the last process and put all activities into the correct sequence. Some activities may depend on another activity being finished and that’s what we deal with in this process.
We typically create diagrams to visualize how each activity needs to fit into the bigger picture.

As we are building the sequence we can insert lead and lag time as needed. Lead is simply letting an activity start ahead of another activity. An example related to IT could be that we developed software that needs to be tested but we are able to provide a preliminary version of the software for testing before it is completely done. That way we can speed up time.
Lag is waiting time between activities. An example of lag time could be shipping time between two activities. It takes a few days to get something needed for the new activity to start.

Activity Resource Estimating
For each activity we also have to determine how many resources we need to complete the activity. This is important to be able to do cost estimating later on.

Activity Duration Estimating
Here we take each activity and find out how long they will take with the resources allocated.
This gives us an estimate of the total number of hours needed including inventory items and/or fixed assets.

Schedule Development
Based on all the previous planning processes in this group we are now able to create the project schedule and that becomes the time baseline for the project.

The project schedule will typically be shown as a Gantt chart but can also include a Milestone Chart and other charts used to support the project time baseline.

Schedule Control
This is the only process that is not regarding planning. It is a monitoring and control process where we compare the work results to the plan and ensure they line up. Like with many other project management processes we have to be proactive when controlling the schedule and not sit around and wait for problems.
In order to calculate how the project is progressing we can use earned value management to determine if we are ahead or behind schedule (see EVM article).

You may say that creating the time baseline is a lot of work and I agree it can be cumbersome and tedious to create the schedule but there is no getting around it. We simply have to do it. Fortunately there are software programs (like Microsoft Project) that can assist you with all the time management processes and can save you a lot of time but also give you a lot of control. Project Management software also allows you to do what-if scenarios and calculate the impact in minutes instead of having to manually redo the schedule to accommodate the new situations.

There are five process groups according to PMI. They are Initiating, Planning, Executing, Monitoring and Controlling, and Closing.

All groups contain a total of 44 project management processes of which 21 are located in the planning group. That doesn’t necessarily make this group the most important or most time consuming but it makes the group the most comprehensive group that covers all of the nine knowledge management areas (link).

In this article I will cover all the processes that goes into the planning group. I will not cover each process in detail but rather show the overall concept of the planning process group and what sequence the processes are executed in.

The order in which the planning processes are executed is determined by how the outputs of those planning processes are used. Most of the time the outputs are used as inputs in subsequent planning processes thus there is a natural order all the processes should be executed in.

Integration Management

1. Develop Project Management Plan

The project management plan is covered under the Integration Management knowledge area and essentially covers all the plans from all knowledge areas including baselines and risk registers (see link).

Scope Management

2. Scope Planning

The process of Scope Planning is about developing a plan that serves as your guidebook to the other scope processes. A common mistake is to plan the scope of the product here, but instead we plan how to conduct the scope gathering, definition, monitoring and control and verification for the entire project.

3. Scope Definition

Based on the preliminary project scope statement we will work to gain additional detail of the scope by doing analysis and design sessions. This process actually produces a detailed project scope and is used to create the WBS (see below).

4. Create Work Breakdown Structure

The Work Breakdown Structure (WBS) is a complete and very detailed decomposition of the entire scope in to small work packages that are easy to estimate for time, cost and activities (link).

Time Management

5. Activity Definition

Using the WBS we now decompose each work package into activities needed to complete each package.

6. Activity Sequencing

Once we have defined all the activities we need to put them into the correct sequence. We also need to make sure that activities that depend on other activities being finished are executed as soon as possible after the end of the previous activity. There are much more to this process and some is partially covered by my article about critical paths (Link).

7. Activity Resource Estimating

In this process we estimate how many resources (people and purchases) each activity requires. This is later used as an input into Cost Estimating.

8. Activity Duration Estimating

Here we estimate how long each activity will take.

9. Schedule Development

Here we use the outputs from all the previously planned processes and develop the project schedule. The project schedule is one of the most visible and important parts of the project plan and is often mistakenly referred to as the project plan. The schedule is part of the project plan but is not the project plan.

Cost Management

10. Cost Estimating

Each activity is analyzed to evaluate the time and resource estimates to establish a good cost estimate.

11. Cost Budgeting

The budget is also known as a cost baseline. The cost baseline takes the estimated cost and maps it back to the calendar to allow us to plan for cash flow and expenses.

Quality Management

12. Quality Planning

In this process we are planning how to make sure that the resulting product is of acceptable quality. See this article about quality management in IT projects.

Human Resource Management

13. Human Resource Planning

Here we plan how we will staff, manage, team-build, assess and improve the project team.

Communications Management

14. Communications Planning

This process is about how communication will be distributed and updated including the format of the communication. We also plan which stakeholders should receive the communication.

Risk Management

15. Risk Management Planning

I think you know get the idea about what we do in the planning processes. In this process we plan how we are going to handle risks in all risk processes.

16. Risk Identification

Here we identify the risks that we the project can encounter. Most think of risks as negative but some risks can also have a positive outcome. As project managers we tend to focus mostly on the negative risks since they can jeopardize the project outcome but some risks can have a good outcome. The output is a risk register that is an important part of the project management plan.

17. Qualitative Risk Analysis

In this process we prioritize the risks of the project and update the risk register.

18. Quantitative Risk Analysis

Here we will try to quantify the risk by assigning a projected value if the risk should occur. We want to know what the cost potentially could be to the project in case each risk would occur.

19. Risk Response Plan

Here we create a detailed plan what we will do if a risk should occur.

Purchase Management

20. Plan Purchases & Acquisitions

In this process we plan how we are going to purchase resources or products to the project. Since purchasing can happen during the entire project we may often come back to this process and plan accordingly.

21. Plan Contracting

Here we create requests for proposals and send them out to potential sellers.

In order to complete a successful implementation of a project we must be good at planning. Not all projects may need all the planning processes I mention above, but use this as a checklist for the project planning and include what applies to your project to ensure that you have planned the best you could before the project starts to execute.

The buzzword these days in the ERP software industry is “Role Based”. If you open a brochure from any major ERP software vendor they all mention role based this and that and there are actually many advantages to role-based user interfaces and hardly any drawbacks.

First let’s first find out what Role Based User Interface (RBUI) is.

In any organization all employees are each assigned a particular role. If you are working as an A/P clerk your role may be to pay vendors who have been approved for payment. If you are working in A/R your role may be to call clients who have past due balances. Or maybe you are a sales person and you work with the CRM system and sales quoting. As you can see, all these different roles require access to different parts of the ERP system. The A/P clerk will not need to see sales quotes and the sales person doesn’t need to work on payments for vendors.

In the more traditional ERP software systems, users may get access to a lot of areas they really don’t need but more important the user must actively go and look for information.

If I want to see customer invoices that are past due I would click Financial Management, Receivables, Reports and run the report Aged Accounts Receivable. After getting the report off the printer I will go through it and maybe even look up each past due invoice to see what it contains. Then I can start my collection efforts.

So I have to click and work quite a lot but what’s even worse I also have to know how to get there. That requires that I am trained and that I also remember how to do it.

This is how a lot of ERP software packages work today. I call this the traditional ERP user interface. Once you get used to it, you will probably say this works pretty great.

So now let’s see how the role-based user interface handles the same scenario.

In this user interface we are presented with the information right on the screen. We don’t have to go and look for it. I can click the pile of Overdue Sales Invoices (called a cue) and get to the invoices right away. I can get to all the needed area relevant to my role from the main screen. The user interface is presenting the information to me instead of me getting the information. So I get to the same information in the role-based interface by clicking one time. Also, if the cue is empty I don’t have to do anything! You must agree that this is much simpler. We also have access to our emails in Outlook, we can see all our most used customer and vendors and we even have notifications about things we need to do.

So these all sound pretty great, right? When we are working with a RBUI we can work much faster and more efficient? Well, in many cases it would be correct. If you are doing the same 4-5 things every day the RBUI can definitely help speed up your daily work. It is also much easier to work with and new employees can be trained much more quickly with the RBUI than the traditional user interface.

The issue comes up when you have to do something that is not something you normally do. If what you need to do is not on the front page, you have to go and look for it, just like in the traditional user interface. Another issue could be that you are wearing many hats within the company. You may have to do a little bit of everything or you may be a super user that really needs comprehensive access to all areas of the application. In that case you are really not able to build a decent RBUI without overcrowding it that will defeat the purpose of using RBUI in the first place.

So by simplifying the user interface we also lose some flexibility. If we need to do tasks outside of our normal role we have to approach this using the methods of the traditional user interface. We have to click our way to the right place. See below.

So the role-based user interface is much easier to use than the traditional interface because we are presented with all relevant information and only if we have to do something outside of our normal role do we have to go look for information.