Epic Reporting
What To Do When Epic Reporting Requests Become Overwhelming
Discover what to do when Epic reporting requests become overwhelming and learn how you can eliminate an Epic reporting backlog
10 practical lessons for Epic report requests management. Stop losing sleep over Epic reports.
Remember when you had to burn the midnight oil (or laptop battery) on that urgent request sent 3 months earlier that you were reminded of just before leaving the office?Or that day when you were pulling your hair out looking at a list of requests marked "top priority," "high priority," "urgent," and "from the CFO"?
Let's face it: each request is a priority for its requestor and the Epic reporting team ends up with loads of reports that seem to require immediate attention.
Unless you have an effective Epic report requests management process in place, be prepared to have many sleepless nights. Whether you are defining or refining your process, here are 6 practical tips you might want to consider.
1. Centralize
Epic report requests come in various shapes and forms: Clarity reports, data extracts, one-time ad hoc queries, dashboards, existing report modifications, reports distribution issues, etc... An effective report requests management process should enable you to visualize all your workload in one place.
You might have different workflows for handling routine requests, issues, or projects. But you still need to be able to have a central list to determine where resources are or need to be allocated. To make sure different types of requests coexist nicely in the same list, include a "Request Type" or similar column that will help easily distinguish various categories of requests. Also, account for the flexibility to group items. You could call this column "Request Group" or "Project" or anything else that works for you. This offers the advantage of visualizing related requests together and breaking down project tasks into individual requests under the same group.
Ultimately, the goal is to be able to track all requests so that nothing gets forgotten. But this is only one part of the solution.
2. Define and enforce your request logging process
Having a list that can contain all requests does not mean they will all make it there. You need to define a request submission process that will ensure all items are landing in the list. Document and communicate this process throughout the organization to set potential requesters' expectations. You might even want to conduct formal meetings with some key target audiences to reinforce the message. Leadership backing is also welcome here particularly since the goal is to help track requests and utilize IT resources more efficiently.
Once the word is out, enforce the process. Whether it is opening a helpdesk ticket for a queue that houses all your requests or sending an email to a particular distribution list, make sure only requests that follow the process are handled. Diplomatically remind offenders from all ranks that following the process is in their best interest. Be prepared to have to continuously hold the line: after all, laws need policing.
3. Designate an owner
You might want to appoint an Epic report requests "champion" who would monitor and help manage your work list. This is someone who can help educate users about the request submission process, ensure missing specifications are chased down, clarify requests justifications, manage delivery date expectations, follow up with developers regarding progress updates, track and advertise key stats about your Epic report requests, etc... Due to the time required for these activities, it is best that this person not be expected to also develop reports. Their role is to make sure requests are flowing through the work list without getting forgotten or stuck indefinitely.
4. Regularly review your list as a team
The request champion is not supposed to be the only one aware of what is in the Epic requests pipeline. All members of your Epic reporting team should be aware of what is on the list. The adage is true: out of sight, out of mind. Besides contributing to a shared sense of purpose and a collective hightened sense of urgency whenever needed, a habitual review of the list reinforces the importance of the Epic report requests management process itself. It is a collective responsibility. Not the burden of one individual.
How often should you review the list? This is an "it depends" kind of question. You need to find out what works for you and fosters a good weekly throughput of completed requests. At a mininum, once a week. I have seen organizations borrow from the agile concept of daily scrum meetings and effectively review requests for a brief 15-20 mins every day. Consider breaking down the list into smaller chunks that can be the focus for the next two weeks or so. Allow for those inevitable urgent requests when building the list. The two week intervals help build a sense of focus and a production rhythm.
5. Estimate efforts and track critical dates
Effort here is to be understood in project management terms: number of hours needed to complete an Epic report request. It is worth the effort to estimate efforts (yes, I couldn't resist). This is the first critical piece in determining resource requirements. Since it is an estimate, it is bound to be wrong. But, you should be able to report against your Epic report requests healthcare management data and determine how good your estimates are. Here is how.
Use an "Original Estimated Effort" field to hold your first educated guess about how long the work will take. Never modify this field no matter what. Efforts that are fewer than 5 hrs can be explicitly called out in hourly increments (1, 2, 3, 4, 5) while anything beyond that can be rounded to the nearest multiple of 5. As work progresses, track "Remaining Effort" and "Actual Effort" defined respectively as the new best guess about how many hours remain, and the actual numbers of hours allocated to the request thus far. These two fields don't have to add up to the original estimate. In fact comparing their sum to the original estimate is how you measure your ability to estimate work accurately.
The second piece of the puzzle for planning resources is the notion of a target completion date. We cannot complete all requests in the same day and we cannot afford to drag them on forever either. Whether imposed by requestors, or negotiated based on current priorities, or even arbitrarily selected to push work forward, each request should have a target date (particularly those being actively processed).
As you can see, estimated efforts and target dates are critical for evaluating whether or not you can climb up your mountain of Epic report requests as fast as you thought.
Please remember that they are not set in stone. Target dates can be negotiated with requesters and estimates are based on assumptions. You can revisit such assumptions and revise your numbers. For instance, a developer might have estimated 20 hours for a request, but leveraging expertise from another team member could cut this down. Focused work sessions can also help resolve complex development hurdles and revise estimates downward.
I personally prefer using target dates instead of coding request priority levels because they let you put lower priority requests on the map (otherwise they never get addressed).
Besides target due dates, it is a good idea to track request received dates, work start dates, and actual completion dates. They help measure meaningful time lags.
6. Distinguish between workflow step and request status
This final tip has helped clear up much confusion for some teams. It is the distinction between "where are you?" and "how are you doing?" When it comes to Epic report requests, these two notions tend to be blended into a generic status field with values such as "not started," "in progress," "on hold," "canceled," "completed." Such values do not highlight where in the report development process each item stands. Consequently, it is hard to tell what requires crucial attention.
An effective requests management system should help track requests at various stages of development and indicate their "health status." A simple workflow could have the following stages: received, assessment, development, testing, publishing, closed. If a problem arises at any of those steps, the status field (not the workflow step) would indicate what the trouble might be. Possible status values to consider include "needs more info," "slow performance," "no longer needed," "pending user feedback"... The idea here is to define values that are meaningful to your team and actionable. Therefore a request that made it to the "publishing" stage but has a "no longer needed" status shows wasted efforts, while another in the "assessment" stage with a "needs more info" flag is probably not alarming. Once workflow steps and status fields are updated regularly and consistently, you will gain more insight into your Epic report requests management.
I hope you can leverage these few tips to your advantage and adapt them into your own system to capture relevant data and track Epic report requests. I welcome your thoughts regarding what has worked well for you or what you might still find challenging.
