By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,947 Members | 1,594 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,947 IT Pros & Developers. It's quick & easy.

Project time estimation

P: n/a
Does this sound familliar to anyone?

Regardless of the fact that you have been programming in Access for umpteen
years, you still are overly optimistic when it comes to estimating time.

The client gives you a requirement that is "obviously just another form", and
your brain does a quick calculation, saying that should take 1 to 2 hours.
You know you tend to be optimistic, so you double the average of that, and
call it 3 hours.

Now, you actually start working on the form, and find out that the form worn't
work because there's been a problem with the schema - something neither you or
the client fully understood before, but having to implement this form has
brought into sharp relief. It's a minor issue, though, so you press on, add a
field, and keep going. You hit a few more unanticipated issues, a combo box
that needs an exceptional case, so add a table with a single-row, so you can
include it in queries with special case UNIONS, build a UNION query, etc...

Now, you're only 2 hours past your estimate - not too bad. You been
programming long enough, though, that you realize you need to spot check all
code in the app that's remotely related, because even though your changes
shouldn't affect anything else, you never know 'til you check. In testing,
you find a form that worked before, and now gives an error because you added
the field where it made sense in the field order, not at the end of the list
and Josephine who worked on the app before you used a query of that table with
<tablename>.* in the select list as a combo box source which now shows the
wrong field.

Damn, you say, fix it, then realize you'd better make sure there are no more
of those, so you fire up Speed Ferret, and search the project for tblFoo.*.
You find one more of those, and fix it. Now, you're 4 hours past the
estimate, and you were going to leave for the day. The boss is still there,
though, and everything looks fine, so you demo it for the boss.

The first thing the boss does is try something you didn't do in your tests,
you didn't know she ever did, and boom, it crashes. It seems you called a
procedure you've used successfully before to resize the subform if the user
resizes the main form, but it assumes the window will open at a size at least
as big as the detail section, and the boss had maximized a window before
opening the new one, and also had the Access application window non-maximized
such that the form opened at a size smaller than the detail section...

The above scenario is fictional, but contains elements similar to what I've
often seen in real life. How do other people here make their estimates as
accurate as possible given that the unexpected will occur more often than not
in spite of our best efforts? How do you make sure that you remember to track
how your progress is relating to your estimate early enough to let the client
know the estimate is wrong and why early enough to allow them to adjust
development priorities and delivery time expectations?

Some tricks I've found:
- Break tasks up into smaller pieces - no, smaller than that <g>. If a small
piece goes over time, it's not as big a deal, and the progress rate of the
smaller tasks acts as a gauge of how real time is comparing to estimated time
on the larger tasks that contain them.
- Use some cleverness to try to make each small task something that actually
delivers a useful piece of functionality to the user, so the user can cut
functional requirements or change the spec. on remaining functionality to
balance schedule vs completeness at any time.
- When something you do that shouldn't affect anything else does affect
something else, take extra time to fix the "something else" to be
better-behaved. Even though this adversely affects the schedule for the
current task, the time is made up with interest in very short order, keeping
your average delivery rate higher. This one is hard, because there is time
pressure on you now, but not doing it is throwing away good time after bad.
Think of this as part of every job, like cleaning up the kitchen after
cooking.
- Keep a historical log of planned vs actual, so you can see what kind of
unanticipated time costs tend to be incurred on what kinds of tasks. Refer to
past logs when estimating new tasks (Just starting this one - I'll post back
when I see how it goes).
Nov 13 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Steve Jorgensen wrote:
Does this sound familliar to anyone?


Absolutely not. My projects, whether they be Access or Oracle always
are completed on time with no extra hours needed.

There's obviously something fundamentally wrong with you, Steve.

8) 8)

If I were to say the above to your face, the pressure to stop from
giggling would explode my insides.

Thanks for the tricks. I don't anything will help me. 8(

I often find thinking a great deal about how the processes are going to
work and even going through the dreary business of documenting in detail
how they will work (I'm talking over and above flow diagrams for
business process, etc, more in terms of how information function flows
from form to form, use of list box versus datasheet, what variables are
needed to pass, etc) does an amazing job of keeping me focused and
helping me ignore the time traps of "ooooh, what about doing this?"

Even so, I still often write in a schedule "forever".
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Nov 13 '05 #2

P: n/a
Steve Jorgensen wrote:
Does this sound familliar to anyone?

Regardless of the fact that you have been programming in Access for umpteen
years, you still are overly optimistic when it comes to estimating time.

The client gives you a requirement that is "obviously just another form", and
your brain does a quick calculation, saying that should take 1 to 2 hours.
You know you tend to be optimistic, so you double the average of that, and
call it 3 hours.

Now, you actually start working on the form, and find out that the form worn't
work because there's been a problem with the schema - something neither you or
the client fully understood before, but having to implement this form has
brought into sharp relief. It's a minor issue, though, so you press on, add a
field, and keep going. You hit a few more unanticipated issues, a combo box
that needs an exceptional case, so add a table with a single-row, so you can
include it in queries with special case UNIONS, build a UNION query, etc...


In the sub-contracting business a company may get the plans to put in a
pipe from point A to point B from a general contractor. Later on it is
found that there is a cement obstacle in between the two points that was
not known about/specified when the estimate was created. At this point,
a change order is created and signed off between both parties. Later on
a different toilet model is desired instead of the one in the original
contract. Again, a change order is issued. It's possible that change
orders may assist in this process you described.

But I know what you mean.
Nov 13 '05 #3

P: n/a
Steve Jorgensen <no****@nospam.nospam> wrote in
news:lf********************************@4ax.com:
The above scenario is fictional, but contains elements similar to
what I've often seen in real life. . . .
Yep, all of your snags made me giggle.
. . . How do other people here make
their estimates as accurate as possible given that the unexpected
will occur more often than not in spite of our best efforts? . . .
First off, you have to practice expectation management. Don't ever
sell an estimate to a client as anything but a really rough guess
based on not really knowing exactly what is going to be required.

I have found that taking more time to produce the estimate does
little to improve the estimate. It simply tends to reduce the size
of the range, but in my experience has not served to get me any
closer to an accurate estimate.
. . . How
do you make sure that you remember to track how your progress is
relating to your estimate early enough to let the client know the
estimate is wrong and why early enough to allow them to adjust
development priorities and delivery time expectations?


For anything that I think is going to take less than a day's work, I
don't spend much time on figuring out how long it's going to take.
If it looks like 2 hours, I estimate at 4-8 hours.

For anything that's more than a couple of days work, I make sure the
client knows what the unknowns are, and then tell them that halfway
through the estimated time I'll re-estimate.

But the key point is expectation management: an estimate is only an
estimate. You don't get made at the carpenter who estimates 8 hours
to reframe the wall, who once he's torn out the old wall finds that
the foundation is rotten and also has to be replaced. You make the
estimate based on the information you know, and some of the scope of
a project cannot be known until you've actually started the work.
Clients understand that *if* you bother to explain it to them.

I make a point of telling them that if I run into anything
significant I'll call them immediately and we'll discuss whether we
want to continue with the original plan or scale things back or go
in an entirely new direction. As long as they feel they are making
the decision about where they are spending their money, they mostly
don't seem to get too upset.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #4

P: n/a
Tim Marshall <TI****@PurplePandaChasers.Moertherium> wrote in
news:ct**********@coranto.ucs.mun.ca:
Even so, I still often write in a schedule "forever".


I have always told clients that I can have an estimate for them that
is within 10% of accuracy 1 month after completing their entire
project.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #5

P: n/a
David W. Fenton wrote:
Steve Jorgensen <no****@nospam.nospam> wrote in
news:lf********************************@4ax.com:

The above scenario is fictional, but contains elements similar to
what I've often seen in real life. . . .

Yep, all of your snags made me giggle.

. . . How do other people here make
their estimates as accurate as possible given that the unexpected
will occur more often than not in spite of our best efforts? . . .

First off, you have to practice expectation management. Don't ever
sell an estimate to a client as anything but a really rough guess
based on not really knowing exactly what is going to be required.

I have found that taking more time to produce the estimate does
little to improve the estimate. It simply tends to reduce the size
of the range, but in my experience has not served to get me any
closer to an accurate estimate.

. . . How
do you make sure that you remember to track how your progress is
relating to your estimate early enough to let the client know the
estimate is wrong and why early enough to allow them to adjust
development priorities and delivery time expectations?

For anything that I think is going to take less than a day's work, I
don't spend much time on figuring out how long it's going to take.
If it looks like 2 hours, I estimate at 4-8 hours.

For anything that's more than a couple of days work, I make sure the
client knows what the unknowns are, and then tell them that halfway
through the estimated time I'll re-estimate.

But the key point is expectation management: an estimate is only an
estimate. You don't get made at the carpenter who estimates 8 hours
to reframe the wall, who once he's torn out the old wall finds that
the foundation is rotten and also has to be replaced. You make the
estimate based on the information you know, and some of the scope of
a project cannot be known until you've actually started the work.
Clients understand that *if* you bother to explain it to them.

I make a point of telling them that if I run into anything
significant I'll call them immediately and we'll discuss whether we
want to continue with the original plan or scale things back or go
in an entirely new direction. As long as they feel they are making
the decision about where they are spending their money, they mostly
don't seem to get too upset.


That is ultimately the best approach, to directly explain the problem
to the client and keep them in the driver's seat.

I also use the "double the hours" approach because, and I guess this
may be a common trait among the majority of developers, I notoriously
underestimate the time needed for various tasks. Usually because, as
Steve stated, the internals become much more visible once you remove
the crust and inevitably find unanticipated problems.

I think one of the most appealing aspects of XP programming is the
concentration on testing which in my case seems to be the place
where I spend more time than unexpected. It would be nice if we could
do automated UI testing with Access/VBA and I know that Steve has
done some work in this area - it would be nice if there was a way
to prepare a set of common tests that could be run using the UI.

--
'---------------
'John Mishefske
'---------------
Nov 13 '05 #6

P: n/a
Hofstadter's Law

It always takes longer than you expect, even when you take into account
Hofstadter's Law.
Nov 13 '05 #7

P: n/a
My boss generally likens it to decorating, yeah will take a day to strip
the wallpaper and another day to hang the new stuff. After stripping the
wallpaper the plaster (of Paris or Dry-wall for the septics) is
crumbling, will need to re-plaster the wall. Get the old plaster off and
find rising damp, this needs treating so now we're over a week.

I have to write estimates based on everything going well, unforseen
events will have to be taken into account and when one is known (like
the rising damp above) tell the client before you proceed, better to get
an agreement for them to pay more now then try and wrangle it out of
them later like a pikey.
Nov 13 '05 #8

P: n/a
Thanks for all the respones. There seems to be a common theme in the
responses that the problem is not that some of us can't estimate well, but
that good up-front estimation is rarely possible at all, because the real
scope of work is unknowable.

I can see how management of expectation and getting the customer involved in
decision making along the way is helpful, but I can recall several clients and
customers who don't want to be bothered with details, and still expect things
to cost something like what was predicted. Perhaps, the answer in these cases
is that those are clients and jobs we can do without?

On Tue, 01 Feb 2005 08:28:38 -0800, Steve Jorgensen <no****@nospam.nospam>
wrote:
Does this sound familliar to anyone?

Regardless of the fact that you have been programming in Access for umpteen
years, you still are overly optimistic when it comes to estimating time.

....
Nov 13 '05 #9

P: n/a
John Mishefske <mi************@JUNKtds.net> wrote in
news:42**********@newspeer2.tds.net:
I think one of the most appealing aspects of XP programming is the
concentration on testing which in my case seems to be the place
where I spend more time than unexpected. It would be nice if we
could do automated UI testing with Access/VBA and I know that
Steve has done some work in this area - it would be nice if there
was a way to prepare a set of common tests that could be run using
the UI.


XP is, in my opinion, mostly worthless for the kind of programming
that an Access application is going to include, which is primarily
UI design.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

P: n/a
Steve Jorgensen <no****@nospam.nospam> wrote in
news:l7********************************@4ax.com:
Thanks for all the respones. There seems to be a common theme in
the responses that the problem is not that some of us can't
estimate well, but that good up-front estimation is rarely
possible at all, because the real scope of work is unknowable.
I can't build an accurate spec without doing as much work as it
would take to build the app. If the client is paying me for the spec
in order that the estimate be accurate, then what's left to do?

I don't know how truly large software projects ever get done, either
in the planning or the completion.
I can see how management of expectation and getting the customer
involved in decision making along the way is helpful, but I can
recall several clients and customers who don't want to be bothered
with details, and still expect things to cost something like what
was predicted. Perhaps, the answer in these cases is that those
are clients and jobs we can do without?


Build a re-negotiation point into the original schedule. This should
happen somewhere around the midway point of the original estimated
time.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #11

P: n/a
On Wed, 02 Feb 2005 21:10:33 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
John Mishefske <mi************@JUNKtds.net> wrote in
news:42**********@newspeer2.tds.net:
I think one of the most appealing aspects of XP programming is the
concentration on testing which in my case seems to be the place
where I spend more time than unexpected. It would be nice if we
could do automated UI testing with Access/VBA and I know that
Steve has done some work in this area - it would be nice if there
was a way to prepare a set of common tests that could be run using
the UI.


XP is, in my opinion, mostly worthless for the kind of programming
that an Access application is going to include, which is primarily
UI design.


Having done some real XP work now, I'd put it as "XP is only useful where the
project velocity calls for a team at least 2 or 3 programmers." XP turns out
to be possible with Access, but silly. It's easier to do XP with something
like .NET or Java, and the productivity gains of doing it that way exceed the
RAD productivity gains Access offers.

That said, I'm finding that most all of the values of XP translate well to
Access programming, even if the actual XP practices do not.

- Use note cards to document stories ( use cases / features ) to be
implemented. Keep stories of roughly equal size. Split stories that are too
large. Merge stories that are too small. A story should have a time estimate
of no longer than 1 day.
- Write stories as far ahead as you like, but don't try to prioritize
accurately anything beyond the current iteration - it'll get changed anyway.
- Work in small iterations (1 to 3 weeks) with defined time scope.
- Slip features per iteration as required, but do not slip iteration time
boxes.
- Slip features per release as required, but do not slip planned release
times.
- Support future code changes by making code simple, flexible and
well-designed, not by accounting for specific future probabilities up-front.
- Test early - test often - test thoroughly. It's vastly easier to fix a bug
before its source has become lost in the sands of time, and before other code
has been built onto the original erroneous design.
- Code in tiny cycles (minutes to 1/2 an hour), test after each cycle,
refactor after the cycle's code is working to make the code as clean as
possible. Test again after refactoring.
- Use Test Driven Development where possible if you know how (study is
required). Write automated tests as much as possible in any case. If
something about the application is hard to write an automated test for, change
the design to make that easier.
Nov 13 '05 #12

P: n/a
Steve Jorgensen <no****@nospam.nospam> wrote in
news:h2********************************@4ax.com:
- Use note cards


You're writing database applications and you're recommending using
note cards?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #13

P: n/a
On Fri, 04 Feb 2005 01:32:03 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
Steve Jorgensen <no****@nospam.nospam> wrote in
news:h2********************************@4ax.com :
- Use note cards


You're writing database applications and you're recommending using
note cards?


In the strongest possible terms - yes.

The issue is the practical, phychological, and sociological interaction with
the content. You can sit at a table with the client and handle stacks of
cards, shuffle them, write notes on them, tear them up, etc. In most cases, a
record of what has been worked on, planned vs actual, etc. eventually ends up
in a database, but for planning purposes, note cards are fantastic. Also, the
satisfaction of tearing up a card when a task is done and seeing the stack
visibly shrink one or a few times per day is viscerally satisfying.

Here's one of a hundred good note card experiences I could relate...

I've just finished a big sub-project on-site for a client, and I have a
collection of additional-item cards from the last big planning session with
the client. I also have some blue cards (things I think the client will want,
but that I have not been asked to do). The client is always very busy and
hard to pin down, so I grab the 5 or 6 most important looking cards, catch the
client in the hallway, and ask him to look at the cards and tell me his top 3
priorities.

At the end of the day, the boss has 2 of the 3 things he most wanted, and I
have some satisfying note card confetti in my waste basket.
Nov 13 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.