After the requirements have been signed off on by the userbase, more detailed, technical design documentation can be prepared. Having this general design in-hand and signed off on by your audience will prepare you for the unavoidable eventualities of users who are dissatisfied with the product or claim that the product lacks intended features.

While everyone's experiences will vary on this subject, this was the way it was done at a consulting firm I worked for. We tried to document everything up front (mistake #1), have the user sign off on them (mistake #2) and when the user wanted changes, the Project Manager had to say "You signed off on this...if you want changes it will cost you $x".

The customers would typically piss and moan about this until the sales people (weasels) would buckle under the pressure and tell our boss to tell us just to do it. This of course would lead to projects being a) overbudget (internally we would mark these extra hours as "unbillable") or b) late.

I am now pretty convinced that attempting to document things up front and having a user sign-off is not the way to go about things. They will inevitably want changes...oh...and they'll want the changes in the same amount of time as the original project.

Granted, I will write up as much documentation as I need to get the job done, but that's about it. Luckily, as an independant doing mostly sub-contracting work, I can bypass most of the issues I've had in the past and focus on what needs to be done, not what a bunch of sales weasels want. I'm starting to see the value in what the Extreme Programming people have to say although I haven't had the opportunity to try any of it yet.

mike

In reply to Re: Re: Design Documents? by mjeaton
in thread Design Documents? by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.