7053RE: accurate quotes was Re: [agile-usability] stories and wireframes
- Feb 28, 2010
While I see the value of your question, I think what Jon is pointing out was not an unusual situation, when the RFI was used to reveal the ‘best ideas’ from multiple vendors. The resulting RFP’s and RFQ were not much more than a combined shopping list from all the vendors who submitted. To the ‘winners’ of such contracts, the software CLIN’s were often poorly disguised lifts from the RFI’s and the RFP responses. The performance CLIN’s that used MIPS as a criteria still make me edgy. That single bogus criteria probably wasted more ink, legal time, and fruitless development than anything else that comes to mind. Here we had a marketing gimmick being accepted as a benchmarking tool. If you worked for Sperry, CDC, DEC or Wang and had IBM influencing contracts to use MIPS you knew you were going to spend a truck load of time building crap that allowed you to show your system stepping through instructions that mimicked the IBM instruction set and did not take advantage of the advances your products had in macro instruction management. Now jump back to Jon’s comments about an estimate that is supposed to be within 10% and I think Jon’s politic description of this being R&D is a sign of his restraint and maturity.
(BTW my apologies to all those who follow this group. My example is as far from stories and wireframes and UI UX as you can get, but I hope it goes to show that even those of us who dwell in the underworld of computers have usability issues!)
"Planning constantly peers into the future for indications as to where a solution may emerge."
"A Plan is a complex situation, adapting to an emerging solution."
What would define as a "R&D" project?
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Jon Kern
Sent: Sunday, February 28, 2010 1:19 PM
Subject: accurate quotes was Re: [agile-usability] stories and wireframes
well, therein lies my original reason for developing an agile process in
the early 90s... The DOD projects and government customers always seemed
to want estimates +/-X% where X was often pretty low -- like 5% or 10%.
And the projects were R&D, not "Build me another of those simple web sites."
If you get a list of requirements that are like this:
Title: simple feature name
Description: Given X, when Y, Then Z
Hours: estimated time to complete
Risk Multiplier: number like 1, 2, 3 used to multiply the hours by
You can control various parts of your process to at least give the
**illusion** of trying to be responsible at getting an accurate quote.
* Comprehensive nature of the list is inversely proportional to
order of magnitude. You want +/5%? Then you can't leave items off
* Be sure you do not have any risk levels higher than desirable --
or you have to do work to knock down the risk, or simply accept
the multiplier. Acceptable risk level is inversely proportional to
order of magnitude. You want +/5%? Then you can't leave huge swags
in your estimation process.
If you want a highly accurate quote to +/5% on a difficult R&D-like
project, then you basically have to jointly do enough up-front work
until both the client and the developer agrees to have enough
information to make an accurate quote. That's because the nature of such
development (IME) is one of discovery. Pretty hard to estimate that
which is yet to be discovered. Hence, agile methods...
Personally, I find trying to get to an accurate quote is frequently hard
to do and has little payoff. The RFP style of doing software for R&D
type of projects is often a sham. For my money, it is better to work in
the open. Iterate to a reasonable guess at what can be done within a
given budget, and then manage to it as closely as possible, allowing
changes as the business sees fit and is willing to accept.
Tim Wright said the following on 2/27/10 2:24 PM:
> what's the minimum level of up-front analysis necessary in order to------------------------------------
> give a quote that's accurate within an order of magnitude?
Yahoo! Groups Links
- << Previous post in topic Next post in topic >>