[thelist] Re: A Different POV

[martin.p.burns at uk.pwcglobal.com]

Memo from Martin P Burns of PricewaterhouseCoopers

-------------------- Start of message text --------------------

Hi Jay

All this is absolutely fantastic stuff.

I just wanted to throw in a couple of bones:
1) Time spent documenting work should be chargeable time - if the
    client's not paying for it, you are. And you paying for your time is A
    Bad Thing (tm).

2) That being the case, it should be part of your standard terms of
business
   & estimates

3) In producing the documentation, spotting areas of extra work is useful,
   i) As a warning to yourself and the client that it's *not* within
current scope
  ii) As a place to start the sales conversation for Phase 2 of the site
(this is why
     it's easier and more effective to retain existing clients than find
new ones).

4) A certain amount of the documentation (the skeleton at least) should be
   produced during the design phase, so you're not spending quite so
   long in post-mortem mode. And this will help your development, making
   it faster and less error-prone, both of which are Good Things(tm).

Cheers
Martin




Please respond to thelist at lists.evolt.org

Sent by:  thelist-admin at lists.evolt.org

To:   thelist at lists.evolt.org
cc:


Subject:  [thelist] Re: A Different POV


 >The ability to write and document sites/apps/code that your successor
 >can maintain and extend definitely has ROI implications ... So why do we
 >run into so few folks that understand that?

Perhaps I should write an article or series about how to make documentation
as painless as possible while explaining its benefits. Would it be
preaching to the choir? Hmmmm...[*scratching chin*] perhaps a documentation
standards thing similar to webstandards.org? <sarcasm>Nah...it would
require too much documentation!</sarcasm>


Basic Documentation should have the following sections;
Definitions - All terms that may not have an immediately recognizable
meaning in this context.
Scope of Work - An outline of what it will take to accomplish the core of
this particular project. If it ain't in this scope, charge extra for it.
Workflow Models - Descriptions of interfaces and where they go, what they
do, and what the end result is. (i.e. User clicks on link, logs in, and is
presented with an interface offering these choices. When he/she clicks on
this choice he/she is presented with this information and these choices,
and so on, and so on.)
Back-End Information - Database tables (in detail), administrative
passwords, etc.
Milestone List (Project Tracking) - can be as simple as having a list of
things which needs to be done, and a place to put the date of completion.
Could have spots for the developer and the client to initial.
Potential Mods/Adds for the Future -
This is the place to identify things seen during the development process
that can be improved, but would be considered "scope creep' if we just went
ahead and did them.
Also include flowcharts, data diagrams, workflow diagrams, etc.



--------------------- End of message text --------------------

This e-mail is sent by the above named in their
individual, non-business capacity and is not on
behalf of PricewaterhouseCoopers.

PricewaterhouseCoopers may monitor outgoing and incoming
e-mails and other telecommunications on its e-mail and
telecommunications systems.
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.