Mark,
This can be an issue, however I think it is easily solved.
1) Use a mean between the most efficient and least efficient
programmers times, since it could be either one (and probably both) who
work on it.
In many situations, your more efficient programmer is managing your
less efficient pr
I also have a follow-up question:
Another real world constraint is that sometimes by the time the client
approves the quote, I'm involved in another project and it works better
logistically to have another programmer complete the task (or help with
it).
Since programmers are not "plug and play
Thanks for all the feedback and suggestions for improving estimation.
Based on this and other research, I expect to make a sort of "best
practices" documentation for use at my small professional services firm.
I'm thinking of including these key parts in it:
1. A checklist of things to consider w
Mark Stosberg wrote:
On Mon, 2004-11-01 at 07:45, Mark Stosberg wrote:
So, what resources are recommended to consult to make great estimates?
What habits to develop?
Thanks to everyone for all the responses. There is one theme I haven't
heard anyone mention:
The purely scientific approach that I a
Mark,
There is one theme I haven't heard anyone mention:
The purely scientific approach that I assume involves collecting a lot
o
data and using complex formulas.
I think that may be because project estimation is more akin to alchemy
and witchcraft than it is "hard science".
:)
Steve
Mark,
I think Jared and Andy both have made excellent suggestions, especially
Andy's comment about breaking it down into manageable chunks.
So, what resources are recommended to consult to make great estimates?
What habits to develop?
When I first started estimating projects I very often would ma
On 2004-11-01, chromatic <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-11-01 at 07:45, Mark Stosberg wrote:
>
>> So, what resources are recommended to consult to make great estimates?
>> What habits to develop?
>
> I have two primary rules:
>
> 1) Don't make an estimate for something I haven't done bef
On Mon, Nov 01, 2004 at 01:53:59PM -0800, Jared Rhine wrote:
> [Mark == [EMAIL PROTECTED] on Mon, 1 Nov 2004 15:45:34 + (UTC)]
>
> Mark> So, what resources are recommended to consult to make great
> Mark> estimates? What habits to develop?
>
> Estimate only what you know...
Thank you Ja
Hello List (I'm new - met Andy at the WebGUI conference in Chicago and
got inspired to signup!).
We've been pushing down to 8 hours as the max estimate, but I like
Andy's idea of pushing down to 4 hours. The 8 hours came because we
don't believe someone can accurately estimate a task of more t
Estimate with severe granularity. All estimates are a collection of
subestimates.
If you say "I can do that in 8 days", but that 8 day estimate is just
gut feel, why should the customer believe you? Why should YOU believe
you? "Well, it'll be 2 days for this, 3 days for that, and 3 days for
On Mon, 2004-11-01 at 07:45, Mark Stosberg wrote:
> So, what resources are recommended to consult to make great estimates?
> What habits to develop?
I have two primary rules:
1) Don't make an estimate for something I haven't done before.
2) Don't make an estimate for anything that'll take longer
[Mark == [EMAIL PROTECTED] on Mon, 1 Nov 2004 15:45:34 + (UTC)]
Mark> So, what resources are recommended to consult to make great
Mark> estimates? What habits to develop?
Estimate only what you know. My preferred model is to "bid" on only
"one phase at a time". During kickoff, I'll giv
--- Ovid <[EMAIL PROTECTED]> wrote:
> --- Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > So, what resources are recommended to consult to make great
> > estimates?
> > What habits to develop?
And all that writing only to notice that I only peripherally touched on
your question :)
Whoops,
Ovid
--- Mark Stosberg <[EMAIL PROTECTED]> wrote:
> So, what resources are recommended to consult to make great
> estimates?
> What habits to develop?
/me puts on his "economics" hat.
It's widely reported that the majority of "large" software projects
fail. I won't cite anything here as this is easy
Hello,
I imagine that many of you develop Perl with real world constraints--
deadlines and budgets. Whether you deliver your work internally or to an
external client, a good estimate plays an important role in the ultimate
quality of the software.
You may well have experienced working on a proj
15 matches
Mail list logo
