Michael,
The size and scope of the project have a very direct relationship on the
ability to cost the project -- and of course the bigger the project, the
bigger the risk of a bad estimate.
I'll second the motion that requirements/design be done at either an
hourly/daily rate, a separate project, or at least a decent flat rate
proportionate to the size of the project. For a small project (few days),
the requirements phase may be a significant portion of the time; for a large
project, maybe only 10-20%. And of course development methodology and
required documentation play a huge roll.
Let's say you use Fusebox -- an hourly/daily rate for design and then a
per-fuse charge make for a fairly reliable way to estimate costs. This also
lets you cost out improvements/changes easily ("Well, adding those features
requires about 10 fuses, so at $100/fuse, I can add the feature for $1000").
Databases can also be designed in a similar way, though I'd never tell a
client that the database is "$x/table" -- but if you've designed databases,
you've got a pretty good idea of how many objects, how complex the
relationships are, etc, from the initial discussions. Building in a cushion
for inevitable changes makes sense, but I find that 25% is pretty reliably
keeping me out of debt
For (web) design, I determine the number of templates (visual templates, not
ColdFusion templates) and count the designer cost for that many pages --
which I tend to sub out. There's a basic cost for look/feel and then each
major template would be an addon.
It's crucial to build in maintenance costs, which can easily be the majority
of your direct costs. I like doubling my initial estimate to account for
maintenance and inevitable little tweaks and problems.
It's also useful to remember that if you've doing modular development, you
probably have a well-used set of application template components (eg
security, menu system, basic template/layout, etc) that become fixed costs
for you after a couple projects -- so if you lose a little on a project
designing the initial security system, but it's one that will work (at least
as a solid foundation) for other projects, you'll win over time.
Regards,
John Paul Ashenfelter
CTO/Transitionpoint
[EMAIL PROTECTED]
----- Original Message -----
From: "Michael Kear" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 7:19 AM
Subject: How do you estimate development time?
> I have a question that probably gnaws at most development houses at some
> stage - what is the process you use to estimate the number of hours
> you're going to need to complete a project?
>
>
> Do you use a method that boils down to "we had a similar job to that
> last month and that took us 55 hours and this job has that extra tricky
> bit so it'll probably take us 58 hours" or are you more scientific than
> that?
>
>
> I have to change my methodology for billing my major client from a
> hours-worked basis to a job-by-job basis which means I'm going to have
> to be more accurate in estimating how much a job is going to cost me.
>
>
> Cheers,
> Michael Kear
> Windsor, NSW, Australia
> AFP Webworks.
>
>
>
>
>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
