Project Estimation, Part 5: Embellishing the System to Manage Expectations and Costs

Each element requires an associated amount of time to complete, which I capture as a factor and display in the Factor column. As I’ve mentioned in prior articles in this series, I hide the Factor column because I neither need, nor want to reveal how much time I’ve factored for each element. Why, if I’m promoting so much transparency, do I choose not to be transparent about the time necessary to complete the task?

To answer that question, let’s revisit the process I introduced in an earlier installment: performing a time-and-motion study for each of the service elements.

What, exactly, do you need to do to come up with a reliable factor for each element?

Of course, the gold standard is to track the actual time necessary to perform a given task—not just once, but a sufficient number of times that the completion time remains relatively stable. However, there are several problems with this approach:

• You probably can’t run each element that many times. You’ve got a business to run!
• Who should be conducting each trial? Your most experienced or least experienced UX professional? The times would likely differ widely, depending on who was doing the actual work.
• Certain service elements might be less popular or have lower relevance to your market. Plus, your organization might not operate at its best for some of them.
• For service elements that involve multiples—whether multiple iterations or multiple pieces—the cost, in time, of the first instance would likely be higher than the time necessary to complete the final instance.

These are typical process-engineering challenges, and there are tried-and-true principles for overcoming them. For our purposes, we can rely on a set of heuristics.

Heuristic 0: Adjust your numbers over time.

This isn’t life-or-death, mission-critical, or an emergency. If you don’t get it quite right in the first few contracts, make adjustments until the system achieves equilibrium.

Heuristic 1: Estimate high.

Capture the time necessary to complete the first iteration of a task. If I don’t have the resources or opportunity to measure subsequent trials, I estimate that, by the third time, the task would take roughly half the time the first iteration took. I then average the two, concluding that each iteration would take roughly 75% of the time necessary to complete the first iteration.

The problem with this heuristic, if I use it throughout the design-thinking model, is that my proposals might become too high in comparison to the competition. But, if that’s the case and a prospect gives me a chance to rebid, it’s far better to come back with a lower bid than to try to negotiate an increase in the contract later on. It’s always challenging to increase your cost estimate when there’s no change in the scope of effort.

But can you risk the possibility that your bid won’t be competitive? While Heuristic 1 is a good place to start, you should limit its use to those cases where you can’t use a different approach.

Heuristic 2: Ask an expert.

Someone on my team is likely an experienced practitioner of the service element. So we sit down together and work through the time that is necessary given a variety of constraints or variables. While this approach is usually pretty accurate, I often adjust the factor up, just to hedge my bets. Again, if my estimate is too high competitively, I can review where I might be padding a factor and shave off some time.

Heuristic 3: Use the Delphi Method.

The Delphi Method is an approach to estimating that asks a set of experts to respond to a question, in this case: How long does it take to perform task X? The experts are either internal to your organization or are trusted third parties. While the method has been effective in converging on an accurate estimate, its effectiveness does require using experts. If some respondents aren’t familiar with a task, you might end up with lower-confidence estimates.

Even if your respondents have a broad spectrum of experience, you can still pad where you think your estimate might be at risk, and again, adjust down over time.

But wait. All of this supposes you are using experts to estimate. Doesn’t that mean you need experts to actually execute as well?

This is where time—because you’ve pushed it into the background—becomes unimportant as far as costs are concerned. As long as I know that an expert can complete a task in a certain amount of time, I can bill for that task at a standard billing rate—even if, on a specific project, I don’t have an expert doing the task. For example, let’s say I have an employee who is a master interviewer. In one hour, she can complete a stakeholder interview and capture 95% of what she needs to know. I use a factor of 0.125—that is, an eighth of a day, or one hour. Let’s say I pay my expert $60 per hour. That’s not what I bill my client. I bill my client at a loaded rate that covers my costs of operation—let’s say $90 per hour. At that rate, I know I can cover my operating costs if an expert does the work. If I don’t have an expert, I can expect the task to take longer, but of course, I’d be paying that individual less. Perhaps someone needs twice as long to get the same quality of information, but I’m only paying that person $30 per hour. My loaded rate would still cover my costs.

My client doesn’t need to know any of those operational details. They just know that the service element requires a certain head count (HC), and when combined with other elements, would come to a specific cost.

To answer my earlier question: I don’t reveal the time necessary to do a task for two reasons:

• I don’t want my client to reverse engineer how much I’m billing on a service-element basis. It’s just head count—not dollars or time.
• I don’t know which of my resources I’ll be using—so I can’t truthfully say how much time it will take.

And it doesn’t ultimately matter—as long as I’m charging a fair price for the work and the work gets done in a timely manner.

The Difference Between Effort and Duration

The spreadsheet lets me estimate how much time, or effort, any specific service element would take. Each line item calculates that for me, using the formula: Quantity X Factor, as shown in Table 2.

Note—Under Type, Di = Discover. Plus, HC = Headcount.

In this example, completing the content-inventory deliverable would require 3.125 HC—essentially three people. Actually, each line item assumes the task would be completed in one day, resulting in people-days. While this is a mathematical operation—not a reflection of how the work would be done—I still use it as a sanity check on the level of effort on a line-item basis.

To make the simplified person-days calculation more realistic, I introduce the notion of duration. For each section of the table—Discover, Define, and so on—I consider how many calendar days it would take to complete all of the service elements. For example, looking at the Internal interviews entry in Table 2, the factor for Stakeholder / SME interviews is 0.125, or 1 hour. Completing four interviews takes half a day. But, from experience, I know that it could take a week to get on people’s calendars. So, although the actual work takes half a person day, the task’s duration could be as long as five working days. Introducing duration lets me adjust the total number of people I might need for that phase’s work. While the model doesn’t pretend to be a sophisticated project-management system, by using these durations, I can work directly with stakeholders to load-level the work and negotiate scheduling. In addition to the individual duration days for each section of the table, I include an overall total duration for the project, as illustrated in Table 3.

Note—Sub = Subcontractor and HC = Headcount.

In this collapsed version of the spreadsheet, you can see each section’s proposed duration, in working days, along with the proposed total duration for the project, at the top. By working or business days, I generally mean Monday through Friday. So, 20 days equals four working weeks, or a month.

I use these duration days to quickly try out the following scenarios:

• To reduce the necessary resources, I lengthen the duration days for a section of the table.
• To reduce the time necessary to complete the work, I shorten the duration days for a section.

This system is crude, but effective. I can quickly discuss alternatives with clients to help negotiate costs, resources, and time—without firing up an expensive project-management tool. Remember, I use this tool when I’m in the early stages of building a proposal. The detailed work of building a realistic project plan comes after we win a contract. But, with this tool, I can at least propose something that realistically accounts for the resources I have available for my prospect’s desired timeline.

Quick and Dirty, But Not Completely Accurate

Because this tool is crude, it has a few quirks. For example, consider the Card sort group in our hypothetical Craft an IA estimate, shown in Table 4.

Note—Under Type, Ad = Administrative, Di = Discover, De = Define, and Dv = Deliver. Plus, HC = Headcount.

As I mentioned earlier, although I capture these elements within the Discover phase, only two of the line items are actually discovery activities—the others would be better in Define or Deliver or Administrative. So should the section’s duration days apply only to the line items that are associated with the section? Or should the tool assume all the work would need to be done within that phase’s duration days, even if some of the work extends beyond the design-thinking phase?

Now, let’s consider a different scenario that throws a kink into the works, as shown in Table 5.

Note—Under Type, Ad = Administrative, Di = Discover, De = Define, and Dv = Deliver. Plus, HC = Headcount.

I’ve positioned this snippet—a group for estimating a usability test—within the Discover section because, from a design-thinking perspective, that’s the primary focus of this service. But chronologically this test might occur after I’ve delivered all the work—at the end of a project. This raises the key problem with the tool: What, exactly, do I mean by the duration days for the Discover section? I’ve considered a couple of ways of addressing this problem:

• Keep the elements in the Discover section.
• Create a separate, duplicate group in the Deliver section.

If I keep them in Discover, what should I use for the Discover duration days? I could either use the likely number of duration days for the elements that really are part of Discover or add more days to the duration days to account for these Deliver elements. In either case, the number under HC-Duration days won’t be accurate. If I create a duplicate, the spreadsheet practically doubles—because this isn’t the only instance of service elements that might occur during multiple phases.

A third deficiency of the tool is its inability to capture dependencies. Again, the tool is not meant to be a full-fledged project-management system, even though I can rapidly create GANTT-style charts using the service elements as the tasks. As in the Usability test scenario, not all of the work in earlier sections actually occurs chronologically before later sections.

Instead of investing more effort into creating complex formulas or a more intricate spreadsheet, I simply recognize the tool’s shortcomings when I look at the final numbers. When I’m discussing effort and costs with prospects, I’m transparent about where the estimate is hazy. I liberally comment cells with explanations about why a number is what it is. I document the discussion to remind both me and my stakeholder, in the future, how we ended up where we did.

A Few Formulas and Embellishments

Although most contemporary spreadsheet applications would suffice for creating this tool, I use Excel for a couple of reasons:

• It’s what I started with years ago.
• It has a full programming language behind it.

But—assuming that I could live without the Visual Basic for Applications (VBA) code—Smartsheets, Google Sheets, and the like could handle the level of complexity I’ve built into the model.

All of the line-item elements are pretty simple—just multiplying one cell against another to get the HC-Day total.

The HC-Duration days calculation in Table 3 is only a little more complicated. It relies on the SUMPRODUCT formula, which magically multiplies two arrays of cells together—in this case, all of the QTY and FACTOR cells in the section. I then divide that value by the section’s Duration days.

Plus, I’ve added a couple of embellishments:

• I’ve put in some error checking. For example, if one of the section’s Duration days is missing, but there are service elements being calculated in that section, I display an error message. Similarly, if the section’s Duration days are longer than the project’s total Duration days, I display an error message.
• I’ve enabled a way of calculating subcontractor costs. For each line item, I’ve included an option to have an external resource do the work, with a billing rate that’s separate from our internal rate. In this way, if I do need to account for additional resources, I can quickly estimate what they will cost us.

Conclusion

As the adage goes: Time is of the essence. In service work, time is the only essence. Service work, even when it’s enabled or augmented by technology, boils down to the time you spend completing tasks. Thus, most clients expect service providers to offer hourly rates. However, offering your services at an hourly rate is a disincentive to finding approaches that enhance productivity. If you had a magic device that let you provide a service in one minute that would otherwise take an hour and yours was the only company that knew about it, how would you charge for that service?

If I have technology that improves my productivity, I can leverage that technology in either of two ways when quantizing service elements:

• I can increase my profit by providing the service element at the going competitive rate.
• I can become more attractive, competitively, by reducing the cost of that service to my clients.

In either case, by removing hourly rates from the equation and baking my desired loaded costs into service elements, I get paid by the piece. This tool is not a substitute for a well-considered proposal. It can’t do the hard work of knowing what services to offer, how many of each element to suggest, or what resources on your team would be best for the proposed work. However, it is an excellent tool for rapidly and collaboratively estimating work with your prospects—and through that effort, differentiating your company from the competition. Plus, once you’ve won the business, the tool continues to enable collaboration, transparency, and trust as you and your client adjust the scope of effort together—as well as their resulting costs.

In Part 1 of this five-part series, I introduced an approach to modeling a service business that lets you work transparently with your clients and put them in control of their costs, create competitive advantage, and avoid exposing yourself to unnecessary risks. Then, in Part 2, I described how you can create a simple spreadsheet to track your services by estimating and quantizing each service element. In Part 3, I explained how to situate your services within a design-thinking framework. By doing so, you enable your stakeholders to understand the interrelationships among your services, as well as the relationship between your services and theirs. In Part 4, I explained how you can leverage the spreadsheet tool to differentiate your services from your competition by focusing your prospects’ attention on your value proposition, not your hourly rate. In Part 5, this final installment of this series, I’ve described some additional details of the spreadsheet and offered a few approaches to calculating a reliable time factor for each of your service elements.

I hope you’ve found this series helpful in considering how best to position your own services in your market. If you are interested in discussing this approach further, please feel free to reach out to me.