As a software company CEO or management team, deciding to embark upon a software modernization project is a big moment. You need to get your board’s approval and buy-in. But you’re not just “selling” the board on a single project.
You might need the board to agree to infuse additional investment into the company. You should manage expectations with the board around timelines and project milestones. Ultimately, you need the board to buy into your strategic vision for how this software modernization effort will drive growth and ROI for the company.
Want to have a successful board meeting and get approval for your software modernization project? It helps to think like an investor. Keep in mind that your board is fundamentally focused on two questions:
- How much risk does this software modernization project involve? The board is likely to have concerns about the project’s possible impacts on your current revenue base, or the possibility of not meeting financial targets. Sometimes boards will decide to approve a software modernization project because they feel that doing nothing is a higher risk.
- If we agree to this software modernization project, what’s our ROI? What’s the business case for new revenue opportunities from the project? What new features, products, or customer experiences can be created, and how soon can they drive revenue?
With that “investor lens” in mind, let’s take a further look at how to have a productive conversation with your board when seeking approval for software modernization projects – and how to use these conversations to drive innovation and growth at your software company.
Not All Software Modernization Projects Are Created Equal
First, start by clarifying in your mind – and with your technology team – exactly what kind of software modernization project you want to do. There’s a wide range of projects that can be described as “modernization,” but they’re not all at the same level of complexity, cost, or risk.
Think of software modernization as a continuum. There are lots of types of upgrades, tweaks, and fixes that you can do with a piece of commercial software once it’s launched and established in the marketplace and has been successful.
Let’s list the “modernization” continuum in order from least to most complex (and potentially costly):
- Maintenance, bug fixes, small enhancements, and customer requests. This is an everyday form of modernization that’s been going on for as long as there’s been software. All software needs updates or newer versions a few times per year.
- Adding new components, major new features, or new modules. Let’s say you were building an Enterprise Resource Planning (ERP) system, for example, and inventory management is a new module you want to add to an existing solution.
- Adding more advanced capabilities. This could include launching a new cloud-based version of the software or offering support for additional languages, like Spanish, German, or Japanese.
- Full rewrite. This is the classic, multi-year, Big Bang, next-gen project.
Remember: your board is looking at any software modernization effort through an investor lens. Every level of development outlined in the list above represents different levels of investment. That investment can be justified in the following ways:
- Maintenance is a baseline; needed to keep the lights on and keep customers happy.
- New features are created to drive new revenue.
- New modules are often necessary to keep up with the competition and avoid customer attrition.
- Launching a new product in the cloud or adding new language support – even more advanced modernization projects don’t always require a full rewrite; you can often deliver value with some new packaging, tweaking, and massaging of your existing code and technology stack, to refinance your technical debt.
Every step of this continuum (Maintenance → Feature Developments → Major Updates → Cloud Deployment/Full Rewrite) requires increasing levels of investment and increasing levels of risk. You have to look at the potential risks and rewards of the project in its totality.
At the extreme of the modernization continuum is a full rewrite of the software. If you go to the board and ask them to approve a full rewrite, they’re going to ask, “Do we really need to redo the whole thing?” Remember, the board controls the purse strings. For a full rewrite of a flagship product of a software publisher making millions of dollars a year, you could expect tens of millions of dollars of investment and multiyear commitments.
So put the investor lens on and do that risk and return calculation. This is a thought exercise any CEO or CTO can do to help understand how your board is going to look at your software modernization project proposal:
- What is the risk of doing nothing vs. the risk of doing the modernization effort?
- What is the return of actually doing this?
- What are the outcomes of the different options?
Remember that modernization has to be ongoing. You’re in the product space! Customers have effectively leased a product from you, they’re paying you through some financial model to keep the product running and keep making it better. Want long-term relationships with customers? You have to keep delivering more value to the customers. The needs never stop. The customers are never going to be perfectly satisfied forever, and say, “OK we’re happy now! We’re all good for the next 5-10 years!” Some leaders in our industry are now saying, “Plan on rewriting everything every 3 years.”
As a software company CEO, when you go present to the board, don’t just sell a project; sell a strategy. It’s up to the CEO to help the board understand the relative risk and return of the strategy. How much money will you need over the next 18-24 months? Don’t just think about it in terms of, “My team says we need a full rewrite and it’s going to take 3 years and $4 million.” Based on the track record of other modernization projects, you might need to double or triple that amount.
Two Crucial Questions to Help Your Board Sleep At Night
Put yourself in the boards’ shoes and ask yourself a question: What would help me sleep well at night?
Board members ask themselves two questions about your company:
- Are we in a good place?
- Are we on the right path?
As a board member, as long as you can say “Yes” to one of those questions, generally, you can sleep at night. When engaging with the board, with every contact, every ask, and every message, you need to be able to tell them the truth: “Are you in a good place,” and “Are you on the right path.” If the answer to either question is “No” then you need a strategy.
If you’re not in a good place, but on the right path? The board will want to know what does the path look like, and what’s the plan? How many months will it take, and how much money do you need to get to a good place? Board members sleep well when they have confidence in the product, leadership, and strategy, and they feel like they’re on the right path.
To sell any modernization effort, whether it’s a few new features or a full rewrite, you need to pitch the board on the gap between where you are and where you need to be. You need to do this not just at one point in time or at the start and end of a process, but continuously.
Charting a Long-term Roadmap for Software Modernization
Look 5 years out. You might have a modernization roadmap with enough visibility for 18-24 months; that’s fine! But that roadmap is going to be pointing to a certain point in the sky: and you need to be able to show the board, “That’s the vector, that’s where we’re heading. After the first 18-24 months, we’ll have to make adjustments, but that’s where we’re headed.”
Do you know what your 5 and 10-year targets are? Being able to express those longer-term targets, along with a realistic product modernization roadmap, is how you connect with the board and get them to say “Yes.”
You meet with the board once a quarter. What you don’t want is for the board to agree to a multi-year “next-gen” rewrite project without a plan. As you start to work on the project, without fail, the date and financial requirements slip. Often drastically. You need to be able to explain to the board how you are going to invest in this modernization effort without putting your current customer base and revenue stream at risk.
How are you going to calibrate that? Because that’s another challenge of modernization projects: you have to keep your current customers happy during the next couple of years that it takes you to modernize. You have to change the tire on the moving car; you can’t just say “We’re going to shut it all down.”
Make sure you tell the complete story to the board, or you might get shot down when you go to make your pitch.
How to Choose a Software Modernization Partner – “Brains Over Bodies”
Many CEOs find that they need a partner for their software modernization project. But choosing a partner is not just about throwing more bodies at the problem. It’s about “How can I deliver this modernization value for this modernization program most efficiently?”
At most software companies, 80% of their software R&D budget is going to baseline maintenance – keeping the lights on, keeping customers happy, and keeping sales flowing. 90% of your software R&D costs are pure labor costs. So that leaves only 20% of your internal resources free for this modernization effort. It’s difficult to do serious heavy-lift modernization with only 20% of your resource base available.
Now the software company CEO needs to choose:
- Staff up (additional hires) or
- Bring on a partner for additional resources.
Does your modernization project involve a major upgrade, heavy new features like adding a new mobile experience or new API on top of an existing product, or all three of these together? Maybe you’re going for cloud enablement, or shifting over to a SaaS model from on-prem and traditional license revenue base? These are all major modernization tasks.
Often in the software world when faced with these larger challenges, these are larger amounts of technical work, and they’re higher risk. You usually have a shortage of resources. Remember, 80% of your internal resources are doing maintenance, so only 20% of your internal resources are available. You’ll often find that you have a shortage of sheer horsepower, just not enough bodies at keyboards. You may also find you don’t have the right talent, you don’t have the experienced software architects or heavy-lift engineers that you might need to get the job done.
The other thing to understand: labor isn’t the only lever that you should be able to play with. 95% of Software R&D is labor cost and people have been trying to reduce labor costs in software development for years. That’s where the offshore model came from. Nowadays, you can get cheap engineers. They might be 12 time zones away, but they’re cheap.
But here’s something that many people in our industry don’t understand: even if you get “cheap” labor, 95% of your cost is still labor. It’s not just about the cost of labor, it’s about figuring out the right way to do it. The right question to ask is: “How can I modernize with less labor, with efficient use of the labor that I do have – whether it’s your own people or people from a partner?” The idea is to use less labor to get the job done.
Put yourself in the mindset of the “brains over bodies” approach. You’ll get better results. Using less labor for your modernization project will reduce your financial risk, reduce the strain on your organization from having to onboard a larger team, and it will reduce delivery risk.
Want Buy-In from the Board? Show Them a Roadmap.
Build the business case, then get a roadmap to success in two weeks or less. See how our Product Roadmap Workshop will get your team in alignment.