Gaining visibility and commitment to financial services technology projects using planning phase activities and deliverables
I have seen it too often. A financial services technology project gets off to a rocky start, jumps into the middle of a solution, and limps along while all parties hope that it will eventually get straightened out. What results are delays, changes in direction, rework, cost increases, and occasionally project cancellation. Depending on the size of your financial institution, your technology project is vying for attention with hundreds of others within your organization. Most likely, the resources assigned to your project are also working on other projects for other project managers. Throw in daily distractions such as production problems, management fire drills, projects that need just “a little bit” of attention, and dozens of e-mails and voice messages, and it is easy to see how your project can get lost in the “noise.” I am going to present some practical suggestions as to how you can gain visibility for your project, obtain commitment from project Stakeholders and participants by using the project planning process and the Project Plan as tools for success. This presentation will provide tips, tool examples, and real-world experiences for differentiating your project from its start to help you meet your ultimate objective, to get the right project done right.
Getting Started: Using the Planning Phase to Gain Visibility and Commitment
The first step in gaining visibility and commitment is to develop a Project Charter and Scope Statement with the Project Sponsor. This document is the vehicle by which you start gathering data about the project, aligning the project with organizational goals, and defining the boundaries of the project. If your organization is high on the Project Management Maturity Model, it is likely that the sponsor organization will have developed a Project Charter and Scope Statement. If that is not the case, your first objective is to interview the Project Sponsor and have him or her articulate the business drivers, project mission, project objectives, other internal organizations with a stake in the outcome, and his or her definition of what constitutes completion of the project. There is much written about this document in project management literature which I will not reiterate here. Here is what I have found to be effective for financial services projects.
Keep the document short and direct. Start with the following sections; Introduction, Project Description and Justification including Business Drivers, Constraints, Stakeholders, Deliverables, Project Objectives for Time, Cost, Quality, and Scope, Project Resource Roles and Responsibilities, Preliminary Resource Identification, Assumptions, Dependencies, and Issues. This information allows you to begin to coordinate with groups needing to participate on the project. As you assemble the project Core Team, use group work sessions to solicit their input to expand the document beyond the information provided by the Project Sponsor. A tip for the Project Charter and Scope Statement is to use numbered lists for all sections other than the narrative Introduction and Project Description and Justification. These lists provide the relevant information in an easy to read manner that facilitates group review of the document.
Review the document first with the Project Sponsor and Sponsor Division Management. This forum gives them the opportunity to validate the project mission and objectives. It engages their support and participation to direct the project from its inception. It lets them know that their input is valued, raising their level of tangible and intangible project ownership. After updating and refining the document with the Sponsor feedback, the second review is with the Project Sponsor and other primary Stakeholders outside the Sponsor Division. It is their first opportunity to hear some detail about the project, understand the impact to their respective areas, and provide feedback to the project about any aspect of the Charter and Scope. This review also presents the opportunity to identify critical success factors for working with their functional areas. This information will prove invaluable as you continue the planning process and design the project.
The next step in developing the Project Plan is to conduct a Stakeholder Analysis. It is an excellent way to engage the project Core Team and elicit their commitment to the project by having them participate. According to the PMBOK® Guide, Stakeholders are individuals and organizations who are involved in or may be affected by project activities. It is important to the success of the project to understand what they think about the project and how they define success. I have yet to conduct a Stakeholder Analysis without learning something unexpected from an individual Stakeholder that altered some deliverables or affected the project scope of work. What I want to know from each Stakeholder is:
1. Does he or she agree with the project objectives as defined in the Charter and Scope Statement?
2. What does he or she define as the project scope?
3. What does he or she view as project risks?
4. How does he or she define Critical Success Factors for the project?
5. How would he or she define project quality?
6. What, how, and how frequently does he or she want to hear about the project?
Talking to Stakeholders is just that. This is not an e-mail exercise. If you are unable to sit face to face with a Stakeholder, use the telephone. Assign each Core Team member several Stakeholder interviews. There are no rules other than to get their feedback. I have used group and solo, directed and nondirected interviews successfully. For nondirected interviews, I merely ask the questions above. For directed interviews, I create an interview sheet with the lists of Project Objectives and Project Scope from the Charter and Scope Statement, share it with the Stakeholder, and solicit concurrence and feedback. For the question topics above that were not part of the Charter and Scope, I ask the open-ended questions. To assist with the evaluation of the feedback, it is important to obtain the same information from all interviewees.
Upon completion of the Stakeholder Analysis, the Core Team evaluates the data and determines whether any Stakeholder feedback should be assimilated into the Project Charter and Scope Statement. The rest of the information will be used to design the project and build the Project Plan. Specifically, Stakeholder feedback will be used in the Risk Management Plan, Quality Management Plan, and Communication Plan sections of the Project Plan. Between developing the Project Charter and Scope Statement and conducting the Stakeholder Analysis you have given your project visibility, engaged key participants, gained consensus, and started building the Core Team's commitment to the project.
The Project Plan
According to the PMBOK® Guide, the Project Plan is a formal, approved document used to manage and control project execution. It defines the “What, Why, Who, When, Where, and How” of your project. It is a text document not to be confused with the Project Task Schedule or Work Breakdown Structure (WBS). Some organizations seldom produce one. This would be true of organizations that skip directly into requirements definition upon starting a project. It is a major oversight to skip this deliverable because regardless of the size of your project, it documents the manner in which the project intends to achieve its objectives. It also helps other internal and external organizations understand what they will need to do and when to support the project.
There is much available literature about Project Plans that I do not intend to survey here. I will present what has worked well for me managing financial services technology projects. The Project Plan should include the following sections; Introduction, Project Charter and Scope Statement, Milestones, Resource Plan, Scope Management and Change Control, Quality Management, Communication Plan, Communication Matrix, and Deliverables Responsibility Matrix. In addition, it could also include sections on Risk Management, Funding, Issues, as well as a preliminary Project Task Schedule or WBS. Any information that you as the project manager feel is relevant to the management and control of the project should be included. The contents of the Project Plan should be controlled by the size and complexity of the project. However, anytime you consider skipping a section, you should rationalize your decision based on what the project could lose by omitting it.
Although the project manager has primary responsibility for producing the Project Plan, it is an excellent team-building exercise for the Core Team. Participating in the Project Plan development gains their commitment early in the project because they can contribute to and influence project processes. Include staff from the Project Sponsor organization and other key functional areas impacted by your project if they are not already members of the Core Team. The Project Plan will be more readily accepted if it is developed as a partnership between the business and technology organizations.
Project Plan Components:Their Purpose and What They Accomplish
It is useful to include a short Introduction to the readers of the document that details the Background and Purpose of the document, its structure, the Intended Audience, and the reader's obligations. One of the obligations should be to require formal approval from project Stakeholders and that should be directly stated.
Project Charter and Scope Statement
The Project Plan will be distributed to a wider audience than may have participated in the Project Charter and Scope Statement and Stakeholder Analysis exercises. I have found it beneficial to incorporate the completed Project Charter and Scope Statement in its entirety as the next section. This gives project newcomers a brief, comprehensive overview of the project and sets the stage for the rest of the Project Plan.
Milestones With Projected Dates
This section uses a combination of significant events and the list of key deliverables developed in the Project Charter and Scope Statement and sets forth projected beginning and ending dates for each. This information sets expectations as to when components of the project work are to be started and completed. At this early stage of the project, these may merely be best estimates based on the Project Sponsor's required implementation dates. Regardless, this information is helpful to project Stakeholders as they begin thinking about resources they will have to provide and when.
This section identifies project resource roles and responsibilities. It describes the project organization and how the project will interact with the day-to-day organization. Every organization is unique in the way it organizes projects, and this section will reflect the particulars of your organization. At a minimum, one should provide specific role and responsibility information for the Project Sponsor, the Project Manager, the Project Core Team, any Management Oversight or Steering Committees, and specific Business and Technical resources known to be required for the project. This information should also include project reporting hierarchies and matrix relationships developed for the duration of the project. The more information that can be provided, the more likely you will obtain resources with the correct skills to support the project. I list each role, the responsibilities of the role, the skills required, and the projected start date for the resource. In many projects, the Project Sponsor and/or Project Manager know which individuals are critical to the project's success and have already assigned them to the effort. In these cases, it is appropriate to name the specific individuals.
Project Organization Chart
As an adjunct to the Resource Plan, a visual representation of the project team is a helpful tool. It clearly and succinctly communicates the relationships between the project players. Your project may have two views of these relationships. Often the Project Core Team views their roles and relationships somewhat differently than other internal or external organizations. In this case, two project organization charts may be in order, one representing the internal project view, the other representing the external view. For example, the Project Core Team may align itself by the functions that the individuals play on the project, but to the external view, those same individuals represent business interests of different areas within the financial institution. Having two views of the project is often the best way to communicate these differences.
Scope Management and Change Control
Change is inevitable. Change can hurt your project. The Scope Management and Change Control section documents how your project will manage change. There is a much industry literature about Scope Management that I will not present here. I will address the “how to” of Scope Management. It is critical to identify your project's process for submitting, logging, approving, and adopting Change Requests. By defining this process now, you are communicating the same rules to all project participants and Stakeholders. By including the Core Team members in defining the process you are also reinforcing that this is their project. All change is not created equal. Projects deal with both trivial and significant change from day one. Projects must also keep moving in order to accomplish the ultimate objectives in the scheduled time and it is often difficult to engage critical Stakeholders quickly to address every Change Request that is submitted. A tool that I have used successfully to address this issue is to use a Change Control Variance to manage scope.
Exhibit 1. Project Organization Chart—Team View
Exhibit 2. Project Organization Chart—External View
A Change Control Variance is a set of measurements applied to Project Cost, Schedule, Scope, and Quality. These measurements can be used to define a “two-tier” process to approve Change Requests. For any Change Request that does not exceed the variance criteria, the Project Core Team is empowered to make the approve/deny decision. Anything that exceeds the variance criteria requires Management to approve/deny the request. An example of a Project Cost Variance would be, “if the Change Request requires additional staff exceeding one-half staff month ($7,000) in to order to meet the implementation date.” An example of a Project Scope Variance would be, “any Change Request reduces the scope of the project or eliminates tasks.” Defining this two-tier process proved to be another beneficial planning task that brought the Core Team together and engaged Management's support by letting them finalize the variance criteria.
Exhibit 3. Quality Plan Category and Definitions
Exhibit 4. Risk Matrix
There has been much focus on project quality lately. Sometimes in a financial services technology project the definition of quality can be elusive; however, quality can be found and defined. During the Stakeholder Analysis you received feedback from Stakeholders regarding project quality. The Core Team should be able to come up with other ideas. Generally, quality can be defined for an end deliverable, such as the software product, or it can be applied to a process. From a product perspective, quality can be measured in several ways. It can be developing reusable code, defining throughput performance, or integrating the software with organizational infrastructure standards. As for process quality, it can be defined as how the project will conduct a given process so as to produce quality project results. For example, in a Y2K testing project, one financial institution defined quality as having the end users participate in the test planning effort and conduct the actual testing since they knew the system and how they used it best.
The Quality Plan is where your project defines its quality objectives, and its plan for achieving them. These objectives can be defined in Quality Categories. For example, individual deliverables may have their own Quality definitions. In the example above, one could define a category for “Conducting a quality test of the final software product.” Within this category, it is essential to define how the project will measure testing quality. These measurements can be objective or subjective which should be noted. In addition, each quality definition must have a Responsible owner for ensuring that it is accomplished. These concepts are illustrated in Exhibit 3. The final component of the Quality Plan is scheduled reviews to ensure that the project followed the quality directives. For example, in the definition of a quality testing effort, the project may want to review the quality definition measurements after completion of the Test Plan and Test Scripts and then again after the completion of the actual Test Execution.
Risk Management Plan
This section articulates the project's early understanding of risk. I will not delve into the specifics of risk assessment, but I would like to discuss the appropriate level of activity to spend on it at this point in the project life cycle. Naturally, the project size and complexity will be the main drivers of this activity. The objective at this stage is to identify the risk response development that you want to formally build into the project execution processes. In order to do so, the project team must identify and quantify the risks as normal. In the quantification step, it is important to develop common probability and severity criteria so that all risks can be objectively evaluated to the extent possible. This facilitates the use of a Risk Matrix on which you can plot the identified risks in a 3 by 3 (Low, Medium, High) grid with an x axis of Severity and a y axis of Probability. Once plotted, focus the early risk response development on the Medium-High and High-High risks. These risks may require additional planning or the design of tasks built into the WBS. Include the Risk Matrix and a summary of the findings in this section of the Project Plan. Bear in mind that this is not a substitute for continuing your Risk Management activities throughout the project life cycle.
Exhibit 5. Communications Matrix
If you want your project to succeed and be visible throughout its life cycle, communicate, communicate, communicate, and then communicate some more. The Communication Plan section documents the information that you intend to capture and disseminate about project activities. Depending on the practices within your organization, some of it may be predefined, yet other forms may be dictated by the wishes of the Stakeholders or developed by the Core Team. Information captured may include task schedule status, action items, issues, milestone progress, deliverables, deliverable status, meeting minutes or outcomes, and vendor communications. Information disseminated may include deliverables, status reports, current project task schedules, status meeting materials, milestone progress reports, and vendor communications. Certain information loses timeliness quickly, so thought needs to be put into the frequency of distribution for all of your project's communication vehicles. In today's distributed world, there are numerous viable options for receiving and distributing information. When choosing the ones appropriate to your project, listen to what the recipients want. Give them what they want the way they want it. It will elicit their support for the duration of the project. It is a Core Team exercise to define the proposed audience for each vehicle, the frequency of distribution, and the distribution media. After reviewing the completed Project Plan, you can expect that some project participants and Stakeholders will request changes to the Communication Plan. These changes should be accommodated.
Define your project's document standards in the Communication Plan. These include; how you will differentiate document drafts from approval copies, how you will manage version control, how you will identify revisions from prior versions of documents, where you will store hard copy and electronic document versions, how you will prevent unauthorized updates to completed documents, and what you will do with the document repositories after the project has ended. Having the Core Team define these standards makes this another activity that contributes to team commitment.
This matrix is a visual representation of the information collected and documented in the Communication Plan. It is a simple tool to develop, easy to read, and it conveys a significant amount of information on one page. The information presented is the Stakeholders, the communication vehicles, the frequency of the distribution, and the media on which the information will be distributed. The Stakeholders are listed along the top of the x axis, and the communication vehicles are listed along the y axis. For each row along the y axis, list the frequency and media of the vehicle and then place an “X” in the column for each Stakeholder receiving the information.
Exhibit 6. Deliverables Responsibility Matrix
This matrix has the same format as the Communication Matrix, but is focused solely on the Deliverables. Like the Communication Matrix, it is easy to read and conveys a significant amount of information. However, it is not quite as easy to develop because there can be conflict over Deliverable ownership and approval responsibilities. The purpose of this matrix is to document for each Deliverable the project participants responsible for creating the deliverable, actively supporting the creation, reviewing it, and approving it. Stakeholders are listed along the top of the x axis, and the Deliverables are listed along the y axis. For each row along the y axis, list the target date for Deliverable completion and then place one of five values in the column to identify each Stakeholder's responsibility for the Deliverable. These values represent Primary responsibility for deliverable creation, Support responsibility, Review responsibility, Approval of the Deliverable, or “blank” for no responsibility.
There can be honest disagreements about Deliverable responsibilities especially for Approvals. Negotiating acceptable outcomes for the Stakeholders involves engaging their participation in resolving the issue. In respect to assigning responsibilities to individual Deliverables, there should be only one Primary owner for creating a Deliverable. I recommend keeping the number of Approvers for a Deliverable to the essential minimum. Too many Approvers can stall the project at critical times and collecting Approval signatures gets exponentially more difficult the more Approvers there are. However, do not exclude Stakeholders who have a legitimate need to Approve a Deliverable.
Project Task Schedule/WBS With Preliminary Resource Identification
Depending on how much is known about the project at this stage, include the Project Task Schedule or WBS in the Project Plan. In many projects the objectives are to implement known technologies within well-understood environments and the scope of work is clear from the beginning. In these situations, it may be straightforward to work with the Core Team to construct the Project Task Schedule or WBS at this stage and present it with identified resources or responsible functional areas for each task. If you are in a situation that is not well-defined, document what you know about the schedule or WBS to the extent possible. The more information presented, the better Stakeholders will understand the impact to their respective areas.
Finalizing the Project Plan
Congratulations, you have accomplished a significant amount of work producing the Project Plan. Once your review draft has been completed, distribute it to all project participant groups and Stakeholders and schedule group reviews. Depending on the number of project participants and Stakeholders, you may need to conduct several reviews to cover the entire document with everyone. During these reviews, listen carefully to the feedback and negotiate appropriate changes to the document. Upon completion of the reviews, update the document identifying the revisions as you defined in the document standards section of the Communication Plan and redistribute the Project Plan for approval. All Stakeholders should approve the Project Plan in writing. Post the signatures in the project repository.
It is now a matter of executing the plan. I carry the Project Plan with me and refer to it often throughout the project. I use it to keep participants focused on the agreed upon project mission and objectives. When disputes arise about scope or deliverables, the Project Plan is an excellent source for revisiting the planning decisions. If a request falls outside the agreed upon scope, a quick review of the Scope Management and Change Control section sets forth the project's defined process for addressing new requests.
I have described the project planning process that I have effectively used on financial services technology projects to produce a Project Plan. I have demonstrated how the project planning process can engage project participation and commitment from the Sponsor, Stakeholders, and direct participants. I have described a collaborative planning process that encourages input and ownership from groups affected by the project outcomes. These activities are not complicated. Conducting them gives your project early visibility with the organizations that will be instrumental in achieving your objectives. When you are through with this process all interested parties will have a clear understanding of the What, Why, Who, When, Where, and How of your project. Happy project planning!
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA