How do I "finish" a project

N

natira

How do I know when I am "done" with a database and that it's time to move on
to the next project?

I know this sounds silly but I really would like to know if folks have any
"rules" for this. If I let myself, I could keep improving my current project
for a couple weeks yet, but I think it should probably only go out a few more
days so that I can move to the next one.

Any ideas? Thanks for your time!
 
J

Jeff Boyce

I'll assume that your "projects" are for the benefit of some group of users.

I tend to define when I'm "done" by when my users say I'm done. Sometimes,
though, I have to remind them that what they're asking for will cost, and
let them decide if they're willing to pay for the further improvements.

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
A

akphidelt

haha, this is a good one, because I'm in the same boat. Especially if you are
doing work for within your company. It just never stops, once people start
seeing the magic you can do they just keep coming up with more and more
ideas. And the more and more stuff they want added the greater chance for
errors and other problems.

I've just learned to say no when people ask for some ridiculous things, and
I know when my projects when the phone stops ringing for help, haha.
 
J

John W. Vinson

How do I know when I am "done" with a database and that it's time to move on
to the next project?

I know this sounds silly but I really would like to know if folks have any
"rules" for this. If I let myself, I could keep improving my current project
for a couple weeks yet, but I think it should probably only go out a few more
days so that I can move to the next one.

Any ideas? Thanks for your time!
Click to expand...

As Jeff and akphidelt say, that's a tough question. I need to get off the
newsgroups and go do some more design work on PawTrax... which I've been doing
for about nine years now!

It really depends on your work environment, but one way to think of it is that
you and your users are collaborators in an ongoing project. You might not have
the database "finished", static, never again to be improved or upgraded; in
fact you probably don't WANT to. It's important to keep "production" and
"development" separated, so you can work on new features and improvements in a
safe "sandbox", where you won't be interfering with the ongoing production use
of the database; but do so in a way that lets you offer the users the
new-improved version when it's done.

Note that to do so it is VITAL that you split the database into a "backend"
containing the tables and a "frontend" containing the user interface.
 
N

natira

Thanks so much, folks! I got a little nugget or two of good advice from all
of your posts. I really appreciate you taking the time to respond.

I'll check back again to see if there are any new "rules to live by."
 
L

Larry Linson

natira said:
How do I know when I am "done" with a database and
that it's time to move on to the next project?
Click to expand...

If you have done it using certain "modern" techniques -- starting out with
only a vague idea of where it should go and what should be in it, developing
a few days or a week, showing it to the users, getting feedback, changing,
showing, getting feedback, you may have "sold yourself into a lifetime of
involuntary servitude" and never be finished. Not only can you not refer to
any documentation of what was to be done, you can't refer (generally) to any
documentation of what _was_ done, except by digging into the application and
reading the code. Then you still have no idea if that is what _should_ have
been done.

If you are using more traditional techniques -- determining the business
requirements (needs) and documenting them, getting approval from the
sponsoring user, then architecting/designing/implementing whatever way is
best in your environment, somewhere along the way, you should have
documented "completion criteria" even if it is internal.

I have seen large commercial software implementations done by firms who
should have known better drag on approximately forever because the contract
was drawn such that "it's not done until the client says so". Either there
was a cagy client, or an incompetent contract manager at the vendor. In one
case, a little $25,000 fixed price job cost the vendor over $250,000 for
that very reason. At about the $250,000 level of expenditure, one of the
vendor's managers became a hero by talking the customer into agreeing to
completion criteria -- not agreeing that it was complete, just that it would
be, when these additional criteria were met.

Anything less that defined completion criteria leaves you at somebody else's
mercy.

If contracting, not working internally, two suggestions: (1) never, ever
take on a fixed price contract and (2) never, never, never ever take on a
best-estimate with fixed upper limit contract. Even with what seems to be
well-drawn completion criteria, you may never finish; in the first case,
there is some possibility that you might finish early and under your
development budget and make a bigger profit; in the second case, only the
client stands to benefit if you finish under budget, or if you exceed the
budget.

Larry Linson
Microsoft Office Access MVP
 
J

Jeff Boyce

Larry

Good points.

I was overly simplistic in my response. I, too, am not willing to take on
undefined, open-ended, "it ain't over 'til it's over" engagements.

On the other hand, "tell me everything you want and need now, then I'll
build it" seems to create an adversarial relationship.

My approach has been to form a partnership with my client(s) and agree first
on the general outline, then agree on the "top 5" issues, then deliver on
the "top 5" and get paid for that, then re-evaluate the next "top 5" and
whether the client wishes to continue.

The client is in control of how much MORE will get worked on (and will be
paid for).

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
Top