Getting a coherent database brief from the client?

[Paul H]

How do you folks get a reliable and complete brief of what is required
before development starts?

I am forever going back to a client once a project has started saying "Hang
on, now that I've started building this I realise what you want is
impossible, we'll have to do this way instead....etc.."

OK, so this is partly down to me not getting all the facts from day one, but
if the client does not give detailed, accurate instructions there is not a
lot I can do. I feel that most clients think they can show me a report or a
spreadsheet and say "Make a database out of this." and I'll wave a magic
wand and deliver.

The normal scenario for me is:

1. Meet with client to discuss requirements, I take notes and copies any
relevant data.
2. I type up what *I* believe the brief is and fax that to the client with
the quoted price.
3. I start work and find there is loads more to do than I thought

So how do I avoid this constant toing and froing during development and get
a client to write a coherent brief from the start?

Thanks.

Paul

[Steve Jorgensen]

On Mon, 24 Oct 2005 08:49:21 GMT, "Paul H" <no****@nospam.com> wrote:

How do you folks get a reliable and complete brief of what is required
before development starts?
First of all, realize that Reliable and Complete are relative quantities, not
boolean values. 100% is not theoretically possible to achieve.
I am forever going back to a client once a project has started saying "Hang
on, now that I've started building this I realise what you want is
impossible, we'll have to do this way instead....etc.."
Right. It is impossible to see either the real requirements or the real
technical issues until after trying to do what initally seemed to be right.
OK, so this is partly down to me not getting all the facts from day one, but
if the client does not give detailed, accurate instructions there is not a
lot I can do. I feel that most clients think they can show me a report or a
spreadsheet and say "Make a database out of this." and I'll wave a magic
wand and deliver.
The problematic word above is "all". Assume that the client has many
requirements that are not immediately expressible or even knowable, and plan
to do development in multiple release cycles to get everything done.
The normal scenario for me is:

1. Meet with client to discuss requirements, I take notes and copies any
relevant data.
2. I type up what *I* believe the brief is and fax that to the client with
the quoted price.
3. I start work and find there is loads more to do than I thought

So how do I avoid this constant toing and froing during development and get
a client to write a coherent brief from the start?

It's much easier for a client to tell you what they need after they can see
something that's not quite it. The client will resist any attempts to get 90%
perfect information (remember - 100% is not even possible) up front because
the effort in time and energy to do that is massive.

The best approach is to plan from the beginning to work in multiple release
cycles. You generally will not want to squeeze as much as possible into an
iteration, because the more you implement without feedback, the more you may
have rewrite.

Each release cycle should consist of items weighted towards highest business
value for the customer, and towards greatest technical risk. The highest
value weighting is obvious - you want to deliver ROI to the customer quickly,
so they can see you're worth having around, and you want the core program
design to reflect the most important aspects of its operation. The greatest
risk weighting is to reduce the problem of doing the simple stuff in a way
that doesn't take into account all the complexities that may arise, then
having to do lots of rewriting later to fix it.

Release cycle sizes need to be chosen based on how rapidly the customer can
accommodate change and how often they can make time to meet, review, and give
feedback. Iteration sizes can be as short as 2 weeks, or as long as 6 weeks.
Try not to go past 6 weeks. The longer you go without feedback, the farther
off track you can get.

Finally, remember to only give estimates to the customer of how much can be
done in how many hours, and try to let features slip from releases rather than
have release schedules slip. It's much easier to take measurements and
calibrate future estimates if release cycle sizes are absolutely fixed. Also
schedule slipping is a bad habit that leads to doing things like doubling the
time spent on a release to finish up the lowest priority item. Meanwhile, the
customer is spending more and more money without seeing a result.

[Allen Browne]

Paul, that's a great question, and one that is faced by every database
developer.

The core issue is about communication: how do you communicate with the
client to *hear* exactly all they want? How do you communiate to the client
what is included and not included in your spec/quote? The reality is that
this takes quite a bit of work.

It actually takes me 1 - 4 days to write this document that defines exactly
what the database will do, what data will be stored, what reports will be
generated, documentation, support, security, system requirements, etc, etc.
During that time, I have scripted out the data structure on paper, and buit
it in an mdb. Only then can I know for sure that what I have defined is
doable (there's no gaping holes, or unanticipated "manys"), so I know I can
fulfil what is promised and make a reasonsable estimate of the amount of
time involved in creating this database, and hence a fixed quote. The
document will be around 5000 - 10000 words in a fairly terse style. I do
charge for this "business analysis."

Although that's quite exacting, my experience is:
a) I waste less time with people who want something for nothing (so don't
want to do the analysis.)

b) This process goes a long way towards building trust with the client, who
needs to know that you are able to deliver what you promise.

c) This process helps the client think through what they really want, and
identify issues they did not think of.

d) It cuts out so much frustration and backtracking later in the project,
trying to fill in the missed areas.

e) If there are additional items the client wants later, there is no
argument about what was included and what is additional.

f) This document becomes the foundation for developing the project, i.e. you
work through all the items you specified, ticking them off, and you know
exactly whether you are on track and on time.

g) The documentation stage spells out more detail on each section, but
essentially covers the same items, so as you test and write your
documentation you are cross-referencing the original promise.

i) The original, clearly defined and comprehensive spec lays a great
foundation for on-going, clear communication with your client, that
continues through the project, deployment, and into the support phase.

j) You have empowered your client to be clear and precise in their
communications with whomever else they have to explain this project to
(board of directors, manager, finance dept, ...)

Again, this is quite a bit of work to do it this way, but the clear, open,
detailed communication is the key to lasting satisfaction and good client
relations. I'm not kidding about the work, but IMHO it's really worth the
effort.

HTH.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Paul H" <no****@nospam.com> wrote in message
news:le*****************@newsfe4-gui.ntli.net...

How do you folks get a reliable and complete brief of what is required
before development starts?

I am forever going back to a client once a project has started saying
"Hang on, now that I've started building this I realise what you want is
impossible, we'll have to do this way instead....etc.."

OK, so this is partly down to me not getting all the facts from day one,
but if the client does not give detailed, accurate instructions there is
not a lot I can do. I feel that most clients think they can show me a
report or a spreadsheet and say "Make a database out of this." and I'll
wave a magic wand and deliver.

The normal scenario for me is:

1. Meet with client to discuss requirements, I take notes and copies any
relevant data.
2. I type up what *I* believe the brief is and fax that to the client with
the quoted price.
3. I start work and find there is loads more to do than I thought

So how do I avoid this constant toing and froing during development and
get a client to write a coherent brief from the start?

Thanks.

Paul

[Steve Jorgensen]

I like everything you've said, but I'd add the same point I made in my
previous reply to Paul - this is all a lot easier and more effective if you
make sure neither you nor the client expects to cover everything in the first
pass. Gather all the infor that's pretty easy to gather, then have the client
choose a top priority subset of things that you belive can probably be done in
a specific amount of time.

Only do the detailed analysis of those things that are in the first release,
and keep the remaining items witten down for reference to bring back to the
next release planning session. Often, when you get to the next planning
session, the new set of items differs significantly from what previously
seemed to be next on the list, and that's great. It means the cyclical
approach is working to help elicit the most effective understanding of the
requirements.

On Mon, 24 Oct 2005 18:05:58 +0800, "Allen Browne"
<Al*********@SeeSig.Invalid> wrote:

Paul, that's a great question, and one that is faced by every database
developer.

The core issue is about communication: how do you communicate with the
client to *hear* exactly all they want? How do you communiate to the client
what is included and not included in your spec/quote? The reality is that
this takes quite a bit of work.

It actually takes me 1 - 4 days to write this document that defines exactly
what the database will do, what data will be stored, what reports will be
generated, documentation, support, security, system requirements, etc, etc.
During that time, I have scripted out the data structure on paper, and buit
it in an mdb. Only then can I know for sure that what I have defined is
doable (there's no gaping holes, or unanticipated "manys"), so I know I can
fulfil what is promised and make a reasonsable estimate of the amount of
time involved in creating this database, and hence a fixed quote. The
document will be around 5000 - 10000 words in a fairly terse style. I do
charge for this "business analysis."

Although that's quite exacting, my experience is:
a) I waste less time with people who want something for nothing (so don't
want to do the analysis.)

b) This process goes a long way towards building trust with the client, who
needs to know that you are able to deliver what you promise.

c) This process helps the client think through what they really want, and
identify issues they did not think of.

d) It cuts out so much frustration and backtracking later in the project,
trying to fill in the missed areas.

e) If there are additional items the client wants later, there is no
argument about what was included and what is additional.

f) This document becomes the foundation for developing the project, i.e. you
work through all the items you specified, ticking them off, and you know
exactly whether you are on track and on time.

g) The documentation stage spells out more detail on each section, but
essentially covers the same items, so as you test and write your
documentation you are cross-referencing the original promise.

i) The original, clearly defined and comprehensive spec lays a great
foundation for on-going, clear communication with your client, that
continues through the project, deployment, and into the support phase.

j) You have empowered your client to be clear and precise in their
communications with whomever else they have to explain this project to
(board of directors, manager, finance dept, ...)

Again, this is quite a bit of work to do it this way, but the clear, open,
detailed communication is the key to lasting satisfaction and good client
relations. I'm not kidding about the work, but IMHO it's really worth the
effort.

HTH.

[David W. Fenton]

"Paul H" <no****@nospam.com> wrote in
news:le*****************@newsfe4-gui.ntli.net:

How do you folks get a reliable and complete brief of what is
required before development starts?

I am forever going back to a client once a project has started
saying "Hang on, now that I've started building this I realise
what you want is impossible, we'll have to do this way
instead....etc.."
When there is no profesionally created spec to start from, you must
start with the conception that the design and implementation will be
an interative process that is exactly as you describe: you sit with
the client and get some ideas about what they want, then go and
attempt to implement what they said, You then go back to them with
what you've learned and reshape the plan. Lather, rinse, repeat.
OK, so this is partly down to me not getting all the facts from
day one, . . .
It is often the case that the "facts" aren't there to get -- clients
often haven't a clue what they want. It is often the case that they
don't know it until after they have the completed project and have
something to react to (sadly, often in the form of recognizing what
they *don't* want).
. . . but if the client does not give detailed, accurate
instructions there is not a lot I can do. I feel that most
clients think they can show me a report or a spreadsheet and say
"Make a database out of this." and I'll wave a magic wand and
deliver.
This is simply normal, in my experience. Take it as a given, and
tell the client that you will work in an iterative process to refine
the project, since you are imperfect and can't read their minds.

The upshot of this is:

1. never quote a fixed price estimate.

2. if you're not doing straight time and materials hourly billing
for the project, make sure you build in milestones where you get a
chance to reprice the project over all.

3. get your payment in installments, such as 1/3 deposit up front,
1/3 at agreed-upon "halfway" point, and 1/3 upon approval.
The normal scenario for me is:

1. Meet with client to discuss requirements, I take notes and
copies any relevant data.
2. I type up what *I* believe the brief is and fax that to the
client with the quoted price.
3. I start work and find there is loads more to do than I thought
Lather, rinse, repeat.

You go back to step 1 and go through the steps repeatedly until
everyone is happy.
So how do I avoid this constant toing and froing during
development and get a client to write a coherent brief from the
start?

In my experience, you can't, unless there are software professionals
at the client who know how to write a professional-level applciation
specification.

You have to go into the project assuming that you will constantly be
learning more about what the client wants/needs, and that you wiol
be repeatedly going back for clarification, and presenting drafts
for their approval and to get feedback.

This means that fixed-price bids are *very* dangerous, since the
project can completely change scope after the initial meeting. It's
why most Access developers won't do such projects, except for
relatively trivial cut-and-dried applicaitons.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:gt********************************@4ax.com:

I like everything you've said, but I'd add the same point I made
in my previous reply to Paul - this is all a lot easier and more
effective if you make sure neither you nor the client expects to
cover everything in the first pass. Gather all the infor that's
pretty easy to gather, then have the client choose a top priority
subset of things that you belive can probably be done in a
specific amount of time.

Only do the detailed analysis of those things that are in the
first release, and keep the remaining items witten down for
reference to bring back to the next release planning session.
Often, when you get to the next planning session, the new set of
items differs significantly from what previously seemed to be next
on the list, and that's great. It means the cyclical approach is
working to help elicit the most effective understanding of the
requirements.

I definitely agree with Steve on this one.

I have never had any detailed spec work well in the end, because too
much of it is designed in the abstract.

And many, many clients can't see the value in paying for a detailed
spec up front. In fact, I can't justify it myself, because I think
it's impossible to write a complete specification before you've
begun the work. I much prefer the approach Steve outlines, which is
to start with a general overview, then choose one area as the
starting point, and fill in the details in preparation for
designing/implementing that particular sub-module.

I would say that Allen's emphasis on communication is critical,
thouigh. My most successful projects have always been with clients
where I was working with one or two extremely smart and dedicated
people who worked very closely with me in talking through the issues
and making decisions on how to accomplish tasks.

The key point is that the client needs to understand ON THE FRONT
END that this is how it works.

And there's two sides to it -- most clients nod their heads
enthusiastically when you say this kind of thing to them in an
initial meeting but what they hear is "the developer will be
communicating with us frequently" not "we will be involved regularly
in two-way communication with the developer." I often stress that it
takes a lot of work and involvement from them for me to be able to
create something that serves their needs.

And on projects that have gone fully, it's almost always been
because I never hear back from the client and development drags to a
halt (since I'm not about to embark on the next stage of develpoment
without knowing that it's what the client needs/wants).

And, again, time and materials is always better than fixed price,
and fixed price with built-in repricing points is better than fixed
price alone.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc