Top

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

July 29, 2019

Throughout this five-part series, I’ve presented an approach to selling, estimating, and managing services that puts your client in control while letting you maximize your value. Using this approach lets you avoid billing by the hour. You can instead quantize your service offerings—transforming the time necessary to complete a task into a deliverable unit of value. In Part 4, I decomposed an example of a service offering, Craft an IA, into its constituent elements. In a detailed spreadsheet, I illustrated how you can break a single service offering into 24 separate deliverable units—only a few of which relied on hourly charges.

In addition, I discussed how you can leverage this approach to increase your value proposition with your stakeholders. By being transparent about the range and costs of your services with your prospects, you’ll increase their trust in your proposals. Giving your prospects access to your estimating spreadsheet lets you discuss all the possible services you might offer. By working with them throughout the estimating process, you can show that you understand their desired outcomes. By situating each service element within a design-thinking framework, you can help your prospects understand where changes in scope are most likely to occur. In illustrating to your prospects the relationships between your service elements and the larger design-thinking framework, you can communicate both that your approach is rational and logical and that your final scope of effort and resulting costs could likely change.

While you’ll use service elements as building blocks in negotiating your estimate, you’ll use the spreadsheet I’ve provided to manage a project throughout its lifecycle. You can quickly demonstrate how easy it is to change the defined scope of a project and how such changes impact the bottom line. In fact, you can give your clients the estimating spreadsheet and let them make changes themselves to see what their costs would be. When I work as a subcontractor to other agencies in a business-to-business (B2B) relationship, my clients appreciate the level of agility, transparency, and flexibility this approach offers. They don’t have to wait for me to tell them what any changes in costs might be. Instead, they can run scenarios and estimate those costs themselves.

Overview

Now, in this final installment of my five-part series on project estimation, I’ll elaborate further on this approach, providing more details about the use of time, as well as revealing the formulas and technical underpinnings to the spreadsheet. In addition, I’ll cover the very real limitations of this approach and where its advantages stop.

Throughout this series of articles, I’ve emphasized the point that charging hourly rates is not an effective way to compete: your clients would always want you to bill fewer hours, and you would want to bill more. The implication for any service business is that the path to profitability depends on how well you manage time as a factor. Ironically, in the approach I’m presenting, you’ll never discuss time with your prospects—at least, not at the service-element level.

This is not to suggest that you shouldn’t discuss time at all. On the contrary, you must discuss time with your clients because deadlines and dates are a key factor for any engagement. Nevertheless, the following discussion illustrates how I push time into the background, allowing it to appear only within the context of client deadlines and dates.

Baking Time into the Model

Do you recall the snippet of the model that I presented in Part 4, which is shown in Table 1? In it, I offered 24 elements of crafting an information architecture.

Table 1—Expanded services estimate for crafting an IA
No. Type Description Quantity Units Factor Total HC

1

 

Intake

 

 

 

 

1.03

Ad

Project plan

1

Each

0.250

0.25

1.04

Ad

Kickoff meeting

1

Each

0.250

0.25

2

 

Discover

 

 

 

 

2.01

Ad

Discover plan

1

Each

1.000

1

2.03

Di

Business / user needs analysis

1

Hour

0.125

0.125

2.04

 

Internal interviews

 

 

 

 

 

Di

Interview plan / script

1

Each

0.250

0.25

 

Di

Stakeholder / SME interviews

4

Individual

0.125

0.5

 

De

Data analysis / report

1

Each

1.000

1

2.06

 

Audit / assessment

 

 

 

 

 

Di

Content inventory

100

Piece

0.031

3.125

 

Di

Existing site map

20

Pages

0.002

0.042

 

Di

System assessment

4

Each

0.500

2.00

2.09

 

Card sort

 

 

 

 

 

Ad

Plan / screener

1

Each

0.313

0.313

 

Di

Card-element identification

2

50 terms

0.125

0.25

 

Di

Card-sort setup

1

Each

0.500

0.50

 

De

Analysis

1

Each

1.000

1.00

 

Dv

Report

1

Each

0.250

0.25

2.14

 

User observation

 

 

 

 

 

Ad

Plan / screener

1

Each

0.500

0.50

 

Ad

Recruitment

6

Customer

0.125

0.75

 

Di

Small

6

Observations

0.313

1.875

3

 

Define

 

 

 

 

3.10

De

Taxonomy

8

Categories

0.125

1.00

4

 

Design

 

 

 

 

4.10

Ds

Information architecture

16

Nodes

0.125

2.00

4.11

Ds

Navigation definition

16

Nodes

0.125

2.00

4.12

Ds

Site map

15

Pages

0.063

0.938

6

 

Administrative

 

 

 

 

6.01

Ad

Stakeholder reviews

3

Each

0.500

1.50

6.04

Ad

Meetings

6

Hour

0.125

0.75

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

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.

Table 2—How Quantity X Factor indicates head count
No. Type Description Quantity Units Factor Total HC

2.04

 

Internal interviews

 

 

 

 

 

Di

Interview plan / script

1

Each

0.250

0.25

 

Di

Stakeholder / SME interviews

4

Individual

0.125

0.5

2.06

 

Audit / assessment

 

 

 

 

 

Di

Content inventory

100

Piece

0.031

3.125

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.

Table 3—Duration in days for each phase of the design-thinking model
Estimated Project Duration, in days: 60
No. Type Description Quantity Units Factor Total HC Sub? $ (Sub) Duration

1

Intake

2

 

 

 

 

 

 

 

 

TOTAL: Intake

 

 

 

0.05 HC

 

$ —

5

2

Discover

2

 

 

 

 

 

 

 

 

TOTAL: Discover

 

 

 

0.35 HC

 

$ —

40

3

Define

2

 

 

 

 

 

 

 

 

TOTAL: Define

 

 

 

0.10 HC

 

$ —

10

4

Design

4

 

 

 

 

 

 

 

 

TOTAL: Design

 

 

 

0.25 HC

 

$ —

20

5

Deliver

1

 

 

 

 

 

 

 

 

TOTAL: Deliver

 

 

 

 

 

$ —

10

6

Administrative

3

 

 

 

 

 

 

 

 

TOTAL: Administrative, with fixed expenses

 

 

 

0.05 HC

 

$ —

60

NoteSub = 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.

Table 4—Service elements in the Discover section that aren’t discovery elements
No. Type Description Quantity Units Factor Total HC

2

 

Discover

 

 

 

 

2.09

 

Card sort

 

 

 

 

 

Ad

Plan / screener

1

Each

0.313

0.313

 

Di

Card-element identification

2

50 terms

0.125

0.25

 

Di

Card-sort setup

1

Each

0.500

0.50

 

De

Analysis

1

Each

1.000

1.00

 

Dv

Report

1

Each

0.250

0.25

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.

Table 5—Service elements in the Discover section that occur much later
No. Type Description Quantity Units Factor Total HC

 

 

 

 

 

 

 

2.12

 

Usability test

 

 

 

 

 

Ad

Usability-test plan / screener

 

Each

0.313

 

 

Ad

Recruitment

 

Participant

0.125

 

 

Di

Usability test

 

User

0.125

 

 

De

Analysis

 

User

0.063

 

 

Dv

Report

 

Each

0.250

 

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. 

Senior Manager, User Experience, at Home Depot Quote Center

Principal at Phase II

Portland, Oregon, USA

Leo FrishbergWith over 30 years of experience in design management and design—as both a bricks-and-mortar architect and a UX designer—Leo drives highly differentiated and innovative solutions. At The Home Depot QuoteCenter, Leo leads a dynamic team of UX professionals in delivering engaging experiences for Home Depot associates. Previously, as Product Design Manager at Intel, he led UX teams on mission-critical programs. As Principal UX Architect for Tektronix’s Logic Analyzer product line, he filed several patents and spearheaded product vision and definition for the next generation of instruments. Leo is a Certified Scrum Product Owner. Over the past 20 years, he has served as Program Chair, Chair, Vice Chair, and Treasurer on the board for CHIFOO (Computer Human Interaction Forum of Oregon), the Portland Chapter of SIGCHI.  Read More

Other Articles on DesignOps

New on UXmatters