A "project office" experience in a big organization

Introduction

This paper presents an industrial experience carried out in Italy by Getronics Consulting Italia, the Italian subsidiary of the Dutch-based Getronics, one of the world’s leading providers of Information and Communication Technology (ICT), consulting, solutions, and services.

The experience we report has been gathered in the execution of a big complex project for a large and important Italian financial institution. The main goal of the project was Y2K compliance of a large suite of programs and applications. It is important to stress that the project team members were the Customer, Getronics employees, and contractors working both at their own offices and at the Customer’s site. Therefore, a project office was implemented in order to reduce risks and improve project outcomes. The project office was composed of seven people—each one responsible for a specific role: Overall Project Management, Secretary, Integration Management, Distributed Systems Management, HW and Basic SW Management, Bank Application Expert, Consultant, Lawyer. The project lasted about one year and was terminated early 2000, hitting planned objectives and achieving considerable client’s satisfaction.

The main aim of this paper is to discuss the project office approach that was applied to manage the project; describe the approach and details of activities carried out at the customer’s site; highlight pros and cons of the approach; and report on lessons learned while dealing with this big project—with particular emphasis on the project office experience for external project management, even having control of activities assigned to customers’ personnel.

This paper will also present the risk management approach that was used. The approach allows strong integration with other project management tasks and is quite suitable for complex projects.

The Project

Customer Profile

The Customer is a limited liability cooperative company that has 520 banking outlets in 14 regions of Italy and branch offices in Luxembourg and London. It has more than 7,000 employees and over 163,000 shareholders. A full range of commercial, industrial, and individual customers are supported by a complete offer of financial and banking services.

Project Goal and Domain

It consisted in meeting the challenges issued by the Year 2000 problem covering all the impacted domains: application and embedded systems, network infrastructure, insurance, and legal risks (including credit and liquidity).

Hereunder some information concerning IT Department architecture and portfolio:

• Three-level architecture: mainframe, midrange (HP, AS/400), and PC (more than 1,000 servers and 6,000 clients)

• Application portfolio: 170 business applications with 42,000 programs and modules (45% of sw packages)

• Total estimated effort: 320 man months provided for IT Department (2/3) and other Functions activities (1/3)

• Contractors involvement: more than 25% of total effort assigned to external resources for hw and sw remediation

• Y2K impact analysis result: more than 20% of sw applications potentially affected by the “millennium bug”

Process Model

Exhibit 1 illustrates the process model adopted for the Y2K project. Let’s look more closely at the aim of each process:

Project and Risk Management: Ensuring project goals (time, cost, quality) through the Master Plan definition, and the Risk Register continuous monitoring. Weekly Status Reports and global Contingency Plan were also performed within this context.

Assessment: Providing with a comprehensive overview of the Y2K situation, highlighting areas of significant risk and evaluating the readiness of the organization of manage those risks. The process was repeated also two months before the end of the year 1999.

Planning: Providing Execution Plans (who, what, and when) for the Project Teams on the basis of assessment results. In the same context, Test and Rollout Plans are developed for each impacted application/subsystem.

Execution: Remediating, renovating or retiring hw/sw Components on the basis of Execution Plans’ specifications. This process was completely performed by Customer’s and Contractors’ resources with the support of tools for automatic programs remediation.

Testing:Validating hw/sw Components by executing elaboration processes on “critical dates” (end of 1999 / beginning of 2000, 29th February, Easter 2000). The process was supported by tools for simulation of dates and regression testing (automatic comparison between ante/post 2000 outputs).

Exhibit 1. Process Model Applied for Y2K Project

Process Model Applied for Y2K Project

Exhibit 2. Experience Base Support for Project Teams

Experience Base Support for Project Teams

Rollout: Transferring applications into production environment on the basis of Rollout Plans. Due to the remediation technique adopted (called “windowing”), this process was performed progressively during the year 1999 reducing risks and service level regression.

Process and Product Monitoring: Supporting Project Teams in different ways: administrative support (tracking the change process, activities status reporting, meeting agendas, etc.), technical support (test design and reporting, mentoring on risk analysis and resource estimate, etc.), and decisional support (consulting on legal and contractual problems).

Experience Base

The most significant and visible product of Getronics’ support was the “Experience Base,” a project repository available for all the members of Project Teams allowing them to operate effectively.

The main “Experience Packages” (see Exhibit 2), provided after the initial setup and enhanced during the project, were organized and maintained by Getronics on the basis of the following partition domain:

Standard Templates: Documents templates supported by a tool for automatic coding, versioning and managing of the review and approval workflow.

Tutorial: Guidelines and tutorial on critical process as impact analysis and regression testing.

Test DB: Repository of test cases and procedures for validating the application portfolio.

ToolBook: User’s manual of the tools available for the partial or total automation of processes.

Sw Utilities: Standard routines for code remediation and renovation.

Checklist: Forms and questionnaires allowing the check of the project outputs (e.g., Contingency Plan) from a risk-driven perspective.

Project Deliverables: Each significant output provided by the Project Teams (e.g., test plan, cross-reference, etc.) that is potentially reusable by other teams.

Project Organization

In order to meet the project goals and manage all the impacted domains (business, technology, legal, etc.), the organizational structure was founded on a partnership between the Bank and Getronics resources. Roles and responsibility (see Exhibit 3) were assigned with the following criteria:

Bank Responsibilities

• A Project Manager, designated by Managerial Board of the Bank, was charged of all the decisions concerning the Y2K Project.

• More than 20 Project Teams, composed by internal or external resources, were responsible for the execution of remediation and testing activities with the support of Getronics Experts and Consultants.

Getronics Responsibilities

A Project Office Team, composed by up of seven people, was charged of supporting Bank’s resources in the following activities:

• Overall Project and Risk Management: Including the progress monitoring, status reporting, and definition of Contingency Plan.

Experience Factory Management: Maintenance of the Project Repository and for Secretary activities.

• Overall Project Teams Support: Test Planning and Execution, Integration Management, Distributed Systems Management supplied by Technicians and Consultants involved in different problem domains. A Lawyer for legal aspects and Insurance policies analysis was also provided within the Project Office.

Support Tools

As mentioned before, a set of tools was installed for supporting the following activities:

• Inventory and cross-reference of application components (programs, procedures, copies, datasets, etc.), including the code impact analysis to the “date sensitive” statements

• Simulation of “system date” for executing online and batch processes around the Y2K event

• Extraction of DB and automatic translation of fields containing dates on the basis of external parameters and without dependency from dates format

• Capture and automatic playback of online transactions for regression testing ante/post sw remediation

• Complete documentation management in terms of generation by templates, version control, review process and final approval.

Managing Risks

Project Office activity was focused on two essential guidelines:

• The capitalization of the best practices acquired by Getronics in the context of “mass maintenance” and “system integration” projects. The Experience Factory concept, for example, was applied in many cases with positive results.

• The application of risk-driven approach at different levels, not only within project planning and control, but also on conducting assessment and on test strategy definition.

Y2K Assessment

The model used for the initial (and final) risk was based on a standard questionnaire and was aimed at the evaluation of the organizational readiness of the Bank to meet the challenges issued by the Year 2000 problem. Within this context, business, insurance, and legal risks that could impact on the Bank organization were evaluated, including credit and liquidity risks. The assessment focused on risks arising from relationships with critical third parties. Finally, the technology risks that arise from the use of computer programs in business were quantified, including, but not restricted to, risks in the area of information technology.

Exhibit 3. Organizational Breakdown Structure

Organizational Breakdown Structure

In evaluating Customer’s responses to the questionnaire, the Getronics team assigned scores to each answer on the basis of judgment and expertise. Those scores formed a quantitative baseline for those comparisons, and also permit to measure the progress toward full Year 2000 readiness over time.

The report produced at the end of the assessment process describes the results in each of these areas by use of bar graphs. By reviewing the graphs, the project manager was quickly able to evaluate the overall risks and readiness of the Bank. The vertical axis of each graph represents the evaluation of risk or readiness on a scale of 1-100. The higher the number, the greater the risk or readiness. Here’s closer look at the assessment details and results.

Exhibit 4 shows the degree of readiness in six areas:

Awareness: Understanding by the organization of the seriousness of the problem and potential impacts.

Y2K Organization: Clear stating of who bears the responsibility for managing the Y2K problem in each business unit.

Assessment Remediation Efforts: Existence of an accurate and complete inventory for evaluating progress in adapting information systems.

Communication and Documentation: Existence of risk that important sectors (e.g., sales personnel) will not develop an adequate understanding of the Y2K.

Funding: Capability of decreasing risk by funding a separate Year 2000 budget.

Contingency Plans: Existence of specified actions and procedures in case of potential failures.

Exhibit 4. Organizational Readiness Evaluation

Organizational Readiness Evaluation

Exhibit 5. Business and Legal Risks and Readiness

Business and Legal Risks and Readiness

Exhibit 5 is focused on the comparison between risks and readiness within business and legal context. The goal is to:

• Assess if Key Business Relationships are completely and correctly identified

• Evaluate Inquiries To third parties (e.g., for products or services from supplier and outsourcers)

• Evaluate Inquiries From third parties (e.g., business partners requests about the Bank compliance to Y2K)

• Analyze Contracts condition of purchases, licenses, or leases goods or services (including software)

• Ensure that Bank’s Directors and Officers acted in accordance with applicable Italian legal standards

Exhibit 6. Technology Risks and Readiness

Technology Risks and Readiness

Exhibit 7. Evaluating Factors

Evaluating Factors

• Check if the Bank’s organization had extensive insurance coverage.

Y2K assessment was completed by the risk and readiness analysis from the technology perspective. Exhibit 6 shows the final results on different problem domains (not quoted elements were not applicable):

Services provided in the marketplace

• Dependency from external Suppliers

• Requests from/to Customers about Y2K compliance

• Interfaces with Financial Service Organization

Information Technology Infrastructure compliance

Facilities (focused on checking elevators and HVAC)

Utilities (focused in Uninterruptible Power Supplies)

Industry Infrastructure (focused on verify networks)

National Infrastructure (based on telecommunication, energy and gas services provided by the government).

Testing Strategy

As stated before, a risk-driven approach was also adopted for the definition of testing strategy.

First, all the applications were evaluated in term of Global Risk Level (R) using the formula:

R: A * (B + C+ D + E + F) where the evaluating factors are determined on the basis of the criteria in Exhibit 7.

A second ranking criteria was established to assign a Y2K Compliance Level to each application (see Exhibit 8).

On the basis of the two indicators (Global Risk and Y2K Compliance) and using the “Matrix Data Analysis,” each application of the sw portfolio was positioned in the matrix (see Exhibit 9) and assigned to a specific testing strategy:

Low Risk—High Compliance: Testing is restricted to the critical functionality

Exhibit 8. Competency Levels

Competency Levels

Exhibit 9. Matrix of “Risk-Driven“Test Strategy

Matrix of “Risk-Driven“Test Strategy

Low Risk—Low Compliance: Testing is mainly focused on critical interfaces with other applications

High Risk—High Compliance: Testing is restricted to the critical functionality and interfaces too

High Risk—Low Compliance: Testing is extended to a complete validation of functionality and interfaces.

Contingency Plan

The third milestone of the approach to risk management as implemented by Getronics’ Project Office was the Contingency Plan directed to possible IT failures in each area of the Bank operations. Key processes and applications, including scenarios of potential failures were identified and connected to the actions and procedures verifying that systems were fully operational.

Contingency Plan was sent to the branch agencies and tested on Saturdays using National Bank procedures. In addition, the Bank created a Year 2000 Command Center for the boundary day (December 31 to January 1) period.

Other elements of characterization of Contingency Plan were as follows:

• Assumption that there would be no failure of electrical power or telecommunications

• Criteria of identifying priorities and selecting between alternative courses of action

• Capability of managing simultaneous failures in more than one area. Unlike ordinary disaster recovery planning, Year 2000 failures could strike almost every area of business at the same time

• Addition of guidelines to manage customer and liquidity risks

• A Business Resumption Plan Section including a method for checking that systems are fully operational. The resumption plan was distributed to all relevant operative personnel (not just IT) to ensure that most employees were trained to implement the method. Such training helped in ensuring that Bank personnel could collaborate in establishing critical paths or timelines to resume operations in the event of a disruption. Accordingly, the plan was aimed at communicating to employees what was expected of them in the event of a Year 2000 disruption.

Lessons Learned and Conclusions

The industrial experience carried out by Getronics Consulting Italia was capitalized in other “mass maintenance” projects for industries and financial institutions (e.g., for the transition to the Euro currency unit). In this context, some major points have to be stressed as “lesson learned”:

• The offer of Project Office capability may represent a competitive advantage for a Solution and System Integrator as Getronics; its operational role is an added value and is well accepted by the Customer’s people.

• As the complexity of projects increases, the Customer wants to see detailed project plans and expects the contractor have the ability of coordinating critical processes, as the rollout of a new application or subsystem.

• Generally speaking, organization needs to use few skilled professionals on multiple projects. The Project Office is an effective strategy for delegating some duties and reducing the effects of the “skill shortage.” The Project Office may also represent a good initiative for training new professionals on the project management discipline.

• One of the most powerful way for promoting quality and productivity is the “experience reuse” among project teams; this is a typical duty of the Project Office: the capability of building up an environment that enables project teams to work effectively.

References

Basili V.R. 1991. The Experience Factory: Packaging Software Experience.

Block, Tom, and J. Davidson Frame. 1998. The Project Office: A Key To Managing Projects Effectively.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.