Pitch Pen consists of a diverse group of executive & senior leadership and allows company to review project requests greater than $100,000 for a consistent approval process, rather than focusing only on what’s needed in a singular area of the company. It focuses on where the company should spend capital to foster growth and innovation. This also allows managers to hear what other areas are requesting, allowing for cross-dialogue about needs and how we could potentially solve them differently. Pitch Pen is held twice a year – in the fall prior to budgeting and in the spring to help with year-end forecasting.

The Technology Committee (TC) is a chartered committee of CCB and is comprised of members who are a combination of senior managers across the enterprise and technology managers. The TC has oversight of the Project Management Office and is responsible for elements of Project Portfolio Management (PPM) such as project prioritization, resolution of competing project resources, and review of project Benefits Realization.

The Project Management Office (PMO) is a department whose primary responsibility is to provide project management resources to the organization. The PMO is comprised of a department manager and multiple PMs. Specific PMO responsibilities include providing guidance to senior and middle management in required steps in the Initiation phase of a project, to work closely with management during the Planning phase, to manage the Execution, Monitoring and Controlling, and Closing phases of PMO-managed projects, and to provide guidance for those associates outside the PMO who are executing department-managed projects.

The Project Sponsor is the person with the primary responsibility for the project. This is a single individual who carries the overall accountability for project success. The Project Sponsor is responsible for activities such as defining the Project Objectives, developing the Business Case, assessing project risks, and setting the project budget. As the project progresses, the Project Sponsor is responsible for approving the project scope and requirements, approving and rejecting proposed changes to the scope, allocating resources, and consulting with the PM on project status. After the project is closed, the Project Sponsor is responsible for ongoing reporting for BRM.

In some cases, the Project Sponsor operates at a high level in the organization and the demands on their time make it difficult to perform some of their required functions. In these cases it may be appropriate for the Project Sponsor to delegate the functional responsibilities to another senior person on their team. When this occurs, the two roles are referred to as the Executive Sponsor and the Functional Sponsor.

• The Executive Sponsor retains primary accountability for the project and has responsibility for approving project documents and scope changes
• The Functional Sponsor acts as the primary contact for the PM and Project Stakeholders. The Functional Sponsor performs the activities normally associated with sponsorship, including developing initiation phase documents and providing direction during the planning and execution phases. Ultimate responsibility for decisions affecting the project resides with the Executive Sponsor.

In situations where sponsorship is split between Executive and Functional Sponsors, both individuals should be listed as such on the Project Charter and other project documents. The body of this document will simply reference the person(s) responsible for sponsorship collectively as the Project Sponsor.

The Project Manager (PM) is the person with the primary responsibility for successful project implementation. This is a single individual for each project. For PMO-managed projects, the PM will be an associate in the PMO, and will be assigned after the project is approved at the end of the Initiation Phase. In some cases, the PM will be asked to assist with project initiation. For department-managed projects, the PM is typically a manager or an associate within the department for which the project is being executed. Responsibilities of the PM include ensuring that all required project steps are performed by the right people in the right sequence in the early project phases, to ensure that all Project Stakeholders are identified, to assemble a Project Team, to develop and execute project plans for the Execution phase, to ensure that appropriate steps are taken for the Monitoring and Controlling and the Closing phases, and to measure and report the success of project execution to the Project Sponsor and Project Stakeholders at the conclusion of the project.

Project Stakeholders are the individuals who are responsible for areas of the organization that will be affected by the project. In other words, they hold a vested interest (or a “stake”) in the project because the lines of business or the departments that they manage will be affected by it. Depending on the size and complexity of a given project, Project Stakeholders are sometimes categorized into Major and Minor Stakeholders. The role of Project Stakeholders is to ensure that their interests for their areas of responsibility are considered in the project, to participate in project status meetings, and to participate in review and approval of project milestones. A Major Stakeholder may need to participate as decisions are made, whereas a Minor Stakeholder may only require knowledge of decisions made.

The Project Team consists of those associates who perform project tasks during the Execution phase. Project Stakeholders are sometimes included in the Project Team but Project Team members are often not Project Stakeholders. The Project Team members are those individuals who actually perform the series of tasks defined in the project plan.

A Subject Matter Expert (SME) is a person who is an authority in a particular area or topic. SMEs may have expertise in internal processes, technology systems, industry best practices, and many other areas. SMEs are often included in Project Teams in order to provide expert judgment at various points in the project.

Sometimes organizations undertake projects that introduce new technologies and/or processes for which there is no existing internal SME. In these cases, development of an internal SME can be a critical component of the project. It is very important that the developed SME be someone other than the PM assigned to the project. This will enable the organization to have the required expertise in the area where it is needed once the project closes and the PM exits the project.

Product/Process/Technology Owners are the people who will be responsible for the ongoing management of new products, system and security administration, new processes, and other changes introduced by the project. During the Closing Phase, the project will be handed off to these people.

 Product/Process/Technology Owners may have some of the characteristics of a SME, but unlike a SME they have direct responsibility for ongoing management and own the maintenance and change processes. There can be multiple Product/Process/ Technology Owners identified in a project and it is important to identify and ensure proper training of these individuals.

The activities described in the initiation phase of the EPF are designed to mitigate as many project risks as possible before capital or human resources are applied to the project. Careful oversight is required to ensure that projects support strategic business objectives and those projects are effectively implemented into an organization's enterprise architecture.  Activities performed during the Initiation Phase include assessing current systems and processes, developing a Business Case and a Feasibility Study, initiating a Project Charter, and identifying Project Stakeholders.

In order to generate allocations and track time being spent during the Initiation phase, the PMO manager or the assigned PM should create the project in PPM Pro from the New Project Template.

Problem Statement

The initiation phase begins when an opportunity to add, to improve, or to correct a system or process is identified. Opportunities such as these are often referred to as a Problem Statement and act as the trigger to initiate a project through the submission of a Project Request. Project Requests are initiated internally by department or division managers.  All projects should be submitted as a Project Request in PPM Pro.

Project Request

The first step in the initiation phase is to generate a Project Request. All Project Requests will be required to contain a project name, brief description, name of the Project Sponsor, strategic alignment, and Project Objectives.

Assess Current Systems and Processes 

In order to ensure project success, it is important to gain a full understanding of existing systems and processes before embarking on a new project. Without this understanding it will be difficult to identify all Project Stakeholders and to plan for the full project impact across the organization. Sometimes a study of existing systems and processes will bring to light existing functionality and/or capacity that can mitigate much of the original purpose of the project.

Business Case

The Business Case should, at a minimum, set forth the problem statement, describe a proposal's purpose, identify expected benefits, and explain how the proposed project supports one of the organization's business strategies. The Business Case should also identify alternative solutions and detail as many informational, functional, and network requirements as possible.

The presentation of a Business Case provides a point for management to reject a proposal before they allocate resources to a formal Feasibility Study. When evaluating software development requests (and during subsequent feasibility and design analysis), management should consider input from all affected parties. Management should also closely evaluate the necessity of each requested functional requirement. If provisional approval to initiate a project is obtained, a more thorough Feasibility Study may be conducted. Completing a Feasibility Study requires management to verify the accuracy of the preliminary assumptions and identify resource requirements in greater detail.

A Business Case can be generated as an extension of the Project Request. The Project Sponsor can do this by completing the fields in the Business Case section of the Project Request. It is also permissible for the Project Sponsor to generate a separate Business Case document that can be attached to the Project Request. We recognize that there are times in which senior management has already concluded that a particular project will go forward, such as a decision to acquire another financial institution, or to close an office. If a C-level executive has already made such a decision, a Business Case will not be required.

Project Request Scoring

Once the Project Request and Business Case fields are completed, the Project Sponsor should score the Project Request. The intent of the score is to assist in project prioritization in the event of competing resources. The Project Sponsor is usually the person who best understands the benefits and potential costs of the requested project and is therefore best suited to perform the scoring task.

Feasibility Study 

Whereas a Business Case sets forth what the project is, why the project is being proposed, and what benefits are expected to be realized, a Feasibility Study describes what it will take to do this project. Primary issues organizations should consider when conducting feasibility include:

• Technical Feasibility: This section focuses on the technology requirements of the project and includes the following areas.
• Economic Feasibility: This should be a detailed analysis of the financial impact of the project. A separate spreadsheet may be attached.
• Regulatory and Legal Feasibility: This section investigates if the proposed system conflicts with regulatory and legal requirements.
• Operational Feasibility: This involves analyzing the impact on the organization and how much change might be required in the following areas:
• Scheduling Feasibility: This component is critical in determining the feasibility of implementing the Proposed Project in the desired timeframe. It involves human resource capacity requirements, conflicts with existing projects, and other areas. 

The Feasibility Study should be completed by the PMO Manager or an assigned PM and submitted to the Project Sponsor. This is accomplished by completing the fields in the Feasibility Study of the Project Request. It should be reviewed by all affected parties. Where capital expenditures are involved, approval needs to be obtained by the appropriate party specified in the Capital Asset Policy (see the section on Approval Gates below). If approved, management should use the Feasibility Study and any accompanying support documentation to begin the planning phase.

A Feasibility Study should be done for all New Project Requests. As all projects are different, not all of the various sections of the study are applicable in every case. When any section of the Feasibility Study is not applicable, this should be indicated by stating “Not Applicable” in that section.

Project Stakeholder Identification 

Before the Planning Phase can begin it is necessary to identify all of the Project Stakeholders. It is important that all Project Stakeholders be identified at this point so that each affected area of the organization can have an opportunity to participate in shaping the direction of the project. Project Stakeholders will be listed on the Project Charter.

Corporate Security Requirements

As projects are being initiated, project sponsors are responsible for working with Corporate Security to satisfy their requirements. The PM may provide guidance to project sponsors in order to ensure that these steps a properly completed. These items are listed below.

• Vendor/Service Provider Initial Risk Assessment: All third-party vendor/service provider relationships undergo an initial risk assessment by the Vendor Relationship Manager and the Chief Information Security Officer or the Information Security Officer according to the processes set forth by the Corporate Security Department. 
• Cloud Computing Service Provider Initial Risk Assessment: Vendor Relationship Manager also needs to complete the “Cloud Computing Service Provider Initial Risk Assessment” for any vendor providing a Cloud Computing service according to the processes set forth by the Corporate Security Department. 
• Application/System Initial Risk Assessment: If an existing or preferred vendor is providing a new application or system for use by CCB associates, the “Application/System Initial Risk Assessment” is required according to the processes set forth by the Corporate Security Department. 
• Security Strategy Team: If a vendor for the project is providing a “new technology product,” it should be reviewed by the Security Strategy Team (SST), formerly known as the Technology Risk Subcommittee. The purpose of this review is to discuss data security implications of the technology, how mitigations for concerns will be managed, and whether or not the potential concerns may conflict with CCB policy.

Note: Please refer to Corporate Security Vendor Management Procedure for more most up-to-date information.

• ERM Risk Assessment:  To ensure that all of the business risks associated with undertaking the project have been properly identified with mitigating procedures in place or planned, a thorough Risk Assessment should be completed. For large projects involving significant risks, a formal Risk Assessment should be performed to identify risks relating to CCBG’s primary ERM risk categories and provide a method for both initial and ongoing risk assessment. For projects involving less risk, risks and their mitigations may be listed in the Project Charter in lieu of a formal assessment via CCBG’s ERM process. Responsibility to identify and assess project risks belongs to the Project Sponsor. There are times when the Project Sponsor will delegate another individual to do most of the work, but the Project Sponsor should thoroughly review the work and sign off on it.

There are several kinds of risks that need to be considered. Obvious risks to running a project include such things as scope creep, budget and time overruns, poor quality of project output, etc. Risks to the organization associated with the project may include items such as capital risks, operational risks, business continuity risks, regulatory risks, and market risks. A process to thoughtfully identify and mitigate all the various kinds of risks should be done as appropriate for the size and scope of the project.

• Vendor Selection and Contracts: Specifics relating to activities involving vendor selection and contract negotiation can be found in the FFIEC IT Booklets for Development and Acquisition, and for Outsourcing of Technology Services.

Copies of signed contracts should be forwarded to the Corporate Security Department.

• User Roles and Permissions for Applications: For new systems, Corporate Security will need documentation on all of the user roles and permissions. They will then determine how those roles may or may not relate to SJFCs.

Approval Gates

The purpose of Approval Gates for Project Requests is to ensure that certain individuals in the organization have an opportunity to review the Project Request from their standpoint before the project moves forward into the Planning Phase. If the keeper of any particular Approval Gate is not satisfied the Project Request conforms to the company needs from their view, they have the opportunity to reject the Project Request, which will send it back to the previous Approval Gate. The Approval Gates are as follows:

1. Gate 1 is the PMO Manager’s approval. This is the first gate when the requestor submits the request and provides the PMO Manager an opportunity to ensure that all of the needed Project Request and Business Case have been properly executed before the Feasibility Study is generated. The assigned PM can then send the Request to the next gate for further approvals.
2. Gate 2 is the Business Lines gate. It includes the manager of Corporate Security, the manager of IT Network, the company Controller, and the chairperson of the TC. This gate provides an opportunity for the gate approvers to ensure that the project request has met the security requirements, meets IT infrastructure requirements, has been properly budgeted, has sufficient value, and does not present any significant conflicts with resource constraints or other projects before approving.
3. Final Gate where the PMO manager or assigned PM gives final approval for the project to proceed.

Once all approvals for the request have been received and recorded, the assigned PM can then populate the project with data from the request in PPM Pro.

Project Charter

The Project Charter is a document that guides all of the efforts in the project. During the Initiation Phase, the PMO Manager or the assigned PM works with the Project Sponsor (and other SMEs and/or Project Stakeholders as needed) to gather information that will eventually be included in the Project Charter. Once the Request moves through the Approval Gates and reaches the final gate, the PMO Manager or assigned PM will create a Project in a “proposed” status from the Request. The Project Charter will document the Project Objectives, Project Stakeholders, scope, risks, and many other facets of the project. It should be fully developed by the end of the Planning Phase by the PM.

The Planning Phase is conducted by the assigned PM with input from the Project Sponsor and others. It includes a number of project activities including generating project requirements, selecting the members of the Project Team, generating a Work Breakdown Structure (WBS), and defining and sequencing activities. Estimating resource requirements, durations, critical path, schedule, budget are also performed during this phase. Additionally, communication plans, risk assessments, and project plans are developed. The Planning Phase concludes with the project kickoff meeting.

Project Requirements 

Before any other project work can commence, the Project Requirements need to be determined. Project Requirements should consist of a detailed list of end user requirements as well as requirements to meet the Project Objectives. This is particularly important when acquiring or building new software systems is being considered. The preferred method of solving business needs via software solutions is to use features of existing software systems.  This maximizes the value of the investment in existing software while minimizing the cost of new software, whether through acquisition or in-house development.  Only when a particular business need cannot be reasonably met by the utilization of existing software should a new software solution be considered. (Please refer to BRD Guidelines for more information.)

Project Scope

The PM uses the documents developed during the Initiation Phase and, in conjunction with the Project Requirements and in consultation with all the Project Stakeholders, documents the Project Scope in the appropriate area of the Project Charter. Project Scope defines all of the elements included in project as well as all of the elements NOT included in the project.  It is essential that Project Scope be prepared in detail and accepted by all parties in order to prevent scope creep.  By signing the Project Charter, the Project Sponsor acknowledges that any additions to the Project Scope will result in additional resources (time, money, and/or human resources) required by the Project.

Owner and SME Identification 

Projects often introduce new products, processes, and/or technologies into an organization. Once the project has concluded, responsibility for ongoing management of these things will need to be assigned. At this stage in the planning process, it is important to identify who the owners of these areas will be so that they can be included in the project and be properly trained to perform their ongoing functions.

Subject Matter Experts (SMEs) are individuals who have expertise in certain areas. The identification of these individuals is important in the planning phase as their expertise can be drawn upon as project tasks are developed. There are cases in which projects introduce new products, process, and/or technologies and there may not be an internal SME that currently exists. It is important that expertise be developed in the functional areas of the organization during the project. The organization should not come to rely on their PM as a SME.

Project Team 

The Project Team is the collection of individuals (internal associates and vendors) that are responsible for the performance of all project tasks. Project Stakeholders are sometimes asked to participate as member of the Project Team, but this is not always the case. For example, a department manager may be identified as a Project Stakeholder, but one or more associates from that department may be assigned the responsibility of performing the actual project tasks. Project Team members often include personnel from business units, Star University, Information Technology, Corporate Security, and others.

Since most (if not all) of the Project Team members do not directly report to the PM in their day-to-day functions, it is critical that the managers of the Project Team members allocate the appropriate amount of time for their associates and give the PM their full support. Issues with particular team members encountered during the execution of the implementation phase should be escalated by the PM to the team member’s manager if the PM is not able to resolve the issue themselves.

Work Breakdown Structure 

Once the various project participants have been identified, the process of identifying each activity or task can commence. For large and some medium projects, an effective method of doing this is to create a work breakdown structure (WBS). A WBS can be thought of as a continuous stream of work from the beginning to the end of the project which is broken down into manageable pieces. The process is accomplished by dividing the project into major Project Objectives and partitioning those Project Objectives into work packages and sub-work packages. The lowest level sub-work packages are the basis of individual project tasks. Estimating the task resource requirements can then be done by qualified members of the Project Team based upon their experience.

When building a WBS, the PM should begin with the Project Sponsor to identify the Project Objectives that will drive high-level work packages and to identify the related SME’s. The PM should then work with each SME to further breakdown the work packages into smaller ones. Eventually, the PM should work directly with the Project Team members to identify each task to be completed and who will likely be assigned to complete each task. The EPF does not govern the PM’s choice of tools for creating the WBS.

When contemplating the entire body of work for a project, it is important to include all impacted areas of the organization. These areas should have been identified when the Project Stakeholders were identified. Be sure to include Marketing, Corporate Security, Star University, Compliance, and Information Technology, in addition to the business units for which the project is being performed in the WBS.

Project Budget 

A high-level budget should have been estimated as part of the Feasibility Study. Now that a complete WBS has been generated, a detailed project budget can be developed. The budget should be reviewed and signed off by the Project Sponsor. Any proposed changes to the budget are subject to the project change management process discussed later in the EPF. 

Communication Plan 

Defined communication techniques enhance project efficiency. Therefore, the PM should establish procedures for gathering and disseminating information. Standard report forms, defined reporting requirements, and established meeting schedules facilitate project communications. Project Sponsors, Project Stakeholders, and Team Members all require differing levels of communication, and this should be taken into consideration as part of the Communication Plan.

Project Plan 

Planning activities are a critical aspect of project management due to the high number of interrelated project tasks. Poor planning often contributes to projects failing to meet expectations. When a good WBS has been created, it forms the basis of the project plan. For department-managed projects, the PM can effectively use internally developed spreadsheets for project plans. For PMO-managed projects, the PM should use PPM Pro. PPM Pro provides a way for the PM to link tasks together based on predecessors, track project status against a baseline, manage the project according to the critical path, and provide tracking reports.

Regardless of who manages the project, certain organizational changes are desirable as described in the Feasibility Study. It is important that the PM studies the documents from the Initiation and Planning phases and consult with Project Sponsors in order to incorporate tasks for organizational changes and other desired outcomes into the project plan.

Task Durations 

Project tasks are more easily managed the smaller their estimated duration. Therefore, if possible, no single project task should exceed one week to perform. Project tasks with estimated durations of longer than one week should be broken into smaller tasks of shorter duration when possible. This will provide the PM a way to identify and remediate project slippage more quickly. Realistic estimates should be used for project task duration. An experienced PM will allow some time in the project plan for unforeseen circumstances, but that is best managed by creating a separate task. For example, there may be a task called Conduct System Test and the estimated duration may be 6 hours. Since it is likely that problems will be encountered during the test, the PM should also create a task called something like “Remediate Testing Problems” for some appropriate duration, and then a third task called something like “Final System Test.” Planning in this manner will help avoid the temptation to pad task durations unreasonably and will more accurately predict how the project will actually run.

Deliverables

Whenever possible, project tasks should be tied to tangible deliverables. For purposes of the EPF, a deliverable can be defined as a tangible work output that can only be described as complete or not complete. Examples of deliverables might include an approved training schedule, a signed test result document, or a delivered vendor interface program. Using deliverables to define project task completion eliminates the human tendency to report a task as “90% done” or otherwise almost done. With a task either being complete or not complete, Project Team members become more accountable for their work and project slippage and remediation can take place in more timely manner. Additionally, deliverables inherently serve as documentation of completion of project tasks.

Milestones

For projects with many project tasks, the PM will often group tasks together with each group ending with a project “milestone”. (Project management software sometimes refers to these task groupings as “phases.” These project plan-level phases should not be confused with the overall EPF project phases.) Milestones provide a way for the Project Team and Project Stakeholders to observe progress and completion at multiple points during the overall duration of the project. In addition to the psychological benefit of observing milestones met, this also provides a way for Project Stakeholders to sign-off on certain portions of project completion as appropriate. Project go-live date(s) should be included in the task list (project plan) as milestone(s).

Planned Go-live Date 

Once all the tasks with their associated responsible people, estimated durations, and dependencies are entered into a project plan, the PM will be able to determine if the projected go-live date of the project meets the expectations of the Project Sponsor. If the projected go-live date is beyond expectations, the PM works with the Project Sponsor, Project Stakeholders and Project Team members to remediate the situation. Possibilities for remediation include accepting a later go-live date, eliminating certain expendable items from the project scope, and assigning additional project resources. Once an acceptable project implementation plan has been built, it should be approved by the Project Sponsor and the Project Stakeholders. 

Note: Some projects can have more than one go-live date for different milestones. In this kind of situations, PM enters the first go-live as planned go-live date and checks the multiple go-live date checkbox in PPM Pro.

Completion Criteria 

One of the dangers that the PM sometimes faces is the so-called never-ending projects. Sponsors, Project Stakeholders, Project Team members, and end-users often ask for additional things from the PM. Sometimes the PM is called upon to provide ongoing support for a project that should be considered complete. It is important to establish the criteria that, when met, the Project Sponsor will consider the project to be complete. This provides an exit strategy from the project for the PM so that their time can be allocated to subsequent projects.

Sponsor Approval of Project Charter 

Now that all of the elements of the Planning Phase have been organized and documented on the Project Charter, the PM should review the results of the work with the Project Sponsor. If all is satisfactory, the Project Sponsor should approve the Project Charter. Approval can be documented either by a physical signature or by email.

Project Kick-Off 

The Planning Phase should culminate with a project “kick-off” meeting conducted by the PM. Everyone involved in the project may attend this meeting, including the Project Sponsor, the Project Stakeholders, the Project Team members, and the managers of those individuals.  In this meeting, the PM reviews the Project Objectives, scope, members of the Project Team, and high-level milestones with all in attendance.  It is important for everyone present to buy-in to the project in order to achieve success. Approval from Project Stakeholders should be obtained. Email approval is acceptable in lieu of wet signatures.

Meetings with the Project Team should be conducted on a weekly basis unless a different interval is determined to be more effective for a particular project. Minutes from these meetings should be recorded and disseminated to team members. Additionally, project status reports should be generated and disseminated to Project Stakeholders and the Project Sponsor at least monthly, unless it is determined that a different interval is more appropriate for a particular project.

Once the project is officially “kicked-off,” the Execution Phase can begin. This is the phase of a project in which the actual project implementation tasks are performed according to the project plan. Activities performed during the Execution Phase include managing the work, quality assurance, and developing the Project Team, communication, and reporting. An important aspect of this phase is project change management.

Responsibility

The PM is responsible for satisfactory execution of the Execution Phase. Therefore, the PM should be equipped with all the knowledge, skills, and other tools required for a successful implementation. Training and experience with managing projects are essential requirements for a PM. In order to be successful, a PM will also require:

• Cooperation, support, and buy-in from management.
• A Project Team with the appropriate skills and time allocated to the project.
• Project management planning, tracking, and reporting software tools

Often a vendor that is providing software or other products and/or services will provide a PM for the project. This does not remove project management responsibility from CCBG. CCBG must still assign a qualified PM to manage the project. The CCBG PM will work with the vendor-assigned PM, and project documents provided by the vendor (project plans, timelines, etc.) will be augmented by the CCBG PM to include other tasks required by CCBG.

Project Management 

Project management for the Execution Phase consists of the following elements, each of which is described in detail below:

• Managing Project Scope
• Project Team Management
• Communication
• Tracking
• Change Control
• Security Administration
• Testing
• Training
• Implementation
• Post Implementation

Managing to Project Scope 

The value of a well-crafted Project Scope document that includes what is and is not included in the scope and has been signed by the Project Sponsor cannot be underestimated. At any point during project execution when situations arise in which someone wants to add something to the project that is not included in the Project Scope document, it is very easy to say no. The PM must not allow any tasks to be added to the project that are not within the approved scope. Additions to the scope of a project will result in some combination of additional resources, time, and/or cost. If there is a valid business reason to consider a change to the project scope, the Project Change Management process must be followed. 

Project Team Management 

Most often, members of a Project Team do not report directly to the PM. They are assigned to the project from various areas of the organization to work in a temporary Project Team. Managing the Project Team requires some special considerations in order for the team to be effective.

After the initial kick-off meeting it is often advantageous for the PM to facilitate regular and/or ad hoc team meetings with all or parts of the team as appropriate. If the team members were appropriately included in the WBS process, they should already have a certain level of buy-in to how the project is organized. The PM should clearly communicate the roles and responsibilities of each team member. At the same time, the PM needs to be sensitive to the availability of each team member to the project. Their managers may only be able to allocate them to the project for a certain percentage of their time, or only on certain days. These considerations should have been included in the project plan.

Conflict will almost certainly arise from time to time within the Project Team. While each team is different, it is important for the PM to understand the changing team dynamics: Form, Storm, Norm, and Perform. It is natural for a team to move through these phases, and it is up to the PM to guide them through it. Often a team can work through the “storms” by themselves, but there will be times when the PM will need to speak privately with certain team members to explain how their behavior may be negatively impacting the team’s performance. It is important to treat each individual with respect in order to build trust with the team. The PM should recognize and reward good performance as well as deal with the negatives.

Communication 

As noted above, the different people involved in a project require different levels of communication. The Project Sponsor and Project Stakeholders usually require status reports on some periodic basis as appropriate for the project. But they also need a forum to express any concerns to the PM. A bi-directional flow of information is best. Often, all the Project Sponsor wants to see is a very brief synopsis of the project status, while Project Stakeholders may appreciate more detail.

A good project communication plan should include:

• Project Sponsor reporting
• Project Stakeholder reporting
• Regular and ad hoc team meetings
• Meeting agendas and minutes
• The weekly project status meeting

Tracking 

In order to ensure that a project is making progress and on track to deliver, there needs to be a mechanism to monitor the progress of the project. Project tracking is a very important aspect of the responsibilities of a PMO. 

It is the project manager’s responsibility to monitor the progress of a project to assess if it is making the correct progress in order to achieve the agreed objectives or outcomes, make interventions and keep sponsors and stakeholders appraised.

PM monitors and tracks the project progress with tangible metrics such as:

• Overall RAG status
• Budget
• Milestones
• Go-live date(s)
• Achievements current period / Planned next period
• Key risks, assumptions, issues, dependencies (drawn from RAID log)

Please refer to Monitoring and Controlling Phase for more detail.

Change Control

Change control process is an important part of project execution phase and helps the flow of information when it comes to project changes. Project manager oversees all change requests to change the approved baseline of a project are captured, evaluated, and then approved, rejected, or deferred. Please refer to the Change Management Process section for more information. 

Security Administration 

Security administration is particularly important for projects in which new systems are being installed. In order to mitigate the risks relating to improper system access once implemented, the project plan should include steps to build the security administration process. All application security administration is subject to CCBG’s Corporate Security Policy and procedures. At a minimum, the implementation plan should address the following:

• Identification and training of both an application system administrator and a backup administrator,
• System parameter setup,
• Identification of end user roles and system access requirements,
• Adding the new application access requirements to existing System Job Functions, or creating new System Job Functions as needed, and
• Granting appropriate system access to end users.

Testing

In order to mitigate the risks associated with configuration of new systems, adequate functionality, accurate processing, and accurate data conversion, the importance of well-planned and thorough testing cannot be over-emphasized. Tests that are well scripted, well executed, and thoroughly reviewed are essential to a successful implementation. In the event that data is being converted from one system to another, comparing the converted data to the unconverted data and documenting the results is absolutely critical.

There are many varieties of system testing that can be performed to accomplish different purposes. Testing should be designed in consultation with IT managers in a way to mitigate the risks associated with new systems. Specifics on system testing can be found in the FFIEC IT Booklet for Development and Acquisition. Evidence of testing and Project Sponsor approval should be captured and maintained.

Note: Please refer to CCBG IT Testing Process Standard Operational Procedure for more detail about TSS Testing Procedure.

Training

Training requirements and activities should be included in the implementation plan. Proper training performed at the proper time is essential to the project at several levels. Areas to consider when formulating a training plan should include the following:

• Technical training for network and database administrators
• Administration training for application administrators
• Training for testers, including end-user training, training on performing tests, and training on verification of tests.
• Training for the end-user community at large.

Sufficient time should be allocated to Star University to develop and conduct training. End user training should be provided very shortly before go-live dates. If too much time passes between the training and the time that the acquired knowledge is utilized, the risk that the acquired knowledge will be forgotten becomes greater.

Implementation

For projects involving new systems and for certain other types of projects, the implementation portion of the project plan contains the actual cutover steps to go live and steps to be taken to verify the intended results of the implementation. Some elements to consider when formulating an implementation plan include the following:

• Bringing the new system live
• Cessation of utilization of any systems being decommissioned.
• An emergency back-out plan
• Live data conversion verification requirements
• System functionality verification requirements

Unlike some project tasks that may span a certain number of days, activities on an implementation plan are often scheduled to occur at specific times of day on implementation day. Often it can be helpful to generate a separate document to show the planned implementation “clock.” Some projects are implemented in phases and may require multiple implementation plans.  The actual project implementation will be executed according to these implementation plan(s).

Issues can arise at implementation even for well-planned and well-executed projects. In order to ensure that all problems encountered at implementation are captured and addressed, a single person should be assigned the responsibility of keeping a running list. This associate can be the PM or a member of the Project Team. The PM ensures timely resolution to each item on the problem list.

This phase of the project occurs simultaneously with the Execution Phase. As the PM manages the Project Team members to ensure that their tasks are completed on time, it is important to constantly monitor and control the progress, risks, and budget. To do this, the PM must measure and analyze project progress against the project plan and take action when slippage or other problems occur. A solid project change control process needs to be in place in order to avoid scope creep. All of this must be done with a risk-based approach.

Project execution involves a set of risks that are unique from the previous phases and include (but are not limited to):

• Scope creep
• Missed deadlines
• Communication failures
• Insufficient planning
• Unapproved project changes
• Insufficient testing
• Insufficient training
• Failed or problematic implementation

Mitigation of these and other risks requires strict control by a qualified PM through a sound and detailed project management methodology including progress tracking, budget tracking, and Open Item (action log) tracking.

Tracking progress 

The PM is responsible for clearly communicating assigned tasks and expected completion dates to the team members. The Project Team members are responsible for completing the tasks on time and reporting the status of their assigned tasks back to the PM. The PM is also responsible for making the Project Team members accountable for their tasks. This accountability can be in the form of reporting tasks not complete and why in project status meetings, private conversations between the team member, their supervisor, and the PM, etc. Project status meetings are usually held on a weekly basis unless it is determined that a different interval is more appropriate for a particular project.

Once the project plan is approved and the kick-off meeting held, the PM should save a “baseline” of the project plan. As the project progresses and things change in the plan, changes can be compared to the baseline.

Weekly Project Status Meeting 

A weekly project status meeting can be a very effective tool for motivating team members to complete their assigned tasks on time. The meeting is very short, sometimes as short as 10 minutes. Everyone involved in the project is invited to attend, although the Project Sponsor and some Project Stakeholders will likely not attend every meeting. The meeting consists of two parts. First, the list of Open Items used in the change management process is reviewed. Secondly, every task that was due to be completed that week is marked as either complete or late. There is no in-between task status. After seeing a few individuals have their tasks marked “late” in front of everyone, there is usually high motivation on the part of the team members to not have that happen to them.

Critical Path 

The PM should determine which tasks are in the project’s “critical path.” A critical path task is any task that will negatively impact the end date of the project or milestone if not completed on time. The PM should spend more effort on ensuring timely completion of critical path tasks than other tasks. However, if non-critical path tasks become too late, they can quickly end up in the critical path, so the PM must constantly be aware and manage these changes. When critical path tasks run late, the PM should take immediate corrective action to ensure that the entire project does not run late. Possible corrective actions include assigning additional resources to the late or subsequent tasks, assigning additional hours (overtime) to the team member, or shifting assignments of subsequent tasks.

Budget Tracking 

The financial costs of projects should also be tracked against the allocated budget. At CCBG, soft costs such as internal associates are not included in project budgets. Hard costs that require tracking include contracted services, hardware, software licenses and/or usage fees, maintenance fees, etc. The costs incurred and eliminated by the project should both be included in tracking project costs.

The PMO coordinates with the Financial Accounting (FA) department to track project costs. FA has assigned the PMO the range of project numbers from 9000 to 9999 in the BankTEL Accounts Payable (AP) system. These numbers are kept in a spreadsheet named Project Cost Numbers in the PMO/Projects folder. Whenever a new project that involves any kind of costs is generated, the PM will enter the name of the project in the spreadsheet so as to secure that particular number for the project. The PM will also record the project number in PPM Pro in the field named AP Project Number. Periodically the PMO Manager will send an updated copy of the spreadsheet to FA.

The PM will instruct members of their project team to code invoices and expense reports associated with the project.

• Invoices: Invoices are already coded with G/L branch, account, and cost center numbers. To associate an invoice with a project, an additional code will be added to the end of the existing coded numbers in this manner:
  xxx(branch)-xxxxxx(g/l account)-xxxx(cost center)-xxxx(project number)
• Expense Reports: The associate submitting an expense report where expenses are for a particular project will simply include “Project #xxxx” in the expense description.

The FA associates will record these numbers in the AP system. Periodically the PMO manager will export project costs from the AP system and import them into PPM Pro for project cost reporting purposes.

Change Management Process

During the implementation (execution) phase, it is very common for unforeseen problems to occur. It is also common for the PM to receive requests to perform additional tasks not included in the original project plan. Since both of these situations have the potential to cause the project to overrun either time or cost allocations or both, it is critical that there be a process in place to control any changes to the project.

The term “Open Item” refers to any unresolved item not included in the project plan. Unforeseen issues, action Items, questions, risks and requests for changes are all considered Open Items and should be maintained in the Project Log, or Open Items List. The PM is responsible for maintaining a list of all Open Items and for seeing the resolution of each Open Item before the end date of the implementation. The Project Log should document the nature of the Open Item, its origin and origin date, and whether or not the scope is affected by the Open Item. No changes in project scope should ever be implemented without an analysis of the project impact in terms of time and cost, and without the approval of the Project Sponsor. Many Open Items can be resolved without altering the implementation project plan itself. Open Items that increase the scope of the project should result in additional project tasks ONLY after thorough evaluation and approval by the Project Sponsor and Project Stakeholders.

Note: Please refer to Project Change Management Procedure for more detail.

Risk Management

Project Risk is “a future event that may or may not happen which, if it does happen, will have some impact on the objectives of the project. It could be positive—an opportunity, or negative—a threat.” Project managers are responsible for overseeing the risk management process throughout the duration of the project.

There are essential steps of the Risk Management Process:

1. Identify the risks that could potentially impact the project.
2. Analyze each risk to fully understand the driving factors involved and potential impacts. 
3. Prioritize project risks according to urgency and the severity of the impact they could cause. 
4. Assign ownership of each identified risk to a team member who will be charged with overseeing that threat or opportunity. 
5. Respond to the identified risks in accordance with the risk management approach, either by taking steps to prevent the risk event from occurring or to minimize the impact if it does occur. 
6. Monitor and Report on the risk.

Risk management is an ongoing effort throughout the project.

Note: Please refer to Project Risk Management Procedure for more detail.

The Closing phase is the last phase of the project. Activities performed in the Closing Phase include project handoff, confirmation of project requirements, project acceptance, gathering feedback, performance reporting, documenting lessons learned, and ongoing monitoring and measuring for BRM.

Project Handoff

In order to gracefully exit the project, the PM should plan for ensuring that whatever change was implemented by the project will be appropriately administered and maintained. This includes things such as identifying and ensuring the training of system administrators, integration of new security requirements into existing processes, management of new processes, etc. These responsibilities should be handed off to the Product/ Technology/ Process Owners who were identified and trained during the course of the project.

Transition and Service Design Document

The Transition process prepares operations to assume responsibility for maintaining and supporting the new solution. If not planned and executed appropriately, Project teams run the risk of becoming lost in transition when the new product/service/technology is not properly transitioned to an operation support team.

For effective shift of responsibilities, the Project Team must provide those responsible for system support with a combination of technical documentation, training, and hands-on assistance to enable them to provide an acceptable level of operational support to the end-users. 

Successful transition is key to sustainable benefit realization and Return on Investment for projects. The Project Manager oversees the transition process and sets the completed project for long term success.

Project Manager works with TSS, project team and stakeholders to complete the Service Design Document before the hand-over. Due to the technical nature of the Service Design Document, it should be completed by the operation team with the input of SMEs and Stakeholders.

Acceptance 

There should be a final exit meeting of the Project Sponsor and Project Stakeholders. This meeting will be used to ensure that the Project Objectives were successfully met as well as to document any project deficiencies and to plan for dealing with those deficiencies. A plan should be put in place to address any lingering issues. Upon satisfactory review of the project, approvals should be obtained from the Project Stakeholders and the Project Sponsor. Additionally, the PM should report on how the previously defined acceptance criteria were met. Having met all of these requirements, the Project Sponsor should give final sign-off to the completion of the project.

Feedback and Performance Reporting 

In an effort to continually improve the performance of the PMO, the PM should survey the Project Sponsor, Project Stakeholders, and team members to get their feedback on how the project went and their suggestions for improvement. The input should be gathered and summarized into a report suitable for distribution to all who participated.

The PM should analyze the effectiveness of the project management activities by comparing, among other things, planned and actual costs, benefits, and development times. They should document the results and present them to the Project Sponsor.

Lessons Learned 

In addition to feedback from others, the PM should maintain a list of lessons learned throughout the project. This list will be kept as an internal document for the PMO to periodically review for the purpose of learning from others and continual performance improvement.

Ongoing Monitoring and Measuring 

Often, it takes time to see whether or not certain Project Objectives were actually met. For example, an objective to reduce costs by a certain amount by a specified date cannot be measured until that date. The PM is responsible to ensure that the Project Sponsor has defined an appropriate way to measure and report the project benefits as described in the Project Objectives and that an entry describing these activities is entered into the Project Log with a type of BRM and an end date for the measuring. The actual measuring and reporting is then performed as described in the Benefits Realization after the project is closed.

Final Sponsor Approval 

Once all Closing Phase tasks are complete, the Project Sponsor approves the project as Closed. This approval can be either by physical signature on the Project Charter or by email.

With the approval of the closure of the project, new system/technology/product is considered “closed” and transitioned to operation/support team. All changes, requests and maintenance activities will be performed by support team and governed by the TSS SOPs.

Routine System Upgrade form:

1. Upgrade description fields
2. Identify upgrade Project Stakeholders
3. Identify resources required
4. Risks, mitigations, and back-out plan
5. Bit9 approval from IT Network
6. Desired time frame
7. Approval (usually a department manager)

1. Project Request
2. Business Case
3. Feasibility Study
4. Small Project Charter
   • Project Team Organization
   • Project Scope
   • Risk Assessment
   • Project Plans
   • Project Execution
   • Project Review

Initiation Phase – Performed by Project Sponsor (with Exceptions as Noted) 

1. Contact the PMO.
2. Complete a Project Request.
   • Problem Statement
   • Project Description
   • Strategic Alignment
   • Project Objectives
   • Project Category
   • Assess Current Environment
   • Identify Project Stakeholders
   • Estimated Budget
   • Potential Time Frame
   • Business Case
   • Request Scoring
   • Submit Request
3. Gate 1: PMO Assesses if Feasibility is needed
   • Feasibility Study (performed by PMO, work with Sponsors)
   • Obtain approval of Business Case and/or Feasibility Study (from approval authority)
   • Corporate Security Requirements
     • Perform Vendor Risk Assessment
     • Perform ERM Risk Assessment
     • SST Review (New Technology Products)
     • Select Vendor(s) and Negotiate Contract(s)
     • User Roles and Permissions for Applications
4. Gates 2: Business Lines
   • Corporate Security, Compliance, IT Networking, Controller, Technology Committee
5. Final Gate Approval (performed by PMO Manager)
6. Sign Contracts
7. Forward Signed Contract Copies to Corporate Security
8. Final Gate Approval (performed by PMO Manager)
9. Create Project and Assign PM (performed by PMO Manager)

Planning Phase - Performed by Project Sponsor and PM

1. Determine Project Requirements.
2. Determine Project Scope.
3. Identify Product/Process/Technology Owners and SMEs.
4. Identify Project Team.
5. Create Work Breakdown Structure - Always consider the following:
   • Training Needs (technical, admins, testers, end users)
   • Marketing (clients and associates)
   • Compliance
   • Changes to Departmental Processes and Procedures
   • Reporting (Who, What, Client Feedback, When, Where, How)
   • Enforcement (driving adoption of change)
   • Network (People, Capacity, Bit9, etc.)
   • Security (System Admins, System Parameters, SJFCs, System Access and Exceptions)
   • System Administration and Maintenance
   • Implementation
6. Determine Project Budget.
7. Generate Communication Plan.
8. Generate Project Plan.
9. Generate Completion Criteria.
10. Obtain Project Sponsor approval of the Project Charter.
11. Hold the Project Kick-Off Meeting.

Execution Phase - Performed by PM

1. Execute the Project Plan.
2. Hold regular Project Team meetings.
3. Execute Communication Plan
4. Execute Test Plan (if applicable).
5. Obtain Project Sponsor approval of testing (if applicable).
6. Obtain Project Sponsor approval to implement.
7. Implement the project.
8. Obtain completed implementation clock.

Monitoring and Controlling Phase - Performed by PM

1. Perform progress tracking.
   • Regular Updates to Project Plan
   • Weekly Project Status Meeting
   • Critical Path
2. Perform budget tracking.
3. Perform change control.
   • Open Items List
   • Project Sponsor Approval of Any Changes to Scope

Closing Phase - Performed by PM

1. Facilitate project handoff.
2. Obtain project acceptance.
3. Obtain feedback and provide performance reporting.
4. Document and share lessons learned.
5. Facilitate ongoing monitoring and measuring (BRM).
6. Obtain final project sponsor approval on Project Charter.

Benefits Realization

1. Generate reporting reminders to Project Sponsors.
2. Collect report from Project Sponsors and/or other assigned associates.
3. Report to the Technology Committee.