GOV950 Government Application Development

1. GOV950 Government Application Development Joe Mondile, PSI Systems, Inc.Senior ProgrammerJoe@psi-systems.com, 650-321-2640 x118June 20, 2003

2. 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.

3. 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

4. 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, Oregon • 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

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

6. 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

7. Government App. Features Mission • 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

8. 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

9. Government App. Features Accountability • They have to provide services and information as required by mission • 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)

10. 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

11. 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

12. Development Methodology Tasks • 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

13. Methodology Approach Rapid Application Development - RAD

14. Users/Customers • 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.

15. 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

16. 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…..

17. 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

18. 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

19. 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 project

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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.

26. 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

27. 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

28. 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

29. 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.

30. 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 endicia.com and usps.com

31. 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

32. 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

33. 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

34. 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

35. 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, commissions. • 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

36. 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 each. • External Factors and Interfaces • Mostly schedule constraints when rules change • Keys • Integrating diverse requirements • Database driven policies drive the UI and Navigation

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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.

47. 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

48. Conclusions & Lessons Learned Government nuances can leverage your methodology • Understand their mission – it is important • Use organizational process to document and verify requirements • get to know the individuals and interactions • Use Performance Measures to test; was the mission accomplished • 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.

49. 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 government

50. Contact Information • Email or call me • Joe Mondile, Amine Khechfe • PSI Systems, Inc • Palo Alto, CA • Joe@psi-systems.com, a@psi-systems.com • 650-321-2640 x118 • www.psi-systems.com • Input is appreciated • Critique • Future Presentations or ideas • Topics to cover • Your Experiences