Three Ways Health IT Project Kickoff Meetings Fall Short

Stay up to date on our latest blogs and content

Subscribe

By Bob Gronberg | Jan 15, 2021

4 minute read EHR/EMR| Blog

After a year of healthcare IT projects being delayed to make way for front-line support, many teams are reassessing projects such as EHR migrations and related implementations or kicking off new ones. And here is where we consider the Project Kickoff meeting. In my many years delivering EHR solutions and consulting on health information management (HIM), there are a few areas where the project kickoff always falls short. These include:

  1. Assigning Executive leadership responsibility; putting a NAME down.
  2. Defining reporting mechanisms and communications cadence.
  3. Answering the question; “What is my role on this project”?

Most teams successfully establish the base foundation for the project, work through the initial scope setting exercise, timelines, roles, and team member responsibilities. The shortfall areas I mention are especially critical in health IT projects, and even more when considering the significant pressures on healthcare organizations to execute new projects that improve operational efficiency and support transformation.

The Buck Stops Here: Executive Leadership

It is important to ensure that projects are assigned to an executive (singular tense emphasized) who has responsibility for the final delivery of the end product. Health IT projects are complex, time-consuming, and resource-intensive. Only Executive Leadership can make decisions and allocate resources to achieve results, even reallocating personnel from less strategic initiatives. Ideally, the executive sponsor should be from the business unit that is deploying the new technology and have oversight into the direct impact of the project.

As an example, it is not uncommon for a CNO or COO to be the project executive for the rollout of a new EHR platform. This is done to modernize the clinical data entry and method of retrieval of patient information, as well as align with the clinical and physician staff who are key end-users. What we would caution against is having the Executive Leader be from IT (CIO, CMIO) being the project executive for said EHR replacement. While the CIO plays a critical role in the overall technical direction and operations for an organization, this choice would cause the EHR project to be seen as an IT project and less as an organizationally-led transformation initiative. Remember that with great power comes great responsibility. In this case, executive leadership comes with leading projects and often embodying the quote on Harry S Truman’s desk: “The Buck Stops Here.”

Aligning the Moving Parts: Defining Reporting Mechanisms and Communications Cadence

Health IT projects are often comprised of several different stakeholder groups or components, all working on parts of the whole project.  Rarely do these groups communicate well or share the same perspectives on the project. Communication is extremely important to the success and the one focus of the kickoff meeting should be on defining the tools, methods, and frequency of cross-team collaboration. Start with establishing expectations and defining timeframes and processes that will be used to communicate internally, with larger teams, with executives, and project sponsors. Typically meetings are structured similar to the following:

  1. Weekly Core team meeting – Discuss current and future project activities, issues, and risks at a granular level. These meetings are generally held with the project staff executing work tasks along with various vendors and consulting staff.
  2. Bi-Weekly Core Team Leads meeting –  Core team leads meet collectively and discuss progress, issues, and risks to their portions of the project. This is generally led by the Project Director or Project Manager. Report outs should be done by all team leads. This builds ownership and ensures awareness of project hurdles and risks as well as reinforces the goals, milestones, and timelines.
  3. Project Executive meeting – This meeting gathers all impacted executives and project leadership representatives (Project Director or Project Manager) and is led by the assigned Project Executive. The meeting goal is to ensure that the team is well informed and prepared to field questions and concerns from their peers. Our best practice at CereCore is to utilize a project dashboard as the communication tool, with a significant focus on project issues and risks. This meeting is generally held monthly, though as the project nears go-live, more frequent meetings tend to be beneficial to address escalation items.

The Red Flag Question: “What is my role in this project?”

When a team member asks “what am I responsible for on this project?” after the project kickoff meeting, this is a red flag. A core objective of the project kickoff meeting is to define roles and responsibilities. Many tools and methods can be leveraged to highlight how resource utilization and resource assignments. One of my favorites is the RACI chart. This is a simple tool that details various project roles along one axis and tasks along the other axis. The chart is then completed with one of four letters (R, A, C, I) representing the following:

raci-chart

Responsible (R)

This task indicates project member’s primary area of responsibility, aka, their job in the project.  They must also ensure that the task is completed on time and at a satisfactory level. Technical work falls into this description. Project managers usually have administrative and project management tasks they are responsible for, and project sponsor or project executives are typically responsible for approval of project expenditures. This group performs the tasks in collaboration with the accountable people (A) for them.

Accountable (A)

This indicates those who are accountable for the results of the task even though they are not directly performing the work. They are accountable for timely execution, deliverable quality, and other assigned success criteria. They often get credit for the success or failure of the task.  This includes people who are reviewing or approving the deliverables and work product. This role requires familiarity with the technical details of the work because it will reflect on them.

Consulted (C)

This indicates teams or individuals who need to be consulted and allowed to provide input into the task. They have knowledge or staff that need to be incorporated into the task’s work and deliverables.  This group should be consulted at appropriate times within the project since their feedback may affect decisions and workflow design.

Informed (I)

This group needs to be kept aware of task results, outcomes, and decisions, etc.

If there’s one thing we’ve learned in healthcare technology in the past year, it is that there is always something we can optimize, implement, or transform – even the tried and true project kickoff meeting.

About the Author:
Bob Gronberg

Assistant Vice President, MEDITECH Professional Services,

Put Us to Work

Let us know how we can support your initiatives and take some of the heavy lifting from healthcare IT.

Untitled-4