In-Depth

Help For the Helper

• 06/01/1999

Support organizations, both internal help desks and external customer service centers, are critical components of any Year 2000 effort. Since these groups field calls from customers and employees, they must be prepared to respond to Y2K inquiries and Y2K-related business outages.

As the Year 2000 projects are progressing, critical information needs to be captured and relayed to the support teams to prepare them for upcoming Y2K issues. These issues will not be limited to Year 2000-incidents. Issues will include migration of new applications, which the clients may find unfamiliar; remediation fixes, which may trigger untried/untested scenarios in related applications that have not had code changes; and increased call volumes as clients uncover errors in applications that share converted data. This can only occur, however, if the support and Y2K teams work together throughout the project.

The links between the support and Y2K project teams are not present in most companies. The support center is busy focusing on daily operations, fielding calls on broken printers and misrouted e-mail. The Y2K team is busy focusing on planning and implementing date fixes, outside of daily MIS workflow. Often, the Y2K team is operating as a separate MIS group, staffed by external resources, and is not incorporated into other MIS operations.

Due to the nature of their work, both of these groups operate separately from one another. Unless your company makes a conscious effort to link these groups and build relationships, the following dangers can occur:

• Inadequate planning, staffing, training
. If the support center is unaware of upcoming Y2K changes, they will not be able to adequately prepare to resolve calls on these modified platforms and applications.
• Mishandling of Y2K system failures
. If the support team is not informed about Y2K events, a Y2K system failure may be wrongly identified, mishandled, unnecessarily escalated and inappropriately documented.
• Project derailment
. Y2K projects are cross-enterprise and cross-functional endeavors. Furthermore, they have the attention of the CEO and Board of Directors. Due to the scope and visibility of these projects, any misstep by the support group will receive more scrutiny and have more consequences than general operational miscues.
• Legal consequences
. There is potential liability surrounding any Y2K event that prevents the company from delivering products or services. If the support center is not involved in business continuity and contingency planning, the way Y2K system failures are handled may inadvertently increase a company’s liability.

Year 2000 has three implications for support centers. First, the support organization needs to understand its role in the enterprise Y2K project. Second, in order to support the business effectively, the support center needs to be tightly linked to the enterprise Year 2000 project and its implementers. Third, the support center needs to evaluate its own preparedness to ensure that its systems and resources are Y2K-ready. Each of these is outlined below.

Comprehensive Year 2000 projects contain six phases. The support center’s role in each of these phases is described below.

1. Compliance Definition
. Understand how your company defines Y2K readiness and what constitutes the Y2K Project Office. Identify key MIS and business unit Y2K representatives.
2. Inventory
. Investigate how inventories were collected, and how to use this data in ongoing problem resolution and asset management.
3. Assessment/Cost-Benefit
. Learn which systems are mission-critical, when system fail dates are anticipated and how Y2K activities are prioritized.
4. Remediation
. Know the decision, schedule and roles for system replacement, remediation and standards.
5. Testing and Implementation
. Know the schedule for code changes, platform migrations and other events.
6. Business Continuity
. Be involved in contingency planning and crisis management strategies. This is particularly crucial since support centers will be the front line for any problem resolution effort.

Managing the change introduced by a Y2K project requires communication and planning. And the threat of potential litigation from hidden Y2K issues requires a legal strategy and a methodology addresses these three components of communications and planning:

1. Change Management
. Support groups must be able to identify upcoming changes, assess their impact both to the business and therefore the support center, develop appropriate response plans and monitor these changes both for due diligence and ongoing compliance.
2. Communications
. A communications strategy needs to be an ongoing part of the Year 2000 project. The support center needs general Year 2000 awareness training, as well as specific project training for upcoming changes. Additionally, the support center needs to develop system failure response plans, including inbound and outbound responses, continuity plan triggers, notification and escalation procedures and required reporting and documentation, in conjunction with the Year 2000 program office.
3. Legal and Audit
. The success of any potential Y2K litigation will hinge on the completeness and accuracy of information produced and retained from the Y2K initiative. Support centers need to ensure they are collecting and providing the appropriate documentation around any Y2K events, both project changes and system failures.

Integration, communication and planning provide an overview of ways to ensure that support centers are linked to the critical junctures of the corporation’s Year 2000 project. An equally important consideration is preparing the support center to handle all of the upcoming changes. The number and scope of changes that will occur during the Y2K project will almost inevitably be more than your company has ever gone through before. To provide perspective, consider that a Year 2000 project might have 10 to 20 times the impact on the support center that a typical system migration project would have. The support center will, of course, also have to continue to support daily operations as it manages through all these Y2K changes. Additionally, support centers need to address how their service level agreements, budgets and staffing may be affected by the increased support coverage required throughout the Year 2000 project.

Companies have typically concentrated their Y2K efforts around enterprise systems and applications. In so doing, however, many companies have overlooked issues concerning home equipment, on-site vendor systems (either networked or standalone), and end user homegrown programs (such as macros and databases). When reviewing desktop management and non-standard software policies it is important to determine how to maintain a Y2K-ready desktop environment. It is also important to consider how response times and call volumes will be impacted when support third-party contracts and service levels (i.e. break/fix) become an issue. In short, companies need to develop policies to address Y2K-related calls around these issues, since many of the above are client-managed rather than IT-managed.

For any support center, smooth problem notification and resolution is crucial. For Year 2000 issues, it is even more so, due to the potential for business disruption and liability. You need a specific system failure communications strategy before any Y2K issues arise. Each element of your communications strategy needs to be evaluated to understand how existing procedures may need to be adjusted to accommodate specific Y2K needs.

The first priority is to develop your Y2K escalation schema. Depending on how your Y2K project office and organization is structured; your Year 2000 escalation schema may need to be different than those for standard problem resolution. Ensure that your escalation schema includes key contacts, response times, client communication, SLA modification and call tracking adjustments. Other key components of your Y2K system failure communication strategy include contingency plan triggers, notification and escalation procedures and reporting and documentation requirements. Scripts should be prepared for the support team’s inbound response, outbound announcements to clients and public relations/press responses.

Across industries, Year 2000 issues will not so much spike on 1/1/2000 as they will arc over the next 12 months, depending on the date history/forecasting within systems. Some systems experience date failures now as clients try to schedule events into the year 2000. Other systems may fail well after January 1, based on month-end, quarter-end and even year-end processing. You need to understand your company’s specific fail dates to gauge your anticipated staffing needs.

While existing support organizations can be used as a base on which to build crisis management organizations, the volume and timing of issues most often requires supplemental staffing. Since your company may not be in a position to hire additional resources, you can consider supplemental staffing alternatives. Consider new shift patterns or authorizing overtime for existing staff. Internal staff sharing with other departments may help during peak call times. Also, automated tools and knowledge bases can speed problem resolution and/or provide self-service for routine inquiries.

Even as you evaluate the increased need for supplemental resources, also ensure that your current staff remains available during this crucial time. Develop retention policies for key players to ensure that critical knowledge stays in-house. Working on the Y2K project can be positioned as a career development opportunity as new technologies are introduced and project work is scheduled.

Business continuity planning defines those steps an organization must address as part of existing and operating into the Year 2000. Organizations must accept that their plans will not be flawless, that both suppliers and customers will almost certainly have issues with their systems. No organization can guarantee that they have eliminated all Year 2000 exposure… but the smart organizations will have plans to react to crises as they occur and continue to service their clients and remain operational. Business continuity planning has three goals: reduce the risk of Y2K induced failures; maintain a minimum acceptable level of service; and identify alternate resources and processes to continue operations

Achieving these goals includes business continuity planning, focused on top-down business issues; contingency planning based on bottom-up system workarounds, and short-term crisis management strategies in the event that the volume of events exceeds normal problem resolution efforts.

It is important to note that Year 2000 contingency planning differs from traditional disaster recovery. Contingency planning as it relates to disaster recovery contains procedures to create backups of existing systems and recover these systems in event of an emergency. However, if a system fails due to Y2K issues, the backup of this system will also have the same bug and will therefore fail as well. Year 2000 contingency planning needs to provide for alternative systems and procedures if the existing systems are not available.

Support groups need to be able to distinguish between Y2K-related calls and standard service calls. The caller may not know, or care, whether their issue is Y2K-related or not. The call taker, however, needs to know, needs to care and needs to know how to react accordingly.

Support organizations need to be the focal point for any business continuity planning effort. They will be the front line for any crisis management effort. As such, they need to be an integral part of any business continuity planning team; this team also needs to include both business and MIS representatives. Support areas to address include:

• How to flag Y2K issues
• Continuity plan triggers
• Phased plans for outages of varying lengths (day, week, month)
• SWAT teams for key systems/scenarios/organizations
• Support strategy for internal technical support and external customer service groups
• Scope of effort
• Call flow processes, including escalations and priorities
• Standard operating procedures
• Reporting and metrics
• Staffing

Y2K projects present unique challenges and a lot of hard work, but with the proper planning and up-front analysis, the process can be managed.

Protect Your Y2K Assets

by Joel Fleiss

Organizations worldwide have spent significant dollars to assure that their systems are Y2K compliant. This includes assessing, verifying, remediating, validating and replacing software applications, computer systems, embedded microchips, infrastructure, business partners and business processes.

The other major Y2K expenditure driving force is the protecting of one’s firm from unforeseen future legal damages. But how do we prepare our firms for future litigation? The answer, quiet simply is to document, document and then document some more your Y2K effort. The problem is that there is no consensus as to what to document. The following document list, presented in alphabetical order, should be part of any Y2K project.

Agendas. Includes time, date, meeting location, attendees and topics..

Awareness Memorandums. Any memorandum informing employees about Y2K issues.

Budgets. Y2K relevant budgets -- proposed and actual.

Business Partner Questionnaire. A question set that allows the determination of the status of a business partner’s Y2K readiness.

Business Partner Warranty Statement. A statement to be signed by your business partners assuring their Y2K compliance.

Communication. All internal e-mail, memorandums, etc., relevant to your Y2K effort.

Compliance Methodology. The methodology for ascertaining compliance for each item within each compliance area.

Contingency Plans. Usually for medium and above risk mission and business critical inventory items and business processes. Includes responsibilities, trigger dates, schedules, budgets, risk factors, etc.

Database. Includes contact data, status, compliancy methods, criticality, schedule, etc.

Date Variable Reports. For each in-house and third-party software application containing the list of "Include" and "Exclude" strings used to locate date variables and constants. It also contains a list of the actual date variables within the application and the location of where each variable/constant is referenced in the source program.

Electronic Repository Structure. The format of the directory structure used to maintain your Y2K electronic information.

Expense Reports. Y2K expense reports including actual Y2K expenditures.

Glossary. The definition of commonly used terms within your organization that are applicable to the Y2K effort.

Internet Y2K Statement. Copy of compliancy statement or Y2K status for your home page.

Inventory. All items from each compliance area. If a specific inventory item appears multiple times (a PC computer desktop), then only a single occurrence need be on the list with a count. A separate list contains where each occurrence is located, the business unit, contact, etc.

Legal Documents. Any relevant Y2K legal documents, such as a warranty statement that is used in contracts.

Master Project Plan. A list of tasks, with the subtasks, including a start date, end date, necessary resources and task dependencies.

Minutes. Includes time, date, meeting location, attendees and topics. The topics include a summary of the key points discussed and decisions made. The minutes also include a list of action items with responsibilities and action dates.

Presentations. All Y2K presentation slides and notes.

Purchase Orders. POs containing Y2K relevant information.

Reference Material. Relevant reference material used as part of your firm’s Y2K project.

Requirement’s Specification. Describes the functionality for third-party and in-house software applications. It depicts where dates are used within reports (printouts, screens, files, and input/output streams).

Risk Evaluation. A checklist evaluating the risk associated with obtaining compliance for each.

Source Program. The actual source program of an in-house application prior to and after the remediation.

Status Reports. The Y2K Project Office should provide the CIO or Vice President of MIS (or equivalent) a weekly, semi-monthly or monthly status report. Likewise each member of the Y2K Program Office provides the Y2K Program Manager a weekly status report.

Test Plan Template for Embedded Systems. Describes the test philosophy, methodology, and steps for verification.

Test Plan Template for In-house Software Applications. Describes the test philosophy, methodology, and steps for verifying that each in-house software application is compliant. Should include a sign-off section for the test engineer and witness.

Test Plan Template for Third-Party Software Applications. Describes the test philosophy, methodology, and steps for verifying that each third-party software application is compliant. Should also include a sign-off section for the test engineer and witness.

Test Reports for Embedded Systems, In-house and Third-party Software Applications. Describes the test environment for the embedded system, the in-house and third-party software applications and being tested, the test steps, expected results and actual results.

Time Sheets. All time sheets with Y2K hours expended.

User Guides. Describes how to use third-party and in-house software applications.

Third-Party Vendor Letter Template/List. Sent to all third-party software vendors. Includes a warranty statement and questionnaire to assess their Y2K readiness.

Third-Party Vendor Questionnaire. This is a set of questions that allows you to assess the status of your 3^rd-party software vendor’s Y2K readiness.

About the Author:

Joel Fleiss is President and CEO of Millennium Information Technologies, Inc (MIT). He can be reached at [email protected].