Extracting requirements is an art as well as a science, and from your
description, sounds as if with this client, it verges on torture for you. I
agree with the other responder that, under these circumstances, you should
only work on a time and materials basis (definitely not a "best estimate
with fixed upper limit" nor "fixed price" basis), and, if you've been doing
things so far as a "marketing effort", the time has come to contract for a
Requirements study.
Then, have a frank conversation and tell them, politely, about the
difficulties and that each "surprise" delays the project, takes your time,
and is costing them money. Do not proceed until they agree that the
Requirements Study will result in a Requirements Document, and that you will
not begin design until that Document has been reviewed, and approved by them
as the "baseline" from which the design will be done. You will have to
direct the discussion back to the subject when the client is sidetracked,
but unfortunately, you are likely to have to proceed some distance down the
sidetrack before you can determine whether it is or is not important.
Also, introduce a Change Control Procedure... where once the Baseline is
established, any change will be reviewed by you and the client, you will
estimate the impact and the price of the changes (and don't lowball the
estimates), and then they will choose to Reject the change, Defer the change
until after some other project milestone (such as delivery of the database),
or Accept it. In the latter case, the estimates will be recorded as
additions to the previously-agreed project estimates. And, as a courtesy as
well as for your own protection, you should point out the total cost of the
project including these estimates before they decide the disposition of the
change.
There are a number of more-or-less structured, more-or-less workable
approaches to gathering and documenting requirements, none of which is
sufficiently brief for a newsgroup response. One that I have used (sometime
in the late 1970s or early 1980s) is "Structured Analysis" which included
Data Flow Diagrams (DFD) -- which was taught in a course and book produced
by Yourdon, Inc.. I note that Ed Yourdon has enhanced the technique and you
can find out more by looking at his wiki at
http://yourdon.com/strucanalysis/wik...e=Introduction. I see
that a revised version of his 1989 book (written sometime after I first used
the technique... I believe our book was written by a Yourdon employee named
DeMarco) is available in PDF format via a link from the wiki. Be cautioned,
however, that learning the technique and DFD is not an "overnight read".
On the other hand, perhaps a "break in the action" or a little "quiet time"
would be beneficial, lest you get so eager to have the contract that you
inadvertently sell yourself into a "lifetime of involuntary servitude".
Larry Linson
Microsoft Access MVP
"Paul H" <pa**@nospam.comwrote in message
news:c6*********************@eclipse.net.uk...
>I am trying to get the spec for a database. The trouble is the client
frequently blurts out industry jargon, speaks insanely quickly and is
easily sidetracked. They are currently using around 30 different
spreadsheets and they want me to refine those spreadsheets in to an Access
DB. The current system is a complete mess.
My gut feeling is the project is actually fairly straightforward, but
after several meetings, emails and telephone conversations I am no closer
to "grasping" the scope of this job. I seem to be asking the same
questions over and over and getting different answers or finding another
"surprise" entity is required. In a nutshell I don't think it is unfair to
say that they are both disorganised and poor communicators.
I have started trying to diagram the database (I am new to this, but
confident with it) but it's like pulling teeth trying to reduce our
confusing conversations and mass of spreadsheets down to a simple data
flow diagram.
I want this job.
What would you do next?
Paul
