Reading Time: 5 minutes

Many project managers are firm believers in using earned value analysis to measure project performance. This technique puts an emphasis on a metric called estimate to complete (ETC). ETC involves estimating the percent of work completed on each activity, and then converting that percentage data to the dollar value of work remaining, or the cost to finish. It’s a practice that is taught to all project managers. The goal of earned value is to provide a meaningful indicator of project performance but estimating progress is required.

In the business world, unlike the construction world, activity progress is much harder to evaluate. Yet, some project experts continue to push for earned value analysis and no one seems to be focusing on the distinctive differences between projects where percent complete can reliably be estimated and those where it can’t. When the percent complete of an activity is nothing more than an educated guess, the earned value data can be significantly misleading.

In this blog, I’ll provide some clarification on why some projects don’t lend themselves to earned value analysis and outline a six-pronged alternative.

As an example of the difficulty in estimating percent complete, I’m currently building the project plan for a large project. The client wanted an Excel-based plan. I’ve been working on it for days, and getting feedback from everyone on the team and the client. And yet, I don’t know whether I’m 30% complete or 70% complete. I’ll turn in the plan to the client at some point, and will hope that I’m finished; i.e. 100% complete. And yet, I know that in contract negotiations on this project, this plan will get dissected and that there will be clean up after that. The clean up could take many hours, or even days…. The entire risk management strategy or communications plan may have to be rewritten. Scope inclusions and exclusions will be carefully considered, as will time and money estimates.

If you are working on an activity that is essentially driven by machines; such as applying a chocolate coating to bonbons, installing windows in a building, or installing bridge pilings in a river, you can observe the progress, count the bonbons, windows or pilings, and do the math. It’s still an estimate but it is backed up by observable progress.

Unfortunately, if the activity relies in large part on brainpower, estimating percent complete is fraught with complications. Having multiple people involved in the completion of the activity and the approval process will only make it harder. Discussions, texts, emails, or even Slack conversations about how to solve a problem, while necessary, can be never-ending and unproductive at times. Progress is not observable; it is in the mind(s) of the person(s) doing the estimating. It is simply human nature to underestimate how long an activity will take and to overestimate our progress.

It is human nature to underestimate how long an activity will take and overestimate our progress. Click To Tweet

Once we recognize that estimating progress on projects that are reliant on brainpower is fraught with complications, is there another option? Of course there is! At Smart Projex, we’ve been working on that for years.

Take advantage of small wins to build momentum.

Break the project into discrete deliverables that can be finished in a few days to a week, and then, start getting them done. Make sure you have thoroughly defined what “done” means. Is your deliverable a PowerPoint slide deck, a Powtoons video, a Word document, a 50-page legal brief, a 3-page executive summary, or an Excel spreadsheet? Does done mean a draft, or does done mean the client has approved a final product? Who needs to approve it?

As individuals see activities actually completed, that will inspire them, as a team, to keep moving. Avoid having deliverables that are so large that every meeting includes a litany of “I’m working on that. It’s proceeding. I’m making progress.” Don’t ask for percent complete because the data won’t be valid. Ask for DONE!

Set deadlines for the important deliverables, and monitor them carefully.

I so often find teams wanting to have deadlines for everything. Hundreds of activities, all with deadlines, plus the meetings that accompany the work, can crowd your calendar. You run the risk of missing the forest for the trees. I find it helpful to distinguish between target deadlines, which you can use to move the project along, and fixed deadlines, which are critical and must be met. And maybe some activities don’t have deadlines, and you work them in when you can.

Align “done” with invoices.

When you are working on a big project for a client, their question, when they get your invoice often becomes, what am I paying for? In legal projects it may be hard to identify what value the client has received when the only thing that has happened is that really smart people have put their heads together and come up with some ways to move forward. Deliverables may not represent work products that go to the client, but rather a court filing, deposition, or brief.

To the extent you can aim to finish some defined deliverables by the billing date, you can at least report to your client the value that you actually delivered. While necessary, internal phone calls, meetings, and email communications don’t feel like real work to your client. What progress did you actually make on their work?

Without a change authorization, limit scope to what was defined.

It can be tempting to think that this or that analysis will add value to what you are doing or help solve a problem. When smart people get together to solve big problems, they can’t help but explore other ideas and opportunities. That’s their job. And yet, at some point in a project, we have to limit scope to what is agreed on, and require a change authorization for anything else. One way to help ensure that you don’t stray from the defined scope is to track time by deliverables. When there is no category to bill the time to, people will eventually learn to stop doing that work.

Keep conversations focused on your objective.

When smart people get together, even at the water cooler, it can be so tempting to get started discussing all of the project work, changes, possibilities, implications, questions, concerns, and opportunities. And some portion of this is very valuable. The problem is that sometimes these conversations lose focus and ramble on. How can you keep the conversation focused on the problem you are trying to solve?

It is important to give teams opportunities for these overarching brainstorming sessions. To keep them from being a time-suck, try to have a well-defined objective in mind. Try to structure meetings so that everyone is focused on the problem that needs to be solved. Finish your conversation by assessing how well you met your objective and reviewing the action items that were identified in the conversation.

Build effective teams.

Project teams spend a lot of time meeting, both as a team and in smaller groups. The kinds of projects I’m writing about involve teams of smart people, and they won’t always agree on how to best accomplish an objective. Building a team of people who have enough trust to use meeting time to solve problems and effectively engage in conflict resolution takes time.

I’ve written before on the subject of checkpoint and standing meetings and how to make meetings more productive. Every project and every team are different. The cadence of meetings will vary.

Are your project teams struggling? Estimating progress on some projects is just not worth the effort but that doesn’t mean that you give up managing your project. We can help. Check out these resources.