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

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

Note—Under 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%

Note—HC = 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.