1 / 37

Implementation of a Project Management Approach for OTTR Software

This presentation by Keith Anderson discusses the planning and implementation of OTTR software, including identifying workflow gaps, requesting a demo, defining the proposed system, and creating a project management plan. It also explores the use of Agile and Waterfall approaches, rolling wave planning, contingency time, risk management, stakeholder identification, and project documentation tools.

hatcher
Download Presentation

Implementation of a Project Management Approach for OTTR Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OTTR 7 Implementation A Project Management Approach Presented by: Keith Anderson OTTR OUI 2017

  2. Planning • Need for enhancement of current software • New installation? • Document current workflow process with clinical teams • Consult with users, administrative teams • Identify where the gaps are in workflow • Will the proposed system fill the gaps? • Request a demo • Define the proposed system: local, enterprise or campus • Integration with or without EMR via interfaces (new, existing) HL7 or CCDA? • Create a plan document for leadership

  3. Project Scope • Work order or project summary to project management organization for review and consideration • Define project segments, stakeholders, benefits, deliverables, and resources. Include costs, hardware-software specs and timeframe • Identify teams required to implement the project: vendors, administrative, IT, interface, database, security and clinical • Try to gage how much time, commitment is required for resource allocation • Run your time estimates by the teams who will actually perform the work: they may see things differently • Work Breakdown Schedule: comprised of a tree structure that hierarchically represents the project and its component deliverables

  4. Scope / Plan Document

  5. Project Management • Today traditional project management methods may not apply during implementation of OTTR software • A combination of both Agile and Waterfall approaches may offer better results overall Agile: Short iterations, focuses on rapid life cycle approach, features frequent demonstrations, check-ins to get immediate feedback as the project progresses Waterfall: is more traditional, linear, serves a useful purpose when identifying tasks that occur one after the other Rolling Wave Approach: plan tasks that lie out further in the future on a higher level, define deliverables for the next 1-3 months, break into sections. • Anything further off may keep you eyeing the end goal instead of focusing on what’s in front of you.

  6. Project Management Document: Agile • Screen shot of MS Project displaying key deliverables, milestones, not in any specific order. The ability to move tasks around, focus on what needs finishing now.

  7. Technical Tasks for Go-Live: Waterfall Approach

  8. Contingency • Extra time built into the project: Allow for unscheduled events or delays with specific tasks or deliverables taking longer than expected • Add extra time (10% or more) for key deliverables, prepare for delays due to multiple projects other team members are working on • Work contingency time into your estimates as bug fixes or software installation, attach to key deliverables • Acts a cushion of time if needed, if not then you’re ahead of schedule • Most teams will use the contingency time if defined to stretch out work, stick with your estimates

  9. Consider Risks • Elements that may go wrong in your project • Maybe you’re using a newer version of MS SharePoint for your project, most users don’t have the version you’re using, creating a huge learning curve • Identify potential risks, rate then by likelihood to occur and severity (table to rate potential risks) • Choose which risks to plan for and how best to deal with them

  10. Approval • Does the proposed project meet the facility’s needs, strategic initiatives? • Can you secure a financial commitment from leadership? Identify stakeholders (project sponsors, physicians, and program administrators) • Identify, select your administrative, physician champions. You’ll need them to drive home the need for a software solution to leadership • Secure project buy-in with administrative and physician champions • ADMIN and Physician champions: who understand the need and support the software solution proposed, will go a long way towards approval of the project and user acceptance during installation

  11. Tools • Project org chart and communication plan • Flowcharts to break down key deliverables • Identify dependencies (tasks): Break down deliverables to understand the tasks, time estimates required to complete the work • Don’t get caught up in percentage of completed tasks. Is it done or not? • What tools work best in your environment? MS Project, Excel, Visio, Adobe or Word? • Utilize tools you’re already familiar with, verify others are able to open your documentation or common share for all to reference • Do you have a shared team documentation area within your organization?

  12. Tools Cont. • If you’re using MS SharePoint Portal Services: create a shared site for users, project team members to access, review updated documentation • Publish project documents for review: overall project plan, current tasks, and timelines for teams to reference project progress. • Use a PDF creator to preserve project document versions (shared or otherwise) to avoid accidental changes by others. • I also added an OTTR Support sub-site within the top level SharePoint Site to assist with questions and problems • Lurie OTTR Support Site: contains user documents and tutorials

  13. Project Cover Page

  14. Initiation • Verification of intent to implement solution • PID = Project Initiation Document: Summary of the what, why, how, who, and when of the document • A quick look at the overall project (high level) for all to agree on, verify the deliverables, time and commitment Kickoff: Hold a kickoff meeting to formally start the project, include all teams (management, IT, users, and Vendor)

  15. Environment Build • Allow ample time for IT to build your systems, review release notes (planning phase) • Review Vendor specifications with IT (scoping phase), technical tasks to build the environment • Engage you IT department, who’s responsible for building the servers (physical or VMs), SharePoint Site, Portal services, interfaces, and preferred browser used with OTTR • OS software, servers, test and production databases, Citrix, and licensing (scoping phase) • Identify your IT resources for time and commitment (during the scoping phase) and verify they’re ready • Who will write your reports? Crystal Reports and SSRS are most commonly used to generate reports

  16. Executing • Load or upgrade test environment and test interfaces • Keep track of deliverables sections, refer back to the plan, make sure your timing falls within the project scope, not falling behind due to risks, technical issues or hard to complete tasks • How will users login? Manually, AD accounts, SSO… • As an OTTR administrator: you’ll need to know how users are setup in OTTR and your network

  17. Testing • TEST everything in the application, match current workflow, look for opportunities to improve workflow and decrease work effort • Concentrate on functions specific to your program workflow, data entry. Look at ease of use • Create a core testing support group, include key members of each program (APNs, Pharmacists, Physicians, Nutritionists, Back office support assistants and Research) • Interfaced labs, ADT, text documents and reports. Chances are you’ll spend a fair amount of time here, keep track of what’s tested and if it passed or not • Lists: what works, are you seeing the expected data? Record what’s incorrect, request modifications from OTTR support

  18. Testing Cont. • Define Lists you’ll need moving forward, remove or hide older versions of lists that don’t work • You won’t need every list in the system • Test interfaces for accuracy of ADT, Lab results, Text documents and other interfaces you contracted for (inbound and outbound) HL7 or CCD • TEST, TEST, and TEST again! You’ll come away with a better understanding of OTTR application functions, and how it fits your current workflow • There’s always time to improve your workflow, start slow and meet with teams for ideas, and TEST!

  19. Training • Who needs training? • Train the trainer • Walk-in sessions • Web training provided by OTTR • Shared documents: tutorials, quick start guide, workflow, how to guide, and test users

  20. Walk-In Training Sessions • Nice option for users that can’t attend formal training

  21. Go-Live • Make final announcement prior to go-live

  22. Go-Live Cont. • Test Again! I’m sure you’ll find something not working correctly, best to get a jump on it before your users • Support, triage issues and severity • Create a Post Go-Live working document of known issues • Submit known issues to OTTR Support site to resolve • Use SharePoint support site to field issues from users, make announcements • Use the OTTR Message of the Day or OTTR 7 Announcements

  23. Post Go-Live Support • Ongoing support for user issues, updates from OTTR Support • Identify with vendor if issues reported are correctable or an enhancement request • Resolve feature or workflow problems • Check your Misc. Labs not mapped list, remap missing labs in flowsheets! • Allow a couple of weeks post go-live before you call the project finished, to get the bugs out • Continue to meet with clinical teams for new issues, training in OTTR 7 • Setup follow up calls with OTTR PM, Support, Interface and Clinical teams

  24. Go-Live Issues Working Document

  25. Closing the Project • Draw a line when most deliverables have been completed • Are users able to complete all tasks per workflow? • Refer back to the PID Project Initiation Document, along with basic scope, time line and deliverable details to define project success • Project Sign-Off Communications • Communicate at all levels of the project to Stakeholders, Users, IT teams, and administration • Use shared documentation location (SharePoint) for testers, users, support and email updates

  26. Meetings • What’s the best method to make sure you’re heard? • Clinical team meetings • Schedule upgrade meetings • Conference calls • Share meeting minutes for others to review, keep a sign-in sheet of team meeting attendees • Assign a name to the task and when they’re due • Ask if your method of communication is working, change what’s not

  27. Lessons Learned • Review Lists for accuracy: MRN instead of OTTR ID • New or Upgrade Installations: Run stock lists in OTTR 7, test their function • Request modification from OTTR Support, if lists don’t meet your needs • Check all single, multi patient reports in OTTR 7 • Ask for email favorites move during upgrade for V6 clients • Watch out for view changes, functions of tiles, and how it affects entering-viewing data

  28. Questions?

  29. Thank You!

More Related