Application maintenance will cost more than cost for initial development. The customers (management and users) deserve explanation on best practices; developers assigned to maintenance should follow same design, build and test practices as those in more "prestigious" roles.

1. Total Cost of Ownership (TCO)
Part One – Maintenance and Change Control
Business Analyst Academy
Department of Water Resources

2. Objectives
2
Business Analyst Academy -Maintenance and Change Control
• Dimensions of Total Cost of Ownership
• Cost to Build
• Cost of People-Driven tasks plus Training plus Network plus Maintenance
• Time to Make a Change
• Why Quality of Design Matters
• Consequences of Delayed Maintenance
• Cheap Fixes are like Duct Tape—they work until they don’t
• Why Cheap Fixes Occur – Training, oversight, not invented here, showing
off
• Service Level Agreements
• When Duplication: Declaring Victory, Accepting Inevitable
• Road Map to Live to Fight another Day

3. What is Quality?
• Single source of truth: know the Database of Record
• Availability – Technology and Administration enable Up Time
• Performance – End to End completion time frame
• Ease of Enhancement – Application design matters over time
• Ease of Upgrade – Ability to replace old products with newer releases
• Compatibility – Works with new Servers, desktops, database products
• Interoperability – Minimize need to rekey data
• Staff have skills, time, and motivation to make reliable changes
• Avoid workaround solutions due to unresponsive systems
• Staff Committed to Using the Solution
Business Analyst Academy -Maintenance and Change Control 3

4. Categories of Maintenance
• Cosmetic
• Not adding functionality
• Ease of Use
• Vanity and Power
• Distract from substantive needs
• Web Page Design and Navigation
• Refinement
• More robust error messages
• Perfective (Functional)
• Lousy term; keep application current with Process, Data, and Decisions
• Usage
• New type of query or report but not modifying rules
• Integration
• Enable sharing data and results with other systems
• Corrective
• Fix defects from missed or mis-interpreted specifications
• Adaptive
• Modifications to stay compatible new products and product upgrades
• Preventive
• Refactor after a bunch of changes made; tune the database;
Business Analyst Academy -Maintenance and Change Control 4
Ask:
How does the proposed
maintenance activity
enhance the Quality of the
overall Solution????

5. DON’T Confuse Maintenance with Defects
• Defects are development shortcomings identified during initial application
development
• There are MANY types of improvements that are NOT result of a defect
• New features: Adding alerts and notifications
• New functionality such as new decisions, new data, new interface
• Perfections and Cosmetic such as Ease of Use and Report layout
• Refinement: more informative error messages; on-line help; ddlb descriptions
• Enhancement – building an integration to another system
• Performance Improvement – Database indexing and organization
• New Shared Service – Adding a shared service capability such as automating workflow,
integrating email generation,
• Defects found in production should be only for 1 in a 1000 occurrences otherwise
user acceptance testing was deficient;
• Budget a warranty to cover defects; do not expect perfections and other
improvements to be covered by a warranty.
Business Analyst Academy -Maintenance and Change Control 5

6. Why classification is important
• Your client is going to make regular requests for
modifications to what the team is doing.
• You want to socialize the proper terms to classify the
type of modifications they want to make.
• During testing, they will identify a range of things they
want changed:
• Screen design
• Report format
• Range of values for a list
• New data items
• New decisions and new business rules
• New functionality and new features
• Each of these is a DIFFERENT TYPE OF CHANGE. None of
them are defects
Business Analyst Academy -Maintenance and Change Control 6

7. Words Matter
• When someone says there is a Defect
• Client hears there is a problem and loses confidence
• Developer hears there is something to fix..no big deal
• Analyst hears there is something to diagnose and provide
guidance
• Guidance
• Every unexpected result from testing is an ITEM
• Analyst evaluates ITEMS to determine the cause and
assignment
• Only assign to Developer if the code didn’t do what the
specification called for
• Anything else Requires Entry to the Change Control Request
Log
• Approval can be delegated for minor changes to avoid delays
• Every change requires recognition
Business Analyst Academy -Maintenance and Change Control 7

8. Why Every Change Requires Recognition
• Changes due to Ambiguity in the Specification
• Highlight in order to help the client participants appreciate
that they can help reduce ambiguity going forward
• Helps the Analyst identify early where else in the
specifications there may be ambiguity to clarify—get in front
of it
• Changes due to client getting smarter about what they
want
• Make it clear that you are responding to their requests
• Any change that is not recognized is not appreciated
• No one appreciates a hand out—”thank you” counts as
recognition
• Keep an eye on scope creep and measure against Minimum
Viable Product
• Changes due to increased confidence in automation’s
potential
Business Analyst Academy -Maintenance and Change Control 8

9. Maintenance Portfolio Management
• Categorize every proposed change during
initial build throughout solution life
• Avoid over-emphasis on cosmetic and
perfective changes
• Keep client eye on adding Decisions, rules,
notifications, dashboard for greater
productivity – not just greater convenience
• Perfections are busy work and at the end
of the year you get further behind in
demonstrating value of the automation
effort
• Also make certain functionality changes
allocated across the major modules,
manage the influence of the overbearing
user
Business Analyst Academy -Maintenance and Change Control 9
Maintenance Portfolio
Corrective
Cosmetic
Functional
Integration
Usage

10. Cosmetic Perfection is the Enemy of Improvement
Powerful Users and Not Always Power Users
Powerful User proposes changes
• Tweak the layout and navigation of the page or
report
• Vanity changes
Danger of Responding to the Powerful User
Functional Improvements deferred while
focusing on instant gratification
Business Analyst Academy -Maintenance and Change Control 10

11. Make Use of the Power User
• Nurture the Subject Matter Expert With
Imagination and Determination
• Find out how they REALLY use the
application
• What are their “work arounds” ?
• Create a “backlog” of requests for new
capabilities
Business Analyst Academy -Maintenance and Change Control 11

12. Why Have a Request BackLog???
• Request Backlog is a good thing
• Not a measure of application deficiency
• A measure of application POTENTIAL
• Aids in preparing your annual work plan
• “Shovel ready projects”
• If there is year-end money you have head start in justifying
getting it
• Always ready with a Budget Change Proposal
• Rebuttal for the long list of cosmetic changes
• Show substantive needs to attract best developers and
analysts
• Keep the Client motivated
Business Analyst Academy -Maintenance and Change Control 12

13. The Maintenance Process
• There is a Life Cycle for Maintenance Changes that is very similar to the process for new
application development
• Change Request
• Analysis
• The Process Model Impacts: What Precedes, what is Changed, what follows
• Priority and Road Map
• New and modified Themes and User Stories; Acceptance Criteria;
• New and Changed Decisions and Business Rules;
• New and Changed Data Model and data definitions
• Design Review
• Testing
• Training
• Verify Documentation Updated
• Release Planning
• Rollout
Business Analyst Academy -Maintenance and Change Control 13

14. Protecting Solution Integrity During Maintenance
Business Analyst Academy -Maintenance and Change Control 14

15. Conclusions
• Maintenance Deserves Same Recognition and New Development
• Applications are a major capital investment
• Deferring Maintenance erodes the application from the inside out
• Keep the Backlog Visible to Keep Sponsor’s Attention
• Portfolio Management: Don’t let cosmetic changes dominate the
effort
• Total Cost of Ownership: Patches are Expensive
• What will it Cost to Replace an Unreliable System?
Business Analyst Academy -Maintenance and Change Control 15