In my first job as a web analyst in the late ‘90s, I worked in an IT department of a large telecommunications company. The analytics team consisted of me and another person who was part time. We worked out a pretty good process of providing standardized reporting to about 40 marketers, content editors and executives on a monthly basis.
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.
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.
- SharePoint is Already Legacy
- Are You Too Old to Work in Tech? IT's Midlife Crisis
- Has Google Just Reinvented Gmail?
- What to Do When Yammer Adoption Stalls
- Is Your Information Architecture Ready for SharePoint 2013?
- Microsoft Lync Can Spy on Enterprise BYOD Use
- Discussion Point: Is There a Secret Sauce for Employee Engagement?