Hi Reader,

I hope this email finds you well! A quick update before this week’s excerpt.

I shared in an earlier email that the manuscript had gone through a developmental assessment. I’ve been working through that feedback over the past few weeks, and it has been a productive process. A few chapters needed restructuring, a few sections needed to be made more concise, and a handful of gaps needed to be filled with content that was missing but clearly belonged in the book. This week’s excerpt is from one of those sections. The assessment flagged Chapter 10 as strong in concept but in need of more tactical depth for the executive sponsor audience — specifically around the topic of custom code. I took that feedback seriously and did a significant rewrite. What you are reading below is the result.

Custom code is probably the highest-risk activity on any digital transformation project. That doesn’t mean you shouldn’t do it — it’s necessary on the majority of the projects I’ve worked on. But I have seen custom code be the primary factor that drives these projects into the ditch more times than I can count. The frustrating part is that most of it was avoidable. The decision to write custom code is one of the most consequential decisions an executive sponsor can make, and it’s almost always delegated to people who have every incentive to say “yes” and very little accountability for the long-term consequences. That is why I want every executive sponsor reading this book to be equipped to ask the hard questions before that decision is made.

I’d love to know if you think this section hits the mark.

Excerpt from The Digital Transformation Guidebook

Chapter 10: Navigating Your Route — Creating Your Future

Questions You Should Ask Before Writing Custom Code

Whether you are contemplating writing custom software or customizing an off-the-shelf system, there are a few questions you should ask before you start writing the code.

Have You Fully Explored Your Configuration Options?

The first question you should ask is whether your team has truly exhausted what the system can already do through configuration alone. You would be surprised how many times I have been brought into an implementation and found custom code providing the same functionality that already exists in the system.

Many modern platforms are far more configurable than the systems of the past. If your team hasn’t worked through every configuration option available, that is where to start — not with a development estimate.

Do We Really Need the Proposed Capability?

If the system truly doesn’t support the desired functionality, the next question you should ask is whether you really need to do this. I find the best way to answer that question is to ask four clarifying questions.

First: “Do we really need to perform that process or task?” Second: “Can we do it in a way that is supported by the platform?” In my experience, companies often perform their processes in a specific way mostly because that is the way they have always done it. If the answer to either of those questions is “no,” the custom code can’t be justified.

If your team is convinced the process must be performed and must be done in the way being proposed, ask two follow-up questions: “What will happen if we don’t write the custom code?” and “Will that custom code generate enough revenue or save enough money to justify spending two to four times the current estimate?” If the answer to the first doesn’t have a significant business impact, the true answer to either of the first two questions probably should have been “no.”

Is This Capability Already on the Vendor’s Roadmap?

One question that can save a significant amount of money is simply asking the vendor whether what you need is already planned for a future release. Many vendors have a published roadmap you can consult. I have seen organizations fund custom development for functionality the vendor was months away from releasing as a standard feature. That is an expensive mistake a single conversation could have prevented.

If the vendor does not publish a feature roadmap, ask them directly, and get the answer in writing.

Is There an Existing Add-On That Already Does This?

If you get to this point in the decision process, you still have one more option before writing custom code. The next question to ask is whether someone has already solved this problem. Most major platforms have active partner ecosystems with pre-built extensions developed specifically for that environment. In my experience, this search doesn’t happen as often as it should.

A third-party add-on is almost always preferable to custom development, even when it doesn’t meet every requirement exactly. The cost difference is rarely close, and the risk difference is even wider. Make sure your team has researched that option before you authorize development.

Can You Justify the Risk and Cost of Custom Code?

Once you have eliminated the options above, the next question you should ask is whether you can justify the risk and cost of the custom code being proposed. Writing custom code is expensive and risky. You need to have a compelling business case to justify it.

Answering that question isn’t always easy. First you will need to have an estimate for the custom code, and before you can have an estimate there must be a proposed design for the solution. That proposed design should be attached directly to one or more proposed “to-be” process designs.

Is This a Permanent Business Need or a Transitional One?

You should also ask whether the need driving the custom code is permanent or temporary. The total cost of ownership for short-term, custom solutions is often much less than permanent solutions because your maintenance lifecycle is shorter or non-existent.

Be careful with temporary solutions, however. Make sure there is a concrete timeline and plan for taking the temporary solution out of service. I have seen custom code written specifically to bridge a gap during migration — handling a legacy data format, for example — that quietly became a permanent fixture because nobody went back to remove it after go-live. If the need is transitional, the cost and risk calculation is very different than for a permanent process requirement. Be clear about which one you are actually solving.

Who Will Write the Code?

Once you have decided to move forward with custom code, another question you should ask is who will write it. If you don’t have a software development team, you are going to be dependent on a vendor. If you do have a software development team, do they have experience with the type of development necessary? Many systems have their own code language, each of which comes with nuances that are costly to learn.

Who Will Support the Code?

Directly on the heels of the previous question, you should ask who will support the custom code. Support not only means answering user questions when something goes wrong, but also fixing bugs when — not if — they are found, and modifying the code to stay current with the systems with which it is integrating or in which it is running.

Off-the-shelf systems are constantly changing. When they do, there is a probability those changes will impact the code that was written as part of your project. Who will be responsible for making sure your custom code continues to work and provide the appropriate capabilities?

Will This Code Survive the Vendor’s Upgrade Cycle?

Related to the support question, you need to ask whether this code will survive the next upgrade — and the one after that. This is the most underestimated long-term risk in any customization decision, and in my experience it rarely gets the attention it deserves.

Ask your technical team directly: are we building inside the vendor’s supported extension model? Code written within the vendor’s supported extensibility framework behaves very differently over time than code written outside of it. Code built on the vendor’s supported extension points has a reasonable chance of surviving those upgrades. Code that modifies core application logic almost certainly will not — not without rework, and not without cost. Know which one you are authorizing.

Do We Have a Test Plan Specifically for This Code?

You should make sure your team has a dedicated test plan for the custom code itself — not just for the functional testing it will eventually participate in. As soon as you add new code into the mix you need to test the code itself prior to testing its ability to meet your business requirements. That means unit testing, integration testing, and a plan for regression testing each time the underlying system updates.

If your team doesn’t have a documented plan before development starts, you are not ready to start.

What Is Our Rollback Plan if This Fails at Go-Live?

One question almost nobody asks before authorizing custom code is what happens if it fails in production. If a customization breaks at go-live, what is the recovery path? Can the business operate without it temporarily? Is there a manual workaround that buys time to fix it?

The absence of a rollback plan is not a manageable risk. It is an unmanaged one. Make sure you have the answer before you need it.

What Will This Actually Cost Over Five Years?

The last question you should ask is what this customization will really cost — not just to build, but to own. The initial development estimate is the smallest number in the true calculation. A realistic view includes the initial build, testing across all cycles, deployment, post-go-live bug fixes, upgrade compatibility rework, and the ongoing cost to manage and maintain it over time.

In my experience, the five-year number is often four to six times the initial estimate. Make sure the decision to proceed is based on what this will actually cost, not just what the first invoice will say.

This list of questions is something I work through with clients every time custom code comes up. The goal isn’t to talk anyone out of it — sometimes custom code is absolutely the right answer. The goal is to make sure the decision is made with eyes open, and that you as the executive sponsor are driving that conversation rather than being handed a foregone conclusion.

I’d love to hear your reaction, especially if you’ve been in a situation where custom code became a problem on a project. Please hit reply and share the story. These are exactly the kinds of real-world examples that make the book better for everyone.

I hope you found this email useful. If you would like to talk to me, you can use the button below to schedule a time on my calendar.

​
Kind regards,

Tory Bjorklund