[music]

0:00:05.8 Announcer: Welcome to the Analytics Power Hour. Analytics topics covered conversationally and sometimes with explicit language.

0:00:13.9 Michael Helbling: Hi everybody, welcome to the Analytics Power Hour and this is episode 231. At some point, if you continue to progress in your analytics career, you’re going to be come up with the estimate for how long an analysis, a project or a piece of work will take. And well, sometimes that doesn’t go all that well. Sometimes the goalposts move, maybe people want what you are making much faster than anticipated or sometimes things go amazing, everything is on time and you are beloved by your business partners and peers. Speaking of beloved by their peers, let me introduce my co-host for this episode, Moe Kiss. Welcome, welcome.

0:00:53.6 Moe Kiss: Hi, thanks for describing the dream state there at the end.

0:00:57.5 MH: Well, yeah, I figured it’s not going to be all negative stories, right? We have some positive events.

0:01:01.1 MK: Sure.

0:01:03.0 MH: And Val Kroll, also here today. Thank you for coming. Welcome.

0:01:07.4 Val Kroll: Yeah, I’m excited to talk about how I’ve never worked on a project that didn’t go amazingly. So I hope I have something to contribute to this conversation.

0:01:16.3 MH: We need balance ’cause most of mine have gone very poorly. No, I’m just kidding. I’m like, overly. So in this episode, we’re talking about estimating effort for analytics projects. So to get us started, does anybody want to share an anecdote of an estimate that didn’t go so well?

0:01:33.0 MK: Wow, getting right into hot and heavy.

0:01:36.1 VK: I’m like, yeah, way to really throw us in the deep end.

0:01:39.9 MH: Well. I mean, it’s, I feel like it’d be relatable. I don’t know. I’ll tell one. I don’t care. I had, in the consulting world, a lot of times you work with different partners and one of those partners would go and sell their product to companies and then they would send us the consulting work. Well, their efforts to estimate were not usually very thorough. And as a result, a lot of times the very first conversation you’d have you bought in to do the project was the estimate you think is going to do this project is not the estimate that’s going to do this project. And so right out of the gate, you have angry stakeholders and an angry partner because you basically said their estimate was a piece of garbage. Usually we were right, but it was an awkward way to start any relationship. What’s cool though, is that by being upfront about it at the very beginning, a lot of times it got us into a place of trust with the client at least and we were able to make progress from there. But yeah, sucky way to start a project would be like, “Yeah, this estimate that you think is going to get all these wonderful things you think are going to get done. Yeah, definitely not going to happen.” So yeah, that’s one thing that I’ve definitely experienced. Anyways, maybe you have something something a little better.

0:03:00.3 MK: So you noted or you gave one of the root causes of a bad estimate on in that case is lack of thoroughness from the partner. Do you think it was thoroughness or were there some other causes there? ‘Cause I don’t even… Are the motivations aligned appropriately for them to estimate that correctly or do they know what it actually takes the person who’s estimating?

0:03:22.0 MH: Well, so again, like this all comes in that particular scenario, you’ve got many layers working, which is you have probably somewhere someone has put together a playbook of some kind which is, this is our standard approach it should take about this amount of time. And then that goes through various departments and things throughout a big company and gets misshapen into then to somethings that look what it comes out as at the end. And then there’s then perspective of how to do it from our point of view, which was different than the point of view of maybe the vendor themselves. So that misalignment then creates problems in terms of how you go out and execute. And so that’s really what at the heart of it is. Nobody’s trying to do a bad job, it’s just a different set of expectations going in.

0:04:10.5 MK: But that’s the thing. It is such a freaking hard skill. And it’s so funny. I was so intimidated doing this show with the two of you because I immediately was like, “Oh my God, Val and Helbs are so good at this. This is like their bread and butter.” This is not a skill, I think, that I would say that I’m very good at. I can definitely work my way through it, and I don’t know if that is a reflection of my experience or it’s just not something… Like it’s a skill that I’m less good at. I don’t know. But it is interesting kind of across the board. Like I’ve obviously been in-house for most of my career, I’ve had a little bit of time working at an agency. And I do remember when I was kind of floating around for a little bit on my own doing some consulting and messaging my lovely brother-in-law Lee being like, “I need to do a statement of work and an estimate,” and like, “Can you help?” And he had to send me all his templates and I still was completely overwhelmed and terrified and didn’t quite know what to do. Yeah. But like Val, you and Helbs have quite different experience to me.

0:05:17.4 VK: Yeah, Helbs, you’re like the exact opposite of Moe, right? Like most of your time has been in the agency consulting world, a little stint or two in-house. And I think I’ve kind of been like…

0:05:26.0 MH: Yeah. Three years.

0:05:28.0 VK: Three years. And mine’s been like more 50-50 kind of jumping back and forth. And so I would actually argue Moe that you’re probably better at it than you think just because you don’t put hours in a Work Breakdown Structure by all the tasks and milestones and have all of your assumptions laid out about what is or is not true. You still have to coordinate a lot of work and effort across the resources on your team and make sure that the work is prioritized and is focused on the right things. And so I think probably a lot of it is just is represented much differently in-house. I know that when I was in-house, my first in-house role in digital analytics was at the American Medical Association. And we were very much, we tried to run our team like an in-house agency ’cause I always felt like we’re going to be in competition with whatever next piece of work could be bit externally. And so we set some goals that I actually used from my prior agency side to hold ourselves accountable with like SOPs and like turnaround times on communications and things like that. So I would say that you’re going to have a lot to add in this conversation.

0:06:31.0 MK: Oh, so tell me more about this. So like your turnaround times on communications, like you would set that with your team as like, this is the expectation. Tell me more about that.

0:06:43.2 VK: Yeah. So one of the things that you learn on the consulting side agency side is the confirm receipt email because your client never wants to think like, “Did that message go off into the ether? Did they hear me?” ‘Cause they know that… Most clients know that you’re not their only client that they’re looking at or focused on but they want to make sure that their needs are prioritized. And so we very much had the within 24 hours, at least a confirm receipt email, if not like an answer or this would be better for a meeting, I’m going to schedule time for us. But definitely taking the ownership of communication on and setting the expectation for what excellence looks like. We wanted our clients to be able to expect a lot of us as if they could get a similar level of service if they were to bid the work externally.

0:07:25.5 MK: Oh, I really like that.

0:07:26.9 MH: That’s nice. Yeah. It is interesting when you’re in-house I feel like though you don’t have as much… You don’t necessarily always have to have as much rigor around an estimate because you’re not necessarily beholden to like very specific deadlines. Although, I will also say when you’re in-house, it feels like sometimes the deadlines are applied to you more than you’re sort of saying, “We’ll do this by then.”

0:07:55.8 MK: Yeah.

0:07:56.0 MH: Because you’re working within the structure of the business itself. So it’s sort of like, “We’ve got to have that by next week.” So come hell or high water, you got to find a way to get this done. But there’s lots of ways that happens. Like a lot of analytics work happens in the sort of like agile types environments where it goes into a sprint and you sort it with points and I don’t know…

0:08:19.0 MK: T-shirt sizing.

0:08:19.9 MH: I’m not a pro. Is that a thing? Really?

0:08:22.1 MK: Yeah, small, medium, large, extra large. Yeah.

0:08:26.1 MH: Okay. Well, there you go. That’s one new one on me. I think that’s… So, but those are the different ways I think it can happen. But then if you’re doing sort of like a bigger project, then yeah, you just want to lay it out based on sort of like, “Well, what we’ll get done when, and what are the dependencies?” And sort of build those things up.

0:08:43.8 MK: I’ve got to ask the thing that’s totally obnoxious. And yes, I have limited agency experience, but there is this perception when you’re in-house. So like the bit that we probably find the most difficult is that yes, we’re trying to scope a project or a piece of work, but we’re also fitting that in amongst all of the other things we need to deliver for those same stakeholders or for competing stakeholders, which creates quite a bit of tension, and yes, insane need to prioritize and stack rank and all of those sort of things. And sometimes… Well, not sometimes, almost always the long term important work will get shelved to pick up urgent, less important things. And there is, I guess, this perception that agencies don’t have to deal with that shit, which I don’t totally agree but when you’re agency side, you can choose to say yes or no to projects or like push back on things. Whereas sometimes I feel like in-house, you kind of are at the mercy of the way that the ship is going. You can’t jump off and be like, “No, we’re going to catch a different, we’re going to catch a plane instead.” That was not a great analogy. I’ll let that one go.

0:10:02.7 MH: No, but I think you bring up a really great point. Val, I want you to talk about this too. But the tyranny of the urgent, I think is ever present. And I would just say, when you’re working with clients in the consulting or agency space where you’re not working against like a specific scope that you’ve already agreed upon upfront, like, this project, we’re going to do this. So maybe it’s like a little more open ended, like we’re an extension of your team and you need to come to us and we’ll help you with things or whatever that might look like, it can get pretty crazy. And really the wheels fall off at the point of who the point of contact is for the client really. Because if they’re just a yes person, then everyone’s going to be running around with like their hair on fire all the time. And so I’ve seen it done well, and I’ve seen it done poorly. And it impacts the flow of work in an agency setting just as much I think.

0:11:02.2 VK: Yeah, definitely a lot of differences in project work versus retainer work, like you’re talking Michael, where you say, there’s a bucket of hours and we’ll work with you primary contact to prioritize week over week or month over month. However smaller frequent those conversations need to happen but there’s definitely times where you feel like your chain is getting yanked along with the priorities. And a lot of times when we hear it, we have even less context than you do, Moe, for why some of that’s happening. Like sometimes you hear in like week two of dumpster fire number four, like, “Oh, there’s a big meeting that we’re preparing for, ” or that they’re trying to march against that they didn’t know that they’re going to be a part of into the last minute. So I think we get some of that but it’s easier for us to say like, what things do you want us to de-prioritize in place of this? And so I think it’s a little… To your point, I think it’s a little bit easier for us to negotiate.

0:11:52.0 VK: And the other perspective that I’ll add to this is because client delivery and those hours for those accounts is what brings in the money, a lot of times we will have the balance between client work and what we call like non-bill. So other priorities that are in-house, so initiatives of, we really want to standardize a template for XYZ because there’s a lot of great thinking, but how do we memorialize it for the next time that this comes across our desk? So it’s always hard and always a struggle to make some of those things a priority for the exact same reason.

[music]

0:12:26.8 S1: All right, it’s time to step away from the show for a quick word about Piwik PRO. Tim, tell us about it.

0:12:32.8 Speaker 5: Well, Piwik PRO is easy to implement, easy to use and reminiscent of Google’s Universal Analytics in a lot of ways.

0:12:38.5 S1: I love that it’s got basic data views for less technical users, but it keeps advanced features like segmentation, custom reporting and calculated metrics for power users. We’re running Piwik PRO’s free plan on the podcast website, but they also have a paid plan that adds scale and some additional features.

0:12:53.9 S1: That’s right. So head over to Piwik.PRO and check them out for yourself. Get started with their free plan. That’s Piwik.PRO. All right, let’s get back to the show.

[music]

0:13:05.7 MH: All right, let’s estimate a project together.

[laughter]

0:13:09.2 MK: I actually do think, look, I’m not going to lie, I’m going to not talk through most of it, but I think that’s a great idea so we can all, well, I can learn and our listeners can.

0:13:17.0 MH: Well, we’ll do a couple of examples, I think. So here’s one that I think has happened to all of us at some point. We’re an analyst sitting at our desk working on things. Somebody comes up and says, “Here’s this business problem. Could you pull together some analysis that I could see on that? How long do you think that’ll take?” So let’s start there, right? So that’s what we’ve got so far. So, okay, what do we do first to estimate out? Okay, well, what is the answer I’m going to give to this person who just asked?

0:13:49.8 MK: Oh my God, can I say what I would do first and you guys tell me if I’m wrong?

0:13:53.8 MH: No, go ahead. Yeah.

0:13:55.4 MK: I would reverse brief first.

0:14:00.0 MH: Okay, I think that makes total sense.

0:14:01.0 MK: That is like literally the first step that I would do to make sure that I understand the task correctly.

0:14:06.4 MH: Yeah. So I feel like at that point the questions that you ask to refine what the request is, is probably the most important thing about estimating that you could do, ’cause if you don’t understand or fully get what they’re exactly or why they’re asking it, those kinds of things. And our analytics industry is so full of like the analyst should ask why, why, why. And it’s hard because we expect people to just be like, why machines? And that’s really annoying. But there is a way like the way you said it, Moe, like reverse brief it. Like, let me reflect back to you what I think I’ve heard and make sure that’s getting at those things. Let me understand the context better. Those kinds of things. So asking questions or figuring out, did I really get it? Okay, I love it. What do you think next is gonna… What do you do next?

0:14:58.9 MK: This is where I put my hands up and say, Val.

0:15:03.5 VK: Well, is this so for this for this role playing, which I love this. Is this an in-house example, Michael or what?

0:15:08.9 MH: Yeah, yeah. So this is like an in-house example where we work within the team. We’re all in the same team. Yeah. We’ll do a consulting example after this one.

0:15:17.8 VK: Yeah, ’cause in this scenario, you don’t need to ask expectations about like the tech or access or all of that, those battery of questions. We get to skip forward because we’re assuming that we have some understanding of that. I think the clarification in that like early discovery, I can’t even think of a better word for it. I know it’s in-house, but doing some of that initial discovery is really what’s going to allow you to put together kind of like your assumptions document or like your analysis outline. That’s really going to kind of scope it. So I think after you get your first set of questions answered, it’s a little bit of work on you to kind of put some boundaries and parameters around it. And then I would have a follow up discussion to review and kind of say, here’s what I heard, can you please correct or fill in, or there’s a couple more questions that I thought of as this marinated a little bit just to make sure that everyone’s kind of head nodding before we start putting hands on keyboards.

0:16:09.3 MH: Yeah, I like it. I’m always reminded of Tim’s hypothesis.

0:16:16.8 VK: Library?

0:16:17.4 MH: Library. Yes, about this formation like…

0:16:19.7 VK: Oh, yeah. The template.

0:16:20.0 MH: If I learn this then I’ll do this, ’cause I’m often whenever I’m getting ready to like analyze something, a lot of times as I’m taking notes or thinking it’s sort of like I’m trying to write down the key questions that I’m trying to answer. It’s like, here’s what I’m trying to actually answer and that’s what I’m honing in on. So I feel like that’s really like that first step for me is like that’s the important step. And then a lot of times forming it into some sort of hypothesis. I think the next thing after that for me is to determine how familiar I am with that data. So like if is it a data set I know really well, or is it a new set of data or… So this reminds me a lot of the episode we just did with Viyaleta Apgar, look getting to know your data set. So I feel like that’s the other one is, okay, do I need to ramp up on this data or get to know what this data is looking like? Is it data I’ve got a high contextual awareness of so I don’t need to go do a lot of ramp up. I can just dive right in. And so like, that’s the other thing that I would probably start to think about too from that point.

0:17:23.0 VK: Yeah, I love that you brought up the hypothesis framework, Michael, because that gets you thinking about, “Hey, business partner, are we aligned on the action that you’re hoping to take from this bit?” Which can really change the context of the way you approach it or like the fidelity that you need to perform the task at. So I think that that’s huge. That’s a great call out. So what happens next?

0:17:43.6 MH: Then I just make up a number.

[laughter]

0:17:46.8 VK: You pull out the dartboard.

0:17:48.8 MH: That’s right. Sandbag the shit out of it. That’s what I do.

[laughter]

0:17:55.0 VK: I think the only other thing that comes to mind for me that I would do is I would want to set expectations and kind of like a communications cadence so that you’re not like going off into a cave and like, “I’ll re-emerge in six weeks with a final product and hopefully it’s what you’re looking for.” But just deciding like depending on who it is and how senior they are and out of office calendars, like when are we going to check in? What they can expect from you? Just really that expectations side.

0:18:20.9 MH: Yeah. Or maybe like, what’s the level of this? Do you need just a quick and dirty? Do you need like a full on presentation? That obviously matters quite a bit as well. It’s like, do you need me to send you an email with five numbers in it that shows you what I’m trying to do? Or do you need me to set up the storyline and the PowerPoint behind it and all that stuff? ‘Cause that takes a little more effort.

0:18:41.0 MK: One thing we haven’t asked, or like, I know that we’ve talked a little bit about like initial discovery and that sort of stuff, but there’s kind of one really important thing as we start to move closer to actually estimating the time, is whether the stakeholder has a deadline. So, do they have a meeting they need this for tomorrow? Is this for a thing next week? Yeah, like I assume that probably would have happened in the initial discovery, but I’m just going to explicitly call it out.

0:19:12.8 MH: That’s fair. And that’s what I mean by like when you work inside a company, sometimes the estimate deadline gets picked for you, because it’s sort of like, “Oh, I’ve got a board meeting next Tuesday, so we’ve got to have it by Monday.” Okay, well then it doesn’t really matter what my estimate is. I now know when this needs to be done by and that’s it. And then you just have to reprioritize as needed.

0:19:34.2 VK: And adjust the fidelity at which you can complete the task. So like, I can give you ballparks by next week. If you give me three, we can get something a little more accurate.

0:19:42.9 MH: Yeah. And then I think really, I just go through a process of like, thinking about analysis I’ve already done, and the steps I’ll take, and then just sort of vaguely thinking about, okay, this is probably about how long it’ll take to do. And everyone, I think, has a different process for that. I tend to explore a lot of different ways of looking at the data. So I kind of like, I will end up doing probably 2x the amount of analysis for free, usually, before I actually come up with what I think is the right answer, which is not great from a time management perspective. But it’s just the way that I… Like I just want to look at it other ways, so we’ll just pull it apart in different ways and try to think about it. But see if anything’s there. Sometimes it’s useful, sometimes it’s not. And then sometimes you don’t need to do that ’cause you know what you’re doing. But then it’s just a matter of saying like, “Okay, I think we can get it to you by this date.” Or like, “If you have this, okay, I can balance against these other things that get you a version by this time.” So it’s pretty simple.

0:20:53.6 MK: Easy peasy.

0:20:54.9 MH: Love it. We’re great. We would be so good. Like if we were analysts in a company, we’d be awesome.

0:21:01.4 MK: So Michael, do you want to walk us through what some of the processes on the agency side, just calling out some of the big differences, the big departures?

0:21:11.0 MH: Well, the I mean, the first thing is, is you know so little about any of the context when you are a consultant outside. So you have to be really careful about making assumptions, like about their data, about their process.

0:21:25.5 MK: I was gonna say like their tooling or like, even what you’re going to have access to?

0:21:30.1 MH: All those things. Yeah. So all of that stuff starts to matter and you have to sort of lay out sort of like an ideal scenario. And Val, you and I probably both come from the three-pager Work Breakdown Structure school, given where we both work.

0:21:50.0 MK: You’re gonna have to say more about that.

0:21:52.5 MH: Well, so Mike Gustafson, who’s my old boss, brought in at Search Discovery sort of this method for estimating projects, which basically was three sheets in an Excel file or Google Sheet. The first one was a very clean description of the project itself with the stakeholders, what are we trying to do? What have we heard from the client? What are we going to produce? So basically, you read that you kind of know what the project is about. The second sheet is every task and role and what we think the time is for that. So how much time is going to take?

0:22:23.4 MK: Kind of like a Gantt chart or no?

0:22:25.3 MH: Not yet. It’s…

0:22:26.2 MK: Okay. Okay.

0:22:27.7 MH: It’s this one is not necessarily over time yet as much as it’s just listing out everything we know needs to get done on a project.

0:22:32.9 MK: Yeah. Okay.

0:22:33.6 MH: And then the third sheet is the application of a timeline to that same set of tasks to like lay it out over time, say when it’s going to get done.

0:22:41.1 MK: So I do love I really love a Gantt chart. Like I like hardcore love them. It’s so weird. I probably try and use them when they’re not appropriate.

0:22:50.9 MH: I think it’s a skill to be good at them and I’m not skillful with them at all.

0:22:56.1 MK: With, oh, with Gantt ‘s or with Work Breakdown Structure?

0:22:58.1 MH: No, like Gantt charts. No, I think I can estimate a project pretty well.

0:23:02.7 MK: So can I reflect on something? We’re talking about here data practitioners really having to do this. And the thing that I find kind of interesting about it is, ’cause this is like coming up a lot with this whole theme of like data product managers and stuff. And then also like the role of ops people in the business. These are often skills at like PMs and ops people are like, this is a bread and butter. They can do this stuff for breakfast. And I personally am starting to get to the point of like there are really good reasons to have cross functional teams where data team have the support of ops and/or PMs. Not only like especially in-house from like a PM side to help with like breaking down the strategy, the vision and then the like projects we want to do to get to that vision and then break it down into milestones and tasks and all that sort of stuff and really communicate it effectively.

0:24:04.4 MK: And then the same with ops trying to really help with handling that BIU prioritization of urgent requests, making sure things don’t… Like the lights don’t turn off on anything. But like we’re really talking about data practitioners owning this end to end. And I guess what I’m trying to wrap my head around is, do you think there is a point in like team size or scalability where you go actually, it no longer serves our purpose to have every analyst in the team doing this on their own and that we should bring in some of those other specialties or like… I don’t know. I’m personally wrapping my head around this at the moment and I don’t know the answer.

0:24:49.7 MH: It’s a good question. I think the answer is sort of yes, but. And this is sort of something I was going to talk about later on, which is when you’re doing an estimate or estimating a project when you’re not going to be the one doing the work, this is where I think this kind of comes into it. So let’s say we’ve got a team and we’ve got a project management person with a great set of skills for this and they can really help us with that. What I’ve seen happen is there’s this balancing act that you have to strike between that person assisting the team effectively versus taking over the prioritization and running people’s lives without knowledge of what the work actually is.

0:25:33.9 MK: But isn’t that how engineering teams work? Like the PM, like the engineers…

0:25:41.8 MH: I don’t know.

0:25:42.1 MK: The engineers help with sizing the task, and that’s where t-shirt sizing is often used.

0:25:45.8 MH: Well sure. And that’s what I mean. You just have to make sure that you don’t lose the connectivity ’cause the second the PM thinks they know it all and they can do it themselves, they’re going to make some terrible error and your estimates are going to get real bad and everybody’s going to hate their life. So I won’t send a project out unless I’ve checked with who I’m working with on the project and get their validation. Like do you think this makes sense? This structure, this estimate, does that sound right to you? Any questions you have? What am I missing here in the detail? ‘Cause especially like I estimate projects all the time in areas where I don’t have a specific set of skills. So it would be like data engineering tasks or data science tasks and things like that where that’s not my strong suit.

0:26:34.8 MH: So I very much will lay out what I think it is I can structure it, but I go to the person and team and say, what do you think? How does this look to you? What am I missing? And sometimes the opposite is true where someone who has a specialized skill set will throw together their version of it. And I’ll be like, have you thought about whether or not you’ll need to spend time doing this? What about time spent doing this? What about? And they’re like, oh, yeah. ‘Cause sometimes when you’re really good at something and you have a high degree of skill, you sort of skip steps and don’t think about every little detailed step. And so like, that’s the other thing about being a good estimator is thinking about every single thing that might possibly need to happen or go wrong when you’re working through this.

0:27:17.6 MK: But that’s like, PMs do that, right? But they, I would say they would more add a buffer of like, I’m going to add a 10% or a 15% buffer to whatever my engineer has said the time is going to take, because I just know that that is going to lead to a better business outcome because then we’re more likely to deliver on time, versus… But I like the way that you’re thinking about it of like, what are the components of the tasks that are missing?

0:27:43.5 MH: Yeah. And there’s way better people out there who know how to do those kinds of like mathematical estimating. The very simple method I was trained on many, many years ago is like make a high estimate, make a low estimate, add them together, divide by two. Like that’s like, Okay, pretty close.

0:28:02.1 VK: Which, disclaimer, is not necessarily the current Search Discovery approach for any listeners.

[laughter]

0:28:06.1 MH: No, no. That’s not even my current approach today at all. And that wasn’t at Search Discovery that I learned that, it was before that.

0:28:15.4 VK: Just want to throw that out there, clear it out.

0:28:17.7 MH: But it’s it’s not super scientific ’cause it’s sort of like, well, what’s your best guess? And then you do have to sort of, Moe, like you said, build in some sense of contingency of like, okay, if anything. But that’s where assumptions come in. I think that’s where you say, I’m assuming it’s going to go like this. If it doesn’t go like this and these other things enter into it, then my estimate is trash at this point, we have to reconfigure it a little better, change our approach. So this is why when you estimate out a project, you also layer in all of those assumptions that say, here’s how I’m thinking this project is going to go. I am assuming, for instance, you’ll give us access to your systems by the second week of the project. So we’re not sort of just all sitting, spinning, twiddling our thumbs for a month and a half while you think we’re getting work done. And you haven’t even given us a chance to work inside the system yet, which has never happened, by the way. It’s great.

0:29:12.3 VK: Never, never. Definitely not currently experiencing that. But one thing I just want to touch upon back to what you were saying, Moe, is I think that I don’t necessarily have a POV on like at what point or size of the team that you decide to bring in that role. But I will say that this is one of the few areas where I do think experience is important to build intuition around what some of these things take to get done. And like Michael said, to understand what the average of the norm is, so not just for yourself. But if you have really good estimates, I feel like a project manager should be able to run with it. Like with that input phase, that estimation phase, I feel like is the one thing that’s still precious that should be still in the analyst’s hands, unless it’s something that’s like super rote and repeatable. Like, you have like a report that you’re doing if you’re in-house, like a quarterly meeting that you know you’re going to need to prepare some things for. That might be something that you can just like plug in.

0:30:04.3 VK: But I do think that this is a lot of experiences because to your point, Michael, when we’re bringing up some of our junior mid-level talent, bringing them into like BD process and scoping, I always feel like they err on the side of underestimating. Like, really, I’m like, whoa, we won’t need that much time for it. But it is all about like giving the right space for those considerations. Just some of the things that you don’t even think about necessarily all the time. Like, this is a financial services client, so I know that this is going to be true. Or they’re a center of excellence model versus distributed, and so this means we have like three stakeholders versus one or… So those are those impact estimations and assumptions.

0:30:45.0 MH: Yeah. The size of the company will impact it. If it’s a small company, you don’t have to do as much administrative overhead. You could just go direct to the stakeholder or the business partner and get stuff done and have one meeting instead of five.

0:31:01.9 MK: So on these junior people like underestimating. So here is random anecdote about a thing that I read that I don’t remember where I read. Amazon… Was it Amazon? I think it was Amazon. Oh, no, maybe it was a previous company I worked at. Anyway, there used to be like an estimate for delivery of your package. And people would always try and be like, oh, it’s going to get there in two days because two days is super fast. It’s going to get there in three hours or whatever it is, like the quickest time possible. And then if you went over the time, generally customers would be pretty unhappy because it’s like, “You said it would be here in two days. It’s taken three.” So then you actually flip it and you go, it’s going to take three days. It arrives in two and you have a much happier customer because they’re like, “Oh, my package arrived early.” I think that way about estimating, but I think junior people don’t. But I really wanted to throw this out there and get your perspectives.

0:31:58.8 MH: I agree. Yeah. Everything is about expectation setting because I always get the calculation wrong. But I was always taught like client satisfaction is expectation minus results or something like that. Is that the right way to say it? Experience, experience. Expectation minus experience. So if you say… Or is it experience minus expectation. See, this is what I always get wrong. Anyways, the point is wherever you set the bar for what their expectation is, now you have to deliver above and beyond that to make them happy like this. So of course you you tell people like, Oh, yeah, I’ll get that to you by Friday and then you get it to them by Thursday. That’s way better than getting it to them end of day Friday. And there’d be like, okay, you just made it out of the bar or Monday because you forgot and did it over the weekend, or whatever the case may be.

0:32:56.7 MK: But do you think people get like a reputation for doing that a bit too much?

0:33:00.2 VK: I was going to say that’s not like an always kind of thing. If you say it’s Friday and you do it Friday and you do it Friday morning, you’re still going to have like a happy client.

[overlapping conversation]

0:33:12.4 MK: Yes yes.

0:33:12.5 MH: Its totally fine.

0:33:13.6 VK: Same fucking time frame. And if you’re going to be late on it, try to tell them before or Friday and well, yeah, set expectations that way. It’s like always just recalibrate and show that their best interests are your interests.

0:33:27.8 MH: But do you mean, Moe, like if you always are adding an additional day and you’re always getting onto the deadline, these people start thinking you’re just a bad estimator.

0:33:35.2 MK: Or that you’re trying to you’re trying to under promise so you can over deliver. So you have a good reputation.

0:33:40.3 MH: Yeah. I think that all comes back to sort of the perception of the person and how what you’re throwing off is a vibe a little bit too. ‘Cause if you’re hanging around to get the attaboy at the end of that, like, well, maybe people start to question, like, what are you doing here? But if you’re just sort of like, you’re doing your job and trying to do a great job, they’ll be like, “Wow, they’re really pulling on it, and they did a day early. We really appreciate it.” So I think it’s fine but I think you just have to don’t try to game it. It’s not a thing you hack. You’re building relationships here. You’re not trying to work… It’s not a video game. It’s like real life.

0:34:22.7 MK: Okay, so next big question. Sorry. I’m getting so much out of this, I’m actually taking notes.

0:34:26.5 MH: No, this is great.

0:34:30.2 MK: Scope. So I feel like when you’re agency side, there are definitely times I’m sure there is like a bit of scope creep or a request for scope creep. But I feel like when you’re in-house, it is almost inevitable and incredibly frustrating because you’re like, you put in all this work to be like, this is what we’re doing. Like, I almost… I mean, when we write design docs, we do have a section that’s called out of scope. But that doesn’t mean it’ll be like, oh, but priorities have changed. So like now it’s in scope and you’re like, fuck.

0:35:06.3 MH: Not for me. It’s not.

[laughter]

0:35:09.4 MK: Yeah. Like, do you think that reflection is accurate or like, do you think there’s just as much pressure either way?

0:35:12.8 MH: Well, again, it’s all about management, like how you manage that. I always think about scope as sort of like hostage negotiation. I never tell anyone no, but it’s different how I say yes. So in other words, it’s not just sort of like, “Okay, I accept whatever you’re going to say.” I say, “Okay, yeah, I think we can fit that in. So what we’ll do is we’ll deprioritize this, this and this.” And then they are suddenly faced with like, “Oh, I don’t want to de-prioritize that.” “Oh, Okay. Well, that’s Okay. Well, let’s work this out. Do we want to just maybe like do less of that?” And then, so basically you make it a negotiation at that point. Well, you’re super agreeable and friendly and never saying like, “No, we can’t do that.” You’re totally like, “Yeah, well, we’re definitely here to help you. And we’ll see what we can accomplish.” So what we’ll do is we’ll just stop working on these other priorities. “You’re okay with that, right? Jen, we can do that. You’re willing to wait a couple of weeks on that.” And then Jen’s like, “Well, I don’t want to wait on my project to get done.” And so there, you make them fight it out. And then…

0:36:25.2 MK: God I just… The more time goes on the more I like kind of want to watch Helbs in action. And I’m like a little bit jealous that everyone else has gotten to. And I’ve never seen it ’cause I’m always like, oh, that’s so smart. Why can’t I say that?

0:36:38.0 VK: Masterful.

0:36:40.9 MH: First off, I don’t think so. I don’t think it’s… I think I’m just sort of like plugging along. I’m just a normal guy. But that’s all it is. It’s like you’re always there to help. That’s the thing is you never want to be that no sayer because that loses people’s interests and trust and confidence, and you’re always trying to build that up. And so that was when people are coming at you with multiple priorities, you have to kind of… It’s the Aikido right of taking their force and using it against them, and like spinning it back around. It’s like, wow, you’re coming in with a big request. Wow, that sounds really important. Let’s move everything out of the way so that your important requests can be handled. And what I’m going to bring all of a sudden, all these other things are toppling over because of them, and you’re just a conduit like you didn’t do anything wrong. And sometimes people will try to call you out and be like, “No, all of these things have to be done. Everything’s a priority.” And you’d be like, “Well, if everything’s a priority, nothing is. And you’ll just get it when I get done with it. And if that makes you unhappy or whatever, we should probably just have a conversation to the side about working conditions at this company or whatever.”

[laughter]

0:37:55.0 MH: And then you start replying to those LinkedIn recruiters.

[laughter]

0:38:03.3 VK: One of the things that I think occurs a lot, and I think it occurred when I was in-house to, Moe, I’m not sure how frequently you experience this one, but that the scope creep happens a lot in the presentation of an analysis or a conversation where you’re sharing it because you’re like, “Ooh, wouldn’t it be nice if we could also see this by, or.

0:38:20.0 MK: Yes.

0:38:20.6 MH: Oh yeah.

0:38:22.5 VK: And they think of like their 100 more questions and then you’re like, deep gulp like, “Oh my God, oh, I thought was done with this one.” So I think that like, that one, I think again, if you were to go back into edit, like what you’re calling your design document or like your analysis brief or whatever that is to kind of level some of those future requests against, again, like put it in a hypothesis like how actionable versus interesting are some of these things. Because sometimes it feels really nice in the moment, especially if you’re like, “Hey, I’m gonna show you the slide. Do you have any questions about it or other things to say?”

0:38:55.1 VK: Everyone’s gonna have something to say. Everyone’s gonna feel like their value in that conversation is measured by how many comments or more requests they make in time. So I think going back and saying like part two of this design document, like how much will those additional requests move forward this action or uncovering the truth about this business question you have, or demystifying or de-risking a decision. I think that that can also help, like, help you wade through what’s important to spend your time on versus what we can just like leave in that conversation.

0:39:28.3 MH: That’s good. Yeah. That’s an inevitable one where you Yeah, like what you said Val, that pops up a lot. And that interesting versus useful thing that’s a lot of wasted cycles in a lot of teams, I feel like.

0:39:43.2 MK: I feel like it’s almost, I mean it’s not worse in-house, but like there is definitely a lot of like, because you do have everything, I guess so to speak, versus like being limited by the data that you have. And so it’s just like, oh, it’d be really great if we could see blah, blah blah. And you’re like, oh, for God sakes.

0:40:06.5 VK: But Moe, I’m curious like how you prioritize and kind of orchestrate the work across your team. Just ’cause you’re not just thinking about like your own capacity, you’re thinking about A lot of people servicing a lot of different parts of the business. How do you work with them? ’cause I’m sure there’s some work that they have to do independently where you’re expecting them to be able to triage and appropriately set expectations and all things we’ve been talking about. But could you talk a little bit about how you handle that internally?

0:40:32.9 MK: Well, Val, I have six amazing team leads that each manage the work of their six teams. So that is a big part of it. I think what we have worked on, which is actually, look, I have mixed feelings about if this is the right thing or the wrong thing. I still don’t know, this is still a like, work in progress, but what we have found that we need to do is like the business we work in moves so fast and we have such like “urgent”, I’ve got to air quote, things that come up that we found the only way we can really prioritize important work is to have teams dedicated to longer term strategic projects. And like, I think we’ve been on this merry-go-round a thousand times of being like, “Oh, let’s spend 40% of our time on important work.”

0:41:25.0 MK: And it just often doesn’t happen. And so we’ve really been testing this structure where we have a specific team, it’s called measurement and strategic recommendations that work on the longer term projects or like bigger business impact questions. And then we also have a team that’s dedicated to data tooling. And what, I mean, I keep referring to it as a data lab and everyone keeps rolling their eyes at me because they’re like, that’s such a corny name. So it is not trademarked at all, but like somewhere like… We have a bit of an R&D function where we can do like exploratory work and like test out ideas and build out MVPs of solutions that we want to then build for the company. And so like the only way we’ve effectively been able to do that work is to create separate teams for it.

0:42:18.2 MK: I don’t know if that’s the right answer. And like there is definitely a conversation we have internally around like, okay, well if we’re gonna have this approach, we need to have high mobility within our teams because for the teams that are doing a lot of like the more like regular reporting and analysis and all that sort of stuff, we wanted them to have the opportunity to work on the longer term projects as well. So what we’ve been trying to do is move people around more regularly. But, and I don’t know if it’s right, it does seem to be working like I would say that the last sort of year, if I had to write down, actually I had to write it down yesterday, like the impactful work the team has done and I would say it has more than 10xed based on this structure. But, yeah.

0:43:00.2 MH: Wow.

0:43:01.8 MK: We’re now having business impact in like tens of millions of dollars which we were not having before.

0:43:06.9 VK: That’s incredible. I mean, I feel like the proof is in the body that it’s going well.

0:43:11.2 MH: Yeah. Just probably keep doing some of that then.

0:43:13.5 MK: Yeah. I think we probably will keep doing some of that, but I just, I don’t know. I feel like there’s probably a thousand other people around who have found a way to do this. And I always think of Emily, I’m gonna butcher her last name, Chikario, Chikaro, who seemed to have a really good way of making sure the team were able to split their time. And I just found like trying to split just doesn’t seem to work well. Like you have good intent, but it just doesn’t.

0:43:42.0 VK: I think one of the biggest trip ups that I had, leading that the team I was talking about before internally at the American Medical Association is I had two analysts underneath me for the majority of my time there. And we had essentially six stakeholder groups. And so we’re like, oh, three and three perfect. And then I was kind of like the floater and tying things together and whatever. And I was like, Hmm. But there’s one of the six is e-commerce and one of them is a foundation. Like there’s a lot of unique experiences here. So every six months, how about we flip flop all three and three.

0:44:14.3 MK: And you know, I mean…

0:44:15.0 VK: Do you know What that was like?

0:44:16.0 MK: Oh, what?

0:44:16.8 VK: When we got into that six month mark, oh my god.

0:44:19.8 MK: What happened?

0:44:20.6 VK: That was the worst idea I’ve ever had. Oh my, it was terrible. I mean, because they were so… I mean we were a small but mighty team and we would be really embedded in a lot of those business meetings. And so just the handoff, we should have done like one at a time, like traded them. But we tried to do a wholesale switch at the three. And I think that like our clients felt the pain and it was rip the band aid, was a terrible.

0:44:47.0 MK: I had a tech team where we used to self-select the teams we all wanted to go in. They were fully cross-functional. So we had full stack engineers, UX people, data people. And at the start of every season, like three month quarter, we would be like, these are the product managers that are building these things. And everyone would self-select the teams they wanted to go in and we would all move every three months. It actually worked. I think every three months is a little bit too often, but it’s something like I’ve talked about Richard Heuer’s book quite a few times. The Psychology of Intelligence Analysis. In the intelligence community, they move their analysts every two years, three years maximum because you need that new perspective. Like it actually makes your, ’cause you start coming in and asking questions that someone who’s been working on the problem for a while might not ask. So I am like all for team mobility, but yeah, maybe every six months.

0:45:41.6 MH: Well, Maybe the issue is more just expecting velocity and current state to continue on unabated, right?

0:45:47.8 MK: Yes.

0:45:48.0 MH: But during the transition, you actually need to kind of plan a different timeframe for things. Like whenever you’re swapping out people on a project, the new person has to ramp up on so much stuff. Like that’s a bunch of sunk time that you gotta figure out how to… So like whenever you have to switch someone in and out of a project, it’s difficult to estimate for that. The other thing I wanna bring up is sort of like when you’re good at something and you’re estimating it and then you have to hand it off to someone else. How do you handle that? Because like, I can think of things where it’s like, okay, that’ll take me four hours to do. But a more junior analyst, it might take them eight hours or something like that. And so, I don’t know, I’m just curious, what are your thoughts? How do you handle a situation like that one?

0:46:36.3 VK: Well, I would like to answer your question with a question.

0:46:39.5 MH: Oh, okay.

0:46:41.2 VK: And so we can come back to that one, Michael, but I would say that that to me is a little easier than when you know that you want to be training a junior level analyst on the project and you need to account for the additional time for reviewing the work and shaping and molding and feedback loops and like, “Watch me do it then I watch you do it.” That whole, the six step kind of process. And so it’s like how do you make sure that there’s enough space for your junior analysts to thrive, but make sure that they know that they have that security net. ’cause I would argue that when you try to… Like the first time around, it’s gonna be the most labor intensive on like the training side.

0:47:17.9 VK: So I think it’s easier to kind of say like, for me to do this task is only eight hours of work will only take me four weeks in duration. But if someone’s approaching it for the first time, I’m sure they’re gonna have a couple of these questions. But like you said, if you put it in front of other people to kind of just like get that thumbs up on it, that one feels like a good catch for any biases or like anything that you’re bringing to the problem. But making sure that you create the right environment for someone else to skill up is always, that’s one that I have not figured out for sure.

0:47:52.0 MH: When I worked briefly in the tax world, my manager would yell at me if I took longer than what the tax preparer last year took for a certain task. So that was a good way to make sure things stayed on time.

0:48:04.8 VK: Yeah. I think you knew the answer to the question, it sounds like that.

0:48:06.5 MH: Yeah. No, well, I’ve chosen a different path, but I was like, that’s one way. But yeah. Like I usually try to upfront it with here’s what we’re working on, here’s it, do you understand it? Like, lay out everything and then say spend about this much time. If you go past that time, then let’s talk and regroup and see where you’re at.

0:48:33.1 MK: Oh, I like that.

0:48:33.9 MH: And then usually I’ll build in a buffer so that way they have a sense of like a clock they time… I help them time box it a little bit because I’ve seen, I’ve done this to poor analysts before where I’ll give them something and they just go and flail for like two days and can’t figure anything out. And then you come back, you’re like, all right, what have you got? And they’re like, I didn’t get anything done. I’m sorry, I’m the worst. It’s like.

0:48:55.1 MK: Or they don’t even tell you that they floundered, like that is the the worst.

0:49:02.7 MH: And it’s like, I’d rather you just let me know. Like we’ve got a deadline here and now we’ve got nothing and less time. So that’s the worst thing.

0:49:10.0 MK: But Helbs, on this I just wanna clarify ’cause I think this is really important. I will kind of, not vaguely, but like roughly say like, Hey, if you’re stuck for more than this amount of time, like let’s say if you were banging your head against a wall for three hours, let me know. Is that sufficient or do you feel like it needs to be more specific, like with where the progress checkpoints are?

0:49:32.4 MH: That’s a good question. It depends obviously on the complexity I think. I think that would make sense. And then I think it also is by person ’cause I also, sometimes you have people who wanna check with you on everything and they’re afraid to take a step. And so you kind of need to shove them out of the nest a little bit too and be like, you go figure it out and then come back when you have an answer.

0:49:53.5 MK: So how do you handle that?

0:49:54.8 MH: And so, well, you just make yourself a little bit less available during those three hours or whatever that they’re gonna work on it or whatever. And then you come back and say, okay. Or you say, okay, organize all of your questions into one thing and let’s sit down at once, and instead of this sort of back and forth constantly, which Slack enables and other things enable in our lives. I’m just pinging you with questions all the time because then you’re not getting anything done. But yeah, I think it’s just more a function of sort of knowing the person. Because some people will be like, okay, I’ve got this and I’ve gotta finish it. And so I’m like that, like, I don’t wanna come back to you with nothing to show for it and I don’t wanna bug you with questions, so now I’m just gonna try to figure it out and I’ll just run into the wall 15 times until I feel like I’m gonna like break through it or not. And then they’re like, “So what do you got?” And I’m like, “Oh, not much. It’s not very good.” And then, you’re like, “Oh, I feel like terrible.” And they’re like, “Why didn’t you come ask a question?” I’m like, “Oh, that’s a good thought. I should have done that.” But then there’s other people you’re like RTFM come on. Like, just figure it out. Use Google. Here’s a Google search box. You can do it.

0:51:08.4 VK: Well and I also think like creating a safe space because, and being upfront and saying like, you’re actually gonna learn a lot more from the “mistakes” you make, “mistakes” because like, I’m gonna catch it before it goes to the client, we’re in this together. But like, you’re gonna learn a lot from like being pushed out of the nest, like you said Michael. And some of the mistakes you make, that will just become like a rope part of your process in the future. Like, “Oh, always make sure to check your audience definition criteria,” whatever those things are that just become like the way that you shape the way you approach a task. And so like just saying like, there’s probably gonna be some imperfect parts to this. And I think that that’s a natural, I expect it and it’s safe space like so, if you say…

0:51:49.6 MH: And if I just hire like Tim Wilson and say, “Hey, help these analysts learn how to be good analysts.”

0:51:55.8 MK: So Val, I have a last question. What do you do when the estimate goes wrong? When it completely blows out? What is your advice?

0:52:10.4 VK: So that’s a good one. I think all best plans get disrupted at some point. And I think it depends on why it’s going south I think is part of it. But I go back to what I was saying earlier about communication early and often, transparency. Obviously you did the best you could at the scoping phase with what you thought needed to be included and the assumptions that you had of what was gonna be available or what integrations were already active and what needed maintenance and what did not. A lot of times process related things will cause it maybe to go sideways. Oh we have a development process for building out tests. And then, you get in there and they’re like, oh yeah, our devs are jammed up to 2025. So…

0:52:52.3 MH: Yeah.

0:52:52.8 VK: But we say like, we’ll deliver three tests, right? And so then it’s like, oh shit. And so I think the communication with the client early and often, but like pulling in your whole cross-functional team to kind of like see what you could do to creatively problem solve. I was actually in a very recent situation where we had a lot of missed expectations and scoping, but in week two we were all kind of head nodding around it. And so we proposed that our client services person lead a conversation with our primary stakeholder to re-scope the entire project to say, “We want to make sure we’re delivering value for you at the end of this eight week project and we are not in a position to do so and so here’s what we would propose with the time that we have.” And they were actually super thankful that we came at them. And Michael, this kind of goes back to your first story too about like building trust and showing that you’re trust advisor, a good partner of them, like being a good steward of their investment in you and your expert resources that you have working against this. And so I don’t really have like great advice hopefully Michael you can save me in this one.

0:53:50.7 MK: That was great advice.

0:53:52.0 MH: Though, that was awesome advice. No, I mean all I’ll say is over time I’ve learned that communication is everything in that context. And you’ve, you kind of alluded that too, Val. ’cause even on the inside when something is going longer, like you’re docking on an analysis, but it’s gonna take you longer than you thought. Letting people know where you’re at. What are the problems I ran into? What are we doing about it? That’s, I always say, that’s always what people want to know is what went wrong? What are we doing about it? How are we making sure it doesn’t happen again? That’s it. And it’s actually, I found over the years that builds your relationship with people and stakeholders or business partners more than if everything goes swimmingly. Because when you’re honest, when you’re transparent and when you actually do deliver on the thing you said you’re gonna deliver on, but you go through those steps, those are the things that people remember like yeah, we got in some rough water, but you know what, you restored our confidence.

0:54:51.2 MH: And I’ve had that conversation where a project went terribly sideways and I had to step in and a bunch of things pulled other people in and at the end of like six weeks, the main client stakeholder sat down and we were talking about it and he’s like, you really restored our confidence. It is one of the best feelings I’ve ever had. Because it’s like wow, we have a great relationship now because we went through hardship together but we did it the right way and we worked hard to get out of the spot we were in. And I’ve made every mistake in the book so I’ve had a lot of opportunities to try to rescue bad situations.

0:55:27.8 MK: A lot of learnings.

0:55:29.1 MH: A lot of learnings. That’s right. There’s no failures in testing, just learnings. Anyways, one thing we do need to do is start to wrap up. This has been fun to have this conversation with both of you. So thank you so much for chatting about this, which I think is sort of an underrated skillset for our industry for sure because of how important it’s, but anyways, one thing we love to do is go around the horn and share a last call. Moe, do you have a last call you wanna share?

0:55:57.1 MK: I do and I feel like I often am early in the stages of like testing something out and then I tell all about poor listeners about it and then I should probably come back and tell them how it went. But I’ve been really obsessed with the concept of timeboxing. I’m always trying to find ways to work more effectively and make sure that I don’t forget about things because it’s something that I’m not good at. And so I’m like, yeah, I’m always trying to like compensate for that and figure out ways to get better at it. So what kind of like drove me down this path of late was an article in HBR called How Timeboxing Works and Why It Will Make You More Productive. And so I kind of like committed to the fact that I wanted to test out timeboxing.

0:56:39.0 MK: So basically you have to do a task, you find time in your calendar to do it, so on. Yesterday, I actually at the end of the day I was at work and I said to my whole team, I was like, “Oh my gosh everyone.” And they’re like, “What?” And I was like, “I’ve just had the most productive day I’ve had in a long time and I feel really good leaving work today.” I didn’t get everything done that I wanted and all of my estimates were not accurate. I think I estimated 30 minutes for some task that took an hour, but I felt like I made a lot more progress. And so I am gonna do a shout out to the Motion app because I did install it and I decided I’m gonna let AI figure out my calendar. So it not only does timeboxing, but it then, so you add the task and then it time boxes it into your calendar and then if urgent things come up it like reshuffles your calendar. I’m still figuring it out. I’m like day one, but I am giving it a whirl and I’ll let you know how I go with it.

0:57:39.0 MH: Wow. AI helping us out.

0:57:41.6 MK: I know. Yeah.

0:57:44.1 MH: Great. That’s crazy. Val what about you? What’s your last call?

0:57:50.0 VK: Yeah, so, mine is a article that was on Medium from published on towards data science and it is related to the topic. I think I haven’t done a great job of that lately, but this is also a follow on a little bit Michael to what we’re talking about the Viyaleta Apgar episode that we did recently where we’re talking about the structured approach to data exploration. So this I think is a nice compliment because it could be the step that you do before you begin your analysis, but where you start to uncover some of those elements to help you scope and therefore estimate your work. So it’s called How to Effectively Structure Data Science Projects and it’s a explanation of the PSW tool, which I wasn’t familiar with, but apparently it’s pretty common in like IT world, it’s a problem statement worksheet.

0:58:38.2 VK: But the author walks through like, there’s like six main blocks of things that you would ask yourself to understand a lot of what we talked about today, like the background criteria for success, understanding what the constraints are within the solution space. But it’s a really nice way to apply it to a data science or analytics problem. And I definitely think it’s something that could be used in-house to understand how to effectively scope and know what you’re walking into and make sure that your partners are gonna be happy with your delivery. So it’s a good one.

0:59:06.0 MH: Nice.

0:59:07.1 VK: How about you Michael?

0:59:08.2 MH: Well, I’m glad you asked. So in my world, in the day to day, still a lot of people struggling with their transition over to Google Analytics 4, and a tool I ran across and we had the chance to use recently is called the GA4 auditor. And you can like run your GA4 implementation through this little audit tool and it does a really nice job of highlighting just a bunch of things to look for in your implementation and stuff like that. So if you’re struggling with that at your company and you just want some second pair of eyes, that’s a really easy low cost way to get some really good information about what your current implementation looks like. So I highly recommend it and it’s pretty inexpensive as well. So, and then you can hire Search Discovery or stacked analytics to go do a much deeper dive later, anyways…

0:59:58.1 VK: Thanks.

1:00:00.0 MH: Or whatever, not a pitch. Anyway, so that was just one that we’ve found useful in some of, the work that we do and some of our clients, helping them get to the bottom of some issues. So, alright, well thank you for listening and I’m sure as you’ve listened you might have been like, “Hey, you didn’t talk about this or this thing.” Well that’s very likely ’cause we are just talking about our experience, but we’d love to hear from you, so please reach out. And the best way to do that is the Measure Slack group or also on LinkedIn or on Twitter. I don’t know whichever one you want or X I guess now it’s called, I don’t know, it’s hard to rebrand things. Anyways, we’d love to hear from you and there’s that. And of course no show would be complete without the great work by our producer Josh Crowhurst. Thank you Josh for all you do behind the scenes. Really appreciate it. Alright, listen, no matter what you’re doing, whether you’re estimating a small analysis or a big multi-phase milestone project, I know I can speak for both of my co-hosts, Moe and Val, when I say, keep analyzing.

1:01:13.6 Announcer: Thanks for listening. Let’s keep the conversation going with your comments, suggestions, and questions on Twitter at @analyticshour, on the web at analyticshour.io, our LinkedIn group and the Measure Chat Slack group. Music for the podcast by Josh Crowhurst.

1:01:31.0 Charles Barkley: So Smart guys wanted to fit in, so they made up a term called analytics. Analytics don’t work.

1:01:37.8 Kamala Harris: I love Venn diagrams. It’s just something about those three circles and the analysis about where there is the intersection, right?

1:01:49.5 MK: He, Put me as the rock flagger. What an asshole.

[laughter]

1:01:58.0 MK: That Is just unkind. Eww. Rock flag and never say no.

Podcast: Download | Embed

Subscribe: RSS