473,700 Members | 2,845 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Getting a coherent database brief from the client?

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
Nov 13 '05 #1
5 2216
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.
Nov 13 '05 #2
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******** *********@newsf e4-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

Nov 13 '05 #3
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*********@Se eSig.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
documentatio n 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
communicatio ns 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.


Nov 13 '05 #4
"Paul H" <no****@nospam. com> wrote in
news:le******** *********@newsf e4-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
Nov 13 '05 #5
Steve Jorgensen <no****@nospam. nospam> wrote in
news:gt******** *************** *********@4ax.c om:
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
enthusiasticall y 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
Nov 13 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
2755
by: PHPkemon | last post by:
Hi there, A few weeks ago I made a post and got an answer which seemed very logical. Here's part of the post: PHPkemon wrote: > I think I've figured out how to do the main things like storing products in
7
2297
by: Chris | last post by:
<apologies for cross-posting> Hi All, I am based in the UK and have been doing some private work for a client which involved setting up a database and scripts to search it and display results etc, all the usual stuff. The work was at about the halfway point when the client asked for a time estimate for the whole project. I sent him this and he wrote back
68
5155
by: rkusenet | last post by:
http://www.eweek.com/article2/0,1759,1820667,00.asp The database market grew by 10.3 percent in 2004, fueled largely by hunger for business intelligence and analytics, according to numbers released by the Gartner Group on Monday. With 34.1 percent of the overall market, IBM holds a slim margin over its closest competitor, Oracle Corp., which maintains 33.7 percent of the overall market. Microsoft Corp. follows up with 20 percent of...
19
5418
by: adirat | last post by:
I have read a lot on this subject on newsgroups and other access related websites on data corruption, but since we are still not able to isolate the problem – I am posting this detailed explanation of my problem: We have a 23 user environment with Windows advanced server and windows 2000 clients with access 2002 running on all clients in a FE/BE format. The problem is our database gets corrupted almost 3-6 times on a busy day (lot of...
12
1671
by: anna | last post by:
Map, generate, and maintain 50% of your .NET application code, namely your business and data objects. Use these objects in ASP.NET, Windows Forms, console or services applications. Business and Data Objects Framework -- Map objects to relational databases -- Embed SQL, stored procedure calls, and business rules -- Generate .NET components in C# and VB.NET -- Use components in your own high-traffic custom applications
5
1121
by: JRB | last post by:
I'm going to develop a single user program written in C# that will connect to a database on the local machine only. I'm thinking about using Microsoft Access for the database. My question is does each individual machine that I deploy the program on need to have Micrsoft Access actually installed, or will the program be able to access, read, write, and query without Access installed. Or do I need some kind of driver? Thanks for the feedback.
0
1667
by: Fraggle | last post by:
I am using PlaceHolders in a Repeater to generate a multi choice survey. I need a way of testing to see what the placeholder has been turned into at runtime, and reading out the data. The admin can add questions to a survey, then add possible answers to each question. Certain functions are also set, for example multi answer (display with a checkboxlist) single answer (radiolist). Also toggle the presence of an "other" selection which...
0
780
by: dphill | last post by:
Hello all I am a beginner .Net programmer so please forgive my ignorance. In brief, I am trying to read from xml file stored in a SQL database table’s field. This is what I used to create the table: CREATE TABLE Document ( DocID int IDENTITY NOT NULL, Description nvarchar(50) NOT NULL, DocumentStore xml NOT NULL,
10
2075
by: Paul H | last post by:
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...
0
8709
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8638
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9202
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9058
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8952
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
7791
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6555
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5894
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4395
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.