In part 1 of this article, I’m going to talk about the chicken-and-egg problem faced by product owners and software developers when estimating a new project. In part 2, I’ll cover some of the UX tactics that can be used to close this definition gap.

I’ve seen a lot of projects fail to get off the ground because product owners (POs) and developers need more project definition. The PO may contact a software development partner and ask for an estimate but, in order to provide a useful estimate, the developer needs a definition of what needs to be developed. If the PO doesn’t have the wherewithal to create that definition, and if the developer doesn’t want to create it for free, there is a gap between the level of definition available and the level needed to support a useful estimate. (Note that I didn’t say accurate estimate. The accuracy of an estimate can only be validated after the project is complete.)

At this point, the developer has a few options:

  1. Provide a heavily-qualified time and materials estimate with a wide range to account for the lack of definition. This is the developer’s best guess at the cost and time based on very limited information. From the PO’s perspective, this level of uncertainty may appear to reflect a lack of domain expertise or a lack of interest in the project. In reality, both sides are working with incomplete information.
  2. Provide an estimate based on resource utilization over time. The developer can provide a fixed project cost based on a fixed allocation of resources. This eliminates the wide range of the T&M estimate, but this estimate is not based on scope. The PO can’t expect that specific project objectives will be met in return for the funds invested. The PO could spend their budget and fall short of their goals for the project.
  3. Refuse to provide an estimate. If a developer feels that providing any estimate carries too much risk, they may pass on estimating altogether. This could be an inconvenience to POs who are charged with collecting competitive estimates, but it avoids setting an expectation that can’t be met.

Imagine you are a product manager at a large services company. You manage a software application that customers use to view their bills and make changes to their service on mobile devices and the web. You’ve been given a budget of $100,000 over the next two years to expand the product’s capabilities so that it will move key performance metrics for your business unit. You solicit estimates from a number of developers and get the following estimates:

  • Developer 1: $75,000 - $150,000 T&M
  • Developer 2: $8,000 Fixed Bid
  • Developer 3: $250,000 Fixed Bid

Assuming all shops are working with the same information and are acting in good faith, what explains the differences in these estimates? Any estimate is just a guess based upon the information available. Each developer has to fill in the blanks based on their past experience and their current business model. Developers may inject some definition on their own in order to support their estimate, but doing so increases their cost of sale and, without a substantiated belief that doing so will secure the business, they are unlikely to create speculative work.

How do we close this gap so that the developer can provide a useful estimate to the PO? How can the PO determine whether the project will meet their goals within the budget available? How can both parties reduce the risks associated with expanding scope or missed requirements that result from estimates based on too little definition?

In part 2 of this article, I’ll talk about how to develop ad-hoc definition documents that will place limits on the complexity of the software. This enables the downstream subject matter experts (designers, developers, system admins) to provide estimates with a high degree of confidence. This definition documentation also protects the PO and the developer against scope creep; increases in complexity can be detected using this initial definition. We will have to break a few rules of User Experience Design to do this efficiently. Keep in mind that we are doing this to create a reference definition that supports an estimate and not necessarily to design the product in full.