Dr. Ivan Zak and Ryan Leech discuss the importance of having prioritization procedures in place to avoid running too many projects at once and resulting in failure.
Additionally, we cover how the Consolidator Operating Framework adapted Kanban methodology, and how to implement Weighted Shortest Job First as used in Scaled Agile Framework (SAFe).
Welcome to Consolidate That! Ivan, great to see you again today.
Hey, man, how are you?
I’m great. I’m happy that we’re doing some of these not solo episodes but partnered episodes, just the two of us. Today we’ve got some cool stuff that we’re going to talk about, we were looking back at some of the old episodes that we’ve done and I know you wanted today to talk about prioritization, which we have landed on the consolidator operating framework that we have on our website and I’ll be frank with you, I’m a little confused because I know episode maybe five or so, we talked about strategic filter and if you can just start off by kicking off and all of our listeners probably know the difference but if you can tell me the difference between strategic filter and prioritization and then we can dive into prioritization, how does that sound?
Sure. I also wanted to start with saying that I am recording from Ukraine and very excited to have you here next week. Maybe we’ll do sort of a bonus episode recorded live from the same location.
From the streets, from the streets of Ukraine.
Of Kiev specifically.
Yes, totally cool. I’m looking forward to it. After the flight, I’m not sure if I’m looking forward to the flight but I’ve done worse things.
Yup. Yeah, let’s dive into it, I love this topic. If you’ll think about what the strategic filter does and what prioritization does, once you – it’s tied to the quarterly planning as well because what essentially we do with a quarterly plan, we create the plans for the quarter and then what we want to do is to use our value streams, essentially at every level of organization, you have certain stream, which delivers and hopefully captures values after and hopefully value comes out at the end.
When we talked about the strategic filters, strategic filter is something that helps you to decide what you do and more importantly, what you don’t do because so often, there’s so many things that you want to tackle, you see these lists of we have 65 rocks between five people and it’s just like undoable and then by the end of the quarter you’re like, “Well, we took too much, it’s okay not to complete them.”
You want to be precise, you want to be sort of not more than five, six big ones and then cascade them through OKR’s or objective key results like we talked before it. Then comes a dilemma, you have 12 or six or five rocks or quarterly plans, which one do you do first? Can you do all six of it at a time, how do you decide? I think that that’s where prioritization kicks in and you need to have a very specific way of putting them in order and there is a methodology that we implemented to do so.
Okay, if I’m hearing right, the strategic filter comes in place. It filters out the things that you’re planning to do and then the prioritizations’ going to come into play to figure out the order of the things that actually made it through the filter.
Yeah, the specific one that we use, I mean, there’s tons of ways of prioritizing your tasks from whichever you like more and whichever department this is in to becoming more strategic about it and saying, “What is best for a strategy to do first?” The specific method that we use is called, Weighted Shortest Job First.
We stole it from the large-scale transformation methodology which is called safe so scale their gel of framework and you can find it there, you can find it on our website because we kind of give it a little bit of a consolidated color but essentially, what you want to do, you want to understand what is the cost of delay?
What it would cost us if we don’t do this thing first, that’s really what it boils down to but there is a way to kind of be scientific about it.
Yeah, I actually – I pulled it up on the framework here and I was looking at that equation, which is kind of cool, it’s nice when you can put numbers behind everything. The way to show this job first, what I’m saying here is equals the cost of delay, divided by the job duration.
Yup. Essentially, what you want to do is calculate the cost of delay and we can break down that, how you do that and then you also estimate the duration and of course, you don’t know how long it took you to do the task before you did the task but hopefully, you have teams that have done these things before. They can estimate at least what we call a T-shirt size in the development, it’s sort of small, medium, large, extra-large and just to say okay, these are the size or you can use something like a one out of 10.
The cool thing about this is that you have a team of leaders sitting around and you know, there’s five, six people that can decide that it’s going to take us equal eight out of 10 so it’s a long task or it’s two, it’s very easy and then everybody can contribute and decide together because some people may know more about this, some people may know more less, but then, if you did make a mistake as a group, you move on to the next item and then once you value that one and say, “Okay, well this one, it’s five.”
Then you look back to the first one and say, “Well, the first one was two and this one is five, does that still play well together?” No, actually, the other one is a little bigger than two if we say this one is five. You kind of iterate on this but it’s sort of a rough estimation but you convert subjectivity to more objectivity.
Don’t they? It’s kind of like women’s jeans sizes, right? The numbers don’t actually mean anything, they’re all just relative to one another.
Yeah, I bet that’s what they were thinking when they…
Thinking Weighted Shortest Job First when putting those things in place.
Yeah, the most weighted person with the shortest jeans.
Stop, stop him, stop him now. For anyone listening, that was Ivan, not me. What I think though is a lot of people will look at prioritization and they’ll say and I’ll say this too a lot of times, “I can multitask. Sure, we have a big project going on but I’ve got time to knock out these small little things here on the side and sure, I could write a blog post in the afternoon” and that can hop away from this big project that we’re working on. How does that fall into the overall goal of prioritization?
Yeah, a lot of people, first of all, it’s now, I think has been scientifically proven that multitasking doesn’t work, it just doesn’t. Everybody who says that they are multitasking, they probably just don’t understand that they can’t. We have this guy on our team, his mane is Sergei, Sergei, that’s a shout out to you, who is asking very simple question.
When he opens our Jira or whichever sort of system we use, a lot of developers in SmartFlow, we use Sergei built our system there and we use Kanban board. Developers love putting three items and putting into peruse and say, “I have these three things I’m working on.” I say, “Okay, simultaneously?” He’s like, “Yeah” I said, “Well, which one of you are coding right now? There’s one out of three.” He’s like, “Well, I’m doing the second one.” “Essentially, you are not doing the first and the third one right now” don’t put them on progress because you can’t work simultaneously on two tasks.
You really are doing one task, you have to be very disciplined about it and when I went through training at the flow research collective, They were talking about extreme unitasking and that means turn off everything, have one tab open on your computer, have everything turned off, all the messengers, that means, sort of extreme unitasking, you sit down, you take the task, complete the task and then take the next task.
That sort of – if you’re limiting your work in progress. We’re going to talk more about it about the flow. Some systems are capable of putting through or have the throughput of two items at a time and usually, it’s allowed because you have two people working on that unit. Then you may begin to have two tasks in progress but not by one person. It’s sort of a myth about the multitasking, you really need to sort of take one, complete it, according to definition of done and when it’s done, take the next one.
As it relates to – let’s take a portion of the MNA process for consolidation. If you were to look at the legal due diligence side of things. When you’re looking at doing that, I mean, your lawyer, if you have one lawyer that’s doing your legal due diligence, they aren’t working on six of them at the same time. They’re working on one and maybe they have to pause one while they’re waiting for responses or next steps with the client but is that something that you would push external people to be able to sort of prioritize their work or to communicate to you in the same way?
If you are outsourcing your legal due diligence or your financial due diligence or something to that effect, would you talk to them about, “Hey, tell me which one you’re actually pushing buttons on or you’re actually writing the contracts on or you’re waiting for the signatures on.” Is that way to sort of manage the external clients as well?
More like vendors, not the clients.
It’s funny because we have a lawyer who works exactly like that. Love him to death, but he cannot handle three things simultaneously, then it just freezes all three and it’s a very good example of not being able to multitask. I actually use this rule of throughput and I tell everybody on our team, they’re like, “Oh our contract with that company is not ready and we have this acquisition that we’ve done and we need to finish as a purchase agreement and we need the shareholder’s agreement to be completed” and you bumped into this too, right?
What happens, I usually say, our lawyer has a whip limit of one item at a time, he can do two and if you throw two, he freezes. We need to do in the organizations where you have external vendor that is not belonging to the organization, trying to explain Weighted Shortest Job First to a lawyer at your expense might be expensive. What you want to do is to say, “Okay, who is responsible on our team for legal due diligence?” For example, on the clinics. Then we say, all right, well we have in the pipeline that business development brought in number of clinics, there’s like four, five of them. Then, we need to decide what it would cost us not to do certain work.
This is where I would like to dive into how do you determine cost of delay because we talked about the job duration, you kind of vote on that and decide what that is. The cost of delay is sort of a combination of other items because it’s not like you can’t just automatically have label on every task. If we’re talking in that context that you gave an example on clinics there’s three things that usually are taken into the account when you were thinking about cost of delay.
Cost of delay is usually split into three things that you can also vote on with the whole leadership team. Number one is, user business value. If we – out of these six deals, what is the value to our organization? You can basically measure it by revenue, if you need to hit certain target on the revenue or if you need to hit certain target on EBITDA, you can select which one and then out of six, pretty simple, you’re looking at one number and you’ll put them in order and say, “Okay, one, two, three, these are the numbers.”
Again, I like to associate them back with a one out of 10 because you’re not going on EBITDA because you want to then look at on what revenue that happens, you just throw the number seven and say, “This one is business value, three, this one build less value. Nine, this one is six” and then again, you’re comparing them to each other and say, “Okay, do we kind of, T-shirt size them that way.”
The second thing that is a component of the cost of delay is the time criticality. How critical it is for us to assess this clinic versus that clinic? For example, there is six clinics in the pipeline and then business development finds out that they want to sell clinic within three months. Not as much concerned on the culture, which they’re selling in, the guy’s tired, burned out, COVID and then he just wants to sell.
If you don’t close this clinic in three months, he’s going to sell it to someone else. There’s a time criticality. Again, you take that into equation and you add that to business values. Now you have your subjective, converted to objective and business value then you also vote as the team and saying, time criticality on certainty, so that’s component number two. The third component of cost of delay is risk reduction or opportunity enablement. It’s one of the two.
I’ll give you an example of that. You have six clinics in the pipeline, we assess them again for business value, time criticality and now we’re looking at risk reduction. For example, our debt-to-equity ratio is creeping up and we’re close or EBITDA to debt ratio rate. If you’re taking money from the bank to acquire the practices and then bank is not going to give you more debts if you’re early consolidator, if your ratio is over fine.
Start using four, maybe five, maybe up to six, not more than seven. When you were a large organization, maybe they’ll allow you to go up to seven. You need to increase your EBITDA and as a consolidator, you may look at this and say, “Okay, well this is more time critical clinic but the risk reduction is the greatest.” We have the risk of not getting money from the bank and if our EBITDA is not going to be much bigger right now, yes we have five clinics but one of them is a very large hospital that we didn’t want to buy because operations were not ready but then if we buy this clinic for $20 million, we’ll have this huge EBITDA that will open up the window of debt.
You make the third, sort of one out of ten assessment of each opportunity, so then you have the entire cost of delay from three numbers. You take your business value, you add the time criticality and you add the risk reduction and that’s where you arrive to cost of delay and you divide it by the job duration, which we determine at the beginning. It’s confusing to hear it on the sort of podcast but I really recommend to listeners to go to vetintegrations.com.
To come to the consolidator operating framework and click on the prioritization so it describes the methodology there.
Yeah, definitely and I mean, I actually have that pulled up and I’m looking at it and following along as you’re speaking because it is helpful to be able to see it. That’s the waited portion of it, which is makes a lot more sense when you’re looking at that and one thing as you were talking, I was curious, these things are not happening. These decisions are not happening siloed from one another, is that right?
You are comparing the opportunity or the user business value of one deal or one opportunity to a different one as oppose to just ranking them independently, is that correct?
That’s the key, yeah because what exactly and that is where the prioritization happens, right? Because you are arriving to an objective number, now it is not, “Bob said this, Nancy said that.” All together, we contributed to this decision because what also happens is if you just ask five people, which one is the priority for you, marketing may have one priority. Business development will have another priority, operations will have a third priority because maybe they’re downstream.
They’re clogged and they can’t accept more clinics, so every department will have a different opinion on this if it is so subjective but when you take all the leaders in the room and you do this exercise, by the way, you can go through 65 items on the list and rank them that way in two hours and have the exact order in which you should execute on tasks, acquisitions, whatever you were doing in business. It’s a phenomenal methodology that was originally used to put the backlogged items in the software development and you always have tons of ideas from customers.
You always have a lot of ideas from internal stakeholders like marketing or your support ones to do this integration and asking the dev team and dev team is really – it needs to be really focused on what they’re developing and what they’re not developing. After all the requests were put in, then they are assessed with this methodology and you can actually put the entire formula into the Excel and then as you sort it out, the Excel will kind of sort them out into order for you and then after two hours, you arrive to a very solid strategy on how to execute on this within this quarter.
I think that’s wonderful. The other thing, you know, two things that we have hit on there but don’t always hit on when we’re talking about these topics is what the risk is of not doing this. I think just from listening to you and my knowledge, I think one of the risk is overloading your systems. On the BD side, the business development side, your risk is not buying the clinic that needs to be bought right then or pushing through a clinic that operations isn’t ready for because you haven’t put together the cost to delay or any of those sort of things.
What other potential risks would happen not just within the consolidation but by not taking advantage of the overall system of where to shore this job first and prioritization as a whole?
Well, it’s a very typical problem in any organization. The other thing that we talked about in the past, the OKR, how do you size the tasks because if you have a task of like starting the ecommerce platform and then next to the item, you will have something like create an SOP of how do you buy computer for a new employee, those are vastly different size of projects. One is a major initiative for probably the entire quarter with like two departments, development and marketing and then another one it’s someone task.
It’s not a rock, it’s not the quarterly plan, it is just a small item so you really need to be careful how do you size them because you can take through this prioritization sequence only items that are equal in value like how big they are on the level of the organization. That’s why if you scroll back to the left on the consolidator operating framework, you will see that there is – it starts with the objectives given by the board and it’s initiatives by executive team.
They were broken down into the rocks, the regional managers have milestones and then the projects and then you always want to make sure when you’re prioritizing, they are different sizes. A lot of companies struggle with having 65 things to do and it’s basically half of it is someone’s to-do list. It is not a major plan, so you really need to kind of sift through those and make sure that you’re having the right items. That’s another thing that a lot of companies do.
Yeah, as I look at the – our framework again, it’s interesting. Prioritization is the only thing on the whole board here that – or one of two things that has the multiple boxes of the same thing. Prioritization falls in every single level of the organization. It is important for everyone to do and I think the other thing that’s important is the impact that it has on reducing burnout.
There is a new article that you just wrote, so it’s very well done and on the cover of DVM360, discussing some of the work that VIS and you have been doing around burnout prevention but prioritization really is a major burnout prevention tool because you should be able to have actionable numbers of metrics and ideas behind every single step that’s going through the business. Obviously, a lot of these things are discussing at the corporate level or the executive level of what’s going on or the regional level but maybe not as much within the practice.
How do you think that corporate teams or regional teams could describe prioritization to the clinic with a way to let them know, “This is why we’re doing this, this is how we got to these decisions and our goal is to improve the business as well as preventing burnout.”
It is a great topic that you touched on because usually what happens in the organizations that did use prioritization and finish their task because one thing is prioritize and then you need to execute on them because you can prioritize and say, “Okay, these five items I’m going to do in sequence, one, two, three, four, five” and then you get all five off and then you are again doing everything at the same time.
The important thing here is there’s two factors. One is proper change management, so when you’re accepting the task to be even not executed, just when you talked about it and said, “We are going to start the ecommerce platform” you don’t start it in some marketing or dev department until it’s half done and then just push it on the clinics. You need to have that weekly rhythm with the entire company where you kick off the initiatives like that and then everybody knows that this is coming.
Then you take it into different phases of development and then you develop sort of you explore the item, you create requirements then you kick it off again and showing everything that you’re doing and then after it’s completed, you deploy it to the clinics. That’s the proper sequence. When you don’t do that, the classic problem between upstream and downstream conflict happens because upstream is usually business development and the integrations and then sometimes they’ll include them into sort of upstream, sometimes not.
Then everything downstream is operations and when those two departments are not connected, people in the upstream in classic sort of agility framework are things that can rapidly change and they can change the priorities. They can fall out of the funnel. There are things that visionary and maybe the customers can change on the go and in development world, it is something that visionaries coming out with their hundred features and then before it hits developers, it needs to go through validation of the hypothesis, the cost of delay for doing this and you make a solid decision to execute on this.
If you don’t do that, every idea that comes upstream is just thrown downstream and then after they started working on it, it discontinues because upstream decided to stop this initiative because it does not give value anymore. This is the major conflict in any large organization when there are two sort of concepts of upstream and downstream. In the software development world, it was me with SmartFlow. I had a zillion ideas per day and then half of the zillion would be dropped into our design.
Then design would drop it on developers, they would start coding and then I’d come back next week from another conference or implementation and like, “And here’s a new idea” and then they’re like, “Well, we’re working on this” and like, “No, forget about that. Here’s a new idea” so upstream should be very flexible. Downstream should not be flexible, they should take things into execution and complete it.
How that all goes back to burnout is that usually in organizations when there is no good prioritization methodology, downstream are the people that are actually doing the work think that their executive team has no idea what they’re doing and changing their mind three times a day and that is usually what you see on the burnout side is because people are just getting tired of it and then they just leave.
Definitely. Well, I appreciate that we went through this because it is something that’s valuable. It is something that I think is a nice exercise and a nice way for people to be able to plug something and then be able to just listen to this, read some information about it and really implement it. It doesn’t require you to change your entire organization. It is something though that you can really do and take control over some of the decision making that’s going on in prioritization within the business.
Usually when we have a guest, I get to ask them for a book and a guest recommendation but this time, I’m just a couple of days away from a 12 to 15 hour flight, so you get 15 hours of my brain diving into a book unless I put on my own mask and fall asleep but what should I read while I’m on a flight?
You should watch then movies, so that’s number one.
Number one, yeah. You know, maybe a little movie just during the meal service if they are even doing that for the flight but –
Yeah, I think that while we talked about Traction I think that’s a good part. If you haven’t read that book that would be very good for this but I would refer because this needs to be a little visual like if we were talking about this, then I think that going onto vetintegrations.com, onto the framework and clicking on the prioritization, then you will get a visual how to build out the system. We can also teach you that too so if there is any people that are interested in learning how to do that, they can contact us. Yeah and on the books though Ryan, you have how many hours did you said? 14?
I think it’s like 12 to 15, somewhere in there. It is a lot of time zones. I know on the way back, I get home before I leave.
The excellent book if you haven’t read it is The Goal by Eliyahu Goldratt and then there is the second book that is sort of an – it’s not a sequel but it’s similar to The Goal, which I am reading right now is called The Phoenix Project. It is actually very similar to that and they refer a lot to The Goal but now they are talking about how the operations and IT and dev weren’t getting together and it’s just sort of written in a sort of a fiction kind of style.
It’s not sort of very business-y book, so it will put you right to sleep, which it did with me on the flight here, so The Phoenix Project and The Goal.
All right, so you have a few days, you have a week while I’m there as well to finish that book so that I can take it from you and fly home with it, so you better buckle down.
It’s in Audible so you can access that.
It’s in Audible, even better. I’ll be able to listen to it. Well, this was great Ivan. Always enjoyable when we get to do our one-on-one episodes together. Really excited to see you and the whole team very soon and then one of the next episodes that are – you know, we might slot a guest in there but one of the episodes that are – everyone is going to be able to listen to is one live from Kiev and looking forward to it very much.
Me too, so have a safe flight and I hope to see you Monday in one piece.