Project Life Cycle

International Journal of Wisdom Based Computing, Vol.
1 (3), December 2011
146
Software Development Life Cycle Standards for

Banking and Financial Services IT Industry
Poyyamozhi Kuttalam, Project Manager, Larsen and Toubro Infotech
Dr.K.Iyakutti and Dr.K.Alagarsamy
Madurai Kamaraj University.
poyyamozhi@gmail.com
ABSTRACT: In general we have Software Development Life

Cycle standards for the IT projects in common, considering all
the industries or domains or businesses. This effort particularly
outlines the Software Development Life Cycle Standards
structures by which a Banking and Financial ServicesInformation Technology Organization (BFS IT) can effectively
plan, execute, monitor, control and close a project or
maintenance request. It defines high-level activities that can be
applied to all organizations within the BFS IT industry.
participate in the delivery of technology projects or

maintenance requests [1] [2].
1.3 Scope
The scope of this document will be the Minor and Major
Project Lifecycle structures and Maintenance Life Cycle,
and their associated processes. These include:
1. INTRODUCTION
1.1 Background
Organizations perform work to achieve a set of
objectives. Generally, work can be categorized as either
projects or operations. The objectives of projects and
operations are fundamentally different. The purpose of a
project is to attain its objectives and terminate.
Conversely, the objective of ongoing operations is to
sustain the business. Projects are different because the
project concludes when its specific objectives have been
attained, while operations adopt a new set of objectives
and the work continues. Operation work is managed or
supported through planned maintenance or production
support activities. Projects are managed through the
Minor or Major Project Life Cycles and when
appropriate the Program Life Cycle.
Project Management is the discipline of defining and
achieving targets while optimizing the use of resources
(time, money, people, materials, energy, space, etc) over
the course of an endeavor. Using a system of procedures,
practices, technologies and business knowledge, provides
the planning, organizing, staffing, directing, and
controlling necessary to successfully manage the work.
This effort is a roadmap to assist organizations in
successfully delivering in a manner that fits the
Organizations objectives as framed [1] [2] [3] [5] [10].
1.2 Audience
The intended audiences for this Software Development
Lifecycle Standard are Managers of Information
Technology, Project Managers and any resources that
Phases
ETVX Model
Phase Review and Phase Gates
Activities and Deliverables
Recommended Roles & Responsibilities
1.4 Out of Scope

The following items are out of scope of this document:
LOB (Line of Business) level implementation processes

Production Support or Break/Fix model
LOB specific activities and deliverables
Program Lifecycle
1.5 Assumptions
The following assumptions apply:
Prioritization model ensures project alignment

with business objectives
Project Sponsors are engaged to provide direction,

address escalated issues and mitigate risks
Quality Assurance practices will support the

proposed model
2. RELATED
SUPPORTING
DOCUMENTS
2.1.1
BFS IT MP
The Banking and Financial Services Information

Technology Management Policy (BFS IT MP) is the BFS
standard for managing Information Technology within
the organization; the document includes Architecture,
Change Management, Contracting and Outsourcing,
Information Security, Problem Management, Project
Management, Resource Management, and Software
International Journal of Wisdom Based Computing, Vol. 1 (3), December 2011
Management. Many of these policies guide activities

executed during the individual lifecycles [1] [2] [4].
2.1.2
BFS IT Lifecycle Standard
The BFS IT Lifecycle Standard is developed and

maintained by BFS IT for the purpose of applying a
common approach to delivering project and planned
maintenance work across all BFS IT Segments and
Businesses.
Banking Financial Services Information Technology
(BFS IT) Lifecycle Standard shall consistently and
effectively plan, execute, monitor and control technology
projects and maintenance work requests by following a
defined set of delivery lifecycles and high-level activities
[1] [2].
The Standards within this effort supports the BFS IT
Lifecycle Standard.
2.1.3
LOB Process Control Manuals (PCM)
The LOB Process Control Manuals outline a progression

of activities and details from the Initiation Phase through
the Post-Implementation Phase. It provides detailed
procedures specific to the LOB for managing and
delivering support for their technology systems and may
contain references to other LOB specific documents and
templates [4].
2.2 Management Approach

Effective management is critical to the success of
delivery. Implementing a structured and well-defined
process is the first step towards meeting the
organizations goal of providing consistent service [1]
[2]. See Figure 1 for project management life cycle.
2.3 Project Management Process

The process of managing work involves initiation,
planning, execution, monitor & control and closure
throughout the life of the endeavor. Project management
emphasizes understanding the goals and scope of the
project, compiling project plans for successful execution
of projects, and lastly, controlling and managing any
deviations from the plan. Project plans, baselines to
schedules, project risks and issues must be tracked in the
project management tool. See Figure 1 for project
management life cycle.
A project management plan includes those processes,
tools, and techniques to be applied to the project, how the
work will be accomplished, changes controlled, and key
management reviews [1] [2] [3] [10].
2.3.1
Initiation
147
Initiation is a phase where the requestor identifies a need

and submits a work request for new technology or
enhancement to an existing technology. The activities
focus on recognizing and documenting the request.
2.3.2
Planning
Planning provides a framework for identifying,

prioritizing, and planning work. It includes identifying
project scope, schedule, resources, and cost at a high
level. The processes documented here provide the Project
Team with the groundwork to plan the work they will do,
develop estimates of efforts, develop a schedule, and plan
their management and technical approaches.
2.3.3
Execution
This involves performing and coordinating various

aspects of the plan to complete the work to accomplish
the objective or requirements defined in the Statement of
Work (SOW). All stakeholders must follow a defined
framework to ensure focus on resources and major
project variables like time, costs, scope, and quality of
deliverables at predefined intervals based on the type,
complexity and size of the effort.
2.3.4
Monitor and Control
This segment of project management involves measuring

and monitoring progress based on the project plan. It
includes the tracking of required artifacts and ensuring
that risks and issues are identified, assessed, prioritized,
documented, escalated, and mitigated where appropriate.
Risk is an inherent part of all projects and must be
managed to ensure they do not become a threat to
meeting the objectives or result in major rework. The
assessment of risk is necessary to make management
aware of the potential risks in undertaking or continuing
with the project. Periodic update meetings ensure full
communication between the Project Team, the client
Project Team, project management, and business
stakeholders.
2.3.5
Closure
This part of project management involves the formal

closeout of a project. This includes the Post
Implementation
Review
with
lessons
learned
documented and completion of all project deliverables
and audit reviews.
2.4 Phase Structure

The ETVX (Entry, Tasks, Verification and Validation,
and EXit) model outlines a structured approach for
accomplishing activities and ensuring that tasks meet
defined criteria. By utilizing this model, at each phase in
a Lifecycle, it creates a soft stop allowing activities of
following phases to be started without a final signoff of
all required deliverables of the past phase.
Entry Criteria: A checklist of conditions that must be

satisfied before the beginning of phase activities.
Qualities such as accuracy and completeness of
deliverables are covered by deliverable review and
approval activities. Timeliness of deliverables and
Oversight & Tracking is the responsibility of Project
Management or in the case of Maintenance, the
Technology Lead.
2.4.2
148
Phase Review: A soft stop is a point where a

project can continue into the next phases activities
without fully completing the requirements of the last
phase. However, the last phase will remain
incomplete until all activities/deliverables are
complete.
Monitoring and Controlling
Tasks: A set of tasks that need to be carried out.
Monitoring and controlling is done over all major project

variables; cost, time, scope and quality of deliverable
throughout the project Lifecycle.
Verification and Validation: A list of validation tasks to

verify the work items produced by the activity.
3. Work Categorization
Exit Criteria: A checklist of conditions that must be

satisfied before the activity is completed.
Entry Criteria
The business initiates all types of work requests utilizing

a workflow appropriate to each LOB. Authorized
requests are reviewed and categorized into work streams
of Non-Project or Project work. Each LOB will
incorporate appropriate controls to confirm the
classification and leverage BFS level terminology and
high-level processes to determine the right Lifecycle
classification based on effort, cost and risk indicators [8]
[9]. See Figure 2 for Investment Categories
Tasks
To align with corporate strategies for grouping IT efforts,
BFS IT organization will categorize work requests as
Validation
Program/Project Requests
Exit Criteria
2.4.1
Phase Exit
Phase Exits are critical decision points in the Lifecycle of

the project. At each phase a decision is made on whether
to continue with the project, to stop it, to do a significant
change in it or to determine if no work in later phases can
be started without the completion of all deliverables of
phases up to that point. Thus a phase exit provides the
project manager and release managers with an
opportunity to closely review the progress and quality of
the project up to that point to ensure that it is meeting its
objectives and quality standards.
Core Operating Activities
The phase exit of the ETVX model can be a Phase

Review or a Phase Gate.
Phase Gate: A hard stop checkpoints in the BFS IT

Lifecycle where specific deliverables are reported,
reviewed, and measured to assure readiness to move
forward is assessed. A phase gate will allow
deliverables in the next phase to start, however, the
phase will remain incomplete until all activities and
deliverables are completed and a phase oversight pass
is provided.
Strategic - IT Investment that enables LOBs to

achieve defined strategies, or reposition BFS industry
in the Market. Usually entails delivering new
functionality or infrastructure and involves significant
investment dollars.
Enhancements - IT Investment that enhances or
evolves existing products or supports current
relationships within a specific Segment or LOB. May
entail launching a similar product in a new market, or
may be strategic in nature, requiring less investment.
Mandatory - Investment required to remain compliant
with government or financial regulations, to maintain
association relationships, or to support corporate
mandated activities.
Maintenance - Repetitive work that modifies or

changes existing features, products or services in a
current technology framework. Typically very small
in scale, complexity and risk, and are considered to
be non-project activities
Production Support - IT Investment that addresses or
prevents break/fix issues, or is required to maintain
infrastructure and development environments.
Administrative - Supports the process of managing
people and resources efficiently and to direct
activities toward common goals and objectives.
This Standards document will focus on defining Project

activities and the Maintenance efforts under Non-Project
category [6] [7].
3.1 Non-Project
Non-Project work is defined as straight forward, static,
low risk, simple, small effort, repetitive type work
requests that impact existing functions, features,
interfaces, applications, products or services in the
current technology framework. It is highly recommended
that Non-Project work involve a limited number of user
areas (internal or external), it resides on a mature
technology platform, involves a mature application or
infrastructure, its repeatable/operational in nature, and
has a small scale of technology resource effort. Each
LOB will further define maintenance work utilizing these
common characteristics. Requests under this category
will follow the Maintenance Lifecycle [6].
Examples of Maintenance Work in the BFS IT sector:
Cognos reporting and data elements for existing

framework models and database tables
Infrastructure updates to existing software versions,
SMS pushes, restacks, Domain/IP changes, server
retirement, changes to application/job run schedules,
etc..,
Table updates, updates/releases from existing
vendors, Prime Rate changes
Data transfer requests, post transactions from existing
source or interface
Minor screen/window changes, text changes to
customer communications, repeatable marketing
collateral requests
Product/Brand/Logo name changes
Branch retirement
3.2 Project
Project work is defined as a request with a specific
beginning and ending that is to create a unique product or
service that is different from all other products or
services currently provided. The project work stream
outlines structures by which an Information Technology
Project Manager can effectively plan, execute, monitor
and control a project [1] [2]. Requests under this
category may include the follows:
Development Requests (Dev): include new software
development or software upgrade.
Infrastructure Requests (Inf): involve changes to all
environments including integration of new commercial
off-the-shelf software, operating system upgrades,
software / hardware upgrades, installations, support on
servers, network re-configurations etc.
149
Based upon effort, cost and/or risk categorization, a

project request will follow either a Major or Minor
Project Lifecycle.
3.2.1
Minor Project Lifecycle
The Minor Project Lifecycle is used to manage changes

for well known and mature systems with few customer
touch points and few system interfaces. It defines highlevel activities that can be applied to all organizations
within BFS organization with the ability to add LOB
level activities and deliverables to meet the needs of that
particular business.
3.2.2
Major Project Lifecycle
The Major Project Lifecycle is used to manage new

technology, multiple-technologies / platforms, languages,
medium to high technology requirements with medium to
high interfaces with other systems, services or products.
It defines high-level activities that can be applied to all
the sections within BFS organization with the ability to
add LOB level activities and deliverables to meet the
needs of that particular business.
3.3 Program
The Program Lifecycle is used to manage a group of
related projects in a coordinated way to obtain benefits
and control not available by managing them individually.
A Program may include elements of related work outside
of the scope of the discrete projects in the program.
Program management is the centralized management and
coordination of a group of projects to achieve the
program strategic objectives and benefits [7].
The Program Lifecycle is a separate topic (not covered in
this journal or paper) which defines high-level activities
that can be applied to all organizations within BFS
industry with the ability to add LOB level activities and
deliverables to meet the needs of that particular business
[1] [2] [5] 7].
4. Related Processes
4.1 Proposed Prioritization Process
Each LOB should reference the proposed BFS IT
Prioritization model below and further define the steps
specifically applicable to their business prioritization
[8][9].
Functional Prioritization:
The Information Technology Client Services Executive /
Management and the Business leaders partner to:
Discuss and understand the division level

organizational strategic vision.
Develop a Roadmap for the CEO Direct report
functional areas and manage the Roadmap through
scheduled status reviews.
Break
Roadmap
initiatives
into
Strategic,
Compliance/Legal, and Mandatory Programs and
Projects and rank them.
Other Projects and planned Maintenance work
identified and prepared for prioritization against
Shared Resource pools.
150
Communication Planning: Strategic communication

planning and execution should focus on the proactive and
targeted development and delivery of key messages, and
engagement of key stakeholders at the right time and in
the right manner.
Communication Control: The art of managing
communications to inform stakeholders about the project.
It ensures that policies and procedures are received and
understood by the intended recipients.
Consensus on Organizations Priorities:

Functional Priorities discussed at Senior Functional
Leadership forum:
Legal,
Compliance,
and
Mandatory
Programs/Projects for each CEO Direct discussed and
Linkage to Organization Vision, Goals and
Objectives confirmed.
Consensus among CEO Directs that these projects
must be completed above all else.
Organizational Level Roadmap created and reviewed
Monthly, with Quarterly updates from each CEO
Direct.
Organization will align to support Strategic Initiatives.

Assumes that Business Requirements provided are
defined and ready for execution:
Resources assigned to support Strategic Initiatives

Resource tradeoffs minimized and negotiated
Resources allocated to Legal, Compliance and
Mandatory initiatives from each CEO Direct
Resource tradeoffs minimized and negotiated
Non Project work queue worked by Functional
Leader and IT Resources available for tradeoff
4.2 Communication Plan

Communication through a clearly planned approach is a
major component of a successful project. Without
effective communication, key stakeholders could miss
out on vital information and may not understand why
change is needed. Communication management is the
process of determining the information and
communication needs of the project stakeholders in terms
of who needs what information, when they need it and
how it will be given to them. Because of the diversity of
stakeholders possible within a project and the wide range
of their information needs, communications planning
must address not only content, media, customers, and
timing (weekly as a recommendation) but also the
processes and/or systems of data capture, compilation,
and distillation into information for centralized reporting.
Where applicable, the plan must account for and
accommodate differences in nationality, culture and
language, such that it does not impede the effective,
efficient implementation of the project.
Information Distribution: Information distribution is part

of the communication plans and is the process for
making needed information available to project
stakeholders.
4.3 Cost Management

Project cost management includes planning, estimating,
budgeting and controlling costs so that the project can be
completed within the approved budget.
Estimating Costs: Sizing and Effort Estimation for
Project estimates are described in the following section.
Re-forecasting Costs: As the project is executed, project
expenditures must be regularly compared to the project
budget to identify variances so that appropriate action
can be taken.
Cost Control: Cost control will be done proactively by
identifying cost variance from the plan and, where
possible, doing trend analysis to predict problem areas
early. Cost forecasts will also be included as a proactive
cost control.
4.3.1
Capitalization Process
Development
of
new
functionality
and
upgrades/enhancements to existing internal use software
that result in additional functionality is considered an
asset to the company. Rather than incur the expense of
developing this functionality in the current period,
Financial Accounting Standards (FAS) allow for the
capitalization of the internally developed software as an
asset, with the expense to be incurred in future periods.
Technology Finance performs a monthly process that
identifies projects that qualify for capitalization and the
dollars associated with capitalized projects are captured
and booked as an asset on the balance sheet. Once the
software is in production the expense associated with the
additional functionality is incurred over a three to five
year period, and write down the value of the asset,
similar to depreciating a piece of hardware. This allows
the company to realize the expense of the asset over the
period of its useful life [9].
4.3.2
Sizing and Effort Estimation
The purpose of Sizing and Effort Estimation is to assess

the requirement of labor, hardware and software
resources of a project. The Project Manager must gather
the estimates from IT project stakeholders and develop a
work break down structure level estimate. Estimation
must be performed at various stages of the project
lifecycle. Monitoring project progress through the project
lifecycle may identify cost variances exceeding
acceptable thresholds resulting in additional review of
overall project cost and investment [1] [2] [8] [9].
151
Compare the estimate with established standards

Determine whether the methodology is acceptable for
the project
Focus on cost drivers
Determine whether the estimate meets the objective
Use a different approach to validate the estimate
Ensure that mitigation tasks are included in the
estimate (i.e. risk costs)
Ensure that reserve funds have been identified (if
applicable and acceptable to LOB practice)
The cycle is iterative, taking more depth as more

information is discovered through the requirements
engineering and design practices. The cycle is embedded
in the Initiation, Planning and Execution phases of the
project lifecycle.
Sizing and Effort Estimation model must be utilized to

establish consistency of the estimation process in relation
to the overall Process Framework. This must be ensured
by executing the required integration activities.
Formalized and informal tools are utilized by varying
lines of business, but adhere to the overall strategy as
part of the standardization.
The Sizing and Effort Estimation Process may contain

three (3) Levels of estimates. This occurs:
In general, the benefits of introducing standardized

estimation process and models are the facilitation of:
E0 Initiation to support generation of Authorized

Statement of Work (i.e. Project Charter, Cost Benefit
Analysis)
E1 - Business Requirements/Scope Document: Due
after the Business Requirements Document (BRD) or
after the Scope Document
E2 Design/Defined Solution: Due after Detailed
Design is completed or once a solution is defined
Making investment or other financial decisions

involving a software development effort
Setting project budgets and schedules as a basis for
planning and control
Deciding on or negotiating trade-offs among software
cost, schedule, functional, performance, and quality
factors
Making software cost and schedule risk management
decisions
Deciding which parts of a software system to
develop, reuse, lease, or purchase
Making legacy software inventory decisions about
what to modify, phase out, outsource, etc.
Setting mixed investment strategies to improve the
organizations software capability, via reuse, tools,
process maturity, outsourcing, etc.
See Table 1 for details.

* Note: Each LOB can establish thresholds within the
accuracy guidelines documented above.
Methods to be considered:
Parametric specific measures used to estimate the effort
required completing a particular task or producing a
particular work product.
Analogy / Comparison Estimating
o
o
o
o
o
Evaluate project
Find comparable Project
Assess comparable Project
Evaluate cost of previous project
Apply to new project
Expert Judgment Estimates

o
o
Used to assess input to the estimating process

Expertise is provided by any group or individual with
specialized knowledge of training
The activities to be estimated will include not only

development or infrastructure related tasks but also test
related validations (from unit testing, systems integration
testing to UAT) and support related tasks (configuration
management / change management). Specifically, for
each environment it will include:
Configuration
activities creation / changes / testing (example: new
environment(s), new object types), build and deployment
activities and data management (extract / refresh)
activities [1] [2].
Others
o
o
o
PERT
Function Point Analysis
Individual LOB defined methods
Validating an Estimate
It is important that the validity of the estimation (whether
it is cost or hours) be understood.
Review the definition of the project

Study ground rules, constraints, and assumptions
Focus on sources of the data
4.4 Deviation Process

The deviation process must be utilized only for approvals
on exceptions to process or where architectural standards
are sought. Exceptions must not be the norm. Mitigating
factors that reduce or eliminate risk as well as offset
benefits to be realized by the company must be criteria
for approval/disapproval of any request. The deviation
document will be stored with the project or identify what
deviation the project executing under and their location.
4.5 Requirements Management
4.5.1
Requirements Traceability
Requirements Traceability is the ability to describe and

follow the life of a requirement, from its origin through
construction, validation and implementation or
deployment. The purpose of Requirements Traceability is
to ensure completeness and consistency of the
requirements throughout the lifecycle of the project. It's
one of the key activities driving the success of a project
[1] [2].
Use of a requirements tracing technique or method must
be defined by each LOB. Regardless of method or
technique, the traceability will:
4.5.2
provide a linkage of requirement to designs,

components and/or test cases
ensure coverage of test/validation
identify inconsistencies
provide verification of requirements through the
lifecycle
support changes of requirements
Scope Change Management
Scope Change Management is the procedure that

manages and controls the baselines.
A change control system includes formal documented
procedures to define how to manage change, it
establishes documentation, tracking systems, and
approval levels necessary to authorize change [1] [2].
Evaluation of change is critical to the overall project

impact assessment.
Determine if the change is
Baselines must be established because they are

commitments. Baselines also
Incorporate the original plans for a project plus or

minus approved changes
Serve as the basis for managing change
Help serve as the basis of ensuring that the project is
complete
Define the Scope of the project
Are approved
Change Management Plans may include
Change Control Process

Change Request Forms
Directly related to an agreed-upon deliverable

Required to maintain the integrity of the solution
Affecting cost, schedule and risk (relative to the
remaining schedule) and time line
Affecting any other change requests
Has a cumulative effect
Determining who can authorize change to a project is

established at project initiation and is then recognized as
the Change Control Board (CCB).
Authorized representatives accept, reject, defer, or

negotiate changes
Authorizing parties will be the Change Control Board
Authorization may change over the lifecycle of the
project
Change Control Board exists for the life of the project
Change can originate from anywhere.
It is the single most important problem facing the

project management team
It will affect cost, schedule, scope (increase or

decrease), risk, and resources
It can originate from anywhere and must be

controlled
Managing change
Facilitates trade-off analysis between change requests
Improves customer satisfaction by making the right

changes
Supports effective use of resources
Authorized representatives whose purpose is to

receive, review, recommend and communicate the
change identified for assessment
A Change Control Log which provides the decision
made by the representatives for the change
acceptance, rejection, deferment
It is important to identify what baselines will be

controlled, at what level of detail, and how and by whom.
Change must be managed because
152
Authorized representatives accept, reject, defer, or

negotiate changes
Authorizing parties may be internal to the project
team or external
Authorization may change over the lifecycle of the
project
There may be multiple authorities
The primary role of the project manager relative to

change management is to ensure there is a change
management process, or to establish a change
management process for the project. This may vary
dependent upon whether a change management process
has been designed, implemented and established for the
LOB. If the process has not been established, the project
manager must design the process and establish the
change management process. Implementation of the
process includes
Analysis of the change requests assessing the

effects of the change: risk, baselines
Management of the scope accept or reject change
Revise baselines
Communication of the results of the decisions to
accept, reject or defer
Guidelines for change management
Determine how changes are to be introduced and
processed as part of the project plan
Use a change request form to document any proposed
changes
4.6
Ensure that changes are approved by the authorized

representatives (CCB)
Update the baselines and all appropriate
documentation after the change is approved
Ensure that the change management process reflects
acceptable design characteristics that support change
management and a control plan
Risk Management
The purpose of Risk Management is to ensure that levels

of risk and uncertainty are properly managed so that the
project is successfully completed. Risk Management at
the project level identifies project risk and executes
project risk response plans.
Risk is a possible undesirable and unplanned event that
could result in the project not meeting one or more of its
objectives [1].
project) is one of the key processes for the success of the

project. The project stakeholders must begin the process
of identifying risks as early as the project initiation
phase. Risks must be documented by the Project
Manager and updated on a regular basis. At a minimum,
risk should be re-evaluated at the phase gates.
The proper response to an identified risk depends on its
probability (low, medium, or high) and the impact if it
actually occurs (low, medium, or high). A risk that is
both high probability and high impact must be avoided if
possible, or a contingency plan written to reduce the
damage if it occurs. A risk that is low probability and/or
low impact may not require any corrective action or a
contingency plan.
Considerations for managing project level risks include:
Reviewing risk plans of component include:
An event identify the risk event

Probability Identify the probability of the
occurrences of that event
Impact Determine the amount of impact or the
amount at stake
Note: All projects have risks. If risks are ignored, the

likelihood that the project will fail in some way is
increased. Probability and impact are relative to the
specific individual project.
Risk Management is important because it:
Assists in the protection of cost, schedule, and

requirements
Prevents surprises
Promotes the focus on building the right offering the
first time
Facilitates the prevention of management by crisis
Prevents / minimizes problems from occurring or (if
problems do occur) from escalating
Institutionalization of risk management

Planning to handle risks
Incorporating risk management into the project
management planning process
Using the right tools to fit the situation
Monitoring / communicating risk on a regular basis
Reassessing risk after each risk event
Facilitating risk management process
Calling for independent reviews (i.e. Quality
Assurance tests)
Risk Management (the process of identifying risks and

mitigating and monitoring them at early stages of the
Identifying cross project risks

Reviewing risk plans of component projects that
could affect other projects in the program
Determining root cause of inter-project risks
Risk Identification: Project risks must be identified to

minimize impact to deliverables.
Identify Risk Indicators (Triggers) for each risk event:
Use these triggers to monitor the potential

occurrences of a risk event
Document and communicate these triggers to the
team
Update triggers as circumstances demand
Assign owner
Risk Analysis: The probability of risk occurrence and the

severity of impact on the project must be routinely
assessed throughout the lifecycle.
Evaluate Risk:
It is the project managers responsibility to identify the

risks, assess the severity of the risks, and describe
mitigation strategies and contingency plans. However, it
is the combined project teams responsibility to identify
and understand risks. Tasks within the project delivery
include:
153
Analyzing
Determine
o Probability of occurrence
o Magnitude of loss or impact of each
identified risk event
o Severity of risk (Severity = Probability X
Impact)
Prioritizing
o Rank those risks that will have an effect on
the project
o Decide which risks are worthy of attention
Methods for Analyzing Risk
Quantitative
Objective
Uses probability concepts
Understanding of statistics is helpful
Qualitative
Subjective
Uses ordinal values
Requires definition of ranking system
Prioritize Risks
Rank analyzed risks highest to lowest

Use rankings when possible, otherwise use qualitative
rankings
Separately rank risks with similar ratings
Prioritize risks as a team (assess variations on
tolerance to risk)
Do not plan mitigation strategies at this time
Risk Response: Procedures and techniques should be

developed to enhance opportunities and reduce threats to
the delivery of project benefits. Risks must be escalated
to the appropriate levels to ensure risk resolution
Risk Mitigation Strategies:
Avoid risk has been identified, but choosing not to

respond or act on the risk
Ignore risk has been identified and willing to accept
the consequences should they occur
Contain risk has been identified and will take
specific action to minimize its occurrences and
effects
Establish Contingency risk has been identified and
funds have been set aside to be used when the risk
occurs or when later containment is deemed to be
appropriate
Transfer risk has been identified, and will transfer
all or a portion of it to another entity
The following factors affect selection of risk mitigation

strategies:
Project phase and application

Size
Priority
Complexity
Expense
Time available
Cost of risk response and mitigation technique
Required level of detail
Ease of use
Resource availability
Project manager and upper managers commitment
Risk Tracking: The assessment of risk is tracked and

communicated to stakeholders.
4.7
Issue Management
Issue management and control involves identifying,

tracking and closing issues effectively to ensure that
stakeholder expectations are aligned with project
activities and deliverables. An issue is a risk that
becomes reality.
Risk management and issue
management are closely aligned. If an issue was not
previously identified as a risk it might be captured in the
applicable risk catalog for future information [1] [2].
154
Issue management and control at the project level may

also include addressing the issues escalated from the
constituent projects that could not be resolved at the
project level.
Issue Identification: Project issues must be identified to
minimize impact to deliverables.
Issue Tracking: The assessment, ownership and
remediation of issues are tracked and communicated to
stakeholders.
Issue Escalation: Unresolved issues must be escalated to
the appropriate level in the project governance structure.
Issue Management is a project lifecycle process and must
be documented and reported by the Project Manager and
updated on a weekly basis. Issues should be re-evaluated
at the phase gates
4.8
Lessons Learned
The purpose of Lessons Learned is to evaluate the

changes, risks, issues; actions, outcomes, behaviors, etc
that positively or negatively impact the successful
completion of the project.
The identification of lessons learned occurs throughout
the life of the project. The primary role of the project
manager relative to capturing lessons learned is to ensure
there is a gathering mechanism identified early in the
lifecycle, informally review and maintain them
throughout the life of the project and summarize them at
project closure.
4.9
Release Management Process
Release Management is responsible for leading the effort

to address the formal planning of technical and nontechnical requirements of technology deployments. The
Release Management function comprises several major
functions:
Release Management, Implementation
Management, and Environment Management [1] [2].
The Release Management process takes a holistic view of
a change to the enterprise and considers the impact of
that change to IT services. Release Management ensures
that all aspects of a Release, both technical and nontechnical, are considered together.
The Release Management area is heavily involved
throughout most of the project lifecycle. They are
engaged upfront in determining appropriate release
schedules for delivery of projects, serving as gatekeepers to ensure appropriate milestones are met,
reviewing projects to be installed into production from
the UAT environments, monitoring releases, release
changes, and managing approvals to implement.
155
Project Manager Responsibility:

The purpose for the Release Management process is to
support the ability to monitor and list what is being
released. The Release Management function is specific
to line of business (LOB). A Release Calendar will be
established and published and followed for project
deployment for planning and control purposes.
Release Structure Exceptions for mandatory legal, audit
and compliance projects are to be created at the LOB
level, with appropriate approvals as required.
4.10
Software Quality Assurance (SQA)
Software Quality Assurance (SQA) is an independent

evaluation of adherence to project management standards
and processes. SQA performs the validation and
verification roles through end-to-end monitoring of
project activities and deliverables. SQA ensures that the
defined BFS IT Life Cycle and Project Management
Standards are followed and all key project deliverables
are complete and are of quality. SQA examines whether
or not projects are being managed, built, and
implemented according to processes that will deliver the
agreed customer requirements in a cost effective and
timely manner [1] [2] [10].
Program Manager Responsibility:
Components of the SQA Process include:
Review Continuous review of active projects

Artifact Deviation Allow artifact deviation for
projects as needed
Validation Validate required key project
deliverables and project health metrics
Reporting Report non-compliance issues (NCIs) to
management
Escalation Escalate unresolved NCIs to
management for resolution
SQA Process includes:
Identification of active projects in repository or

project management tool
Notification of reviews
Validate retention of all final version of documents in
project repository as audit evidence
Retention of SQA Review results in SQA repository
as audit evidence
Continuous review of all active, ranked, and closed
projects in accordance with the SQA Review
Checklist
Communication of non-compliance issues to
responsible management
Resolution of non-compliance issues
Escalation of unresolved issues including aging of
issues to responsible management
Communication of SQA Monthly Report to
responsible LOB and BFS IT management
Periodic analysis of SQA metrics and root cause
analysis, corrective actions and mentoring
Understands and adheres to the BFS IT Life Cycle

Standards including the:
o Life Cycles for Software Development and
Infrastructure Projects (Major and Minor)
o Maintenance Life Cycle
Understands and adheres to the LOB Process Control
Manual(s).
Oversees the completion of required deliverables and
their storage in the project repository
Assures all project goals, scope, plans, schedules and
budget are consistent.
Reviews the project status at each phase, after
analyzing each hard and soft gate, and conducts
impact analysis on plans, schedules and budget.
Works with the assigned SQM during the SQA
review.
Oversees the resolution of non-compliance issues
identified during the SQA reviews in a timely
manner.
Understands and adheres to the BFS IT Program Life

Cycle.
Notify SQA Team of the initiation of Programs.
Communicates with the SQA Team throughout the
Program Life Cycle and incorporates SQA feedback
into program activities and deliverables.
Documents and executes programs in accordance
with the Program Life Cycle.
Software Quality Assurance (SQA) Responsibility
Conduct continuous reviews of all active projects.

Communicate issues to Project Managers as they are
identified.
Review and close issues as they are resolved by
Project Managers.
Escalate un-resolved issues to responsible
management.
SQA Escalations
Escalations provide the structure and methodology
for representatives from the SQA group to validate
adherence to the process and escalate noncompliance issues effectively. Non-Compliance
items identified by the SQA group are first
addressed with the appropriate owners and are
resolved, if possible. For issues not resolved, the
SQA group escalates to an appropriate level of
management
for
resolution.
Appropriate
management owns the responsibility to have
corrective actions in place to resolve the outstanding
issues.
Recourse to Escalation: Escalation notification must be
evaluated to understand the root cause of the escalation.
If appropriate, processes must be reviewed and adjusted
as needed to address any gaps. Alternatively, if the root
cause is lack of training, then mentoring and training to
resolve the escalation must be provided to the appropriate

accountable individual or groups. Reoccurring instances
of non-compliance could result in management taking
appropriate corrective actions to improve individual or
group performance.
4.11
Risk Control Self Assessment (RCSA)
Defining Roles and Responsibilities: Once the team

structure is defined and individuals selected, roles and
responsibilities must be documented along functional and
service line roles. The following are key roles that make
up the project team.
Role
Project Manager
Delivery Lifecycle
BFS Industrys Risk and Control Self Assessment /
Operation Risk Policy and Standards require technology
organizations to perform periodic self-assessments based
on the BFS Information Technology Management Policy
(BFS IT MP). BFS IT MP is the BFS standard for
managing information technology. The BFS IT RCSA
Process is based on a standardized Risk and Controls
Framework that identifies both important and less than
important risks, and the associated key and non-key
controls. Controls are periodically assessed and any gaps
are subject to corrective action.
Project Stakeholder(s)
Sponsor
Client Service Manager
Senior technology management reviews results of the

self-assessment quarterly.
Customer(s)
4.12
Document Retention
Resource Manager(s)
LOB Project Management Office will comply with

the Records Retention Policy.
4.13
Resource Management
Resource management determines the people and

systems that are needed, and in what quantities and from
what organizations, in order to complete the project. It
seeks to optimize the use of available resources across
the project. Resource planning at the project level must
pay careful attention to how common project resources
are allocated across projects to ensure that they are not
overcommitted. Resource escalation procedures must be
defined, where applicable [1].
Managing Human Resources: Human resource
management monitors human resources to ensure that
committed resources are made available to the project
consistent with commitments, i.e. that they are allocated
and released according to the project plan. A detailed
analysis must be undertaken to identify the personnel
needed to complete the projects activities and tasks on
time and to the required level of quality.
An escalation plan for insufficient resource allocation
among negotiated resources must be documented and
become part of the Project Management Plan, where
needed.
156
Project Management
Office
Project Team Members
Responsibilities
The individual responsible for managing
the project. The Project Manager (PM)
owns the project plan & schedule and is
directly involved in managing the project's
activities to achieve the project's
objectives. The PM is responsible for
preparing project plans, identifying and
requesting resources from the
Resource/Technical Manager for the
project tasks.
Individuals and organizations that are
actively involved in the project, or whose
interests may be positively or negatively
affected as a result of project execution or
project completion.
The individual or group that provides the
financial resources for the project.
The technology liaison to the Business.
Responsible for ensuring business and
technology alignment and has both,
business technology specific knowledge.
The individual or organization that will
use the projects product.
The Resource/Technical Manager is
responsible for supporting and
maintaining application systems.
Responsible for ensuring changes to
systems comply with applicable
architecture and coding standards. The
Resource/Technical Manager owns the
resources and is responsible for managing
resource schedules, responding to resource
requests from the PM and assigning staff
to project activities.
The Project Management Office (PMO) in
a business or professional enterprise is the
department or group that defines and
maintains the standards of process,
generally related to project management,
within the organization. The PMO strives
to standardize and introduce economies of
repetition in the execution of projects. The
PMO is the source of documentation,
guidance and metrics on the practice of
project management and execution.
The group that is performing the work of
the project.
The project organization structure supports the

completion of project activities and provides an adequate
level of oversight, review, and contribution from
necessary parties. Clearly defining the project
organization structure up-front is a critical success factor
for projects.
The roles and responsibilities are specific to each LOB
and must be baseline at that level for the individual
phases of a project.
Defining Reporting Relationship: Where matrix reporting

relationships occur in a project structure, these
relationships need to be clearly articulated to avoid
conflict.
Phase
Overview
of this phase validates requirements
have been met and implementation
approval obtained. Each LOB must
establish responsibility for sign-off
approval on each request based on a
review of the deliverables and testing
results.
5. Maintenance Lifecycle
5.1
Purpose
ETVX: Phase Gate
The Maintenance Lifecycle provides an overview of the

process for managing non-project work as previously
defined in Section 3.1. This includes the coordination
and prioritization of cross-functional resources to obtain
the desired benefits of the maintenance request.
The Maintenance Lifecycle outlines the structure by
which an Information Technology manager can
effectively provide planned support to operational
applications. It defines high level activities that can be
applied to all organizations within BFS IT with the
ability to add LOB level activities and deliverables to
meet the needs of that particular business. It contains the
required deliverables and activities that can be followed
logically from beginning to end and is demonstrated
through steps within each phase. See Figure 3 for details.
5.2
Phase Overview
Phase
Initiation
Overview
The purpose of the Initiation Phase is
to define and document the scope
and objectives of the work and to
ensure that the work is classified for
the
appropriate
lifecycle
and
authorized to move forward.
ETVX: Phase Review
Work prioritization is incorporated into
the authorization process.
The
outcome of the prioritization process
will be a prioritized/ranked list of work
requests. Criteria for this process are
defined at the LOB level.
Construction
Validation
157
This phase focuses on the translation

of work requests into technical
changes. The objectives are to
modify necessary components and
conduct
preliminary
tests
and
configuration
management
in
preparation for deployment.
The
Maintenance Lead tracks and
controls the requests.
ETVX: Phase Review
This phase includes appropriate
levels of testing, when applicable. In
addition, the phase includes the
verification that correct components
are
staged
and
ready
and
configuration
management
documentation is completed. The end
Implementation
At this point, appropriate change

units are implemented into production
and system functionality is validated.
There is follow up with the
business/requestor to ensure that
they are satisfied with the delivery
and communicated issues are
appropriately resolved.
Maintenance Close: Finalize the
maintenance tracking activities and
officially closes the request.
5.3
Maintenance Requirements
Maintenance Requirements provides flexibility for the

maintenance team to determine phase level requirements
based on the scope and complexity of the individual
request. During planning, the maintenance lead must
evaluate requirements categorized as C and determine
the documentation that will be provided as part of the
maintenance deliverables. See Table 2.
5.4
Initiation Phase
5.4.1
Purpose
As the name suggests, the first phase of the Maintenance

Lifecycle is the notification and analysis of an
operational need. The purpose of this phase is to
evaluate the maintenance request in a way that
determines the necessity and sets the priority of the
request so that management can plan and address the
need in an expedient manner. Upon completion of this
phase the maintenance request should be validated,
categorized, scheduled and resourced for resolution.
ETVX
5.4.2
Entry Criteria
Criteria
Operational Need - A work request has been initiated.
5.4.3
Tasks
See Table 3.
158
Exit Criteria
5.4.4
Validation and Verification
Deliverable
R/C
Action
Technology Assessment
Definition of what is to be accomplished has been

documented
Preliminary Information Security Questionnaire
Unit Test Results
Configuration Management Record(s)
Review of work request
5.4.5
Exit Criteria
(R - Required, C - Comply as necessary, NA - Not Applicable)
Deliverable
R/C
Work Request Validated
Work Request Categorized/ Prioritized
5.6
5.5
Construction Phase
5.5.1
Purpose
The purpose of this phase is to develop the requested

changes so that the intended deliverables satisfy the work
request. This may include analysis, the development of
specifications, deliverables, testing of deliverables and
Configuration Management records. Upon completion of
this phase the work request should be ready for formal
testing
and/or
validation
approval.
ETVX
5.5.2
Validation Phase
5.6.1
Purpose
Validation is the confirmation, by examination and

provision of objective evidence, that maintenance
specifications have been met and will fulfill the
operational need and intended use of the work product.
ETVX
5.6.2
Entry Criteria
Criteria
Code (and/or other work products)
Unit Test Results
Entry Criteria
5.6.3
Tasks
Criteria
See Table 5
Work Request Validated
Work Request Categorized/ Prioritized
5.5.3
Tasks
5.6.4
Action Phase Gate Hard Stop

Approval to implement, defined by LOB.
See Table 4 for Tasks
5.5.4
5.6.5
Exit Criteria
Action
Deliverable
R/C
Review work products and/or test results against maintenance

standards (i.e. specifications, hardware, code, etc).
System Test Results (Conditional)
User Acceptance Test Results (Conditional)
Approved Configuration Management Record
5.7
6.2
Implementation Phase
Phase Overview
Purpose
Overview
To transfer the modified application(s) to the production

environment, ensure the work product(s) is performing as
intended, and close the work request.
Phase
5.7.1
The purpose of the Initiation Phase is to define and

document the scope and objectives of the change
request and to ensure that the project is classified for
the appropriate lifecycle and authorized to move
forward.
ETVX: Phase Review
ETVX
5.7.2
Entry Criteria
Criteria
Project prioritization is incorporated into the

authorization process.
The outcome of the
prioritization process will be a prioritized/ranked list of
projects. Criteria for this process are defined at the
LOB level.
Initiation
Validation Phase Gate Pass

Approved Configuration Management Record
5.7.3
This phase is used to define requirements. This

includes a detailed understanding of the business
requirements. The business requirements are
reviewed by project stakeholders and technology to
seek a better understanding of the why, who, when,
and how of the sponsors request. During this phase
the sizing, plan and draft schedule are updated with a
soft release date commitment.
ETVX: Phase Gate
Tasks
Definition
See Table 6
5.7.4
Action
Documentation complete and work closed out.
Completed (closed) Work Request
(R - Required, C - Comply as necessary, NA - Not

Applicable)
6. Minor Project Lifecycle

Purpose
The Minor Project Lifecycle provides an overview of the

process for managing small projects or work requests that
are better managed as small projects. These are
modifications or changes to existing features, products,
or services on well known and mature technology with
few customer touch points and few system interfaces.
This includes the coordination and prioritization of crossfunctional resources to obtain the desired benefits of the
requested actions.
The Minor Project Lifecycle outlines the structure by
which an Information Technology Project Manager can
effectively plan, execute, monitor and control the work.
It defines high-level activities that can be applied to all
organizations within BFS IT industry with the ability to
add LOB level activities and deliverables to meet the
needs of that particular business. See Figure 4 for
details.
The solution is ready to move into testing. This

includes system testing and when applicable
coordinates user acceptance testing with the
supported business units. The end of this phase
validates testing has been completed and business
requirements have been met.
ETVX: Phase Gate
Validation
R/C
Construction
Exit Criteria
Deliverable
6.1
This phase focuses on the translation of the

requirements information gathered into functional
specifications and a technical solution. The
objectives are to produce a functional specification
and/or technical design for construction. The sizing,
plan and schedule are finalized and the release date
is locked. The PM concentrates on tracking and
controlling the project. In general, this phase focuses
on all scheduled activities (writing software, unit
testing, etc.).
ETVX: Phase Review
Implement-ation
5.7.5
159
At this point, business sign-off has been obtained

and the change request has been accomplished. A
contingency plan has been considered. Changes are
implemented into production and changes are
validated in production. This phase provides an
opportunity to identify and manage any defects on
the change request just installed into production.
There must be follow up with the business to ensure
that the business is satisfied with the system and
communicate open issues to appropriate groups to
resolve.
Project Close: Lessons learned are conducted and
communicated and the transition to BAU takes place.
The project is officially closed.
ETVX: Phase Review
NOTE: Definitive stages of what can be capitalized

/ not capitalized should be directed by the Finance
group.
6.3
Project Requirements
Project Requirements provide flexibility for the project

team to determine phase level requirements based on the
scope and complexity of the individual request. During
project planning phases, the project team must evaluate
requirements categorized as C and agree upon the
documentation that will be provided as part of the project
deliverables. See Table 7.
6.4
6.4.5
160
Exit Criteria (Phase Review)
Deliverable
Dev
Inf
Initial E0 Estimate
Preliminary Project Plan
Project Priority and Rank
Approved
Objectives
Project
Scope
&
Initiation Phase
6.4.1
Purpose

document the request, review the request with the
affected parties, and ultimately approve the request. The
Project Initiation process ensures that all projects receive
appropriate due diligence and are reviewed in reference
to the organizations strategic plan and business
objectives. Once the request is approved, analysis can
begin to assess whether the request is reasonable and
technologically feasible. Preliminary analysis includes
determining possible approaches estimating work effort
based on those assumptions.
An outcome of this
analysis is prioritization followed by assignment of
Project Manager to execute the appropriate project
methodology. A preliminary project plan with the
appropriate level of detail (task or milestone) is also
created in this phase.
ETVX
6.4.2
Entry Criteria
Criteria
Business Need - A business problem or initiative that requires
project management methodology.
Business case, alignment with business goals and strategy,
problem statement, business risk analysis, cross functional
impacts, and priority criteria.
6.5
Definition Phase
Purpose
Definition is the process of quantifying performance and
interface requirements through an analysis of all of the
client requirements. This phase includes the assessment
of the current environment and the development of the
specific business requirements that will fulfill the needs
of the business stakeholders.
During this phase, business requirements are approved.
Both a Technology Assessment and an Export
Compliance review are conducted to identify project
risks early on. In addition, the Information Security
Requirements (ISR) is initiated and questionnaires are
completed to ensure adherence with the BFS IT MP and
BFS Information Security Standards (CISS). It is
important to maintain cross team communication to
ensure all key organization and stakeholder requests are
considered.
ETVX
6.5.1
Entry Criteria
Criteria
6.4.3
Tasks
See Table 8
Approved scope and objectives

E0 Estimate
Priority Ranking and High level Plan
6.4.4
Action
documented
Review of preliminary project plan
6.5.2
Tasks
See Table 9
6.5.3
161
Criteria
Definition Phase Gate Pass
Validate all deliverables for phases are available

Validate the BRD and Approvals (if applicable to the
project)
Approved Business Requirements Document (BRD) (if

applicable)
Review/Approve the E1 Estimates and revised Project

Schedule (if applicable to the project)
Acknowledgement of Technology Assessments
Review the risk assessments (Technology Assessment,

Export Compliance, Information Security)
Acknowledgment of Export Compliance Assessment
Review the risk and contingency plans
Acknowledgment
Assessment
6.5.4
of
Preliminary
Information
Security
Exit Criteria (Phase Gate)

Coding and Infrastructure standards are available
Deliverable
Dev
Inf
Approved Business Requirements
Acknowledgement
Assessment
Project Lifecycle assignment
Action
Acknowledgment of
Assessment
Export Compliance
Review of Test Plan and Scripts
Acknowledgement
of
Preliminary
Information Security Assessment
Initiation Estimate (E1)
Maintained Scope Change Management,

Risk and Issues
Maintained Schedule and Status
6.6.3
Tasks
See Table 10
of
Technology
6.6.4
Review estimates and project plan

Review the Functional Specification and Technical Design
if applicable
Review / walkthrough the code available
Validate Construction Information Security Questionnaire
R
Review the unit test results
6.6.5
6.6
Construction Phase
6.6.1
Purpose
Construction phase involves translating business

requirements into functional specifications and technical
design. This phase covers the operational aspects for the
proposed solution and should provide detailed
information for the IT area to construct the system. This
phase also involves initiation of software development,
infrastructure procurement and deployment, rollout
plans, and unit test plans based on the user requirements.
ETVX
6.6.2
Entry Criteria
Deliverable
Dev
Inf
Approved Functional Specification
Technical Design
Design Estimate (E2)
Test Plans, Scripts and Results
Code reviews / Infrastructure reviews
Configuration Management Record Testing
NA
Maintained Scope Change Management, Risk

and Issues
Construction
Questionnaire
Information
Security
6.7
Validation Phase
6.7.1
Purpose
Validation is the confirmation by examination, and

provision of objective evidence, that project
specifications have been met and will fulfill the business
requirements. Project implementation can occur only
after successful completion of the acceptance test and
there is confidence that the system meets the business
requirements. The focus of this phase will be to ensure
system meets the specifications, end user acceptance of
the product and appropriate regression testing to ensure
system sustainability in a production environment.
ETVX
6.7.2
Entry Criteria
Criteria
Product readiness Completed construction, peer reviews,
unit testing.
Quality Test Plans and Scripts Test plan and scripts built
against the BRD, functional and technical design.
Configuration Management (s) Configuration records
exist for migrating code into the testing environment.
6.7.3
Tasks
See Table 11
6.7.4

Validate all deliverables for previous phases are available
Ensure Test Results are documented in the system of
record
Deliverable
Dev
Inf
Information Security Questionnaire
Test Results
Sponsor Approval to Implement
Technology Operational Handoff
Approved
Record
Management
Maintained Scope Change Management,

Risk and Issues
Configuration
6.8
6.8.1
Purpose
This phase represents the actual implementation of the

product into the production environment upon the
successful completion of testing. These criteria are
specific to data center groups and must be verified with
the specific business units. At this phase defects are
managed and ensured that the systems are re-tested based
on defect related coding changes. The phase is also an
opportunity to conduct lessons learned before project
closure. Lessons Learned are to be shared with project
stakeholders to improve processes as appropriate.
ETVX
6.8.2
Entry Criteria
Criteria
Validation Information Security Assessment, if applicable
6.8.3
Validate Operational Handoff Documentation, if applicable
See Table 12
Ensure Sponsors Approval to Implement
162
6.8.4
Tasks
Action
6.7.5
Ensure production defects are logged, prioritized, fixed

and/or transferred to production support.
Ensure Lessons Learned is summarized.
Validate all documentation is available and project is closed
out.
6.8.5
163
Deliverable
Dev
Inf
Production Defect Logs
NA
Summarized Lessons Learned
This phase is used to define

requirements.
This includes a
detailed
understanding
of
the
business requirements. The business
requirements are reviewed by project
stakeholders and technology to seek
a better understanding of the why,
who, when, and how of the sponsors
request.
During this phase the
sizing, plan and draft schedule are
updated with a soft release date
commitment.
ETVX: Phase Gate
Definition
(R - Required, C - Comply as necessary, NA - Not

Applicable)
7. Major Project Life cycle

7.1
Design
Purpose
The Major Project Lifecycle provides an overview of the

process for managing new technology, multipletechnologies / platforms, languages, medium to high
technology requirements with medium to high interfaces
with other systems, services, and/or products. This
includes unique products or services that are different
from other products or services currently provided. This
requires the coordination and prioritization of crossfunctional resources to obtain the desired benefits of the
requested actions.
The Major Project Lifecycle outlines the structure by
which an Information Technology Project Manager can
effectively plan, execute, monitor and control a project. It
defines high-level activities that can be applied to all
organizations within BFS organization with the ability to
add line of business level activities and deliverables to
meet the needs of that particular business. See figure 5.
7.2
This phase focuses on the translation

of the requirements information
gathered into functional specifications
and a technical solution. The
objectives are to produce a technical
design for the Construction through
Implementation phases of the project.
The sizing, plan and schedule are
finalized and the release date is
locked.
ETVX: Phase Review
Phase Overview
Phase
Overview
Initiation
The purpose of the Initiation Phase is

to define and document the scope
and objectives of the change request
and to ensure that the project is
classified for the appropriate lifecycle
and authorized to move forward.
ETVX: Phase Review
Project prioritization is incorporated
into the authorization process. The
outcome of the prioritization process
will be a prioritized/ranked list of
projects. Criteria for this process are
defined at the LOB level.
The PM concentrates on tracking and

controlling the project. In general, this
phase focuses on all scheduled
activities (writing software, unit
testing, etc.).
ETVX: Phase Review
Construction
The solution is ready to move into

testing. This includes system testing
and when applicable coordinates user
acceptance testing with the supported
business units. The end of this phase
validates testing has been completed
and business requirements have
been met.
ETVX: Phase Gate
Validation
At this point, business sign-off has

been obtained and the change
request has been accomplished. A
contingency
plan
has
been
considered.
Changes
are
implemented into production and
changes are validated in production.
ETVX: Phase Review
Implementation
Post
Implementation
This phase provides an opportunity to

identify and manage any defects on
the change request just installed into
production. There must be follow up
with the business to ensure that the
business is satisfied with the system
and communicate open issues to
appropriate groups to resolve.
Project Close: Lessons Learned are
conducted and communicated and
the transition to BAU takes place.
The project is officially closed.
ETVX: None
NOTE: Definitive stages of what is capitalizable/not

capitalizable should be directed by the Finance group.
Project Requirements
7.4
Project Requirements provide flexibility for the project

team to determine phase level requirements based on the
scope and complexity of the individual request. During
project planning phases, the project team must evaluate
requirements categorized as C and agree upon the
documentation that will be provided as part of the project
deliverables. See Table 13
7.4.1
7.3
Initiation Phase
7.3.1
Purpose

document the request, review the request with the
affected parties, and ultimately approve the request. The
Project Initiation process ensures that all projects receive
appropriate due diligence and are reviewed in reference
to the organizations strategic plan and business
objectives. Once the request is approved, analysis can
begin to assess whether the request is reasonable and
technologically feasible. Preliminary analysis includes
determining possible approaches estimating work effort
based on those assumptions.
An outcome of this
analysis is prioritization followed by assignment of a
Project Manager to execute the appropriate project
methodology. A preliminary project plan with the
appropriate level of details (task or milestone) is also
created in this phase.
ETVX
7.3.2
164
Definition Phase
Purpose
Definition is the process of quantifying performance and

interface requirements through an analysis of all of the
client requirements. This phase includes the assessment
of the current environment and the development of the
specific business requirements that will fulfill the needs
of the business stakeholders.
During this phase, business requirements are approved.
Both a Technology Assessment and an Export
Compliance review are conducted to identify project
risks early on. In addition, the Information Security
Requirements (ISR) is initiated and questionnaires are
completed to ensure adherence with the BFS IT MP and
BFS Information Security Standards (BFS ISS). It is
important to maintain cross team communication to
ensure all key organization and stakeholder requests are
considered.
ETVX
7.4.2
Entry Criteria
Criteria
Approved scope and objectives
E0 Estimate
Entry Criteria
Priority Ranking and High Level Plan
See Table 14
7.3.3
7.4.3
Action
documented
Cost/Benefit analysis
Tasks
See Table 15
7.4.4
Review of preliminary project plan
7.3.4

Validate all deliverables for previous phases are available
Deliverable
Dev
Inf
Approved Project Scope & Objectives
Initial E0 Estimate and Cost / Benefit Analysis
Project Priority and Rank
Review the risk assessments (Technology Assessment,

Export Compliance, Information Security).
Preliminary Project Plan
Review the risk and contingency plans.
Review the BRD and approvals.
Review/Approve the E1 Estimates and revise Project

Plans.
7.4.5
7.5.4
165
Action
Deliverable
Dev
Inf
Approved Business Requirements
Project Lifecycle assignment
Acknowledgment of Export Compliance

Assessment
Acknowledgement
of
Preliminary
E1 Estimate,
Tentative Release Date
Maintained Schedule, Status, Scope

Change Management, Risk and Issues
Review estimates and project plan

Review the Technical Design
Validate Design Information Security Questionnaire
Review System Test Plans
7.5.5
Deliverable
Dev
Inf
Technical Design
Approved E2 Estimates
Approved CEP

Change Management, Risks and Issues
Design
Information
Questionnaire
Security
7.5
Design Phase
7.5.1
Purpose
Design phase involves translating business requirements

into Functional Specifications and Technical Design.
This phase covers the operational aspects for the
proposed solution and should provide detailed
information for the IT area to construct the system.
ETVX
7.5.2
Entry Criteria
7.6
Construction Phase
7.6.1
Purpose
Construction phase involves initiation of software

development,
infrastructure
procurement
and
deployment, rollout plans, unit test plans and operational
handoff documentation based on the user requirements.
ETVX
Criteria
Definition Phase Gate Pass
Approved Business Requirements Document (BRD)
Completed Technology Assessments
Acknowledgment of Export Compliance Document
Acknowledgment of Preliminary Information Security
Questionnaire (ISQ)
7.5.3
Tasks
See Table 16
7.6.2
Entry Criteria
Criteria
Functional Specification
Technical Design
System Test Plans
Coding and Infrastructure Standards are available
7.6.3
Tasks
See Table 17
7.6.4
166
Criteria
Action
Product readiness Completed construction, peer

reviews and unit testing.
Review of Test Plan and Scripts

Quality Test Plans and Scripts Test plan and scripts
built against BRD, functional and technical design.
Review the Project Plan

Review / walkthrough the code and/or Infrastructure
changes
Configuration Management (s) Ensure appropriate

approvals exist for migrating code into the testing
environment.
Validate Construction Information Security Assessment
7.7.3
Review the unit test results
Tasks
See Table 18
7.6.5
7.7.4
Deliverable
Dev
Inf
Test Plans, Scripts and Test results
Validate that all deliverables for previous phases are

available.
Construction
Questionnaire
Information
Security
Ensure Test Results are documented in the system of

record.
Code reviews / Infrastructure reviews
Configuration Management
Testing
NA
Verify Information Security Assessment

Record -

Validate Operational
applicable.
R
Handoff
Documentation,
if
Validate Configuration
available
Management
Records
are
Ensure Sponsors Approval to Implement.
7.7
Validation Phase
Ensure Business Operational Readiness.
7.7.1
Purpose
Validation is the confirmation by examination and

provision of objective evidence that project specifications
have been met and will fulfill the business requirements.
Project implementation can occur only after successful
completion of the acceptance test and there is confidence
that the system meets the business requirements. Focus
of this phase will be to ensure system meets the
specifications, end user acceptance of the product and
appropriate regression testing to ensure system
sustainability in a production environment.
ETVX
7.7.2
Entry Criteria
7.7.5
Deliverable
Dev
Inf
Test Results
Sponsors Approval to Implement
Production
Record -

Validation
Assessment
Information
Security
7.8
7.9.3
7.8.1
Tasks
See Table 20
Purpose
This phase represents the actual implementation of the

product into the production environment upon the
successful completion of testing. These criteria are
specific to data center groups and must be verified with
the specific business units.
7.9.4
Action
Ensure production defects are prioritized, fixed and/or
transferred to production support.
Ensure Lessons Learned is summarized.
ETVX
7.8.2
167
Entry Criteria
Validate all documentation is available and project is

closed out.
Criteria
7.8.3
7.9.5
Tasks
See Table 19
7.8.4
Action
has
occurred
per
Deliverable
Configuration Management Record(s) Production
Dev
Inf
R
Post-Implementation Phase
7.9.1
Purpose
The purpose of the Post-Implementation phase is to

assess the effectiveness of the implemented system,
manage any defects and ensure that the systems are retested based on defect related coding changes. The phase
is also an opportunity to conduct lessons learned before
project closure. Lessons Learned are to be shared with
project stakeholders to improve processes as appropriate
ETVX
7.9.2
Dev
Inf
Production Defect Logs
NA
Summarized Lessons Learned
8. Appendix
8.1
7.9
Deliverable
Validate production deployment

Configuration Management details
7.8.5
Exit Criteria
Entry Criteria
Criteria
Implementation into a Production environment
Glossary
Architecture documentation: It is a special breed of

design document. In a way, architecture documents are
third derivative from the code (design document being
second derivative, and code documents being first).
Banking and Financial Services (BFS): Banking and
Financial Services (also known as BFS) is an industry
name. This term is commonly used by IT/ITES/BPO
companies to refer to the services they offer to
companies in these domains. Banking may include core
banking, retail, private, corporate, investment, cards and
the like. Financial Services may include stock-broking,
payment gateways, mutual funds etc. A lot of data
processing, application testing and software development
activities are outsourced to companies that specialize in
this domain.
Change management: It is a structured approach to
shifting/transitioning
individuals,
teams,
and
organizations from a current state to a desired future
state. It is an organizational process aimed at helping
employees to accept and embrace changes in their current
business environment. In project management, change
management refers to a project management process
where changes to a project are formally introduced and
approved
Line of business (LOB): It is a general term which often

refers to a set of one or more highly related products
which service a particular customer transaction or
business need.
Breadth: The extent to which the task will impact
business processes, customers, functional team resources,
lines of business and the requirements surrounding
sponsorship.
Business Requirement Document: In IT projects
business requirements is often a precursor to designing
and building a new business application/system, or
changing an existing one, and often sets the context for
business process modeling, requirements analysis. The
business requirements may encompass pre-requisites for
both functional requirements and non-functional
requirements that are desirable in the new or to be
changed system.
Contract and Outsourcing: Contract is a legally
enforceable agreement between two or more parties with
mutual obligations, which may or may not have elements
in writing. Outsourcing or sub-servicing often refers to
the process of contracting to a third-party.
Complexity: The level of intricacy of the proposed task
relating to design and testing requirements.
Change Control Board: In software development, a
Change Control Board (CCB) or Software Change
Control Board (SCCB) is a committee that makes
decisions regarding whether or not proposed changes to a
software project should be implemented.
Financial Accounting Standards: It is a private, notfor-profit organization whose primary purpose is to
develop generally accepted accounting principles in the
public's interest.
Information security: It means protecting information
and information systems from unauthorized access, use,
disclosure, disruption, modification, perusal, inspection,
recording or destruction.
analyze and represent the tasks involved in completing a

given project.
Phase Gate: A hard stop where the project can not
enter the next phase of the lifecycle without having
completed all activities/deliverables of the phases prior to
that Phase Gate.
Phase Review: A soft stop where a project can
continue into the next phases activities without fully
completing the requirements of the last phase. However,
the last phase will remain incomplete until all
activities/deliverables are completed.
Problem Management: It is the process responsible for
managing the lifecycle of all problems. The primary
objectives of Problem Management are to prevent
problems and resulting incidents from happening, to
eliminate recurring incidents and to minimize the impact
of incidents that cannot be prevented.
Project management: It is the discipline of planning,
organizing, securing, and managing resources to achieve
specific goals
Resource Management: In organizational studies,
resource management is the efficient and effective
deployment of an organization's resources when they are
needed. Such resources may include financial resources,
inventory, human skills, production resources, or
information technology (IT).
Software Management: The management of software
systems borrows heavily from project management, but
there are nuances encountered in software not seen in
other management disciplines.
Template: A document or file having a preset format,
used as a starting point for a particular application so that
the format does not have to be recreated each time it is
used.
8.2
Acronym
Scale: Consists of effort and cost and is implemented at

LOB level due to vast differences in capacity but must
have each of the following size categories defined; small,
medium, large, and extra large.
Acronym
BAU
BRD
CCB
CEO
CEP
BFS ISS
Technology: A holistic view of the technologies to be

implemented or modified and the associated impacts and
risks they give to the environment.
BFS IT MP
PERT: The Program (or Project) Evaluation and Review

Technique, commonly abbreviated PERT, is a statistical
tool, used in project management, that is designed to
168
ETVX
FAS
IDLC
ISQ
ISR
LOB
Definition
Business As Usual
Business Requirement Document
Change Control Board
Chief Executive Officer
Capital Expenditure Policy
Banking & Financial Services Information
Security Standards
Technology Management Policy
Entry Tasks Validation and Verification eXit
Financial Accounting Standards
Infrastructure Delivery Lifecycle
Information Security Review
Line of Business
BFS IT

Technology
Non Billable Type
Process Control Manual
Program Evaluation Review Technique
Project Manager
Risk Control and Self Assessment
Resource Manager / Technical Manager
Solution Delivery Lifecycle
System Integration Testing
Statement of Work
Software Quality Assurance
Software Quality Manager
User Acceptance Testing
NBT
PCM
PERT
PM
RCSA
RM
SDLC
SIT
SOW
SQA
SQM
UAT
8.3
Acknowledgement:
We are grateful to Larsen and Toubro Infotech India,

Madurai Kamaraj University-India, Citigroup-USA and
Nordea AB-Sweden for this effort to get realized.
References
169
ANSI/PMI 99-001-2008. Also available for download by PMI members

at: www.pmi.org
[2] PMP Exam Prep, Sixth Edition - Rita Mulcahy PMP 2009
[3] Software engineering: a practitioners approach / Roger S.
Pressman.5th ed. (McGraw-Hill series in computer science) 2001
[4] Adelson, B., and Soloway, E. The role of domain experience in
software design. IEEE Trans. Softw. Eng. 11, 11 {Nov. 1985), 13511360.
[5] Curtis, B. et al., "A Field Study of the Software Design Process for
Large Systems," IEEE Trans. Software Engineering, vol. SE-31, no. 11,
November 1988
[6] Software Maintenance - As Part of the Software Life Cycle,
Comp180: Software Engineering. Prof. Stafford, Department of
Computer Science, Tufts University. . http://hepguru.com/
maintenance/Final_121603_v6.pdf
[7]
SOFTWARE
DEVELOPMENT
PROGRAM
CHARACTERISTICS. Pekka Forselius http://www.compaid.com/
caiinternet/ezine/forselius-characteristics.pdf
[8] The global and independent source of data and analysis for the IT
industry.
Also available for download by members at:
http://www.isbsg.org/
http://www.isbsg.org/isbsgnew.nsf/webpages/~GBL~Development%20
&%20Enhancement
[9] Finnish Software Measurement Association http://www.fisma.fi/ inenglish/methods/
[10]
http://www.softwarecertifications.org/cboks/cmsq/
skillcategories.htm. Also available for download by Certified Manager
for Software Quality members in QAI Global Institute.
[1] A Guide to the Project Management - Body of Knowledge

(PMBOK Guide) Fourth Edition. An American National Standard
Project Management Life Cycle

(Project Management Institutes Standard Model)
Initiation
Authorization
SOW
Planning
Schedule
Resource Mgt Team
Roles/Responsibilities
Communications
Operational
Readiness
Information
Engineering Life Cycle
identified
Monitor and
Control
Execution
Risk Management
Progress Management
Management of Change
Management Reviews
Close
Post-Implementation
Archival
Figure 1
Table 1
Estimation Type
Variance
E0
Order of magnitude
-25/+50%
E1
Budget
-10% / +25%
E2
Definitive
-5% / +10%
Phase
Initiation
Based on
Analogy / Comparison parametric
(cost factors)
Expert Judgment
Definition

(cost factors)
Expert Judgment
Design

Expert Judgment
Supplier
170
Program
Non-Project
Project
Maintenance
Minor
Major
Small
Small / Medium (Simple)
Medium / Large
Multiple Projects
Single / few, simple process(es)
Single / few simple process(es)
Multiple processes, multidisciplinary
Multiple processes, multidisciplinary, multiple sponsors,

multi-project, multiple LOB
impacts
Low
Low / Medium
Medium / High
High
Well known / mature
Well known / mature, few

customer touch points, few
system interfaces
New technology, multipletechnologies / platforms,

languages, medium to high
technology requirements with
medium to high interfaces with
other systems / services /
products
Re-engineering, re-architecting,
multiple conversions
Strategic
Importance
Operational
Renewal
Repositioning - New Product

Legislative Product / Market
Expansion
Capital Expansion Repositioning

Executive Sponsorship
Phase Gates
Phase Gate approval after

Validation
Phase Gate approvals after

Definition and Validation
Phase Gate approvals after

Definition and Validation
3 Phase Gate approvals, 8

Phase Life cycle
Bi-Weekly status reports

(frequency increases if needed
Weekly status reports; Release

Oversight
Weekly status reports; Release

Oversight
Steering Committee and/or

Guidance Management Team
Release
Structure*
As planned & published by LOB

(e.g., weekly, monthly, quarterly)

(e.g., weekly, monthly, quarterly)

(e.g., monthly, quarterly)

(e.g., monthly, quarterly)
Examples
Table change, Report change,

Network changes, life cycle
could be used to support break
fix changes
New communications, simple

Infrastructure projects, portfolio
re-pricing
New products, new features,

changes to formulas/executable
system functionality.
Acquisitions or mergers, New

business venture, New
technology platform, Create new
assets
Scale
Breadth
Complexity
Technology
Governance
& Oversight
Figure 2: Investment Categories
Figure 3
Table 2
Infrastructure
Initiation
Approved work request form

(LOB defined)
Minimum requirements for a work request: Business

Sponsor, Executive Summary & Objectives, Type
(Regulatory, Revenue (incremental or protection),
R
Operational Efficiencies, Business Processes impacted.
Business requirements may be incorporated into this
request form.
Prioritized Ranking of Work

Request
Phase Requirements (Required

for Exit and not presented in
sequential order)
Implementation
Prioritization process for Maintenance
Each LOB must have some form of Technology

C Assessment objective being understanding technology
impacts, infrastructure, etc.
R Minimum of E0 estimate is required
Preliminary Information Security

Questionnaire (ISQ)
Requests affecting security policy or standards must

perform an information security risk assessment. Each
C
LOB must have set of preliminary questions to ensure the
Information security of the effort.
Specification
Construction Activities
Code Review / Infrastructure

Review
Record - Testing
Unit Test Results
Validation Information Security

Questionnaire
UAT Test Results
Approval to implement
Record - Production
Construction
Validation
Additional Criteria / Notes

Table Key: R - Required,
C - Comply as necessary,
NA - Not Applicable
Development
Phase
Communicate final status to

Requestor
Close Out Work Request
Technical specification to capture definition of request and

solution approach dependent upon type of request
some maintenance requests can be one-time jobs, table

R updates and no code is written; others might include code
development
Code Review required on all software development
C efforts; Infrastructure Review required on infrastructure
efforts
Obtain Configuration managements records for QA/ UAT
NA
environments
Based on the type of request, multiple groups
C (Development, Infrastructure and QA) may perform tests
and provide results
This is completed based on security impact responses
from the Preliminary ISQ. Each LOB must have set of
C
questions to ensure the Information security of the effort at
this Validation level.
Based on the type of request, multiple groups
C (Development, Infrastructure and QA) may conduct
independent tests.
R Authorization to implement the request, defined by LOB.
Configuration Management to implement in production
R must be provided. Date to Production milestone task
indicates date to rollout
R Provide notification to Requestor/project stakeholders
R Perform closeout activities
171
172
Table 3
Activity
Purpose
Dev
Inf
Authorize Work
Request
Ensure that:
Requirement for change has been clearly specified.
The operational implication(s) is provided, including a realistic

understanding of the cost and risk of not acting on the request.
The request has been submitted from an authorized source.
Categorize/Prioritize
Work Request
Evaluate the request based on the critical nature of both the change and the
system to which the change is requested.
The priority is based on LOB factors and may include high-medium-low or

other designations.
Factors to be considered include the potential impact of not responding to
the request, for example:
Loss of income or assets
Disruption of customer service
Regulatory penalties
Potential of litigation with large damages
Negative publicity or loss of reputation
System integrity
Reduced operational efficiency

Note: Based on effort each LOB will determine if the Work Request is
applicable to the Maintenance Lifecycle or to another Lifecycle.
Table 4
Activity
Purpose
Technology
Assessment
Review and assess the technology and/or infrastructure impact
Dev
Inf
Create Initiation
Estimate (E0)
At a minimum, an E0 Estimate is required
Conduct Preliminary
Information Security
Assessment
Complete Preliminary Information Security Questionnaire (ISQ). Ensures

information security risks are evaluated, addressed and Information Security
is engaged to begin review. Must be completed if request includes application
development
Develop
Specifications
The specifications are used to document the overall solution design. It should
provide details for and/or consider the following:
Requirements/Analysis
Description of each function
What method(s) will be used
Performance criteria and error handling
How the system should operate
Layout of screen formats
Layout of generated reports or file extract
Conduct
Construction
Activities
Perform necessary activities to satisfy changes documented in the work

request. which may include the following: Modify infrastructure and/or compile
code
Conduct infrastructure and/or code review(s)
Create/select unit test cases
Conduct Unit
Testing
Tests may be carried out by the individual who made the modification(s) or by
other resources to ensure the modification(s) is consistent with the
specifications. Any discovered defects are addressed and re-tested.
Build Configuration
Management
Records
Follow the appropriate Configuration Management protocol and establish

Configuration Management records for the anticipated deployment into the
testing environment.
NA
173
Table 5
Activity
Purpose
Dev
Inf
Execute System Test

(Conditional)
Prepare a System Test Plan and System Test Script(s). Execute the
test(s) following the Test Script(s) and maintain a record of the results.
Make modifications to the work products to correct errors identified in

testing. Repeat tests which have failed in accordance with the System
Test Plan.
Execute Acceptance Test
(Conditional)
Prepare an Acceptance Test Plan and Acceptance Test Script(s).

Execute the test(s) following the Test Script(s) and maintain a record of
the results.
Make modifications to the work products to correct errors identified in
testing. Repeat tests which have failed in accordance with the
Acceptance Test Plan.
Conduct Validation
Assessment
Complete Validation Information Security Questionnaire (ISQ). Ensures

information security risks are evaluated, addressed and Information
Security is engaged
Finalize Configuration
Management Records
Follow the appropriate Configuration Management protocol and

establish Configuration Management records for the anticipated
deployment into the production environment.
Obtain approvals
Obtain approval to implement. Process configuration management

records and secures install approvals
Table 6
Activity
Purpose
Dev
Inf
Implement Changes
Transfer work products to the production environment and if necessary

update appropriate production schedules.
Validate Intended Result
Monitor usage and performance of the work products. Ensure the work
products are fully functional and provide results as intended in the
production environment.
Closeout Work Request
Date and mark the Work Request as complete. Ensure all logs are
closed and supporting documentation is stored in the specified
maintenance knowledge base.
174
Definition
Initiation
Construction
Validation

Table Key: R - Required, C - Comply as necessary,
NA - Not Applicable
Feasibility Assessment
Minimum requirements for a project request: Business Sponsor,

Executive Summary & Objectives, Type (Regulatory, Revenue
R (incremental or protection)), Operational Efficiencies, Business
Processes impacted. Business requirements may be incorporated
into this request form.
C
Prioritized Ranking of Work Request

Approved Business Requirements and
Signoff.
Export Compliance Determination
Each LOB must have some form of Minor Technology

R Assessment / Checklist objective being understanding technology
impacts, infrastructure, new technology, build vs. buy, etc.
R
Definition Estimate (E1)
Maintained Scope Change

Management, Risk & Issues
Approved Functional Specifications

and Signoff
Preliminary Information Security

Questionnaire (ISQ)
Requests affecting security policy or standards must perform an

information security risk assessment.
Technical design related to the application and system to be

created.
Approved work request form (LOB

defined)
Technical Design

Unit/Systems Integration/QA Test
Plans
Construction Information Security
Questionnaire
Code Review / Infrastructure Review

Configuration Management - Testing
R
C
Validation Information Security

Questionnaire
Test Results

Document
Implementatio
n
Infrastructure
Phase Requirements (Required for

Exit and not presented in sequential
order)
Development
Phase
Table 7
Install Configuration to Production
R
C
NA .
C Design estimate approval from business stakeholders

Based on the type of request, multiple groups (Development,
R
Infrastructure and QA) may develop test plans
This must be completed based on security impact responses from
C
the Preliminary ISQ and/or scope change.
Code Review required on all software development efforts;
C
Infrastructure Review required on infrastructure efforts
R
Based on the nature and complexity of the minor work, changes,
C
risks, and issues may not occur.
N/A Obtain Configuration managements for QA/UAT environments
This must be completed based on security impact responses from
C the Preliminary ISQ and/or results of the /Construction ISQ and/or
scope change.
R
Infrastructure and QA) may conduct independent tests.
C
Post-Implementation Defect
Fix/Test/Implement
Summarize Lessons Learned


Configuration management to implement in production must be

R provided.
Monitoring for a set period of time to identify defects and address
C
them in a timely way to minimize customer impact
Based on complexity of project and size as a secondary indicator,
R the project manager and project team could determine depth of
review needed (high level or detailed).
175
Table 8
Activity
Create
Scope
Objectives
and
Purpose
Dev
Inf
Defines the reason for the project, objectives and scope of the project.
Recommended items to be included in the Scope
- Business Case
- Benefits
- Problem Statement
- Goal Statement
- High-level Project Statement of Scope
- Project Assumptions and Limitations
Perform
Assessment
Feasibility
Initial review to determine feasibility of the request. Scope should

include determining if the risks that will be taken while executing the
project are within acceptable tolerance levels and can be appropriately
mitigated to ensure project success.
Perform prioritization and

ranking
Identify how project aligns with business strategy and goals and assign
priority and ranking accordingly
Project Planning
E0 creation, resource assignment, scheduling
Table 9
Activity
Purpose
Dev
Inf
Analyze, state, and agree to

the finalized business
requirements document and
conduct peer review
To elicit and reach consensus on the business problem and the

requirements that must be met to solve the problem.
Obtain Approval on the BRD
Formal approval and sign-off ensures a common goal and expectations

and sets boundaries for the project.
Conduct Technology
Assessment
The technology assessment identifies any technology risks and

addresses feasibility.
Complete Export
Compliance Assessment
The first assessment of whether additional Export control steps will be

needed.
Perform project lifecycle

classification
Based on risk criteria, determine project lifecycle assignment
Create and obtain approval

on E1 Estimate
Conduct Preliminary
Assessment
Ensures information security risks are evaluated, addressed and

Information Security is engaged to begin review.
Maintain Schedule and

Status
Maintain Scope Change
Management, Risks and
Issues, Lessons Learned
Project processes that are iterative throughout the project lifecycle

should be managed and maintained. All related project processes and
supporting documentation are inclusive within this activity (i.e.
Communication Management, Risk Management, Issue Management,
Change Management, Human Resource Management and Cost
Management).
176
Table 10
Activity
Purpose
Dev
Inf
Create the Functional

Specification that addresses
the business problem
Functional response to the business requirements.
NA
Develop Technical Design

and if applicable develop
prototype
Translate functional specification and BRD to a detailed technical

design, which includes components that can be used for
development and infrastructure tasks.
Create and obtain approval on

Technical Design Estimate
(E2)
Revise estimates based on technical design and update project

schedules.
Create System Test Plans
Create system test plans
NA
Finalize Unit Testing / System

Integration Testing (SIT) /
Quality Assurance (QA) Test
Plan and scripts
Validate test plans / scripts based on the understanding of detailed

technical design.
Validate Construction
Assessment
Validate information security risk impacts that are covered after

code development.
Perform Code Reviews and/or

Infrastructure Reviews
Conduct peer review of the code and/or infrastructure changes

prior to quality testing tasks beginning.
Create Configuration
Management Records
Enter details on configuration management records to migrate

code into test environments
NA
Test scripts will be used for validation for System Integration

Testing (SIT) and Quality Assurance (QA).
Maintain Schedule and Status


should be managed and maintained. All related project processes
and supporting documentation are inclusive within this activity (i.e.
Communication Management, Risk Management, Issue
Management, Change Management, Human Resource
Management and Cost Management).
Table 12
Activity
Purpose
Dev
Inf
Implement Changes
Transfer work products to the production environment and if necessary

update appropriate production schedules.
Validate Intended Result
Monitor usage and performance of the work products. Ensure the work
products are fully functional and provide results as intended in the
production environment.
Summarize
Learned
Compile Lessons Learned through the full project lifecycle to determine

areas of improvement and document best practices for future. Share with
project team.
Complete the project; ensure all documentation is stored for audit

purposes and release human resources.
Lessons
Initiation
Start
177
Definition
Construction
Validation
Implementation
Define
Requirements
(optional)
Define Technical
Design
(Conditional)
Execute Tests:
System / UAT /
Regression
Implement
Changes
Size, Plan &

Schedule
Define Test Plans

& Scripts
Define
Implementation
Plan
Validate Changes
& Processing
Prioritize Work &

Target Release
Develop /
Construct & Unit
Test
Approve to
Implement
Transition to BAU /
close-out Project
Authorized Work
Request
Categorize Work
Request
YIELD
ETVX
ETVX
ETVX
End
Build Configuration
Mgmt Records
YIELD
ETVX
Figure 4
Initiation
Definition
Design
Construction
Validation
Implementation
PostImplementation
Define
Requirements
Define Technical
Requirements
Develop /
Construct & Unit
Test
Execute Tests:
System / UAT /
Regression
Implement
Changes
Conduct Lessons
Learned
Size, Plan & Draft

Schedule
Re-Size, ReSchedule, Target

Release
Build Configuration
Mgmt Records
Define
Implementation &
COB Plans
Validate Changes
& Processing
Transition to BAU /
close-out Project
Prioritize Work &

Soft Commitment
Define Test Plans

& Scripts
ETVX
ETVX
Start
Authorized Work
Request
Size & Categorize

Work Request
YIELD
YIELD
ETVX
YIELD
ETVX
ETVX
Approve to
Implement
YIELD
ETVX
Figure 5
End
178
Table 11
Activity
Purpose
Dev
Inf
Execute System Test by

Quality Assurance Team
Execute tests according to the test plans, scripts and specifications.
Document and report on test results and defect logs. Validates

functionality against specifications.
Initiate corrective actions
on defects
Ensure defects are addressed before implementation.
Execute End User

Acceptance Test (UAT)
Execute tests according to the test plans, scripts and specifications.
NA
Communicate defects to IT for resolution.

Prioritize defect and determine workarounds on low priority defects
Validate Information
Security Assessment
Complete Validation Information Security Questionnaire
Sponsors Approval to
Implement
Obtain project sponsors approval to implement.
Conduct Technology
Operational Handoff
Provide production support personnel with operational procedures for

Technology support staff.
Build Configuration
Management Records
Follow the appropriate Configuration Management protocol and

establish Configuration Management records for the anticipated
deployment into the production environment.
Maintain Schedule and

Status

should be managed and maintained. All related project processes
and supporting documentation are inclusive within this activity (i.e.
Management, Change Management, Human Resource Management
and Cost Management).
Infrastructure
Development
Phase Requirements (required for Exit and not

presented in sequential order)

Table Key: R - Required, C - Comply as necessary,
NA - Not Applicable
Feasibility Assessment
Minimum requirements for a project request: Business

Sponsor, Executive Summary & Objectives, Business Benefit
(quantified), Type (Regulatory, Revenue (incremental or
R
protection), Operational Efficiencies,
Risk Assessment,
Business Processes impacted, financials (E0 and NBT- NonBillable Time)
C
Prioritized Ranking of Work Request
Approved work request form including financial

justification (SOW) (LOB defined)
i
n
i
t
Initiation
Phase
Table 13
Approved Business Requirements and Signoff
Export Compliance Determination
Each LOB must have some form of Technology Review

R objective being understanding technology impacts,
infrastructure, new technology, build vs. buy, etc.
R Required on all requests
Definition Estimate (E1)

Maintained Scope Change Management, Risk &
Issues
Approved Functional Specifications and Signoff
NA
Preliminary Information Security Questionnaire (ISQ)
Implementa
tion
Validation
Construction
Design
Technical Design
PostImpleme
ntation
179
All requests affecting application development must be

reviewed for information security risk assessment.
. Technical design of the application or system must be
R
created.
R Design estimate approval from business stakeholders.
This must be completed based on security impact responses
C
from the Preliminary ISQ.
R
Design Information Security Questionnaire
Approved Capital Expenditure (CEP)
C CEP Policy will be maintained by the BFS organization.

Issues
Unit /Systems Integration/QA Test Plans
Construction Information Security Assessment
Code Review /Infrastructure Review

Issues
Configuration Management - Testing
NA
Validation Information Security Questionnaire
Test Results
Technology Operational Handoff Document

Maintained Schedule, Status, Scope Change
Obtain configuration management records for QA/UAT

environments
This must be completed based on security impact responses
C from the Preliminary ISQ and/or results of the Construction
ISQ and/or scope change.
R
Infrastructure and QA) may conduct independent tests.
C
Configuration Management - Production
Configuration Management records to implement in

R production must be provided.
Install Configuration to Production
Configuration management to implement in production must

R be provided.
Implementation Defect Fix/Test/Implement
Post-Implementation Defect Fix/Test/Implement
Summarize Lessons Learned

Infrastructure and QA) may develop test plans.
This is completed based on security impact responses from

the Preliminary/Design ISQ and/or scope change.
Code Review on all software development efforts;
C
Infrastructure Review on infrastructure efforts
C
Monitoring for a set period of time to identify defects and

address them in a timely way to minimize customer impact.

Based on complexity of project and size as a secondary
R indicator, the project manager and project team could
determine depth of review needed (high level or detailed).
C
180
Table 14
Criteria
Business Need - A business problem or initiative that requires project management methodology.
Business case, alignment with business goals and strategy, problem statement, business risk analysis, cross functional impacts,
and priority criteria.
Tasks Activity
Purpose
Dev
Inf
Create Scope and

Objectives
Defines the reason for the project, objectives and scope of the project.
Recommended items to be included in the Scope:

- Business Case
- Benefits
- Problem Statement
- Goal Statement
- High-level Project Statement of Scope
- Project Assumptions and Limitations
Perform Initial Cost

Benefit Analysis
Initial review to determine if the benefits to be obtained from the project will outweigh the
costs incurred from it or by not doing it. E0 level effort/cost estimate.
Perform Feasibility
Assessment
Initial review to determine feasibility of the request. Scope should include determining if
the risks that will be taken while executing the project are within acceptable tolerance
levels and can be appropriately mitigated to ensure project success.
Perform prioritization
and ranking
Identify how project aligns with business strategy and goals and assign priority and
ranking accordingly.
Project Planning
E0 creation, Resource assignment, scheduling
Table 15
Activity
Purpose
Dev
Inf
Analyze, state, and agree to the

finalized business requirements
document and conduct peer review
To elicit and reach consensus on the business problem and the

requirements that must be met to solve the problem.
Obtain Business Approval on the

BRD
Formal approval and sign-off ensures a common goal and

expectations and sets boundaries for the project.
Conduct Technology Assessment
The technology assessment identifies any technology risks and

addresses feasibility.
Complete Export Compliance

Assessment
The first assessment of whether additional Export control steps

will be needed.
Create and Obtain approval on E1

estimations.
Formal approval and sign-off ensures a common understanding

across the project team.
NA
Perform project lifecycle

classification
Based on risk criteria, determine project lifecycle assignment
Conduct Preliminary Information

Security Assessment.
Complete Preliminary Information Security Questionnaire (ISQ).

Ensures information security risks are evaluated, addressed and
Information Security is engaged to begin review.
Update financials and work on CEP,

if required.
Ensures that the detail tasks for the next phase are planned and
resourced.
181
Activity
Purpose
Dev
Inf
Target Release Date Assignment
Confirm target release date based on E1 estimate and updated

project plan.
Project processes that are iterative throughout the project

lifecycle should be managed and maintained.

Management, Risks and Issues
Lessons Learned
All related project processes and supporting documentation are

inclusive within this activity (i.e. Communication Management,
Risk Management, Issue Management, Change Management,
Human Resource Management and Cost Management).
Table 16
Activity
Purpose
Dev
Inf
Create the Functional Specification that

addresses the business problem.
Functional response to the business requirements.
NA
Develop Technical Design and, if

applicable, develop prototype
Translate functional specification and BRD to a detailed

technical design which includes components that can be
used for development and infrastructure tasks.
Create System Test Plans
Create system test plans.
NA
Create and obtain approval on

Technical Design Estimate (E2)
Revise estimates based on technical design and update

project schedules.
Update project financials CEP

approval, if required
Ensure BFS IT standards for capitalization expenditure

proposal are adhered to.
Perform Design Information Security

Assessment
Perform Design Information Security Questionnaire.

Identify information security impacts after Technical
Design is completed.

Maintain Scope Change Management,

Risks and Issues Lessons Learned
All
related
project
processes
and
supporting
documentation are inclusive within this activity (i.e.
Management, Change Management, Human Resource
Management and Cost Management).
Table 19
Activity
Purpose
Dev
Inf
Implement Changes
Transfer work products to the production environment and, if

necessary, update appropriate production schedules.
Implementation Defects, Fixed

182
Table 17
Activity
Purpose
Dev
Inf
Finalize Unit Testing, System

Integration Testing (SIT) /
Quality Assurance (QA) Test
Plan and define test scripts.
Validate test plans based on the understanding of detailed

technical design.
Validate Construction
Assessment.
Complete Construction Information Security Assessment.

Validate information security risk impacts that are covered after
code development.
Create Code Review or

Infrastructure Review Checklist
Create Code Review Checklist and conduct peer review of the

code prior to quality testing tasks beginning.
Define test scripts that will be used for validation for System
Integration Testing (SIT) and Quality Assurance (QA).
Create Infrastructure Review Checklist and conduct appropriate

validation.
Management Record
Obtain details on configuration management records submitted

to migrate code into test environments
NA


Management, Risks and Issues
Lessons Learned

Table 20
Activity
Purpose
Dev
Inf
Production Defect
Management
Identify production defects and address those through either

changes to the application or alternate work-around.
NA
Summarized Lessons
Learned
Compile Lessons Learned through the full project lifecycle to

determine areas of improvement and document best practices for
future. Share with project team.
Complete the project, ensure all documentation is stored for audit

purposes and release human resources.
Table 18
Activity
Purpose
Dev
Inf
Execute System Test by

Quality Assurance Team
Execute tests according to the test plans, scripts and

specifications.
Document and report on test results and defect logs. Validates

functionality against specifications.
183
Activity
Purpose
Dev
Inf
Initiate corrective actions on

defects
Ensure defects are addressed before implementation.
Execute End User Acceptance

Test (UAT)
Execute tests according to the test plans, scripts and

specifications.
NA
Communicate defects to IT for resolution.

Prioritize defect and determine workarounds on low priority
defects.
Perform Validation Information
Security Assessment
Complete Validation Information Security Questionnaire
Sponsors Approval to
Implement
Obtain project sponsors approval to implement.
Conduct Technology
Operational Handoff
Provide production support personnel with operational

procedures for Technology support staff.
Ensure Business Operational

Readiness
Ensure business readiness training, business process,

procedural updates.
Management documentation.
Obtain details on configuration management records submitted

to migrate code into production environments.


Issues Lessons Learned


Project Life Cycle

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Life Cycle

Uploaded by

Copyright:

Available Formats

International Journal of Wisdom Based Computing, Vol.

1 (3), December 2011

Software Development Life Cycle Standards for

ABSTRACT: In general we have Software Development Life

participate in the delivery of technology projects or

1.4 Out of Scope

LOB (Line of Business) level implementation processes

Prioritization model ensures project alignment

Project Sponsors are engaged to provide direction,

Quality Assurance practices will support the

The Banking and Financial Services Information

International Journal of Wisdom Based Computing, Vol. 1 (3), December 2011

Management. Many of these policies guide activities

BFS IT Lifecycle Standard

The BFS IT Lifecycle Standard is developed and

LOB Process Control Manuals (PCM)

The LOB Process Control Manuals outline a progression

2.2 Management Approach

2.3 Project Management Process

Initiation is a phase where the requestor identifies a need

Planning provides a framework for identifying,

This involves performing and coordinating various

Monitor and Control

This segment of project management involves measuring

This part of project management involves the formal

2.4 Phase Structure

International Journal of Wisdom Based Computing, Vol. 1 (3), December 2011

Entry Criteria: A checklist of conditions that must be

Phase Review: A soft stop is a point where a

Monitoring and Controlling

Tasks: A set of tasks that need to be carried out.

Monitoring and controlling is done over all major project

Verification and Validation: A list of validation tasks to

Exit Criteria: A checklist of conditions that must be

The business initiates all types of work requests utilizing

Phase Exits are critical decision points in the Lifecycle of

Core Operating Activities

The phase exit of the ETVX model can be a Phase

Phase Gate: A hard stop checkpoints in the BFS IT

Strategic - IT Investment that enables LOBs to

Maintenance - Repetitive work that modifies or

International Journal of Wisdom Based Computing, Vol. 1 (3), December 2011

This Standards document will focus on defining Project

Cognos reporting and data elements for existing

Based upon effort, cost and/or risk categorization, a

Minor Project Lifecycle

The Minor Project Lifecycle is used to manage changes

Major Project Lifecycle

The Major Project Lifecycle is used to manage new

International Journal of Wisdom Based Computing, Vol. 1 (3), December 2011

Discuss and understand the division level

Communication Planning: Strategic communication

Consensus on Organizations Priorities:

Organization will align to support Strategic Initiatives.

Resources assigned to support Strategic Initiatives

4.2 Communication Plan

Information Distribution: Information distribution is part

4.3 Cost Management

International Journal of Wisdom Based Computing, Vol. 1 (3), December 2011

Sizing and Effort Estimation

The purpose of Sizing and Effort Estimation is to assess

Compare the estimate with established standards

The cycle is iterative, taking more depth as more

Sizing and Effort Estimation model must be utilized to