VIDYA SYSTEMS

#46, 1st Floor, Y.M.S. Complex,

HMT Main Road, Mathikere,
Bangalore
Centre Code: 00023

PROJECT MANAGEMENT FOR

HEALTH AND WELFARE MODULE
EXECUTED ON ORACLE PLATFORM
By
VINAYASHREE K.A

A project report submitted in partial fulfillment of the requirements for

the degree of Master of Business Administration during 2012 of
Sikkim Manipal University, INDIA

Sikkim-Manipal University of Health, Medical and Technological

Sciences,
Distance Education Wing
Syndicate House, Manipal – 576104
 STUDENT DECLARATION

I hereby declare that the project report entitled

PROJECT MANAGEMENT FOR

HEALTH AND WELFARE MODULE
EXECUTED ON ORACLE PLATFORM

Submitted in partial fulfillment of the requirements for the degree of

Masters of Business Administration

To Sikkim-Manipal University, India, is my original work and not

submitted for the award of any other Degree, Diploma, Fellowship, or

any other similar title or prizes

Place: Bangalore VINAYASHREE .K.A.

Date: 25 – May 2012 Reg. No: 510913025
 EXAMINER’S CERTIFICATION

The project report of

VINAYASHREE .K.A.

“PROJECT
MANAGEMENT FOR
HEALTH AND WELFARE MODULE
EXECUTED ON ORACLE PLATFORM”

Is approved and is acceptable in quality and form

Internal Examiner External Examiner

(Name, Qualification and Designation) (Name, Qualification and
Designation)
 UNIVERSITY STUDY CENTRE CERTIFICATE

This is to certify that the project report entitled

PROJECT MANAGEMENT FOR

HEALTH AND WELFARE MODULE
EXECUTED ON ORACLE PLATFORM

Submitted in partial fulfillment of the requirements for the degree of

Masters of Business Administration of Sikkim-Manipal University of

Health, Medical and technological sciences

Vinayashree .K.A.

has worked under my supervision and guidance and that no part of this

report has been submitted for the award of any other Degree, Diploma,

Fellowship or other similar titles or prizes and that the work has not

been published in any journal or magazine.

Rag No: 510913025 Certified

Guide’s Name and Qualification

 PROJECT COMPLETION CERTIFICATE

Certified that this project report titled “Project Management For

Health and Welfare Module Executed On Oracle Platform” is
the work of Vinayashree K.A. who carried out the work under
our supervision, from the period ranging from April 2012 to
May 2012. This is towards the partial fulfillment requirement
for the MBA Degree.

Place: Bangalore Sudheshna M

Date: May 25 2012 HR Manager
 ACKNOWLEDGEMENT

I would like to express my immense gratitude to Pranab Majumdar for

his/her guidance, continuous encouragement and valuable suggestion at
every stage of my project.

I am very thankful to Mrs. Radha Karanth for her co-operation in the

course of my study.

I would like to thank Sudheshna M, Manager-HR, Bangalore for giving

me the opportunity to conduct the study and for his valuable suggestions
and comments.

I extend my deep sense of gratitude to all my Friends and Family who

have directly or indirectly encouraged and helped me to complete my
project successfully.

VINAYASHREE .K.A

Reg. No: 510913025

PREFACE
Employers face many challenges in delivering Health & Welfare benefits
today:

Staying ahead of legislative and regulatory changes

Maintaining compliance with new administrative requirements

Developing plan design strategies to serve diverse employee

populations

Engaging employees to make good decisions and better manage

their health

Finding solutions to these challenges is critical to achieving sustainable

results with your benefits programs. Skyrocketing health care costs,
retirement readiness uncertainties, and shifting workforce demographics
have changed the face of corporate benefits programs.

Any Organization that is enabled to provide these benefits and wellness

services should also look at effectively serving employees and achieve
cost-reduction strategies for the Client Companies.

Employer sponsored health insurance is paid for by businesses on behalf

of their employees as part of an employee benefit package. The employer
typically makes a substantial contribution towards the cost of coverage.

The following project gives an overview of project management

during New Client Implementation carried out by an Organization called
Fidelity Business Services India Pvt Ltd also known as FMR India .The
team responsible for doing this Implementation is called the H&W
Implementation team. This team would help configure H&W product for
the approached client organization. The team’s responsibilities include
requirements gathering (client facing), analyzing and defining solutions
with the help of solution architects, ensuring adherence to Fidelity
Standards, negotiating with clients towards the same, documenting and
publishing final requirements to internal teams and configuring the
platform, migrating data for new implementations and large corporate
actions. The team also validates configuration from business perspective,
supports client testing, and completes the client hands over to ongoing
client services teams.

In brief, bringing new clients on HW platform or adding acquired

population on the HW platform for existing clients is the business of the
New Client Implementation team.
ORGANIZATION
PROFILE
Fidelity Investments is one of the world’s largest providers of
financial services. It is the leading provider of investment
management, retirement planning, portfolio guidance, brokerage,
benefits outsourcing and many other financial products and
services to individuals and institutions. FMR (Fidelity Marketing
and Research) India is the flagship captive unit of Fidelity US.
FMR India collaborates with its parent organization in
strengthening Fidelity’s endeavors to enable clients in achieving
lifelong financial independence and peace of mind.

To provide all round efficient service to Fidelity Investments US

clients, FMR India has segregated its operations into Technology
services, Enterprise Delivery Solutions, Human Resources and
Finance. The range of operations include IT development &
support, Business Process Outsourcing, Implementation and
Business Analytics and Research.

The Enterprise Delivery Solutions (EDS) group supports 17

Fidelity Business Partners and offers a wide spectrum of services.
The EDS group caters to different groups such as Asset
Management, Fidelity Institutional Business and Personal
Workplace Investing.

The New Client Implementation team that was mentioned

previously falls under the Enterprise Delivery Solutions group.
 TABLE OF CONTENTS

CHAPTER NO. TITLE PAGE NO.

1. INTRODUCTION
1.1 History of Project Management 05
1.2 Project Management Approaches. 06
1.2.1 The Traditional Approach 06
1.2.2 Critical Chain Project Management 08
Extreme Project
1.2.3 Management 08
1.2.4 Event Chain Methodology 09
1.2.5 PRINCE 2 10
1.3 Process Based Management 11
1.4 Project Management Process 11
1.4.1 Initiation 12
1.4.2 Planning and Design 13
1.4.3 Executing 14
1.4.4 Monitoring and Controlling 14
1.4.5 Closing 16
1.5 Project Control Systems 17
1.6 Software Testing 17
Software Verification and
1.7 Validation 19
2. SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) DURING
NEW CLIENT
IMPLEMENTATIO
N 20
2.1 Project Kickof 21
2.2 Project Management Phases 21
2.3 Project Life Cycle Definition 22
2.4 Solution Confirmation/Configuration/
Development 24
2.5 Project Transition to Ongoing 26
2.6 Roles and Responsibilities 27
 2.7 Ensuring Resource Coverage 28
2.8 Project Governance 28
3. RESOURCE MANAGEMENT 30
4. SCHEDULE MANAGEMENT 31
4.1 Project Timeline 32
4.2 Critical Milestones Status 33
5. SCOPE MANAGEMENT 34
5.1 Change Control Process 34
6 QUALITY MANAGEMENT 36
6.1 Validation 37
6.2 Defect Process 38
7. RISK MANAGEMENT 40
7.1 Failure Mode and Efects Analysis 40
8. COMMNICATION MANAGEMENT 41
8.1 Meeting Overview 42
8.2 PMO Communication Tools 43
8.3 Escalation Protocols 44
8.4 Resolving Escalations 45
CONCLUSION
9. S 46
Recommendations 46
REFERENCES 48
 LIST of TABLES

TABLE NAME PAGE NO

Table 1: Project Management Phases 21

Table 2: Health and Welfare Implementation Process 22
Table 3: Implementation Release Contents Template 25
Table 4: Associate Back up Table 28
Table 5: Testing Types 37
Table 6: Ongoing Communication 42
Table 7: Communication Tools 43
Table 8: Escalation Levels 45
 LIST OF FIGURES

FIGURE NAME PAGE NO

Figure 1: Typical Development Phases 07
Figure 2: Planning and Feedback loops 09
Figure 3: The PRINCE2 process model 10
Figure 4: Capability Model 11
Figure 5: Project Management Process 12
Figure 6: Initiating Process Group Processes 12
Figure 7: Planning Process Group Activities 13
Figure 8: Executing Process Group Processes 14
Figure 9: Monitoring and Controlling Process Group Processes 15
Figure 10: Closing Process Group Processes 16
Figure 11: Project Governance 29
Figure 12: H&W Implementation Team Structure 30
Figure 13: Weekly Schedule Management Process 32
Figure 14: Project Timeline 32
Figure 15: Defect Process Flow 39

4
 CHAPTER 1: INTRODUCTION

1.1 History of project management

Project management has been practiced since early civilization. Until

1900 civil engineering projects were generally managed by creative
architects and engineers themselves, among those for example Vitruvius
(1st century BC), Christopher Wren (1632–1723) , Thomas Telford
(1757-1834) and Isambard Kingdom Brunel (1806–1859) [6] It was in the
1950s that organizations started to systematically apply project
management tools and techniques to complex projects.[7]

As a discipline, Project Management developed from several fields of

application including construction, engineering, and defense activity.[8]
Two forefathers of project management are Henry Gantt, called the father
of planning and control techniques[9], who is famous for his use of the
Gantt chart as a project management tool; and Henri Fayol for his
creation of the 5 management functions which form the foundation of the
body of knowledge associated with project and program management.
[10] Both Gantt and Fayol were students of Frederick Winslow Taylor's
theories of scientific management. His work is the forerunner to modern
project management tools including work breakdown structure (WBS)
and resource allocation.

The 1950s marked the beginning of the modern Project Management era.
Project management became recognized as a distinct discipline arising
from the management discipline.[11] In the United States, prior to the
1950s, projects were managed on an ad hoc basis using mostly Gantt
Charts, and informal techniques and tools. At that time, two mathematical
project-scheduling models were developed. The "Critical Path Method"
(CPM) was developed as a joint venture between DuPont Corporation and
Remington Rand Corporation for managing plant maintenance projects.
And the "Program Evaluation and Review Technique" or PERT, was
developed by Booz-Allen & Hamilton as part of the United States Navy's
(in conjunction with the Lockheed Corporation) Polaris missile submarine
program;[12] These mathematical techniques quickly spread into many
private enterprises.

At the same time, as project-scheduling models were being developed,

technology for project cost estimating, cost management, and engineering
economics was evolving, with pioneering work by Hans Lang and others.
In 1956, the American Association of Cost Engineers (now AACE
International; the Association for the Advancement of Cost Engineering)
was formed by early practitioners of project management and the
associated specialties of planning and scheduling, cost estimating, and
cost/schedule control (project control). AACE continued its pioneering
work and in 2006 released the first integrated process for portfolio,
program and project management (Total Cost Management Framework).

The International Project Management Association (IPMA) was founded

in Europe in 1967, [13] as a federation of several national project
management associations. IPMA maintains its federal structure today and
now includes member associations on every continent except Antarctica.
IPMA offers a Four Level Certification program based on the IPMA
Competence Baseline (ICB).[14] The ICB covers technical competences,
contextual competences, and behavioral competences.

In 1969, the Project Management Institute (PMI) was formed in the USA.
[15] PMI publishes A Guide to the Project Management Body of
Knowledge (PMBOK Guide), which describes project management
practices that are common to "most projects, most of the time." PMI also
offers multiple certifications.
The AAPM American Academy of Project Management International
Board of Standards 1996 was the first to institute post-graduate
certifications such as the MPM Master Project Manager, PME Project
Management E-Business, CEC Certified-Ecommerce Consultant, and
CIPM Certified International project Manager. The AAPM also issues the
post-graduate standards body of knowledge for executives.

1.2 Project management approaches

There are a number of approaches to managing project activities

including agile, interactive, incremental, and phased approaches.
Regardless of the methodology employed, careful consideration must be
given to the overall project objectives, timeline, and cost, as well as the
roles and responsibilities of all participants and stakeholders.

1.2.1 The traditional approach

A traditional phased approach identifies a sequence of steps to be

completed. In the "traditional approach", we can distinguish 5
components of a project (4 stages plus control) in the development of a
project:
 Figure 1: Typical Development Phases

Typical development phases of a project

Project initiation stage;

Project planning or design stage;

Project execution or production stage;

Project monitoring and controlling systems;

Project completion stage.

Not all the projects will visit every stage as projects can be
terminated before they reach completion. Some projects do not
follow a structured planning and/or monitoring stages. Some
projects will go through steps 2, 3 and 4 multiple times.

Many industries use variations on these project stages. For

example, when working on a brick and mortar design and
construction, projects will typically progress through stages like
Pre-Planning, Conceptual Design, Schematic Design, Design
Development, Construction Drawings (or Contract Documents),
and Construction Administration. In software development, this
approach is often known as the waterfall model[16], i.e., one series
of tasks after another in linear sequence. In software development
many organizations have adapted the Rational Unified Process
(RUP) to fit this methodology, although RUP does not require or
explicitly recommend this practice. Waterfall development works
well for small, well defined projects, but often fails in larger
projects of undefined and ambiguous nature. The Cone of
Uncertainty explains some of this as the planning made on the
initial phase of the project suffers from a high degree of
uncertainty. This becomes especially true as software development
is often the realization of a new or novel product. In projects where
requirements have not been finalized and can change, requirements
management is used to develop an accurate and complete definition
of the behavior of software that can serve as the basis for software
development[17]. While the terms may differ from industry to
industry, the actual stages typically follow common steps to
problem solving — "defining the problem, weighing options,
choosing a path, implementation and evaluation."

1.2.2 Critical Chain Project Management

Critical Chain Project Management (CCPM) is a method of

planning and managing projects that puts more emphasis on the
resources (physical and human) needed in order to execute project
tasks. It is an application of the Theory of Constraints (TOC) to
projects. The goal is to increase the rate of throughput (or
completion rates) of projects in an organization. Applying the first
three of the five focusing steps of TOC, the system constraint for
all projects is identified as are the resources. To exploit the
constraint, tasks on the critical chain are given priority over all
other activities. Finally, projects are planned and managed to
ensure that the resources are ready when the critical chain tasks
must start, subordinating all other resources to the critical chain.

Regardless of project type, the project plan should undergo

Resource Leveling, and the longest sequence of resource-
constrained tasks should be identified as the critical chain. In
multi-project environments, resource leveling should be performed
across projects. However, it is often enough to identify (or simply
select) a single "drum" resource—a resource that acts as a
constraint across projects—and stagger projects based on the
availability of that single resource.

Planning and feedback loops in Extreme Programming (XP) with

the time frames of the multiple loops.

1.2.3 Extreme Project Management

In critical studies of Project Management, it has been noted that

several of these fundamentally PERT-based models are not well
suited for the multi-project company environment of today.
[citation needed] Most of them are aimed at very large-scale, one-
time, non-routine projects, and nowadays all kinds of management
are expressed in terms of projects.

Using complex models for "projects" (or rather "tasks") spanning a

few weeks has been proven to cause unnecessary costs and low
maneuverability in several cases[citation needed]. Instead, project
management experts try to identify different "lightweight" models,
such
as Agile Project Management methods including Extreme
Programming for software development and Scrum techniques.
Figure 2: Planning and Feedback loops

The generalization of Extreme Programming to other kinds of

projects is extreme project management, which may be used in
combination with the process modeling and management
principles of human interaction management.

1.2.4 Event chain methodology

Event chain methodology is another method that complements

critical path method and critical chain project management
methodologies.

Event chain methodology is an uncertainty modeling and schedule

network analysis technique that is focused on identifying and
managing events and event chains that affect project schedules.
Event chain methodology helps to mitigate the negative impact of
psychological heuristics and biases, as well as to allow for easy
modeling of uncertainties in the project schedules. Event chain
methodology is based on the following principles:

Probabilistic moment of risk: An activity (task) in most

real life processes is not a continuous uniform process. Tasks
are affected by external events, which can occur at some
point in the middle of the task.

Event chains: Events can cause other events, which will

create event chains. These event chains can significantly
affect the course
of the project. Quantitative analysis is used to determine a
cumulative effect of these event chains on the project
schedule.

Critical events or event chains: The single events or the

event chains that have the most potential to affect the
projects are the
―critical events‖ or ―critical chains of events.‖ They can be
determined by the analysis.

Project tracking with events: Even if a project is partially

completed and data about the project duration, cost, and
events occurred is available, it is still possible to refine
information about future potential events and helps to
forecast future project performance.
 Event chain visualization: Events and event chains can be
visualized using event chain diagrams on a Gantt chart.

1.2.5 PRINCE2
PRINCE2 is a structured approach to project management, released
in 1996 as a generic project management method.[18] It combined
the original PROMPT methodology (which evolved into the
PRINCE methodology) with IBM's MITP (managing the
implementation of the total project) methodology. PRINCE2
provides a method for managing projects within a clearly defined
framework. PRINCE2 describes procedures to coordinate people
and activities in a project, how to design and supervise the project,
and what to do if the project has to be adjusted if it does not
develop as planned.

Figure 3: The PRINCE2 process model

In the method, each process is specified with its key inputs and
outputs and with specific goals and activities to be carried out. This
allows for automatic control of any deviations from the plan.
Divided into
manageable stages, the method enables an efficient control of
resources. On the basis of close monitoring, the project can be
carried out in a controlled and organized way.

PRINCE2 provides a common language for all participants in the

project. The various management roles and responsibilities
involved in a project are fully described and are adaptable to suit
the complexity of the project and skills of the organization.

1.3 Process-based management

Figure 4: Capability Model

Capability Maturity Model, predecessor of the CMMI Model

Also furthering the concept of project control is the incorporation

of process-based management. This area has been driven by the
use of Maturity models such as the CMMI (Capability Maturity
Model Integration) and ISO/IEC15504 (SPICE - Software Process
Improvement and Capability Estimation).
Agile Project Management approaches based on the principles of
human interaction management are founded on a process view of
human collaboration. This contrasts sharply with the traditional
approach. In the agile software development or flexible product
development approach, the project is seen as a series of relatively
small tasks conceived and executed as the situation demands in an
adaptive manner, rather than as a completely pre-planned process.

1.4 Project Management Processes

Traditionally, project management includes a number of elements:
four to five process groups, and a control system. Regardless of the
methodology or terminology used, the same basic project
management processes will be used.

Figure 5: Project Management Process

The project development stages Major process groups generally

include: Initiation
Planning or development
Production or execution
Monitoring and controlling
Closing

In project environments with a significant exploratory element

(e.g., Research and development), these stages may be
supplemented with decision points (go/no go decisions) at which
the project's continuation is debated and decided. An example is
the Stage-Gate model.

1.4.1 Initiation

Figure 6: Initiating Process Group

Processes

The initiation processes determine the nature and scope of the

project. If this stage is not performed well, it is unlikely that the
project will be successful in meeting the business needs. The key
project controls needed here are an understanding of the business
environment and making sure that all necessary controls are
incorporated into the project. Any deficiencies should be reported
and a recommendation should be made to fix them.

The initiation stage should include a plan that encompasses the

following areas:
Analyzing the business needs/requirements in measurable
goals

Reviewing of the current operations

Financial analysis of the costs and benefits including a
budget

Stakeholder analysis, including users, and support personnel

for the project
Project charter including costs, tasks, deliverables, and
schedule
 1.4.2 Planning and design

Figure 7: Planning Process Group

Activities

After the initiation stage, the project is planned to an appropriate

level of detail. The main purpose is to plan time, cost and resources
adequately to estimate the work needed and to effectively manage
risk during project execution. As with the Initiation process group,
a failure to adequately plan greatly reduces the project's chances of
successfully accomplishing its goals.

Project planning generally consists of

Determining how to plan (e.g. by level of detail or rolling
wave);

Developing the scope statement;

Selecting the planning team;

Identifying deliverables and creating the work breakdown

structure;

Identifying the activities needed to complete those

deliverables and networking the activities in their logical
sequence;
 Estimating the resource requirements for the activities;
estimating time and cost for

Activities; developing the

schedule;
Developing the
budget; risk
planning;
Gaining formal approval to begin work.

Additional processes, such as planning for communications and for

scope management, identifying roles and responsibilities,
determining what to purchase for the project and holding a kick-off
meeting are also generally advisable.

For new product development projects, conceptual design of the

operation of the final product may be performed concurrent with
the project planning activities, and may help to inform the planning
team when identifying deliverables and planning activities.

1.4.3 Executing

Figure 8: Executing Process Group

Processes
Executing consists of the processes used to complete the work
defined in the project management plan to accomplish the project's
requirements. Execution process involves coordinating people and
resources, as well as integrating and performing the activities of the
project in accordance with the project management plan. The
deliverables are produced as outputs from the processes performed
as defined in the project management plan.

1.4.4 Monitoring and controlling

Monitoring and controlling consists of those processes performed

to observe project execution so that potential problems can be
identified in a timely manner and corrective action can be taken,
when necessary, to control the execution of the project. The key
benefit is that project performance is observed and measured
regularly to identify variances from the project management plan.

Figure 9: Monitoring and Controlling Process Group

Processes
Monitoring and Controlling includes:
Measuring the ongoing project activities ('where we are');
Monitoring the project variables (cost, effort, scope, etc.)
against the project management plan and the project
performance baseline (where we should be);
Identify corrective actions to address issues and risks
properly (How can we get on track again);
Influencing the factors that could circumvent integrated
change control so only approved changes are implemented

In multi-phase projects, the monitoring and controlling process also

provides feedback between project phases, in order to implement
corrective or preventive actions to bring the project into
compliance with the project management plan.

Project Maintenance is an ongoing process, and it

includes: Continuing support of end users
Correction of errors

Updates of the software over time

In this stage, auditors should pay attention to how effectively and

quickly user problems are resolved.
Over the course of any construction project, the work scope may
change. Change is a normal and expected part of the construction
process. Changes can be the result of necessary design
modifications, differing site conditions, material availability,
contractor-requested changes, value engineering and impacts from
third parties, to name a few. Beyond executing the change in the
field, the change normally needs to be documented to show what
was actually constructed. This is referred to as Change
Management. Hence, the owner usually requires a final record to
show all changes or, more specifically, any change that modifies
the tangible portions of the finished work. The record is made on
the contract documents – usually, but not necessarily limited to, the
design drawings. The end product of this effort is what the industry
terms as-built drawings, or more simply, ―as built.‖ The
requirement for providing them is a norm in construction contracts.

When changes are introduced to the project, the viability of the

project has to be re-assessed. It is important not to lose sight of the
initial goals and targets of the projects. When the changes
accumulate, the forecasted result may not justify the original
proposed investment in the project.

1.4.5 Closing

Figure 10: Closing Process Group Processes.

Closing includes the formal acceptance of the project and the
ending thereof. Administrative activities include the archiving of
the files and documenting lessons learned.

This phase consists of:

Project close: Finalize all activities across all of the process
groups to formally close the project or a project phase

Contract closure: Complete and settle each contract

(including the resolution of any open items) and close each
contract applicable to the project or project phase
1.5 Project control systems

Project control is that element of a project that keeps it on-track,

on-time and within budget. Project control begins early in the
project with planning and ends late in the project with post-
implementation review, having a thorough involvement of each
step in the process. Each project should be assessed for the
appropriate level of control needed: too much control is too time
consuming, too little control is very risky. If project control is not
implemented correctly, the cost to the business should be clarified
in terms of errors, fixes, and additional audit fees.

Control systems are needed for cost, risk, quality, communication,

time, change, procurement, and human resources. In addition,
auditors should consider how important the projects are to the
financial statements, how reliant the stakeholders are on controls,
and how many controls exist. Auditors should review the
development process and procedures for how they are
implemented. The process of development and the quality of the
final product may also be assessed if needed or requested. A
business may want the auditing firm to be involved throughout the
process to catch problems earlier on so that they can be fixed more
easily. An auditor can serve as a controls consultant as part of the
development team or as an independent auditor as part of an audit.

Businesses sometimes use formal systems development processes.

These help assure that systems are developed successfully. A
formal process is more effective in creating strong controls, and
auditors should review this process to confirm that it is well
designed and is followed in practice. A good formal systems
development plan outlines:
A strategy to align development with the organization‘s
broader objectives
Standards for new systems
Project management policies for timing and budgeting
Procedures describing the process
Evaluation of quality of
change
1.6 Software Testing

Software testing is an investigation conducted to provide

stakeholders with information about the quality of the product or
service under test.[1] Software testing also provides an objective,
independent view of the software to allow the business to
appreciate and understand the risks at implementation of the
software. Test techniques include, but are not limited to, the
process of executing a program or application with the intent of
finding software bugs.

Software testing can also be stated as the process of validating and

verifying that a software program/application/product:

1. meets the business and technical requirements that guided its

design and development;
2. works as expected; and
3. Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can

be implemented at any time in the development process. However,
most of the test effort occurs after the requirements have been
defined and the coding process has been completed. As such, the
methodology of the test is governed by the software development
methodology adopted.

Different software development models will focus the test effort at

different points in the development process. Newer development
models, such as Agile, often employ test driven development and
place an increased portion of the testing in the hands of the
developer, before it reaches a formal team of testers. In a more
traditional model, most of the test execution occurs after the
requirements have been defined and the coding process has been
completed.

Testing can never completely identify all the defects within

software. Instead, it furnishes a criticism or comparison that
compares the state and behavior of the product against oracles—
principles or mechanisms by which someone might recognize a
problem. These oracles may include (but are not limited to)
specifications, contracts,[2] comparable products, past versions of
the same product, inferences about intended or expected purpose,
user or customer expectations, relevant standards, applicable laws,
or other criteria.

Every software product has a target audience. For example, the

audience for video game software is completely different from
banking software. Therefore, when an organization develops or
otherwise invests in a software product, it can assess whether the
software product will be acceptable to its end users, its target
audience, its purchasers, and other stakeholders. Software testing is
the process of attempting to make this assessment.

A study conducted by NIST in 2002 reports that software bugs cost

the U.S. economy $59.5 billion annually. More than a third of this
cost could be avoided if better software testing was performed.
The separation of debugging from testing was initially introduced
by Glenford J. Myers in 1979. Although his attention was on
breakage testing ("a successful test is one that finds a bug") it
illustrated the desire of the software engineering community to
separate fundamental development activities, such as debugging,
from that of verification. Dave Gelperin and William C. Hetzel
classified in 1988 the phases and goals in software testing in the
following stages:
Until 1956 - Debugging oriented
1957–1978 - Demonstration oriented
1979–1982 - Destruction oriented
1983–1987 - Evaluation oriented
1988–2000 - Prevention oriented

1.7 Software verification and validation

Software testing is used in association with verification and

validation

Verification: Have we built the software right? (i.e., does it

match the specification).

Validation: Have we built the right software? (i.e., is this

what the customer wants).

The terms verification and validation are commonly used

interchangeably in the industry; it is also common to see these two
terms incorrectly defined. According to the IEEE Standard
Glossary of Software Engineering Terminology:

Verification is the process of evaluating a system or component to

determine whether the products of a given development phase
satisfy the conditions imposed at the start of that phase.

Validation is the process of evaluating a system or component

during or at the end of the development process to determine
whether it satisfies specified requirements.
 CHAPTER 2: SOFTWARE DEVELOPMENT LIFE
CYCLE
(SDLC) DURING NEW CLIENT IMPLEMENTATION
Fidelity uses FSDM (Fidelity Systems Development Lifecycle) as
its System development Life Cycle in all system related
developments projects. FSDM is a highly successful and
comprehensive approach to system development and has been
utilized across a wide range of system development efforts. FSDM
is based on Agile methodology, which includes:
Rolling wave planning
Iterative and incremental system development
Ongoing refinement of project scope, resource allocation and
project schedule.
Each iteration goes through the entire system development
life cycle.
Incremental system demonstration to the
client. Daily iteration and communication of
team members.
Integrated quality assurance of all internal and external
development efforts.
Adherence to process and design
methodologies. Flexible reaction to
change.
Clear communication channels with the customer.
The Lead Program Manager has the responsibility and authority for
managing and executing the implementation plan as well as all
subsidiary plans. The Projects team consists of members from the
following functions:
Business Analysis
Call Support Services
Communications
Data Processing
Financial Operations
Ongoing Operations
Project Management
Solution Architecture
Systems Development/Configuration
System Integration Testing
A relationship governance structure and process will be instituted
to set forth the framework in which the fidelity and Client
relationship will be managed. This Structure will provide a forum
to:
Discuss implementation strategy, priorities and service
model.

Manage the contractual relationship between

organizations. Establish appropriate change
control routines.
Ensure overall alignment with the business strategy
and objectives. Monitor service delivery and project
status reporting
Identify areas of process improvement.

2.1 Project Kickoff:

Upon being notified of being selected to perform the Health

and Welfare administration work, a project kickoff will be
scheduled to initiate all project activities. Following are the
activities:
Project / Team
Introductions
Program
objectives
Initial Project
Timeline overview
Project governance
structure

Fidelity Implementation Methodologies

Domain breakouts (Project Planning, Communications,
Data, Contract Open Issues, Requirements, Quality
Assurance)
Client resource Allocation
2.2 Project Management Phases:

A Health and Welfare implementation consists of 4 project

management phases, they are outlines below:
Table 1: Project Management Phases
Project Management
Purpose Major Activities Major Deliverables
Phase
Project Initiation This Phase Assign Program Preliminary
establishes the and Project milestone plans.
mgmnt and the Managers. 60 day project
governance Identify planning
structure for the governance roadmap.
implementation structure Preliminary
project, and Document scope of
delineates the preliminary services
methods and tools scope. baseline.
that will be used to Create Staffing
execute and control Plan.
the project. Conduct internal
and client
kickoffs.
Initiate Contract
amendment
process.
Finalize Approved
Schedule of Schedule of
Project plan will be Services. services.
established by the Develop project Project resource
project manager, resource plan. plan.
which will be used Develop MS Project work
Project Planning
to direct, monitor Project Plan. Plan.
and control all Develop Risk Project budget.
implementation Register.
activities. Requirements
and System
documentation
Ensuring actual Updated Project
effort is Plan.
This Phase consists matching Approved
of execution and estimated. Change control.
delivery on project Identifying and Approved
plan line items. documenting requirements
Includes monitoring changes in documents.
and controlling the scope. Approved issues
Project Execution execution of the Documenting all and risk logs.
activities involved issues that can Client
in designing, impact client acceptance
developing deliverables. testing.
configuring data and Identifying and Ongoing
conversion and mitigating risk Operations
 system deployment. that can impact Transition plan.
project

Finalize effort Lessons learned

This Phase consists tracking. document.
formally concluding Finalize all Process
the implementation project artifacts. improvements.
Project Closure
project artifacts for Transition to Client
use by subsequent ongoing team. satisfaction
efforts. Lessons learned. survey.

2.3 Project Life Cycle Definition:

Each release within a Health and Welfare implementation

goes through the following phases:

Table 2: Health and Welfare Implementation Process

Project Phase Purpose Dependencies Major Deliverables

Requirements Detailed definition of Kickoff is Business
Definition all system complete. Requirement
requirements for the Release‘s Documents.
release are schedule of Client Sign Off
established. services
approved by
client.
Solution Design Design specifications Requirements Solution design
are developed for are iterative. specifications.
system components Prior releases Revisions to
that will need to be are complete. project timeline
developed or and effort
modified in order to estimates.
meet the clients System Design
business templates.
requirements.
Configuration Systems are Client and Core record
configured based on Fidelity have keeping system
design specifications. approved is configured
solution based on client
design. requirements.
Client has
approved
project
schedule.
Development Custom code is Client and Client specific
 developed for non Fidelity have rules are ready
standard client approved for use in
provisions. solution Configuration.
design.
Client has
approved
project
schedule.
Data Conversion Client feed rules Data summit Core record
created according to complete. keeping system
Fidelity Best is configured
Practices, third party based on client
and vendor feed rules.
requirements.

Quality All code is verified to Configuration System

assurance ensure it is developed is complete. integration test
and configured based Development approval.
on client is complete. System
requirements and are Unit Testing demonstration/Cl
deployed in a manner has been ient acceptance
that will meet fidelity performed. test (CAT)
standards for approval.
availability, Fully
responsiveness, functioning
accuracy,consistency, administration
and security. components per
release scope.

Transition Approved code is Written Support

deployed to next approval of documentation is
release phase or CAT or system complete.
Fidelity‘s production demo. Functionality
environment for use For production ready for
by the client and readiness, production or
eligible health plan contract next release of
requirements. finalization is implementation.
required. Training
complete.
2.4 Solution Confirmation/Configuration/Development

Once Fidelity receives verbal confirmation they have been

selected as the new provider the Program Initiation and
Environment, Preparation stages begin. The H&W Project
Manager initiates the set up of the environments and applications
during the Environment Preparation stage. Access is granted to
associates for applications needed to implement the client. Most
of the work in this phase is performed by what is referred to as
the Build component. There are 7 releases in the Build and
functionality is demonstrated to the client at the end of each
release.

Program Initiation: It is first stage of Solution

Confirmation, Configuration and Development phase. This
stage is initiated by the notification of a sale and starts
with a Project Tem Kick –off meeting. The primary goal of
the stage is to confirm client engagement to ensure
understanding , participation in and support of the key
success elements of the Fidelity Implementation Process.

Note on Annual Enrollment: When the Implementation also

encompasses Annual Enrollment (AE) for the new plan year,
the Imp – to – Own team will run the Annual Enrollment (AE)
following the established Fidelity processes and procedure for
AE. Annual Enrollment ―kick –off: with the client should
begin just after the main

BPD‘s are completed and no later than May for a Fall AE.
The critical management tasks from the standard AE Project
Plan will be incorporated in the Implementation Project Plan
 as the tasks for both are interdependent and require integrated
management reporting.

Environment Preparation: The Systems Project Manager should begin

with the Environment Setup UPD. The Environment Setup UPD
provides a checklist of the tasks that need to be performed as part
of Environment Preparation.

The Environment Strategy document outlines the non Production

instances to be used for all phases of the Implementation Process.

Common Tools:

HOBS Environments: HOBS/ AR URL‘s and Log in.

NPAMA: Non Production Account Management
Application: HOBS Database Access Tool

Access Central: Help you manage any access administration
needs and tools needed.

CSW : Client Service Workstation

Lotus Notes: Tool where Incident Requests, Service
Requests, Work Requests, Rules Development Requests ad
Migration Requests are entered to lookup , enter or modify
requests to groups based upon the need to build or fix.

Build (5 Releases): Several stages within the Solution

Confirmation/Configuration /Development phase make up the
Build component of the project. There are 5 releases in the
Build for a Standard implementation .Each Release is a month
in duration and consists of 2 week iterations. Following
snapshot shows these:

Table 3: Implementation Release Contents Template

Implementation Release Contents Template

 HOBS & AR Configuration /Data Management delivery to
Systems Test

Functional Release Contents

Release 1:
Data Maintenance: Standard HRMS
Core Functions:Benefit Structure
Participant Experience NetBenefits, CSS and VRU
Primary Care Provider
Release 2:
HRMS - Client Specific Benefit and Data Structure
Core Functions: Active Eligibility and Rates
Benefit Decision Support Tools
COBRA Services: Eligibility & Rates

Domestic Partner Services:Eligibility and Rates

Release 3:
Life Events:Feed
Carrier Election Reporting/Enrollment Files
Online Life Event Modelling
Medicare Core Services: Eligibility
Release 4:
Medicare Part B Reimbursement :Eligibility
Medicare Part D Services: Eligibility
Literature Extract
HIPAA Certificate Processing - Reporting
Life Events: Participants - On Line
Life events : Temporal
QMSCO Services :Events
Participant Experience:Auto PFS and Confirm
Inactive Billing
Release 5:
Retirement Initiation: Feeds
Survivor Services
HIPAA Certificate Processing - Reporting
Annual Imputed Income
Accounts Payable Premium Processing
FSA Debit Card
Health Savings Account: Reporting
FSA Services: Reporting

Communications:
 Communications will be delivered through electronic
channels (web/email) whenever possible, and participants
will have access to the tools they need to make the right
benefit decision for their personal circumstance. Print
communications will be used for any life event that
references cancellation or loss of health and Welfare benefit
coverage.
The Communications and Education team has developed a
standard portfolio to be used as a starting point when
working with clients to meet their communication needs. All
of the standard communication pieces are accessible via the
links section on the bottom part of your screen. A
communications Consultant and / or a Communications
Analyst are responsible for reviewing communication
materials with a client.
2.5 Project Transition to Ongoing

Fidelity‘s Health and Welfare implementation Transition process

follows the concept of ‗Imp-to-Own‘. This means that key members
of ongoing operations team will be involved with the
implementation from the start to ensure a smooth transition. It also
allows these associates to build
strong working relationship with client corporate benefit team
members prior to the actual work transition. The team can therefore
focus on relationship building and transition at the appropriate
sequential times.

The Managing Director and the Service Delivery Leader are

involved in the implementation from the beginning. This
involvement supports regular communication with the Client
Service Team responsible for the ongoing administration of
benefits, and ensures a seamless transition from the
implementation team. At an appropriate time during the
implementation, Fidelity assigns additional resources from the
ongoing services team in order to ensure effective knowledge
transfer and training.

During the transition phase of the implementation a formal

handoff from implementation to ongoing services occurs. At this
point, there is a walkthrough and assignment of outstanding
issues and future deliverables.

2.6 Roles and Responsibilities.

The Fidelity Program Management Team members are as follows:

Portfolio Manager: Manage Client escalations, guide capacity

planning, resource allocation, employ good business sense and
apply compliance considerations by mitigating risk.

Integrated Program Manager: Responsible for the facilitation,

coordination and management of multi product programs. Manages
business, functional and technical resources in a matrix. Main
point of contact for client in regards to implementation standards.
Proactively manages integrated risk.

Health and Welfare Program Manager: Responsible for the

facilitation ,coordination and management of H&W programs.
Manages H&W business, functional and technical resources in a
matrix environment across multiple locations and direct their
efforts to successfully deliver projects.

Senior Client Management Team: Engages team to come to

resolution on open items and requirements to keep the
implementation on schedule. Acquire and manage resources for the
implementation work including coordination of other functional
areas such as IT and Payroll.
Implementation Project Manager: Partners with Fidelity Health
and Welfare Project Manager to manage the execution of
implementation deliverables. Proactively manages H&W risk.
Drives quality of H&W programs by ensuring appropriate reviews
and validations occur by business partners.

2.7 Ensuring Resource Coverage:

The following measures are in place to ensure that the

implementation team members have access to Fidelity team
members in the event of planned or unplanned absences.
Business Continuity: Fidelity has an extensive business continuity
protocol in place to ensure that customers and clients are minimally
impacted by any business continuity event. If during an
implementation a business continuity event occurs, client contacts
will be contacted by a member of the program management team to
outline the event and what, if any, impact has on implementation
work.

Associate backups:

Table 4: Associate Back up Table

Team Member Primary Backup Secondary backup

Managing Director Service Delivery Lead Portfolio Manager
Portfolio Manager Service Delivery Lead Client Service Manager
Service Delivery Lead Managing Director Portfolio Manager
Integrated Program Portfolio Manager H&W Project Manager
Manager
H& W Project Manager Integrated Program Solution Architect
Manager
Solution Architect H& W Project Manager Requirements Lead
Systems Project H&W Project Manager Solution Architect
Manager
 Client service Manager H&W Project Manager Service Delivery Lead
Configuration Lead Solution Architect H&W Project Manager
Requirements Lead Solution Architect H&W Project Manager
Quality Assurance Lead Solution Architect H&W Project Manager
Data Lead Solution Architect H&W Project Manager
Business Validation Test Solution Architect H&W Project Manager
Lead
Communications Any Communication H&W Project Manager
Team Member

2.8 Project Governance

The following chart outlines governance roles and responsibilities:

Figure 11: Project Governance

Steering Committee Management will be attained through a

monthly Steering Committee meeting. More frequent meetings of
the leadership and PMO teams will facilitate the gathering of data
to report the following at Steering Committee meetings.

Overall Project Timeline and Status

Contact Progression
Detailed Accomplishments and Challenges
Upcoming Milestones
Issues and Risks
Transition and Planning
 Change Controls
Lessons Learned
Key Actions Needed.

CHAPTER 3: RESOURCE MANAGEMENT

Resource management refers to the manner in which Fidelity

associates are allocated to the project teams, as well as how they
are managed throughout the project life cycle. The actual
performance of the associates is measured by the functional
manager that the associate reports to with input from team project
managers.

Resources are allocated to a project based on complexity and

schedule analysis that occurs at the beginning of the project. A
staffing profile is developed to quantify resource needs for the
entire project life cycle. Once the staffing profile is developed, the
program management team works with functional managers to
identify associates in their organisations that have the appropriate
skill sets to accomplish all project deliverables.

Once a project is staffed, it will be the role of the Program

Management Team to monitor staffing needs on a daily basis to
ensure that the project changes have not created staffing gaps.
Upon completion of the applicable project deliverables, the
program management team will be responsible for the release of
team members.
 Figure 12: H&W Implementation Team Structure

CHAPTER 4: SCHEDULE MANAGEMENT

Schedule Management processes will be in place to ensure the

timely completion of all project deliverables. The Project Manager
will use a Microsoft Project Plan to oversee all aspects of the
project execution. Other documents such as task charts, open items
lists, and status reports will be used to supplement the project plans
execution to the daily task that team members perform. The
Schedule Management Plan takes into account the following when
creating the overall project plan:

Definition of all project activities

Analysis of dependencies between activities in
the plan. Duration estimates of each activity
Resource allocation and
assignment. Critical Path
identification and analysis
 Contingency and Risk Planning

The Project Manager will manage the project on a daily basis using
the following tools and reports:

Microsoft Project Plan

Daily Effort meetings
High Level and Milestone Gantt Charts
Milestone and Task Detail Reports
Recently Complete Task Report
Upcoming Deliverable Report
Overdue Task – Unfinished Report
Overdue Task – Not started Report

Updates will be made to the project plan based on the completion

of the deliverables and adjustments will be made to the plan in
reaction to any scope changes or project delays. Updates to the
project plan will be shared in weekly project meetings and posted
to Team Workspace (TWS).
Below is an outline of the general weekly schedule management
process:

Figure 13: Weekly Schedule Management Process

4.1 Project Timeline:

The project will follow an iterative timeline similar to the one
depicted below:

Figure 14: Project Timeline

Throughout the seven releases of software the client will be

engaged in requirements definition and clarification. At the end of
each release, fidelity will perform a system demonstration to
accomplish the following:
Ensure requirements and interpretations are
correct Provide an opportunity for feedback
Demonstrate system development progress.

Upon Completion of Release 5, a full end to end client acceptance

test will occur to provide client the opportunity to fully test the
system before it is available to the participant.

4.2 Critical Milestones Status:

The project manager will work with the entire project team to make
a determination of the critical milestone status on a weekly basis.
Below is a summary of how it is determined. For statuses other
than green, action items will be developed to reach a yellow or
green status.

Key Considerations:

Project Plan Critical Path

Milestones within the Last Month
Milestones within the next month
Potential impact of change requests

Critical Path – the series of project activities that determines the

duration of the project Milestone - a significant event in the
project, usually completion of a major deliverable.

Statuses:
Green: Project Plan critical path matches project expectations (time
frame,quality and content robustness of deliverables)

Yellow: Critical Path related work is late, and / or highly

probability /resource impact change requests are likely to be
integrated in the projects schedule, and /or critical path key/next
milestone slippage of 5 to 10%.

Red: Critical Path related work is late or high probability/resource

impact change requests are likely to be integrated in the project
schedule and/or critical path key/next milestone slippage of more
than 10%.
 CHAPTER 5: SCOPE MANAGEMENT

Scope Management processes will be in place to ensure that the

product delivered for client contains all of the features and
capabilities specified in the projects scope. Scope management will
be the sole responsibility of Program/Project Managers with input
from the Functional Managers and associates. The scope of this
project is defined by the contract and service Delivery model
supplemented by the Business Requirements documentation.

All Change requests will be submitted to the program manager

who will then evaluate the requested scope change. Upon
acceptance of the scope change request the Project Manager will
submit the scope change request to the Change Control Board
(CCB). Upon approval of scope changes by the CCB, the Project
Manager will communicate the appropriate fee and details of the
solution created for scope change.

Once the client approves the change order, the project manager
will update all project documents and communicate the scope
change for all stakeholders. The client is responsible for the
acceptance of the final project deliverables and project scope via a
Client Acceptance Test (CAT).Once final deliverables are complete
and accepted by the client, the ownership of benefits
administration will transfer from the implementation team to the
ongoing operations team within Fidelity.

5.1 Change Control Process:

Change Control is defines as a request to expand or reduce the
project scope, modify policies, processes, plans or procedures,
modify costs, budgets or revise schedules.

Fidelity‘s Change Control Process consists of the following general

steps:

1. Identify the need for a change: A potential change may be

identified by an Fidelity Implementation Team Member or
member of Clients implementation team. Once a Team
Member identifies a change, he or she discusses the change
with the appropriate parties, internal and external to begin
the estimation process.

2. Initial requirements discovery for that change: Initial

reviews will be done to determine general requirements for
the change. This will allow Fidelity Implementation
resources to develop a complete scope of the change so that
the effort and timing to implement can be created.

3. Estimation of the effort required for the change: Fidelity will

analyze the impact of the change in terms of schedule, risk
and in some cases, cost.

4. Change Control submission: The project manager will work

with appropriate parties to submit the change control
document to an authorized client approver.
5. Change Order Approval: Works with internal parties and
fidelity to sign off on the change control. All change orders that
do not meet Fast Track requirements must be formally signed
off by the client before the change order can proceed.

6. Change Control Review Board Determination: Once a change

order is signed off by the client, it will be reviewed one final
time by the Fidelity Change Control Board for a final
determination of risk and final scheduling.

7. Project Implementation: Once the project is approved, it moves

to a development phase where it goes through the entire
development life cycle ending in client approval via Client
Acceptance Test.

CHAPTER 6: QUALITY MANAGEMENT

Fidelity employs many testing initiatives based on the unique

characteristics of the project to ensure the final product matches the
scope outlines in requirements documentation. Each test phase
builds upon the last, resulting in a fully tested system with minimal
defects entering into production.

There are several methods that will be used to ensure that the client
implementation, and the application that results from it, adhere to
appropriate standards:

Systems Testing/Quality Assurance: There are multiple

phases of testing that occurs within multiple groups at
Fidelity to ensure that the system being developed matches
requirements.

Business Acceptance Testing/Review: These are internal

 project team work sessions in which the team reviews all
deliverables for a phase before scheduling a client review.

Walkthroughs / System Demonstration: These are

collaborative group work sessions in which the walkthrough
team validates the deliverable with the client. Additionally,
they will have question and answer sessions, as well as brain
storming sessions, if appropriate, to ensure that the system
being developed meets client expectations.

Client Acceptance Test: These are reviews of a deliverable

by the client for the purpose of inspecting and approving the
deliverable.

End to End Testing: Testing of integrated functionality across

products to ensure complete transactions work as per
functional requirements. Testing may also include third part
vendors as appropriate.
Audit and Control Mechanisms: Once the system is deployed
in production, there will be multiple audits, editing, reports
run on an ongoing basis to ensure that the system is
monitored for defects once it is fully operational.

In addition to the six phases of testing for this implementation,

Fidelity‘s
Standard monthly maintenance process includes the following
testing in pre –production environments.

Table 5: Testing Types

Other Testing Types

Performance Testing
Volume Testing
Disaster Recovery Testing
Stress Testing
Fail Over Testing
Load Testing
Post – Production Testing

6.1 Validation:
The Validation Phase is made up of 2 stages – the Business Process
Validation and the Data Validation stages. During the Business
Process Validation stage the end to end system is validated to
ensure its ready for production .Validation in this stage is
performed by the client known as Client Acceptance Testing or
CAT.

Business Process Validation: This is where Client

Acceptance Testing (CAT) occurs.CAT is considered to be
the final stage of code change validation and is performed by
the Client through Net benefits before the code is migrated
to production. Net benefits is an online link where one can
see as and from a Participant perspective, the end result of
the performance of the different Functional areas. Setup for
Functional areas such as HOBS configuration, CSW and
web content must be complete before the client can begin
CAT.
Data Validation: During this process UNIX commands are
used to lead the client data into the Health and Other
Benefits system (HOBS) utilizing a data transformation tool,
Informatica (Powermart). The files received from the
transitioning record keepers are transformed by Powermart
in to two types of Odump files – Indicative and Enrolment.
These files are used to load the client data into HOBS. The
Data Conversion Load process is comprised of
BCC1,BCC2,BENMNGLE, ad BCC3.

1. BCC1: Process loads the participant demographic,

Participant employment, and dependent demographic
data to
 HOBS. This process also inserts a potential
―Conversion‖
Life Event for each employee.

2. BCC2: Process that loads the current and historical

enrolment data.
3. BENMNGLE: After BCC1 and BCC2 are completed
and validated, a batch process runs to compare the
actual eligibility based on configuration in HOBS to
the data that was loaded. Based on the key data
change that occurred, BENMNGLE determines what
eligibility and electability are available.

The Following is determined during this process:


Health Plans a participant is eligible for.

Whether or not the participant can make
changes to elections.

Applicable Rates.

The length or period of opportunity he gets to
enrol to benefits.

The literature of Communication that needs to
be sent.

4. BCC3 : Process compares the results of BCC1 and

BCC2 against what is configured into the system. The
BCC3 process stimulates the act of a participant
making elections associated with the conversion life
event. The BCC3 process stimulates the act of a
participant making elections associated with the
Conversion event. This job process converts
participants who have elections. If the participant is
eligible for the loaded plan, the election is saved. If
not, the election is rejected and the ―Participant
found ineligible for converted enrolment‖ error is
 generated.

Through each of these processes (BCC1 through

BCC3), errors will be generated if the data is unable to
load successfully.

6.2 Defect Process:

When a defect is reported from an internal or External Party, the

following key data will be captured to help in prioritizing,
planning, and resolving the defect:
Defect Description
Priority
Status
Assignee
Identification Date
Due Date
Complexity

Defects will be managed by the project manager, and assigned to

project team members who will own the resolution of the defect. A
defect report will be utilized to ensure that defects are being
resolved prior to the code being deployed to production. Prior to
client demo or Client Acceptance Testing, a Known Defect Log
will be communicated. Below is a high level defect process flow:
 Figure 15: Defect Process Flow

CHAPTER 7: RISK MANAGEMENT

Risk Management is an ongoing process that continues through the
life of a project. It includes processes for risk management
planning, identification, analysis, monitoring and control. Many of
these processes are updated throughout the project lifecycle as new
risks can be identified at any time. It‘s the objective of risk
management to decrease the probability and impact of events
adverse to the project.

7.1 Failure Mode and Effects Analysis (FMEA)

Failure Mode and Effects Analysis will begin at the initiation of the
project, and will continue through the project life cycle. This
analysis will be utilized to track the ongoing risk ad to plan
remediation for any potential risks that do surface. Key items
tracked on the register are:
Description and causes of a
potential risk Severity and impact
of potential risk
Process controls and protections to
avoid risk Risk Priority Numbers
(RPN)
Mitigation strategy
Actions taken to mitigate risk
Revised Risk Priority Numbers
(RPN)

RPN Methodology calls on the implementation team to track

three ratings for each risk identified:
Severity: How severe an impact that failure will have?
Occurrence: How likely is it that the failure will occur?
Detection: How likely is it that the failure will be caught
before being visible to the participant?

Each rating scale will be measured on a scale of 1 to 5:

Rating 1: Very Low
Rating 2: Low
Rating 3: Moderate
 Rating 4: High
Rating 5: Catastrophic

The effectiveness of a planned risk response can be

measured by using the revised RPN to determine how the
potential risk has been impacted by our developed response
strategy. The RPN along with the revised RPN will be used
to prioritize risk.

CHAPTER 8: COMMUNICATION MANAGEMENT

The intention of Fidelity‘s communication management
strategy is to facilitate a common approach to working together
and communicating with all parties. The program management
team has developed standard documents.

Agenda
Attendees
list
Meeting
minutes
Action/Issue
s Logs
Action Plan

The implementation team members will be communicating with

each other frequently. Fidelity and client should determine which
methods will work best for the combined team and determine the
preferred communication media. Available communications media
include:

E-mail
Face to face meetings
Blackberry
Phone/Voice mail
Plan sponsor website
All pertinent written documentation will be stored in the Plan
Sponsor Website (PSW) to ensure each team member/stakeholder
has access to documentation when needed.

When documents are updated in PSW, archiving will occur to

ensure changes are tracked appropriately. When a document is
changed or added to PSW, the author will notify the appropriate
project team members via the email notification functionality on
PSW to ensure all parties are aware of the document‘s posting.

The following coordination will be put into place to ensure

effective coordination of client‘s and external partner resources.

Meetings will have a clearly defined purpose and expected

outcome Meetings will begin and end on time
Meeting agendas will be sent 24 hours in advance
Meetings will be facilitated with a one-team approach (One
conversation at a time), with a clearly defined leader of the
meeting

If a resource is unable to attend, responsibility for

follow up is placed upon the individual
Decisions, issues and actions, with clear ownership and
expected timelines, will be clearly documented via
formal tracking tools and made available to all
participants.
Discussions that need to take place outside of the
meeting will be captured as ―Parking Lot‖ items.
Meeting notes and action items distributed to all
meeting participants within 2 business days
following meeting.

8.1 Meeting overview

The following meetings will be utilized to facilitate

ongoing communication throughout the project:
Table 6: Ongoing Communication
Meeting Meeting Purpose Meeting Suggested Meeting Actual
 Name Frequency Attendees Meeting
Attendees
Executive Manage relationship, Monthly Fidelity:
steering oversight and
committee strategic planning Managing Director
activities Program Manager
Responsible for Vice president
resolving escalated Service Delivery
issues Lead
Approves certain
change control Client:
requests
Executive Leaders
Project Manager

Leadership Maintain governance Biweekly Fidelity:

Team structure
Plan updates to Program Manager
business owners Service Delivery
Critical project Lead
decision making
Milestone review Client:
Resolve roadblocks
Project Manager

Integrated Alignment of systems Weekly Fidelity:

PMO and integrated
Product/Project work Program & Project
teams Manager
Report progress Functional Leads

Meeting Meeting Purpose Meeting Suggested Meeting Actual

Name Frequency Attendees Meeting
Attendees
updates and Portfolio
milestone status Management
Resolve cross
product/project issues Client:
Act on Change
Control memos Project Manager
awaiting approval by Functional Leads
both parties

Open items Resolve open items Weekly Fidelity:

Discuss project
deliverables Program & Project
Review project Manager
metrics and status Other team
reports members as needed
 Client:

Daily contacts
Project Manager
Other team
members as needed

Product Kickoff project Adhoc Determined based

specific activities on meeting topic
Review requirements
System
demonstrations

Fidelity Keep the team Weekly Fidelity team

weekly informed of the members and
team project status managers engaged
meeting Raise concerns/issues or soon to be
that needed to be engaged on the
addressed project

Daily What was worked on 4 days a Fidelity team

huddle yesterday week members and
What will be worked managers engaged
on today or soon to be
What help can be engaged on the
given project

8.2 PMO Communication Tools

Following tools and documents will be utilized by the

program management to foster strong communication
Table 7: Communication Tools

Tool/Report Description/Purpose Frequency Location on PSW

of Update
Project Status Provide PMO and project Weekly Status Reporting> PMO
Report team full transparency into Status report
the progress of the
program
Issues/Risks & Formal capture of Continuous Issues, Risks & Action
Action Items identified issues, risks and items>
actions with owners, target Items>Issues_Risks_Acti
dates and status ons Log
Team Contact List Listing of all project team Program Team Info>Project
member‘s contact initiation and Contact List
information and primary as needed
area of responsibility
 Team Vacation Listing of all project team Program Team Info> Project
Planner member‘s vacation/out of initiation and Vacation Calendar
office plans for the as needed
duration of the program
Work stream Formal tracking of all Continuous Project Plan>
Project Plans work stream project tasks
with owners. Dates and
status

8.3 Escalation protocols

The Following escalation process to raise project issues to a

higher authority on the team to ensure a more timely
resolution. The goals of the escalation process are to:

Have expectations up front as to how certain issues will

be escalated to senior
Keep senior management in the loop on key issues
potentially impacting the project outcome
Set the context that particularly tough issues should be
escalated quickly when normal paths of communications
are not resolving the issues
Escalations will be tracked on the open items log to ensure
they are reviewed regularly until resolution. If an item was
already on the Open items log and it has become an
escalation, the project‘s priority will be sent to ‗urgent‘.
During the implementation project, escalations should occur in
an organized manner. When required, the following chart
outlines the appropriate channels for different escalations that
occur throughout the project life cycle. Level three being the
lowest impact, level zero being the highest escalation:

Table 8: Escalation Levels

 Escalation Audience Impact Action Example
Level
Level 0 Executive Requires Steering committee Unresolved
Leadership Executive escalates to contract
decision making Executive Sponsors issue that
requires a
decision
Level 1 Steering Requires PMO leadership Unresolved
Committee leadership escalates to plan design
direction or steering committee decision
intervention that requires
direction
Level 2 Program Impacts multiple Escalates to Delay in
management products/functio program PM or delivery of
office ns PMO leadership SCF test file
(Integrated
data feed)
Level 3 Product Project Impacts Escalates to Project Change
Team individual PM or SME requirement
product/function s for HW
plan
requires a
change
control

8.4 Resolving Escalations

The team or team member that receives an escalation will

address the escalation in the following manner:

1. Work with team member making the escalation to

understand the issue and its impact.
2. Outline all project subteams and processes impacted.
3. Solicit input from other team members for recommended
solutions.
4. Work with the team to agree on a proposed solution.
5. Ensure the client agrees with the proposed solution
6. Assign to project manager to track to completion
7. Regroup at an agreed upon time to ensure the escalation
was appropriately resolved.
 CHAPTER 9: CONCLUSIONS

Agile Methodology some may find is suitable for medium and

small projects and may not be suitable for Large Projects if the
latter is not broken down to smaller modules.

With proper implementation, agile methods are efficient with fewer

resources than traditional development methods. Provided that the
Agile teams recognize the significance of documentation and
identification of critical requirements. Additionally, Agile teams
working in parallel with frequent communication between teams
are well equipped to handle large projects. At the culmination of
each iteration the agile teams should provide a demonstration, post
mortem analysis and discussion and review of documentation.
Consequently, properly implemented agile methods are viable and
competent solutions to the very projects that proponents of
traditional development methods are quick point out are not
suitable for Agile methods.

Fidelity Agile Methodology (FAM) follows a lean approach to

software delivery at Fidelity that combines agile with other
development methodologies and practices, such as Extreme
Programming (XP),Rational Unified Process(RUP) and
Scrum.FAM can be used by technologists, their business partners
and product teams across the enterprise to develop IT Solutions in
more predictable and efficient manner while realizing a faster time
to market and delivering the highest value and most critical
software functions and features.
RECOMMENDATIONS:

The following few recommendations would help increase the

productivity of this New Client Implementation team that
works on Agile Methodology:
Send Daily status updates at the end of the day
Status update includes In progress work, Completed,
Issues/Concerns
This would particularly level with this team due to the
teams distributed across Onshore and Offshore
partners.
Call when Appropriate
Calling someone rather than pinging on Sametime
creates more personal relationship with your co
workers
Usually fixes the problem a lot quicker than waiting
for someone to respond.
Meeting Project Team (distributed Teams)
Having a face to face interaction with your project team
creates a better relationship
Video Conference
Though in house facilities are available we must make use of
it diligently
A tool such as teleplace would be good for this: allows you
to see team as well as the iteration board.
REFERENCES:

Stellman, Andrew; Greene, Jennifer . ―Applied Software

Project Management”, O‘Reilly Media, 2005

Boehm, B.W. "Software Engineering Economics", Prentice_Hall,

1981

Albrechet, A.J. etc. "Software Function, Source Lines of Code,

and Development Effort Prediction: A Software Science
Validation", IEEE on Software Engineering, NOV 1983