Feature
This system would work great until our manager would stop by one of our cubes with a time-consuming, ad hoc request that would throw off our timing and perfectly tuned schedule. The requests weren't necessarily difficult -- like running a geolocation visit report based on a specific date range -- they just came at inopportune times and would throw our schedule off. We called these random requests “drive bys.”
I conducted research with over 100 digital analytics managers a few years ago and was a bit surprised that ad hoc requests came up as a task that comprised nearly 50 percent of their team's work hours. Many of the digital analytics managers I’ve worked with over the years describe ad hoc requests as an issue that won’t go away.
While it would be easy to talk about the lack of consideration my old boss had for the beautiful schedule my colleague and I had put together, or the unrealistic expectations your manager or stakeholders have for you to have complex analyses turned around in 48 hours, I believe the accountability for change could be staring you in the mirror. That’s right, it’s you.
The change you need to make?
Don’t Say 'Yes'
This doesn’t mean saying “no” to requests either.
It really means “I hear your request. Now let me evaluate what it will take to do this and also evaluate what will not get done, if I fulfill this request."
Here are 5 points to consider before you say “yes.”
1. What is the business reason for the request?
A business reason requires the requestor to describe why they want their ad hoc request fulfilled. Once you understand the request, you can determine whether this is a task you’ve never undertaken, or perhaps you’ve done similar work or created a similar report or analysis that provides the answer to the question being asked.
Learning Opportunities
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
Conference
May
1
Qualtrics X4 Salt Lake City 2024
Register
Webinar
May
2
Unleash AI for Crisis Management: Transform Threats into Triumphs
Learn how Sprinklr Insights provides real-time insights on current events, trends, and brand crises to empower your team.
Register
Webinar
May
9
Driving Customer-Centricity in the Financial Services Industry
Discover how financial organizations are leveraging generative AI technologies.
Register
Conference
May
9
An Irish Roundtable in the Valley: The Economic Impact of AI on the World of Work Stanford 2024
Exploring the Impact of AI On the World of Work with Irish diaspora leaders and tech business champions from the North of Ireland
Register
Conference
May
13
Gartner Marketing Symposium/Xpo Conference London 2024
Register
2. Are the analyses or reports requested the right ones to answer the business question?
The requestor may or may not have experience in analytics, but you are the resident expert. Once you know the business reason, you may see that there are metrics to be created and reports to be run that are not the same as what was originally requested.
Regardless of the approach, be sure to confirm the requirements with your stakeholder before doing the work. Creating a separate document or email, having a meeting to review for changes and then a written acknowledgement at the beginning of the work may not seem necessary, but once the project starts and everyone forgets the details, having clear approval helps everybody.
3. Once you've figured out how the ad hoc request should be fulfilled, determine the level of effort needed to produce the work product and the amount of time it will take.
We generally don’t want to think about how much time it will take to go through all of the steps to produce the analysis. Estimating hours on a task level is not a lot of fun. It requires us to be accountable for our time, and it puts us into the uncomfortable role of creating an expectation -- and we don’t want to fall short of these expectations. Here’s what you do;
- List out the tasks.
- Provide a range of time you think it will take to complete the task. Add 50 percent of time to the top of your range. If you think 10 hours, then estimate 15 hours for your Level of Effort (LOE).
- Think of dependencies that will affect your tasks from being completed on time and within the time estimates you’ve given. For example, if you can’t get all of the necessary stakeholders together for requirements meetings, review sessions and approvals. Or, if you need to depend on a development team or third party vendor to do the necessary coding to enable data collection on a new application that you need to monitor. List these dependencies with your estimate. If you are making assumptions, such as that the metrics requirements that you have been given are final, then indicate these as well.
- Plot out the timeline based on the team that will be doing the work and with consideration of their schedules. If this is something that is simple and quick, it may need only an hour of someone’s time. If it is more complex and you require multiple resources, you’ll need to consider this.
- Communicate LOE and timeline to your stakeholder and make sure that you have approval. Like requirements, getting buy-in on LOE and timeline help set expectations that you can’t turn the work around in 48 hours when your LOE claims you’ll need 96.
The important point to remember is that most people will ask you for something as soon as possible. Only you can set parameters and definitions around what “as soon as possible” actually translates into. If doing their project takes away from other important projects or delays delivery of another stakeholder's work, tell them and ask that they negotiate the delay with the affected shareholder. Spread the accountability so that you are not the bottleneck.
4. Analyze your work to figure out how to streamline productivity.
Start to forecast hours required to complete tasks and the actual time to complete tasks. Use this data to be able to provide Level of Effort estimates more quickly and with greater accuracy. You may also determine that there are people on your team who are better and faster at certain tasks. This may give you greater flexibility in chunking out projects so that you can have work streams in parallel rather than in sequence. For example, you can have your implementation expert work on code design while your dashboard export creates design mock ups. Or you can have someone design data queries while a junior resource runs the queries.
5. Have an intake and evaluation process and let everyone know about it.
You can have a formal intake process where everyone has to fill out a form, send an email or talk to someone on your team and provide them with the information you need to evaluate. Or you can have an informal process, where the information is collected but perhaps conversationally.
In either case, you need to settle on the process of intake, evaluation and expectation setting and communicate this to your stakeholders. In larger organizations, this can take a long time and require a good deal of education and perhaps consensus building.
If you have no process, no boundaries and no ground rules, you can’t expect anyone to know how to do business with you. Once you have put a stake in the ground, you have a place to negotiate from. You can create a policy that defines expected timelines and levels of urgency where emergency requests are ok. In eliminating uncertainty and questions, you’ll find a decrease in “drive bys” and increase in respect for the work that you and your team accomplish.
Title image by IntelFreePress (Flickr) via a Creative Commons BY-SA 2.0 license
