IFS Digitalization CollABorative: Aligning Technology with your Business Plans w/ Darlene Schroeder, SVP IT Delivery at IFS
Date of Meeting: 08 May 2025 10:00 AM US Eastern Standard Time
Darlene’s Presentation:
When we talk about a Technology Strategy, it's important to realize different organizations will use different labels—some call it a strategy, others a portfolio, and many refer to it as a roadmap. Personally, I lean towards "Road Mapping" over just "strategy" because it brings the work to life. Strategy can often get stuck in the "what" and miss the "how." Road mapping bridges that gap—it starts to dig into execution, which is where most of the real value gets unlocked.
That said, what you call it might vary depending on your organization’s culture or where you are in your growth cycle. A new company building from scratch will have very different needs than a mature one looking to modernize or refresh. Similarly, if you're going through M&A, the strategy's focus shifts again because now you’re inheriting technology, not just choosing it.
When I think about a strategy framework, I often use four main pillars. In some cases, especially in more complex environments, I break each one into sub-pillars—maybe three per pillar—because that added granularity helps you focus where it matters. Again, the depth depends on where your organization is and what you're trying to achieve.
But before you even start building out a roadmap or strategy, you need to ask the big "why." What’s the point of this strategy? What outcome are we hoping to see? Sometimes that means setting a 12-month roadmap because the organization can’t see beyond that yet. In other cases, it might be a more mature setup aiming for a three- to five-year horizon. Though, honestly, in today’s world—with how fast technology evolves, especially with things like AI—a five-year plan can feel like a stretch. Most of us weren’t even seriously talking about AI three years ago, and now it’s everywhere.
So, you ground the strategy in a clear objective. I’ve listed a bunch before, but efficiency tends to always be near the top. How can we automate, streamline, reduce manual effort? It’s rare to see a strategy where efficiency isn't a priority.
Now, when you begin shaping your roadmap, the first place to start is understanding the business strategy. Easier said than done, right? Sometimes it’s fuzzy or incomplete. But even if you only know 80% of it, that’s enough to start aligning. That’s when it becomes crucial to engage with your peers—talk to HR, marketing, manufacturing—find out what their top priorities are. That context shapes what IT needs to support.
Then, look at your IT cost base. You’ve got two big buckets: non-discretionary spend (just keeping the lights on—maintenance, basic security, legacy support) and discretionary spend (where you can invest and innovate). The more your budget is tied up in non-discretionary, the less room you have to move forward. So, I always start by digging into that non-discretionary piece and looking for ways to bring it down.
If you can shift even 10–20% of that into the discretionary bucket, that’s transformational. That’s money you can now spend on things that push the business forward, not just keep it afloat. That’s how you move from being reactive and tactical to being proactive and strategic.
You start by fixing the basics. Tech debt is one part, but process debt is huge too. Think of all the old governance frameworks, PMO structures, ITIL layers—we put them in place ages ago and often forget why. They grow over time, and suddenly you’ve got a bloated operating model that's slowing everything down.
Then comes architecture. We need to move towards service-based, modular, integration-friendly environments. That gives you agility—so when new technologies come along, you can plug them in without blowing the whole thing up.
Another big one is maximizing the value of evergreen SaaS platforms. If you’ve moved to cloud, great—but are you really leveraging the continuous updates and best practices they offer? Or are you still customizing them so much that you’re stuck supporting a pseudo-on-prem version in the cloud? The leaner and more standardized your use of SaaS is, the more value—and the more flexibility—you get.
That’s where the strategy gets exciting. When you can show that by reducing tech and process debt, and leveraging modern architecture and SaaS, you’ve created space to invest—that’s when the business starts to listen. They’re no longer hearing, “We need more money to maintain the old,” but “We’ve freed up resources to drive something new.”
And look, I’ve worked across all kinds of setups. In private equity-backed businesses, the playbook is aggressive—cut costs fast, maximize efficiency. In others, it’s about slowly transitioning from legacy to new while minimizing disruption. There's no one-size-fits-all. The right strategy depends entirely on where your organization is and what it's trying to become.
One thing I’m passionate about—and I think it makes a huge difference—is getting everyone to see IT as just another function of the business. Not “IT and the business,” but “IT as part of the business.” The way you think about strategy shifts when you make that mindset change. IT has a strategy just like marketing does, just like finance does. And how we build that strategy and deliver it alongside our peers is critical.
Let’s go a little deeper here. I talked earlier about understanding what layer of the strategy you need to operate at. That starts with the business. Do we actually have one single, unified business strategy? Or do we have multiple? In many cases—especially with M&A or a company with a diverse product portfolio—you’ll find sub-strategies driving different parts of the business. That translates into different processes, and it means IT has to be able to service all of them. So we have to be flexible about how deep we go to align properly.
I also want to touch on governance and management. People tend to dislike governance—it’s often seen as red tape. But it's essential. The trick is making it valuable and lean. Every time my team proposes a new governance step, my first question is: What value does it bring? To us? To the business? Because in my experience, organizations keep layering process on top of process, adding Band-Aids without stepping back to reimagine how it could be done better. That’s where transformation happens.
Then there’s organizational structure and skills. These changes depending on where you are in your company’s lifecycle. Do you want a small, in-house team of highly skilled experts? That might work if your architecture is lean and modular. Or do you want a core group of strategic thinkers who partner with external providers to do the day-to-day execution? It’s important to define what kind of IT organization you want to be. A lot of smaller companies keep things in-house until they outgrow that model—and sometimes don’t realize it until the pain hits.
We’ve already talked about architecture, but to recap: your tech stack needs to be lean and modular. That’s how you stay agile and get the most out of your technology investments.
Now, how do you actually build the roadmap? The biggest thing I’ll say here is: keep it short and sharp. It will never be perfect. You can very easily end up in analysis paralysis—spending too much time debating detail instead of getting started.
At IFS, since I joined, we’ve built roadmaps across the tech estate, and each item on the roadmap gets a one-pager. It needs to answer a few questions: Why are we doing it? What outcome are we expecting? And what’s the value hypothesis for the organization? That’s what helps us prioritize—because let’s be honest, there’s always more on the list than we can deliver. That’s not a bad thing. It just means we need to focus.
Mobilization is key—define your scope, know what you’re trying to achieve, identify the stakeholders you need to engage with, and plan your workshops accordingly. Make sure you understand the business strategy and your IT landscape. And when I say understand the landscape, I mean really understand it. If I stopped here and asked how many people could accurately draw their current-state architecture, more than half wouldn’t be able to. That’s normal, but it’s not where you want to be when you’re building a forward-looking strategy.
You’ve got to be honest about your processes, too. Face the mirror and admit what’s not working. This isn’t a reflection on individuals—it’s just recognizing where you are as an organization. Personally, I always assume the process is broken until proven otherwise. That mindset keeps us honest and focused on improvement.
Also, know your budget. You will never be able to do everything, so you’ve got to prioritize—ruthlessly. And understand your business pain points. What’s causing friction out there? That should drive where your attention goes.
One final point: when you understand your current-state architecture, be brave enough to speak up. Sometimes the business will say, “Can you just give me this feature?” And you’ll have to come back and say, “Only if we upgrade these five systems, build an integration layer, and then we’re looking at a 2027 delivery.” That’s not what they want to hear, but it’s the truth—and it sets realistic expectations. If you’re not honest, you’ll end up with an unrealistic roadmap that will only create frustration down the line.
And lastly—maybe most importantly—once you’ve built that roadmap, keep it alive. Review it monthly as a team, quarterly with your business partners. Don’t let it become one of those dusty documents that gets filed away and forgotten. It should be a living, breathing part of how you run the business.
Discussion between Tom, Darlene and Nick
[Tom]: And I think that’s a good question too, Darlene. It’s something that gets people thinking. Some might have a clear roadmap already, some might not—but it’s a valid conversation either way. Maybe I’m a bit naive in this area—my background is in technology, but not specifically in IT infrastructure or architecture. So, I’m curious: what do people typically use to produce their roadmaps? I’ve seen them done in PowerPoint, Excel, Word… but is that the right approach? Is there even a right or wrong way to do it? What’s your opinion on that, Darlene?
[Darlene]: I'll be brutally honest—I still use Excel a lot. We do use a portfolio management tool now, but it’s a simple add-on. And honestly, all of our roadmaps that we share monthly and quarterly are still in PowerPoint. You can overthink this. I’ve been through the whole “let’s find the perfect tool” process, and in my experience, it either handles programme-level road mapping but not project management—or vice versa. So, my advice is: keep it really simple. If you get really, good at it—just like with project management—then maybe look at a tool. But the tool isn’t the issue, and it shouldn’t be the focus.
[Tom]: That’s probably a maximum you could apply across all of business—but let’s not open that debate today. So, over to the team, over to the audience: what do you have in place for your roadmap? Do you feel like you’ve got a solid handle on it? Is it something you’d like to improve or approach differently? What are your thoughts?
[Nick]: From my perspective, I’m still building mine out. I’ve only been in this role for about two and a half months, so I’m right in the thick of it. It’s a smaller business, and a smaller IT group than I’m used to. So, I’m trying to build from the ground up—because honestly, it’s not quite where it needs to be yet. Right now, there’s a lot of tactical focus, just trying to lay those foundational blocks.
In fact, I’ve got a board meeting in about 15 minutes to walk through some of this. But for me, it’s about getting that first hurdle out of the way before I can even think about the next eight or nine. I’ve got ideas and plans, but a lot hinges on whether we can make some fundamental changes—like broadening the capabilities of the team, maybe by engaging with an MSP. Simple things like that could really make a difference.
Right now, we’ve got a small team, which means a limited skill set—and that obviously comes with constraints on how far we can go unless we scale that. It’s an interesting spot to be in. And when it comes to tools, just to echo what was said earlier—I’m a visual person. I like being able to show and explain things clearly, especially to people at different levels across the business. So, for me, PowerPoint is great for that. It just works.
[Darlene]: It really does the job, doesn’t it? Exactly. And I think what you said is spot on — that transition from being tactical and reactive to becoming proactive and strategic is a real tipping point. And it's not easy. It’s something a lot of organizations really struggle with.
So I do feel for you — it’s a tough shift to make. But once you push through that initial battle, it does get better. It just takes time and persistence.
Maybe this is a good point to segue into the last bit I was going to share — our experience at IFS from the perspective of being a customer ourselves.
[Tom]: What is our organization's data strategy going forward, and why have we selected this approach?
[Darlene]: Reflecting on our past challenges, we recognize that we haven't always ensured data resides in the system of record or master system. Our strategy now focuses on using data from these core systems whenever possible. Only if necessary, we move data to a Data Lake or another platform for specific purposes.
Currently, our goal is to consolidate data back into core platforms like IFS Cloud, though it could be another platform we use. We aim to maximize data processing within these master systems, rather than outside them. This is our refined strategy moving forward.
[Tom]: That's really interesting and good to know. This approach is likely common among many of our customers and other organizations.
Are there any thoughts from the team or audience about this approach? Specifically, how are you planning to implement it, and how does it tie into your IFS Cloud or other IFS solutions?
[Nick]: Adding to Darling's point, using data directly from the system of record is indeed the right approach. While there are valid reasons for pulling and blending data into a master data warehouse or lake, it's preferable to pull data directly from the system of record whenever possible, provided it doesn't impact performance.
[Tom]: I'd like to open up the discussion to the wider audience, not just specifically around IFS applications but overall. We have Darlene here, who is incredibly experienced, and it's a great opportunity to pick her brains on a few things.
One key topic is integration, which is top of mind for us as an organization, especially after recent M&As. We've heard from the teams at Poka and Copperleaf, both offering interesting solutions. As we blend these organizations in, we face two main integration challenges: integrating their data, IT infrastructure, and strategy, as well as their physical data.
What ideas or options are there for doing this strategically without disrupting either business? This must be a significant challenge.
[Darlene]: Integrating acquisitions is indeed a real challenge and largely depends on your approach to M&A. I've seen M&As where there is a detailed plan from day one, outlining integration steps for the first 100 days. This approach is very structured and regimented, ensuring full integration within a set timeframe.
On the other hand, some organizations keep acquisitions at arm's length. One non-negotiable aspect, in my experience, is adhering to security standards. When an acquisition occurs, the acquiring organization becomes accountable for the new entity's security compliance.
Another aspect of integration is identifying value levers. Instead of a wholesale integration, we often assess where the acquisition excels and determine if it would be more cost-effective to leave them as best-of-breed in certain areas. This means integrating them enough to utilize IFS where required but allowing them to operate independently where they perform well.
Does that make sense? It's a tricky question because I've seen organizations with both fluid and rigid approaches. Understanding which approach you're taking is crucial for defining your strategy.
I know this isn't a straightforward answer, but it reflects the complexity of the issue. It's really interesting to see how different organizations handle this challenge.
[Tom]: Even if an organization isn't undergoing M&A, there will still be instances where new data sources or departments are introduced. It's essential to determine how to integrate these into the overall strategy.
Should these new elements run separately for a period, or should they be integrated immediately to maximize the benefits of their data and efficiencies? This is indeed a challenging decision to make.
I'd love to hear your thoughts on this approach and any strategies you might consider for effectively integrating new data sources or departments into the existing framework.
[Darlene]: Yes, it's a fascinating area. When discussing data strategy, it's crucial to define what we mean by "data." People often speak about data in broad terms, but it's essential to identify the specific data points that are truly valuable. Focusing on these key data points can help maximize their benefits.
[Tom]: A good approach to strategy involves prioritizing what's important to your business and maximizing the value from your teams and organization. It's like providing an internal service to the rest of the business. Ensuring that your staff and teams deliver in the best possible way is crucial.
There's a lot to prioritize and consider. Strategy isn't just about combining applications to make them work; it's much broader. We also need to consider risk, security, and governance, which are significant factors in IT strategy. This is especially true for our organization and our customers at IFS.
[Darlene]: Absolutely. As we build our strategy, security should be integral to every aspect of the roadmap. It's not a standalone element but a fundamental part of the entire strategy. Security by design should be a core principle in every strategy, ensuring that it is always at the forefront of our planning and execution.
Darlene’s Continues her Presentation:
So firstly, we run IFS — and we run it using IFS. Our IT strategy is very much “IFS runs IFS,” wherever that makes sense. Of course, that also brings its own challenges. For example, we’re not in one of our core industries, so staying evergreen can be harder. We haven’t always got that right in the past, but we’re actively in the middle of a program to bring ourselves back to evergreen.
As a customer, we’ve made a deliberate decision to use IFS Consulting Services. We engage with them just like any other customer would — contracts, deliverables, the whole lot. We also work with partners when the IFS team doesn’t have the specific skills we need. On top of that, we use support services, including Unified Support. If there’s a problem with our platform, we raise tickets, follow the same escalation paths — just like you would.
That said, where we do have an advantage is in our access — we can give feedback more quickly because we know the people. We don’t always have to go through the process. We use that access to share challenges — good or bad — and we’re hoping that by doing so, we contribute to improving the overall support model for everyone.
When we say “IFS runs IFS,” we mean it — not just the technology, but the operations too. We have an internal IFS Cloud support team, both onshore and offshore. But as part of the broader program, I’ve come in to lead, I’ve been asking: why aren’t we leveraging more of our own services?
So now we are. We’ve started working with Customer Success with a really clear focus: reviewing whether we’ve designed and built the best landscape, understanding our customizations, and figuring out how to bring them back to evergreen. We’re working with them through 2025 and 2026 on those focus areas.
We're also exploring new services — things like Build Services and Build Place. These manage your estate in a kind of MSP model. So we’re asking ourselves: if that’s part of the service we offer our customers, why are we trying to manage all of that ourselves in-house?
To be clear, it hasn’t always been perfect. We haven’t always done this brilliantly. But we’re improving. We’re going through all the upgrades — currently preparing for the 25R1 release. And for the first time, we’re also taking on new capabilities as part of that release. It’s always been a technical upgrade before. But now I’ve asked the team to be brave — to implement new capabilities and deliver real value to the business at the same time.
So yes — IFS runs IFS. But we’re also focused on how we continue to mature, and how we get the most out of our platform, just like every one of our customers.
Questions / Answers:
Q: Given the rapid pace of technological change, you mentioned the importance of selecting the right solutions and integrating them into the overall architecture. There is an ongoing debate between adopting a best-of-breed approach versus a single solution to address organizational needs. Considering the wide array of choices available today, what are your thoughts on the best approach, Darlene? Is there a definitive answer, or does it depend on specific circumstances? Additionally, could you touch on how this aligns with a cohesive strategy and perhaps share the approach that IFS has taken?
A: Absolutely, we should be looking to leverage complementary technologies as organizations. Even in today's world, integrated platforms offer unbeatable data flow. When you start knitting many systems together, maintaining aligned data becomes challenging. Good data is crucial, especially for advancing AI initiatives.
There are niche areas where specialized software can be highly beneficial. For example, at IFS, we've been exploring innovative software to complement our back-office platforms. One such area is legal support, where technology can help sift through hundreds of contracts and identify common themes and challenges quickly. This demonstrates the value of hybrid approaches, combining integrated platforms with niche solutions.
Q: Jim, you mentioned that data management is a challenge for every IT organization, including yours. How are you overcoming this challenge? Do you have a master data management strategy, or are you sourcing all data through a data lake? What is your overall approach to managing multiple sources of data?
A: We manage data through integrations whenever possible. If integrations aren't feasible, we use a data warehouse to aggregate data through our BI service.
Q: That's great to know. I think every IFS customer and business around the world faces similar challenges. Whether you're dealing with a mix of solutions or an older, antiquated system that did many things for you, streamlining can be complex. As organizations grow, they often adopt best-of-breed solutions within departments and then realize the need for a strategy to integrate them. This can be quite challenging. Darlene, you briefly mentioned M&A earlier. With any acquisition or merger, you're essentially doubling your potential integration issues. How do you manage pulling everything together in such scenarios?
A: Absolutely. As part of my role at IFS, I deal with platform integration daily, and it's a significant challenge. We aim for speed in integration, but best-of-breed solutions in incoming organizations make it complex. The real challenge often lies with the people aspect, not just the technology. Getting buy-in from the business is crucial. Balancing the value of single platforms with the ease of acquiring new technology today is part of the challenge.
Next CollABoratives:
- 20 May 2025 10:00 AM US EST / 15:00 BST / 16:00 CEST
IFS Service CollABorative: Meet the Member - 28 May 2025 10:00 AM US EST / 15:00 BST / 16:00 CEST
IFS Assets CollABorative: Think Tank - Incorporating ESG in Capital Planning Decisions
If you are an IFS Customer and you would like to join the CollABoratives, please click here to fill out the form.