Documentation & Training

CRM Technology has documentation experts who become part of project teams and are responsible for variety of documents starting from project documents to reference manuals. A possible list of documents in a project is mentioned below.

CRM Technology also has Trainers who co-ordinate training needs, create training schedules, manage the logistics of providing training across US and the Globe, create training material and does the classroom delivery or train internal company resources and assist them in delivering the training session.

 

Document	Audience	Description	Advice
Contract models	Other Teams	A document describing the technical interface to a system or portion of a system.
Design decisions	Developers, Maintenance Developers, Project Managers	A summary of critical decisions pertaining to design and architecture that the team made throughout development	Focus on decisions that are not obvious, which had other reasonable alternatives, or ones where you explored what initially looked like a reasonable alternative that in the end proved insufficient for your needs. The goal of this effort is to avoid needless refactoring at some point in the future or rehashing a previously made decision. Design decisions are often documented throughout other artifacts, such as system overviews and source code, although you may choose to have a separate document when appropriate to the situation.
Executive Overview	Senior Management, User Management, Project Management	A definition of the vision for the system and a summary of the current cost estimates, predicted benefits, risks, staffing estimates, and scheduled milestones.	This document is typically used to gain funding and support for your project as well as provide status updates to important project stakeholders who may not be actively involved with your project on a day-to-day basis. Have the courage to make this publicly available to everyone that should have access to it, even when it contains bad news, according to the principle
Operations documentation	Operations Staff	This documentation typically includes an indication of the dependencies that your system is involved with; the nature of its interaction with other systems, databases, and files; references to backup procedures; a list of contact points for your system and how to reach them; a summary of the availability/reliability requirements for your system; an indication of the expected load profile of your system; and troubleshooting guidelines.	Your operations dept often has a standard format for this type of documentation or at least may have good examples from other systems that they can provide you to base your document(s) on.
Project overview	Developers, Managers, Maintenance Developers, Operations Staff	A summary of critical information such as the vision for the system, primary user contacts, technologies and tools used to build the system, and the critical operating processes (some applicable to development, such as how to build the system and some applicable to production, such as how to back up data storage).  Also provides references to critical project artifacts such as the source code (the project name in the source code control system is often sufficient), where the permanent models pertaining to the system (if any) are, and where other documents (if any) are.	Keep it short and to the point, I don’t ever remember one getting beyond ten printed pages and most are less than five.   This document serves as a starting point for anyone new to the team, including maintenance developers, because it answers fundamental questions that they are likely to have.  Whenever you first share this document with anyone ask them to keep track of major issues that they were not able to easily resolve using this document, or any misinformation they discover, to provide insight into potential updates for the document.
Requirements document	Developers, Maintenance Developers,  Users, User Managers	This document defines what the system will do, summarizing or composed of requirements artifacts such as business rule definitions, use cases, user stories, or essential user interface prototypes (to name a few).
Support documentation	Support Staff	This documentation includes training materials specific to support staff; all user documentation to use as reference when solving problems; a trouble-shooting guide; escalation procedures for handling difficult problems; and a list of contact points within the maintenance team.	You will find that your support dept often has a standard escalation procedure in place, therefore you will not need to write one, and like the operations department may have standard templates or examples that you can work from.
System documentation	Maintenance Developers, Developers	The purpose of this document is to provide an overview of the system and to help people understand the system.  Common information in this document includes an overview of the technical architecture, the business architecture, and the high-level requirements for the system.  Detailed architecture and design models, or references to them, may also be included where appropriate.	System documentation helps to reduce perceived risk on the project by providing “truck insurance”, the assurance that if the development team leaves, or gets hit by a truck, that critical information about the project is left behind.  Unfortunately this is typically false insurance – if you lose someone(s) then no matter how good the documentation is you have a serious problem on your hands because new people still need to be identified, assigned to your system, and need to learn the system.  You’re much better off increasing your project’s “truck number”, the minimum number of people that if you lost them would put your project at risk, by supporting knowledge sharing practices such as Active Stakeholder Participation, Collective Ownership, and Model With Others.
User documentation	Users, User Managers	Your users may require a reference manual, a usage guide, a support guide, and even training materials.  It’s important that you distinguish between these different types of documents because the way that each one is used varies: one is for quick lookups, one is for discovering about how to work with the system, one is for how to obtain additional help, and one is for training.	Typically base the usage guide and training materials on the use cases for the system – the use cases describe how the actors work with the system, therefore they should be a very good foundation on which to base both of these documents. User documentation should be considered part of the user interface for your system and therefore should undergo usability testing.

 

 

@ 1999-2006 CRM Technology, Inc. All rights reserved. Privacy Statement, Legal Disclaimer of CRM Technology, Inc.