Prev: Managing our data
Next: Field Property Sheet Tabs; don't see
From: Armen Stein on 15 Feb 2010 00:44
On 13 Feb 2010 22:41:40 GMT, "David W. Fenton"
<XXXusenet(a)dfenton.com.invalid> wrote:

>Good article, but I still think that there's a real issue with
>estimating.

When I do presentations on managing software projects, I like to say
that writing software is easy. Estimating how long it will take is
hard.

>I have always tried to build my projects with milestones such that
>there's the initial estimate, a re-estimate at a designated midpoint
>and then a final assessment at the end of the project. My main
>problem is that the midpoint often gets schedule too early in the
>project, and a 2nd "midpoint" needs to be added.

We estimate after we get a general idea of the requirements, which
might be after a free consultation or a 30-hour Phase 0 - it depends
on the scope of the project. This is a "top down" estimate with hours
for just the various stages (design, construction, conversion,
testing, etc.)

Then we estimate the whole thing again after we've designed the
database and sketched all the screens, reports, web pages, functions,
etc. This is the "roll up" estimate. It usually occurs about 1/3 of
the way through the budget (for Access projects). This is also where
we add a contingency, because it's much more likely that we've missed
something than counted it twice. :)

>My point is that it's completely reasonable for the client to want
>hard numbers -- it's the job of a fiscally responsible manager to
>control costs. So, I give my first estimate, and re-estimate as many
>times as necessary, but I still keep in mind that I've got a range
>for a realistic final cost that has been set up by the original
>estimate (you can't estimate $2,000 and then say oh, by the way,
>it's going to be $20,000).

True. Well, not many times and keep your business going, anyway.
That's why a reasonable accurate initial estimate is so important.

>It's also a constant struggle in that the managers are seldom
>involved in the actual development process so don't understand the
>evolution of the project. It's always good to have somebody on the
>client end who is deeply involved in the development process who can
>explain the issues to the finance department (or whoever has control
>of the budget).

Yes, this is our point person, or project "champion". They have true
ownership of the project design from the client's perspective. If we
don't have a champion, or if they leave part way through, the project
will be much more difficult to deliver.

>I'm lucky on my current active projects to be dealing with
>organizations of fewer than 5 people, so I have very little of this
>problem. I really prefer these type of clients to larger
>organizations because of the direct communication and lack of
>bureaucracy. They also pay quicker!

Definitely! Smaller clients & projects are really nice. But the
bigger ones keep more people on my team busier for a longer period of
time, so they are welcome as part of the mix.

>But, yes, it's a good article. I've bookmarked it and may use it
>with future potential clients.

Thanks David, I appreciate your comments.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

From: David W. Fenton on 15 Feb 2010 23:42
Armen Stein <ArmenStein(a)removethisgmail.com> wrote in
news:p3nhn5hbavj404ulb2uj1fcott3um7tjag(a)4ax.com:

> On 13 Feb 2010 22:41:40 GMT, "David W. Fenton"
><XXXusenet(a)dfenton.com.invalid> wrote:
>
>>Good article, but I still think that there's a real issue with
>>estimating.
>
> When I do presentations on managing software projects, I like to
> say that writing software is easy. Estimating how long it will
> take is hard.

I have always said that the only time I can give an estimate that's
within 10% of accurate is 6 months after the project is
complete...and sometimes I'm not even sure about that!

>>I have always tried to build my projects with milestones such that
>>there's the initial estimate, a re-estimate at a designated
>>midpoint and then a final assessment at the end of the project. My
>>main problem is that the midpoint often gets schedule too early in
>>the project, and a 2nd "midpoint" needs to be added.
>
> We estimate after we get a general idea of the requirements, which
> might be after a free consultation or a 30-hour Phase 0 - it
> depends on the scope of the project. This is a "top down"
> estimate with hours for just the various stages (design,
> construction, conversion, testing, etc.)
>
> Then we estimate the whole thing again after we've designed the
> database and sketched all the screens, reports, web pages,
> functions, etc.

I haven't had a bottom-up app design in years. I'm usually brought
in to take over an old Access app that needs to be enhanced, fixed,
brought up to date and expanded. My newest project has data back to
1993, though I think it only started in Access with A97. My previous
big project (which lasted from May through Sept.) was an app that
was started in Access 2 in 1996, and upgraded along the way but
NEVER SIGNIFICANTLY ENHANCED over that whole time. There was a huge
backlog of needs, and the client had gotten estimates of $25k-30K to
rebuild the whole thing in some different platform (nobody wanted to
touch the Access app). I brought the project in at under $6K, and
exceeded the original conception of the project by the clients about
about 1/3 functionality and features.

It wasn't all that hard, either.

But it was one of those great projects where I was working with
really smart people who understood a lot already and had clear ideas
of what they needed and wanted, and were also allowed by their boss
to take the time necessary to work with me to get it right.

It was really a great project, and I look forward to returning to it
for a third round of smaller enhancements in the next few months (we
already did a second round in December).

So, these things are much harder to estimate, as you have to figure
out how to fix what's already there without breaking daily
functionality. I often tell clients that it's easier to build a new
house than to remodel an old one, but that doesn't mean we tear down
all the old houses and build new ones.

> This is the "roll up" estimate. It usually occurs about 1/3 of
> the way through the budget (for Access projects). This is also
> where we add a contingency, because it's much more likely that
> we've missed something than counted it twice. :)

I adjust as I go, breaking the project down into 10-20 blocks so
there's almost never any chance of any one part getting too far out
of hand. That is, there's an overall first estimate, a pilot project
to implement some new desired feature set, and then the experience
with that is used to reality-check the original high-level estimate.
It's also at that point that I have delved into the guts of the
existing app and have a pretty good idea of how rotten the plumbing
is! From then on, I find it pretty easy to accurately estimate each
of the 10-20 hour blocks, and it's only when I'm implementing
something new that I miss the mark (that happened only once in the
summer project, and I caught it early and the client decided to go
ahead and invest the extra time, because it was a high-value
feature).

It really does require incredible cooperation with the users/testers
for all of that to work, though. You know, the kind of people who
will laugh when I tell them "Attached find a zipped up database
update with an entirely new set of bugs for you to enjoy..." instead
of getting mad at me!

>>My point is that it's completely reasonable for the client to want
>>hard numbers -- it's the job of a fiscally responsible manager to
>>control costs. So, I give my first estimate, and re-estimate as
>>many times as necessary, but I still keep in mind that I've got a
>>range for a realistic final cost that has been set up by the
>>original estimate (you can't estimate $2,000 and then say oh, by
>>the way, it's going to be $20,000).
>
> True. Well, not many times and keep your business going, anyway.
> That's why a reasonable accurate initial estimate is so important.

I stress that early on, I don't have enough information to be very
accurate, so the error bars are much larger. As I learn more about
their apps and about the specifics of what they need and how their
organization works, I'm able to narrow those error bars. And I've
found the easiest way to keep things accurate is to break things
down into the smallest chunks possible. This often has the result
that you're giving a menu of modular choices that also help the
client budget (or feel like they have control over the budget), and
I've never had a client who didn't respond well to this once they
got into the swing of it.

>>It's also a constant struggle in that the managers are seldom
>>involved in the actual development process so don't understand the
>>evolution of the project. It's always good to have somebody on the
>>client end who is deeply involved in the development process who
>>can explain the issues to the finance department (or whoever has
>>control of the budget).
>
> Yes, this is our point person, or project "champion". They have
> true ownership of the project design from the client's
> perspective. If we don't have a champion, or if they leave part
> way through, the project will be much more difficult to deliver.

I had a terrible situation a few years about where a $15K project
was 2/3s paid for, and 90% complete when the project lead became
ill, went into the hospital, and never returned to work, retiring
instead. The project died with his departure, and I never got the
last payment (though my price structure was such on that project
that I didn't lose money).

I've also had a fairly large project where I'd hired outside help
and paid them out of my own pocket before getting paid, and then the
project gets killed after a management change. That was a bad time,
but at least I was making enough money that it didn't kill me. It
would definitely be a bad problem these days as I don't have that
kind of project load any longer (in the last 10 years there's been
huge downward pressure in the NYC area on hourly rates for what I
do, and I've barely managed to stay even in nominal $$, which means
I'm making less).

>>I'm lucky on my current active projects to be dealing with
>>organizations of fewer than 5 people, so I have very little of
>>this problem. I really prefer these type of clients to larger
>>organizations because of the direct communication and lack of
>>bureaucracy. They also pay quicker!
>
> Definitely! Smaller clients & projects are really nice. But the
> bigger ones keep more people on my team busier for a longer period
> of time, so they are welcome as part of the mix.

I'm a lone wolf and prefer it that way. Every time I've found
someone really stellar to work with, they've ended up getting a
full-time job and then couldn't work with me any longer! So I've
decided to only pursue projects that I can do on my own. This has
worked out pretty well, as it also means I've got nobody else
depending on me and no overhead. I would not have made it through
the last five years had I not decided to operate in that way.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: a a r o n . k e m p f on 23 Feb 2010 14:18
I think that it is immoral to charge for any work using Jet.

it's a worthless database format.

move to SQL Server / Access Data Projects if you really want to give
the best solution to your clients




On Feb 12, 4:29 am, Dan Dan the OTTR Man <maxwell....(a)gmail.com>
wrote:
> I may have an opportunity to do some freelance work on anAccessdb.
> Has anyone here done this before?  I'm wondering what I should charge
> for the service.  Do I charge by the hour or by theproject?  Any
> advice is appreciated.

From: Tony Toews [MVP] on 23 Feb 2010 15:25
"a a r o n . k e m p f @ g m a i l . c o m" <aaron.kempf(a)gmail.com>
wrote:

>I think that it is immoral to charge for any work using Jet.
>
>it's a worthless database format.
>
>move to SQL Server / Access Data Projects if you really want to give
>the best solution to your clients

ADPs have their place as a solution. As does Jet.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
From: a a r o n . k e m p f on 23 Feb 2010 17:45
Jet has no place anywhere.

Jet doesn't support _RAM_ it doesn't support _X64_ it doesn't support
multi-core processors.

-Aaron



On Feb 23, 12:25 pm, "Tony Toews [MVP]" <tto...(a)telusplanet.net>
wrote:
> "a a r o n . k e m p f @ g m a i l . c o m" <aaron.ke...(a)gmail.com>
> wrote:
>
> >I think that it is immoral to charge for any work using Jet.
>
> >it's a worthless database format.
>
> >move to SQL Server / Access Data Projects if you really want to give
> >the best solution to your clients
>
> ADPs have their place as a solution.  As does Jet.
>
> Tony
> --
> Tony Toews, Microsoft Access MVP
> Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm
> Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
> For a convenient utility to keep your users FEs and other files
>   updated seehttp://www.autofeupdater.com/
> Granite Fleet Managerhttp://www.granitefleet.com/

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Managing our data
Next: Field Property Sheet Tabs; don't see