Now, when I say fight, of course I do not mean an all out Battle Royal cage match with your Project Executive (PE). I mean, when you come to a point in the project and you and the PE disagree, fundamentally (on a particular vendor, let’s say). Let’s assume, for the purpose of this article, that you have already sat down and discussed the issue on reasonable terms and you still both sit on opposite sides of the issue…what do you do? As the Project Manager (PM), you are responsible for ensuring the success of the project. As the PE, your colleague will be accountable for the success of the project. You both have a lot at stake, so some discussions can get quite heated. There are a few things you can do to resolve this:

Try to determine the PE’s motivation for their decision.
Are they motivated purely by the success of the project, or are there other areas that may be influencing them? Their boss? Office politics? Desire to be recognized? Once you have determined this, it may make compromise a little easier.

Acknowledge their position, but also identify its risks.
You can always say things like “I realize that choosing the smaller vendor will be less expensive in the short-term, but my experience has shown that you may end up doubling your costs later when we realize the vendor’s short-comings. It is not right or wrong, only a legitimate risk.” By identifying the risks, you are separating the idea from the person and judging purely based on the merits of the idea, not who came up with it.

Know when to concede and put it behind you.
After going through all of the right steps and your PE is still standing firm on their position, you also need to know when to let it go. The PE has ultimate accountability, so at some point you need to move forward. This is not easy or fun, but is sometimes in the best interest of the project. This is not “giving in,” it is just being smart. You are not going to win every battle. Put it behind you and move on.

There is no right answer to this situation, but you should only be doing what you are comfortable with. I have previously told clients that I disagree with their opinion, but I will go along with it because they are the client and have the final say. I agree to move forward reticently, but I also make clear that the risks have been identified and that I will not be held accountable if the decision turns out to be the wrong one! However, it is also important that if the decision turns out to be the right one, give your PE some credit.

---

Andrew Miller is President of ACM Consulting Inc. (www.acmconsulting.ca), a company that provides supply chain and project management solutions. Andrew is PMP certified and has led a variety of clients through complex systems implementations and organizational changes. He is an Instructor of the Procurement and Contracting course, part of the Masters Certificate in Project Management program through the Schulich School of Business Executive Education Centre (SEEC) in Toronto. Andrew has an International MBA from the Schulich School of Business with majors in Logistics and Marketing. He can be reached at [email protected].

Project managers are expected to know the progress of their project at all times. Are you meeting expectations? Staying within budget? Staying on schedule? These can be tough questions to answer without the use of Earned Value Management (EVM).

Fortunately, EVM doesn’t require a different approach to project planning and management. Rather, it extracts useful information from planning work that you’re routinely doing.

The Need for EVM

If every project went according to plan, there would be no need for EVM.

EVM serves to illustrate the difference between what was planned and what is actually happening. It’s an early warning system that alerts management to the realities of project performance.

In essence, EVM creates a performance “contract” for a project. It clarifies exactly what was expected to happen before the project was launched, and then measures whether those expectations are coming true during execution.

The problem with most contracts is that sellers (in this case, project managers) don’t want to commit to a fixed price. They want to spend money as necessary in order to get the work done.

On the other hand, the buyers (members of senior management) want to know exactly what their money will be purchasing. They want a firm commitment from the project manager.

EVM helps to solve this conflict by providing a firm estimate of performance (developed in the planning stage) and then generating interim measures of whether that estimate is being realized.

History of EVM: A Hundred Years of Evolution

Earned value is basic cost accounting applied to the one-time events we call projects.

The practices we now call EVM developed out of cost management techniques used in large factories as early as the 1800s. Industrial engineers of the time compared planned vs. actual output, timing, and cost to provide a picture of performance relative to expectations. Modern EVM does exactly the same thing.

Today, EVM has returned to its roots in cost accounting, but has gone high tech regarding the use of computers and statistical analysis. The new EVM is efficient, effective, and easy to use. It is intended for general use by project managers, working on any type of project, where senior management wants to be kept informed of project progress, not just the final outcome.

The Role of EVM: Monitoring Projects

EVM determines how much of a project has been completed at specific points in time, known as milestones (more on those later). Knowing how much has been completed allows senior management to release funds in small increments and see if they are getting value for their money.

EVM allows senior management to monitor progress and to react to poor performance. Using EVM, senior management can tell early in the life of a project whether it is likely to meet its targets. Management can then decide whether to abandon the project early on, before a huge amount of money has been spent. Likewise, if senior management’s expectations are unrealistic, EVM will quickly highlight the problem.

For the project manager, EVM changes the emphasis from performance targets way off in the distance, to targets that are coming up near term. The project manager knows how the project is performing at any given time and whether or not management will be (or should be) pleased.

Measuring the performance of individual tasks rather than the project as a whole gives both the project manager and senior management a steady stream of signals about the health of the project.

Milestones: The Key to EVM

Established during planning, milestones are a fundamental strategic tool used to subdivide a project’s work effort. They’re created with the express purpose of indicating how much work should have been completed as of a given date.

In order to serve as progress measures for controlling projects, milestones must be defined in three dimensions:

• Clearly quantified work: there can be no confusion about whether or not a task has been completed
• Allocated resources: indicated by either time or dollars spent
• Completion date: can be natural (the end of a contract), artificial (every Friday), or based on a need to measure progress as of a certain date/expenditure (as of May 14 the painting will be complete at a cost of $1,500)

Like alarm clocks, milestones tell management that something should have been completed by a certain date and cost. If it has not been done, something is wrong; there has been an exception to the plan.

Milestone timing depends on the reporting needs of the project. However, the shorter the time between milestones, the lower the risk that the project will not deliver the expected value.

EVM Project Planning

EVM is all about planning. EVM starts with your existing project plan and then breaks it down into tasks that have individually planned expectations of scope, budget, and time frame. These are then used to build a resource-loaded schedule that relates expenditures to work and time.

Rewards (payments and continued funding of a project) are related to a cumulative measure of performance based on how well tasks are being completed as compared with planned performance. When those expectations are not met, this is a signal for management to investigate.

The Performance Measurement Baseline (PMB) documents expectations for the project based on a schedule that relates the work (scope) and resources (money) to a specific date range. With a PMB it is possible to compare actual performance to what was planned for specific points in time. The difference between actual and planned is then used to forecast probable completion costs and schedule.

While the structure and style will vary according to your organization’s preferences, there are three key components of a PMB:

• WBS (Work Breakdown Structure): Either a WBS or an equivalent analysis of all project work.
• Resource-loaded schedule: This is typically a Gantt chart indicating when tasks are to be completed and their associated budget, with milestone markers illustrating control points.
• Budget graph: Summarizes the timing and magnitude of expenses. At the beginning of a project, the only line on the graph is PV (planned value). As the project progresses, AC (actual cost) and EV (earned value) are included.

Management by Exception

Management by exception requires that there be a plan; a prediction of how a project should unfold. An exception is any process that is not going according to plan (that is, over budget or behind schedule).

Management by exception uses the guiding principle that managers should concentrate their energies on fixing the most serious problems first. In an EVM project, problems are defined as performance results that are not the same as the planned results.

Management by exception is greatly simplified by EVM because exceptions are so clearly highlighted by routine performance monitoring relative to a highly structured performance baseline. The more severe the discrepancy, the higher is its priority for management attention.

EVM Statistics

There are four sets of data generated by EVM projects.

• BAC (budget at completion): Original completion budget for project
• PV (planned value): How much the project was expected to cost at any given time
• AC (actual cost): What the accountants say was actually spent
• EV (earned value): What the expected cost was for the work that was completed (the planned value for work completed)

Having a visual understanding of the relationship between these data is helpful for interpreting the meaning of EVM statistics. In this figure, the various terms are illustrated with respect to three basic cost lines, planned, actual, and earned.

BAC and PV are forecasted numbers representing planned expectations for the project. BAC does not change. PV is predicted for the entire duration of the project and ends with the BAC. Data for AC and EV are collected through project monitoring.

This is all the information that is required to manage EVM projects. From these data, performance statistics are generated.

Performance Statistics

There are three variance statistics used in EVM performance measurement, as follows:

• Variance at Completion (VAC): the difference between the original planned completion cost (BAC) and the latest prediction of completion cost.
• Cost Variance (CV): the difference between the expected cost to complete what has been accomplished and what it actually cost (AC).
• Schedule Variance (SV): the difference between, what was planned to be completed as of a given date, and what was actually completed.

There are three index statistics that match up with the three variances, as follows:

• To Complete Performance Index (TCPI): an indication of the efficiency rate needed on all remaining work in order to complete the project on budget. A value of more than 1 implies that all remaining tasks will need to come in under budget (on average) in order for the project to meet the BAC.
• Cost Performance Index (CPI): shows how well the project is meeting cost targets. A value of 1 indicates that actual costs are the same as planned (AC=EV) for the work that has been completed. A value over 1 indicates that costs are less than planned. A value of less than 1 implies that costs have been higher than planned.
• Schedule Performance Index (SPI): indicates whether the project is meeting schedule expectations. A value of 1 indicates that the work completed to date is right on schedule. A value of over 1 indicates the project is ahead of schedule. A value of less than 1 implies the project is behind schedule.

Forecasting

Forecasts use performance indices to predict the future. If the project has been doing really well up to this point, what does that imply about the completion cost and schedule? If tasks are, on average, taking half as long as planned, it suggests that the project overall will be completed in half the time.

While EVM techniques are better able to predict completion cost than schedule, both forecasts remain useful tools.

Forty years of empirical evidence from government acquisition projects has shown that as early as 10 to 15 percent into a project, the CPI provides a reasonable forecast of what a project will achieve. What this means is that cost overruns early in a project will not fix themselves by the end of the project. If anything, the overruns will get worse.

The SPI is a less precise tool for forecasting the future. The principle reason is that tasks affecting the SPI are not necessarily on the critical path for a project, and therefore, they may not affect the completion date. If a large number of tasks not on the critical path are completed ahead of schedule, they will make the SPI look good, even though tasks that are on the critical path may be behind schedule. The SPI provides a high-level overview that, when combined with critical path analysis, allows for an effective prediction of the completion schedule.

The Value of Earned Value

EVM is referred to as “project management with the lights on,” because it shows management where a project is and where it is headed.

Is EVM a magic bullet for perfect projects? No. It will not fix poor planning or poor execution. However, it is a crucial tool for monitoring and reporting performance.

Copyright © Global Knowledge Training LLC. All rights reserved.

---

This information was drawn from Global Knowledge’s Earned Value Management course developed by Vaddac Consulting in cooperation with Global Knowledge Training LLC. Course director and author Brian Egan is CEO of a manufacturing company (Book Box Company) and a management consultant. He has written three professional development manuals and several white papers on aspects of management science. Since 2000, Brian has been a part-time instructor for Global Knowledge within the Business Training product line.Copyright © Global Knowledge Training LLC. All rights reserved.

For many years, one of the challenges with technology was to think of software ‘packages’. This pervasive way of thinking inevitably brings us to thinking of software as a collection of features. We even compare one product to another by listing the features on one side with the features on the other.

The idea of having software as a series of interrelated parts that could be made into plug-and-play components of a larger system often meant we would need to do lots and lots of programming of the interrelating software. Our company has focused on solution selling for years, so for us we’re used to asking a client for the problem before we list the solution. But it does make us think around here of software more as a vehicle for creating a solution, rather than a list of features that the client might find attractive.

In the last couple of years, however, there has been sufficient movement in the software business towards more common standards that we can start to think of technology as a “stack” of functionality, and interact with it as the potential for a solution, rather than the fixed list of what can be delivered on the first day.

I recently presented some project management software to a rather large company with a worldwide brand name. This company certainly has extensive project management experience but in the particular division I was interacting with, project management had always been an ad-hoc or project-by-project notion rather than centrally organized. The division’s volume of work has recently increased, however, and the complexity of that work has grown by an order of magnitude. It’s time to make project management a more formal process.

So, I showed them this software, which was rather well received. I showed the software as I often do, after extensive conversations about what the company is attempting to accomplish. Once I’d done the presentation, I turned off the projector and told a story.

“Imagine,” I said, “having to create a new project. You wouldn’t turn on the software we’d just shown you. Instead, you’d click on a link on your corporate intranet portal. The link would present a web-based form for new projects. You’d fill in this form on your terminal. You wouldn’t need specialized project management experience. You might not need to know how to create the schedule and establish the dependencies between tasks, or what a lag is, or that CPM stands for Critical Path Methodology. You’d just fill in this form.

”Depending on who you are, the form might look different. If you were a senior executive for example, certain parts of the form for approvals might not appear. Other parts of the form might only appear depending on other data you’d enter. If the project details you entered had, for example, a place for the cost of the project and that value was, say, more than $100,000 then another part of the form might instantly appear with additional fields of information required to start a project of that value.

“Now, imagine once completing that form that you click on the ‘Submit’ button and depending on who you are, and the data in the form, it is automatically sent to the person in your organization who needs to approve new projects. That person would receive an email in their Inbox. They might see the whole form there or click on a link to the form online in their browser. They would see what you had typed in but they might also see other information. Perhaps they can see right on the form, for example, the value of the project you typed but also the total value of the budget that has been allocated so far for this year. They would see different buttons on the form such as ‘Reject’ or ‘Request more details’ or ‘Approve’ or ‘Forward for approval’. They would click on the ‘Approve’ button and several things would happen. First you would get an email saying that the project is now approved. In your Enterprise Project Management system a new project would instantly appear. It would have the data from the form that you filled out. There might even be a very high level schedule of milestones if those were required in the form for new projects. The stage for the stage-gate methodology would be set to “initialized”. Other key people might be triggered by that event to create certain project documents and so on and so on.

“Now we can do the same thing with change management, budget approval, resource allocation etc.”

There was nothing on the projector. It was a story. But the story was compelling.

“That’s just what we need,” said the representative of the organization.

All of this has become possible and not just with one tool. In fact, if you wanted to make my story into a solution, there are several tools you’d go to look for. They might come from the same vendor or from several vendors.

You’ll need a server-based enterprise project management system of course. That’s a good starting point and there are a number on the market.

You’ll also need server-based workflow engine. Again, there are several on the market that are quite excellent and can be configured without having to be a programmer.

You’ll need a forms-generator for online forms to be able to create intelligent forms that can take actions in the background. Most workflow vendors have such forms-based tools embedded in them or attached to them, but most workflow tools can work with numerous forms tools.

This interoperability is all thanks to the ubiquitous presence of the Internet and the movement from older client-based systems to server-based centralized systems. This has prompted more and more vendors to open their technology. We hear more of the terms “Software as a Service” (SaaS) or “Simple Object Access Protocol” (SOAP). The movement towards Software available as a Service means that whatever functionality is available can be used by different interfaces to create blended functionality. The standard of SOAP and other such protocols means that everyone has a standard syntax and grammar for communicating between products. The end result is the potential to combine the functionality from where you can find it into the solution where you need it, and that’s all possible today.

That’s all the good news.

I know. You were waiting for the bad news weren’t you?

The challenge is what’s implied in my story. The workflow sounded wonderful to my client but, if I want to implement that technology, we need to know what the workflow is. That implies a standardization of process that everyone in the organization agrees to. As I’d mentioned earlier, this particular organization had managed projects in a very casual ad-hoc manner. So getting consensus on what the new project process might be will almost certainly take some work, and consensus is key. Also, we can, in theory, proceduralize almost anything, but the law of diminishing returns takes effect in here somewhere. There will come a point where making a formal automated process of one more procedure rather than leaving it to be managed casually won’t produce any more efficiency. There needs to be someone central to make the decision on what that point is.

Who will make the final decision on what to proceduralize? Who will have the final say on what a particular process will be? What will be the process to change or add to the process? If the processes we’re discussing will touch several departments (such as Finance, or HR) instead of just project management, then who will be the liaison for those departments? Who will be the keeper of the process? What is their authority in the organization?

This is why, when I talk about enterprise project management and what’s possible, I inevitably talk about it as a change management project rather than as a technology project. At its core, we’re asking the organization to change how it works and possibly how some core aspects of how it works. That change is always going to be a bigger challenge than the technology required to deliver the solution.

What’s important to know? That it’s now possible to blend these technologies together and as a result bring the project management process to levels of the organization that will never see or need to understand a GANTT chart or a PERT diagram.

---

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]. This e-mail address is being protected from spam bots, you need JavaScript enabled to view it.