Estimating for iterative design

21 Feb 2005 - 10:52am
9 years ago
4 replies
783 reads
Narey, Kevin
2004

I currently give time/cost estimates for iterative design based on a minimum
of two iterations of a prototype and then demonstrations to the project team
and customer. Historically I've found that this has been a problem in more
than one project area, as two iterations is usually not enough to get the
product design licked, due to unforeseen technical complexity. Costs
inevitably become an irreconcilable issue.

A world-wide corporate culture exists where, through experience alone, a
<subject matter expert> can estimate how long should be spent on <subject>.
My department has a x-functional team that has more than enough experience
as a collective and therefore I remain unconvinced about this default
approach. I understand that there's a big 'it depends' on the type of
problem and it's context, but IT projects suffer the world over from poor
estimating - not just poor/no design effort.

It's a bit of a long shot, but are there any frameworks available for
estimating design based activity in software development? I've seen COCOMO
(A software costing model), but it's very technocratic and not very designer
friendly (i.e. it doesn't even mention designers). It bases it's cost model
on the number of lines of code in a prospective application. Does anyone
else have a minimum of iterations of a prototype that they sell/propose to
the customer? What are the estimating-for-design experiences of the
community?

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

Comments

22 Feb 2005 - 4:09am
Peter Boersma
2003

Kevin wrote:
> A world-wide corporate culture exists where, through experience alone, a
> <subject matter expert> can estimate how long should be spent on
> <subject>.
> My department has a x-functional team that has more than enough experience
> as a collective and therefore I remain unconvinced about this default
> approach.

That means your team should be able to give lower and upper estimates for
their activities for simple and complex cases. These could be (over time)
confirmed by the actual times spent on projects.

> It's a bit of a long shot, but are there any frameworks available for
> estimating design based activity in software development?

Well, there's Function Point Analysis (see for example
http://www.qpmg.com/fp-intro.htm or http://www.ifpug.com/fpafund.htm) that
can be adpated to include more user centered design functions or factors.

At my company, we have set up an estimation model speadsheet that allows us
to perform an estimation. It's based on early requirements, using as input
rough numbers of use cases, numbers of screens, external applications as
well as overall factors such as familiarity with the client, the technical
environment, the need/room for usability testing, required accessibility
levels, etc.

Every year we update the built-in estimates calculations based on last
year's projects actual numbers.

If your company does similar projects all the time (we design and build
transactional web applications for a living) such an estimation spreadsheet
should be feasible.

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

22 Feb 2005 - 5:47am
Narey, Kevin
2004

Peter wrote:

> That means your team should be able to give lower and upper estimates for
their
> activities for simple and complex cases. These could be (over time)
confirmed
> by the actual times spent on projects.

Agreed. And we always do. That doesn't stop things from going awry though.
:)

>Well, there's Function Point Analysis....

Thanks for this Peter. I've seen this too, but again it's very tech-heavy
and doesn't really support, accentuate or focus on design time. I've yet to
see a software development estimation framework that accentuates the
importance of design over the coding element. I believe this would help to
prosper a design-lead focus and culture.

>At my company, we have set up an estimation model speadsheet that allows us
to
>perform an estimation. It's based on early requirements, using as input
rough numbers of use cases,
>numbers of screens, external applications as well as overall factors such
as
>familiarity with the client, the technical environment, the need/room for
usability
>testing, required accessibility levels, etc.

We very rarely get the luxury of working on Time and Materials projects;
mainly fixed cost. Design is notoriously difficult to estimate on fixed cost
projects. My current design time box caters for two major iterations of a
prototype plus demonstrations. I'd prefer it to be four or five, but
economics and culture dictate the demand, for the time being.

I've been thinking about producing an MS project plan template for design
activities that could be used to break recurring tasks down and help in
estimation. This could then be adjoined to the development effort plan. It
also gives PMs an idea of what design scope needs to be considered. Has
anyone else tried this?

>Every year we update the built-in estimates calculations based on last
year's projects actual numbers.

We use historical metrics for estimating, but the quality of the data
captured is often of low quality and therefore misleading. 'Actual numbers'
are often not 'actual' in my experience. Using previously obtained data is a
great idea in principle, but unless there is a conscious effort by all
stakeholders to adhere to making the input a quality one, it's not as
effective.

All this aside, the estimating process usually starts with sales folk and
we'll forever have to deal with the consequences of their finger in the air.

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

23 Feb 2005 - 12:01pm
Peter Boersma
2003

Kevin wrote;
> >Well, there's Function Point Analysis....
>
> Thanks for this Peter. I've seen this too, but again it's very tech-heavy
> and doesn't really support, accentuate or focus on design time.
> I've yet to
> see a software development estimation framework that accentuates the
> importance of design over the coding element. I believe this would help to
> prosper a design-lead focus and culture.

Come on! We're supposed to be the creative types right? Or, failing that,
the thinkers, the analytical types?

We can turn any tech-heavy methodology and its tools into something we can
apply, can't we? In my upcoming presentation at the IA Summit I will show
several examples of companies that have tried this, from coming up with a
list of standardized names of deliverables to complete stand-alone (and
public!) websites about the methodology.

And besides, the good thing about estimation tools that are based on
historical data is that you double your luck if you manage to get the first
foot in the door: you get to do your thing (method, deliverable) and it gets
logged for future reference. After that it's a matter of delivering on what
you promise (but that's always a good thing).

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

23 Feb 2005 - 12:30pm
Narey, Kevin
2004

Peter wrote:

>We can turn any tech-heavy methodology and its tools into something we can
apply, can't we?

I'm looking to adopt an estimating environment that encourages carte blanche
design as a platform for innovation (or as close to it as possible) Peter,
not re-hash technology-based paradigms to shoe-horn design into.
Ideological? Probably....

Function Point Analysis refers to..... well functions, many of which could
bear no [high-level] resemblance to anything else that's likely to be built
in the future, regardless if you always do the same type of work. What I'm
saying is that at the moment all the damage has been done prior to those
function points being analysed. If it supported complex design patterns,
which I'm not sure it does, then I'd explore further.

I'm not saying it's a bad way, it's quite popular I believe, but it's
generally regarded as quite costly and resource heavy and it's based on
looking at the problem from a technology component viewpoint - not the level
of design time that's required to solve the problem.

>....It's a matter of delivering on what you promise (but that's always a
good thing).

I can't argue with that :-)

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

Syndicate content Get the feed