From: dbucklin@sdf.org Date: 2016-11-28 Subject: Getting Started -- Part 1 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 tac- tics 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 develop- er 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 de- veloper's best guess at the cost and time based on very limited in- formation. 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 al- location of resources. This eliminates the wide range of the T&M estimate, but this estimate is not based on scope. The PO can't ex- pect 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 es- timating altogether. This could be an inconvenience to POs who are charged with collecting competitive estimates, but it avoids set- ting 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 per- formance 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 esti- mates? 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 esti- mate, but doing so increases their cost of sale and, without a sub- stantiated 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 defini- tion? 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 pro- tects 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 ef- ficiently. Keep in mind that we are doing this to create a refer- ence definition that supports an estimate and not necessarily to design the product in full.