Cbrewer db pres-03

Type: Presentation 1 Pages: 40 Classification: Restricted

COMPLIANCE RESOURCE
DATABASE PROJECT
PRESENTATION TITLE

A PRESENTATION FOR UW MEDICINE COMPLIANCE

1
Presentation for: UW Medicine Compliance
CASS BREWER Date: 20 June 2011
casscomplex@gmail.com 206-774-0183 RESTRICTIONS: INTERNAL AND CONFIDENTIAL: DO NOT DISTRIBUTE

[META]
TITLE

Compliance Resource Database Design

● Few database projects are sui generis: Some start with “I
need.” Most start with “I don't know.”
● Databases and applications are joined at the hip, so we'll
look a bit at that relationship.
● A project planning approach should be scalable, and
we'll address that, too.
BODY

Presentation for: UW Medicine Compliance Page 2
CASS BREWER Date: 20 June 2011 40

HYPOTHETICAL PROJECT
TITLE


● Driver: Compliance managers to better LOCAL SCOPE
understand and access their compliance ● 2 months
research, policies, procedures, standards, ● Internal resources
plans, records, resources, and performance ● No budget
data they have at their disposal.
GLOBAL SCOPE
BODY

8 months
Solution: Provide an intranet portal through
●
●

which departmental compliance, security, ● Internal + external
and risk managers can discover and analyze ● $14,000
available compliance assets. First, we need to
gather the data...

Presentation for: UW Medicine Compliance Page

OPPORTUNITIES
TITLE


Evidence basis for decisions
The right information, right now
Admin view of performance across programs
Cross-program efficiencies
Gap analysis
BODY

Standardization
Better resource access = Better compliance
Self-service queries = Less work for everyone
Extensibility

CHALLENGES
TITLE


Asset identification: What do we have?
Structure: How should it be organized?
Diverse asset types
Maintenance / currency ( ) 2

Control ( ) 2
BODY

Asset distribution vs. centralization
Volume


CAN WE LOWER THE BARRIERS?
TITLE


● Can it build on existing resources?

● Can we leverage knowledge /
technology / outputs from other projects?
BODY

● If we have to build it from scratch, what
other goals or projects can it benefit?


WHO NEEDS TO BE INVOLVED?
TITLE


CCO (executive sponsor)
Compliance program staff
Administrator (project sponsor, customer)
CIA (project manager)
Analysts (customers, stakeholders)
IT (DB & dev) representatives (key stakeholders)
BODY

Delegates from compliance functions at Harborview, UWMC, UWPN, Airlift
Northwest, Children’s, NWHMC, UW School of Medicine, UW Physicians
(UWP), clinics, UWM billing, and other impacted organizations (customers)
Legal counsel (stakeholder)
(Internal audit representative (stakeholder) )


HOW DO WE GET THEIR BUY-IN?
TITLE


● “Contributory,” not “conscriptive”
● Augments existing resources and processes
● Non-disruptive
● Benefits: universal || value: specific
● Confidentiality maintained
BODY


BUT SHOULD WE DO IT?
TITLE


● Business case (descriptive)
● Solution idea (high-level)
● Goals (business and technical)
● Alternatives (why not them?)
● Project team
BODY

● Estimated costs and resources
● High-level timeline

Ducks in a row, but devil's still in the details


CHECKPOINT: GO / NO
TITLE


● Aligned with current strategy?
● Realistic?
● Competencies
– Managerial
– Operational (application and DB)
Time
BODY

●

● Budget
● IT environment
● Best alternative?


EXPLORATORY MEETING
TITLE


● Present the project: drivers, goals, results
● Introduce team members: who and why
● Refine business case, use cases, objectives
● Clarify project scope SQL!

Billing!
HIPAA!
● List and rank customer requirements
BODY

● Address concerns
● Create excitement
● Confirm buy-in (hopefully)
Exploratory meetings are like proteins:
They look messy, but are mighty.

STRENGTHEN THE PROJECT PLAN
TITLE


● More explicit business case
● Draft use cases
● Specific objectives & performance criteria
● Key performance indicators
● Key risk indicators
● Project scoping
● Rough schedule
BODY

● Estimated budget
● Communications/awareness
● Implementation
● Support/training
● Maintenance
A complete picture, even if some
aspects could be clearer


SCOPING: LOCAL PROJECT
TITLE


Functional System Dependcs Data Technology Orgzn Deliverables Objs/KPIs Change
Mgmt
Centralized Asset Data Information Existing Compliance Project Identify assets Change tracking.
maintainance database availability assets within hardware, program admin documentation (%)
and storage of Compliance software, and only Managerial
compliance Search and System program: network Asset Catalog assets review/ approval
assets query capacity research, spreadsheet (%) for changes that
application policies, DB (SQL), impact
Identification of Related procedures, simple Business object Add assets in production
existing assets Search and projects standards, search/query model DB (%) systems or
and gaps query interface plans, records, application processes
resources, (php, Process maps Discover “lost”
Simple inter- performance javascript), for asset assets (#)
departmental data, Web interface creation,
performance performance (HTML, CSS, approval, use, Reduce asset
analysis and resports javascript) updates, searching time
reporting retirement (# hrs/mo)
[Bus object Behind firewall
model (internal
BODY

Map of existing 0 redundant
provided] access via assets and assets (+/- goal)
existing ID, locations
roles, and 0 obsolete assets
permissions)
Extension (+/- goal)
strategy
Extensible,
Asset gaps
standards-
Asset catalog documented (#)
based
technologies
whenever Keywords Better
possible performance
Database data tracking (#
hrs/mo on
Search/query reporting)
application

Web interface


SCOPING: GLOBAL PROJECT
TITLE


Functional System Dependcs Data Technology Organizn Deliverables Objs/KPIs Change
Mgmt
Centralized Asset database Data availability Information App server, Web Participating Project Identify assets Formal change
storage of assets within server, APIs, compliance documentation (%) management and
compliance Search and System capacity Compliance integration functions across documentation
assets query program: layers, UWM units Asset tracking Catalog assets
application Related projects research, aggregation spreadsheet & (%) Change requests,
Identification of policies, layers ● Org 1 maps review, impact,
existing assets Query interface Existing work procedures, ● Org 2 Query all assets approval
and gaps tools and standards, plans, DB (SQL), ● Org 3 Business object (%) documented for
Administrative processes records, simple ● ... model all non-routine
In-depth interface resources, search/query Discover “lost” changes
departmental Ability to couple performance application (php, Standardized assets (#)
compliance Dashboard new data, javascript), Web definitions, Project PM
performance roles/groups performance interface classifications, 0 redundant included in dev
reporting Supplemental elements with resports (HTML, CSS, taxonomy assets (+/- goal) CM processes
role/group db global IAM (if javascript)
Intradepart- (coupled to necessary) [Bus object Process maps 0 obsolete assets
BODY

mental global IAM) model provided] Behind firewall (+/- goal)
performance Relational db
analysis and Analytical Existing Ids, Fill asset gaps (#
reporting application augmented roles, Search/query new assets)
groups, and application
Report templates permissions Usable system
Reporting (# queries/mo,
Standards: application & hrs use, #users)
configuration, templates
programming, Better
database, Web interface performance
interface decisions (#
design Dev PM “live” queries, #
documentation new reports, $
Unit and costs dependent
system testing Technical actions )
by user documentation
committee
Online manual


TECHNOLOGY PLAN
TITLE


TECH REQUIREMENTS - Assess existing processes
- Define, generally, how data will be organized
- Define development tasks and steps
PM IT C ( SP ) - Define security and privacy requirements

DESIGN - Define system components and their relationships
Phased development or major upgrades

- Define the technology domain
- Define interface standards
- Write a detailed functional specification*
PM IT

IMPLEMENTATION/ - Build the system (database, application, interface)
- Make sure component parts work properly
UNIT TESTING - Make sure notable changes are documented, reviewed, and
BODY

PM IT < C ( SP ) approved

INTEGRATION - Test entire completed system, using practical scenarios
- Make sure it's what we expected and wanted
TESTING - Make any final tweaks and to functionality, data, and interface
PM IT < C ( SP )

RELEASE & - Finalize operational setup to mirror live-use environment
- Last chance to tweak and catch errors
MAINTENANCE - Periodically meet with end users to identify problems and
PM IT ( C SP ) - opportunities for improvement

Project Project Customers /
PARTICIPANTS: SP sponsor(s) PM manager IT IT C delegates


SCOPING: FEASIBILITY
TITLE


Research reduces uncertainty and assumptions
● Quantitative
– Compliance asset identification
● Catalog of resources on known network
● Broadcast email to compliance staff (subset?)
● Staff (“customer”) survey
– Skills survey
BODY

– Process workflow and data flows
– Budget items
● Qualitative:
– Asset prioritization chart
– Needs survey
– Wish list

SCOPING DECISIONS
TITLE


● Which requirements are critical?
● What are the limiters (time, budget, capabilities,
technology)?
● What are the team's highest priorities?
● Which requirements represent the highest ROI?
BODY

● Hard payoff: Capital directly earned or saved
● Soft payoff: Employee/customer satisfaction,
qualitative benefits


SCHEDULE
TITLE


Local Project Global project
● Gantt +
● Calendar
● Resources/responsibilities
● Tasks ● Tasks (PERT notes)
● Deliverables ● Milestones
● Constraints ● Deliverable lifecycles
Dependencies
BODY

●
● Report due dates ● (Available hours/resource)
● Meetings ● Critical paths
● Constraints
● Meetings


SCHEDULING > GANTT +
TITLE


Critical path 1
Critical path 1

Process
Process Critical path 2
Critical path 2
milestone
milestone

Communications
Communications
milestone
milestone
BODY


BUDGET & RESOURCES PLAN
TITLE


Local Project Global Project
● No formal budget ● Resources
● No additional resources ● Application developers
● Database developers
● Consultants/temps/services
Software support
BODY

●

● Technology (hardware,
licenses, etc.)
● Supplies


COMMUNICATIONS PLAN
TITLE


For simple project with local teams:
● Status periods
● Key communication cycles

For complex projects:
● Status updates (PM ► Team)
● Reporting expectations (subcommittees ◄►Team/PM)
BODY

● Deliverables that require review/approval and expected responses (PM ► Team)
● Team communication best practices
– Team members' contact information
– PM contact for communications and conflict questions
● Communications tools and media (highlight “special” tools)
● Key communications also in project schedule


MARKETING PLAN
TITLE


●

●

●
Target
(Launch campaign)
Post-launch awareness
Feedback loops { Messages
Materials
Channels
Success metrics
BODY

●

● Costs


SUPPORT PLAN
TITLE


Timeline
● Training & support ●

During project
goals and KPIs
●

– Write user manual (core + group variations)
– Write content for contextual (online) help
● Deliverables – Write / compile training classe materials
● At launch
● Unique objectives – Publish user manual and contextual help
● One month after launch
● Outlines – Group classes (tailored by group)
BODY

– One-on-one training, as needed
● 3 and 12 months after launch: Review and
maintanance survey
● Continual
– Phone & email support

Disclaimer: No magic brain machines.


MAINTENANCE PLAN
TITLE


● Technology maintenance ● Security maintenance
● Requirements ● Workflows (if known)
Automation / tools
Responsibilities
●
●

● Procedures
● Phased upgrades included
● (Schedule) in original project scope
● Data maintenance should be re-evaluated and
BODY

recertified at each phase
● Requirements
● Responsibilities
● Procedures
● Schedule


CONTINUAL IMPROVEMENT PROCEDURE
TITLE


● Team post-mortem
● Customer process
and results survey
● Performance-to-target analysis
● Lessons learned
BODY

● Recommendations for
improvement


BACK TO PROCESS
TITLE


[ breathe ]
BODY


KICK-OFF MEETING
TITLE


● All members of project team (important!)
● Reintroduce (who, why)
● Distribute project plan and supporting materials
● Re-present project, emphasizing
● The impact of their feedback
Changes since exploratory meeting
BODY

●

● Schedule
● Risks
● Importance of effective communications
● Address ALL concerns (even if to park)


CHECKPOINT 2: RISK ASSESSMENT
TITLE


● Still aligned with current strategy?
● Still meets primary goal?
● Is our focus drifting?
● Still realistic?
● Is our scope creeping?
BODY

● Still supported by customers and sponsors?
● Signficant uncertainties
● Emergent risks


TITLE


Will we proceed? ;-)
BODY

Thank you!


Cbrewer db pres-03

Recommended

Recommended

More Related Content

Similar to Cbrewer db pres-03

Similar to Cbrewer db pres-03 (20)

Recently uploaded

Recently uploaded (20)

Cbrewer db pres-03