HudsonBanc Billing

System Upgrade
Project Analysis
Aaron Hall
Walden University

Project Analysis Overview

Purpose
Why the company chose a new billing system
over maintaining the older systems
Process
What steps were taken to develop, test, and
deploy the new system
Problems
Where the project experienced difficulties and the
impact it had on the business
Progression
How the situation was corrected and steps to
avoid similar outcomes in the future

Project Purpose
The recent merger, which formed HudsonBanc,
included an evaluation of the two billing systems used
by both banks. Management decided the two
systems should be replaced with a modern Webbased application.
Existing technology was outdated.
Upgrade and replacement
costs were too high.
New system could be purchased
and brought online more quickly
at a lower cost.

Project Process
New infrastructure and software installation took place in
January.
A random sample of 10 percent of the customer
accounts was copied to the new system (Satzinger,
Jackson, and Burd, 2012, p. 439).
The project team
used a partial parallel
deployment and
operation approach.
The systems ran in
parallel for a period of
two months using the
10% sample of
accounts.

Project Process (cont.)

Responsibilities of each system during two month parallel
operation:
Operation

Old System

New System
(only 10% sample)

Record Payments
Compute Billing
Statements
Print Billing
Statements
Update customer
accounts

Manual checking of the sample data was performed to validate

accuracy with the old system.
The data migration occurred in mid-April, and the old systems
were turned off May 1 (Satzinger et. al., 2012, p. 439).

Project Problems
Transaction Load after the cut over date overloaded the
system.
Data entry and customer access slowed.
Payments backed up.

Transaction errors occurred in key areas:

Charge corrections
Credits for overpayment

The system refused to print any information for

transactions more than 30 days old (Satzinger et. al.,
2012, p. 439).

50,000 Accounts identified with errors!

Project Problems (cont.)

Fixing the situation:
Payment back ups and customer complaints:
Development personnel were reassigned to help with the
billing backlog and additional individuals reassigned

Transaction Errors:
Manual updates of accounts containing errors over a six
week period
Functions corrected to perform transactions properly

30-day Transaction and billing restriction:

Software correction and testing began but required more
than a month
Manual account adjustments were made
Billing completed within 30 days

Project Progression
Learning opportunities and the future
Focus on testing
The project included two months of system testing but only
covered some of the units involved in the system
Usability testing occurred on limited functions within the
system

A 10% random sample does

not provide enough of a
base for system testing.
Each use case should be
tested before system
deployment.
Full unit testing should occur
prior to full system cut over

Customer Base
Sample Accounts

Unused Accounts

10%

90%

Project Progression (cont.)

Performance Testing did not occur:
According to Satzinger, Jackson, and Burd (2012), a
performance test, also called a stress test, determines whether a
system or subsystem can meet such time-based performance
criteria as response time or throughput.
Performance testing must be included in all future
system upgrades.
Partial parallel operation was not enough:
Full parallel operation should be used in the future due to risk
reduction, which is especially important for such mission critical
applications as customer service,basic accounting functions, and
most forms of online transaction processing (Satzinger et. al.,
2012, p. 430). HudsonBanc operates in all of these areas.

Final Analysis
Information Systems are critical to the success of the business.
Going live on a new system should not happen until all functions
of the product have been fully tested.
While full parallel deployment and operation may be costly and
complex:
The critical nature of financial systems requires parallel system
transitions to reduce risk
The cost and impact to the business from not employing the
approach has been significant

Performance and stress testing should be a part of every

deployment.
When deploying new systems, assessment of the unknown,
actively quantifying the risk of failure, testing assumptions and
revising expectations to reflect reality, are all fundamental
(Donohue and Gregory, 2000).

References
Donohue, B., & Gregory, S. (2000). How to Manage
Projects that Stop Off into the Unknown. Retrieved from
http://www.techtransfer.berkeley.edu/newsletter/004/projects.php.
Satzinger, J., Jackson, R., & Burd, S. (2012). Systems
analysis and design in a changing world (6th ed.).
Boston, MA: Course Technology, Cengage Learning.