Top

Project Estimation, Part 4: Leveraging Design Thinking to Drive Higher Quality

July 15, 2019

One of the greatest challenges of running a service business is balancing your labor costs against clients’ true needs. Addressing a complex business problem can require significantly more resources than addressing a simple one. Complex problems often require more time, higher-paid employees, or both. Complicating matters further, clients want to know how much to budget and the extent to which that budget will be accurate throughout the course of a project. But complex projects, by their nature, are extremely difficult to predict up front. Of course, clients want to get the most value for their money, so they’ll want to reduce costs whenever possible, making estimating even more challenging.

When you put all these challenges together, it’s not too surprising to see service projects failing to meet client expectations, running over budget, or delivering outcomes of far lower value than anyone had hoped. While the approach to estimating that I’ve been discussing throughout this series of articles won’t solve all of these problems, it does eliminate a couple of them by

  • keeping the client in control of costs throughout the project—even when scope changes
  • removing dependencies on hourly rates

In the earlier installments of this series, I introduced an approach based on two important concepts: decomposing services into quantized service elements and situating those service elements within a design-thinking framework. Plus, I described a spreadsheet tool that I’ve used throughout my career for estimating, managing, and reconciling these service elements to ensure my clients stay in control of their costs. This approach is particularly useful when working as a subcontractor to other service providers in a Business-to-Business (B2B) relationship. It lets my clients quickly telegraph to their clients how changes in scope would affect changes in costs.

Overview

In this installment, I’ll elaborate on the spreadsheet tool, looking beyond simply estimating or reconciling the scope of work. You can use this tool in educating your prospects about the variety of services you can provide, differentiating your company from your competition. By educating your clients, you can encourage them to consider higher-value services—not just higher value to you, but in service of better results for them.

Starting with the basic spreadsheet I introduced in Part 2 of this series and the design-thinking framework I introduced in Part 3, I’ll elaborate on the tool by situating each service within the appropriate design-thinking phase. You might recall that, in Part 1, I used a single service offering, crafting an information architecture, or Craft an IA, as an example of how to decompose your services into discrete offerings. In Part 2, I demonstrated how to build a simple spreadsheet in which to capture each quantized element and take a piece-work approach to estimating your services. Recognizing that this approach is unorthodox, I asked for some suspension of disbelief. Can I really translate a service, such as crafting an IA, from a time-based calculation into several items of piece work? By the end of this installment, I hope you’ll see how you can model your service elements as quantized components, enabling you to be competitive and transparent and letting your clients stay in control of their budget. I’ll accomplish this by expanding on that initial Craft an IA service element.

Building a More Robust Model

What does it take to actually craft an information architecture for a site? Here is a list of possible activities you might consider:

  • initial kick-off meeting
  • building a project plan
  • identifying internal stakeholders
  • interviewing internal stakeholders
  • building a discovery plan
  • identifying target users
  • interviewing target users
  • creating a card sort
  • administering a card sort
  • analyzing the results
  • proposing an information architecture
  • proposing a navigation structure

By quantizing each of these activities, you can assign value to them independent of your hourly rate. In the spreadsheet tool, each of these activities would have a quantity, unit, factor, and head-count total.

However, each of these activities supports very different goals—even as they all relate to crafting an IA. The kick-off meeting, for example, is all about achieving alignment with your client, while interviewing target users is all about discovery. Why is this important? Remember, activities that occur in the divergent phases of the design-thinking model are more likely to expand or contract the original estimates for activities that occur in the convergent phases. But you’re offering an estimate, up front, before you’ve done any of the discovery work! How is it possible to even get close to an accurate proposal if you can’t predict the number, size, and ultimately, the cost of downstream service elements?

That’s why, as I discussed in earlier installments, you won’t provide a fixed-fee proposal, but an estimate of service elements that is based on what you know at the time you provide it. Even though you can’t be completely certain of the scope of downstream services, you have enough experience to know that some set of services will be necessary and, with your experience, you can make a pretty good, educated guess about what those services would likely be. But you won’t just offer a lump-sum guess of the cost of those offerings. Instead, since you’re being transparent at a service-component level—even at the proposal stage, when you’re least certain of the total cost—your prospects can see what services might change, along with the cost of each of those services.

In my experience, prospects are delighted by this transparency, even if I can’t guarantee a fixed price. Following our discussions and because of the contract language to which we’ve agreed, they know I won’t proceed on any work without their prior agreement. At the same time, they have, at a minimum, a clear description of the work that I’m proposing and an approximate cost for that work.

Table 1 shows an example estimate for the crafting an IA services.

Table 1—Example services estimate for crafting an IA
Item Type Description Quantity Unit Factor Total HC

1.01

Ad

Kick-off meeting

1

Hour

0.125

0.125

1.01

De

Data gap analysis

2

Hour

0.125

0.25

 

Ad

Stakeholder interview plan / script

1

Each

0.250

0.25

 

Di

Stakeholder interviews

4

Stakeholder

0.125

0.5

 

De

Data analysis / report

1

Each

1.000

1

 

Di

Content inventory

100

Piece

0.031

3.125

 

Di

Existing site map

20

Pages

0.002

0.042

1.06

Di

System assessment

4

Each

0.500

2.00

 

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

2.11

Ds

Taxonomy

1

Iterations

1

1.00

3.10

Ds

Information architecture

2

Iterations

1

2.00

3.11

Ds

Navigation definition

2

Iterations

1

2.00

3.12

Dv

Site map

15

Pages

0.063

0.938

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

It took me about five minutes to fill in this spreadsheet. For most engagements, based on all my up-front conversations with the prospect, along with my experience working on similar projects, it takes only about 30 minutes to provide an estimate.

Table 1 includes almost everything you would discuss with a prospect about crafting an IA, but it’s missing the design-thinking framework. There’s a hint of the framework in the column labeled Type, but I’ve found that isn’t enough to help my prospects understand how each service element supports a design-thinking model. Therefore, I’ve expanded the spreadsheet to help drive that conversation.

In the revised estimate spreadsheet shown in Table 2, I’ve segregated the various elements into the following design-thinking phases: Discover, Define, Design, and Deliver. I’ve also added two more sections: Intake and Administrative for project-overhead activities.

Table 2—Expanded services estimate for crafting an IA
No. Type Description Quantity Unit 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 = Discovery, De = Definition, Ds = Design, and Dv = Deliver. Plus, HC = Headcount.

Of the 24 line items in Table 2, only two units are hourly. This is the approximate ratio for most projects. About 5–10% of the service components end up being hourly—mostly meetings.

This example reveals two columns that I don’t usually show to my stakeholders: Type and Factor. I usually hide the Type column because it’s visually noisy and doesn’t add much value to the conversation. But I use the values in that column in the tool’s formulas for building the aggregate dashboard, which I’ll discuss later in this article. I hide the Factor column because it reveals the formula behind my underlying rate. For the purpose of determining what my clients want—the right quality outcome for the price or a proper value proposition—clients don’t need to know my value proposition! However, I’ve exposed these columns to make this discussion easier to follow.

When working with a prospect, use the following process:

  1. During a pre-proposal meeting, sit down with the decision makers and walk through each of the line items in your spreadsheet. As an example, my spreadsheet has over 100 line items, whose clustering is similar to the example shown in Table 2.
  2. As you come to each item, explain why you would or wouldn’t offer that service to the prospect.

I’ve encountered several reactions to this process, as follows:

  • A prospect is keenly interested in each of the services and may question why I’m not proposing a service—or equally likely, why I feel the need to include one. After learning my rationale, prospects are usually pleased to know that I’m basing my decisions on my understanding of their desired outcome. These discussions allow my prospect to help me get things right during the proposal stage.
  • A prospect tires of the process and, after a few minutes, asks me to put together my best guess and go over that with them when it’s ready. In this case, they’re telegraphing that they trust my judgment.
  • A prospect isn’t at all interested in going through the line items. In this case, I’m happy to relieve them of the burden and put together a proposal without their participation. I remind prospects that I will include the spreadsheet as part of my proposal and will use it to manage and reconcile scope throughout the project. While they appreciate my transparency, for whatever reason, they’re not interested in engaging with the details.

The last case is rare, but actually signals a potential problem: a prospect who isn’t interested in the details during the proposal stage may be a poor partner going forward. Or the prospect may have made up his mind and just wants me out of his office. My point here: the estimating tool—by providing an opportunity to discuss your range of services—lets you understand the prospect’s level of engagement, maturity, and potential for partnership.

In any case, I make the spreadsheet available to prospects during the initial estimating session, so they have an opportunity to learn more about the range of services I offer.

The Impact of Divergent Phases on the Estimate

The spreadsheet that I present at the beginning of an engagement with a client is an estimate and, therefore, is subject to change based on new information that I gain during the process. For example, consider the snippet shown in Table 3.

Table 3—Snippet from services estimate showing up-front guestimates
No. Type Description Quantity Unit 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

 

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

NoteUnder Type, Di = Discovery and De = Definition.

The numbers for sections 2.04 and 2.06 are not completely arbitrary. In all likelihood, during at least one discussion with the prospect, I’ve learned that there are four people I need to interview to get my team up to speed on the current content. For the content inventory and site map, I’ve reviewed the target space and judged how many elements the team must review. Finally, in discussing their infrastructure, I make sure to understand the number of underlying systems they rely on to manage their content.

But what if, after interviewing those four SMEs, you learned that you need to talk to at least two more? And what if, during those interviews, you discover a treasure trove of content you hadn’t been aware of at the start of the project? It’s pretty simple, really. Reach out to your client representative as soon as you discover these discrepancies and suggest a change in scope. Then provide a revised estimate for that change. It takes moments to calculate an estimate and a quick conversation to confirm that the client is on board with the differences. If the client prefers to stick to the original estimate, discuss the tradeoffs for cost versus quality. The conversation becomes pretty clinical at this stage: there is a lot more content than you were aware of, the content is probably important—according to their own internal experts’ perceptions—and absorbing that content incurs an incremental cost.

Now, interestingly, the opposite is just as likely to occur: After chatting with their four SMEs, you learn that there really aren’t four systems you need to assess; or maybe there really are four systems, but only two are complicated, while the two others are pretty minimal. Your conversation with the client might go a little differently in this case. Remind the client that you won’t charge for anything you don’t do; and they’ll get a credit at the end of the billing cycle for any over-estimated elements.

Frequently, these two cases cancel each other out—either in part or entirely. In such cases, the conversation is trivial. During your regular check-ins with the client, mention that there is an overage on one; an underage on another. Suggest that there will consequently be some differences. Remember, this is still an estimate—you have not yet actually processed all of the pieces or completed the full system assessment. However, you can provide a more accurate estimate at this stage. When the billing cycle hits, provide the exact numbers, which should be close to what your final estimate predicted.

Of course, this assumes you’re good about managing the project. This spreadsheet helps to keep your team on track. Going into the engagement, each team member knows your estimates. If the original estimate was for 100 pieces of content, agree to limit the work to 100 pieces of content before proceeding. Transparency with your client and within your team reduces errors in meeting your commitments.

Estimating Within the Context of the Design-Thinking Model

Consider two factors when estimating projects within the context of the design-thinking model:

  1. Aggregating by design phase
  2. Identifying resources

Aggregating by Design Phase

Let’s look at one section of the estimating spreadsheet example from Table 2: the section on Card sorting.

Table 4—Micro versus macro design-thinking phases
No. Type Description Quantity Unit 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 = Discovery, De = Definition, and Dv = Deliver. Plus, HC = Headcount.

This section belongs to the Discover phase of the design-thinking model because that’s when this activity actually occurs. It serves as a research tool to understand users’ affinities for terms. But take a look at the Type entries—Ad, Di, and so on. Even during discovery, you may have work going on that isn’t limited to the Discover phase—in this case, some administrative, definition, and delivery work.

Why is this important? One way in which you can use this tool is to analyze how much effort you’re expending in each design-thinking quadrant—not at the macro level as the card-sort section suggests, but at the specific activity level. Once you’ve won the job, share this analysis with your client, indicating how much time or what percentage of effort you’re spending on the various phases. For some clients who are skeptical of research or concerned about administrative overhead, you can set their mind at ease by providing a summary of the work. In my spreadsheet, I’ve reserved a dashboard for that purpose, as shown in Table 5.

Table 5—Dashboard view of the head count (HC) for the work
DiscoverHC DefineHC DesignHC DeliverHC AdminHC

0.15 HC

0.05 HC

0.10 HC

0.01 HC

0.10 HC

43%

14%

29%

1%

29%

NoteHC = Headcount.

The first row of numbers in Table 5 indicates that doing discovery would require about 15% of one person’s time; definition, about 5%; design, 10% ; and delivery, 1%. Because this is predominately a discovery engagement, I would expect to see significant engagement during the Discover phase.

Most projects have an administrative cost of about a 10%—administrative refers to client meetings, stakeholder reviews, and other client-facing overhead. I do not explicitly transfer our administrative costs such as billing, payroll, or the like to our clients. They’re baked into our factors. The bottom row in Table 5 shows the relative percentages of time spent on each phase. Depending on the type of work, these percentages would vary—for example, heavy on discovery, as in this case, versus mostly delivery—such as wireframing, redlining, or coding.

Note—In this example, administrative is almost a third of the effort because we are illustrating just one set of services: Craft an IA. However, in a typical engagement, the administrative overhead would get distributed across many more service elements, reducing its relative size.

Identifying Resources

Another reason I tag each entry with a specific phase of the design-thinking cycle is to allow me to consider all of the resources I have available to do the work. Some of my team members might be more skilled at discovery work, while others may have a knack for stakeholder engagement or copywriting. Based on the estimate for each type of activity, the design-thinking model shows me how to assign resources.

Table 6—High-level view of the head count (HC) for the overall effort
  All Head Count

Approximate total for duration

0.40 HC

Maximum across phases

0.35 HC

Note—The Maximum across phases total represents the maximum total effort that is necessary across all four phases. In this case, the Discover phase requires about 35% of a person’s time. HC = Headcount.

The design-thinking model also lets me total the effort across all the activities. Plus, it gives me a high-water mark—that is, the maximum effort across all the phases. For example, the entry 0.35 HC indicates that, for one of the phases, the combined effort requires about 35% of a person’s time. Although, in this example, the effort is a fraction of a person’s time, quite often the effort exceeds a single person, meaning the head-count number would exceed 1.00. This would tell me two things:

  • I would need more than one person.
  • More importantly, I would need to consider who in my pool of resources is available and appropriate for that phase.

Further, if the head count goes too high, I might need to bring on contractors. Bringing in outside resources could change my cost structure. (The full spreadsheet can calculate subcontractor costs for any of the service elements. I’ll cover this enhancement in the next installment.) Although the model doesn’t address load leveling for resources—as a full project-management tool would do—it does account for the amount of effort required for a set duration. For example, let’s say the 0.35 HC is necessary over a 20-work-day period. You would need to assign about one third of a person’s time for about four weeks. But during discussions with the client, you might learn that four weeks would be too long. No problem. Cut the duration in half and increase the head count to 0.70. However, there really is a problem—two problems actually, as follows:

  1. It might not be possible to do the work in two weeks—for lots of good reasons.
  2. You might not have the right resources available who can dedicate that much of their time during that period.

The beauty of this model—and of making it visible to your prospects—is the way you can use it to have a rational conversation about resolving such potential conflicts. If the date is hard and fast—and you have the resources to meet it—you’d be happy to negotiate a higher fee to cover additional costs or the impact on your other commitments. But, if a prospect is unwilling to pay more for your being able to meet their dates, you might choose to part ways. Or, if you’re hungry for work, you could decide how to fold their work into your operations.

The point is: you’re negotiating before you’ve committed to any course of action, and you’re doing it transparently. Using this model as a tool for negotiation reduces the potential for misunderstanding, losses, or injury to your brand—not to mention your failing to help your client meet their goals!

Conclusion

Estimating services is fraught. It’s impossible to estimate services accurately that depend on up-front discovery. The tool I’ve presented in this article doesn’t pretend to predict an unknowable future accurately. Instead, I use this tool to engage with my prospects, clients, and stakeholders in a transparent discussion of the elemental services that are necessary to achieve their desired outcomes. By situating these services within a design-thinking framework, I can distinguish the services that would likely change the scope of effort from those that wouldn’t.

The key here is not to create a fixed-fee contract, but to provide as accurate an estimate as possible, no matter what stage the project is in. At the beginning, when the future is least certain, the conversation is always about outcomes and possible costs. In the middle, after discovery has helped identify the work you’re most likely to do, it’s still about outcomes and costs, but now the way is more certain and the value discussion is crisper. At this stage, you and your client can review the estimate and adjust each element up or down, as appropriate. Throughout the billing cycle and to the end of a project, there is no mystery about what work you’ve completed or its associated costs. 

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