Preparing for Business Transformation

Business ReadinessDigital TransformationProgram Management
Written By Michael Daehne

Introduction

Michael Daehne: Hey y'all, Welcome to Inflect. I'm Michael Daehne and on today's show, I'm joined by Pedro Cortez and Liz Pryor from the FlexPoint team to talk about preparing for your transformation. I’m really glad to have two of my team members here today who have so much experience envisioning, planning, and implementing large-scale business and technology transformation initiatives. They're also going to share some of their war stories. We're calling this a behind-the-scenes blog post they wrote earlier this month. I’m looking forward to the conversation.

Before we get into that, I want to give Pedro and Liz a chance to introduce themselves. So, Pedro, take it away.

Pedro Cortez: Thank you, Michael. My name is Pedro Cortez, and I am one of the directors here at FlexPoint on digital transformation. One of the focus areas I've had over my career has really been in product management and program management. I have a tendency to come into these implementation programs either at the very beginning and help navigate them through the early decisions of what business goals need to be attained and how we're trying to move forward. And sometimes we get brought in midstream, trying to figure out where things have gone wrong and how do we correct the missteps that have taken place from there. So, I’m looking forward to today's conversation.

Liz Pryor: I'm Liz Pryor, and my background is mostly in the software development and custom software world. I was there for five-to-six years. From there, I translated it into data transformation - how do you take the requirements and what's needed behind the scenes to then build the thing? And now we're taking something that's already built and trying to make it better and build the new thing.

Framework Overview

Michael Daehne: Awesome. So glad to have you both here. For those who haven't read the series of blog posts that y'all put together, the overarching theme of it is: ‘Hey, don't wait for your large project or transformation to start before you start working on some of the kind of key enabling activities, decision making, communications processes, and really defining the scope and the approach to the transformation.’

There's a lot of that stuff you can get ahead of, and so with the new year comes an opportunity for organizations to start doing some of that pre-work even as they may still be in the discovery phases and thinking through, ‘Hey, what investments are we going to make? What changes, what transformations are we going to, going to invest in this year?’

You put together a really awesome three-part framework around preparing the organization, defining the transformation, and planning the transformation. Pedro, maybe just briefly speak to what we mean by each of those three buckets, and then we'll get into some war stories and other lessons learned y'all have to share.

Pedro Cortez: Yeah. A lot of it comes down to, as businesses decide they want to make improvements and get better, more effective, more efficient, more profitable, they're looking for ways to make changes. You know, a lot of it has to do with the way they're changing their business strategy, their approach, the way they view their product lines, or the new technologies they want to implement in order to get them over the hump and take on these new objectives and goals.

When we looked at it, we broke it down into three phases.

  1. Preparing the Organization: In preparing the organization, what are the things you really need to think about? If you've decided that, ‘Hey look, we're at an inflection point; it's time for us to make a move. What do we need to consider in making that leap? Because it is going to require investment both in time and resources on top of, you know, financial implications to it on.’

  2. Defining the Transformation: Once you've done some of that initial thought processing and you’re trying to figure out where you need to go, then it's defining what objectives we want to meet. We're not just doing this for the sake of modernizing, right? Too many business transformations have failed that. Hey, here's the next new technology. We should adopt it, right? Really homing in on defining what it is we want to meet, what's the objective we want to reach, what's our business goals we want to drive towards.

  3. Planning for the Transformation: Once we define that, then lay out what does this transformation look like? Let's plan for it. What do we need to prepare for? Liz and I put some thoughts together on what that framework should look like. As you're moving into these concepts of these transformations for your business and how do we become bigger, better, stronger, faster? What should you be considering as a business if this is a leap you're getting ready to make?

MD: Yeah, great. I think what I loved about the framework y'all put together is it's not just about the project; it starts with the organization. Before you can start talking about the work you're going to do on a specific project, how do we work together? How do we communicate? How do we share decision-making across the organization? What are our delivery models? All those key questions.

Once you do start defining the transformation, scoping it, planning it, Liz, can you share any examples of some of the tactics? I think y'all mentioned gap sessions and some other ideas in your blog posts, but share tactics you may have used in the past to kind of get everyone on the same page about the work to be done and the scope and approach of the transformation.

Liz Pryor: Sure. Something that we did before is sit down and map out what were some of those key business processes that both systems need to support or both companies need to support. When you know what that main pipe that everything needs to go through looks like, and you're able to kind of define what the boundaries of that are, you know where you're working. Anything from there would be more specific. Just sitting down and defining: where's your freeway before you build the country roads?

Preparing Your Organization for Transformation

Michael Daehne: Yeah. Were there any other things early on in the planning phase or decisions you made or discussions you had that later on, six months, 12 months, 18 months later, that you were really glad you had because it maybe got everyone on the same page before you got into the fire of the project?

Liz Pryor: One thing that we did sit down and do is when an issue would arise or when there was a defect or when there’d be a problem, we mapped out who gets told what when down to a schedule, so people knew when to expect updates. I think it really saved us down the line to not have people blowing up phones or blowing you up over email when issues came up. They knew what to expect and when to expect it. That simple little trick saved us time down the road.

Pedro Cortez: To add a little more to the preparation phase, set up the roles and responsibilities for the people who are going to be on the team. You want to clearly define that at the outset, right? Who gets to participate in the decision-making process? Who are the people that need to be consulted? We've heard the term RACI before, right? Who's Responsible, Accountable, needs to be Consulted, or just Informed? That's a great framework to start from. We've also talked about looking at it from a DARE [Deciders, Advisors, Recommenders, Execution Stakeholders] perspective. You change the order, you're making some deciders in the room, and they get certain votes.

And you know, this communication plan is critical to the success of any of these transformations. Knowing who’s the right person to go to, who's your throughput, who's your front door in order to take on this task. Having that defined by the people who are going to be engaged in the project is critical. Otherwise, you might have informed somebody, ‘Hey, we've got a problem.’ Or, you know, to Liz's example - people could have gotten a phone call who I know that they've worked with defects in the past. I'm going to pick up the phone and call them. It might have been effective for them in the past, but when it's 3 AM and they're not the ones on-call, what are they going to do? They're going to pick up the phone and call the person who's actually on-call that night and responsible for defect triage, for this go-live, and all we're doing is upsetting the apple tree when we've got, you know, clearly dealing in a process you could be following. You want to get those articulated early on so that way you can follow those and know who to go through. That playbook gets established early on and just rely on it.

Defining the Transformation

Michael Daehne: Yeah, absolutely. I think that's such a good call out. On the idea of building a playbook and getting everyone aligned on the ways of working. Pedro, I know you've spent a lot of time in your career the delivery model or work management side of how we work together. What's our cadence? What’s our approach, or the tooling we're using? Share more about that and how you approach that early on when you're still in that preparation and planning phase.

Pedro Cortez: Yeah, I think one of the early decisions that has to be made is how are you going to handle the day-to-day operations while we're going through the transformation effort. Is the transformation work, the project research, the discovery, is that all going to be done as peanut butter spread on top of people's day jobs? Or is the company going to be supportive enough and invest enough to go find temporary support? Contractors, consultancy, whatever, to bring people in to help with the day-to-day operations and train them on that with the team that's going to be supplanted to go take on this new transformation.

It really starts there. The resource planning of who's going to be dedicated to the project. Again, we talked about roles a second ago. Who’s going to take on what role within the decision tree for this transformation?

Then it's getting your processes and protocols kind of laid out. Are we happy with Waterfall? Do we like using all the artifacts? Has that been beneficial for us? Waterfall is not dead, necessarily. I mean, people still use it today. It's reliable. It's predictable. There's value to that. If it's a known way of replacing legacy systems or legacy work. Okay.

But in today's environment, we're seeing more and more clients move towards an Agile delivery methodology and using those frameworks more because the feedback turnaround is so much faster. You can get into a discovery session on Monday, and by Wednesday, people are bringing stories back to you, and you can evaluate if the interpretation is correct. Is this acceptance criteria what I would expect it to be, and does it actually meet my needs when this widget gets built in the end? That feedback loop is really critical - the turnaround in Agile is so much faster and why you tend to see more successful throughput because you're eliminating the development waste on the front side of that.

Not to turn this into an Agile podcast, but in essence, the thing that we're trying to do with these clients that really want to move towards that Agility framework is provide more of that customer interaction face-to-face. Get more of the feedback in a faster turnaround time. Do things in prototype mode. There's nothing wrong with laying things out in PowerPoint or some other visualization tool that says, ‘Hey, this is what it might look like. This is what the architecture could be.’ You know, Visio is a great tool to lay out what some of these sketches and schemes could look like.

Actually, having to put hands on the keyboard and code, so when you put these prototypes in front of people, now they have a chance to evaluate. ‘Oh, it's just going to get me what I need. This is what my getting the expected result that I'm hoping to achieve at the end of it. Am I reaching my goals?’ So that's really where some of those frameworks will become critical in deciding which one of these two past leads my company towards success.

And then sometimes you've got to reevaluate that midstream. You may be a year in or 18 months into the program, and either you're on track and keep going or maybe things aren't coming as fast as you need them to, or they're not coming in a particular way. ‘We're not seeing success, and now it's time to re-evaluate,’ not just your resources and teams — do we have people who are in the right positions to make this program successful — but are we using the right methods? Do we have the right frameworks in place? Have we set ourselves up for success?

Some of the things that we've seen at some of our client sites, we've had people who've wanted to make that transition from Waterfall to Agile, and they do it without training. They often just reassign a project manager to a scrum master role or take a business analyst and make them a product owner. In some cases, that's fine and works really well. In other cases, it doesn't.

We've seen the opposite take place too. When they're like, ‘Well, we tried Agile and we want to go back to Waterfall. But we have all these people who have these Agile titles, so let's move them back into their previous titles that would align to their previous role.’ Again, it's met with mixed results, you know, and at the end, ultimately, the program leads and leadership have to get behind: ‘Hey, we're going to experiment or we're not. And if we're not going to experiment, how do we get to that predictability so that we can get the end result we're looking for?’

A lot of this comes down to the goals. What are the goals of the transformation project? What does the leadership want to get out of this? And how do they best align the results they want to get to what they're actually seeing in the program?

Tensions in Transformation Prep

Michael Daehne: And I will say, if anyone was going to turn this into an Agile conversation, it would be you, Pedro, so you're allowed to do that.

I think one interesting thing in reading the content y'all put together about planning for and the pre-work you can do on these big projects is this natural tension between keeping planning very high-level like when you say, ‘Oh, keep it high level. We'll get into the details later.’

There's tension between that and the fact that you kind of need to get into some of the details to build a good plan. I'm curious, Liz, do you have any thoughts, lessons, or tips around how you balance those two things when you're still in that kind of pre work phase and maybe examples from your past where you did get down in the weeds are in the details and it paid off down the road because you invested the time up front?

Liz Pryor: I worked on a dashboard project back in the day and knowing how the data was coming in actually ended up changing the scope of the project. So initially, we thought it was going to come in a daily batch file and found out down the road that it was not. Having that very defined, ‘This is how we're getting our data,’ working with the architects directly at the very beginning of the project really helped because when we talked to the more business side of the folks, they did not understand accurately how their data was getting where it needed to be. Jumping on the phone early on with those people really helped.

MD: I think one really resonant thing in your comment there is the idea of, ‘Hey, go talk to the architect, talk to the business.’ That's something we see a lot when we're working on planning discovery-type work with clients. It really matters that you talk to all the right people because I think sometimes there's a risk of saying, ‘We have this one person that's working. They've been working on this plan for a long time. They're working on it, they're figuring out the scope, they're going to get vendors, etc.’ And it's like, ‘Hey, has that person talked to the key business users? Has that person talked to enterprise architecture, data, information security, all these different groups?’

That takes time and it's harder, but that's also why I think there's so much value and opportunity in doing more of the planning and pre-work before you get into the project, because you can make sure you get all the right voices in the room and represented.

Pedro Cortez: You know, there's a balance to be had there, right? And that's always a tough chord to strike. You've got to find where that line is because, in any project, you're fighting the triangle all the time – scope, time, and money. People want to bring new scope because, maybe in the legacy system, they've got all these pain points they would like to eliminate. They want to make themselves and their daily operations easier, right? Make it simpler on themselves, make it faster. Because if they can get more throughput, they can be more productive. And that means opportunities for more widgets, right? So, you try to correlate that back out to sales. But that scope creep tends to end up creating a longer timeline, which, in some places, you just can't do, right?

You've got a finite amount of time to get this in or it's going to cost you more money in resources because your timeline is not going to move. So you need to bring more people in to get more work done in that same period of time. There's always a balance because you would love to create the ultimate customer experience in every business transformation, regardless of what the scope is.

But there's a chord to be struck there with governance and oversight, and I think in every program we've been in, there's some type of governance structure that's in place to say, ‘Yeah, we could add that.’ And other places like, ‘Nope, can't really do that because it costs exorbitantly more to bring in a different tool, change a decision on a previously decided upon tool, or even elongate the time frame. It's just not acceptable so we don't want to take on the additional cost for additional resources.’ There's always a balance to be struck there, and it's hard to find in some places it can go beyond what the original intent was.

Liz and I have a war story where we worked together on this massive M&A program, and part of that transformation was consolidating two billing platforms and two ordering platforms into a single tool. They pre-selected the vendor, they pre-selected the tools they wanted to put in, and they gave a rough estimate of what that cost would look like. When the teams actually came together and had a gap session to look at all the capabilities they wanted to translate into the new world and what was the new future state going to look like, the estimate was almost 2x what the original estimate was, and everybody lost their mind. ‘What do you mean it's going to be two times what the original estimate? We’ve got to cut. We’ve got to cut. We’ve got to cut.’ So, all of a sudden, there was scope being eliminated. There were teams being eliminated from the program, and they were trying to deliver an MVP solution that would meet the current state needs. They're trying to create feature parity.

But ultimately, what they ended up doing was creating a state of bare metal where they could make zero mistakes. They had to completely restructure the way they were working, completely retool who was going to be part of the program, finding cheaper resources, which sometimes delivered parity, but sometimes delivered lower quality, in the end result. So, like I said, there's a fine line to walk there. And sometimes you follow, you fall off the cliff, and other times, it's fine. You can retool and re-forecast and re-budget, but it's hard. That's one of the hardest things in project management and program management - trying to find where does that line exist and how do you walk it?

Advice When Preparing, Defining, & Planning for Transformation

Michael Daehne: Well said. Always natural tension there. I have one more question on this topic. And I’ve got a couple of lightning-round questions for you all. So, the last one on this topic is as you think about the experiences you've had and the reflections you shared in the blog post about preparing for a large transformation. Of all the things we've discussed today, what's the number one thing you would recommend to clients who are preparing to embark on a big transformation project?

Liz Pryor: Be prepared for the unexpected to happen. Know there's going to be something you didn't know. Something will happen that you didn't plan for - the unexpected will occur. What will you do when you face the unexpected? Defining that up front will help you down the road.

Pedro Cortez: Yeah, I would add to what Liz said. It's not just preparing for the unexpected, as you need to budget for it as well. And I don't just mean in financial dollars, right? If you were to look at all your funding upfront and say, ‘Look, you're locked into a budget. Here's what you're trying to do. This is all you can play with.’ It's hard getting to the end result because you're always battling the dollars because if it takes more than 60 days to get the program completed, the market's going to move. Cost of staffing, cost of technology, cost of resourcing. All that's going to go up and you've got to create some type of inflation spin there.

I encourage clients to go think about it in terms of placing bets or investments. I'm going to give you a quarterly investment of this much. Go spend it for the next three months in these areas. These are the focus points in our transformation plan. Creating these roadmaps: where do we want to be in 24 months or 36 months? For the next three months, here are the things we want to be able to do. Let's invest in dollars today for that and keep a pool available to jump into the next quarter, a quarter after that, and a quarter after that.

So I'd say think about this from a budgeting standpoint, not just in today's dollars, but looking over the overall program to get you to the transformation goals you want to reach, invest in it on a quarterly basis, and just keep placing those bets again because you can pivot in three months from now and say, ‘You know what? The market's moved. We no longer want that to be our goal. We have a new goal to reach, so we need to change the way we address our transformation.’ Instead of being locked into a budget, an approach, and a long-term plan, just reinvest that every three months.

Lightning Round Q&A

Michael Daehne: Love that. Great advice. Okay, a couple of lightning round questions. First of all, best book, podcast, or movie you've consumed recently that you would recommend to our listeners?

Pedro Cortez: That's not fair. There have been so many good books I've been reading on product management. I'm a big fan of Melissa Perri's Escaping the Build Trap. I think there are too many organizations that we've had either as clients or we've heard, you know, in consulting powwows with friends of ours who have talked about, ‘Hey, I’ve got to keep my developers busy. I need to keep my testers busy. So I'm just feeding them stories and work, just to keep them maximized on the utilization because they got to be busy.’ I don't agree with that at all. You really should take your resources and help them get into your discovery. Take questions from their lens and help them build a better product, build a better widget. A lot of that philosophy comes from her book.

The Product Kata is also in there. I think it's a great thing to lean into for companies that are going through their transformations. I want to be more product-centric and I think that's absolutely great.

I'm about to finish Amazon's book, Working Backwards. I think it's phenomenal as well. It tells the story of how Amazon has gone through their transformation and become who they are. I think one of the really cool things they talk about is writing their press releases and their FAQS before they ever get into discovery. What do they want this next thing to be? And then work backward. They're really taking the customer experience into account and what the technologies need to be that underlie it - not thinking about the technology that's going to drive their future. They have great stories in there about how Prime came to be and their predecessor to that. Things that they did with Amazon Web Services. It is just a really cool read to foundationally figure out, ‘Huh, this is the way one company went about approaching it.’

And Michael, you know I wasn't going to give you one. I loved Simon Sinek's book, Find Your Why. His first book, Start With Why really set the foundation for the golden circle and how we apply that in our everyday lives. Really trying to drive towards why a company exists and how do the products and services they offer feed that, more than just talking about the bells and whistles that come with it.

Liz Pryor: I'd say Think Again by Adam Grant. I really enjoyed this book. He did a really great job of reframing how to think through problems and how to interpret how other people are presenting problems to you so you can keep a 360 view of what's going on.

Podcast-wise, I would recommend anything Malcolm Gladwell; I’m a big fan of Revisionist History. And another good one that I just started listening to is called Your Undivided Attention. The two hosts are Aza Raskin and Tristan Harris. They take a very human approach to technology. As we are getting more into AI and as you're starting to see more things like smart refrigerators, how do we continue on that path of technology coming into the home without it being creepy? I just think the subject matter is interesting.

MD: Awesome. I'll have to check those out. I do love both Adam Grant and Malcolm Gladwell. I highly recommend Adam Grant's other new book, Hidden Potential. Thank you both for giving us like 85 book and podcast recommendations in the lightning round. That's awesome, no shortage of recommendations.

Okay, something we have not talked about at all, but is true about all three of us is that we're all huge sports fans. I have allegiances a little further south in Texas than the two of you do in the Dallas area, but nonetheless, we all root for Texas teams. So, we're going to end on this one. What's your all-time favorite sports moment?

LP: Corey Seager’s home run during game six of the World Series that sealed it for us this past year.

PC: That was a good one. For me, I have to go back to Texas-USC in the Rose Bowl playing for the national championship. Watching Vince Young break from the middle on a quarterback scramble, hitting the end zone on the right side, for what ended up being the winning touchdown in that game that brought Texas its most recent national championship. That one sticks in my memory as just a great sports moment for me personally.

Closing

Michael Daehne: I think this answers the question, why do I have a podcast? And it's to talk about Vince Young in 2005 and the Rose Bowl. So, I'm glad we could end on that note.

I really appreciate y'all joining and talking about, planning, and preparing for large transformations. For all our listeners, if you want to read more, there's a great series of blog posts out on FlexPointConsulting.com and on our LinkedIn page that Pedro, Liz, and some of our other team members contributed to as well. I really appreciate you listening and thanks for a great discussion.

Pedro Cortez: Thanks, Michael.

Mentioned

Three-part blog series on preparing for business transformation:

Books & Podcasts:

Michael Daehne
Previous

Building a Culture of Change Leadership
Next

Leading with Your Head and Your Heart