Singapore_Pics

Monday, December 21, 2009

Implementation of Information System Plan

Rationale for an Information Systems Plan
Every year, $300-700 million dollar corporations spend about 5% of their gross income on information systems and their supports. That's from about $15,000,000 to $35,000,000! A significant part of those funds support enterprise databases, a philosophy of database system applications that enable corporations to research the past, control the present, and plan for the future.
Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all.
Many enterprises do not have model-based information systems development environments that allow system designers to see the benefits of rearranging an information systems development schedule. Consequently, the questions that cannot be answered include:
• What effect will there be on the overall schedule if an information system is purchased versus developed?
• At what point does it pay to hire an abnormal quantity of contract staff to advance a schedule?
• What is the long term benefit from 4GL versus 3GL?
• Is it better to generate 3GL than to generate/use a 4GL?
• What are the real costs of distributed software development over centralized development?
If these questions were transformed and applied to any other component of a business (e.g., accounting, manufacturing, distribution and marketing), and remained unanswered, that unit's manager would surely be fired!
We not only need answers to these questions NOW!, we also need them quickly, cost effectively, and in a form that they can be modeled and changed in response to unfolding realities. This paper provides a brief review of a successful 10-step strategy that answers these questions.
Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.
This ad hoc information systems plan was possible only because all design and development was centralized, the only computer was a main-frame, and the past was acceptable prologue because budgets were ever increasing, schedules always slipping, and information was not yet part of the corporation's critical edge.
Well, today is different, really different! Budgets are decreasing, and slipped schedules are being cited as preventing business alternatives. Confounding the computing environment are different operating systems, DBMSs, development tools, telecommunications (LAN, WAN, Intra-, Inter-, and Extra-net), and distributed hard- and software.
Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring.
Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information.
Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.

Characteristics of a Quality ISP

A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.

Timely
The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.

Useable
The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.

Maintainable
The ISP must be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.

Quality
While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.

Reproducible
The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.

Whenever a proposal for the development of an ISP is created it must be assessed against these five characteristics. If any fail or not addressed in an optimum way, the entire set of funds for the development of an ISP is risked.
ISP Within the Context of the Meta data Environment
The information systems plan is the plan by which databases and information systems of the enterprise are accomplished in a timely manner. A key facility through which the ISP obtains its Adata@ is the meta data repository. The domain of the meta data repository is set forth in Figure 1, and, as seen through Figure 1, persons through their role within an organization perform functions in the accomplishment of enterprise missions, they have information needs. These information needs reflect the state of certain enterprise resources such as finance, people, and products that are known to the enterprises. The states are created through business information systems and databases.
The majority of the meta data employed to develop the ISP resides in the meta entities supporting the enterprise=s resource life cycles (see TDAN issue #7, December 1998, Resource Life Cycle Analysis), the databases and information systems, and project management. All these meta entities are depicted within the meta data repository meta model in Figure 2.


Figure 1


Figure 2

The ISP Steps
The information systems plan project determines the sequence for implementing specific information systems. The goal of the strategy is to deliver the most valuable business information at the earliest time possible in the most cost-effective manner.
The end product of the information systems project is an information systems plan (ISP). Once deployed, the information systems department can implement the plan with confidence that they are doing the correct information systems project at the right time and in the right sequence. The focus of the ISP is not one information system but the entire suite of information systems for the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.

Information Systems Plan Development Steps


1. Create the mission model
The mission model, generally shorter than 30 pages presents end-result characterizations of the essential raison d=etre of the enterprise. Missions are strategic, long range, and a-political because they are stripped of the Awho@ and the Ahow.@

2. Develop a high-level data model
The high-level data model is an Entity Relationship diagram created to meet the data needs of the mission descriptions. No attributes or keys are created.

3. Create the resource life cycles (RLC) and their nodes
Resources are drawn from both the mission descriptions and the high level data model. Resources and their life cycles are the names, descriptions and life cycles of the critical assets of the enterprise, which, when exercised achieve one or more aspect of the missions. Each enterprise resource Alives@ through its resource life cycle.

4. Allocate precedence vectors among RLC nodes
Tied together into a enablement network, the resulting resource life cycle network forms a framework of enterprise=s assets that represent an order and set of inter-resource relationships. The enterprise Alives@ through its resource life cycle network.

5. Allocate existing information systems and databases to the RLC nodes
The resource life cycle network presents a Alattice-work@onto which the Aas is@ business information systems and databases can be Aattached.@ See for example, the meta model in Figure 2. The Ato-be@ databases and information systems are similarly attached. ADifference projects@ between the Aas-is@ and the Ato-be@ are then formulated. Achievement of all the difference projects is the achievement of the Information Systems Plan.

6. Allocate standard work break down structures (WBS) to each RLC node
Detailed planning of the Adifference projects@ entails allocating the appropriate canned work breakdown structures and metrics. Employing WBS and metrics from a comprehensive methodology supports project management standardization, repeatability, and self-learning.

7. Load resources into each WBS node
Once the resources are determined, these are loaded into the project management meta entities of the meta data repository, that is, metrics, project, work plan and deliverables. The meta entities are those inferred by Figure 2.

8. Schedule the RLC nodes through a project management package facilities.
The entire suite of projects is then scheduled on an enterprise-wide basis. The PERT chart used by project management is the APERT@ chart represented by the Resource Life Cycle enablement network.

9. Produce and review of the ISP
The scheduled result is predicable: Too long, too costly, and too ambitious. At that point, the real work starts: paring down the suite of projects to a realistic set within time and budget. Because of the meta data environment (see Figure 1), the integrated project management meta data (see Figure 2), and because all projects are configured against fundamental business-rationale based designs, the results of the inevitable trade-offs can be set against business basics. Although the process is painful, the results can be justified and rationalized.

10. Execute and adjust the ISP through time.
As the ISP is set into execution, technology changes occur that affect resource loadings. In this case, only steps 6-9 need to be repeated. As work progresses, the underlying meta data built or used in steps 1-5 will also change. Because a quality ISP is Aautomated@ the recasting of the ISP should only take a week or less.

Collectively, the first nine steps take about 5000 staff hours, or about $500,000. Compared to an IS budget $15-35 million, that's only about 3.0% to 1.0%.
If the pundits are to be believed, that is, that the right information at the right time is the competitive edge, then paying for an information systems plan that is accurate, repeatable, and reliable is a small price indeed.
Executive and Adjusting the ISP Through Time
IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.
In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. Figure 3 illustrates the continuous flow process environment that supports releases. The continuous flow process environment is characterized by:
• Multiple, concurrent, but differently scheduled projects against the same enterprise resource
• Single projects that affect multiple enterprise resources
• Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources
It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.
There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:
• Need Identification
• Need Assessment
• Design
• Deployment
The box in the center is the meta data repository. Specification and impact analysis is represented through the left two processes. Implementation design and accomplishment is represented by the right two processes. Two key characteristics should be immediately apparent. First, unlike the water-fall approach, the activities do not flow one to the other. They are disjoint. In fact, they may be done by different teams, on different time schedules, and involve different quantities of products under management. In short, these four activities are independent one from the other. Their only interdependence is through the meta data repository.
The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.
Through this continuous-flow process, several unique features are present:
• All four processes are concurrently executing.
• Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
• The meta data repository is always contains all the enterprise resource specifications: current or planned. Simply put, if an enterprise resource semantic is not within the meta data repository, it is not enterprise policy.
• All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
• All documentation of all types is generated from the meta data repository.
ISP Summary
In summary, any technique employed to achieve an ISP must be accomplishable with less than 3% of the IT budget. Additionally, it must be timely, useable, maintainable, able to be iterated into a quality product, and reproducible. IT organizations, once they have completed their initial set of databases and business information systems will find themselves transformed from a project to a release environment.
The continuous flow environment then becomes the only viable alternative for moving the enterprise forward. It is precisely because of the release environment that enterprise-wide information systems plans that can be created, evolved, and maintained are essential.

Here are the steps that will help expedite the implementation of an Information System Plan:

I got this from Federal Emergency Management Agency site which will exactly help our University in implementing an Information System plan also.

Step 1 – Establish a Planning Team
There must be an individual or group in charge of developing the emergency management plan. The following is guidance for making the appointment.
Form the Team
The size of the planning team will depend on the facility's operations, requirements and resources. Usually involving a group of people is best because:
• It encourages participation and gets more people invested in the process.
• It increases the amount of time and energy participants are able to give.
• It enhances the visibility and stature of the planning process.
• It provides for a broad perspective on the issues.
Determine who can be an active member and who can serve in an advisory capacity. In most cases, one or two people will be doing the bulk of the work. At the very least, you should obtain input from all functional areas. Remember:
• Upper management
• Line management
• Labor
• Human Resources
• Engineering and maintenance
• Safety, health and environmental affairs
• Public information officer
• Security
• Community relations
• Sales and marketing
• Legal
• Finance and purchasing
Have participants appointed in writing by upper management. Their job descriptions could also reflect this assignment.
Establish Authority
Demonstrate management's commitment and promote an atmosphere of cooperation by "authorizing" the planning group to take the steps necessary to develop a plan. The group should be led by the chief executive or the plant manager. Establish a clear line of authority between group members and the group leader, though not so rigid as to prevent the free flow of ideas.
Issue a Mission Statement
Have the chief executive or plant manager issue a mission statement to demonstrate the company's commitment to emergency management. The statement should:
Define the purpose of the plan and indicate that it will involve the entire organization
Define the authority and structure of the planning group
Establish a Schedule and Budget
Establish a work schedule and planning deadlines. Timelines can be modified as priorities become more clearly defined.
Develop an initial budget for such things as research, printing, seminars, consulting services and other expenses that may be necessary during the development process.

Step 2 – Analyze Capabilities and Hazards

This step entails gathering information about current capabilities and about possible hazards and emergencies, and then conducting a vulnerability analysis to determine the facility's capabilities for handling emergencies.
Where Do You Stand Right Now?
Review Internal Plans and Policies
Documents to look for include:
• Evacuation plan
• Fire protection plan
• Safety and health program
• Environmental policies
• Security procedures
• Insurance programs
• Finance and purchasing procedures
• Plant closing policy
• Employee manuals
• Hazardous materials plan
• Process safety assessment
• Risk management plan
• Capital improvement program
• Mutual aid agreements
Meet with Outside Groups
Meet with government agencies, community organizations and utilities. Ask about potential emergencies and about plans and available resources for responding to them. Sources of information include:
• Community emergency management office
• Mayor or Community Administrator's office
• Local Emergency Planning Committee (LEPC)
• Fire Department
• Police Department
• Emergency Medical Services organizations
• American Red Cross
• National Weather Service
• Public Works Department
• Planning Commission
• Telephone companies
• Electric utilities
• Neighboring businesses
While researching potential emergencies, one facility discovered that a dam -- 50 miles away -- posed a threat to its community. The facility was able to plan accordingly.
Identify Codes and Regulations
Identify applicable Federal, State and local regulations such as:
• Occupational safety and health regulations
• Environmental regulations
• Fire codes
• Seismic safety codes
• Transportation regulations
• Zoning regulations
• Corporate policies
Identify Critical Products, Services and Operations
You'll need this information to assess the impact of potential emergencies and to determine the need for backup systems. Areas to review include:
• Company products and services and the facilities and equipment needed to produce them
• Products and services provided by suppliers, especially sole source vendors
• Lifeline services such as electrical power, water, sewer, gas, telecommunications and transportation
• Operations, equipment and personnel vital to the continued functioning of the facility
Identify Internal Resources and Capabilities
Resources and capabilities that could be needed in an emergency include:
• Personnel -- fire brigade, hazardous materials response team, emergency medical services, security, emergency management group, evacuation team, public information officer
• Equipment -- fire protection and suppression equipment, communications equipment, first aid supplies, emergency supplies, warning systems, emergency power equipment, decontamination equipment
• Facilities -- emergency operating center, media briefing area, shelter areas, first-aid stations, sanitation facilities
• Organizational capabilities -- training, evacuation plan, employee support system
• Backup systems -- arrangements with other facilities to provide for:
o Payroll
o Communications
o Production
o Customer services
o Shipping and receiving
o Information systems support
o Emergency power
o Recovery support
One way to increase response capabilities is to identify employee skills (medical, engineering, communications, foreign language) that might be needed in an emergency.
Identify External Resources
There are many external resources that could be needed in an emergency. In some cases, formal agreements may be necessary to define the facility's relationship with the following:
• Local emergency management office
• Fire Department
• Hazardous materials response organization
• Emergency medical services
• Hospitals
• Local and State police
• Community service organizations
• Utilities
• Contractors
• Suppliers of emergency equipment
• Insurance carriers
Do an Insurance Review
Meet with insurance carriers to review all policies. (See Section 2: Recovery and Restoration.)
Conduct a Vulnerability Analysis
The next step is to assess the vulnerability of your facility -- the probability and potential impact of each emergency. Use the Vulnerability Analysis Chart to guide the process, which entails assigning probabilities, estimating impact and assessing resources, using a numerical system. The lower the score the better.

Vulnerability Analysis Chart
Rate each criteria on a scale of 1 to 5 with 1 being low and 5 being high.

Type of EmergencyProbability Human Impact Property Impact Business ImpactInternal Resources External ResourcesTotal


































List Potential Emergencies
In the first column of the chart, list all emergencies that could affect your facility, including those identified by your local emergency management office. Consider both:
• Emergencies that could occur within your facility
• Emergencies that could occur in your community
Below are some other factors to consider:
Historical -- What types of emergencies have occurred in the community, at this facility and at other facilities in the area?
• Fires
• Severe weather
• Hazardous material spills
• Transportation accidents
• Earthquakes
• Hurricanes
• Tornadoes
• Terrorism
• Utility outages
Geographic -- What can happen as a result of the facility's location? Keep in mind:
• Proximity to flood plains, seismic faults and dams
• Proximity to companies that produce, store, use or transport hazardous materials
• Proximity to major transportation routes and airports
• Proximity to nuclear power plants
Technological -- What could result from a process or system failure? Possibilities include:
• Fire, explosion, hazardous materials incident
• Safety system failure
• Telecommunications failure
• Computer system failure
• Power failure
• Heating/cooling system failure
• Emergency notification system failure
Human Error -- What emergencies can be caused by employee error? Are employees trained to work safely? Do they know what to do in an emergency? Human error is the single largest cause of workplace emergencies and can result from:
• Poor training
• Poor maintenance
• Carelessness
• Misconduct
• Substance abuse
• Fatigue
Physical -- What types of emergencies could result from the design or construction of the facility? Does the physical facility enhance safety? Consider:
• The physical construction of the facility
• Hazardous processes or byproducts
• Facilities for storing combustibles
• Layout of equipment
• Lighting
• Evacuation routes and exits
• Proximity of shelter areas
Regulatory -- What emergencies or hazards are you regulated to deal with?
Analyze each potential emergency from beginning to end. Consider what could happen as a result of:
• Prohibited access to the facility
• Loss of electric power
• Communication lines down
• Ruptured gas mains
• Water damage
• Smoke damage
• Structural damage
• Air or water contamination
• Explosion
• Building collapse
• Trapped persons
• Chemical release
Estimate Probability
In the Probability column, rate the likelihood of each emergency's occurrence. This is a subjective consideration, but useful nonetheless. Use a simple scale of 1 to 5 with 1 as the lowest probability and 5 as the highest.
Assess the Potential Human Impact
Analyze the potential human impact of each emergency -- the possibility of death or injury. Assign a rating in the Human Impact column of the Vulnerability Analysis Chart. Use a 1 to 5 scale with 1 as the lowest impact and 5 as the highest.
Assess the Potential Business Impact
Consider the potential loss of market share. Assign a rating in the Business Impact column. Again, 1 is the lowest impact and 5 is the highest. Assess the impact of:
• Business interruption
• Employees unable to report to work
• Customers unable to reach facility
• Company in violation of contractual agreements
• Imposition of fines and penalties or legal costs
• Interruption of critical supplies
• Interruption of product distribution
Assess the Potential Property Impact
Consider the potential property for losses and damages. Again, assign a rating in the Property Impact column, 1 being the lowest impact and 5 being the highest. Consider:
• Cost to replace
• Cost to set up temporary replacement
• Cost to repair
A bank's vulnerability analysis concluded that a "small" fire could be as catastrophic to the business as a computer system failure. The planning group discovered that bank employees did not know how to use fire extinguishers, and that the bank lacked any kind of evacuation or emergency response system.
Assess Internal and External Resources
Next assess your resources and ability to respond. Assign a score to your Internal Resources and External Resources. The lower the score the better. To help you do this, consider each potential emergency from beginning to end and each resource that would be needed to respond. For each emergency ask these questions:
• Do we have the needed resources and capabilities to respond?
• Will external resources be able to respond to us for this emergency as quickly as we may need them, or will they have other priority areas to serve?
If the answers are yes, move on to the next assessment. If the answers are no, identify what can be done to correct the problem. For example, you may need to:
• Develop additional emergency procedures
• Conduct additional training
• Acquire additional equipment
• Establish mutual aid agreements
• Establish agreements with specialized contractors
Add the Columns
Total the scores for each emergency. The lower the score the better. While this is a subjective rating, the comparisons will help determine planning and resource priorities -- the subject of the pages to follow.
When assessing resources, remember that community emergency workers -- police, paramedics, firefighters -- will focus their response where the need is greatest. Or they may be victims themselves and be unable to respond immediately. That means response to your facility may be delayed.

Step 3 – Develop the Plan

Plan Components
Your plan should include the following basic components.
Executive Summary
The executive summary gives management a brief overview of: the purpose of the plan; the facility's emergency management policy; authorities and responsibilities of key personnel; the types of emergencies that could occur; and where response operations will be managed.
Emergency Management Elements
This section of the plan briefly describes the facility's approach to the core elements of emergency management, which are:
• Direction and control
• Communications
• Life safety
• Property protection
• Community outreach
• Recovery and restoration
• Administration and logistics
.
These elements, which are described in detail in Section 2, are the foundation for the emergency procedures that your facility will follow to protect personnel and equipment and resume operations.
Emergency Response Procedures
The procedures spell out how the facility will respond to emergencies. Whenever possible, develop them as a series of checklists that can be quickly accessed by senior management, department heads, response personnel and employees.
Determine what actions would be necessary to:
• Assess the situation
• Protect employees, customers, visitors, equipment, vital records and other assets, particularly during the first three days
• Get the business back up and running.
Specific procedures might be needed for any number of situations such as bomb threats or tornadoes, and for such functions as:
• Warning employees and customers
• Communicating with personnel and community responders
• Conducting an evacuation and accounting for all persons in the facility
• Managing response activities
• Activating and operating an emergency operations center
• Fighting fires
• Shutting down operations
• Protecting vital records
• Restoring operations
Support Documents
Documents that could be needed in an emergency include:
Emergency call lists -- lists (wallet size if possible) of all persons on and off site who would be involved in responding to an emergency, their responsibilities and their 24-hour telephone numbers
Building and site maps that indicate:
• Utility shutoffs
• Water hydrants
• Water main valves
• Water lines
• Gas main valves
• Gas lines
• Electrical cutoffs
• Electrical substations
• Storm drains
• Sewer lines
• Location of each building (include name of building, street name and number)
• Floor plans
• Alarm and enunciators
• Fire extinguishers
• Fire suppression systems
• Exits
• Stairways
• Designated escape routes
• Restricted areas
• Hazardous materials (including cleaning supplies and chemicals)
• High-value items
Resource lists -- lists of major resources (equipment, supplies, services) that could be needed in an emergency; mutual aid agreements with other companies and government agencies.
In an emergency, all personnel should know:
• What is my role?
• Where should I go?
Some facilities are required to develop:
• Emergency escape procedures and routes
• Procedures for employees who perform or shut down critical operations before an evacuation
• Procedures to account for all employees, visitors and contractors after an evacuation is completed
• Rescue and medical duties for assigned employees
• Procedures for reporting emergencies
• Names of persons or departments to be contacted for information regarding the plan
The Development Process
The following is guidance for developing the plan.
1. Identify Challenges and Prioritize Activities
Determine specific goals and milestones. Make a list of tasks to be performed, by whom and when. Determine how you will address the problem areas and resource shortfalls that were identified in the vulnerability analysis.
2. Write the Plan
Assign each member of the planning group a section to write. Determine the most appropriate format for each section.
Establish an aggressive timeline with specific goals. Provide enough time for completion of work, but not so much as to allow assignments to linger. Establish a schedule for:
o First draft
o Review
o Second draft
o Tabletop exercise
o Final draft
o Printing
o Distribution
3. Establish a Training Schedule
Have one person or department responsible for developing a training schedule for your facility. For specific ideas about training, refer to Step 4.
4. Coordinate with Outside Organizations
Meet periodically with local government agencies and community organizations. Inform appropriate government agencies that you are creating an emergency management plan. While their official approval may not be required, they will likely have valuable insights and information to offer.
Determine State and local requirements for reporting emergencies, and incorporate them into your procedures.
Determine protocols for turning control of a response over to outside agencies. Some details that may need to be worked out are:
o Which gate or entrance will responding units use?
o Where and to whom will they report?
o How will they be identified?
o How will facility personnel communicate with outside responders?
o Who will be in charge of response activities?
Determine what kind of identification authorities will require to allow your key personnel into your facility during an emergency.
Determine the needs of disabled persons and non-English-speaking personnel. For example, a blind employee could be assigned a partner in case an evacuation is necessary.
The Americans with Disabilities Act (ADA) defines a disabled person as anyone who has a physical or mental impairment that substantially limits one or more major life activities, such as seeing, hearing, walking, breathing, performing manual tasks, learning, caring for oneself or working.
Your emergency planning priorities may be influenced by government regulation. To remain in compliance you may be required to address specific emergency management functions that might otherwise be a lower priority activity for that given year.
5. Maintain Contact with Other Corporate Offices
Communicate with other offices and divisions in your company to learn:
o Their emergency notification requirements
o The conditions where mutual assistance would be necessary
o How offices will support each other in an emergency
o Names, telephone numbers and pager numbers of key personnel
Incorporate this information into your procedures.
6. Review, Conduct Training and Revise
Distribute the first draft to group members for review. Revise as needed.
For a second review, conduct a tabletop exercise with management and personnel who have a key emergency management responsibility. In a conference room setting, describe an emergency scenario and have participants discuss their responsibilities and how they would react to the situation. Based on this discussion, identify areas of confusion and overlap, and modify the plan accordingly.
7. Seek Final Approval
Arrange a briefing for the chief executive officer and senior management and obtain written approval.
8. Distribute the Plan
Place the final plan in three-ring binders and number all copies and pages. Each individual who receives a copy should be required to sign for it and be responsible for posting subsequent changes.
Determine which sections of the plan would be appropriate to show to government agencies (some sections may refer to corporate secrets or include private listings of names, telephone numbers or radio frequencies). Distribute the final plan to:
o Chief executive and senior managers
o Key members of the company's emergency response organization
o Company headquarters
o Community emergency response agencies (appropriate sections)
Have key personnel keep a copy of the plan in their homes. Inform employees about the plan and training schedule.
Consolidate emergency plans for better coordination. Stand-alone plans, such as a Spill Prevention Control and Countermeasures (SPCC) plan, fire protection plan or safety and health plan, should be incorporated into one comprehensive plan.

Step 4 - Implement the Plan

Implementation means more than simply exercising the plan during an emergency. It means acting on recommendations made during the vulnerability analysis, integrating the plan into company operations, training employees and evaluating the plan.
Integrate the Plan into Company Operations
Emergency planning must become part of the corporate culture.
Look for opportunities to build awareness; to educate and train personnel; to test procedures; to involve all levels of management, all departments and the community in the planning process; and to make emergency management part of what personnel do on a day-to-day basis.
Test How Completely The Plan Has Been Integrated By Asking:
• How well does senior management support the responsibilities outlined in the plan?
• Have emergency planning concepts been fully incorporated into the facility's accounting, personnel and financial procedures?
• How can the facility's processes for evaluating employees and defining job classifications better address emergency management responsibilities?
• Are there opportunities for distributing emergency preparedness information through corporate newsletters, employee manuals or employee mailings?
• What kinds of safety posters or other visible reminders would be helpful?
• Do personnel know what they should do in an emergency?
• How can all levels of the organization be involved in evaluating and updating the plan?
Conduct Training, Drills and Exercises
Everyone who works at or visits the facility requires some form of training. This could include periodic employee discussion sessions to review procedures, technical training in equipment use for emergency responders, evacuation drills and full-scale exercises. Below are basic considerations for developing a training plan.
1. Planning Considerations
Assign responsibility for developing a training plan. Consider the training and information needs for employees, contractors, visitors, managers and those with an emergency response role identified in the plan. Determine for a 12 month period:
o Who will be trained?
o Who will do the training?
o What training activities will be used?
o When and where each session will take place?
o How the session will be evaluated and documented?
Use the Training Drills and Exercises Chart in the appendix section to schedule training activities or create one of your own. Consider how to involve community responders in training activities.
Conduct reviews after each training activity. Involve both personnel and community responders in the evaluation process.
2. Training Activities
Training can take many forms:
o Orientation and Education Sessions - These are regularly scheduled discussion sessions to provide information, answer questions and identify needs and concerns.
o Tabletop Exercise - Members of the emergency management group meet in a conference room setting to discuss their responsibilities and how they would react to emergency scenarios. This is a cost-effective and efficient way to identify areas of overlap and confusion before conducting more demanding training activities.
o Walk-through Drill - The emergency management group and response teams actually perform their emergency response functions. This activity generally involves more people and is more thorough than a tabletop exercise.
o Functional Drills - These drills test specific functions such as medical response, emergency notifications, warning and communications procedures and equipment, though not necessarily at the same time. Personnel are asked to evaluate the systems and identify problem areas.
o Evacuation Drill - Personnel walk the evacuation route to a designated area where procedures for accounting for all personnel are tested. Participants are asked to make notes as they go along of what might become a hazard during an emergency, e.g., stairways cluttered with debris, smoke in the hallways. Plans are modified accordingly.
o Full-scale Exercise - A real-life emergency situation is simulated as closely as possible. This exercise involves company emergency response personnel, employees, management and community response organizations.
3. Employee Training
General training for all employees should address:
o Individual roles and responsibilities
o Information about threats, hazards and protective actions
o Notification, warning and communications procedures
o Means for locating family members in an emergency
o Emergency response procedures
o Evacuation, shelter and accountability procedures
o Location and use of common emergency equipment
o Emergency shutdown procedures
The scenarios developed during the vulnerability analysis can serve as the basis for training events.
OSHA training requirements are a minimum standard for many facilities that have a fire brigade, hazardous materials team, rescue team or emergency medical response team.
4. Evaluate and Modify the Plan
Conduct a formal audit of the entire plan at least once a year. Among the issues to consider are:
o How can you involve all levels of management in evaluating and updating the plan?
o Are the problem areas and resource shortfalls identified in the vulnerability analysis being sufficiently addressed?
o Does the plan reflect lessons learned from drills and actual events?
o Do members of the emergency management group and emergency response team understand their respective responsibilities? Have new members been trained?
o Does the plan reflect changes in the physical layout of the facility? Does it reflect new facility processes?
o Are photographs and other records of facility assets up to date?
o Is the facility attaining its training objectives?
o Have the hazards in the facility changed?
o Are the names, titles and telephone numbers in the plan current?
o Are steps being taken to incorporate emergency management into other facility processes?
o Have community agencies and organizations been briefed on the plan? Are they involved in evaluating the plan?
In addition to a yearly audit, evaluate and modify the plan at these times:
o After each training drill or exercise
o After each emergency
o When personnel or their responsibilities change
o When the layout or design of the facility changes
o When policies or procedures change
o Remember to brief personnel on changes to the plan.
Conduct a formal audit of the entire plan at least once a year.




References:

http://www.tdan.com/view-articles/5262
Michael M. Gorman –
Published: September 1, 1999
Published in TDAN.com September 1999
Michael, the President of Whitemarsh Information Systems Corporation, has been involved in database and DBMS for more than 40 years. Michael has been the Secretary of the ANSI Database Languages Committee for more than 30 years. This committee standardizes SQL. A full list of Whitemarsh's clients and products can be found on the website. Whitemarsh has developed a very comprehensive Metadata CASE/Repository tool, Metabase, that supports enterprise architectures, information systems planning, comprehensive data model creation and management, and interfaces with the finest code generator on the market, Clarion ( www.SoftVelocity.com). The Whitemarsh website makes available data management books, courses, workshops, methodologies, software, and metrics. Whitemarsh prices are very reasonable and are designed for the individual, the information technology organization and professional training organizations. Whitemarsh provides free use of its materials for universities/colleges. Please contact Whitemarsh for assistance in data modeling, data architecture, enterprise architecture, metadata management, and for on-site delivery of data management workshops, courses, and seminars. Our phone number is (301) 249-1142. Our email address is: mmgorman@wiscorp.com.
Recent articles by Michael M. Gorman
• Business Event Management
• Earned Value Management
• Data Semantics Management - New Book Just Announced

FEMA
http://www.fema.gov/business/guide/section1a.shtm
http://www.fema.gov/business/guide/section1b.shtm
http://www.fema.gov/business/guide/section1c.shtm
http://www.fema.gov/business/guide/section1d.shtm

FEMA has more than 3,700 full time employees. They work at FEMA headquarters in Washington D.C., at regional and area offices across the country, the Mount Weather Emergency Operations Center, and the National Emergency Training Center in Emmitsburg, Maryland. FEMA also has nearly 4,000 standby disaster assistance employees who are available for deployment after disasters. Often FEMA works in partnership with other organizations that are part of the nation's emergency management system. These partners include state and local emergency management agencies, 27 federal agencies and the American Red Cross.

Statutory Authority
Robert T. Stafford Disaster Relief and Emergency Assistance Act, PL 100-707, signed into law November 23, 1988; amended the Disaster Relief Act of 1974, PL 93-288. This Act constitutes the statutory authority for most Federal disaster response activities especially as they pertain to FEMA and FEMA programs.

U.S. Department of Homeland Security | Federal Emergency Management Agency
500 C Street SW, Washington, D.C. 20472
Disaster Assistance: (800) 621-FEMA / TTY (800) 462-7585

No comments: