Re: signing off on Web stages?

Kind lengthy....  But I chose to include some text version examples of what
we do.  Hope they are beneficial to you.  Just too many details to keep
track of on large or complex sites.  Please excuse the rantings of a lunatic
<LOL>...   :-)

We use a series of documents - Requirements Response, based entirely on
client. Then a detailed design specifications document, which include
various person's signoff for version changes, etc...  These often have
initial Draft or screenshots and original artwork included, or in the case
of a network or application design, all the specs as denoted, or as they are
developed, etc....

These doc's usually are included in a project scope and or with a profile
that we create.  All in some way shape or form require the client
signatures, whther or not they are included in our initial contracts may
depend, but they are usually included in the proposal in some way, letting
the client know that there are specific things we address and that those
things, require their approval bwefore we continue. Actual contracts vary on
a client-by-client basis but usuall are inclusive depicting the ownership,
licensing rights, terms,etc...

By no means am I saying to use something like these without modifying to
suit your specific business.  Additionally you should consult your attorney
or legal representative before doing anything.  (Plug for Legal Beagles....)
They cost us upfront, but usually they pay significant long term dividends
in things like: peace of mind and enforceability on backend.  It also
clarifies responsibilities, requiring both the designer and the client to
express their understanding of these all too valuable issues. It just keeps
everything in order.  Everyone knows and ultimately agrees on who is doing
what, why and how.

TEXT Versions follow...
***********REQUIREMENTS RESPONSE********************

Project Name:
Project Number: 2000-22
Project Manager: Chris Moos
Contributors:
Technical Writer:
Creation Date:   01/03/2000 3:27 PM
Revision Date:  01/21/2000 9:59 AM
Revision Number: 1.1


Revision History (Table)
Date of Revision  ******Revision Reason *******Revision Number
January 18, 2000 ****Module Development Descriptions  ****1.1


Requirements Response Sign-Offs:
Product Development  Requestor(s)  Development Architect

Network Department NOC Department Security Architect



Table of Contents

Summary/ Overview 3
Internal Requirements 4
Alternative Solutions 5
Network and Hardware Architecture 6
Application and Database Architecture 7
Redundancy and Disaster Recovery 8
Preliminary Test Plan 9
Estimated Project Costs 10
Preliminary Operations Support Plan 11

**********************END REQUIREMENTS DOC**************************


********************************************
DETAILED DESIGN SPECIFICATIONS

Project Name:
Project Number:  2000-22 (We Macro this with an Auto-Numbering sequence)
Product Manager:
Project Manager: Chris Moos
Contributors:
Technical Writer:
Creation Date:   01/03/2000 3:11 PM  (Origination Date)
Revision Date:  01/21/2000 9:51 AM (Auto Updated)
Revision Number: 1.0 (We Macro this with an Auto-Numbering sequence)


Revision History
Date of Revision  Revision Reason Revision Number
(Create a Table consisting of Revision Number, Date and Purpose of Change)




Detail Design Sign-Offs: (New Signatures Required on Every Version)
Actual Derpartments or names/titles change based on how your organization is
setup)
Product Development  Client   Development Architect

Network Department NOC Department Security Architect





Table of Contents

(Depicting example pages, etc....)
1. Product Concepts 4
1.1. Product Primary Mission/Purpose - MRD Input 4
1.1.1. Customer Requirement - MRD input 4
1.1.2. Partner Requirement - MRD input 4
1.1.3. WebFLuence Requirement - IRD input 4
1.2. Product Secondary Mission/purpose - MRD input 4
1.3. Operational Concepts 4
1.4. Operational Support Environment 4
1.5. Operational Scenarios 4
2. Product Design 5
2.1. Product Architecture 5
2.2. Product architecture definition 5
2.2.1. Hardware components 5
2.2.2. Network components 5
2.2.3. Software components 5
2.2.4. Interface architecture 5
2.2.5. Systems management components 5
2.2.6. Security components 5
2.2.7. Redundancy/Fault Tolerant/Disaster Recovery components 5
2.2.8. Operational support components 5
2.2.9. Engineering support components 5
2.2.10. System Test Plan - Q/A & Product Certification plan 5
2.3. Product system/software component level definition 6
2.3.1. System/software component definition 6
2.3.2. Component characteristics 6
3. Product Test Plan 7
3.1. Test/pilot environment 7
3.1.1. Hardware Requirements 7
3.1.2. Software Requirements 7
3.1.3. Setup and installation Requirements 7
3.1.4. Test personnel Requirements 7
3.2. Product test Requirements 7
3.2.1. Product/system level testing 7
3.2.2. Component level testing 7

**********************END DETAIL DESIGN*********

***********Project Profile*****************

This one is the sample that we use to teach persons about our processes or
with new consultant Project managers, depicting to them what we want to see
within it and what we expect to have to do for it.

Client Name:
Project Name:
Proposal Name:
Contract Name:
Project Manager:
Project Start Date:
Project End Date:
Project Number:
Service Line Name:
Project Type:
Industry:
Practice:
Project Status:
Project E-mail:
Customization:
Revenue:

1. Client Contacts
List primary client contacts (name, contact phone, E-mail and address)
2. Summary of Project
Concise, one paragraph summary of the project.
2.1. Background
2.1.1. The Client
Describe the overall organization. What is its business, and what are its
main functions? What is its geographic scope?
Describe the immediate client. What is its scope of operations within the
overall organization? What specific business functions are performed?
2.1.2. The Business Challenge
Describe the business challenge and its drivers, but don't describe the
solution just yet. What did the client want to be able to do, or to do
better, or to stop doing? What factors were creating pressure for a change?
What kinds of tangible and/or intangibles benefits were sought? Use numbers
wherever possible in describing the magnitude of the problem and the
expected benefits.
2.1.3. Relationship to Other Projects
If this project is part of a multi-project engagement with the client,
briefly describe the engagement, noting that the other activities in the
engagement are described there. If this project is not part of a
multi-project engagement but is related to past or current projects for this
or other clients (e.g. follow-on, software re-use), then briefly describe
those projects.
2.2. Performance
2.2.1. Resolving the Business Problem
Describe the nature of the solution in general terms.
2.2.2. Methodology and Products
Describe the general approach used and the major products or other results
that were produced. If possible, use the table to organize all of this
information and write only a brief introduction under this heading. List all
phases not yet completed (if known), and describe the anticipated
methodology and products in each case.
The table below lists the major tasks of the project and summarizes the
major activities and deliverable(s) for each phase.


Project Task Activities Deliverables
[Task Name]x/xx - x/xx �  �
[Task Name]x/xx - x/xx �  �
[Task Name]x/xx - x/xx �  �
[Task Name]x/xx - x/xx �  �

2.3. Results
2.3.1. Principal Features of the Solution
Describe the main elements of the solution developed or recommended (or that
will eventually be delivered). Emphasize innovative features and creative,
efficient solutions to technical or intellectual challenges. If applicable,
describe the application requirements and key functionality implemented.
When necessary, link to the specific general documents (requirements
definition document, functional design document and detailed design
document).
2.3.2. Project Impact on Client's Business
Describe the tangible and/or intangible benefits the client organization
received, or is now receiving, as a result of the project. Emphasize
positive results that can be directly attributed to consultant's
involvement. Be specific and quantitative wherever possible (e.g., number of
current users, cost savings or avoidance, cycle-time reductions).


3. Appendix A - Additional Project Information
Development Environment
Include any relevant  information about the development environment required
for the project execution. Describe the development process and define
design and coding standards. Include a description of the client quality
procedures. This information will normally change from client to client and
will be dependent on physical hardware, software and networking resources.
Development Process
Coding Standards
Quality Procedures


*********END PROJECT PROFILE************************

Chris Moos
Got WebFLuence...?
M Systems Software, LLC
http://msyssoft.com
cmoos(at)msyssoft.com
U.S.A. 1-781-575-9956

.

HTML: hwg-business mailing list archives, maintained by Webmasters @ IWA