2

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?

  • "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" - ask those people how they've been successful given the obstacles at hand? – dwizum Mar 19 at 13:04
  • What are the typical timeframes for each new analytic undertaking, who sets those timeframes, and how do they determine how much time you're allowed? Do you have any historical data about the delays you've experienced? – Upper_Case Mar 19 at 13:46
  • 3
    Work out what the RAIDs are (RAID: Risks, Assumptions, Issues, Dependencies) and tell the people you answer to about them well ahead of your deadline. When they accuse you of giving 'excuses' refer them to the place in your RAID report where you highlighted that data from BigCorp has been unreliable in the past and you raised it as a risk two weeks ago - for example – Dave Gremlin Mar 19 at 17:17
  • 2
    Reporting directly to business people is always risky always feed them a risk of delays even if you believe there's no reason and always warn them of edge case scenarios from the beginning – user86742 Mar 19 at 19:06
4

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.

  • 1
    Great answer. I'm also an analyst, and when something like this comes up that messes up the timeline I've previously given that gets transmitted to my boss right away, along with a new estimate and possible alternatives (if any). – Upper_Case Mar 19 at 13:48
  • +1 The OP should put themselves in the position of those watchign the presentation; they asked for something to be done and the first time they discover there's something wrong is in the presentation. They go in expecting to see the finished product. They need to be warned, as soon as possible (and perhaps even just before the presentation) about the potential problems – Dave Gremlin Mar 20 at 9:54
1

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.

1

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?)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.