A lot of Health and Human Services agencies have recently found themselves with the Quality Improvement Mandate. For a variety of reasons, agencies have adopted continuous quality improvement models, most notably the Plan-Do-Study-Act methodology.
With the emphasis on PDSA, Quality Improvement professionals have been asked by executives, board members, and regulatory agencies; to "show " them successful projects. This presents a problem.
Quality Improvement projects consist of work that is often spread across a variety of platforms, and a series of notes, reports, and spreadsheets don't "show" the project as the requester has intended.
This guide is meant to demonstrate how to convert the hard work that exists within your Quality Improvement project into a human readable narrative will be understood by any and all of your interested stakeholders.
Documenting your Plan-Do-Study-Act process is all about turning your activity into a compelling story. Your agency undoubtedly has quality being improved all the time, but can you demonstrate to the right people who is doing what, with the right intelligence, at the right time, to produce better outcomes?
It’s important to convert your project management methodology into a chronological narrative that is easy to follow along by those who don’t have the day in and day out understanding of your work and your projects. You need to be able to communicate why the project exists. Who did what, when and how. And, why you will or won't continue doing it in the future.
This story can’t be told from project tasks lists or static graphs or spreadsheets. When your CEO wants to see your Quality Improvement efforts, a shared folder with Gantt charts and spreadsheets and task lists won’t suffice because it doesn’t weave together the narrative. When the Council on Accreditation (or other regulatory body) wants to see evidence of your Quality Improvement system in action, submitting 6 separate documents to tell your story won't paint the picture of value of your efforts.
Executives and stakeholders want to see that a group of people decided to do better at something, how those people chose to take action, and how that action resulted in better outcomes. It’s not a series of electronic files saved into the same folder. It’s a story.
Let’s explore how to tell it.
Documenting a Quality Improvement Story means capturing Events. An event is any entry that moves the project forward in some way. Documenting events requires the following:
In every stage of Plan/Do/Study/Act there are people holding meetings, analyzing data, and assigning and completing tasks. In order to tell your story it is critical to capture each event in the chronological order it takes place. If you can capture the events as you go - by the end of the project you will have a timeline that any reader can follow from the formation of your AIM Statement all the way to the action steps that make your new process permanent.
Quality Improvement happens when the right combinations of people come together and use their complimentary skills to make positive change. That makes people the foundation of the Quality Improvement story. All of the events in the story should be attributed to the people responsible for them. It is critically important for someone reading your story to see the names and faces responsible for the activities. Even if the reader doesn't know them, it paints a picture that enables them to visualize the work and really see the change happening.
While every event should be attributed to a single person responsible - that hardly means that others shouldn't be mentioned. If Steve is responsible for a piece of Data Analysis he would be tagged as the owner that drives the event. However, if Steve collaborates with Cathy to draw conclusions for the analysis then Cathy needs to be mentioned in that part of the story.
Ensuring that people are mentioned for their activity helps tell a compelling story, but it’s also about giving credit where credit is due. Telling a QI story is a chance to promote the good work of individuals that create greater team success, and that should be embraced, not rejected. Readers of QI stories want to see who is doing what to improve a program or agency. Its not selfish self promotion - its telling the truth.
Every PDSA project should start by developing an AIM Statement that outlines the opportunity and goal of your project. It should be short and succinct and outline specifically what improvement the project is intended to produce, by how much, and within what time frame. The goal portion should reference a specific amount of improvement desired, so the final conclusion can reflect whether the project was more or less successful than expected. And a general timeline should realistically forecast how long it will take for changes to appear in your reports.
In literary terms the AIM Statement is your thesis. Therefore it only makes sense that it appears at the beginning of your QI Story and sets the stage for everything that comes after. Unlike the rest of your QI Story that should run in chronological order of events, the AIM statement should appear at the beginning even though it may be developed by the team during the Planning Stage and there could be mention-able events that technically come before it is created.
For more help with crafting AIM statements read: AIM For Quality Improvement by Christa Foschio-Bebak at CCNY Inc.
The most common way people bring their skills together is during meetings. Meetings will occur in all stages of the PDSA cycle, but they will be for different purposes and produce different tasks and ideas that relate to other aspects of your quality improvement story.
You may have a meeting to look at some reports that result in Data Analysis. You may have a meeting where your project team agrees to a list of tasks to be completed, who will complete them, and when they are due. You may have a meeting to kick off your project that results in drafting your project AIM statement. Whatever the purpose and result of the meeting - your Quality Improvement Story needs to show who got together, when, where, for what purpose, and what came out of it.
You may think it’s in the nature of project management efficiency to avoid documenting trivial details like meeting locations for example; however, to the reader of your QI story it’s invaluable. The narrative that forms when the reader gets to visualize your project team logging onto a Zoom call or arriving at your offices and coming together in a board room, transforms your project from a lifeless list of meetings and tasks into a dynamic story that demonstrates the emotional investment and hard work being dedicated to improvement.
You may think that only big planned meetings should be documented; however, if that impromptu get together by a couple of team members to analyze some data is what cracked the case then you still want to highlight the image of people getting together and producing results.
You may be thinking that Data should stand on its own, but there should really never be Data in a QI story that isn't supported with contextual narrative. And there must be Data in a QI story. During the Plan stage of PDSA you will be determining what measures will demonstrate success, and those are the measures that will be used to indicate if your process changes are effective or not. However, there may be other measures that help dig deeper and direct what the process changes should focus on.
In any data presentation scenario you want to include narrative that explains what the numbers mean. Is any change in the data substantial, why or why not. You should always assume your reader has little to zero understanding of your data. All data should be visual to demonstrate change over time in graphical format, and the compliment of your narrative with those visuals will produce compelling details that demonstrate your activity and results.
Image of a Data Analysis event as it appears in QI Folio software
Sometimes that narrative may need to be detailed to explain complicated calculations and why that math should be used for the project - while others may be simple as explaining that one color line is for Location A and the other color line is for Location B. Sometimes a Data & Analysis event is inconclusive, or simply leads to looking at another data set. Those types of data events should not go undocumented even if they don't drive the final actions. Telling the story may be as much about the small data events as it is about the big ones.
The results will be there at the end - let your reader follow how you and your team got there from start to finish and EVERYTHING in between.
If its people with skills that make Quality Improvement happen - then its the things people do that explain how those skills have been put to use. Tasks are the individual activities that individuals are responsible for executing. During the project tasks are often outstanding, assigned to certain people, have due dates, or move around through various stages of completeness. For the project story to be final all tasks should be completed and documented.
Tasks can range from the necessary administration such as: Staff will schedule a meeting to discuss process mapping - to critical actions like: Managers will train staff on new procedures for immediate use. In either case - tasks are often stored in list fashion in spreadsheets, or Gantt charts, or other project organization methodologies, all of which are useful tools for executing a project and should continue to be used. However, building the Quality Improvement Story should break up the project tasks and insert them among the other documented events; Meetings, Data & Analysis, and other Tasks. The chronological nature of a good QI story converts the list like nature of project management into a chronological commentary that the reader can visualize.
Documenting tasks is critical - and requires your project team to understand how their work becomes the QI story at the end. If someone's task is to execute a new process or procedure, its not enough to simply mark it complete and give it a date. The reflection from staff that execute a task is what adds the color to a compelling story. Was it easy, hard, and how did that relate to expectations? Was there an immediate response? Did clients comment? The data will prove the effectiveness of the actions taken - but ensuring every action has an accompanying explanation will turn project to do lists into a compelling narrative.
An easy way to think about Quality Improvement documentation is to consider the strategies behind clinical documentation. The notes are always best if taken during or soon after the event takes place. Documenting when ideas are top of mind leads to more succinct and concise notes that will build stronger narratives.
Additionally, you may consider workflow processes that funnel completed event notes from team members through QI staff. Having a review process for event documentation helps produce a consistent voice and ensures that notes touch on all the critical areas before saving as final.
Document as you go and you will be positioned to produce complete Quality Improvement Stories to demonstrate better outcomes with maximum effectiveness!