Tools of Engagement: Critical Components of Program Management Governance

Transcription

1 Jason Shimko FIS Consulting Services

2 Executive Take-aways The approach many banks take toward project management is insufficient in scope to govern with the high-level perspective and extensive business reach required by large initiatives. These initiatives, called programs, consist of multiple interrelated projects that function toward the realization of a broad, unified strategic business goal. Therefore, successful banks are turning to program management to govern their intricate, wide-ranging initiatives. Program management methodology is designed to handle the more challenging characteristics of a program, because it can: Handle large-sized initiatives that can also be complex in their scope and magnitude Be flexible enough to coordinate, direct and oversee the implementation of related projects and activities Deliver outcomes and benefits supportive of a financial institution s strategic objectives and client requirements Complex initiatives require a program manager. The position bears ultimate authority for the program but receives direction from governance or steering committee(s) consisting of the program s key stakeholders. They determine the specifics of the program and its goals within the bank s overall business strategy. The program management team has at its disposal, and must capitalize upon, a number of tools for effective program management. A typical governance tool set includes: Overview and statement of purpose Articulated statement of purpose incorporating the business goals that define why the program has been organized Communication plan Definition of the approved methods of communications, frequency or recurring communication, and types of updates provided to program stakeholders and project teams associated with the program Integrated program schedule Tool to identify the key tasks, durations, dependencies, program milestones and responsible parties defined to deliver the program Program quality plan Definition of the agreed-to quality that will be delivered by the program and how it will be tracked and measured Program risk management plan Detailed assessment of the tolerance for risk throughout the program and how it will be regularly tracked and monitored Program issue management plan Plan to provide strategies and guiding principles for identifying, tracking, escalating and resolving issues Program change management plan Definition of the authority the program has to incorporate change requests from a subordinated project and the impact threshold when changes require additional authorization. It also details how changes affect agreed-upon scope and are rolled into plans for delivery. Program monitoring and control management This activity defines how program management ensures adherence to time, scope, quality and cost guidelines in order to meet business goals FIS and/or its subsidiaries. All Rights Reserved. 2

3 No Project Is an Island The decade has borne witness to improvements in the application of project management. One might say the practice has entered a kind of golden age, with an unprecedented number of organizations in fields as diverse as engineering, manufacturing, construction and financial services displaying the confidence to buy into and implement sophisticated project management methodologies. The technology sector has seen a rapid increase in the development and adoption of differing methodologies such as Agile, Critical Path, PRINCE2 and SCRUM. Unfortunately, organizations are finding this pursuit does not necessarily translate into achievement. Many large, complex IT initiatives are prone to failure within the U.S. In 2012, a McKinsey study of projects valued at more than $15 million each found that on average, 45 percent were over budget, while just over half (56 percent) delivered less value than anticipated. The aggregate cost of the 5,400 overrun projects in the study was $66 billion. In a different study that same year, the Standish group found projects succeeding at a rate of just 39 percent (delivered on time, on budget, with required features and functions), while 43 percent were challenged (late, over budget and/or with less than the required features and functions) and 18 percent failed (cancelled prior to completion or delivered and never used). Those results are shown in following graphic. Project Success Rates 39% 1 43% Challenged 2Failed 3Successful 18% Project resolution from 2012 Standish Group research Even the outcomes of projects managed with enough proficiency to meet budgetary and scheduling expectations do not necessarily translate into business value because the individual projects are being approached without considering the organizational system of which they are an integrated part. No project is an island; it affects and is affected by the variables and activities surrounding it, including other projects that may or may not contribute to a common outcome. Project activities are often interlinked in complex, unforeseen ways; this is certainly true in the financial services industry with its myriad of integration, consolidation and M&A initiatives expected to align with the bank s overall strategic plan FIS and/or its subsidiaries. All Rights Reserved. 3

4 Project management lacks the high-level perspective and extensive reach required to govern large initiatives effectively, which may result in the construction of barriers that impede an organization s ability to glean business value from IT investments. According to a recent Forrester Research report, Historically weak IT governance leaves organizations without formal processes for demand management, investment management and portfolio management. There are no consistent approaches to project funding and no standard business case formats. Confronted with the inadequacies of project management to handle dynamic, far-flung initiatives, more and more financial institutions are turning to program management to improve success in meeting their business objectives. The Program Defined The program provides an umbrella framework and the guidelines to coordinate multiple, interdependent projects, not just with each other, but with other critical components that contribute to an institutional goal. Ancillary factors can be organizational, personnel-related or process-specific. A program manager working closely with a steering or governance committee controls and directs multiple, interdependent subprojects in order to produce an overall system that meets client requirements. Program management is also distinguished by its ongoing, dynamic approach to oversight as the initiative unfolds. When unforeseen changes occur, the program manager and team assess the changes, ascertain the necessary modifications and provide guidance as the changes are implemented through to the close of the program, after which a formalized schedule of follow-up protocols is set in motion. Projects versus Programs Although definitions vary among organizations and academics, for the purposes of this paper, the characteristics of projects and programs are contrasted as follows: Project Less complex; one component Defined parameters Individual initiative with limited formal interfaces to other projects Created with minimum emphasis on the overall business plan/ strategy Deals with outputs Project manager interacts with suppliers that impact the project specifically Program More complex Flexible organization built to accommodate change Created to coordinate, direct and oversee the implementation of a set of related projects and activities Supportive of strategic business objectives and client requirements Deals with outcomes Interaction with multiple suppliers outside the program manager's direct organizational area Impact upon multiple clients and/or clients of significant strategic business importance to the bank A program s success is typically measured by the following criteria: Delivering the program to the client on time and within the dates specified in the agreement, taking into account any amendments or approved change requests 2014 FIS and/or its subsidiaries. All Rights Reserved. 4

5 Achieving the financial objectives set forth in the business case, taking into account any amendments or change controls Meeting all expectations related to quality and fulfillment of program requirements Adhering to an established program methodology measured by a joint governance board Achieving overall client satisfaction Program initiation and program management pose significant challenges for a financial institution, including having oversight and program governance. Fortunately, a number of proven tools are available to bank executives and stakeholders as they construct their program governance plan. Program Development The initial stages of the program management initiative are critical. While some banks are ambitious enough to create their own governance components, a more practical and common approach is adapting a set of generic tools, already existent, to the bank s specific needs. These are often sourced from a third party with program management expertise. That isn t to say adapting these tools to the organization is simple. It requires participation by the bank on a considerable scale, a team effort led by a program manager. A high-ranking manager or a project manager familiar enough with the overall program and how it aligns with the bank s overall business goals is preferred. If an outside entity is called in to act as a program manager, their liaison is often a bank project manager. The two work in tandem to dispense direction, navigate the program out of the starting gate and keep it guided in the proper direction for its duration. The program manager supervises the work of multiple project managers and key program contributors of varying levels and professional disciplines. Although he or she bears the ultimate responsibility for the program s success or failure, the position is seldom, if ever, expected to make a unilateral decision. A program governance plan requires the assembly of a strong steering committee in the largest programs, multiple steering committees each with its own area of emphasis to work with and support the program manager. The steering committee(s) provide guidance and direction throughout the different stages of the program as they evolve. Comprised of the program s stakeholders (senior management for the business units within the financial institution, a technology manager, an executive from the financial office, etc.), this team defines the program s framework and goals. The program team executes each piece at the appropriate time, drives the program until completion and manages adjustments to the initial plan when a change in direction is required. The makeup of the committee can evolve as the program evolves. The critical components reviewed in the next section are utilized to help ensure the goals established by the steering committee are achieved FIS and/or its subsidiaries. All Rights Reserved. 5

6 Critical Components Tools of Engagement Program governance components (see list at right) are holistic. They work together to address all projects and activities that make up the program and how they combine to produce the program s desired outcomes. These tools, for the most part, are a set of documents, forms and charts that when shared with and utilized by the program team provide a common vocabulary that facilitates communication between involved parties. They create a frame of reference allowing project managers to stay focused on their individual goals and objectives without losing sight of the program s goals and objectives. Critical components are nonlinear; they are not deployed during a particular phase of the program but are applicable across all program phases for the program s duration. Program Management Tools of Engagement: Overview and statement of purpose Communication plan Integrated program schedule Program quality plan Program risk management plan Program issue management plan Program change management Program monitoring and control management A best-in-class set of governance tools affords a program manager the luxury of letting his or her project managers do what they do best manage their projects without sacrificing oversight within the context of the whole. An individual project manager never has a chance to cross into another project manager s lane because governance tools ensure the program manager can intervene in a timely manner, if necessary. The end result is a comprehensive methodology that effectively tracks, records and communicates the program s evolving landscape as it progresses. This information forms the basis of a shared information depository accessible by the governance committee, a unified view of and reference point for the program that allows a systematic way to read and measure status. The following sections summarize the purpose of each component. Overview and Statement of Purpose Before diving into the nuts and bolts work of defining each critical program governance component, an articulated statement of purpose incorporating the guiding principles of the program is identified and recorded. The program overview incorporates key objectives that include a look at existing processes and dependencies and how they fit into the program. This effort should also allow for an analysis of new projects that need to be put into play and current projects that need to be terminated. For all intents and purposes, the overview and statement of purpose are the bible for program governance the instruction manual used as a guide to construct it FIS and/or its subsidiaries. All Rights Reserved. 6

7 Communication Plan The communication plan defines the approved methods of communications, frequency, and types of updates that are provided to program stakeholders and project teams associated with the program. Efficient and effective communication is perhaps the most important and fundamental aspect of program governance as it provides consistency and alleviates common misunderstandings and conflicting interpretations. The communication plan applies across functional teams. It establishes and documents standard communication procedures for all, ensures clear and consistent messages are delivered to all areas of the program, and facilitates the collection of information to be used for external communication purposes. In addition, it ensures personnel understand what is expected of them, as well as charting out what information should be distributed and to whom. The group crafts and delivers periodic updates on the progress of the project and the milestones that have been reached, information that staffing uses to operate effectively during conversion weekend, etc. A good communication plan allocates time for status meetings, at which critical information is passed between participants, and sets parameters for what is to be discussed. Typical elements of a communication plan include: Documented communication paths for information sharing, including what tools (secure VOIP, encrypted networking, video/web conferencing, etc.) will be used throughout the program Program and project contact lists A program organization chart to identify high-level organization, reporting, escalation and accountability for the program. It also identifies the business person or committee that provides direction to the specific projects to ensure the project is delivering the specific business gaps identified (Figure 1). Executive Steering Committee Steering Committee Client Relationship Manager Program Manager Bank PM Program Support PgM Solution Architect Project Lead QA Manager Training Lead PM 1 PM 2 PM 3 PM 4 QA Manager Key FIS Resources Bank Resources Figure 1. Sample program organization chart 2014 FIS and/or its subsidiaries. All Rights Reserved. 7

8 Roles and responsibilities matrix Approval and escalation procedures that dictate how decisions are brought to the attention of the teams and individuals impacted by issues that arise. The tools used to log such issues are defined, and those parties that are responsible for resolving said issues are also identified. Recurring communication matrix to ensure timely and effective communication to all stakeholders. These recurring communication methods are reviewed periodically and revised as necessary. Program event management plan that ensures the right event occurrence reporting plan and event tracking tools are in place to record all program level risks (and assumptions), issues, changes, decisions, action items and lessons learned. This plan also contains specific priorities and response times to those priorities. Integrated Program Schedule The integrated program schedule identifies the key tasks, milestones, durations, dependencies and responsible parties for tasks within an assigned program. Regular review and update of this schedule are crucial in providing the program according to the agreed-upon schedule. Individual project teams reference and provide input into the schedule, which tracks tasks at a workable level and records actual versus estimated duration and work efforts, and actual versus estimated start and completion dates. These project plans serve as input into the integrated program plan maintained by the program manager. The program schedule is built based on the information contained within the stand-alone project plans. The schedule tracks high-level tasks and milestones across the program, but with enough detail to communicate any cross-project dependencies. This detail ensures each organization sets expectations with the other as to when information is required from the other to prevent program delays and identify interdependencies. The plan is reviewed by the program leadership team prior to being communicated to the program stakeholders. Program Quality Plan The quality plan defines the expectations of quality that will be delivered by the program. The plan addresses the overall approach that will be adopted by the program and associated projects to ensure that quality is delivered according to stakeholder expectations. The quality plan also defines quantitative measures that are used to validate quality prior to moving through a quality gate and eventually prior to implementation. To reduce the risk of program failure, the program should follow a development life cycle with defined phases/cycles of design, build, internal testing, system integration testing and user acceptance testing. To elaborate on these testing phases/cycles and define the quality assurance plan, multiple planning workshops are held with the client bank and project teams. The relationship of the quality stages and software development life cycle is depicted in the following diagram: 2014 FIS and/or its subsidiaries. All Rights Reserved. 8

9 Figure 2. Quality stage relationships to traditional software development life cycle At the point in time identified in the program plan, the client bank will engage in user acceptance testing (UAT) of the solutions within the program according to the agreed-upon quality plan. The quality plan will contain a defect management strategy that focuses on preventing defects, as well as catching them as early in the development process as possible in order to minimize their impact. A defect management strategy provides the necessary guidelines for executing UAT, including: How defects are communicated The logistics of sharing communication and plans Resolution service level agreements The quality plan not only includes the defect management strategy but also the entrance and exit criteria for each program phase. Defining entrance and exit criteria is critical to ensure that all phases fulfill the quality gates defined to transition from one program phase to another through implementation. Depending on the program, quality assurance can take the form of multiple testing categories, all of which are documented in the plan. Some examples of different testing phases are: Integration testing and connectivity Unit testing Cross-company integration testing Internal system testing Client-assisted testing 2014 FIS and/or its subsidiaries. All Rights Reserved. 9

10 Performance testing Environment readiness testing User acceptance testing Implementation testing Program Risk Management Plan The risk management plan is used to define the tolerance for risk throughout the program life cycle as well as the methods for identifying, recording and addressing risk throughout the program. The early and frequent identification of risk in a program is essential to meeting cost, schedule and quality expectations. It is not uncommon for the steering committee and program manager to meet on a monthly basis, or as defined in the communication plan, to review the identified risks, examine each associated action plan and define updates that need to be initiated. Additionally, the team communicates any newly identified risks that may impact the program as they surface. Newly identified risks may be identified as a result of the experience of the program leadership team or by one of the projects within the program. Regular status reporting identifies risks that may have significant impact to the project and subsequently the program. The program team discusses these risks and takes the appropriate action according to the expertise of the team. The ability to quickly respond to a risk occurrence lies in the ability to monitor and identify the triggering factors of a risk. As such, each project and program risk will identify the associated triggers and will be reviewed regularly. Risk logs can be utilized to document the impact severity, probability and priority. Risks can be categorized as shown by the pie chart in Figure 3. Similar categories of risks can then be addressed within the particular categories noted on the chart. Figure 3. Example program risk distribution 2014 FIS and/or its subsidiaries. All Rights Reserved. 10

11 After the initial risk assessment is complete, any program and/or project risks increasing to high impact and high probability will be communicated to the steering committee using the procedures defined in the communication plan. Often they are the same as those outlined for issue escalation. Program Issue Management Plan Throughout any program, risks are bound to become issues needing resolution in accordance with the strategy defined in the risk management plan. In the likely scenario that an issue arises that has not yet been identified as a risk, the issue management plan provides strategies and guiding principles for resolving the issue. Recognizing that this theoretical situation is not the typical situation in the execution of programs and projects, the same escalation principles identified through the program organization chart apply in the escalation of issues. Each project within the program is expected to maintain detailed issues logs tracking the identification and resolution of issues identified by the project team. Each log at a minimum includes the issue origination, last update date, an assigned owner, a priority, description, target resolution dates and resolution details. Any identified critical or high-priority issue must be included in the regular project status report for possible inclusion in the program issue log. Additionally, if at any time a project team is unable to resolve an issue due to lack of authority within the project, they can escalate to the program team via their weekly status report or through a direct request to the program manager. The issue log typically provides room where each issue can be transcribed, and it is typically divided into two sections: the left half for recording information pertaining to the issue itself and the right half for recording information pertaining to issue resolution. Table 1 displays the typical information that is recorded in each part of the chart for each issue. These forms are large enough to hold the detail of many issues, if necessary. Issue Issue Resolution Status Assignee Name Status Date Target Date Description/Impact Days to Target Priority This Week Resolution Date # of Days on List Resolved by Originator Name Resolution Progress Origination Date Table 1. Types of information recorded in an issue management log 2014 FIS and/or its subsidiaries. All Rights Reserved. 11

12 Program Change Management Whether due to missed requirements, project issues or increased scope, a program is bound to encounter change during the life cycle. The program change management plan defines the authority that the program has to approve change from an associated project, how said project requests change the agreed-to plan and how the program should receive approval on change requests that are beyond its authority. The program scope change management plan defines the process by which scope change is introduced, reviewed and added to the program. Management of program change often requires a dedicated team acting as part of the program management team. The key components of the program change management process are as follows: Define the Change Control Process A clear and consistent change process is required in order to support change control. That starts with describing the process so it is certain that changes are effectively documented and analyzed with regard to impacts to established scope, as well as to the schedule and the total cost of the program. Table 2 shows an example of a form that can be used to formalize change control responsibilities: Initiate Change Request Log Updates, Communications, Track Package and Maintain Supporting Documents Inventory Analysis Estimates and Counsel Gather Supporting Documents Review and Decide Disposition of Request Implement/ Support Request Requesting Project Team Requesting Project Team s Program Level Manager Change Control Coordinator Change Control Team Development Team Quality Assurance Team [Client] Executive Team Table 2. Form for defining change control roles and responsibilities 2014 FIS and/or its subsidiaries. All Rights Reserved. 12

13 Create a Change Control Document Archive All submitted change requests should reside in one area so that all the documentation attached to a change request form can be downloaded, reviewed, analyzed and updated as a whole using the appropriate document controls. Establish a Change Request Tracking Process This is a table that documents the change control process in step-by-step detail, with a brief synopsis of each step. Besides being descriptive, each step contains a numbered reference to the next step that should be initiated once the current step is completed. Designed to be shared among project participants, the change request log provides a clear, non-ambiguous road map for the change control project. This process is often also documented in a flowchart to allow visual understanding of the process (see Figure 4 below). [Client] Change Control Process More Data Required Development Executive Team Triage Team Project Team Team 1 Identify Possible Change 6 Initial Review of SCR by Change Control Team 7 No Continue? Yes 8.2 Request T-Shirt Estimate and Additional Information 9 Develop, Mgr Obtains T- Shirt Estimate 2 Internal Program No Review Continue? Close Of Proposed Change Yes 4.2 Document and Submit SCR Decline Change Request, Add to Change Update Log Control Log Decline Table Change Request, Table Action Approve Require Exec Close SCR, Update Log Update Log Taken? Approval? 12 Iterative Review Yes of Change Request by Triage Team Update SCR with Submit Updated Information Required for SCR for Review Review Iterative Review of Table Change Change Request by Request, Update Log Mgmt Team Table Decline Change Request, Decline Action Update Log Taken? No 15.1 Update Log 16 Initiate Development Project 18.3 Update Log Approve Figure 4. Change control process documented in a flowchart 2014 FIS and/or its subsidiaries. All Rights Reserved. 13

14 Communicate Change Request Documentation Procedures Change management is challenging in that change requests are expected to be thorough and detailed with specific documentation and sign-off required for three main sections: 1) the change request submitted to the program manager and team by the requesting project manager, 2) the change response to be completed by the impacted project(s) and program manager and 3) the documented agreement to proceed from the program manager or steering committee. The activities, contingencies, milestones, dependencies and other key characteristics of the change request program are recorded meticulously in the program change log. Program Monitoring and Control Management Part of the communication plan is the aspect of providing periodic status updates to the stakeholders of the program and project teams. The communication plan defines how projects provide status updates to the program, how those updates are consolidated into the program status report and how the status report is communicated. Program monitoring and control is not only the process of comparing the progress of the program against the individual milestones, but also the review of implemented procedures and processes to ensure effectiveness. The information gathered is used to modify and/or adjust the program plan (governance and schedule) to ensure overall success with respect to cost, timelines and client expectations. Each of the plans cited in earlier sections provide key tools and inputs for monitoring and controlling the overall program. Besides day-to-day performance management, program and project personnel will use the following artifacts, in addition to other tools, to monitor and control the program: Event log (includes identified risks, issues, changes, decisions and action items) Project performance information Weekly status reports With these inputs, each project manager is expected to: To make timely recommendations for corrective or preventative actions that need to be taken Submit change control requests as appropriate to their program manager Communicate variances to existing plans according to the thresholds defined below FIS Engagement Expectations As a long-term partner and significant service provider, FIS is positioned to assist your financial institution in successfully implementing its complex programs, taking into consideration the tenets of program management discussed in the paper FIS and/or its subsidiaries. All Rights Reserved. 14

15 When engaged as a resource for program management, FIS Consulting Services will see to it that the following behaviors are incorporated as part of the program: Provide templates for the components that are covered in this paper, which can then be tailored to the needs of the individual bank after discussions with the bank s key stakeholders. The FIS program manager will have direct access to all steering committees and act as an equal voice when governance committee meetings are held. The agenda for these meetings is co-developed by your institution s program manager and the FIS program manager who function as its sponsors. Governance committees are formed as working committees and are authorized to provide direction, set priorities, identify risks and resolve issues. Projects within the program are organized around business solutions, not vendors. If multiple vendors are expected to deliver a complete solution, the plan to do so must include an integrated project plan accompanied by comprehensive documentation. Projects within the program are assigned a business lead that provides representation to the project and ensures that the project meets defined objectives according to the program purpose. Development projects utilize a defined methodology and create artifacts for sign-off. At a minimum, they require signoff on these artifacts: solution scope, requirements specifications, functional specifications and test plans. Additional artifacts, if required, are to be submitted for timely review and approval at the discretion of the project team. The implementation and utilization of the above components and governance has proven to be successful in programs managed by FIS Consulting Services. This model has been implemented for integration projects, bank conversions, de novo banks and system replacement projects. While the implementation of this methodology is not a guarantee of success, the likelihood is greatly increased. For More Information The FIS Consulting team of specialists comprises practitioners in financial services, operations, technology, risk management and retail and commercial banking. Our expertise spans the many facets of contact center improvement. We deliver measurable results to increase efficiency, grow revenue and improve profitability. For more information on FIS Consulting Services, call and/or visit FIS and/or its subsidiaries. All Rights Reserved. 15