Dale Edman

I’m sure many of us have seen Simon Sinek’s Ted Talk “Start with the Why.”

In the talk, he introduces the golden circle, which consists of what, how, and why.  Sinek suggested that every company knows what they do; some can even articulate how they do it, but few get to Why they do it.

Companies looking to replace their ecommerce system often know what they are doing: replacing their ecommerce system. Some even get to the how, deciding on technologies and partners. But from my experience, few understand why they are replacing their platform. The re-platforming project will be complicated and expensive, and you will need a ‘Why’ to align everyone in the company.

Here are some of the whys that I have heard over the years:

• Legacy systems that are no longer supported.
• Security concerns.
• Increasing total cost of ownership.
• Looking for modern functionality.
• Board/CEO/CIO/CMO — want something new and shiny.

There are other reasons why, so make sure you understand yours. Often, it will have multiple layers. For example, who doesn’t want modern functionality? However, you need to ask yourself what you think you are getting.

Is it enough for the investment? Technical debt and legacy systems can force your hand, but your Why must be bigger than “we have to do it” to get you through the difficulty of the project.

One last word of caution: while having your C-suite on board might be enough, wanting something new or shiny is not enough to sustain your project over the long run.  Your Why is likely to be multi-faceted, and the better you can get to the bottom of it and get transparent with all stakeholders, the more you will set yourself up for success.

Setting Requirements

To accomplish your Why, you must decide on what you are building and establish requirements.  Requirements are an iterative process, starting with high-level requirements often defined by your Why.

For example, I have been a part of many projects that required analytics. “Enable Google Analytics” would be recorded as a project requirement. That is a high-level requirement from the Why, but you will need to define what types of data you need, what you want your dashboards to look like, and whether you have internal resources to build them. There are a couple of other watch-outs when defining requirements; over- and under-engineering.

Once you start to understand your requirements, it is important to consider prioritization. One question that an architect on one of my projects used to ask was, “If this was the only thing not ready, would you still go live?” You will eventually have to make those decisions, so understanding what is necessary versus nice will make the project smoother.

Over-Engineering

As you define your requirements, you may over-engineer the problem. Industry trends, such as “composable or headless commerce,” can cause additional work and overhead.

I worked on a re-platforming project to implement headless commerce.  We needed a high-level strategic resource to design the system, then an architect for the front-end work, an architect for the commerce work, and two or three developers for both the front- and back-end work. Requiring a headless commerce system added overhead to the project. You may have an excellent Why for using more complicated architecture, but make sure you know what you are gaining and what it will cost you.

Another common reason for over-engineering is to future-proof your platform by ensuring you get every requirement in the first build. Not understanding or prioritizing your requirements can lead to everything being important and nothing being important. It also could prevent you from seeing times when an “out-of-the-box” solution could have been adopted with a few tweaks to the requirements, saving costly customization. Remember, you don’t just build these systems; they must be maintained and expanded to meet your consumers’ needs.

Under-Engineering

Under-engineering can also be problematic; phrases like “Lift and Shift” or “Out of the Box” are often used to simplify requirements. With “lift and shift,” you focus on moving the existing site’s functionality into the new technology platform. It may seem the easiest way to avoid scope creep and constrain the project. But it doesn’t work because not every requirement can be ported over.

Most legacy systems were engineered over a decade ago, and there is a reason you are considering a re-platform. At the same time, you may have built those into your legacy system, but the new system tends to handle them differently. Another common mistake is using the “Out of the Box” functionality. You should select a modern ecommerce platform because they have already figured out many of the challenges you are dealing with.

Technology Platform and Partners

You have your team identified; they are clear about the Why and have started the hard work of defining the requirements. The question is, have you already decided on a technology platform? It is tempting to lean heavily on the IT department to make this decision. They will, after all, be responsible for maintaining it, so shouldn’t they have the final say? Since a re-platforming involves more than IT, it should be more than their decision. Your chosen platform has business, merchant, and marketing implications, so you must ensure everyone is comfortable with the decision.

Some things to consider as you look at different platforms:

1. Are you B2C or B2B? Do you need to support other marketplace channels?
2. How do your requirements line up with the functionality of the platform?
3. Will this platform scale with your growth?
4. Support and community: are there resources to turn to? What does the broader partnership ecosystem look like?
5. Interfaces and integration: will this platform integrate with your back-end systems?
6. What is the total cost of ownership, and what do maintenance, licensing, and support costs look like? How do they increase over time?

One last thought on platform selection: Make sure you talk to customers using the platform. Ask the vendor for references, but also do your homework. Reach out to folks in your network to get a sense of how people use the platform, what challenges they have had, and how they feel about it post-launch. You can’t have too many of these calls; they will help you understand what and how the platform works day to day.

Funding and ROI

You will need to understand the total cost of ownership and the benefits or gains the new system will bring. If your Why is technological debt, and you have been in a maintenance mode, it’s more than likely that your new system will cost more. Your old system doesn’t cost anything and feels like a freebie. Not since the early days of commerce have I seen a new system with double conversion rates, so you will need to get creative about what benefits the business and your customers will derive from the project. Having the team bought into the Why will pay dividends. Hopefully, they will  see the benefits, which could be as simple as freeing up your sales teams to have more time to sell and not take orders.

Once you understand your ROI, you can decide how to structure your project and its costs. I have seen two different ways.

1. Only fund the upfront work, requirements gathering, and UI/UX that informs the cost of the development portion of the project. I prefer this method, but most CFOs/CEOs won’t sign off on a project if they don’t have at least some idea of the total cost.
2. Get a bid for the entire project up front. If you have done enough requirements gathering, you can look to get a bid for everything. Your system integrator should know what they typically charge, although none are typical builds. If you go this route, add 40% internal contingency to your request so that you have room for surprises. The last thing you want to do is have to go back and ask for more money.

The other way to manage costs is to be flexible with your requirements. From my experience, this is hard to manage. Most people feel they will never get the functionality if it doesn’t happen at launch. At one company, there was an internal joke that there “was no 2.0,” meaning that once something launched, it was there for good, and nothing would change or get upgraded.

Conclusion

The decision to re-platform your ecommerce business is always a challenging one.  As technology author Rick Watson once said, “No one ever got fired for not re-platforming, but plenty of people have been fired for botched re-platforms.”

Starting with the Why, getting clear about your requirements, resisting the urge to over-/under-engineer, and selecting the right technology platform are crucial to having a successful re-platform project. Hopefully, this will help you understand the importance of firmly setting the foundation for your project.

About the author:

Dale Edman is an independent adviser on B2B and retail ecommerce and digital transformation. He has held ecommerce executive positions at companies including West Marine, Newell Brands and The Wasserstrom Co. He posted an earlier version of this article on LinkedIn.

Submit a nomination

Nominate a game-changer for the Global B2B eCommerce Industry Awards from Digital Commerce 360 and the B2B Ecommerce Association.

Sign up

Sign up for a complimentary subscription to Digital Commerce 360 B2B News, published 4x/week. It covers technology and business trends in the growing B2B ecommerce industry. Contact Mark Brohan, senior vice president of B2B and Market Research, at [email protected]. Follow him on Twitter @markbrohan. Follow us on LinkedIn, Twitter, Facebook and YouTube.