Documentation in eGovernance

A quick guide to government officials
Governments all over the world give high priority to Good Governance initiatives. As Good Governance is a very essential factor for economic growth in general, International Financial Institutions also join hands with governments for the effective and successful implementation of good governance initiatives.

Use of Information and Communication Technology (ICT) is very essential for Good Governance. The application of ICT in Governance is termed as eGovernance. Therefore we can say ‘eGovernance is ICT assisted Good Governance’.

Since eGovernance is a vital administrative reform package, it requires flawless planning. Government or the department/ wing of a government that initiate eGovernance should have thorough understanding of the existing system and possibilities of reforms. Based on this deep understanding of the scenario, the department should frame a strong vision and mission statement. Thus the vision and mission should become the bible for planning.

We can identify all the above activities with a single technical term Documentation. Thus Documentation is the most important and primary step towards implementing an eGovernance initiative. This step requires wide range of in depth consultations with both the internal and external consultants as well as the stakeholders. The quality and success of eGovernance implementation depends on the Documentation Standards.

Major constituents of documentation and  their specifications, as generally seen, are detailed given below. Government officials who are responsible for implementation of eGovernance initiatives may find it a useful reference.

Important Constituents of Documentation are:

I. Request for Proposal (RFP)
A Request for Proposal (RFP) should contain following minimum data


 * Definitions
 * General Information (Purpose, Back Ground, Business Requirements, Issuing Office, RFP Process)
 * General Contract Items (Method of Payment, Term, Contract Management, Public Records, Confidential Information, Transition Requirements, Termination, Survival of Terms, Officials not Personally Liable, Contract Relationship, Taxes, Indemnification, Patents and copyright infringement, Subcontracting and assignment, Force Majeure, Governing Law and Severability, Entire Agreement/ Terms of Contract, Notice of Contract Effectiveness, Computer Software License, Use of Proprietary Information, Warranties, Warranty Exclusions, No Third Party Beneficiaries, Negotiations)
 * Scope of Work and Technical Specifications (Overview, Detailed Request for Services, Required Proposal Contents)
 * Cost Proposal (Incurring Cost, Cost Proposal)
 * Vendor Specifications (Lowest Responsible Bidder, Determination of Responsibility, Bidder Submission Requirements, Bonding and Insurance)
 * Response Format
 * Method of Evaluation and Award

II. Programme Management Related Documents
Programme Management Related Documents are vital to the successful implementation of any eGovernance Project. But unfortunately it is common that clients may accept the Documents, especially in Government Departments without proper study, because of various pressures such as pre-announced launching, time constraints in utilizing the funds etc. But this may lead to redesigning the project very lately causing substantial loss of effort, time and money. Therefore all efforts may be taken to explain the documents to the clients and get their views before proceeding to the implementation stage.

A. Project Management Plan

Project management is a carefully planned and organized effort to accomplish a specific (and usually) one-time effort. Project management includes developing a project plan, which includes defining project goals and objectives, specifying tasks or how goals will be achieved, what resources are need, and associating budgets and timelines for completion. It also includes implementing the project plan, along with careful controls to stay on the "critical path", that is, to ensure the plan is being managed according to plan. Project management usually follows major phases (with various titles for these phases), including feasibility study, project planning, implementation, evaluation and support/maintenance. (Program planning is usually of a broader scope than project planning, but not always.)

Necessary components of PMP are:

B. Software Requirement Specification (SRS):
 * Introduction (Overview & Scope, Reference Documents, List of abbreviations)
 * Objectives (Administrative Objectives, Technical Objectives, Cost Objectives etc)
 * Overall Organization requirement for the project
 * Management Organization and Responsibilities (Project Office, Joint oversight Group, Clients Project Leader/ Project Officer, Deputy Project Officer, Laboratory/Work Place of the Development Group, Team Leader, Deputy Leader, Project Managers, System Administrators etc
 * Sub System/ Organization Structure (The Organization is consisted of Sub Systems, especially in large projects)
 * Project Schedule and Milestones
 * Project Cost Baseline Estimates (ie yearly)
 * Project Reporting Communicating and Review

The purpose of the SRS is to produce great products in most cost-effective and less time consuming manner. An effective Software Requirement Specification is supposed to deliver the following

Accordingly great SRSs will address the following
 * Establish the basis for agreement between the customers and the suppliers on what the software product is intended for. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs.
 * Reduce the development effort and hence the cost also. Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct.
 * Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates.
 * Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured.
 * Facilitate transfer.The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers.
 * Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued production evaluation.


 * Functionality.
 * External interfaces.
 * Performance.
 * Attributes. (the portability, correctness, maintainability, security, etc.)
 * Design constraints imposed on an implementation.

According to world standards SRS should be

If SRS is taken us System Requirement Specifications, it should
 * Correct
 * Unambiguous
 * Complete
 * Consistent
 * Ranked for importance and/or stability
 * Verifiable
 * Modifiable
 * Traceable

C. Software Design Document (SDD)
 * Define the functions of the system
 * Define the Hardware / Software Functional Partitioning
 * Define the Performance Specification
 * Define the Hardware / Software Performance Partitioning
 * Define Safety Requirements
 * Define the User Interface (A good user's manual is often an overlooked part of the System specification. Many of our customers haven't even considered that this is the right time to write the user's manual.)
 * Provide Installation Drawings/Instructions.
 * Provide Interface Control Drawings

Widely accepted contents of the SDD are:


 * Introduction
 * Document Outline
 * Document Description
 * Introduction
 * System Overview
 * Design Considerations
 * Assumptions and Dependencies
 * General Constraints
 * Goals and Guidelines
 * Development Methods
 * Architectural Strategies
 * System Architecture
 * Subsystem Architecture
 * Policies and Tactics
 * Detailed System Design
 * Detailed Subsystem Design
 * Glossary
 * Bibliography

From experience it is found that, in Government Departments, an incremental approach would be most suitable. That is the software may be designed as independently workable modules and such modules may be mounted to the basic structure after necessary testing and pilot running. It will also make transition smoother as the change is gradual. It will also avoid/minimize the chances of failure

III. PPP & Revenue Model for different categories of eGovernance Applications
Public Private Partnership (PPP) Model

Government Departments may find it very difficult in purchasing certain equipments within a limited time and similarly replacing an existing one with the advent of new technology. These kinds of problems can be resolved by identifying projects where Public Private Partnership (PPP) is possible. Before marking a project under PPP, the security/ confidentiality of the data that would be processed through the system should be given consideration. If necessary care is not given in this matter at the very beginning, projects may get entangled in controversies. Separate discussions with Officials concerned and stakeholders seem to be necessary to identify such projects. Governments may be encouraged to identify and shortlist such projects for implementation on priority basis.

Revenue Model

Most often in Government Departments, one of the major reasons that make the e-Governance initiatives vulnerable is the constraint of funds. In this context Revenue Model is a suitable alternative. In the Revenue Model, depending upon the administrative and other economic factors, retrieval of implementation cost or at least the running costs can be collected by way of reasonable service charges. However the model should suggest how systematically the revenue could be collected and used for meeting the running cost. Separate discussions with Officials concerned and stakeholders seem to be necessary to identify such projects. Governments may be encouraged to identify and shortlist such projects for implementation on priority basis.

IV. Design Guidelines for Websites.
User Interface should satisfy the following minimum standards:

Home page must have following links
 * User interface must be simple. This makes system easy to use. The user should be shown only those things that she or he is supposed to see in order to accomplish a task. Special care will be taken in making sure that the user carries out the least number of interactions with application in order to execute a particular function.
 * Design must prevent the user from doing something that she/he is not supposed to do. This makes the system more desirable and easy to use. Users will be prevented from performing inappropriate tasks.
 * Aesthetics helps in increasing user productivity and the first impression of the web site. The user interface should be aesthetically pleasing.
 * In order to have a consistent navigation scheme, system must enable user to access information or perform tasks in same manner and conditions under similar conditions.
 * Static text (labels, captions) on the screen must conform to the terminology of the business that the application supports
 * Static text (labels, captions) on the screen must follow consistent naming convention, that is same label must convey same meaning at all the places.
 * Static text (labels, captions) on the screen must be concise, convincing, and unambiguous
 * Use of icons, controls for HTML forms for different purposes like accepting text input, displaying lists, displaying calendars etc. should be consistent across the web site. That is same icon will always mean the same thing, and conversely the same thing should always be represented by the same icon.
 * Link to the "Home Page" must be present on all pages.
 * User's current location and the navigation path that user followed must be displayed, with hyperlinks on each sub-path, on the screen.
 * Display data and information in a format that does not require conversion by the user and is localized to a region.
 * Do not use unsolicited graphics and windows "pop-up" to the user.
 * Whenever a user leaves the website, the user must be given a feedback clearly telling that the user is moving out of the website.


 * About Us
 * Business tag line that communicates the purpose of web site.
 * Contact Us
 * Disclaimer
 * Feedback
 * Login
 * Logout
 * Site Index
 * Site Map
 * New changes to web site must be communicated through home page.
 * Home page must introduce a user with all the topics on which a web site provides services.
 * Low graphic version for home page
 * Other available e-Governance applications required to be suitably linked to the site. Dropdown menus may be avoided, if possible, since it would cause difficulty to the aged and physically handicapped users.
 * Sufficient interactive pages/applications may be provided on the site for encouraging the usage.
 * The portal/ website should follow a well defined Security Policy for Authentication, Access rights, Delegation of Administrative Powers, Password Policy, User Accounts, Validation of content, Identity Management, Server Access Log, Cookies, Transmission Security, Encryption, Auditing, Server Hardening, Terminal Authentication, Terminal logon procedures, User Access Right on Terminals and Database

Security Firewall Standards: following standards must be ensured while deploying a firewall


 * Regular Auditing - This is required to ensure that everything is working in order.
 * Logs - Proper logs are to be maintained in order to trace any problems/security breaches, which can occur during normal operations.
 * Intrusion Detection- Firewall should be able to detect intrusion attempts.
 * Contingency Planning - In case of failure of firewall, there should be plans to recover immediately
 * Firewall Access Privileges- Access privileges should be controlled by procedures defined by the organization deploying firewall.
 * Disclosure of Internal Network Information- Internal network information must be confidential, proper measures must be taken to ensure confidentiality.
 * Posting Updates- If some updates/patches are released for the firewall they must be installed in acceptable time from the release date.
 * Monitoring Vulnerabilities- system security should be checked at regular intervals by created false attacks on the system, in order to ensure that system is secure.
 * Standard Products- standard products must be used as firewall.

Following measures should be taken for maintaining Physical Security Standards


 * Mission critical system facilities must be located in a secure location that is locked and restricted to authorized personnel only.
 * Access to "critical" computer hardware, wiring, displays and networks must be controlled by rules of least privilege.
 * System configurations (i.e., hardware, wiring, displays and networks) of "critical" systems must be documented. A formal change management process must govern installations and changes to those physical configurations.
 * A system of monitoring and auditing physical access to "critical" computer hardware, wiring, displays and networks must be implemented (e.g. badges, cameras, access logs).
 * Low and medium risk equipment should be protected by an appropriate alarm system in addition to the correct security enclosures.
 * Proper Anti Virus Security Standards

Subsequent updation and maintenance of the sites are the major concern as far as Government Departments are concerned. Generally lethargy is seen in updating the content and analyzing/ responding to the feedbacks being received. These situations required to be changed. As far as major Portals are concerned devoted editorial and development teams should be in place. Periodic Reporting and Periodic monitoring and review by higher authorities are also highly necessary.

V. Record Management, Archival and Retrieval.
Widely accepted definition of a record is: "Information created, received, and maintained as evidence and information by an organization or person in pursuance of legal obligations or in the transaction of business. "The important characteristic of a record is that it provides evidence of a specific business activity. The definition of a record is not restricted by physical format or storage medium and can include records on paper and digital files including records created and managed in structured database systems. The well being of an entire enterprise may depend upon the ability to manage records effectively. The right information must be on file and able to be retrieved at a moment's notice, otherwise the organization may face very serious competitive disadvantage. Therefore proper technology and medium required to be in place for Record Management in each organization attempting e-Governance initiative. Depending on the nature of the data being processed/ archived the implementing agency should suggest proper Record Management System. In fact Record Management is the most important Sub Project of each e-Governance initiative.

Standards in General:

Standards are means to share ideas and to establish a common understanding on a given subject for all stakeholders, which eventually helps in minimizing communication gaps and building low cost solutions. By following standards one can ensure quality, efficiency, reliability and interchangeability at economical cost. The standards framework provides everyone what he or she expects.

Standards are classified in following four categories Dear friends, I hope that above details will be helpful in planning eGovernance initiatives. I would also like to recommend a regular observation and study of best practices all over the world. Replication of best practices will reduce to the cost of implementation as well as the chances of failures.
 * Mandatory: Standards which are tried and tested and represent preferred solution.
 * Recommended: Standards which are tried and tested, but are not mandatory and/or do not represent the preferred solution.
 * Emerging: Standards, which are in line with the intended development trend, but they have not achieved a mature level.
 * Under Evaluation: Standards, which are being considered for incorporation.

eGovernance - Educator for Officials

To WikiEducator - Inda INDEX

Back to MHRM Page