Project Estimation, Part 2: Creating a Scoping and Estimating Tool

Perform a Time-and-Motion Study for Delivering Each of Your Services

Your next step is to figure out, relatively accurately, how much time it takes to complete each of the standardized, repetitive tasks. This is actually pretty easy to do. The challenge is having enough examples to give you confidence in your time measurements. As with many other first attempts at estimating, this is an exercise in trial and learning. First, you might decide to work on a couple of small Web sites—either on your own time or perhaps at an introductory-offer rate to begin a relationship with one of your target prospects. The advantages of using a real project include the following:

• The time you spend on the project is the actual time you need to spend. It isn’t artificial or made up.
• You are starting to build your business even as you’re still creating your estimating tool.

But using a real project to figure out these service components poses several problems:

• No single project—or even a few projects—would likely require all of the service components you want to provide.
• Small sites might not be representative of the effort necessary for larger projects.

It’s almost guaranteed that you’ll get your first estimates wrong. It takes time to dial in the numbers accurately. But it’s okay if you don’t get your costs exactly right from the start. The worst that could happen is that you wouldn’t make as much money as you’d hoped during the early stages of your business. As with most trial-and-learning approaches, you can adjust your tool to make it more accurate over time. In the worst case, your prices would approach what your competitors are charging. But the point of this tool is to give you a competitive advantage by identifying the services that you can make more efficient through technology.

Let’s say, for example, that you determine your prospects would always require you to deliver a navigation structure or information architecture (IA). Setting up that structure seems to take a similar amount of time for all your experimental pilot sites. However, you learn that, for larger sites, creating the navigation structure takes substantially longer because the shift in scale adds greater complexity to the IA. Make a note of this difference because the tool must address it.

To summarize, this key step of building your estimation tool is to figure out the time necessary to perform key tasks that support the services you plan to provide by doing the following:

• Identify the time it takes to complete each of the standardized tasks.
• Identify the time it takes to complete each of the technology-enabled tasks—that is, setting up the technology, tweaking it for a specific site, and testing it.
• Record the custom services—those you identified in step 1—that you are still obligated to provide to meet your clients’ expectations as a service provider.

Quantize and Assign a Price to Each of Your Deliverables

The next step in building your tool is to quantize each of the services. As I mentioned earlier, quantizing converts your hourly earning rate into a billable amount that is independent of an hourly billing rate. Essentially, this step converts your time-and-motion work into a list of services that you offer your clients. Rather than throwing hours of time at an activity, you are providing a discrete piece of work. As I discussed in Part 1, piecework is not the same thing as fixed-fee work. In fact, this estimation tool enables a flexible fee structure at a granular level that your client will appreciate.

You’ll begin by creating a spreadsheet. Although you can use almost any spreadsheet system, if you want to automate certain steps or create advanced capabilities—such as a dashboard for all of your proposals—you’ll need a system that provides macros and a programming environment such as Excel. (This tutorial requires none of that, so you can use any spreadsheet you prefer.)

First, assign a row in the spreadsheet to each of the tasks you’ve analyzed during your time-and-motion study. In our example, the first task is Craft IA. For each task, provide a quantity and a unit of measurement. For our Craft IA task, we might use iterations as our unit. Quantity is the number of times you’ll iterate on the IA. Table 1 shows how the Craft IA task might look in your spreadsheet.

Table 1—Defining the Craft IA task

A	B	C	D
Item #	Item Name	Quantity	Unit
1	Craft IA	—	Iterations

The next step is to create a factor for each task. This factor is based on your timing analysis. Enter it in terms of either days or hours. For our IA example, you might have determined that it would take eight hours to craft an IA. Using an hourly basis, your factor would be 8; for a day, 1. Whichever you choose to use—hours or days—be consistent for all tasks in the estimation tool.

Now that you’ve defined a quantity and a factor, enter the formula that calculates the total effort necessary for that task in a Total column, as shown in Table 2. This formula is very simple: C1*E1.

Table 2—Calculating the Craft IA task

A	B	C	D	E	F
Item #	Item Name	Quantity	Unit	Factor	Total
1	Craft IA	2	Iterations	1	2

Repeat this process for each of the services you intend to provide. Once you’re finished, you’ll have a spreadsheet of all the tasks you expect to perform. You’ll be able to estimate quickly how much an entire job would cost a client by simply entering quantities in the proper cells.

Let’s address several nuances pertaining to this step. Our hypothetical example plays fast and loose with several realities:

• In the real world, crafting an IA could take far more time than eight hours.
• The first iteration might take twice or three times as long as subsequent iterations.
• Crafting an IA isn’t a single activity, but a series of subtasks.
• The time necessary to craft an IA depends on an information architect’s level of expertise so cannot be standardized.

All of these concerns are real, and I’ll address each of them later in this series. But, for the purpose of understanding how to build an estimation tool, assume that Craft IA is a discrete service deliverable.

Before I conclude this installment, I want to address those skeptics who might not believe it’s possible to quantize all services—even our example service, crafting an IA. The objection is that there are just too many ways in which an IA can vary for us to be able to reduce this task to a single number. For some instances of service components, that could actually be true. You’ll likely have some items in your tool that are based on hourly rates—such as meetings. But in the case of Craft IA, as I’ll illustrate in a future article, you should be able to decompose this task into quantized components that increase or decrease appropriately with the size of the IA.

Conclusion

In this article, I’ve introduced an approach to modeling your service business in a way that lets you work transparently with your clients, putting them in control of their costs, without giving up your competitive advantage. Building a spreadsheet that captures your service components is simple. Over time, it becomes a core part of your competitive advantage.

When I first developed this tool for my consultancy Phase II, it took me several months to get the list of services right and perhaps a few more months to optimize the numbers. Then, I revisited this model a few times a year as my business changed. For example, when we expanded and brought on new employees, we faced a new challenge: how to account for individuals’ varying degrees of experience in performing each of the services.

Similarly, when I adapted this model for a broader range of services within an internal corporate context, the process of decomposing the services, quantizing each of them, and calibrating the numbers took several months. I continue to review my model on a quarterly basis as new tools and services emerge and for the particular team delivering them.

In subsequent installments, I’ll cover many of these topics in greater depth and show how you can use my estimation tool to help your stakeholders understand the place of User Experience in the larger context of Product Management and the Software Development Lifecycle.