However, when I sat in my department and rummaged through papers, I could not find much except notes on discussions with the vendor and details of configuration. For instance, there was no document showing an IT plan, applications to be developed / bought, functional areas to be covered, priority of tasks and justification for the equipment and software to be bought. When I went back to the boss expressing my helplessness in the absence of documentation, he was visibly annoyed and refused to discuss further. I then spent the next three months drawing out fresh plans and submitted them for approval.

Having learnt the lesson, I made it a point to always submit a handing over report to the management whenever I left any organization, which carried details on the IT set up, current status on various tasks, pending work, and the matters that would need attention in the following six months.

Consequences of poor documentation

Proper documentation is essential at every stage of our working and it doesn’t have to wait for a specific occasion. Documentation is simply a habit and a discipline and contrary to what many think, it does not require great effort. Good practices speak of creating documentation alongside and not to wait for the entire work to be over. I have faced several embarrassing situations due to lack of documentation. In one case, my assistant misplaced documents relating to approvals and vendor negotiation thus attracting auditor’s comments for loss of control.

Failure to record discussions and agreement with users has often lead to damning arguments during implementation stages. Not documenting system specs has got many of us in trouble. Absence of software specifications or incomplete specs makes many a developer code again rather than trying to rectify an earlier program. Lack of proper recording of approvals for user rights in the user profile can be a serious lapse and may cede ground for frauds to be committed.

What constitutes documentation

Documentation involves creating documents to record details / specification / events or storing and preserving documents that are relevant. They are important for the purposes of recording details of various activities, for retaining as evidence, for documenting policies & rules, for exercising control, preserving for posterity or as instruction for work to be done. Documentation can be on any medium including paper, on disks, DVDs, or on common repositories accessible on the net.

Types of documentation

I would classify documents in the following few categories:

General: Information systems plan, IT strategy, yearly budget, and the spends against the budgets, proposals for projects and their approvals, minutes of important meetings, periodic reports to management, etc.

Commercial: Request for Proposal (RFP), Record of talks / negotiation with vendors, PO copies, correspondence, etc.

Project documents: Requirements, statement of work, scope of work (SOW), software design and functional specification, system design and functional specifications, change management, error and enhancement tracking, user test and acceptance (UTA), and end-user manuals.

Others: List of IT assets, network diagram, security policy and other policies, disaster recovery policies, and action steps, etc.

When to start

I am told by many, that Indians are poor in documentation because of the legacy of the old Vedic period when thousands of lines of verses were carried through generations just by word of mouth. I do not however believe on that theory and strongly suggest that it is matter of habit. All IT service companies and consulting houses are immaculate in their documentation as it is a requirement dictated by the contract of services they have with their customers. It is however in the end-user companies that we face this problem.

The question, when to start: well, it is ‘now’. It doesn’t matter where we begin but we have to make a start and slowly build up our repository and should not be found wanting when any crisis strikes.

Consequences of heterogeneity

Dealing with a variety of systems is sometimes a situation that we may want to avoid. While individual systems provide solutions that are closer to what units or the users want, this approach often poses problems for organizations as they struggle running and maintaining different sets of platforms. Let us look at some of these problems:

• Companies have to deal with multiple vendors making it difficult to juggle around trying to find out the vendor who provided the particular set of solution.

• They lose track of equipment and software whose warranty periods are over or those that are due for AMC renewal as different products / vendors have their own cycles of warranty/ renewal periods.

• They lose the power to negotiate based on the volume of business as the procurement is dispersed over a large number of vendors.

• It is a nightmare trying to build expertise on various platforms that the organization owns and operates.

• Exchange of knowledge and experience become difficult as different units run different systems.

Areas that need standardization

1. Hardware: I have seen companies struggle with hardware bought from various vendors, for example, servers procured from IBM, HP, Sun, and of different vintages. These may be with different business units but sometimes in the same data center. They then have to dabble with multiple operating systems making it so much more difficult for their staff to manage. As software packages have different versions for each operating environment, system administrators have to specify and designate servers with a certain operating system for each package. They are also unable to make use of technologies like virtualization, optimization tools, etc. Same is the story when people buy storage systems or network equipment from different vendors making monitoring so much more difficult.

2. Software: As far as possible, organizations should use a common software platform for the same application in various units and not have different software for any of the reasons stated above. For example, a company that I was associated with had three ERPs bought from different vendors. They already had Oracle Apps running when another business unit decided that SAP was best-suited to their line of business while the HR Dept decided to procure PeopleSoft for HR related work. As expected, the company suffered problems of integration and of consolidated reporting to the management.

3. Processes: The third element is methods and processes that are used throughout the organization. Best practices speak of standardization so that the entire organization works in a controlled fashion. Methods need to be well laid down and defined so that everyone understands it in the same way. It is best to have a few consultants and service providers who are empaneled after proper evaluation so that the business receives quality assistance on the services front.

While standardization is good, too much of it could be detrimental; it may result in bureaucracy and make the system rigid. The case being made out here is not for standardization alone but for reducing heterogeneity as well, i.e. moving into some kind of order, away from chaos.