Generic Billing Solution Proposal

<Client>
Generic Billing Solution Proposal
Date: <Date>
Confidentiality Statement
This <document title> along with all attachments hereto shall be considered <company>’s
Proprietary/Confidential Information
gantthead.com Generic Billing Solution Proposal
Contents
1 Introduction/Background.........................................................................................4
2 Objectives...............................................................................................................5
Overall Objective................................................................................................5
Business............................................................................................................5
Technical............................................................................................................6
Program.............................................................................................................6
3 Scope......................................................................................................................7
Solution Scope...................................................................................................7
Functional Scope...............................................................................................9
Project Scope.....................................................................................................9
Drivers..............................................................................................................11
Overview of Approach......................................................................................12
Phase 1 – Program Start-up............................................................................13
Phase 2 – Program Baseline and Environment Set-up...................................17
Phase 3 – Business Functionality Release (Delivery).....................................19
Phase 4 - Deployment.....................................................................................21
Phase 5 – Product Management.....................................................................23
4 Deliverables..........................................................................................................26
Main Deliverables............................................................................................26
Deliverable Description....................................................................................26
Deliverables by Service Parts..........................................................................27
Other Deliverables...........................................................................................28
5 Methods & Tools Used..........................................................................................29
Methodology....................................................................................................29
Purpose of Methods.........................................................................................29
Main Phases/Activities.....................................................................................29
Tools Used.......................................................................................................32
6 Organization.........................................................................................................36
Introduction......................................................................................................36
Deployment......................................................................................................37
Phase 1 - Program Start-up Organization.......................................................38
Phase 2 - Program baseline and environment set-up.....................................39
Phase 3 – Business Functionality Releases (Delivery)...................................42
Phase 4 - Deployment.....................................................................................44
7 Progress Control & Monitoring.............................................................................46
Program Steering and Control.........................................................................46
Integrated view of Application Development infrastructure.............................48
8 Change Management & Configuration Management...........................................49
©2007 gantthead.com 2
Change Management Procedure....................................................................49

Configuration and Change Management.........................................................53
9 Integration.............................................................................................................56
10 Risks & Risk Management................................................................................58
11 <Company> Credentials....................................................................................62
Experience.......................................................................................................62
Specification and Design.................................................................................63
Build & Deployment.........................................................................................64
Post-Deployment Warranty Support Services.................................................64
Product Management......................................................................................64
Introduction/Background
<Briefly describe the project, the mission statement, and the goals the project is to
address.>
By <When>, <Company> agreed to deliver the following to <Client>:
 <Deliverable>
 <Deliverable>
It was intended that the content of the above deliverables would contribute to Client’s
decision to complete further phases.
The deliverables described above were developed with a number of <Client> staff <How
and When>.
State <Which> existing models were used as ‘straw men’ to assist in shaping ideas,
clarify and determine requirements, and aid productivity.
The high-level analysis work completed during this phase has been captured and will
contribute directly to the next phase of the project. This allows a quick start to the main
phase of the project as described in the approach section below.
In terms of the prototype, the following key requirements have been addressed: (These
are samples. Your requirements might be different!)
 Scalability – The prototype’s architecture is designed to operate on multiple

databases and/or database partitions. Increase in customer base or additional
products can easily be accommodated without disrupting operations. During day-
to-day batch runs, reallocation of resources between partitions can be managed
through batch monitoring processes.
 Multi-Product Capability – The prototype design supports the addition of new

products. Existing customers may avail of these new products offering through
the web interface.
 Customer-Centricity – The prototype’s web interface demonstrates the ability to

show multiple product charges on a single bill. Moreover, the customer can also
define the payment method, including the allocation of his payment to the bill,
through the prototype’s web screens.
Objectives
Overall Objective
The overall objective of the program is to develop a generic billing solution that allows
<Client> to competitively respond to the heterogeneous needs of multiple sector clients
in a consistent and cost effective manner. (This is a sample objective. State your own
objective here in a clear, concise manner.)
<Company> understands that <Client> will use the solution to <Do What>.
To support the program objectives, guiding principles were established to guide the
development:
1. Flexibility - Ability to easily interface into legacy and future systems

2. Scalability - Capable to grow in line with business demands
3. Re-usability - Maximum reuse to support new customers
4. Cost Efficiency - Creative commercial propositions; life cycle costs
5. Timely - Pace to build and deploy
Fundamental to our consideration has been the determination to structure a program

that supports the build of the basic functionality of a quality Generic Billing System in
<State Timeframe>.
Business
The Generic Billing Program is essentially a major change program. <Company>

characterizes such programs as consisting of four dimensions – Management,
Operations, Social and Technical (MOST). Independent industry experience highlights
that many programs focus too much effort on the Technical aspect and neglect the other
key areas that contribute to success. Our approach will assist <Client> to achieve its
commercial objectives in a number of areas. We have examined the program from a
business, technical, and program perspective (note that the relevant dimension of
change is indicated against each objective):
MultiClient, Provide pace to market for complex products and services. Ensure
MultiService, that operability is managed and maintained.
MultiProduct (O)
Scalable (O) Allow deployment for different size clients with different service
level requirements, allowing for significant future growth.
Lifecycle Cost (O) Minimize the cost of support, deployment and system
enhancements.
Introduce New Ensure new products and services can be introduced quickly and
Products Quickly easily.
(O)
Transaction Costs Minimize transaction costs and transaction processing times by
(O) strict validation.
‘End to End’ Provide a capability that supports the ‘end to end’ integration.
integration (O)
Operating costs Reuse of existing infrastructure where appropriate to minimize
(O) costs.
Management and Provision of appropriate dashboard of information to support
operational management decision making
reporting (O)
Customer Centric Maintain Customer related information at a single point of access
(O)
Technical
Simplification (T) Minimize the duplication of functions and systems, reduce
the interfaces and introduce stringent controls to the
environment.
Reduce Impact of Create a flexible componentbased architecture that controls
change (T) change and manages interdependencies.
24 x 7 availability Design the system to support 24 x 7 system availability.
(O)
Align IT and Create business systems that support current operational
Business (T) requirements yet are capable of enhancement to support
future needs.
Scalability and Component Based Architectural Design that supports
speed of business growth and responds to the pace of business
deployment (T) requirements.
Maximize existing Design an environment that allows for the development and
Client Investment reuse of existing systems, data and components enabling
(T) seamless integration with the new applications.
Program
Holistic View (M) Deliver a program structure that manages the dimensions of
a large and complex change program. The Management,
Operational, Social and Technical implications are
understood and incorporated during the formulation and
implementation of the overall program plan, as well as the
supporting project plans.
Program Introduce the standards, controls, methodology and
Management (M) disciplines necessary to deliver a program of this nature.
Architectures (O) Refine, integrate and complete the application, data and
technical architectures.
Tools / Methods Introduce the necessary tools and methodologies to support
Support (T) the architectural implementation alongside the bespoke
development and any package integration required.
Business Benefits Provide a release strategy that delivers a continuous stream
Stream (O) of business benefit through the life of the program linked to
<Client>’s strategy.
Knowledge If required, transfer the skills, techniques and process to
Transfer (S) <Client>’s staff to facilitate their ongoing personal ability
to support the System.
Scope
Solution Scope
<Company> is proposing to assist <Client> with the development and building of a

Generic Billing System. The scope of the proposed solution is shown in the diagram
below and described in the subsequent sections:
<Insert a Graphic Depicting Solution Scope Here>
This first phase will provide a generic billing system. The different areas of this system
are described below. (These are sample topics. Yours might vary.)
Customer Set-up
The set-up of customer accounts. This area receives contracts from such
sources as customer-submitted contracts, sales agents and express contracts. It
is responsible for performing all actions that are required to set up a customer
contract and permit the delivery of a service to a supply point.
Customer Retention
Retention encompasses the business areas for queries, complaints and closure
of accounts. The main objective is to respond quickly and appropriately to
customer queries and complaints. In the event of closing of accounts, services
should be properly terminated. This major area also handles maintenance of
customer contracts.
Usage
The management of the following processing in relation to calculation of usage:
 <List items>
Billing
The calculation of bill items and generation of bills for single or multi-services to
cover various media (print, web and others). Bills can be triggered by a cyclical
period whether measured or non-measured, or upon customer request. This
business area also includes maintenance facilities for complex billing elements,
i.e. tariff, discount and tax calculations.
Payments
The management of the following functionality:
 Receiving payment from different sources, reformatting it to a common format

and allocating the payment to account receivables based on defined
allocation rules;
 Recording of unidentified payments whose accounts are not known at the
time the payment is received;
 Transferring of payment from one account to another;
 Rejecting of payments due to acceptable reasons like bouncing checks,
closed accounts or insufficient funds;
 Refunding of outstanding payments;
 Creating a payment plan that involves the estimation of consumption for a

certain period; and
 Maintaining of a standard payment plan that will be used to validate which
payment plans can be offered or applicable to certain customers based on
specific parameters.
Assistance and Non-Payments
Assistance is designed to keep track of all transactions from the time the
customer service representative receives a customer or agency request. It
accounts all customer information and details related to a particular Assistance
agreement, e.g., time period, agreed fixed arrears, current amount, etc. It also
maintains and records any agencies that interact with the client and the
customer. On the other hand, Non-Payments covers the processing that is
involved in administering a debt. This includes ageing the receivables and
determining what actions to take, depending on the age. This also covers the
creation and monitoring of the payment arrangement.
Sales Agent Management
This business area maintains the sales agency details and the financial
relationship of the client with a sales agent. It records and maintains the basic
details of a sales agent and has the facility to capture of the commission
agreement between the client and a sales agent. The commission agreement
defines the amount of commission awarded to a sales agent for the submission
of a contract. The commission is dependent on the type and details of the
contract and is awarded at certain points in the lifecycle of the contract. The
commission agreement also defines the claw-back mechanism that will be
applied to the commission in the event that a contract is withdrawn or is
delinquent.
Alliances Set-up
This provides the facility for supporting the alliance agreement between a client
and an alliance partner. It includes the entry of the details of an alliance
agreement in terms of inbound and outbound alliances. It also allows the set up
of customers as subscribers to an alliance agreement.
The solution architecture will support future integration of additional components.

These components may be:
 Extensions of the business needs to incorporate <What>.

 Components further developed to customize and/or optimize the generic
system for use by <Client>’s clients
 Legacy system components that can be ‘wrapped’ to work with the generic
system.
 Developments of the overall business solutions incorporating new
technologies and approaches. <Client> has specifically identified Customer
Relationship Management (CRM) as an example of a development that must
fit with the generic system.
<Company> has further identified that new technologies allow use of digital
business based approaches to managing and working with customers.
To take the opportunity of web-based digital business opportunities, business

intelligence (BI) can use data warehousing technology to feed a relationship
management (RM) system. That can then tie to an electronic commerce (EC)
front-end to facilitate ordering, support functions, and communications between
<Client> and the customer.
<Company> will design the generic system to allow full benefit of these
technologies to be easily added at a later date.
Regulatory Reporting
All billing reports necessary for <Client> to meet its regulatory reporting
obligations.
Functional Scope
The functions that are included in the scope of the project are:
<Insert Functional Scope Diagram>
 Set up new account

 Registration
 Losses
 Flow management (including mailbox)
 Usage
 Bill production
 Tariffs set-up and provision
 Payment processing
 Assistance and non-payment
 Budget schemes
 Sales agent management (including commissions)
 Alliances and promotions
 Queries and maintenance
 Complaints and disputes
 Closed accounts
 Operational reporting
 Client reporting
 Regulatory reporting
Project Scope
The project will include:
 The overall program management of the analysis, design and building of the
required solution
 Technical architecture
 Integration
 Testing
 Implementation
Program Management
Program and project plans will be created as a baseline against which to

measure progress and to understand what corrective actions the management
team need to take.
Areas within the scope of this project that will help to exercise this control are:
 The installation and definition of the necessary standards

 A program office to support the development teams and to co-ordinate all the
projects within the program.
Architectures
The architectures necessary for successful delivery are included in the scope of
this program. They will be fully integrated with <Client>’s current architectures.
Broadly, there are considered to be four (4) types of architecture which will be
implemented during the early phases of the project, these are described below.
 Information architecture
 Technical architecture
 Business systems architecture
 Management organization architecture
Integration
Typically a large program is broken down into manageable components to

ensure ease of delivery. While this helps delivery of the program, this approach
increases the complexity. Therefore, the integration aspects of the program are a
critical part of the successful delivery. The integration elements that are included
in the scope of this program are:
 Development Coordination
All projects within the program are integrated into an overall application
framework.
 Release Management
A detailed breakdown of the program into manageable releases that are linked to
the delivery of business benefit and their position in the administration lifecycle.
This is achieved through a Release Management role.
 Application and technical integration

Developing a clear picture of the current applications, how they are linked
together and how they support the business process, plus an evolutionary
migration plan showing how this picture changes by program release. An
important goal here is to define and understand the application interfaces.
Testing
This will include all aspects of component, integration and user testing. The
diagram below depicts the different testing phases.
<Insert Testing Diagram Here>
Unit Tests
Unit testing focuses on individual objects within a design area and ensures that
each one of them is performing its defined tasks.
Component Tests
After unit testing has been performed, a component test is run to verify the
integration of all objects within a component.
Integration Tests
Integration testing is performed on a series of inter-related components to satisfy

interfacing conditions prior to the execution of the user acceptance test.
Stress and Performance Tests
Architectural components are load and stress tested individually and as a

complete to gain confidence that the system will perform as expected when it is
out there in production.
User Acceptance Tests
User acceptance testing covers an end-to-end view to prove that the system is
performing according to the business requirements.
Operations and Commissioning Tests
The operations and commissioning test phase involves testing that pertains to
the execution of operating procedures, ensuring that the operating procedures to
be turned over to the operations and support team are fully tested.
Implementation
Although not included within the scope of this document, <Company> would like
the opportunity to work with <Client> staff to implement the system for use by
<Client>.
Approach
<Company> recommends that the scope of this implementation utilizes the

‘MOST’ techniques that have been so successful for clients working with
<Company>:
Creating business impact is not achieved by delivering new technology. Impact is

the result of a business change program. Whether that change is large or small it
always has the same dimensions - every change program must address
management change, operational change, social change and technical change
(we use the acronym ‘MOST’ to remember these four dimensions).
Management
This addresses the business drivers for the change and focuses on business
measurement. Unless the business defines the desired outcomes and designs
an effective means of measuring and monitoring them the program is unlikely to
be successful. The management dimension designs the roadmap for the
business and provides the tools to navigate.
Operational
This addresses the mechanics of the new business. We focus on the business
rules rather than specific processes (although new processes will almost
certainly emerge). The goal however is to provide a framework in which there is
room for ongoing change and the dynamic development of the new business
operation.
Social
This addresses the people aspects of change. This will include customers and
staff. In almost all cases business impact can only result from a change in the
behavior of people. These may be buying behaviors or work practices. The social
projects will address things like communications, education, incentives, career
alignment.
Technical
This addresses the successful implementation and operation of technology to

support the business change.
Drivers
Our approach is described in some detail in this section. There are some key drivers that
influenced our thinking greatly in defining the approach. These are: (List your own aet;
what’s below is an example):
 Early and recurring business benefits linked to <Client> sales cycle – The
generic billing product is being built as a series of components. For economic
reasons and to aid <Client> sales, we must structure the projects to deliver real
business and benefits as early as possible in support of <Client>’s sales effort. The
approach is designed to deliver full business functionality and benefits within six to
nine months of starting the project, and allows for phased component releases in
support of <Client>’s sales effort and client acquisition strategy.
 Integration – Each GBS client implementation will be different because there will be
many legacy systems and packages to integrate with. Our approach is designed to
allow ease economy of integration. This is achieved through considering the end-to-
end process, designing a component based solution, and establishing core
components prior to designing the specific client versions.
 Change program – Any project, but especially one of this scale, is a complex
change program. It is not simply about building and implementing systems; rather,
it’s about managing a complete set of changes in the business. We characterize
such a program as having four dimensions – Management, Operational, Social and
Technical. We will manage the Generic Billing program under the MOST framework.
[This ensures the support mechanisms are in place for client installation.]
 Achievable projects – There is compelling evidence in our industry that large
projects fail and small projects succeed. The scope of an achievable project is such
that the manager can understand all of the key components. The only safe approach
is to define pragmatic, manageable development projects and co-ordinate their
development. We have broken the program down into three releases, each release
comprising a number of projects.
 Controllable program – Breaking a program down into small projects obviously
requires an equal ability to reassemble the pieces. This requires a high degree of
control and co-ordination of the components being built. We deliberately manage the
number of concurrent components such that it remains manageable. There are

never more than five concurrent development projects.
 Productized – The generic billing solution must be developed as a componentized
product that can interface to standard packages and legacy systems to allow delivery
to a wide range of utility clients. When building the GBS solution, consideration must
be given to product management.
 Component approach – A key to the power of components is moving the control
logic or flow outside the component. In practice, changes to control flow are more
common than changes to business logic. In traditional development, business logic
and control flow are intertwined. As a consequence, any change requires opening up
the complex code of the application. With components the change is isolated, and
updating the control flow cannot impact the business logic. The advantages of a
component approach are flexibility, ease of maintenance, potential of reuse, lower
risks in development and maintenance.
The release strategy will be covered in more detail later in this section. We will not
attempt to execute the project as one large solution. This approach leads to failure –
cost and time overruns and poor functional fit. We believe our incremental, release
based approach is critical to success.
Overview of Approach
Our overall approach to the program is divided into four areas of activity. These are
defined as follows:
 Program start-up is a short but key set of activities to get the organization, detailed
plans and specific resources in place.
 Program baseline and environment set-up is a number of parallel activities to set
up the environment for the program.
 Business functionality releases represents the bulk of the development work on
the project organized into a number of concurrent and sequential releases.
 Deployment covers client deployment.
 Product management covers the management and support of the generic billing
product.
The following graphic is just an example. Insert your own project diagram here.
The following diagram illustrates these areas:
Programme Start-up Plan
Activate
Programme Baseline and Environment
GDC Set-up Complete Complete People

Basic functions Infrastructure Technical Analysis Stream Component
Set-up Architecture Preparation
configuration Set-up
Definition
C
o Review
n Transition
t Plan
r
o Business Functionality Releases (Delivery)
l
Management Operational Social Technical

Change Change Change Change
Deployment /
Product Management
End
It should be noted that this diagram is illustrative rather than time-based. For example,
deployment can start for systems as they are delivered incrementally, not at the end of
the program as it appears, and product management must be considered throughout the
life of the program.
The following sections describe these areas of activity in more detail.
Phase 1 – Program Start-up
The initial phase is dedicated to program start-up. It is essential with a program of this
size to establish a well-defined and disciplined environment in advance of starting the
individual projects. The following are the focus of the start-up area:
Plan
Both <Client> and <Company> must plan and review the plan in this proposal,
create a program definition and the project definitions for each project.
Mobilization
Both <Client> and <Company> must plan the specific resource requirements and
ramp up in a timely manner. <Company> will create an induction plan to get
resources effective as quickly as possible. These tasks include:
 Confirmation of roles and responsibilities

 Initial core team building
 Mobilizing resources required within <Client> and <Company>
 Initiation of methods and tools stream
 Equipping the team

 Daily communication at every level in the program
Program Office
The Program Office is a key mechanism for managing the program overall. One
of the first activities will be to put the office in place and execute the following set-
up steps:
 Producing the Terms of Reference

 Confirmation of budget
 Establishing the Steering committee
 Preparing a framework for communication and reporting
 Communicating with the business and internally within IT
 Identifying the key milestones and critical path
 Examining the costs, benefits and risks
 Any necessary contractual amendments
 Implementation of strict change control procedures
 Agreeing subsequent program deliverables
 Hard resource estimates for next phase, soft for subsequent phases
 Hard time frames for next phase, soft for remainder
 Risk review procedures
Deployment Scoping
As part of start-up, we plan to inventory all the deployment components and

activities to ensure that a successful client implementation can be achieved. For
example, data cleansing and data conversion could compromise a client
implementation unless it is fully prepared for during the development project.
The diagram below shows how the phased approach fits into the client
acquisition lifecycle and indicates possible components that may be required.
(This is a sample diagram. Yours might be different.)
Implementation
Data Cleansing
Training
Client Warranty &
Acquisition Data Take-on Maintenance
MIS
CRM
Other...
Phase 2 – Program Baseline and Environment Set-up
The second phase is focused on establishing a firm baseline for development releases
and setting up the environment for the program. There are several factors to consider in
setting the development agenda and priorities. These will lead to an integrated
component development plan.
Setting the Development Agenda
Functional Requirements
Business Component
Priorities Dependencies
Set by sales Priority
Setting
Component
Development
plan
Evolutionary Deployment Model
Infrastructure Set-up
This stage is responsible for establishing the hardware and software environment
for running all the tools to be used in the program. This will include the loading
and configuring of the tools selected for the program and setting up access
rights. The required servers will be commissioned and made available for the
program team.
Basic Functions Configuration
As part of the set-up activity, the development team will develop the base
functions for the project. Basic Functions is the collective term for the
development guides, technical standards, reusable components and services,
and program templates/libraries established for the mandatory use of every
developer in the project. It serves as the link between the technical architecture
and the application development.
The approach in setting up the Basic Functions is to determine the basic

functions/objects/standards by systematically visiting each key integration area
specific to the technology used:
 GUI (look and feel)

 Systems integration
 System performance
 Interfaces
 Reports
 Data communications
 Data access and integrity
 Naming conventions
 Programming standards
 Security
 Error-handling
 User help
The resulting basic functions are then organized according to each specific
technology. Thus, a typical set of basic functions would appear as:
 Oracle Basic Functions

 NAME OF TOOL Express, Visual Basic Functions
 NAME OF TOOL Conductor Basic Functions.
For the <Client> program, <Company> will use this approach in developing the
basic functions and draw from its component/object/template libraries.
The basic functions are used effectively to promote reuse, design consistency,
productivity, and quality assurance.
Complete Technical Architecture Definition
The primary objective of Technical Architecture (TA) is to provide a cost-effective

combination of hardware, packaged software, application architecture, custom
applications, and operating environment to develop and deploy the required
functionality.
The main driver of the technical architecture is a set of business requirements or

business benefits. These drivers are commonly named “key performance
indicators” (KPI). They resemble the “key success factors” (KSF) identified within
<Client>. These business benefits are translated into “‘volumetrics” stating a
measurable target performance (for example, ability to process one million
transactions within two hours usage). The concept of “volumetrics” is much
broader in scope than the timing implied in this example. Volumetrics include: (a)
work capacity and timing, (b) availability, reliability, maintainability, (c) security,
and (d) service level agreements. Technical Architecture provides the means of
satisfying all these measures of performance.
The Technical Architecture will result in both a framework for ongoing

management and maintenance based on KPI/KSFs and a set of implementation
projects or project options, which would feed into the deployment strategy
documents.
The technical architecture was started in phase 0, and this activity builds on that
deliverable.
Complete Business Analysis
This activity will complete the analysis process. Full data, process and interaction
matrices will be produced. In addition, this will allow the component delivery
phasing, the release priority to be established and ensure that the necessary
controls and architectures are fully defined integrated.
The basis for the analysis will come from the models developed during phase 0
of the project and existing documentation.
The requirements will be detailed to a level that allows the start of design.
Component Preparation and Design
Map the possible reusable components to the <Client> business process. Once
mapped, each component should be prepared for reuse.
People Stream Set-up
The pressures created by a program of this nature are particularly telling on the
participants’ (stakeholders’) staff. A change in culture is required to move towards
a business outcome-focused organization. The transition to a component-based
architecture environment presents a significant challenge in the management of
the staff.
It is essential to rapidly align the with the new approach, define the roles, the
tasks, the new disciplines and show where and how everybody fits into the
organization and how they will contribute to the success of the program.
Transition Plan (or Release Plan)
One of the key deliverables from this stage is the transition plan. The options that
will be considered during transition planning are:
 Build only a core set of components.

 Consider reuse of legacy systems, by wrapping as components, to speed up
deliver and reduce cost.
 Use existing packages, if possible, for the option components (e.g., customer
maintenance).
In producing the transition plan, great care will be give to linking the deliverables
to the sales requirements.
Phase 3 – Business Functionality Release (Delivery)
Phase 3 represents the bulk of the program. This phase produces the business solution
in five release increments. Each release will be addressed using the ‘MOST’ approach.
The release approach and the five proposed planned releases are described in this
section.
Release Approach
The traditional approach to development projects is based on a large and

monolithic program addressing analysis, design and build sequentially. This
approach, as we have stated before, has proved problematic for many large
programs in the past.
Our alternative approach is to break the program down into smaller releases and
build the solution incrementally. However, this is more than just a
project/construction approach as the releases are chosen to deliver business
benefits and are put into production as they are completed.
The key elements of this approach are:
 Releases are designed to deliver business benefit.

 Releases are sized for small teams and short time scales.
 A single team works on a release from beginning to end. This has been
shown to dramatically improve quality.
 A coordination team focuses on maintaining consistency across the releases
and managing communication between the release teams.
The benefits of the approach:
 Improved quality
 Visibility of progress and achievement
 Proven delivery capability
 Early and continuous learning
 Redefining the cost/benefit curve
 Higher probability of success
Planned Releases
The approach is based on five example releases that will be finalized during
transition/release planning. Each release addresses one or more aspects of the
business functionality. The releases will be sequenced to support the <Client>
sales effort. The table below describes the releases, the principal ‘key success
factors’ they support, business support, the software functionality to be delivered
and the associated organizational changes.
Business Key Success Business Software

Release Factors Release Functionality
Number Description
MultiClient, Contract validation
MultiService, Set up Account setup
MultiProduct customer Industry Flows for
Customer
Fast introduction accounts Gas and Electricity
Setup
of new services Set up setup (Supplier to
Speed of customer and from external
delivery contracts organization)
Reduced Setup tariffs Meter reading
lifecycle cost Capture automated
‘End to end’ service usage Create calculations
integration Produce Integrate all
Customer
Improved customer bill products in billing
Servicing
service through Process Group billing
links to partners payments
Manage non
payment
Customer Service queries Single set of
centric and customer
Respond quickly maintenance information
Customer to change Complaints /
Retention Disputes
Manage
account
closure
Increased Define Sales agent
customer base commission information
Sales Agent agreement
Management Monitor
commission
agreement
Customer Define alliance Alliance information
retention scheme and schemes
Alliance Setup Increased Maintain
customer base alliance
customer
The above timeline indicates a potential phasing for the individual releases. It is,
however, important to recognize that each release may well have multiple
delivery drops to allow coordination of the component dependencies between
releases. The arrows indicate these potential links and are by no means
comprehensive.
Process Definition
<Company> will be collecting any new processes and modifications to current

processes throughout the Program – a standard exercise for <Company>
projects. These improved methods will be available to <Client> during the
Program and after implementation. This will mean all best practices will be
captured and available to all current and future staff.
Client Training
<Client> indicated they would like to use <Client> Training Services and facilities
to develop and perform client training.
<Company> have already performed, developed and delivered training for a

large number of its clients, but are happy to support this approach.
Phase 4 - Deployment
A deployment package will be produced as part of the development project, which will
include user guides, data migration plans, operation guides, training courses, etc. The
key issues that compromise the speed of a client deployment are data migration and
data cleansing.
Data Migration
<Company> believes that Data Migration is one of the most important areas of
an application implementation, and one of the most difficult to implement
successfully. Therefore, it is important that a tried and tested approach is
followed when implementing GBS at a client site.
Data migration will have its own problems, but using a standard migration
process will increase the quality and the likelihood of success.
Because a data migration exercise is quite often difficult, it is important to start it

early in the project lifecycle, ideally during the user requirements capture phase
of the project.
<Client>’s clients rely on the quality of its data to conduct their business. To
reduce the risk that the data migration exercise does not compromise <Client>, it
is important that both the business and auditors are involved in each stage of the
migration process.
The approach <Company> follow on any data migration exercise can be broken
into the high level activities detailed below:
 Analyze the current data structures

 Analyze the target data structures
 Map current data structure to target data structure
 Analyze the data quality
 Define data migration strategy
 Build contingency plans
 Perform migration dry runs
 Data reconciliation
Data Cleansing
The data to be migrated from the current client systems will not be clean. Many
of the older systems may have had poor data entry validation allowing unreliable
or incorrect data to be entered. As part of the data analysis exercise, the current
data should be assessed to ascertain its quality. This analysis may result in any
or all of the following:
 Replacement of missing data

 Removal of duplicates, e.g. Names, Addresses, etc.
 Correction of data integrity rules in the new applications
 Implementing data standards, e.g. Naming, Abbreviations, Dates, etc
 Improved data consistency
Once the data cleansing issues have been addressed, the necessary processes
and procedures should be put in place so that <Client>’s data quality remains
high. This may involve checking the data validation rules in the new application to
test for data quality. It may also mean changing some of the data entry processes
by the business or may mean additional business users training.
Phase 5 – Product Management
A product management agreement will be developed, with <Client>, during the

development of GBS. <Company> recommended this, based upon a clearly defined
service level agreement. The service level agreement will define the scope of the work
that needs to be supported, the staffing levels necessary to support the effort and the
turnaround expected. <Company> are committed to a service delivery that will meet your
expectations. The approach is based on the belief that as <Client>’s partner for the
Generic Billing Program, <Company> must become an extension of <Client>’s
organization.
Service Level Agreements
The scope of the work will be based upon the service level agreement jointly
defined during the pre-production phase of the program. The service level
agreement will be utilized as the foundation of the project delivery expectation. It
is standard practice to develop a unique service level agreement with each client.
This forces complete focus on the key drivers to client success and deliver to the
agreed upon goals.
The following are some of the components that are considered as part of a
service level agreement. It is only possible at this stage to give an indication of
the types of service and the associated levels that may be required by <Client>.
Level Description
Base Support Support personnel will be available to address any application
related issues on a 24x7 coverage basis. This will be a local
based support team.
Rapid For emergency level problems a highly trained rapid response
Response team with highly experienced locally based expertise will be
Team available on call and have dialin access.
Level Description
Defect The recommended approach is to categorize all defects based
Response upon severity. The service level agreement will address the
Type/ escalation, prioritization and turnaround expectations based
Volume/ upon the type of defect and the agreed upon volume to be
Turnaround supported.
System A service level agreement will be established with the
Support computer operations team for inclusion in the planning of
availability of system resources for use in support of the
system. This section will address expected system downtime,
maintenance outages, turnaround time on system requests,
timeframe of technical support and level of support available.
Enhancement If required a standard level of enhancement hours can be
Implementati included within each release. Staffing of the team will reflect
on Support any additions beyond the agreed upon enhancement hours.
Since the new system will be under development during this
timeframe, it is recommended that enhancements to the system
be minimized and agreed upon. The implementation of
extensive enhancements will cause significant cost and time
impacts to both the maintenance team and the new
development team. It will also increase the level of co
ordination and communication between the teams.
Technical A baseline technical configuration will be established within
Configuration which <Company> will be responsible for supporting the
& Upgrade system. Additionally, it will include any agreed technical
Schedule platform upgrade schedule. This schedule will be critical so
that the appropriate levels of staffing are available to support
the upgrades according to the agreed upon schedule.
Staff Support It will be necessary to agree upon a level of support from
Availability <Client>’s staff in making production release decisions.
Previous experience has been that a minimal level of support
will be required from <Client>’s team to address complex
issues that may arise.
AdHoc These are generally requests for reports or views of the
Requests database to answer a specific problem or question. It is
required that all requests be tracked because this is often a very
timeconsuming effort for the team. <Company> will
incorporate a defined amount of adhoc support in the service
level agreement.
Level Description
Firmwide <Company> anticipates that the support team may be required
Initiatives to support firmwide task forces or initiatives that are in need
of system knowledge or support. This is very difficult to size
and manage, so we would expect that this support level will be
incorporated within the service level agreement and the
specific firmwide support requirements will be defined within
each quarterly release.
Internal <Company> expects that the systems interfacing with GBS
Systems/ will be undergoing change throughout the support agreement.
Interfaces These teams will require some design assistance and support.
To address this need, the support team will include a system
analyst who will be responsible for working with the other
systems and users in defining requirements and design issues.
The level of support will need to be defined within the service
level agreement and planned with the necessary release plans.
Priority – Proposed Service Level Agreement
Priority A Priority B Priority C Priority D Priority E

Response 5 Minutes 15 1 hour 1 day 2 days
Minutes
Resolution 30 1 hour 5 hours 2 days 4 days
Plan Minutes
Work 2 hours 2 hours 1 day 7 days 14 days
Around
Call 2 hours 4 hours 2 days 14 days 28 days or
Closure* such other
reasonable
time.
Severity Escalation Procedures
Priority A Support Team works on the problem for a maximum of two
hours, until the problem is either fixed or identified as a bug. If
a resolution is not available at that time, the Priority A Problem
Report is escalated to the Escalation Support Team.
The Escalation Support Team works continuously on the
problem, and will work directly with Engineers as needed.
The Management team is briefed on the status of Priority A
every four hours until the Problem Report is downgraded or
resolved.
Priority B Support Team troubleshoots and/or gathers specific information
Severity Escalation Procedures
pertaining to the suspected problem. The Support Team actively
pursues problem resolution for a period not to exceed one
business day. If resolution is not available at that time, the
Problem Report is escalated to the Escalation Support Team for
resolution assistance.
Support Team continues active involvement by working with
the team toward resolution.
The Management team is briefed on the status of Priority B
problems at the beginning of each week in a review meeting.
Priority C Priority C problems are forwarded to the Support Team for
isolation and/or resolution. The problem must be resolved or
identified as a bug within two business days before it is
escalated to Engineering for resolution.
The Management team is briefed on Priority C problems on a
weekly basis in a review meeting.
Priority D Priority D problems are handled by Support. The Support Team
investigates electronic databases available for solution. When
the question is answered the Support Engineer will ensure the
information is saved in a solutions database.
Escalation to Engineering may become necessary when the
ordinary customer support practices have been tried and the
question persists or whenever customer satisfaction is at risk.
The Management team is briefed on Severity 4 problems on a
monthly basis.
Priority E Priority E problems are handled by Support. The Support Team
investigates electronic databases available for solution.
Generally they are minor requirements with no need for
escalation. Escalation to Engineering may become necessary
when the ordinary customer support practices have been tried
and the question persists or whenever customer satisfaction is at
risk.
The Management team is briefed on Severity 4 problems on a
monthly basis.
*upon call closure the priority condition shall revert to a lesser priority (e.g., A to
B, B to C, etc.).
Deliverables
Main Deliverables
There are literally hundreds of possible deliverables throughout the life of the program.
In this section we focus on the most significant deliverables. Others can be seen in the
<Company> architect product, which is in use at <Client>.
Deliverable Description
The key deliverables are described in the following table and in the diagrams on the
pages following this section.
Main
Deliverable Description Purpose Content Format
Deliverables
Project The Terms of Define the tasks, Word Processor
Management Reference for project deliverables,
Plan the Project. structure effort
Project A Gantt Chart Schedule the tasks, In ABT PMW
Schedule for the project activities for resources, dates
the project
Spotlight A high level A spotlight key Word
Report summary of status for performance processing
program status management. indicators by document
with a stoplight project type cataloged in
(r,y,g) indicator Deliverables
for each Manager
project.
Progress A detailed Project Time, effort Word
Report description of Managers and cost processing
the project report expended document
status for a against plan cataloged in
period of time. and estimate to Deliverables
complete Manager
Risk Issues An ongoing list Focus attention risk, Word
and assessment on risks and assessment, processing
of risks for a mitigation mitigation document
project. actions cataloged in
Deliverables
Manager
Issue List An ongoing list Track issue, status, Word
and assessment outstanding severity, date processing
of issues for a issues raised, date document
project. resolved, cataloged in
responsibilities, Deliverables
resolution Manager
Main
Change List An ongoing list Track changes change item, Word
and assessment requests and change request, processing
of change disposition date, impact document
requests for a assessment, cataloged in
project decision, status Deliverables
Manager
Acceptance A definition of To ensure Conditions of Word
Plan the terms under quality and acceptance processing
which the agreement document
business will cataloged in
accept the Deliverables
release. Manager
Project A post project Learn from description, Word
Completion record of project benefits processing
Report project results experience achieved, document
and assessment metrics, lessons cataloged in
of project learned Deliverables
performance. Manager
Quality Plan A statement of State quality quality targets, Word
quality goals target and issues, processing
and the achievement measures document
mechanisms to cataloged in
achieve them. Deliverables
Manager
Project A definition of To facilitate Procedures, Word
Offshore processes, offshore standards and processing
Strategy procedures and development. controls document
controls for the cataloged in
joint onshore/ Deliverables
offshore team Manager
DAD Deliverables
The Distributed Application Development (DAD) method is the primary approach that
we will use at <Client>. As this is a major element of the overall approach, we have
listed the deliverables on the following pages. These diagrams show the relationships
and flow between the deliverables and include illustrations of the key deliverables.
Testing Deliverables
Main
Testing Description of Document the Test goals, Word
Strategy the test testing strategy approach and Processing
strategy. costs document
cataloged in
Deliverables
Manager
Test Plan Description of Plan for testing Test steps, As above
the test plan a release responsibilities
Test List if test Define the Test scenarios Mercury test
Specifications scenarios, actual test and cases director and
conditions and word
cased processing
Test Incident List of test Document and Test executed, Mercury test
Report results analyze the test incidents reports and
including results of the word
incidents noted test. processing
Technical Architecture Deliverables
Technical A diagram of Define the domains and Word
Domain Map technical technical interactions Processing
domains. domain document
cataloged in
Deliverables
Manager
Domain TA A diagram of Illustrate technical As above
Diagram an individual domains components
domain.
Domain A spreadsheet define performance SS cataloged in
Performance documenting performance targets Deliverables
Model performance targets Manager
targets
Domain Flow A diagram Illustrate technical Word
Diagram illustrating a domain support components Processing
business for business and operation document
function requirements steps cataloged in
mapped on top Deliverables
of the domain. Manager
Domain Detail A spreadsheet Specify and bill of materials SS cataloged in
Configuration defining the bill cost Deliverables
of materials for components Manager
the domain
Main
Domain A diagram Understand business Word
System to mapping usage of systems, Processing
Technical business domain by technical document
Mapping systems and systems domains cataloged in
components Deliverables
onto domain Manager
technologies
Domain A description Define operations Word
Operation of operations operations requirements Processing
requirements. requirements document
cataloged in
Deliverables
Manager
Domain A diagram of Document technical As above
Physical the physical physical layout components
Layout layout for a
domain.
Domain A description Define requirements, As above
Maintenance of maintenance maintenance procedures,
and Support and support and support service levels
requirements. requirements
and approach
Deliverables by Service Parts
Develop Deploy Operate

“PACE”   
Proj.Mgmt.
DAD  
Testing  
Technical  
Architecture
Other Deliverables
The majority of the deliverables are directly or indirectly related to the three parts
requested in the proposal. The technical architecture deliverables listed above are
delivered in advance of the three parts but then are both reviewed and updated in the
context of each project starting and on a regular periodic basis over the life of the
program.
Methods & Tools Used

Methodology
The methodology proposed is based on the gantthead.com DAD process. It will be

supplemented with enhancements based on (a) experience with relevant client projects
and (b) emerging approaches not yet in the commercial products – but in use within
<Company>.
The principal extensions that will be used are:
 A modified version of DAD for development with NAME OF TOOL which was
developed at <Client> X and <Client> Y
 A method for technical architecture specification and maintenance based on several
large, performance-intensive projects
 A business contingency planning method
 Note: An integrated test strategy will be implemented as part of this program.
It is our standard practice to modify our methods at a client to fit their environment and
challenges. <Company> has a commitment to continuous learning and improvement that
is supported by process management tools and a process improvement culture.
Purpose of Methods
There are a number of key methods for the work at <Client>. While they each have a
different purpose they are related to and integrated with each other. The key methods
are listed in the following table.
Method Purpose
DAD (Extended) DAD is a process to guide the development of object oriented,
ntier client server applications. It uses UML standards for
modeling and software construction but assumes a relational
database implementation.
The DAD process includes a project management component
which is focused on action and completion. It includes the
stages: Plan, Activate, Control, End.
Architecture The Architecture Planning method drives technical
Planning architecture decisions from business benefits. It creates
linkages to ensure that the architecture is maintained to date
with changes in the business or, alternately, that periodic
assessment of technical changes can be evaluated in a
business context.
Business Business contingency planning is a new approach. It is used
Contingency to analyze the business impact of significant events and create
Planning response plans.
Testing Method The testing methods are integrated with the other
development approaches used by <Company>.
Main Phases/Activities
As described above <Company> will use a range of methods to complete the program at
<Client>. These methods all come from a common framework of approaches used in
<Company> They work with each other to provide a single complete approach.
The major activities within the methods are described below:
Main Activity Purpose Description Outputs When used

DAD Method
Plan Produce a Plan the business case, At the
realistic and activities of the project plan, beginning of
practical plan. project. success criteria each project
and program
Activate Prepare for Prepare the Educated team As above
start and for environment and prepared
success. and team for environment
success.
Control Ensure Control the on Progress At milestones
successful going project report, issues in each project
completion. and drive for list, project and program
completion. assessment,
spotlight report
Architecture Maintain Ensure the fit Infrastructure At the start of
(Project) integrity of of the project Changes, each program
architectures in with the overall Standards
projects. technical Changes
architecture.
Plan extension
projects as
appropriate.
Domain Plan release Understand the High Level At the start of
Modeling based program at a Models, each program
incremental high level for Release
builds. planning and Strategy, Co
coordination ordination
purposes. Model

Business Understand the Analyze the Business During each
Object business future business Object Model, project within a
Analysis requirements. requirements Business program
and produce a Process
model as the Threads/ Use
basis for Cases,
design. Business
Confirm Scenarios,
business rules Business
before Events,
building. Business Rules
Solution Design Design the Class Diagram, During each
Design solution and business and Component project within a
plan systems Packaging, program
component solution. Application
based build. Specify Prototypes
physical design
in terms of
databases and
components to
be built.
Build Construct Assemble Physical During each
components existing and Design, project within a
and databases. build new Component, program
components Component
and databases. Flow,
Database, Test
Scenarios
Deploy Put the Develop Training Plans, During each
business materials to Training project within a
solution into support the Materials, Help program
action. system in the Materials
business.
End Plan for Gracefully end Lessons At the end of
continuity and the project, learned, project each project or
learn from capture assessment, program.
project. materials for team
ongoing assessment,
maintenance library of
and capture materials
lessons
learned.

Testing Method
Test Design Design Plan the test, Test During each
efficient, analyze the test conditions, test project within a
effective, purpose and cases, test program
reusable test function, scripts
strategies. design and
prepare the test
specifications
Test Review Prove system Review the Test report, During each
capabilities. specifications, incident reports project within a
conduct the and analysis program
tests, report
and manage
incidents
Technical Architecture Method
Understand Drive TA from Examine the Business At the
business business. business benefits beginning of
benefits benefits and assessment the overall
understand the program within
measures <Client> and
associated with renewed each
them. six months.
Translate to Define TA For each of the Technical as above
Volumetrics measurable business Domain Map
targets benefits define
a measurable
volumetric.
Map to Describe the Associate the Domain as above
Technical requirements benefits and Performance
Domains for each volumetrics Model,
domain. with technical
domains.
Define Domain Detail the For each Domain Detail as above
Technologies technologies in technical Configuration,
each domain. domain define domain
the physical layout
technologies
and their
interactions.

Expand Test the For each domain flow as above
Technical domain domain map diagram,
Domains technologies the systems to system to TA
through system the TA and mapping
and function illustrate a
mapping. function
execution
Plan Plan Define the domain as above
Technology technology projects maintenance
Projects implementation necessary to and support,
projects implement TA domain
changes operations,
project
justification
The team mix listed below is indicative only. It represents a theoretical mix for a generic
project. The mix will be determined on a project-by-project basis and will be influenced
by both skills and availability.
Main Activity Inputs Outputs Team Mix Tools/

Techniques
Architecture 50%
(Project) <Company>
50% <Client>
Base Infrastructure
Infrastructure Changes
Base Standards Standards
Changes
Domain 75%
Modeling <Company>
25% <Client>
Business Case Release
Strategy
Business High Level
Benefits Models
Existing Coordination
Models Model
Business 50%
Analysis <Company>
50% <Client>
Release Business
Strategy Object Model

Techniques
High Level Business
Models Process
Threads/Use
Cases
Business
Scenarios
Business
Events
Business Rules
Solution 50%
Design <Company>
50% <Client>
Business Class Diagram
Object Model
Business Component
Process Packaging
Threads/Use
Cases
Business Application
Scenarios Prototypes
Business
Events
Business Rules
Build 90%
<Company>
10% <Client>
Class Diagram Physical
Design
Component Component
Packaging
Application Database
Prototypes
Component
Flow
Test Scenarios
Deploy 50%
<Company>
50% <Client>

Techniques
Business Training Plans
Process
Threads/Use
Cases
Business Training
Scenarios Materials
Business Help Materials
Events
Business Rules
Tools Used
The solutions required could be constructed by <Company> in any of the environments

suggested by <Client>. Equally component-based development is a function of approach
and attitude and can be achieved in all of the suggested environments though supported
better in some.
<Company> has defined an approach using NAME OF TOOL as the foundation for the
preferred solution. <Company> believe that this offers the best long term solution for
<Client> for the following reasons:
 Strong support for component based development

 RAD support available through the generation capabilities of NAME OF TOOL
Express and further enhanced through the ease of maintenance/regeneration
available in the inheritance model it supports
 The integrated nature of the ‘middleware’ product NAME OF TOOL Fusion (with
XML) which acts as a component orchestrator
 Inherent capability to wrap legacy code as a component
 Inherent support for compatibility matching and version control for components
 Demonstrated support for high availability and high performance situations
 Support for standards (DCOM, CORBA, IIOP) in the tools and the component
approach create an open solution with a relatively easy migration path
The high degree of flexibility offered by component development and the orchestration in
Conductor provide flexibility in the business and support rapid product development or
configuration.
While component development with the other toolsets is possible, NAME OF TOOL
offers the most natural and mature environment on the market. This will aid in the
change and learning expected in <Client> over the period of the project. The negative
with NAME OF TOOL is that it virtually demands good architecture and design to get the
best result. On this project <Company> will put the architecture in place, define design
guidelines and quality assurance procedures and effect a skills transfer to <Client> staff.
To complete the development environment around NAME OF TOOL there are a number
of additional tools required. These address visual modeling, repository, program and
project management and configuration management. For these products you can either
select point tools and put effort into integration or try to find a single source with
integrated solutions. <Company> favors the latter approach.
Tool Descriptions
Category Tool Description

Visual Modeling CaseWise CaseWise is an object
oriented visual modeling
facility. It supports a
number of modeling
methods, including the
UML notation standard.
It is an open and flexible
tool.

Information Repository Platinum Deliverables Platinum Repository
Manager (PROEE) is, according
to Gartner, one of the
leading products in the
industry. The underlying
engine is the Microsoft
Repository, which
Platinum built for
Microsoft. The value of
this is that all tools
interfacing to the MS
Repository will link to
PROOE. More than 65
tool vendors have
committed to interface
their tools with the MS
Engine and over half of
those will house their
products directly on it.
PROOE has links to the
other Platinum Tools
proposed for use, with
ETI/Extract and with
NAME OF TOOL.
PROEE currently runs
on Windows NT. It is in
test on Unix and MVS.
Platinum has a current
MVS product but we
believe that it is an
inferior product and will
be superseded by
PROEE.
Change Management Platinum Deliverables Addresses change and
Manager configuration
management.

Project Deliverable Platinum Deliverables Deliverables Managers is
Management Manager a project oriented
documentation and file
manager. It provides a
means of locating and
controlling all
deliverables on a project.
Its strength is that it
manages project output
at a practical level – the
individual products or
deliverables. We are
recommending the use of
deliverables manager on
each project team – a
minimum of one copy
per project.
Process Manager Platinum Process PE is the process
Continuum/PE management and process
improvement tool. We
will provide the key
extended method (DAD)
as a process in PE.
Project Management ABT Project Workbench ABT Project Workbench
is a project management
and projectreporting
tool. It is already in use
at <Client>.

Development Tools NAME OF TOOL Tools Gartner describe NAME
OF TOOL as the de
facto choice for
enterpriselevel OO4GL
development.
NAME OF TOOL
TOOL is the
development language as
part of the NAME OF
TOOL environment. It is
in fact more powerful
than a language as it
leverages a systems
framework provided in
NAME OF TOOL.
NAME OF TOOL NAME OF TOOL
Express Express is a rapid
development generator
for the NAME OF
TOOL development
environment. In addition
to rapid development, its
great strength is its
flexibility and support
for customization and in
particular it’s ability to
preserve customized
extensions over new
releases.
NAME OF TOOL NAME OF TOOL
Fusion Fusion is a component
integration and flow
automation tool. It
supports flexible
integration of
components to support
dynamic business
processes.

MS Visual Basic MS Visual Basic is one
of today’s most popular
and powerful
development
environments today. We
may use VB to develop
some complex user
interfaces.
Data Cleansing and 1) Informatica Data cleansing and
Transformation 2) ETI/Extract transformation tool.
Testing Mercury Test Suite Mercury Test Suite is a
collection of tools for
testing applications.
Mercury supports
business function, load
and stress testing. It not
only performs the test
but manages the test
environment allowing
for tracking of testing
and control of test
scenarios. It facilitates
efficient and robust
testing.
Activity/Tool Cross-Reference
Tool Activity
CaseWise E2e business modeling tool,
Business Object Analysis
Platinum Repository (DM) Throughout
Platinum Deliverables Throughout
Manager
Platinum Process Throughout
Continuum/PE
ABT Project Workbench PACE
NAME OF TOOL Tools Solution Design, Build
Informatica or ETI Build
Mercury Test Suite Testing
Tool Reference Sites
Tool Reference
Platinum Deliverables
Manager
Platinum Process
Continuum/PE
ABT Project Workbench
NAME OF TOOL Tools
Mercury Test Suite
Tool Integration
Tool integration is critical to the success of the program. It is a concern primarily

because it impacts the efficiency of the development teams. It is also a concern
because incompatible tools can take a lot of time and resource from the technical
staff to keep the tools working together. This represents an initial cost in setting
up the environment and an ongoing cost as new versions of the various tools are
released. This is a double downside as this cost is largely unproductive – the
effort is going into making infrastructure tools work as opposed to delivering
business benefit.
Maximizing tool integration and minimising the cost of initial set-up and of new
releases was a key factor in our decision-making. We could have satisfied the
need for tools with each tool coming from a different company. This could be
described as a ‘best-of-breed’ approach. However with the leading tools there is
often little to choose between them and they play leapfrog with each other for
leadership every six months. With best-of-breed <Client> also take responsibility
for integration.
The <Company> recommendation for development tools around NAME OF

TOOL is to choose a family of tools from a single vendor. In this way integration
is immediately and dramatically improved. <Company> does not anticipate
perfect integration from such an approach, but the responsibility to fix problems
becomes the vendor’s and not <Client>’s. Each of the tools is rated as leading or
visionary by industry analysts. Equally <Company> have had good experience in
working with these tools.
Organization
Introduction
This section outlines the organization structures and roles required to deliver this
program successfully.
Organization structures are proposed for each stage of the project, i.e.:
 Program start-up
 Program baseline and environment set-up
 Business functionality releases
 Deployment
 Product management
The staffing requirement from <Client> will be:
 A steering or governance group (continue from phase 0)

 A reference group (continue from phase 0)
 During the completion of the analysis phase:
 There is a requirement for <Client> business experts from Gas and Electric [2 full
time and 4 half time for 2 weeks].
 System experts. Staff who understand the current systems and their interfaces. This
may be the core team.
 Technical and infrastructure support
 During the build phase there will be a continued requirement for the full time
business experts, plus access to staff who will use the system. This is to ensure that
any system produced is easy to use. The business users will also specify the
acceptance test cases, perform some of the acceptance testing
 There is also a need to include infrastructure and operations support when
performing ‘end-to-end’ integration testing
If <Client> treats the project as a Package delivery, the only staffing requirement that
would change is the governance structure. <Company> would perform the key roles in
the governance or steering group.
Deployment
A deployment package will be produced as part of the development project. This will
include user guides, data migration plans, operation guides, training courses, etc. The
key issues that compromise the speed of a client deployment are data migration and
data cleansing.
Data Migration
<Company> believes that Data Migration is one of the most important areas of
an application implementation, and one of the most difficult to implement
successfully. Therefore, it is important that a tried and tested approach is
followed when implementing GBS at a client site.
Data migration will have its own problems, but using a standard migration
process will increase the quality and the likelihood of success.
Because a data migration exercise is quite often a difficult exercise, it is

important to start it early in the project lifecycle, ideally during the user
requirements capture phase of the project.
<Client>’s clients rely on the quality of its data to conduct their business. To
reduce the risk that the data migration exercise does not compromise <Client>, it
is important that both the business and auditors are involved in each stage of the
migration process.
The approach <Company> follow on any data migration exercise can be broken
into the high level activities detailed below:
 Analyze the current data structures

 Analyze the target data structures
 Map current data structure to target data structure

 Analyze the data quality
 Define data migration strategy
 Build contingency plans
 Perform migration dry runs
 Data reconciliation
Data Cleansing
Data migrated from the current client systems will not be clean. Many of the older
systems may have had poor data entry validation allowing unreliable or incorrect
data to be entered. As part of the data analysis exercise, the current data should
be assessed to ascertain its quality. This analysis may result in any or all of the
following:
 Replacement of missing data

 Removal of duplicates, e.g., names, addresses, etc.
 Correction of data integrity rules in the new applications
 Implementing data standards, e.g., naming, abbreviations, dates, etc.S
 Improved data consistency
Once the data cleansing issues have been addressed, the necessary processes
and procedures should be put in place so that <Client>’s data quality remains
high. This may involve checking the data validation rules in the new application to
test for data quality. It may mean changing some of the data entry processes by
the business or may mean additional business users training.
Phase 1 - Program Start-up Organization
<Insert organization diagram here>
The program organization structure that will be discussed in this section is shown above.
This structure is only part, although a significant part, of the overall set of business
processes changes and systems improvements in <Client>. <Company>’s
understanding is that <Client> is managing this overall change program. GBS is one
element of that change program.
The program will ramp-up through each phase and the role descriptions that follow relate
to roles within phases. Roles that continue through the program are described only once
for the phase in which they appear. The following narrative describes the key roles in the
organization of the program and the typical skills, abilities and knowledge required for
the role.
<Client> has proposed two different scenarios:
 Software Development
 Package Solution
To ensure that the Generic Billing project is delivered successfully, <Company> feels
that a closely-integrated team is required for both of the above scenarios.
GBS Steering Committee
The GBS Steering Committee will be ultimately responsible for owning the
program and the realization of the business-wide benefits from the program. The
Steering Committee will:
 Ensure that the objectives of the program are fully in accordance with
<Client> and, if necessary <Client> business strategies
 Appoint the Program Manager
 Appoint the Benefits Manager
 Appoint the members of the Sales, Business and IT Review Group
 Ensure that the business case is produced
 Sign off the business case
Sales, Business and IT Review Group
The Sales, Business and IT Review Group should have a good understanding of
<Client>’s business strategy and how the program will deliver benefits to the
organization. Each member of the group will have specific roles and specific
inputs to the project, and are required to render advice, guidance, business and
technical input.
The Review Group will:
 Ensure that the program objectives are fully in accordance with the business
unit’s strategies
 Sign off the business case on behalf of the business units
 Ensure that the necessary people, finance and other resources from within
the business unit are made available, as required
 Ensure that business unit policies, principles and procedures are complied
with
 Ensure that the benefits and operational costs are included in business unit
plans and budgets
 Resolve any issues raised by the Program Manager
 Escalate issues which cannot be resolved to the Steering Committee
 Arrange for reviews of the project
 Be responsible for the delivery of the business benefits from the program.
Program Manager
The Program Manager will be a senior manager with broad-based business and
IT background. He should have delivered multi–stream programs for business
benefit and should have an excellent knowledge of the systems development
lifecycle and issue resolution processes. The Program Manager should be a
<Client> employee ‘shadowed’ and supported by a <Company> consultant.
Key areas of focus:
 Leadership
 Team Building
 Motivation and driving
 Directing
 Coordinating
 Program decision making
 Monitoring Time, Cost Quality
 Relationship management (Accountable Execs, Steering Comms,)
 Understanding the work and seeing the big picture
 Setting Program direction and defining projects
 Resolving conflict and priorities between projects
 Risk Management at program level
 Planning and defining deliverables
 Managing resources at program level
 Managing program documentation
 Forward planning
Phase 2 - Program baseline and environment set-up
The descriptions that follow relate to the key roles during this phase and are shown in
following diagram.
<Insert diagram here.>
The Steering Committee shall be responsible for:
 Ensuring the viability of the program and business case throughout the life of
the program
 Ensuring that the necessary people, finance and other resources are made
available to the program as required
 Ensuring that the program complies with all company policies, principles and
procedures
 Resolving any issues raised by the Program Manager
 Arranging for reviews of the program
 Managing the external communications of the program
 Ensuring that the business-wide benefits of the program are realized
technical input.
unit’s strategies
with
plans and budgets
Program Manager
The Program Manager will:
 Appoint the Project Managers in conjunction with the Steering Committee

 Produce the program plan for <Client>
 Ensure that the projects are coordinated and sequenced as a whole
 Ensure that the dependencies between projects are identified and managed
 Report progress to the Steering Committee
 Resolve any issues raised by the Project Manager
 Coordinate the hand-over of the program deliverables and the completion of
the program
Benefits Manager
The Benefits Manager is an experienced <Client> manager who has a broad

business background in project management and also in identifying and
exploiting benefits. This role should be undertaken by a <Client> employee,
possibly supported by a <Company> consultant part-time, especially during
project review. Initially a direct report to the Program Manager but later becoming
part of the program office, the Benefits Manager will:
 Produce a benefits realization plan

 Define the measurement criteria for the benefits
 Report progress to the Project Manager and Accountable Executive
 Ensure that the benefits realization is actively managed through the life of the
project and post project
 Ensure that any corrective action is taken to keep the benefits realization on
course
The role will continue after the completion of the program until the benefits review
is completed.
Architecture Manager
This role requires knowledge of good design of applications and technical

architecture. This role will initially be taken by a <Company> consultant though it
will transfer to a <Client> employee during the life of the Program.
The Architecture Manager will be responsible for:
 Detailed input to the Application Architecture

 Detailed input to the specification of components
 Detailed input to the design of components
 Advisory role on the finalization of release strategy
 Input to the data conversion requirements definition
 Detailed input to the Technical Architecture Vision
 Detailed input on Development tools
 Detailed input on CASE tools
 Detailed input into Technical Architecture development
 Responsible for specification of changes to technical environment
 Specification of change management requirement
Delivery Manager
The role of GBS Delivery is mentioned specifically because of its importance to

the overall program. The Delivery Manager who will be a <Client> employee here
has a role as outlined for all project managers earlier in this section. In line with
this, there is a need for:
 Awareness of the integration and an understanding of the key dependencies

of the overall program
 Recognition of the importance of the different delivery releases.
Integration Manager
The role of Integration Manager is key to the program. Typically this will be an
experienced <Client> manager who has a good knowledge of <Client>’s
business processes and overall systems architecture. This individual will have
extensive knowledge of existing initiatives in both the business areas of the
<Client> but also the systems developments currently underway. This can be
either a <Company> or a <Client> employee.
The Integration Manager:
 Owns the release plan

 Ensures all dependencies are clearly understood and reflected in the project
plans
 Is the Architect within the overall program
 Gathers a library of all process descriptions documentation relating to
<Client> to allow a full understanding of the boundaries between functions
 Assists in developing a view of the key weaknesses in the current
applications and data architectures
 Specifies how the integration issues identified during the Baseline stage will
be resolved in the new Architecture
 Works closely with the Benefits Manager identify and pursue the synergies
offered by true integration
 Identifies the need for information exchange between projects
 Ensures that a process is in place to facilitate this

 Identifies and analyzes all key interfaces between existing applications to
ensure that legacy applications and interfaces can be decommissioned at the
earliest opportunity and with minimum risk
Phase 3 – Business Functionality Releases (Delivery)
The Steering Committee shall be responsible for:
 Ensuring the viability of the program and business case throughout the life of
the program
 Ensuring that the necessary people, finance and other resources are made
available to the program as required
 Ensuring that the program complies with all company policies, principles and
procedures
 Resolving any issues raised by the Program Manager
 Arranging for reviews of the program
 Managing the external communications of the program
 Ensuring that the business-wide benefits of the program are realized.
technical input.
unit’s strategies
with
plans and budgets
Program Manager
The Program Manager will:
 Appoint the Project Managers in conjunction with the Steering Committee

 Produce the program plan for <Client>

 Ensure that the projects are coordinated and sequenced as a whole
 Ensure that the dependencies between projects are identified and managed
 Report progress to the Steering Committee
 Resolve any issues raised by the Project Manager
 Coordinate the hand-over of the program deliverables and the completion of
the program
Program Office Manager
The Program Office (PO) is managed by the Program Office Manager and
provides administrative support to the program, thereby allowing the program
management to concentrate on their key responsibilities and avoid being
distracted by administrative aspects. The main responsibility areas for the current
PO are:
 Plans and Timesheet Management

 Risk/Issue and Change Log Database management
 Benefit and Costs Management
 Interfacing to the Resource Management within <Client>
<Company> will need to be directly involved to ensure the proposed work is
managed and integrated with other projects correctly. It is recommended (and
included in the Baseline Positioning Stage of the Program) that <Company>
works with the current PO staff to consider a wider scope for the PO. The current
PO is mainly in the Program Administration area and consideration should be
given to adding
 Extended support -for the Project Managers and team members in using the
right processes and techniques. This is in line with and can work with the
Pioneer Initiative.
 Asset Management – for ensuring that there is minimal ‘re-inventing of the
wheel’ through the program and best practice (process and deliverables) is
shared.
 Resource Management – already covered in the current set-up but as the
program grows this may require extra support.
The <Company> view of the key aspect of Program Administration is enlarged
below.
<Insert diagram>.
Delivery Manager
The role of GBS Delivery is mentioned specifically because of its importance to

the overall program. The project manager who will be a <Client> employee here
has a role as outlined for all project managers earlier in this section. In line with
this, there is a need for:
 Awareness of the integration and an understanding of the key dependencies

of the overall program
 Recognize the importance of the different delivery releases.

Business Change Manager
The Business Change Manager is responsible for planning and facilitating

cultural, operational and organizational changes in the organization. He shall look
at management style, internal and external communications patterns,
organizational structure, job and role definitions, and the varied components of
the social systems to identify and recommend changes to better support the
business objectives.
Among the key responsibilities of the Business Change Manager are to:
 Assess the organization’s readiness for change;

 Position the organization for change;
 Develop enterprise-wide communication plans and programs.
Phase 4 - Deployment
Currently it is not known who the first client will be. The deployment team will be defined
when the first Client is known.
 Server configuration and performance management: workstation, NT server, RS6000

 DB configuration and management
 Network management system
 Software distribution
 Recovery and backup
 Operation procedures per Business Component
 Application monitoring and control
 Help desk
 Inventory management
 Repository services
 Technical services
 Data take on and migration skills
In addition the main activities that would be performed are:
 User Training (using training material developed during GBS project)

 Acceptance Testing
 Load / Volumetric testing
 High availability testing
 ‘End to end’ integration testing
 Build system infrastructure, production environment.
The duration of deployment will depend on the complexity of the implementation, the key
issues are:
 Number and complexity of interfaces

 Data migration / data cleansing
Data migration and data cleansing can delay a deployment. We have known data
migration projects to take up to a year when the data in is in poor condition. Therefore it
is important to prepare during the GBS development project, ensuring the approach and
tools have been defined.
We would treat each deployment as a separate project, following the same quality
processes and procedures already described in this proposal.
The length of time a deployment will take depends on the complexity of the
implementation, i.e. whether there is data conversion, new products are being added,
etc.
Progress Control & Monitoring

This section describes the procedures at a steering level and also at a detailed level for
the aspects of Program progress control and monitoring.
This section is divided into two parts:
 Program steering and control
 Procedures and automated tools
Program Steering and Control
The process for progress control of the Program, operates at a number of levels. These
different levels are listed below:
 Board Level (monthly)

 Executive Level (monthly)
 Management Level (weekly)
 Support Level (weekly/daily)
All progress reporting on the program is carried out through the Program Office.
Progress is compiled and reported upwards:
 Project Managers to the Program Manager

 Program Manager to the Accountable Executive
The basis for reporting progress is achievement against the program plan. Each project
in the program portfolio will have specific milestones or checkpoints in it. These are
aggregated for use at a program level. A milestone is a significant event in time, delivery
of a specific goal or completion of a deliverable, which will provide evidence that the
program is proceeding satisfactorily and allow a decision to be taken on whether or not
the project should proceed to the next stage.
Board Level
At present the <Client> Program Manager reports to the Steering group on a

regular basis. Should this continue, a review of the information to be reported will
be carried out at the start of the Program. The items for discussion here would
typically be:
 Major milestone or checkpoint reviews

 Reviewing the program returns
Executive Level
There is a need to review the program in the context of the business benefits
being delivered for <Client>. This will be done using the Steering Committee that
will meet monthly and consist of the Executive Sponsor, all Accountable
Executives and the Program Manager. The items for discussion in this forum
would typically be:
 Progress towards Major Milestones or Checkpoints

 Operational business risks
 Benefits Management
 Summary Level Risks and Issues for the program
 Resources.
Management Level
There will be a need to monitor progress within project teams and consolidate
this to program level. Individual projects will have weekly meetings attended by
senior business users from the areas involved, the team project manager, and
the benefits manager and key members of the team. Other colleagues may
attend on an ad-hoc basis through the lifecycle of the project. The meeting will
report on:
 Progress against milestones

 Summary of actuals vs. variance against budget of cost and man-days
 Resourcing and training
 Variations or changes to benefits
 Project risks and issues for management attention
 Time to completion and outlook regarding future progress
 Scope changes
These reports will be consolidated up to program level by the Program Office for
the Program Manager and circulated to the Executive team.
If there is slippage against the plans, steps will be taken to regain lost time or a
decision made to replan. If it is not possible to regain the slippage, the impact on
the target date must be assessed and if necessary discussed with the
Accountable Executive. This may lead to a benefits review.
Part of the planning process will be to identify the Critical Path for the program.
Any slippage on tasks on the Critical Path will be reported to the Program
Manager
Support Level
The activities monitoring progress and control in this area are undertaken and
administered by the Program Office. Meetings for the Program Office with the
Program Manager will take place weekly. The Program Office will collect and
administer data and information on:
 Project plans
 Risk, issue and change logs
 Slippage
 Timesheets
 Budgetary and cost information
 Project documentation
 Project progress reports
 Resources
 Training.
Integrated view of Application Development infrastructure
Gartner Group view on Application Development infrastructure:
 By 2000, all effective IS organizations will provide central co-ordination of

decentralized AD activities through an internally managed infrastructure.
 Successful organizations will combine integrated methodology/process management
with best practices in project management, measurements, software change
management, and both design and code reuse.
To deliver the level of program management needed, it will be necessary to establish a
fully integrated environment is required. This is shown in the following diagram which
illustrating the development life cycle and the single, underpinning repository for full
control.
The required environment is shown below:
AD Management & Reporting
Project and Process Management
Business Analysis Change

Construction Testing Deployment
Requirements and Design Requests
Configuration and Change Management
Project Repository
The toolsets which are most appropriate in <Client>’s environment have been mapped
on to the previous diagram as follows:
<Insert Diagram>
The primary goal of the unified repository for all tools is to provide complete impact
analysis of any change.
Change Management & Configuration Management
Change Management Procedure
Objective
To investigate, track, evaluate, and dispose of variation requests to approved

project plans. Changes will impact at least one of the following: scope, schedule,
cost, deliverables, work effort or resources. To provide an effective system for
receiving, logging, evaluating, auctioning and implementing, and auditing
Variation requests received throughout the project life cycle.
Change requests are raised to propose corrective actions that change the project
and/or program planned deliverables in terms of:
 Scope
 Duration
 Quality
 Cost
Each Change request requires a formal change plan to effectively implement the
change in a coordinated manner. Not every Change Request will necessarily
result in an action, but a thorough evaluation of the implications of making, or not
making a change, will be made.
With reference to deliverable quality in particular, changes may be raised to

improve any of the following whenever relevant:
 Usability
 Maintainability
 Adaptability
 Reliability
 Portability
 Security
 Performance
 Understanding
 Accuracy
Change management is key in controlling any project. In a program of this type it
becomes critical. Change Requests will be raised for a variety of reasons and
from many sources. The challenges are:
 Log changes in an organized and reliable fashion

 Assess the impact and cost of change
 Identify and record all of the components changed
 Manage multiple versions and configurations as changes are integrated.
As the diagram below illustrates, change management crosses the entire
program life. The recommended tool – Deliverables Manager –supports change
management and control.
<Insert Diagram>
The following flowchart shows the intended operation of this procedure. Step
descriptions are provided below.
Step One: Raise Change Request
Complete a Change Request Form for each change being raised. The Change
Request might be raised by either the Business and/or the IT teams.
A Change request is generated under the following circumstances:
 When there is a requirement to change something which has already been

accepted; and
 When an initial estimate of the effort and cost required to change affects the
defined plan scope, duration, deliverable quality, or cost.
Observations and Issues recorded may trigger Change requests.
Responsibility:
Sales Business and IT Review Group
GBS Program Manager
Delivery Manager
Integration Manager
Step Two: Log Change Request
A copy of each Change Request will be reviewed by the Sponsor and IT Project
Manager. File the Change Request Form in the project Change binder.
Responsibility:
Project Manager
Delivery Manager
Integration Manager
Step Three: Evaluate Change Request
Each Change Request should be assessed according to:
 Accepted for investigation

 Rejected for investigation
 Accepted for investigation without cost
If Change Request is accepted for implementation without cost, proceed to

Implementation. If Change Request is accepted for investigation, proceed to
Impact Analysis. Update the Project Change Form and the project Change
binder.
As a guideline, enhancements or changes requiring less than half a day's effort in

all can be implemented informally. However, these may be monitored in the case
of delays to indicate the overall effect on the time and budget estimates. Update
the Project Change Form and the project Change binder.
Responsibility:
Project Manager
Delivery Manager
Integration Manager
GBS Program Manager
Architectures Manager
Step Four: Produce Change Plan
Upon receipt of signed Change Form, perform Impact Analysis:
 Estimate the workload

 Estimate impact on schedule
 Estimate cost to grant request
Update the Project Change Form and the project Change binder with impact
analysis supporting document.
Each proposed solution is examined for its impact on the project objectives,
scope, benefits, schedule, quality and resources. Changes to scope, timing and
resource use may affect the overall project or other projects, so the development
co-ordination organization should also review the proposal.
The project manager decides which actions to recommend. The proposed

changes are justified in business terms, and the Executive Sponsor and Steering
Committee are made aware of the alternatives and the consequences of not
making the change.
It should be noted that the time taken to complete an impact analysis for a high
impact Change request is not trivial. In these cases, Steering Committee
approval to perform an impact analysis may also be recommended.
Responsibility:
GBS Program Manager
Delivery Manager
Project Manager
Integration Manager
Architectures Manager
Step Five: Approve Change Request
Submit Change Request form to relevant approval authority.
The following roles are entitled to approve the following project Change requests:
High - VS Owner, Project Steering Committee and Program Coordination Group
 Medium - Business Project Manager, VS Owner and Project Steering

Committee
 Low - Business Project Manager and VS Owner
All involved roles must agree each recommended change before it can be
implemented.
The Project Plan is a contract between the team and the Executive Sponsor.
Minor corrections can be done within the original plan. However, the difference
between planned and actual performance may be too great to overcome by
working more effectively. Corrective actions that change the schedule, cost,
scope or deliverables require formal change approval.
The Project Managers and team leaders monitor for warning signs that the
project won’t meet the plan. For example, the team might not be completing
deliverables by the milestone dates, or the deliverable quality might be low. The
cause could be inadequate resources, difficulties in agreeing a design, political
influence, poor productivity, an unreasonable schedule, or inappropriate scope. It
is important to identify the root cause in order to determine the right solution.
Update the Project Change Form and the Project Change binder.
Update project revised baselines to reflect the change in delivery and cost based
on approval memo.
Responsibility:
Project Manager
GBS Steering Group
GBS Program Manager
Program Office
Sales Business and IT Review Group
Step Six: Schedule and Monitor Change
The Administrator generates a Change Management Report on the first working

day of the week. It should contain the following (but not restricted to):
Cover Letter with the name of all addressees
All open Changes (in summary) sorted by responsible person, total number
allocated to this person, and days outstanding.
The Project Change Review meeting should be held on a weekly basis, or as

required. It is chaired by the Project Manager or his/her delegate. Any change not
solved in time and/or impacting multiple projects will be reviewed by the Program
Change Review Committee that should meet once a week or whenever required.
A summary of outstanding Change requests will be produced by the project

librarian prior to each steering committee meeting.
Finally, non-resolved Changes should be escalated at higher level for immediate

action to reach resolution ASAP.
Responsibility:
Project Manager
GBS Program Manger
Step Seven: Close Issue
Update the Change Form and the Change Log.
Responsibility:
Project Manager
Configuration and Change Management
Configuration Management is a key element of an Integrated Application

Development lifecycle.
Configuration Management is to ensure the proper identification and organization

of deliverable items that are part of the system being developed, and to control
and record the changes to these deliverable items, for proper release of its use. It
covers all deliverables over the complete life cycle (from initiation to
maintenance) of the project.
A deliverable is:
 Any object created during the life cycle of a project, be it a source code or a
specification document.
 Any file made available to other users, such as shared libraries or code.
 Any file that is backed up regularly during its development.
 Any executable components that are created by the project.
A configuration management tool enables the automated controlling, monitoring
and communication of the status of any deliverable to the project group, in any
stage in the project lifecycle. It employs a configuration management repository
where all deliverables are centrally stored for a secured yet easy access to all
project information. The tools are of industry standards and closely integrate with
the development and testing tools to be used.
Requirements,
Analysis Design
Project
Initiation Development
Maintenance Testing
Acceptance
Deliverables
Configuration
Configuration Management Tool
Repository
Configuration Management addresses the following needs in managing the

project lifecycle:
Storage Management - involves organizing deliverables and controlling access

to those deliverables. In addition, storage management covers mechanisms for
finding deliverables, such as searching, indexing and cross-referencing facilities.
This enables links among deliverables to inform users that a change made on
one deliverable will have an effect on the linked deliverables.
Version Management - involves recording the changes made to a deliverable

throughout its life. Details of when, why and by whom each change was made
are retained to provide important audit trail information. In addition, version
management allows retrieval work on a particular version of a deliverable.
During the development cycle, more than one user may need to work on a
deliverable at the same time. This parallel development requires the ability to
branch a version of a deliverable and later merge the changes into a new version
of that deliverable.
Version Management also involves controlling and tracking the changes made to
a project as a whole. In addition, it allows accurate identification and retrieval of
all the deliverables used for a particular version of the project at any stage.
Change Management - Managing changes to deliverables involves initiating and

progressing a change request, either to fix a bug or to make an enhancement.
Details of a change including its analysis, estimated effort and assigned user are
recorded to help manage the changes being made to the deliverable and to the
project.
In addition, change management enables impact analysis, so that a full impact

analysis of a change request can be determined before actually implementing
any changes.
Build and Release Management - Building a software product can involve

compiling and linking the product components. Build support helps identify what
version of each component should be used to build the product. This support
ensures the correct version of each deliverable is used to build a specific version
of the product.
During the integration-testing phase of the development cycle, there may be a

need to rebuild the product several times to incorporate final changes. Build
support helps avoid building a version of the product that does not include the
required changes or the required components.
Reuse Management - involves the recycling, publishing and reuse of

development assets. Reuse management provides a mechanism to publish
reusable deliverables, so users can quickly find reusable deliverables that meet
their needs.
In addition, reuse management provides a mechanism for sharing reusable

deliverables and optionally using later versions of those reusable deliverables as
they evolve.
Importance and Benefits
Configuration Management introduces these key benefits to the project:
 Control of project deliverables - eliminates wasted time and the frustration of

searching for the right versions of the information needed. It provides facilities
for controlling deliverables and avoiding configuration errors, which increases
productivity and quality.
 Secure storage - provides a safe yet accessible environment to improve team

and organization collaboration. It provides a scaleable architecture that can
be utilized as the project group's size increases.
 Accelerated project timescales - A more efficient work environment is created
and driven by both recycled deliverables and engineered reuse.
The importance of Configuration Management and the use of Configuration
Management tools may be summarized as follows:
 A consistent and standard approach is implemented across all stages in the

project lifecycle, regardless of hardware and software platforms.
 Production and development failures are reduced.
 A standard toolset will enforce strict adherence to the defined management
process.
 Software and non-software items are managed as a whole.
 Component changes are managed together as a 'change package' rather
than as separate items.
 Components are versioned, allowing historical instances to be easily
recreated.
 Source and object integrity is guaranteed, ensuring that source is never lost
and that the source you see is definitely what's being executed.
 Approval may be enforced at each stage to allow controlled promotion of
changes through the life cycle
 A guaranteed inventory is maintained allowing accurate and efficient impact
analysis to be performed, i.e., "If I change this component, what else must I
consider?"
Configuration Management Approach
A Configuration Management tool will be used for the management of

deliverables in this project. < The tool you will use.> This tool satisfies all of the
management needs for the project life cycle. It has a comprehensive set of
facilities for Storage, Version, Change, Build/Release and Reuse Management.
The tool will also be used to control all deliverables in all the development and
testing stages throughout the project. It is essential that a Configuration
Management Framework and a comprehensive Configuration Management Plan
be created to provide a view on and detail how these development and testing
environments must be set-up, the processes and procedures involved in moving
deliverables between environments, etc. Once the Framework and Plan are set-
up, the Configuration Management tool can be tailored to suit the process.
Configuration Management will cover the following areas:
 Development Environment Structure/Configuration

 Test Environment Structure/Configuration
 Strategies and Procedures for the Turnover of Application Systems from the
Development Group to the Configuration Management Team to the
Integration Testing Group
 Version Control for the Applications
 Installation and configuration of software
The diagram below shows the role of Configuration Management between

Development and Testing teams.
<Insert Diagram>
Integration
The overall approach to integrating new software releases into the legacy recommends
a release strategy and stringent testing. This section focuses on the technical roles and
process control environment required to support full integration over time.
Integration of a New System into the Production Environment
A key activity in the Integrated Application Development lifecycle is the introduction of

the new or modified system into the production environment. This activity refers to
transition from acceptance testing to the production environment.
The list of detailed procedures around this transition will be developed as a part of the
procedures for Configuration Management.
It is important to clearly specify the roles and responsibilities of all involved parties, as
well as possible organization structures to complete the Integration successfully.
The transition plan is required to introduce a newly developed system into the production
environment. Steps required to specify the transition plan are outlined below.
1. Ensure that roles and responsibilities of all involved parties are clearly defined:
 Architects: business, technical

 Project Managers
 Change Managers (responsible for transition)
 Operation Managers
The relationship between these four key roles is shown in the diagram below:
Programme leaders Project Mgr

 owner of the big  delivers functionality
picture  acceptance test
 identifies projects (functional, installation,
 specifies transition operations/SLA, load)
plans
Change Mgr Operation Mgr

 manages changes to  runs current
operational infrastructure business systems
 executes transition plans  help desk
Support Operation
Technical Services
2. Technical Services Support – organization structure and responsibilities (example)
Organized around Technical Domains Responsibilities for all technical
(areas of expertise) domains
OLTP and OLAP (MF, UNIX, DBA) Actively maintain Technical Architecture
documents
Middleware (NAME OF TOOL, For every application installed:
Conductor, MQ Series, Copernicus, Volumetrics (planned, actual), Cost
AWD) Analysis, TCO
Security TA diagrams: physical, logical,
Office automation Application architecture
Network Sizing, performance models, capacity
External interfaces and Internet planning, benchmarks
Operational procedures
Enterprise management and control Skills and organization structure
Development, testing management
Configuration management
3. Technical Services Operation – organization structure and responsibilities (example):
Organized Business Domains And Responsibilities For All Business
Physical Locations, Like: Domain
Data Center Runs operations execution of
operational procedures
Disaster Recovery Site Actively maintain:
Offices Maintenance and support agreements
Agents Unified operational procedures
Bill of Material
Hardware
Software
Operational metrics, SLA
4. Establish technical repository which must have following characteristics:
 Support versioning
 Allow creation of explicit dependencies between documents
 Support change management; change ticket can not be closed without resolving all
dependencies
 Maintain responsibilities and organization structure
Recommended primary tool: <Name of Tool>
Risks & Risk Management

Overall Risks
Changing Priorities
Probability Effect
Medium Medium
Description: The Client’s requirements may differ from the specification given by
<Client>’s business experts.
Risk A componentbased development approach allows changes with
Management minimum impact.
The Regular Review of the Transition Plan allows changing scope and
priorities to be managed as a matter of course.
Define and implement a change management process at the outset of the
Program.
Unenthusiastic
Business Staff
Probability Effect
High High
Description: The logical architecture not reflected in the physical design because the
logical architectures group and physical architectures (e.g. DBAs) group
report to different line organizations.
Risk Ideally manage the logical architects and physical architects as a single
Management team.
As a minimum very close communication is required between the two
teams. Potential use of JAD.
Relationship
Probability Effect
Medium High
Description: The Technical Support processes not aligned to deliver.
Risk Assign a technical support project manager who is responsible for:
Management  Ensuring the ITS support processes are aligned to the delivery
timescales
 Coordination of all ITS staff required for the GBS project
The ITS project manager would work as the project management team.
Integration
Management Probability Effect
Medium High
Description: Poor integration management results in a failure to deliver the program.
Risk Ensure an Integration Manager is appointed who has a proven track
Management record in integration of large complex programs.
Staff
Unavailable
Probability Effect
Low High
Description: The large number of staff required for this program are not mobilised
effectively thus compromising the aggressive program timescales.
Risk <Company> has a tried and tested resourcing process for staffing large
Management programs or projects. This process has already started to provisionally
identify the right resources.
In addition, the key <Company> staff used in the first phase of the
project will continue into the main project.
Scope Creep
Probability Effect
Medium High
Description: The business requirements change frequently and in an uncontrolled
manner, thus affecting the delivery dates for the program.
Risk Ensure that there is a welldefined and implemented change management
Management process which ensures that all the parties involved in the program
understand the impact and cost of any proposed changes.
ITS
Accountability
Probability Effect
Low Medium
Description: ITS project management does not have program accountability.
Risk Ensure that an ITS project manager is appointed who is clear on his/her
Management role and accountabilities.
Poor quality Probability Effect

staff
Medium High
Description: The right business resource is not available.
Risk Ensure that a good staff selection process is employed to select both
Management <Company> and <Client> staff for the program.
Poor (slow) Probability Effect

procurement
process Medium Medium
Description: Procurement process
Risk Tried and tested in other similar environments.
Management Test early at <Client>.
Visit other NAME OF TOOL sites.
Different
knowledge Probability Effect
levels cause
slow start
High Medium
Description: Different levels of knowledge and understanding of the project
objectives could compromise program delivery timescales.
Risk Implement a good program startup / kickoff program.
Management Ensure that there is good induction process and training plan for all new
program staff.
Analysis and Design Risks
Poor Analysis Probability Effect

Medium High
Description: Unable to obtain all the necessary information because of the proprietary
nature of CustomerOne and other proprietary systems.
Risk Ensure there is sufficient business users to provide the necessary
Management information.
Poor Design
Probability Effect
Medium High
Description: Poor design of either Application, Technical Architecture or Database.
The design of any application is important for any application
development, but increased importance is added when following a
component based approach.
Risk Ensure that staff who have a proven track record in design are available
Management to the program.
Introduce a quality control regime (using techniques such as structured
walkthroughs), supported with Risk Reviews.
Build and Deployment Risks

Data Conversion
Probability Effect
Medium High
Description: Client is not willing to commit until GBS system has been completed.
Risk Ensure that the component release schedule is closely linked to the
Management <Client> sales plan.
Release
implementation fails
Probability Effect
Low High
Description: Change in regulatory requirements.
Risk Ensure that requirements are defined by the business and defined as
Management change controls.
Post Deployment and Warranty Risks
Applications not
accepted
Probability Effect
Medium High
Description: The business users do not like the new systems; the Program fails to
deliver the expected business benefits.
Risk Ensure that business users are part of the program and project teams
Management throughout its life.
Use the SignOff procedures correctly.
Demanding Probability Effect

SLAs
Medium High
Description: Diversity of the deployment platforms.
Risk Ensure that the service level agreement is defined and agreed early and
Management considered during the application, technical architecture and database
design stages.
Poor Support
Probability Effect
Low High
Description: The required support levels are not met.
Risk Ensure that the support levels are clearly defined in the program,
Management identifying the required roles and responsibilities of <Client> and
<Company> so that the necessary required support skills are planned.
Poor Usability Probability Effect

Low Medium
Description: The business community is unable to use the application as intended
because of poor training.
Risk Ensure that a well defined, implemented and repeatable training program
Management is put in place to enable the business users to understand the capabilities
of the system.
Ensure that the necessary support is available, particularly during the
early stages of system use.
Poor Usability Probability Effect

Low Medium
Description: Difficult to work with other industry players.
Risk Ensure that all players understand the value to them.
Management Ensure that interfaces are clearly defined and managed.
<Company> Credentials
Experience
Management of Large and Complex Programs
 <Company>’s program and project managers use a standard industry-

acclaimed method, which forms the basis of our successful track record. It
incorporates Risk Management, Issue Management and Quality
Management.
Integration of Business and IT
 <Company> employs a sophisticated range of techniques, such as ‘MOST’,

to ensure that potential solutions are business focused and which take into
account people, process, technology and strategy.
Partnering With Our Clients
 Our aim is to establish a partnership model with our clients in such a way that
transcends the boundaries of traditional customer/supplier relationships. This
is extremely important to this program of work, given the commercial
reusability of the <Company> solution. Our objective is to be considered as a
natural extension to the skills and capabilities that already exists at <Client>.
To that end we ensure that an appropriate program of knowledge transfer is
built into all of our client assignments. <Company> is committed to ensuring
joint success by underpinning commercial agreements with appropriate
risk/reward mechanisms.
References: <Name of client references>
Use of Best Practice Methodologies and Tools
 For almost two decades, <Company> has been at the forefront of the IT
industry in terms of developing methodologies that allows staff to work in a
consistent, repeatable and auditable way.
In-depth Business Knowledge
 <Company> has an extremely successful global Utility practice which has

been operating for over ten years (around 25% of global revenue is derived
from this vertical). One of the key benefits of this global practice is the
extensive knowledge and first-hand experience of working with utility
organizations that have already undertaken much of the rationalization and
gone through many of the challenges currently facing the utility market.
 References: <Name of client references>
Right People for the Job
 A global approach to recruitment, training and development ensures that the

‘<Company> way’ is the accepted way of working for all staff on client
assignments. <Company> takes great care to ensure that skills, experience,
attitudes and behaviors are aligned closely to the needs and expectations of
clients.
Capability to Excel Across All Aspects of the Systems Development
Lifecycle
 <Company> has the requisite experience, skills, manpower and development

environment to deliver fully in line with <Client> expectations and
requirements.
Specification and Design
Use of recognized best practice
 Methods and tools used by thousands of organizations world-wide.

Innovative solutions
 Driven by business experience. Ability to learn from one industry or segment

and apply those principles elsewhere.
Commitment to delivering a business oriented solutions
 <Company>’s focus is on delivery - solutions not reports, involving the

business and user community, thinking from the right, delivery of business
benefits paramount.
Consistent approach to all aspects of project management
 Project Management (plans, resources, deliverables, costs, quality, issues

etc) using highly experienced project managers Partnerships with Tools and
Solution Suppliers
 Valuable commercial and technical partnerships are in place with many of the
world’s leading IT companies.
References: <Name of partner references>
Skills Transfer
 The mentoring of client staff and provision of skills transfer is an established

and crucial aspect of the way we operate.
Build & Deployment
Respect for Legacy Systems
<Company> believes that a critical success factor for large scale IT Programs is
the way in which the new solution integrates with or interfaces to Legacy
Systems. This includes decommissioning of old systems, wrapping and bridging,
data cleanup, data conversion and data loading.
Use of Tools
Widespread use of sophisticated tools.
References: <Name of tools>
Post-Deployment Warranty Support Services
Support for large scale operational systems
<Company> has supported the mission critical operational systems of many

major clients in line with <Client>'s expectations.
References include <Name of client references>
Support for applications developed by <Company>
<Company> has provided a complete back-up service for individual applications

that we have built on behalf of clients.
Honoring client commitments
In a small number of cases, unexpected problems have caused certain projects

to overrun in terms of cost or timescale. Whenever this has occurred, we have
honored our commitments to our clients, even where this has been at significant
cost to ourselves.
Product Management
One of the key benefits of the <Company> is the commercial reusability of the system
and many of its components. Therefore, unlike many solutions the application will have
its own "product life cycle" post delivery. There are a number of key areas to this process
that need to be controlled and managed.

Generic Billing Solution Proposal

Uploaded by

Copyright:

Available Formats

You might also like

Generic Billing Solution Proposal

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

Generic Billing Solution Proposal

Uploaded by

Copyright:

Available Formats

<Client>

Generic Billing Solution Proposal

Change Management Procedure....................................................................49

By <When>, <Company> agreed to deliver the following to <Client>:

 Scalability – The prototype’s architecture is designed to operate on multiple

 Multi-Product Capability – The prototype design supports the addition of new

 Customer-Centricity – The prototype’s web interface demonstrates the ability to

1. Flexibility - Ability to easily interface into legacy and future systems

2. Scalability - Capable to grow in line with business demands

3. Re-usability - Maximum reuse to support new customers

4. Cost Efficiency - Creative commercial propositions; life cycle costs

5. Timely - Pace to build and deploy

Fundamental to our consideration has been the determination to structure a program

The Generic Billing Program is essentially a major change program. <Company>

<Company> is proposing to assist <Client> with the development and building of a

<Insert a Graphic Depicting Solution Scope Here>

The management of the following processing in relation to calculation of usage:

The management of the following functionality:

 Receiving payment from different sources, reformatting it to a common format

 Creating a payment plan that involves the estimation of consumption for a

Sales Agent Management

The solution architecture will support future integration of additional components.

 Extensions of the business needs to incorporate <What>.

To take the opportunity of web-based digital business opportunities, business

<Insert Functional Scope Diagram>

 Set up new account

The project will include:

Program and project plans will be created as a baseline against which to

 The installation and definition of the necessary standards

Typically a large program is broken down into manageable components to

 Application and technical integration

<Insert Testing Diagram Here>

Integration testing is performed on a series of inter-related components to satisfy

Stress and Performance Tests

Architectural components are load and stress tested individually and as a

User Acceptance Tests

Operations and Commissioning Tests

<Company> recommends that the scope of this implementation utilizes the

Creating business impact is not achieved by delivering new technology. Impact is

This addresses the successful implementation and operation of technology to

number of concurrent components such that it remains manageable. There are

The following diagram illustrates these areas:

Programme Start-up Plan

Programme Baseline and Environment

GDC Set-up Complete Complete People

Management Operational Social Technical

The following sections describe these areas of activity in more detail.

Phase 1 – Program Start-up

 Confirmation of roles and responsibilities

 Equipping the team

 Producing the Terms of Reference

As part of start-up, we plan to inventory all the deployment components and

Phase 2 – Program Baseline and Environment Set-up

Setting the Development Agenda

Evolutionary Deployment Model

Basic Functions Configuration

The approach in setting up the Basic Functions is to determine the basic

 GUI (look and feel)

 Oracle Basic Functions