Usps Pay Scale GOV950 Government by rfu13167

VIEWS: 171 PAGES: 50

More Info
									GOV950 Government Application Development

Joe Mondile, PSI Systems, Inc.
Senior Programmer, 650-321-2640 x118
June 20, 2003
Conference Topic Summary

     This session reviews different approaches and applications used in a variety of
      state and federal government environments. Case studies provide a view into
      applications in the judicial/court room arena, academic world, and the
      engineering/facilities space.
Government Apps
Software has helped the Government reach their customers

   Federal Government
        Civilian (US Postal Service, EPA, NIST)
        Military (goes without saying, Navy Bases)
   State
        Universities (Administrative and Student relations)
        Actual Government Entities
   Local
        Counties (Courts, Public Works)
        Cities (Permits)
        Mixes (City and Counties)
   Government can just be the regulator for an application
Government Apps
Products and Services

   Federal
        US Postal Service (Consulting Services and EM Products)
        Navy (Services)
        Endicia (regulated)
   State
        University of California - Berkeley
        MedPro for Cal State, UC-SD, SW Missouri, U-Mass, U-Penn, Montana,
        SSI serving several governmental agencies.
   Local
        City and County of San Francisco Trial Courts
        Santa Barbara Public Defender
        Santa Clara County Pre-Trial & Weights and Measures
        San Mateo County Human Services
Government vs. Private Apps
How are they different?

   Mission (why develop the application?)
   Performance Measures
   Accountability
   Structure and Rules
   Organizational Process
Government vs. Private Apps
How are they similar?

   Methodology
        Development Methodology
   Users are users and interfaces are interfaces
        Should not take short cuts
        Keep high expectations
   External Factors and Interfaces
Government App. Features

   Why develop application?
   Is application needed by (examples):
         new rules
         getting information to public, service body
         reducing cost or wait times by letting users input data
         clear list of defined features
         more typical of government applications
   Is application wanted (examples):
         Head of organization orders web application
         no clear definition of features
Government App. Features
Performance Measures

   How to decide the outcome was achieved
   Can define success or failure of a project
   Mission of application can be different
        Serving the public
        Not tied to profit (good and bad)
        Regulated by government to serve a customer
   Meeting some agency guideline.
        Example, leases need to be closed in 30 days
        Prompt Payment Act (14, 30) or else pay interest
Government App. Features

   They have to provide services and information as required by
   Mission motivates innovation with software applications
   Budget based rather than profit motivated (private sector)
   Accountable to the public
       Tax Payers
       Judge
   Watch groups
   Stricter Outcomes (e.g., privacy)
Government App. Features
Structure and Rules

   Structure in place to handle the rules
   Much more structured in approach
   There usually is a roadmap
   ‘Champions’ help navigate process
       A Champion is an internal resource that will represent you and hand hold your
        requests. They are someone you need to find.
   Use the rules to get around the roadblocks
   Rules can conflict with one another
   Live by mission and goals
Government App. Features
Organizational Process

   Meets the rules
   ‘Champions’ help navigate the structure
   Organization Culture
       Use the culture to document requirements
   Process can be your friend
       Great testing if process is in place
       Set up the goals
       Make it someone’s job
   Process can be an endless loop
       Process to solve a failing process instead of having the right people in place
   Process for different pieces of the puzzle
       Procurement & Contracting
       Development
       Maintenance
       Define and assist in setting up
Development Methodology

   Requirements
           Understand the business carefully
           Get user input, JAD sessions
           Business rules too
   Database Design
           Use modeling tools
   Data Migration (do not underestimate)
           Very visible
   Application Development
           Testing, Training, online help
           Standards
           Prototype, let them touch it
Methodology Approach
Rapid Application Development - RAD

                                   and Staff

            & Design

                       Database                   User

   Watch out for the stereotype
       Not true but does exist
       Professionals (USGS, Engineers, doctors, attorneys, etc)
       It’s a way of life (surgeon without the insurance problems)
       Not focused on profits
   Users are users
       Ease of Use
       Good interface
       Makes job more efficient
       All the stuff that we should do
       We have seen “bad” applications because they were made for the
        government. Gives us a bad name.
External Factors

   Seem to always service some other entity
       Data warehouse
       Other agencies
       Technical Data Interfaces
       Affect other departments
   Conform to external rules
       Interagency agreements (IRS Interfaces, State data needs)
       Regulatory Issues
Case Study – UC Berkeley GradLink
GradLink Overview

   GradLink is a Graduate Division data management system
        Tracks academic progress for graduate students
        Manages graduate awards and grants
        Manages associated financial accounts
        Creates Graduate Division reports
        Import/exports data to other university systems
        And much more…..
Case Study – UC Berkeley GradLink
GradLink Mission

   Mission
        Integrate disparate systems
        Centralize data for Graduate Division
        Enhance student services
        Solve Y2K issues
        Conform with university rules for security, privacy, accounting and reporting
        Prepare for web enabled system
        Leverage Graduate Division programmers
   Oracle Database
   PowerBuilder Client
Case Study – UC Berkeley
Challenges from Government Context

   Performance Measures
        Security, external interfaces, assisting students
   Accountability
        to students and deans, university system
   Structure and Rules
        Language very important
        Live by mission and goals
        Very complex rules
   More Process
        Took a while to get used to (many meetings and meeting minutes)
        Provided framework for decision-making with stakeholders
        Produced reliable documentation
        Motivated users to be fabulous testers
   Development methodology reinforced by strict process
Case Study – UC Berkeley
Challenges typical to any application

   Users are users and interfaces are interfaces
         Should not take short cuts
         Keep high expectations
         Leap in technology had users redesign UI
         Users needed to re-think how they view and enter data
   External Factors and Interfaces
         Datawarehouse, Payroll (PeopleSoft), Registrar
   Graduate Division Programmer training was key part of
Case Study – City and County of San Francisco
ACES Overview

   ACES is used by the Criminal Trial Courts
       Downloads and uploads information from central data warehouse
       Serves all the trial courts
       In use in the court room live
       Servers the entire calendar
       Prints all relevant forms (over 10) live!
       Auditing and reporting
       Two generations of software
Case Study – City and County of San Francisco
Trial Courts

   Mission
       Automate the manual typing of forms
       Reduce the 10 week backlog
       Automate the uploading of data
       Receive some sort of data feed
   Performance Measures
       Reduce Redundancy
       Reduce amount of time
       Reduce labor
       Introduce some level of tracking and repeatability
       Need Reliable process
   Accountability
       Judges, Unions, Public, County
Case Study – City and County of San Francisco
Trial Courts

   Structure and Rules
       Legal
   Process
       Quite direct
       Contact at presentation
   Methodology introduced by PSI
   UI
       Based on PSI
       Production Based
       Navigation essential
       Shortcuts everywhere to deal with Court speed
       This is not the movies – its fast!
   External Factors and Interfaces
       CMS
Case Study – USPS FMSWIN
FMSWIN Overview

   FMSWIN is an extensive Facilities Management System
       40,000 post offices, $5 Billion budget
       Tracks all facilities and projects done on them
       Leasing and Purchasing of buildings and spaces
       Historic & Federal Facilities
       All Real Estate activities imaginable.
       Financials, Accounting, payments
       Contracting, Work Orders, material, services
       Environmental, Compliance, Inspections
       Interfaces to USPS Data Warehouse and other federal systems (IRS)
       USPS.COM
Case Study – USPS FMSWIN
Challenges typical to any application

   Mission
         “Manage” the volume of post offices
         Efficiency
         One of the largest PB deployments at the time
   Performance Measures
         Each subsection had its own measures
         Leases based on time to finish and cost comparisons
         Project Schedules
         Number of inspections
         Also had an EIS reporting section
   Accountability
         To management
Case Study – USPS FMSWIN
Scale is an issue

   Structure and Rules
        Organized in several levels nationwide
        Very large distributed organization
        Input from many sources
   More Process
        Facilities professionals
        Internal IT sometimes had its conflicting processes
        Challenges to keep projects on target
   Development methodology
        Database implementation controlled by IT
        Development methodology and UI nitiated by development group.
Case Study – USPS FMSWIN
External Challenges too

   Users are users and interfaces are interfaces
        Professional User Base
        Power Users
        Several interfaces and navigation techniques
   External Factors and Interfaces
        Date from and to central mainframe
        Financials to pay contractors
        IRS for contractor compliance
        Had to satisfy customers and at times other departments
Case Study – USPS & Envelope Manager
Envelope Manager PAVE/DAZzle Overview

   EM Pave is a Bulk Mailing Program
        Certified by the USPS
        Sold to commercial, government and USPS
        Design a Mail Piece; graphics
        Address Validation via Dial-A-ZIP
        Database & List maintenance
        Discounts on postage
        Conforms to the USPS rules.
        Mailers get a discount when you reduce their work
Case Study – USPS & Envelope Manager
Challenges typical to any application

   Mission
         Product to conform to USPS rules
         Commercially sold
         Certified by the USPS
   Performance Measures
         Needs to produce conforming reports
         Meet goals otherwise customers will not get a discount
   Accountability to USPS certification and buying customers
   Process, Structure and Rules
         Simple for development
         Detailed and complicated for approval
Case Study – USPS & Envelope Manager
Challenges typical to any application

   Simple Development methodology
   Users are users
         Bulk Mailers are power users (fast)
         Direct Mail Marketers prefer a friendly UI
         DM is complicated
         Two products, one wizard interface and one power users
   External Factors and Interfaces
         Several central data sources for rates, delivery confirmation
         Address Validation Servers (ZIP+4). XML Service
   Knowing how to deal with approval process is key.
         Remember to always follow-up
         Do not assume something is done.
Case Study – USPS & Endicia
Endicia Internet Postage and Shipping Overview

   Endicia is a service to print Internet Postage and Shipping
        Certified by the USPS, NIST, Independent Labs
        Sold/licensed to and used by commercial, government and USPS
        Web based XML to the USPS Web Site
        Also Windows based client
        It prints money so heavily regulated.
        Major security hurdles
        Heavy use by eBay type sellers, catalogs, shippers
        Produces all forms of USPS Postage and special services
        Stealth Postage is cool, needed special approval
        Data Warehouse
        Check and
Case Study – USPS & Endicia
Highly Secure

   Mission
        Print Internet Postage
        Desktop Shipping using the Internet
   Certification, rules, structure
        Independent NIST Labs
        FIPS 140
        It prints money!
        Federal Register Process
        High Barrier to entry – only 3 companies
        Accountable to USPS
   Process
        In Place to continually conform to rules
        Monitor and Audit
Case Study – USPS & Endicia
Highly Secure

   Development methodology adheres to strict process
   Users are users and interfaces are interfaces
        Wide range of users
        eBay Sellers
        Fulfillment houses
        Corporations (Enterprise Versions)
   External Factors and Interfaces
        Continuous Data to USPS financial and licensing systems
        Delivery Confirmation
        Account Maintenance
        Server Farm
   Key aspect is having
        Highly educated developers
        Talented team
Case Study - MedPro
MedPro Software Overview

   MedPro is a Student Health Center Information System
        Manages all aspects of a Student Health Center at Universities
        In close to 40 installations
        UC, CSU, Oregon, Mass, Florida, Missouri, Penn, Montana, Alabama
        Remember when we were students and went to Health Center?
        Integrated Lab and Pharmacy
        Uniquely geared to students and universities
        Demographics, Appointments, Transactions, schedules
        Web Interface for Appointments
        Pharmacy & Lab too
        Insurance, billing
        External interfaces from registrar, to accounting, insurance, from lab
Case Study – MedPro
Commercial Application servicing government

   Mission
        Serve IS needs of Student Health
        Only for Student Health
   Performance Measures
        Efficiency Statistics and accounting
   Accountability
        To students
   Structure and Rules
        Very Simple
   Process is like a commercial Company
   Users are users and interfaces are interfaces
        Users mix of administrators and tech aware students
   External Factors and Interfaces
        Registrar, Accounting, Insurance
   Key is the diverse rules of each campus.
        One product with many personalities
Case Study - SSI
SSI Overview

   SSI Provides Insurance for students
        SSI is an insurance broker working with Universities
        Tracks Insurance policies for students at universities
        Accounting between insurance companies, universities, students,
        Data from campuses and students
        Data to insurance companies, student administrators re eligibility.
        Internal Power User Application
        External Web based for Students and Administrators
        Sybase Success Story
        Flexible Policy creation, administration and reporting
Case Study – SSI
Challenges typical to any application

   Mission
         Provide Medical Insurance to students
   Performance Measures
   Accountability to universities and insurance companies
   Insurance Rules but need to also meet campus requirements
   Users are users and interfaces are interfaces
         Users are students, administrators & Power Users. Different interfaces for
   External Factors and Interfaces
         Mostly schedule constraints when rules change
   Keys
         Integrating diverse requirements
         Database driven policies drive the UI and Navigation
Santa Barbara Public Defender - Loco
Loco Overview

   Loco is a Public Defender Case Management System
        Tracks defendants
        Demographics, scheduling, attorneys, charges
        Assists attorneys & administrators in handling case load
        Produces several forms, labels, reports
        Custom Letter Writer
        Adhoc Report Writer
        Two generations of Software
Case Study – Loco
Task automation and performance measurement

   Mission
        Modernize environment
        Integrate all correspondence
        Assist attorneys in scheduling
        Reduce Manual Paperwork
        Y2K compliance
   Performance Measures
        Standardizing countywide statistics per office
        State wide performance reports
        Attorney based workload measurements
   Accountability
        County infrastructure
        Legal requirements
   Structure and Rules
        Did not affect application
        Distributed offices was a factor
Case Study – Loco
Task automation and performance measurement

   Structure and Rules
   Process
        Mostly for internal IT infrastructure
   Development methodology
        Introduced by PSI
        Database Choice was an issue
   Users are users and interfaces are interfaces
        Administrators, Report running, Attorneys
        Training was important
   External Factors and Interfaces
        Confidentiality was key
   Leveraging the database design for several tasks
Santa Clara County – POPS Requirements
Pre-Trial Department Requirements Overview

   POPS requirements for a Pre-Trial Information System
        Jail, Court & Supervision units
        Needed an Integrated System
        Production and Management and Scheduling intertwined
        Same Defendants
        Visio flow diagrams
        Detailed database design
        Internal & External interfaces in batch and real-time
Case Study – POPS
Challenges typical to any application

   Mission
         Integrate system for 3 divisions
   Performance Measures
         Each division had specific measurements that were diverse
   Accountability to Board
   Process changed as players changed!
   Design methodology was not consistent
   Users and interfaces
         Very diverse. Jail Unit production fast (a few hour life cycle). Supervision
          cases over several months.
   External Factors and Interfaces were a challenge
   Very complex bus rules, interfaces and goals
Santa Clara County – Weights and Measures
WMS Overview

   WMS is a project tracking and auditing system
       Used by inspectors to track their site visits and results
       Reporting
       Cab meters, gas stations, grocery stores, products
       Obtained products and audited their contents, volume, meters, regulators
       Collected fees and fines
Case Study – WMS
Challenges typical to any application

   Mission
         Project Tracking tool for inspectors and managers
   Performance Measures
         Measures inspections and tracks schedules
   Accountability
         To management and county
   Structure and Rules
         Based on inspection techniques and standards
Case Study – WMS
Challenges typical to any application

   Process was simple based on user interaction
         Requirements look good but were not complete
         Face-to-face was great!
   Development methodology was based on County IT group
         Face-to-face again!
   Users are users and interfaces are interfaces
         Interface was based on County standards
         Users were administrative and engineering inspectors
   External Factors and Interfaces
         Basically was centered on reports and accounting
   Worked mostly with one or two users
         Production changes since testing did not include a good enough user sample
         Easy to adjust
         Personal Interaction was key
San Mateo County – Health & Human Services
Project Overview

   PSI simply produces Adhoc reports
        Existing Application developed thru consortium
        Our project was to write reports
        Check data migration
        Create invoices
        Many reports for daily work
        Financial summaries
Case Study – San Mateo Reports
Adhoc Report writing

   Mission
        Collect overpaid funds
   Performance Measures
        Measured on collections
   Accountability to board, customers
   Process was user friendly
   Users and interfaces: Adhoc reports
   External Factors and Interfaces
        Had to adjust when dB was changed
   Challenge was to efficiently write reports for an unknown
    database and adjust with the changes and new requirements.
Conclusions & Lessons Learned
Work with or Avoid

   First decide how you want to interact
       Product, Service, Consulting
   Measure the business opportunity
   Be ready to work with Purchasing/Contracting
   Define a reasonable timeline
   Partner
Conclusions & Lessons Learned
Government nuances can leverage your methodology

   Understand their mission – it is important
   Use organizational process to document and verify
       get to know the individuals and interactions
   Use Performance Measures to test; was the mission
   Accountability should increase testing budget
   Structure and Rules should help to document business rules
   Structure the development to reach the incremental
    measurable goals
   Each agency is unique, users are important
   Understand the data flows – in and out.
Business Opportunities

   Services
       Consulting
       Maintenance
       Training
   COTS Commercial of the shelf products
   Products sold to the government
   Commercial products regulated by the government
       Drugs (legal that is)
       Tax Software (TurboTax, TaxCut)
       Internet Postage and Shipping (Endicia)
   Lots of stats why you should do business with the
Contact Information

   Email or call me
       Joe Mondile, Amine Khechfe
       PSI Systems, Inc
       Palo Alto, CA
       650-321-2640 x118
   Input is appreciated
       Critique
       Future Presentations or ideas
       Topics to cover
       Your Experiences

To top