[TriLUG] Looking for Software Process Clue Stick

[Scott Chilcote]

Hi Steve, thanks very much for your reply.

On 07/11/2014 07:29 PM, Steve Litt wrote:
>
> Sounds to me like either:
>
> A) Your problem analysis was lacking, or
>
> B) The customer is willy nilly adding krap and doesn't expect you to
>    say "no".
>

I think that my description of our situation painted too rosy a
picture.  I can use the term "demo-ware" instead of prototype.  When we
sit down with $BIG_CUSTOMER and get a description of their problem, it
never describes the entire situation.  This occurs at the beginning of
the negotiation stage.

In one example, they showed us a client-server system that they use at a
production facility that requires several manual, command line
operations to complete a process that they perform regularly.  The
process was tedious and error prone, requiring hours on a weekly basis. 
We took notes and screen captures from this meeting, then returned to
our offices and quickly assembled a prototype of an automated process
using a web application that we had previously developed. 

Two weeks later we showed them a demonstration of a simple graphical
client that performed the whole process, prompted the user at each step,
and displayed progress.  They really liked it.  But at this phase in the
negotiation process, no opportunity for serious analysis had occurred. 
The demo is more of a selling tool ("we can fix this") than a foundation
for the product. 

We can't get started on that until hands have been shaken and papers signed.

Once the contract arrives, we are able to find out the full details of
the target environment.  That's when we discover things about the
communications link between the client and server system and allowable
protocols.  That's when we find out which variant of which operating
systems are in use, how the systems are firewalled, and what
applications, services, and other limitations exist. 

So the full requirements arrive well after the initial demo.

> Is that asked by the customer, or by the principals in your
> organization? If your own organization, ask them if they can
> *guarantee* that bolting stuff onto a flawed base will get done faster.
> Nobody has a crystal ball.

A fair amount of the problem is fueled by unrealistic expectations from
our own management.  We have a good development team, and we have
managed to pull rabbits out of our hats in the past by having enough of
the right pre-built products, and the ability to leverage a lot of great
free and open source code to make something that works effectively. 
Management begins to view our estimates as padded because we get done
more quickly than we expected.

What I was attempting to describe initially is that, having satisfied
$BIG_CUSTOMER a few times using this approach, they want to use us to
solve more intricate problems that a specific to their production
process.  That's where we run into problems.  The likelihood of finding
existing software products that we can crowbar into a solution begins to
fade. 

So we go to our management and say "We don't think it's going to be as
easy this time."  And management says, "Yeah, we know, but we threw 20%
more development time into our estimate."  And we reply "20% would be
reasonable if we could use the same approach that we've been using, but
we can't.  We have to create a purpose-built solution."  Then they want
to argue with us about how good we are.

> All I can say is we all feel for you, we've all been there (at least
> those of us who ever went freelance). Here is some stuff I wrote on the
> subject almost 2 decades ago. The software is very different, but the
> humanity and the principles are identical:
>
> http://troubleshooters.com/tpromag/9809.htm
>
> SteveT
>
> Steve Litt                *  http://www.troubleshooters.com/
> Troubleshooting Training  *  Human Performance
>

Thanks for making me think about this further Steve.  I hadn't really
thought of this as a "threshold" type problem before, but it's starting
to look that way.  We've been able to get solutions built quickly due to
the fact that we've been able to leverage our existing repository of
past work.  We are reaching beyond that now, and not finding as much
relevant publicly available code and information.  We haven't been doing
a good enough job of making that distinction.

   Scott C.

-- 
Scott Chilcote
scottchilcote at ncrrbiz.com
Cary, NC USA