As an analyst, how can I mitigate the consequences of missed deadlines due to unforeseen blockers?

Question

My company recently put a new set of CRM features into production and management is eager to find ways to monetize them. A large part of my job has become analyzing the new data and making recommendations on how to leverage it. I'm generally expected to produce results within a short amount of time, which would be fine, but more often than not, I discover major issues that make the data unusable. As the system is quite complex and has a lot of moving parts, it can take many hours across multiple teams to find the root cause of an issue and even more time after it's been resolved to collect enough new data to be used in a report.

The people I'm presenting to are non-technical and aren't interested in hearing excuses about why a report wasn't finished by the deadline. As I am the one responsible for delivering the results, I am also the one who bares most of the responsibility for the failure to deliver. It also doesn't help that I'm fairly new to the company and everyone else on the project is a senior leader with many years' worth of successful deliveries under their belts.

Going forward, what can I do to manage expectations and reduce the amount of blame for a missed deadline that lands on me?

Answer 1

Going forward, what can I do to manage expectations and reduce the amount of blame for a missed deadline that lands on me?

I sympathize with your problem.

Yes, you must "manage expectations", but the time to do that is before the deadline arrives. Giving "the surprise" of a missed deadline is one of the worst things you can do to business types.

The aspect of surprise is often worse than the actual consequences of missing the deadline. It means, to them, that they can't trust you. It means that if they give you something critical, there is a possibility that you could fail and that you won't tell them until the time at which they're expecting it. THAT is very scary for business people who make a living by making promises and then delivering on those promises.

What this also means is that a missed deadline isn't necessarily a big deal. Deadlines slip ALL THE TIME. The missed deadline is tolerable if everyone knows, in advance, that the deadline is slipping, that reasonable efforts are being made to close on the project, that unforeseen obstacles are being addressed as they pop up. Most people are rational and understand that there are unforeseen problems in every project.

The best thing you can do is to provide an estimate of completion date that is as accurate as you can make, and then provide timely updates if you see the completion date slipping further into the future. If you do this, you can also make fairly aggressive demands for help, resources, and cooperation if it is framed in the context of hitting the deadline.

Answer 2

I don't have a lot of knowledge in your field, but if I could, I would transition to working where I can at least provide some information when due.

I'm not sure, but it sounds like your model is a house of cards, where the slightest misunderstanding from the offset can cause it to crumble down? Can you restructure how you use data so that you don't have high levels of dependencies on certain parts of it. Are you able to do early checks on the validity of the data before you go down the rabbit hole too much?

If I was your manager I'd ask when the common strategies are for overcoming these obstacles. For instance, in my domain (programming), if a manager asked how we can avoid setbacks regarding bugs, I'm discuss peer-review, continuous integration and the like. Given you seem to be the most senior person with this knowledge, it's your role to come up with solutions.

Rather than reduce blame, you should consider reducing the impact of a missed report.

In answering your question, you cannot simply arrive at a meeting without the work that you have meant to have finished. You need to keep your manager abreast of any issues you are having, and be proactive in finding solutions. If you are scheduled to present information in a meeting, and you don't have that information ready, you need to let your manager know before the meeting, and have a revised timeframe ready.

It's also quite possible that the fact they are non-technical doesn't matter. They want results, and don't care about excuses, even if they many or may not understand them.

Answer 3

You said:

A large part of my job has become analyzing the new data and making recommendations on how to leverage it. I'm generally expected to produce results within a short amount of time, which would be fine, but more often than not, I discover major issues that make the data unusable

The key you need to understand is, there will always be "issues" with data. By nature, data is a digital representation of some real-world event or some tangible thing. You will never get to a stage where your data is always "perfect" in the sense of completeness and accuracy. Sometimes the issues will be true errors (a customer lives in New York but your system incorrectly has an address in California). But other times, even if the data is technically perfect, there will be issues in the sense of interpretation (the customer lives and works in California, but they own a warehouse in New York that they have your product shipped to - what do you use as their address? Your shipping department says New York, your billing team says California). The truth is, the business world is littered with abandoned analytics and business intelligence efforts, because companies walk away from them due to the inability to achieve perfect results, or just the shock when results aren't perfect in the first place. Data being good enough for operational purposes doesn't always mean it's good enough for analytics.

As such, you must learn to produce with imperfect inputs. The key to doing so is understanding the imperfections, mitigating where you can, and explaining them as part of your deliverable instead of trying to cover or hide them, or worse, assuming you need to fix all of them before finishing the project. Obviously, there are truly some cases where you can't just "live" with the results (half your customer's addresses are wrong because of a bug in your ETL) but there are other cases where an explanation as part of the deliverable can help communicate the impact the issues have on the result ("this report is based on shipping address, although some customers have billing addresses in different states" or "the trend we're showing is relevant despite a 10% inaccuracy in addresses").

Often, the work needed to accomplish this starts early in the project - identifying critical points in the data, ensuring you understand the chain of custody for that data (how and why it moves from system to system, quality checks in places, etc), and most importantly, ensuring you understand the interpretation your audience will have so you're not building a system on the wrong elements (do they want the billing address or the shipping address when they say "customer's address?)