Help with The Inevitable Question
- Hi all.
My company are responsible for the continuing development of an 8-year
old legacy application, now weight in at >200,000 lines of VB6 (please
don't run away screaming ;). My company was responsible for the
project in the first place, it's not something we've adopted.
We do bespoke software development for external clients on a project
basis: obviously we've developed a long and intimate relationship with
this client. This system runs the vast majority of their business.
The client has now identified this system as a risk, they say because
of the ageing technology, and its relatively poor design which has
lead to a few nasty problems lately that have been hard to fix. Their
new technical director has asked us (which has fallen to me) to
prepare a presentation about how to bring this system "kicking and
screaming into the century of the fruitbat" (my term not his, with a
nod to TPratchett).
We think they've given us this opportunity because they realise we
know their system and therefore their business practically better than
they know themselves. They wanted us to evaluate the three choices of
letting the system simply carry on until it died, rewriting it from
scratch, or gradually modernising it.
I don't think a from-scratch rewrite would ever work, I favour the
gradual modernisation. If anybody disagrees, please let me know,
because I'd love to talk about it. But, my presentation is about
there, and I've tried very hard to aim it squarely at the business,
talking about ROI, Risk et al.
Here is my problem (at least the biggest I anticipate): I think that
even if I manage to convince the client of my way of thinking, the
inevitable question then is "OK, so we agree in theory with your
approach, but the system does need a complete rewrite, so what do we
tell the business about budget? We need to get the budget for all the
work, not just some of it".
Which comes right back around to the whole tenet of Scrum: Don't
budget and build all at once, do it in bits.
But I know my answer of "just get the budget for initial section X, we
can always then look at next section Y once all the parts of X have
been released, and besides we'd understand what Y would cost better by
then anyway" wouldn't be satisfactory to them.
Have people encountered this situation before? If so please can you
ps. Damn, I wanted this to be a short mail, but it's got big :(
- I agree with whatever you are saying Roy.
But these are my observations/experience:
1. Most project managers have, heard of/Used (even if
poorly)/considered, Function points.
2. Very few have heard of Use case points.
3. Almost no one has heard of COCOMO (shame)
Someone somewhere (blast my memory) has made a very valid point about
estimations showing a graph which corresponds to one of a the
economics curve of law of diminishing marginal returns. This is a
curve of estimation accuracy.vs.effort expended on arriving at the
estimate. I think lot of organisation forget that!
--- In email@example.com, Roy Morien <roymorien@...>
>COCOMO-I was found to be deficient and in need of improvement) and
> Wonderful!! Apply mathematics and metrics (COCOMO-II - because
Function Points, which look great because of the emphasis on metrics
and measurement and historical 'facts' ... and THEN ADD SOME
CONTINGENCY ... which clearly indicates that all those metrics and
measurements and estimating methods don't work very well ... and ...
ummm ... what is the measure of 'some' in that 'add some contingency'
bit?I'm sorry to be appearing to ridicule your suggestion, H. but ...
well, yes, I am ridiculing your suggestion.
>and accurate statement of requirements, and a clear contractual
> My advice to Simon would be to first ask the clients to give a full
undertaking that if it is not stated in that specification, then it
will not be included in the developed system. The client must provide
that spec in sufficient detail for you to give an estimate of
sufficient correctness. They surely are not so unreasonable as to ask
you for accuracy without them also being accurate and correct and
>and so can be pointed to as the spec., then one may ask the question
> If the existing system can be seen as being exactly what they want,
Why on earth are they asking for a rewrite?
> An interesting fact that arose from my research (albeit areasonably restricted research activity to admit to the facts) into
software estimating. I researched amongst consulting firms and
contracting firms that represented well over 50% of the local
industry in my home city; not one of them used COCOMO of any vintage,
and not one of them used Function Point Analysis, and many of the
project managers had never heard of COCOMO or Function Points. Do I
come from the real boondocks of software projects?
>+0000Subject: [scrumdevelopment] Re: Help with The Inevitable Question
> Roy Morien
> To: scrumdevelopment@...: hmeftah@...: Mon, 1 Sep 2008 09:16:55
>revamping anexisting application.You have to start from concrete
> Hi Simon,Many of my clients ask the same question. How estimate
facts: 1) your current application even it's not perfect works every
day. 2) Your application is based on VB code, therefore this code
isthe latest version of your application documentation.3) You know
all functions and methods, screens, data structure andso on.4) you
may know how long a new feature took to be designeddeveloped and
tested.For my point of view your project is quite large so you may
need aproof of concept phase to estimate time and budget. I think
your gradual revamping is a good approach, upon these 4 basicfacts
above you can estimate and budget for example section X whichwill use
that method, that class, this sort of data structure, thisdatabase
access. Use "playing cards" Scrum phase to estimate our teamvelocity
at day one.Then refine your figures by using COCOMOII analysis,
function pointsestimate and add some contingency.Good luckH. Meftah
> Are you a friend magnet? Play now to win prizes for you and your