From: [email protected]
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.

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.