Parakeeto vs. Project Management Tools: What’s the Real Solution?, With Kristen Kelly

Welcome to the Agency Profit Podcast. a show dedicated to going deep space on agency operations, which is just as nerdy as it sounds. I'm your host, Marcel Petipoff. I'm the CEO of Paraketo, a firm that helps digital and creative agencies measure and improve their profitability.

Join me as I interview some of the smartest thought leaders and agency owners in our space and go deep into operations, metrics, and all the other things you need to get right so you can spend less time worrying about operations and more time executing on your vision. Hey, let me ask you a question. How much time does updating your CRM take away from actually selling? If you're anything like we were the answer is probably a lot.

Well, you're in luck because today's episode is brought to you by Folk. Folk is a new CRM that's flipping the script on the bloated, complicated and time-consuming CRMs of the past. You know the platforms I'm talking about. They've built a new kind of CRM that's incredibly simple, integrated, and proactive to use. And yes, it's got a ton of cool AI features too. It's truly one of the simplest CRMs I've ever seen for agencies selling B2B services in a high-touch multi-channel sales motion.

It can capture leads and contacts from your emails and social media accounts like LinkedIn, for example, and automatically enrich them. Then it uses AI to help you identify the right people to follow up with and even drafts the emails and follow us for you. Picture it.

a CRM that does the busy work so you can focus on growing your business. Recently named one of the fastest growing companies by the Financial Times, Folk is the tool of choice for over 3,500 teams around the world and Parakeet listeners can get an exclusive discount and save 30% on their first three months.

by using coupon code Pear Keto at checkout. So if you want to try it out for free, head to folk.app and make sure you use coupon code Pear Keto to save 30% off your first three months. Hello, everyone. Welcome back to the Agency Profit Podcast. Joining me again today is one and only Kristen Kelly. Kristen, thank you for being here today. Thanks for having me, Marcel.

It's a pleasure to have you back on the show. I feel like we've had a string of Carson appearances, so it's nice to have you back. You were enjoying a little bit of time off over the summer, which is great. Some time spent with family. So welcome back. Thank you so much. Yeah, I'm about to be on a run too, so get ready. I think we're set for another string of Kristen. Yeah, amazing. So the topic today is a question that we see come up.

that's posed directly to us, but also just sort of like an idea that we see applied to this problem of profit management pretty often by sometimes by people that are considering working with us and other times. in people that are committing to working with us after having tried this and failed which is this idea of you know project management tools and the role that they play in profit management and i think more broadly the misconception that

a better project management tool or a better PSA should be an adequate solution to this broader problem of profit management. So I think that's what we want to talk about today is like. Why do people believe that? What are some of the challenges that come with that? And how do we think about the role that project management tools play in this problem set? They're important, but why they're probably not the answer to the real problem and the real question.

Yeah. I've seen this so much recently. I'm excited to dive in. Awesome. So with that, we'll just sort of tee it up. What are some of the things that you have heard from clients or some of the things that you've seen them do that...

might be ill-advised as it relates to the project management tool and how that tries to solve for a lot of the operational challenges that people are looking to solve inside their agency.

Yeah, I mean, I think that the project management tool often is the first piece of software that someone will latch on to, someone being a leader, someone being a project manager, someone who's... close to the leader or in a delivery role to try and solve for some level of chaos that's happening or disorganization that's happening where they're just feeling very granularly like they don't have a strong sense of organization and they'd like to change that.

In addition, they also are hoping, because they've been promised through various different marketing campaigns for these tools, that this tool is going to solve for... not only their delivery problems, but also give them some visibility into all these questions that they're trying to answer. So that's your utilization. You'll be able to see that all of a sudden. You'll be able to tell where there are gaps in capacity, how much capacity people have.

all these questions that sound like things that are missing. And I think they're all kind of marketing and marketed it in such a way that it's easy to kind of fall into this, you know, trap or mindset that this project management tool. is going to be this like silver bullet that once installed we've got the answers to not just kind of tame this day-to-day workflow and chaos but also you know installing the answers to all these questions and just addressing things

across the board, both at the PM level and at the exec level. So that is a very common trap that I see, you know, across agencies, across the board. Yeah. Yeah, and I think you've raised an important thing here, which is it's easy for us to sit here.

you know on our high horse and poo poo on people that get excited about a project management tool and think like oh this is going to be great like you know we're going to have all this visibility into projects and people and utilization of forecasting but like this is what they're being sold And don't get me wrong. We have a lot of friends that...

own, that run, that work at these companies. They're great products. They're impressive as a person that has built software. These are amazing tools. They're important. Everybody should have a project management platform. However, I do think it's fair to say that

for the vast majority of these platforms they are massively overselling their capabilities when it comes to the profit management side of the business or at the very least i think you could argue that and if this makes sense like why would you

put an asterisk on the website and then list out all of the requirements that are for most firms, not feasible that need to be met. And all of the edge cases and idiosyncrasies that you happen to have to just be able to like. not deal with in order to actually get a lot of these outcomes that are being sold. And therein lies the problem.

There's people that are listening to this that might already be feeling some resistance to this idea. And then there's other people who have been doing this for a while and have reached that point in sort of like the expert's curve where they've gone from sort of like unaware optimism to aware pessimism. where they've had enough experiences trying to implement a project management tool to realize that every one of them is going to be awesome in some ways.

and then they're going to have this weird idiosyncrasy where like this field just doesn't show up in exports for no reason at all or you can't link this tag to this tag or there's a limit on how many of these fields you can use or you can't put apostrophes in the naming convention

for this one specific field for no reason at all and it wasn't documented in the support docs and like you always run into stuff like this that forces you to then try to like figure out workarounds and in the end you end up with a bunch of stuff that you need and a whole bunch of stuff that is still not quite where it needs to be. So anyway, the rant has begun. We're going to keep ranting here for a little while, but moving on to kind of the next piece.

You know, knowing that a lot of these things are being sold to companies, I've talked about some of the reasons why it doesn't really work. But from your perspective, what are some of the biggest reasons that people who go down this path and try to like really go in on? All in on the PM tool is the way to solve all these problems often end up coming up short or being frustrated by that experience. Yeah.

What I see really commonly is, you know, for this PM tool to kind of get installed and maybe they've seen some of the shortcomings that you're talking about or referenced or maybe not. Maybe things have shown market improvement on the delivery side, but still there's this like no man's land.

people kind of find themselves in, where they are. They've got this PM tool in place, right? So some things are working better, but they've also got financial reports and they've got a CRM and they still have all this, they've got this.

sets of data and they can't make the decisions they were hoping to be able to make by inserting this project management tool into the mix. So it's just finding themselves still kind of stuck because what they're ultimately missing is a framework for understanding their business as a whole and really just uniting those sets of data to be able to make the right decisions.

Yeah. Yeah. I think you've touched on something really important here, which is, again, project management tools are important. They're a part of the solution and they have a role to play in here. And oftentimes it may make sense to like go.

roll something out improve the rollout that you have currently switch tools whatever the case might be but a lot of times i think the reaction to like really hyper fixating on a project management tool and looking to it and trying to hire it to solve like a very, very broad swath of problems.

is indicative of improper sequencing in approaching this problem or in some cases just sort of a perspective that's a little bit too narrow on the scope of this problem it sort of represents almost like a bottom-up mentality to solving the profit management problem. And what I think we see a lot of people run into is they get elbows deep into a rollout of a PM tool. And then all of a sudden they realize like, wait a second, what metrics are we actually trying to track?

And how do we calculate those? And how exactly do we define capacity inside of it? Right? Because they're like sitting there in the project management tool. And it's like, hey, what's the capacity of a person on your team? And they're like, that's an interesting question. We've never thought about that. And all of a sudden, you end up in this really difficult position where maybe you have this timeline and you said, we're going to get this live on September 1st.

And it's August 12. And you're like, I just need to make a decision on this. And then all of a sudden, you make a whole bunch of decisions that weren't thoughtful that didn't consider the framework, like you did things out of sequence, the answers to those questions should have been easy. But there wasn't

the right work done before that. And there wasn't enough consideration of how that was going to affect things upstream. And then you sort of end up in this game of whack-a-mole where it's like, we're constantly having to go back and change the project management tool because we don't have this inside, or we have this limitation, or we didn't segment things.

We didn't have the right schema or the stakeholders still not getting what they want or the timeliness isn't there or, you know, and, and, and, and, and, and. And then it feels like this never ending battle. And then at some point. somebody comes in and goes oh well the problem is we just didn't pick the right tool to begin with right and we've seen this again where they're like oh we've been through four tools in three years the team hates us and we really need to fix this so um

With all that in mind, I want to take a step back and sort of set the frame for the conversation, which comes back to our profit management model. In our opinion, there are kind of three key ingredients, and hopefully this will help people play sort of like, where does the project management tool actually fit into this?

The sequencing around this is the first thing that you mentioned, right, which is the framework. Before we do anything regarding tools, the first question is, what is the framework that we are using to measure the business? And to make that a little bit more objective. We're talking about what metrics are we trying to track? How exactly do we calculate those metrics down to the precision of exactly what is the formula for?

utilization, project profitability, gross margin, delivery margin, whatever those metrics are for you, exactly what's included in each object within that formula. Like you got to get to that level of precision.

And then what are the relationships between those metrics in our business, right? So what questions are they actually helping us answer? What does it mean if it goes up or if it goes down? What does that tell us about our business? How are these things related to each other? Are there any of these metrics that are going to be used to calculate other metrics, right? Are we clear?

on how this whole framework like that has to be the first step because that's the objective that's the outcome that all this stuff should be laddering up to once we have that then we can go look at the data which is do we have the tools in place that could create the data necessary to reach those reporting outcomes? Do we have the right conventions inside of those tools to be able to produce data that's structured in a way that's going to work?

for those kinds of things? And are the tools configured in such a way that they're going to be able to accomplish all the workflow objectives that our team has and still produce good data? And I think the important consideration there is, is it operationally feasible? Right. And this is where there's often a lot of oversight where we like design a system that theoretically should work. But then in practice, the team has to spend like.

two hours a day updating a bazillion tasks and making sure that there's like perfect compliance on having estimates on every single task and every single subtask and adding a tag to every single time entry. And like you just never actually get.

the outcome because the requirements were kind of crazy to begin with so that's kind of part two is data so we had framework we had data and then the last one which is so overlooked is process which is like okay if we assume that the data is going to be messy that things are going to change and that we're going to have to iterate on this and someone's going to have to own taking the data from these tools and actually getting it into the right format.

on the right cadence and maintaining that against all the changes that are going to happen in the business you know do we have clarity on that and specifically that's data hygiene issues which will exist we'll come back to that change management which will happen

We can come back to that too. And then cadences, which is like, are we measuring these things on the right time horizons? And it's as important to make sure that we're doing it quickly enough so that on the weekly meeting, we have a weekly view into the metric that we're talking about. but also that we're not optimizing to a level of timeliness.

That is completely unnecessary and therefore a huge waste of time and energy, like trying to get a daily utilization rate calculation, which is like insanity and completely not useful. And I would argue not even insightful at all, but. definitely very expensive and very operationally difficult to accomplish so framework data process and really the data is the only kind of part of the scope that a project management tool could feasibly

solve for and is really relevant to from our perspective. Yeah. So. You mentioned sequencing. Why is that so important, you know, to go in that order? And when you don't sequence properly, what gaps does that illuminate? Yeah. I mean, the most obvious example of this is... all the decisions that you have to make when evaluating tools.

and implementing tools and then designing workflows around those things if you don't have an understanding of what what are the actual outputs that this needs to generate from a reporting perspective how could you possibly make a decision about how someone's cost per hour is being defined inside of the project management tool. If you're going to use the project management tool to create that data, or if the project management tool even is the right place to have that data, or should it exist?

in a spreadsheet that's appended to people's actual payroll right is that where you're going to draw that from the same thing would be true about how you would define for example the objects on a project What are the different buckets that you might track time against? What are the naming conventions for that? How do you actually structure projects? What are the names for those things, right?

All of those decisions, how do you define people's capacity? What kind of tags or roles or teams are you assigning them to? These are all the kinds of decisions you're going to have to make. when you're implementing a time tracking or project management or resourcing. And you can't answer any of those questions unless you actually know, like, what are the requirements for our data? So you have this chicken and egg game.

But really, it's quite obvious which one should come first. The first one that you should define is like, what are we actually trying to accomplish from a reporting perspective? But I think a lot of people either avoid or don't have that conversation because it's a really... difficult conversation, especially if you're trying to just create your own framework. It's a very complex.

conversation. It took us years to accomplish that at Parakeeto. And we had the opportunity to do it dozens of times before we were able to get it like, right from my perspective. And so I would encourage you to just borrow a framework that already exists, like ours, for example. But if you're not going to do that, if our framework doesn't work for you.

As hard as that is, it has to be the first conversation, in my opinion, because everything else downstream, including what tools you use, how you use them, how they're configured. what data comes out of them, how that data gets stitched together, what process you then need to apply to keep it clean, to keep it consistent, and to get it on the right cadences. You can't figure any of that stuff out until you're clear on what the outcome is going to be. Yeah.

I think it's really clear, you know, why we've made a case for why the framework is really important. And we're saying, hey, you know, your project management tool is really going to capture that centerpiece, the data. And so where does that kind of leave things when it comes to process and how can agencies capture that back piece of the trifecta here?

Yeah, this is a really good question. It's a really important one. And there's two things I want to touch on here. The first is sort of the operational feasibility and precision piece, and then the other piece is data hygiene. And there are some people who are listening to this who might be thinking like, okay, well...

You know, if we already have the framework and we know how that's going to work, my project management tool is telling me on their website that, you know, especially if you're going to more of like an all-in-one PSA type tool. the pitch for those tools is often like all of your reporting problems will be solved because all of your data will be in one place. And while, again, theoretically,

That makes a lot of sense. And in some cases, some of your reporting problems may legitimately be solved or made much simpler because all the data is in one place. What is often not discussed. is the data hygiene side of that the critical assumption that a lot of that pitch is based on is that the data inputs are going to be of good enough quality to drive reporting and therefore the reporting can be done in real time

But the issue with that is two things. The data is not created in real time. In my experience, most people don't track their time every day or on the same cadence. And most people are not perfectly compliant. with naming conventions and project hierarchies and structures. And even if they were, the idea that those things are going to remain static over long periods of time is also often not the case. So from my perspective,

This is not necessarily my opinion. This is just like an observation from the practice of data operations, which has existed for decades and has been done at big companies for a very long time. It's generally not a good practice. to try to do reporting in the same place that you have source data most people use an etl framework which stands for extract transform and load with the key idea being that there's a transform step right so that transform step is where you can

fix things like there's five different ways that people are calling tasks design tasks. So if we want to measure how much design time was spent on projects, we need to take those five variations and consolidate them down to one. right or in the sow we structured this project as one project but in the pm tool we split it up into six phases

Well, we then need to be able to consolidate all of the data from those six phases into this one project, right? This is stuff that needs to happen. Or we used to structure projects this way. And then six months ago, we decided we're going to completely change how we structure projects.

which is fine but now we need to be able to map data from the old period to data to the new period these are things that are going to occur project management tools often don't have any kind of capability to allow you to do those transformations and therefore

the reporting outputs are going to be at the very least restricted. They're going to restrict you operationally for making those changes, but you know, most of the time are just not going to be good or reliable. So that's sort of one key piece that you have to keep in mind around process is

I don't think it's a very good assumption and you're often going to set up your system to fail. If you're building it on the assumption, the data will be clean and consistent because in my experience, it never is. And that's not a flaw in the project management tools. That's just sort of an inherent reality. managing data in any organization. And so I would encourage you to hire a project management tool to help your team do the work.

And in some cases, having an all-in-one tool might be the best answer to that and get you a ton of efficiency in terms of workflows. And it might actually help improve the quality of your data in a lot of different ways. In some cases, that might not be true. You might be better off actually having a stack of smaller, more disconnected.

but best of breed tools, you know, that, that really should be the focus though, is like, is this helping us get the work done? And then assume that from a process perspective, you should have, and is the best process to have, best practice to have.

an extraction of that data and a step where you can do transformations, normalizations, quality assurance, all the things that need to happen to get your data in a good state so that you can then report on it and make sure that it's accurate and complete. So like, that's, I think one important.

consideration and doing that makes your whole system more redundant, and it makes it much more flexible. And it removes a lot of the tension that emerges when you're implementing PM tools, which is the project management team. or the operations team, one of you has to make a compromise because in order to get either the workflow that the PM team wants or the data that the ops team wants, somebody has to give something up.

right you can remove a lot of those tensions by giving yourself a transform step where everybody can kind of have their cake and eat it too so that's that's point one we'll come back to the precision thing but i think that's an important one

Do you want some free resources to help you measure and improve your profitability? If you do, then I want to tell you about our agency profitability toolkit, which you can grab absolutely free in the show notes or by heading to parakeeto.com forward slash toolkit.

It's packed with training videos, cheat sheets, templates, and all kinds of other great resources to help you start measuring and improving the essential metrics that are going to drive better profitability in your business. And it's helped thousands of other agencies around the world do the same.

So I want to encourage you to go and grab a copy of that. And if you'd rather get in the fast lane and just have our team of experts guide you through the process of measuring and improving your profitability, then I want to encourage you to apply for a consultation at parakeeto.com. With that, I want to thank you again for tuning in. I hope you enjoy the episode and I'll let you get back to it. Yeah, no, you mentioned you're actually.

hitting on something super important, which is the trade-off, you know, based on the role. So, you know, your PM really wants this precise set of data. You know, to understand granularly what's happening on the day to day, the ability to resource, make all the decisions that they have to make at any given time versus your operator who really needs to have a much more simplistic data set to be able to.

look at things at a higher level and on a longer time horizon with just a broad sense of accuracy as opposed to that really specific and precise set of data for a PM. Yeah. Yeah. And you see this show up in all kinds of different ways too. Like, um, we, you know, in some organizations where you have like a very creative side of the business and you have a very engineering focused side of the business, like you might find that they want to use the tools completely differently.

In some cases, they might even want to use completely different tools. And that's actually like, that does make sense that the engineering team is on Jira and the creative team is on Asana. And we've seen this before. Right. And so like from an operations perspective and from a workflow perspective, that might make a lot of sense.

But you can imagine that maybe the ops person that has this dream in their mind that like all the data is in one place and it's flowing together and all our reporting are automated, that might make them want to rip their hair out.

um and so it's like well actually those those things don't have to be in tension with one another they can coexist and you can enable that without having to compromise on your visibility but you know you do that through this architecture um you just touched on the next thing which I think is important to talk about here, which is the precision trap. We've talked about this a lot, but...

This is pointing to the thing that you just called out, which is the different needs of the stakeholders in the business. When I think about a project management platform, the first and most important job that that tool is doing is managing projects. And in a lot of cases, that is a highly precise exercise.

Right. And for a project manager to do that, well, they may need to break things down into a lot of different increments and tasks and be looking at things, you know, at a very granular level. And there might be a lot of complexity in that and they may need to take a project and split it up into a very different. of milestones and tasks and subtasks and phases and whatever in the tool to get the visibility that they need to do their job.

than how you have this in QuickBooks or how it's being invoiced or how it's being measured at the executive or the finance level, right? So like those differences are not necessarily indicative of a problem. They might just sort of be inherent. And where we get into, we see a lot of firms get into a lot of trouble is the, in order to enable effective project management and then somehow.

directly connect that to executive level reporting, you end up with a set of constraints that are completely unfeasible. And so I'll give you an example of this. Let's say, for example, you want to measure all of your projects. And you want to know what the profitability of those projects are. And you want to be able to segment that by different service lines that you have. And then you also want to be able to see where you went over budget across a bunch of different role categories.

in a world where you're trying to accomplish all of that directly inside of a project management tool you and let's say you want to forecast on top of that right you think about like what is all the information now that needs to exist on every time entry inside of the project management tool and

what needs to be maintained, right? So now you have the situation where every time entry needs to have this information on it, which means that every task probably is going to need a time estimate, actual time tracked against it. It's going to need to be tied back to... a certain kind of project naming convention, you're probably going to need to apply tags to figure out like what category this time falls into. You're probably also going to need to be managing

uh the scope in the correct way and have some way of assigning value to the project or to time right and that framework may not actually align to how you run your projects depending on what tool you're using and what their limitations are you're also going to need to have some concept of like the cost per hour

of the individual and that's going to have to be maintained against changes over time and depending on what tool you're using when you make an update to that it may just retroactively change all your historical data or it might not right so like And all of that needs to be maintained perfectly all the time. And if your executive team wants to go in and look at a report of how everything's performing, you need globally consistent data, meaning like you have to be on top of that shit all the time.

And so like what team on earth is going to be able to accomplish that? Not a lot. Right. And our perspective on this is, well, actually, like what if the executive team could get all of that visibility? And the PM team didn't have to worry about the majority of that stuff, right? And they could just kind of do whatever they need to do and we could still get that outcome. This is where I think things like joins are really powerful.

where it's like, I don't actually need you to put any information into the project management tool about someone's cost, about a project, or about what role they're in, because I can go get that information from other sources and stitch it into a time entry in my transform step. So all you need in the project management tool, my only requirements are we need to know the project name. We need to know the person and we need to know how many hours we're tracked. That's it.

You could do whatever the hell you want after that. As long as we can get that information out, we can get the reporting outcome because I can go figure out how much that person costs because I have their payroll information. And on that payroll information, I know what department they're in. So that tells me what category the time goes to. And I can go get all the information I need about the project from my project grid, which contains information about...

who the client is, how much we're being paid, how much is estimated on that thing. And I don't need to ask the project management team to manage all of that detail and then spread it across 300 different things when I could just actually have it tied to one object.

Right. So these are the things that I think people don't consider is like, that's the benefit of actually not trying to load all of this into the project management tool where you're exploding the complexity and therefore the cost of maintaining the data set.

And effectively, you know, what you're trying to do when you do that in the project management tool is like build a sandcastle by asking the PM team to spend all day with a set of tweezers trying to stack little grains of sand on top of each other. And every time something changes, the whole thing comes tumbling down. It's like, well.

theoretically that could work but for most teams it's just not going to work in practice yeah No, I for sure have seen more little reporting graveyards than I can count within public management systems that just have blown up sets of data and kind of like half.

complete reports and unfortunately what that really does um you know is kind of erode the trust in the system even at at a fundamental level just because they think they can't even though they probably can trust to some degree some of the data that's being generated in there it's just not being collected and reported upon because it's missing a tag or it's missing a this and so just at the end of that flow

it's incomplete and not a trustworthy um you know representation of what's actually happening and i think like you're not going to call this out but i will we had an experience recently right um of a client that came to us after having worked with another firm and that firm helped them install profitability reporting inside of their project management tool specifically inside of click up

which is an incredibly capable platform. And similarly, like when we looked at it, we were like, well, theoretically, this would be awesome. However, the client was getting no value out of that reporting. because their team was completely incapable of keeping all the stuff up to date that was needed. And this report relied on globally consistent data. So if one project was out of whack.

then their measure of this metric for the whole business was completely out of whack, right? So it's like the reporting system was built on a house of cards and a set of assumptions that was just not reasonable to begin with.

I think you cannot overlook that. I can't stress enough how important that is and how many firms we see fail. Not because the theoretical system wasn't feasible, but just like operationally, it was built on a bunch of... assumptions that were incredibly risky and ultimately set it up for failure.

Yeah, and I think that it can't be understated the amount of friction it can also cause on the day-to-day level, not just with the project manager who's tasked with spinning up something new every time a piece of new business comes in the door. But really just managing the inputs, managing anyone else who's touching that system, making sure that everything is staying intact. And it really can impact.

The ability to execute the work itself because someone's hung up on a specific step or a certain, where do I track this? Or how do I tell where I'm going, you know, to isolate what I'm supposed to do? Just a level of complexity, certainly when you're trying to accomplish all that in one. place in the PM tool. Yeah. Oh, and you've raised such a good point here, which I think is so important.

It's one thing to load this complexity onto project managers, right? And this happens a lot. And in some cases, we unfortunately see a lot of PMs that maybe they're growing in their career and they've been sort of going through the... typical path that a pm often goes through which is like they're the pm and then

All of a sudden, they're like the PM that's been around the longest and the company is growing. They need someone to take on ops. So like they sort of step up into that role and they're doing it for the first time. And then they're like, hey, you're going to be in charge of rolling out the PM tool. And they get all excited and it's a big opportunity for them. And then they sort of like build.

themselves a cage that they then have to live in where they're like oh shit you know i set up the system that's so fucking complex and takes so much time to maintain but if i don't do it then the project fails and then i fail and it's like they sort of like

put themselves in a set of golden handcuffs by building this incredibly complex system that is relying on globally consistent data but the other thing that this often does is it pushes a bunch of complexity to the team and it just absolutely annihilates time tracking compliance and there is just this punishing

exponential curve to the amount of thinking that someone has to do to log their time and how likely they are to actually do it and do it well. So where this typically shows up is the kinds of questions that you have to answer when you log time, which is like,

if you have to ask a person to determine which for example task category does this time belong to is this design time is it you know engineering time is it strategy time is it whatever well if i was just in a design strategy meeting with the engineering team And then I'm sitting in front of my time sheets like this, actually not a very obvious question. And if I have to think through 12 of those kinds of decisions every week when I log my time, that is going to have a massive cost to.

time tracking compliance in the same way that if the project gets broken out into 17 phases. and now all of a sudden it's like well what phase are we actually in right now like this is kind of related to the last phase but on timeline basis we're in this phase but you know this task was sort of like this thing that got punted over for revisions from this other phase um right so you the more sort of

precision that you layer into time tracking and ask your team to do and this is sort of like the inherent cost of trying to do it all in the pm tool as opposed to relying on other sets of data that you can stitch in your time tracking compliance is going to get annihilated by that

You would be amazed at how much that psychological friction just decimates compliance, but it makes sense, right? It like significantly increases the mental load that's required for a person to sit down and do this thing that you think is simple, but then in practice actually ends up being. not that easy. And they're often not the right people to be trying to make those decisions anyway. And it's very hard, the more precise you get to create clear enough guidelines on

how to think about those things and get compliance across the team. So let's say people just do time tracking compliance because you're sufficiently militant about it. What are the chances that they're actually putting data into the right place? Versus just saying like, whatever, I'll just put it here. Good enough. Like I just need to get my time in and move on so that Kristen isn't up my butt on Monday about not getting my time sheets done. So don't underestimate.

that um and there's a very very low threshold before you start to have a big impact there so we're talking a lot about you know stitching in um joining with an external source and i think It would be helpful for us to kind of just provide a little bit more detail in terms of how that actually works, whether it's with paraketo or not. You know, how does that really, what does that look like for someone who's just like, well, look.

i thought this pm tool was the thing and so now it's you know what is the other thing that brings this whole circle um to a helpful point yeah um okay that's a good question so i'll sort of address really at a high level

The question that we get asked a lot, which is like, what's the difference between Parakeeto and a project management tool? And like, what do we actually do? And the way I would describe the difference between that is it's like, let's say you wanted to build a house. In this case, the house is solving the profit management problem in the business. And before...

Actually, let's take another step back. What is profit management? It's that job that someone has to do in the business. Maybe someone is doing it in your business or maybe someone is doing it, but they're not aware that they're doing it. And it's sitting between finance, operations and delivery and sales.

And bringing all that data together to answer the questions that you got to answer every day to run the business. Like, are we making money on stuff that we sell? Are we charging enough? Are we over under servicing? Is our team busy enough? Do we need to hire people? What does our forecast look like? Right? Those are the kinds of questions that you need all that data for. So solving that.

profit management problem, and having that data, when you need it for the right stakeholders, making sure it's accurate, that's the job, right? So if we agree that like, that's the problem that needs to get solved. The difference between parakeeto and a PM tool will be like If you were building a house, Parakito would be like the firm that you go and hire.

and there we're going to do the architecture drawings and bring in the contractors and like the entire strategy right the framework what materials do we need how do we configure all this out and then we actually build the house

versus a PM tool is kind of like you going to the hardware store and being like, give me all the things I would theoretically need to build a house and then going back to an empty lot and then trying to do it yourself. That's essentially the difference. A PM tool is a tool.

and of course we're going to be involved in sort of the data and the pm tool that you're using but what we're really bringing to the table is the entire solution to that problem which is making sure we're clear on the framework

making sure you have the right data being produced, and then actually running the process that gets that data into a set of reports that is aligned to that framework on top of actually coaching you on that data. So that's the difference between us and them. And then the other question that you had asked...

was what does the process actually look like? And I'll sort of describe what it looks like for us, but also just like generally what it looks like when you're building a data pipeline and the examples that we see in the wild.

Um, the way that we do this is we run an ETL process. So of course we have our implementation phase where we're running through the strategic part of this, which is defining the framework, having a look at the tools and figuring out like what needs to be true to get this client's. data into this format so they can see what they need to see when they need to see it. And then we spin up a reporting system and we set up essentially a mini data pipeline. And we were just working on this yesterday.

There's sort of three essential steps to that process. The first is data cleanup. So we ingest time tracking data from their system and we... clean it up so hey there's five different ways that design is being named let's clean that up oh this person's name is misspelled or spelled differently in a couple different places let's clean that up oh this project was broken up into nine different phases in the project management tool but it's actually just one thing that we're trying to measure

Let's clean that up. Oh, people's names are formatted strangely in this time tracking data set. Let's clean that up. Or, hey, the date format was different in the old time tracking tool versus the new time tracking tool. Let's clean that up. So step one is data cleanup rules. And that can be done to clean a whole bunch of different things up that we see. We could talk for hours about all the mistakes that show up and all the changes that.

happen there. Phase two is when we get into joins. So as part of what we do in this system, we create two important tables. One is what we call the project grid. And the other is what we call the payroll grid. And these are tables where we maintain information about people, including their costs, what departments or roles they belong to, therefore where their time should be categorized, when they start, when they end.

how much time off they get, what their capacity is, right? And we can use that to inform a whole bunch of different reports. And then the other table is the project grid. And the project grid contains all the information about projects. When does it start? When does it end? How much do we get paid? How much of that money is ours?

What do we expect the margin to be on that project? How much time are we estimating for it? So when we pull time tracking data from whatever the source is, again, we only need a very, very small amount of information. Who's the person? What's the project?

how much time was logged. And then we joined data from the project grid and the payroll grid to get all the rest of the metadata that's needed to drive all the reports that we're going to do downstream, like project performance and profitability, utilization.

all those kinds of things so that's sort of step three and then step four is normalization right so we have a set of frameworks that feeds into all of our reports and there's a very specific format that those need to fall into so the last step is saying okay well in their time tracking platform, the column is called project phase name. And in our platform, it's just called project. So that last step is really simple. It's like, look at this column called this and...

That's what you're going to use for project. In the project management tool, the thing is called team member. In our system, it's called employee. So look at the team member column. that's going to be employee. So those are at a high level, sort of the three major things that we're doing in our data pipeline. And those you can be doing those same things. And a lot of people are just doing this in a spreadsheet as a starting point.

More advanced teams that do have some data operations capabilities might use data operations tools to do this, to build their data pipelines.

And how feasible that is with some of the off-the-shelf tools that you can find on the internet really comes down to how complex your situation is. There are some things that we're doing that are just like, you can't just... do that in zapier or you can't just do it in some of these sort of more generic tools that you might use to stitch data together but if your implementation is fairly simple you may be able to set this up in such a way where you can do

use some excel formulas or you know some things like that to to do this kind of transformation but the thing to keep in mind is it's not a set it and forget it kind of thing You will need to maintain these over time because there will be changes both upstream and downstream that you'll likely have to account for. Like the naming convention changed. We decided to change time tracking tools. We decided to change how we set things up, et cetera.

But at a high level, that's sort of the process that we're using to actually take data from the PM tools or from all the different places that it might exist, get it structured in a way that we can report on it reliably.

and then pipe it into our systems and the thing that i didn't call out there but i think is important to note is we also have a quality assurance step so we have a person that every time the data is pulled looks through a report that is generated that finds all kinds of problems in the data and then goes and fixes them in the same way that your bookkeeper every month is going to come up with a list of transactions that we've never seen before.

and then figure out where do we need to put these for this to be accurate yeah i've seen this in practice and i think every client that we work with um you know on this process really feels a great deal of relief knowing that that's responsibility that's been removed from their plate and then pulled out of that actual system where it just hasn't had a high degree of success. It's not reliable. And that's really the visibility they're looking for and confidence.

And I think what's also a relief for clients is that we often remove a lot of constraints that have existed before where the PM team is just like, oh, so like, that's all you need. You just need person, time and project. Easy. And oh, like I can kind of set up the project name up like in all these different ways and you guys can just like tie it back to the.

OK, great. It's like we free them up to kind of work in the way that they want and remove a lot. I think a lot of the constraints and a lot of the requirements that they had before. Or conversely, we simplify.

things and that like they no longer have to try to come up with ways to accomplish all of these specific data requirements in the tool um and i think that can be a really big relief for them it's like we just don't have to deal with all of this stuff anymore and we can just keep things simple and sort of be flexible and still get the outcomes that we want and we also don't have to be worrying about every time we change something

thinking through all the different ways and how that's going to impact the system. That becomes our job. Yeah. Yeah. And even just to bring it full circle, you know, talking about relief, I think, you know, once.

agencies do understand, you know, that the framework is the key to unlocking the insight, you know, that is, you know, the other piece that we execute and help them think through in order to just make the most of the data that they're getting out of that project management tool in the center of this whole thing yeah 100 um all right we've talked about this for a while and we actually we have another call to get to kristin so i guess we should probably wrap this up um

So with that, the TLDR, I think, and the big takeaway that I hope people take away from this is project management tools are important. They're a piece of the solution, but they're probably not the whole solution. My belief, my experience, what I've observed having done this for seven years and seen hundreds of people try to accomplish this is hiring your project management tool to solve all your reporting problems is probably setting you up for failure.

So I would just advise you to not try to do that. Use it to run your projects and definitely have one and invest heavily in it. But maybe think a little bit more holistically about how you're going to accomplish the reporting outcomes. All right, that's it. Thanks, everyone. We'll see you on the next one. Thanks for having me.

Hey, thanks so much for tuning in to today's episode. I hope you enjoyed it. And if you've ever found yourself thinking, man, I get so much value from this podcast. I wish there was something I could do to return the favor.

Well, today's your lucky day because you can leave us a review wherever you're listening to this, and it is incredibly helpful. Of course, if you haven't grabbed a free copy of the Agency Profit Toolkit, go and get that. It's got tons of free resources to help you improve your profitability.

If you're looking to get in the fast lane and get help from experts to improve your profitability and measure your most important metrics, then apply for a consultation at parakeeta.com. We'd love to chat with you and figure out how we can help. With all of that, thank you so much for being a listener and we will see you. on the next episode.