Why You Should Strategically Plan on a Quarterly Basis

Webinar transcript – Watch the webinar: How to Thrive in a Fast-Paced Environment – The Art of Quarterly Strategic Planning

Myriam – We’re very happy to welcome you on this Friday to our Webinar to learn more on the Art of Quarterly Planning to help you meet some of the challenges of this modern marketplace. My name is Myriam Sanie and I’m with the marketing team here at Cprime. I’m very happy to introduce Dan Teixeira. Dan is an enterprise transformation lead with over 15 years’ experience, and he helps to lead organizations from team level to portfolio transformation to build mission critical applications to help organizations meet their business goals. He brings his expertise in Agile and Lean best practices and industry experience to help enterprises deliver the right results faster and with higher quality. He is passionate about shepherding organizational change management to ensure organizations thrive in today’s competitive markets.

Dan – Thank you and welcome. Some of the things we’ll be talking about today are some of the challenges that planning brings to organizations. We’ll talk about some of the things that we’ve instituted as far as modifying and adjusting the way that we think about our annual planning, and then thinking about how do we get this more towards a quarterly cadence. The one thing to note is we’re not going to get rid of annual planning from a fiscal perspective, from a stakeholder management perspective. That annual cycle still needs to live, but the quarterly rebalancing to it is what we’re going to try to set up.

And so hopefully by the end of this you’ll have some takeaways, some things that you can practically take into your workday and then we’ll leave all the questions and answers towards the end. So if we look at the problem statement and you think about what the time that you guys were spending in creating your annual plan, we haven’t even completed delivering what we’ve done prior and we’re already thinking about what are we going to do in the future. And so this creates a ton of wasteful behaviors and it pulls people, many of you on the phone, pulls people from when you’re executing and you get pulled to look at planning as it’s going forth. And it’s very, very wasteful as far as the activities that it takes. It results in wishful thinking to a committed plan.

So many of the agile principles and all that talk against this kind of wishful thinking and respect for people aspect up against this and it sets unreal expectations. If we have stakeholders that only chime in a couple of times and not frequently, they see that annual plan, they believe that it’s going to happen regardless. The other space is that this creates a series of long queues. With long queues. We don’t get that feedback loop and so we decide in early, in the mid parts of the year prior that we’re going to do this, this thing based upon value. We never rehash and never rethink about that. We know that long queues as a result of them create poor quality. And so these long queues or something that that become a problem as a result of it. We commit ourselves. We hold ourselves to it. We’ve all been a part of a project that we started working on. A quarter of the way through, we know that it’s not going to deliver the value that we intended, but because it was committed during an annual plan, we continue to do that project and live it through. We need to build a system that lets us react to add and change. And then there’s a ton of overhead as a result of project based budgets. So we all know this from a thought process around Scaled Agile Framework that we need to look at budgeting teams and we need to think about the concept of budgeting teams so that that team can live, pivot and work on the biggest thing of value rather than having project based funding that creates a series of overhead intentions.

Now what we’re going to talk through today is an interim step to this last bullet. So we can’t move directly. Hey, we’re doing project funding today, tomorrow, team funding. There’s some gradual steps that we’ll talk about as we work through and get through those. So these are the challenges ahead of us. These are the things that all of you are sitting there and saying, this is the pain that either I am going through now as a part of annual planning. Some of you are going to start very soon. Other ones have started already on some of this annual planning for 2020, and then the year makes it even worse because 2020 is kind of clinchy and then all of a sudden companies are thinking I need a 2020 plan and there’s put a little bit more thought process and wasteful behavior around that.

At times those commitments are not spoken to and they’re not translated and communicated down to the rest of the organization. So some of these in annual planning, many times I’ve seen that people do this at a very high level, and those commitments are made, but it’s never communicated down. And there’s one thing in which we wish our customers knew exactly what they wanted. And people building things knew exactly how to build them. And in reality today, what happens is our customers learn as we build things and our people building things learn how to build them by actually building them. So the days of going through several layers and reviews of analysis and solutioning, many times the best aspect of solutioning is to start building something, considering failing fast and going forth as a result of it.

And many times we build things and it was built right to what we wanted to, but the value is not there because the customer doesn’t understand that value until they’re moving forth. So let’s talk a little bit about the solution. I think we understand some of the problems that are put in place. There’s essentially five things that I want to convey here today. So the first step of annual planning is not understanding demand. It’s understanding your team’s run rate. We will then talk about how do we then organize the understanding of demands? How do we build roadmaps for the future and start lining in our budgets? How do you finalize against those budgets? Many times this is grueling at the end, right? So there’s all this prep work and then there’s these closed door meetings for days and days where they finalize budgets.

And then the key in annual planning is just because you’ve set the budget, you haven’t done anything. The preparation for next year is key. Many times we see we’ve all been through some organizations where you don’t burn money evenly in January and then you have to start spending it like crazy and then possibly even give some money back. So we’ll talk about some of those pain points, but let’s start where we should. Let’s start with understanding our current run rate. So you need to understand the makeup of teams within your organization. And the desire is that we have many agile teams. These are fully dedicated Scrum or Kanban teams. And so cross functional is possible, component-based funding from component based teams, that’s fine too. But we need to understand who is on those teams, what is the makeup of those teams. And what are the run rates of those teams.

If that team is going to continue, what, how long do we expect them to continue into the next year? So as some of this, to get into this mindset, we do have to have a little bit of a precursor of having some quality of agile teams. So if you don’t have agile teams yet, everything that we’re going to go through here today is going to be your 2.0 of your evolution of your agile journey. We need to have some notion of those agile teams. Now, not everybody’s going to man an agile team. So we also have this notion of a cross delivery enablement team. These are enablers of the teams, the organization. These are people in roles, such as release train engineers, architects, your product managers and any level of business analysts that are on the enterprise level that are supporting in there in order to support the agile teams.

And so you would put this in a cross delivery enablement team. It is always an interesting figure to see how much do you have in enablement, how much money are you spending in enablement versus how much funding money are you spending in teams. There is kind of rules out there that say hey, maybe spend 10% 25% 20%. I’m not going to go into that today. But that number per organization is an important one to know and understand. The next bit is you are going to have not non agile teams. So these are going to be teams that are other people that are supporting and they are there to support the agile team. So from a SAFe perspective, this would be your shared service teams. From other perspectives. This would be just teams that are around that are going to support the teams as they’re going forth.

They should have a consistent run rate but they may not be running as a Scrum or Kanban team. Some of your legacy like assets that have one or two people supporting them, backend systems, all of that. That’s where these non-agile teams would come into play. And then lastly, we will live in a world where there’s still waterfall, especially in this kind of hybrid mode. And in some organizations they may live in this forever as it’s going forth. And so we do have to consider that waterfall team. So is there a project that’s existing in waterfall that we traditionally would call carryover? Is there a project that we’re looking to start new and that we would do in waterfall? You would look to create kind of the same costing methods that you would do previously. As you’re going forth, if you divide your organization into these categories and you begin thinking about what is the cost to run this, you now have an understanding of that cost.

So you understand that run rate of each team and understand that those teams will continue on to next year. You sum up those run rates based upon programs or whatever, release trains or if you’re in that mode or initiatives that you have going on and you sum those up so that you have an understanding of within this area, here’s the run rate of the teams that we have. You now have an understanding and should have an understanding of come January when actuals come out, what number am I going to hit? And the whole aspect of a quality kind of agile organization is that you should have an understanding and a consistency of what your run rate is over a period of time. So step one, we now understand what the current organization is running at a run rate based on the categories. Now we’re going to try to understand the demand.

So the first question that we have to ask is where do priorities come from? Where do demands come from? In many organizations I’ve seen where they start with demand and what they have is an email or a blast that comes out and tell us all your wonderful ideas. Anybody in the organization, tell us where you’re coming from. And we’d come back with 272 requests and these are all things that people want and desire. And so we go off and we would estimate those 272 odd requests. And that’s just not a value add thing to do. And so instead, what we’re looking to do is to align some of those requests and make sure that they’re aligned to where people are thinking. So we have our strategic themes. Every organization has something along this line. They may call them pillars, they may call them strategic initiatives, all that.

One of the questions that you should ask is every request that we have, how does it benefit those pillars? And if it’s a request that the organization believes that they should do, but it’s not organized in the pillars, maybe the pillars are incorrect. Are we doing some major programs? The areas that typically asked for things, marketing, legal compliance, is this tech enablement? Are we investing in our CI/CF pipeline? All that’s coming through. Is this coming directly from the team? Is it coming from production support? So the first thing you have to do and understanding your demand is understanding the channels that all the work comes into and how it strategically aligns to different parts of the organization as to how we’re figuring out where to spend money.

Then we’re going to use our Kanban flow. So this is right out of the Scaled Agile Framework, our traditional epic Kanban flow or a portfolio Kanban flow. So this is where as a part of this flow, there’s something here that I think is often forgot about and often overviewed and in traditional organizations it would have gone funnel – analysis and review. Meaning that we would have took every idea we’ve ever had. We would have done a level of analysis solution and figure out the cost benefit and figure out how much is it going to cost us, what’s the first MVP going to be, all of that. And then we would have reviewed and decided a list. And so we would have gone through and analyzed 200 things. And then we’ve only would have approved 20. And so 180 things just went to waste. One key aspect of the portfolio Kanban is that we review based on value first and so we take and we define our epic statements, we define our weighted shortest job first.

We get a rough understanding and even I would argue that you can get a rough understanding of order of magnitude of how much this is going to cost. This is going to take us a year, six months, three months? Is it just one team, is it teams? Does it take the whole organization? And we could do a quick kind of judgment on is this something worth doing? And then once we believe it’s worth doing, that’s where we move things through into analyzing. And that’s where we get into the deep message of things. As things go on to analyzing, things can always fall out. We can always get a no go here and push things out. But hopefully what we’re doing is we’re pushing things more of it as being filtered out through the review. And as we get to analysis, these things have a better chance to going into implementation and just like any backlog, we’re refining the things to the top in more granular than we are to the things to the bottom.

Things do kick themselves out as a result. The other aspect is, in many of your organizations, setting work in progress limits in the beginning may be impossible. This is something that will grow with time. The first step that you have with the portfolio Kanban is to first allow yourselves to have transparency. Many organizations that I’ve gone into, if I ask five different people on a specific initiative, they give me five different answers. Some say it’s in review, some say it’s in implementation. Some say we’ve finished it already. Some ask, what the heck is that project? I don’t even know what it is. So the first part is gaining that transparency and making sure that we’re doing the reviewing before we go into a deep level of analysis. We’ll talk in a bit as the organization matures, as you can set work in progress as it’s coming into play here. One key note on the bottom is you do want to establish this concept of Epic owners. This is an important concept. Who is the passionate person that is going to drive you to get this thing complete? And so that Epic owner will be the key linchpin that’s holding all the other stakeholders aligned and making sure that it goes through this funnel process specifically to the review and analysis and then shepherding it through the teams.
As a result, we align our backlog, we get some visibility into it, we need to build longer term roadmaps. And so the whole process around this is the Scaled Agile Framework has really matured significantly over the past couple of years in that we start now talking about here’s a solution roadmap. So this is where we’re not just talking about the next sprint, the next program increment, the next year. But we have a horizon of what we’re looking to do over the next up to four years. Now, none of us is committed, but it’s directionally where we would like to go, it’s directionally where we’re looking to head. And so that’s something that we call our solutioning roadmap. And so having this in play helps us to understand what things should we be prioritizing over others? What things should we bringing into analysis?

So in this example here of autonomous cars, if we’re in Q4 of the other year, and we’re starting to think we’re starting to think about or starting Q4, we’re starting to think about the next year. The ability to obey traffic laws as it states here, the ability to make churns. Those are the things that we would next look to prioritize based on the completion of the prior. And then we have our traditional program increment roadmaps. And so these show, what are we doing in PI one, PI two and PI 3. It’s interesting to note here we have committed in the first PI, forecasted in the second, we don’t commit to the whole thing. That creates a long queues that we want them to, but we know directionally where we’re going. There’s overall a fiscal responsibility for us to have a directional standpoint. We can’t be going sprint to sprint, PI to PI without having some of that direction. But to that counterpart we have to understand that committing to that does create quality issues for the longer term. Committing near term is what we would like to see.

So if we think about the different guardrails that we’re putting in play, we have the portfolio Kanban, we have an aspect of understanding, um, where our solution is going, the roadmaps that we’re heading to. One of the great kind of things that Scaled Agile has come out with of late is this concept of horizons. I’m going to spend a minute here talking about these horizons. So this is coming from the perspective that Horizon 3, are the things that you’re evaluating early. These are early products that you’re looking to evaluate out. These would come from possibly innovation labs. They would come from areas of where we’re thinking to focus in and make sure that, we’re getting ahead of the market beating competitors out to things. Horizon 2 is where we really start emerging these ideas. So this is where we validated that it’s something good to do.

We want to start getting it out there to actually get it into the market and get it done. And so here we start, this is where our major programs will be. This is where we’ll invest a significant amount of money to get something from idea into conception. Horizon 1 is what is actively being used. These are things that are being used by our customers. They are things that are being used as solutions to what we’re looking for. And so there’s two kind of aspects of this. One of them is that we’re continuing to invest, meaning we’ve put an MVP out there and we’re continuing to iterate and to put additional enhancements to it and to continue to build out the product. The other one is extracting. So we’re no longer investing further into this at this moment and we’re just receiving the benefit from it.

And then lastly this is our Horizon 2, where we spend money. We have to spend money in order to retire things. And so we’ve got to take time and remember that many times organizations have left legacy applications open and we’ve got to invest every year to make sure that we properly retire things so that we don’t build up our technical debt as we’re going forward. And so that commit decommissioning takes some time. And so as you’re going into annual planning, this is a good tool to say, how much money are we spending in evaluating new ideas? How much money are we spending in taking those new ideas and making them real? How much money are we spending in a valuating and kind of investing and extracting from our new, and how much are we investing in retiring things? And so this is a good tool that helps you to visualize, are we spending our money properly as a result of it, as going forward?

Once you have these across large organizations, the hard part is going to be, each of these horizons could be different products from a business perspective. This could be different applications, different app solutions from a technology perspective. How do we bring it all together? And then as a result of that, establish our budgets and what we’re looking to flow into. The first part of it is having true transparency. So the transparency aspect is going to be key. And having these investment horizons, the Kanbans, the roadmaps across all of them and having that transparency around what we’re looking for is going to be critical. Then we’ve got to bring these pieces together. And as a result of it, we have to make tradeoffs year to year, quarter to quarter. We may want to invest more in one area over a next as a result of it.

And so this concept of purposeful budgeting is what comes into play where different stakeholders from different parts of your business, from different parts of technology, come together and they make sure that we’re aligning and not just doing what’s individually selfish and profitable for one piece of the organization, but looking to do what’s best for the whole. As we think about from a system view, an organization is only as good as its weakest link. And so if an organization gets really strong in one area and weak in others, there needs to be that holistic system view as we’re coming together. This process could be very “mind consuming” and it also could be very stressful. You could result in here in saying, hey, we’re not funding that team, so we have to let that team go. Or one team may move from one business unit to a next. And so these are the tough decisions that many organizations, the leaders within those organizations have to make.

The last part of this is as part of that transparency, we have to understand how are we funding things? What types of work are we funding? Are we spending enough money in our technical debt and maintenance? Are we spending enough money in building up our infrastructure, in our enablers and how much are we spending for our new features as a result of it? And understanding this on a yearly PI to PI and sprint to sprint is really important. When we talk to individual agile teams and we say you should have a working agreement with your product owner, to say we are going to by sprint, spend 10% on our technical debt, 15% on enablers and the rest on teachers. Those percentages are ones that I’ve made up. You would make that up based on the organization that you’re in. These are guardrails, right? So one sprint, we may spend the whole time on new features. The next one, the whole time on tech enablers, but there are guard rails. We should also have these at the annual planning cycle as we’re going forth and revisit them every quarter as a result of it, as what’s going forth as well. And so that kind of conscious, conscientious decision to say, are we investing in the right things? Are we investing in the build out of new features in the infrastructure and in our technical debt?

And then you know, lastly we want to make sure that we’re prioritizing in the right way. And so we’ve learned from Scaled Agile prioritization based on weighted shortest job first (WSJF) and considering cost size or cost of delay over duration. So we want to make sure that we have a concept of making sure that we are considering costs of delay, the cost of not doing something when we’re prioritizing. And then considering that over duration. Now what results as many times as a part of thinking of weighted shortest job first is that the biggest initiatives that we have, the ones that provide us the biggest value are also many times the biggest things to complete. And so this weighted shortest job, first done through the portfolio Kanban will help us to break down ideas to smaller pieces. They’ll help us to think through what should be the initial MVPs.

This also helps us to break down those large queues. So as a result, you may have a very big project, you rank it among a bunch of others and using weighted shortest job first you may see that that project ranks lower, that Epic ranks lower as a result of it. What you want to do is not say, all right, let’s never do that again, because that could be a major breakthrough of value for your organization. You want to take that piece of work and break it down smaller. How can we incrementally grow upon that? How can we build out an initial portion to it and then evaluate whether it’s something worth doing and continue to work through, rather than assuming we know everything which we know is false and build out that entire thing. And then at the end we find out that it’s the wrong thing to do. And so the key thing that weighted shortest job first us for you is it helps you to decouple and to build incrementally. And as a result of decoupling and building incrementally, you’re allowed to truly prioritize with them.

So those are all tools that help us to understand how do we create our business demand. Now let’s talk about how do we align? We understand our runway, we understand our business demand, how do we bring that all together? And so at this point what need to have is a kind of pow wow session where we begin to understand what are the Epics that are coming in as priority and which teams, which existing teams do they take up capacity from? And so some of this is going to be swag level estimates. We don’t have to do this anymore because we have the run rate. We don’t have to do this anymore to say we need 0.75 of Johnny and 0.75 of Jane in order to complete this work. We now say that this piece of work is probably going to take this team, which has a run rate of 500 k a month, two months to do.

so we would line that up and fill in their capacity for that two months. And you begin to continuously fill in that capacity based on the Epics until the teams are fully capacitized. And at that point, what you have is you have a line in the sand that’s drawn. If we want to continue the existing run rate that we have, we’re going to keep these teams. If we want to build, do more work, we’re going to have to ramp on new teams as a result of it. And so, then there’s tradeoffs that are made. So we begin making those different decisions based upon what’s going through. We start thinking about where a feedback were then as a result, could there be possibly one thing that we want to do over another? How do we have that active discussion to make sure that we align?

What the result from this comes into play is by the end of this, we’re looking to finalize our budgets and by finalizing our budgets, we’re going to look at is we’re going to review the value stream, the release trains and the team budgets, and we’re going to review the locking up of what epics those teams can do. From the teams that we funded, what can the teams do and figure out where are the bottom lines that come into play? We’ll then continue to adjust this. This is definitely an iterative process that happens and it’s with our key stakeholders that it doesn’t occur back and forth. Then we have a couple of theoreticals that happen as a result of it, adjustments that are made and so we try to make it so that we understand what are our team capacity and as a result of that team capacity, what can we do from an Epic perspective? What teams do we need to ramp up as a result of it as well?

Lastly, those new teams can’t just start January 1st and so if you’ve just finalized your budget in December, most likely to hire new people, contract new people, whatever you’re going through. It doesn’t start January 1st and so we’ve got to set accurate run rate projections to it. So we may say, it’s going to take us a month to recruit a month to fully onboard. Those people may not start until middle of February and then also it’s going to take some training time so they may not be fully equipped to go through until the beginning of March. So really the kickoff of the work would probably be beginning of March. But setting your delivery system up for success as critical. A key pitfall that I always see is right before Thanksgiving we say, Hey, we’ve finalized the plan. It’s perfect. We’re going to go December. Most organizations don’t. You know, it’s a busy time with personal and holidays and all that such, and then we get to January and we’re just like, well, what are we supposed to do? We locked it through in December, but the teams aren’t here. We need to build plans to prepare and to make sure that we’re kicking it off and setting ourselves up for success for the next year.

I’m seeing a lot of questions come in. Let’s just recap on the key takeaways and I love the Q&A, so we’ll get that going. So the key takeaways, first and foremost, understand your run rate, have dedicated teams and understand your run rate. Where there’s not dedicated teams, put people into buckets like waterfall teams, like enabler teams and get them to settle in. Use roadmaps to help us stop against wishful thinking milestones. We commit to the near term. Here’s where we’re setting it directionally. We can’t just commit to the near term without sending some of that direction forward. It’s just makes it fiscally irresponsible. Use the portfolio guardrails that we discussed to help prioritize what should be funding. Use the concepts of horizons to understand where products are and where they’re evolving.

Use the capacity allocation. How much are we spending on technical debt? Use the portfolio Kanban so we understand where work is in our cycle as it’s going forward. Spend time to make sure that you are preparing your organization for success. So make sure that you are true to when a team will be onboarded. What time are they active to start? Not it’s a kickoff in January, but if it only kicks off due to staffing and onboarding in March, that’s where you want it to go. And then lastly is remember that this annual planning cycle doesn’t go away because annually we do need a lock in our budgets. But what we know is true is that every quarter, we need to regroup ourselves. So the aspects of trying to know everything up front and knowing how to build everything is no longer a world we live in.

And so once you commit to this annual plan, whoever those key stakeholders should come back together every quarter, they should review the roadmaps. They should review the horizons, they should review the portfolio Kanban. They should look at the different capacity allocations, everything that we’ve done in annual planning, . They should do that again and now as a result of it, make adjustments as it’s going forward. So from a time capacity perspective, we started this conversation around: Everyone’s saying that, hey, we start this process pretty early and it takes six months and we try to big bang it through or trying to do instead now is to do enough so that we set the directions, set the fiscal money as to where we’re money’s could be going to be spent and then know that we can’t know everything upfront. So as a result of it, we’re then going to quarterly come back and adjust in that cycle. And so, you set the fiscal year for the money and you look at the boundaries of what are priorities and what should be worked on a quarter to quarter basis and set your organization up for success.

Myriam – A few questions. So we can probably start with the first one, which has to do with run rates. There are a lot of different questions out there about, what are run rates, exactly how to calculate run rates? And how do we calculate those run rates when we don’t have any historical data.

Dan – Great question. So when I talk about runway, I’m talking about fiscal dollar run rates. So we have a team, an agile team that consists of four developers, two folks that are more forecast from a QA practice. Let’s assume it’s not a fully cross functional team. We also have a business analyst on there. We have a product owner and we have a scrum master in many organizations. We use blended rates so that we don’t have people know the exact salary of what we have. We would look at the blended rates for each of those roles. And so you may have a rate of whatever it is per hour, per day, per week, and we would look at what is the cost of that person for that given month.

Or you could even do it for that given sprint. Very important to know we are not correlating this to story points. Do not correlate this to story points. I’m going to say that again, do not correlate this to story points. When you’re looking at annual planning, it is too large of a horizon to look at it from a story point perspective or to calculate the cost of each story point. Because if you start calculating the cost of each story point, if you outsource, I’m going to tell you all the work is 20 points and you’re going to give me a lot of money to do a little amount of work. So that costing of story points makes absolutely no sense. So when we talk about run rate, it’s understanding who is on your team, what is the cost of that team, what is the cost of keeping that team consistent. So if you have a team that together based on the blended rates based on the people that are on it, let’s say they cost you per simple math, a hundred thousand a month, you have that team for 12 months, you’re going to keep them fully dedicated. It’s going to cost you one point $2 million. That’s the cost of the team. You’re then going to bring the work to the team and figure out how you can fill that into there.

From a technology perspective, we haven’t had a lot of great tools that do this right. So if you think of the ones that are completely segregated, so the work is in one and the financial tracking in another. So Atlassian Jira Align, previously Agile Craft, is a tool that lets you do this in an easier fashion. And if you’re interested, we have a lot of documentation and expertise, but this kind of activity can be looked at and explicited with Jira Align.

Paul asks how can we convince executives to adopt this Quarterly Planning philosophy? Get them involved early in demos. So if you have a team that’s building something, it’s early states, they’re still doing some technical enablement work. They haven’t had that big Aha moment. Don’t bring your stakeholders to that demos, but when your team has built something of quality, then start including them as a part of those demos. And not just the product owners and the product managers, but some of the key stakeholders. Reach out to them and say, hey, we have an early view onto the products that you really want. Would love to get your feedback. The team wants to show it to you. So the next piece of this is PI Planning.

And so PI planning gets a direct engagement with the business folks and the teams that are building. With no harm to anybody that’s working at that level, but when you’re in that state, you sometimes forget that the people that are building are actually people. So one of the things that I always harp on tremendously is stop using the word resource. We are not resources. We can’t be 100% utilized. We can’t be pushed to certain limits. We can’t be tasked, switched and used across multiple things. And again, to no harm to anyone, some folks within the business often forget that these folks are not, the people that are building are not a row on the excel sheet, but they’re actual people. So the more that you show them that they are people, the more you have them interact with them, that then becomes a reminder.

And then when you talk to them about, hey, there’s a capacity constraint, hey, we have to call priorities over this. They’re not just saying, why don’t you just add five more lines to that excel sheet of people there, remembering who built it, they’re remembering and knowing who it was there. And so a lot of that aspects of kind of Gemba walking and showing them what’s being built, how they’re planning that and getting them sneak page into the sausage making, I think is the way that you begin to get them involved because they begin to become sympathetic to what’s actually happening and then they’re, you know, looking at and trying to be part of the solution and how to fix it.

Great. Thank you Dan. So last question, moving to Quarterly Planning, what would you say are the biggest pitfalls that customers need to watch out for?
We need to have business involvement and that business buy-in and that business sympathy. So the business involvement is a critical one. We talked about ways to get us towards implementing that. I think one of the other things to remember is the culture change. And that is the hardest thing to do. And so what I’ve seen many organizations try to say is, Hey, we used to fund projects last year. This year we’re going to do teams and it’s all going to flow through. And you’re not going to know how much anything costs, but don’t worry, we’re going to have the teams focus on value and all that. That’s a drastic change. So you’ve got to respect your organizational culture.

So, in the way that I’ve kind of articulated it here, we’re still funding projects, but we’re funding them by teams, not by 25% of one person, 50% of another, etc. And then from a quarterly aspect, they’re going to feel at times that, unless the work is being built incrementally, they’re not going to get the right insights. So you have to get PI planning in right in the beginning. You need to make sure that you have teams that are incrementally building, teams that are incrementally building together so that you get the positive and the actual data and meaningful conversations to come in to that quarterly planning cycle. So if you come back in and it’s the end of March and we have no further insight into the work because we’ve just been doing a bunch of analysis documents, then the quarterly planning won’t work at all. But if we’re building incrementally and we built something we’ve learned and now we need to make a possible pivot on it, that’s people will start being seeing the value out of kind of looking at this quarterly basis. So any the keys are, remember that your business owner has to be part of it, build your solution incrementally and then the quarterly planning will come into play and then culture changes lasts. So make sure that you do this in baby steps so that people can mature through the process.

Myriam – We’ve come to the end of our time together. Thank you to our audience for joining us, and to our speaker, Dan Teixeira, for sharing his insights with us. Have a great day! Okay.