Project management controls

Reading time: 10-12 minutes.

An ecommerce replatforming guide

Replatforming projects are resource intensive. They range from relatively to highly complex, therefore need an experienced project manager to guide them and establish the fundamental principles of IT project management.

Don’t underestimate the amount of work required. Invest upfront to ensure you have a clear project plan and structure; it will save you £££ in the long run. This comprehensive guide walks you through the phases of a replatforming project with advice based on 15+ years’ experience.

Prefer videos?

TL;DR – if you don’t want to read the detailed article below, fast forward to my Repaltforming MasterClass Video series. There are ten videos of 3-4 minutes each covering key elements of project planning, vendor and SI partner selection.

Quick links:

  1. Project planning.
  2. Vendor selection.
  3. SI partner selection.
  4. Discovery.
  5. Development.
  6. Go live stabilization.
  7. Continuous deployment.

Phase 1 – Project planning

It’s essential you have a clearly defined project from the start. Taking the time to get all stakeholders aligned and onboard with the project process will save you a lot of time and money later on. Believe me, I’ve got the scars from rushing in!

Follow the steps below then collate the outputs into a PID (Project Initiation Document) that can be circulated, reviewed, approved and saved for future reference. It can also be version controlled if anything needs to change at a later date.

Define project goals, objectives and success criteria

This ensures you have evaluation criteria against which to measure project progress and outputs.

It’s as simple as creating a table:

GoalTo reduce the total cost of ownership for ecommerce.
Objectives1.        Keep project build costs within £500,000.

2.        Keep annual support & maintenance 3rd party costs less than 2.5% of GMV.

3.        Reduce cost of 3rd party tools from the current £250,000 per annum.

 

Define project budget

Budgetary control is essential because each vendor and SI will have a different cost model, so you need to ensure you only consider options that are affordable.

If the ‘ultimate’ option is beyond your budget but there is a clear business case, put a proposal together for increasing the budget and present back to the project steering group (for larger businesses) or Sponsor (see Project Governance below).

For me, the biggest issues with replatforming projects generally come from three areas (1) lack of detail and contingency in budgeting (2) lack of planning around internal resource preparation of data (3) discovery. I’ve found that delays and over-spend are usually caused by the client – be it via not being able to fulfill tasks on their side or change requests – this needs to all be part of the upfront planning / governance.
Paul Rogers, CEO, Vervaunt.

 

Key cost lines to consider in your website replatforming budget:

  1. Internal resource – time & effort for the project team and stakeholders.
  2. Tools & tech – what will you need internally to manage the project e.g. Sharepoint, JIRA, Basecamp, Slack etc.?
  3. Contractors – what skills are you lacking in-house that require investment in freelancers or contractors e.g. business analyst, change manager, UX/UI designer?
  4. Ecommerce platform license fee – upfront cost & annual renewal.
  5. Platform MVP* build cost – ballpark based on a clearly defined scope (see below).
  6. 3rd party apps and plugins – other tools you’ll need in addition to the platform to achieve your MVP scope e.g. postcode verification.
  7. Support & maintenance – monthly fee to ensure the platform is looked after post go-live.
  8. Site enhancements – monthly provision for resource to enhance existing functionality or implement new features.
  9. Payment fees – transactional costs payable to the platform vendor or a 3rd party gateway.

* I introduced MVP in the article, “What is ecommerce replatforming?“. It means ‘Minimal Viable Product’ and refers to the baseline functionality that must be delivered before the new ecommerce platform is approved for launch.

Define project scope

To get a realistic cost for your new platform from a vendor and/or SI partner, you need to provide a high-level scope definition for the MVP launch.

What does this include?

  • Legal compliance needs to ensure you stay out of prison! e.g. GDPR requirements.
  • Data capabilities to align with core business processes e.g. two-way stock flow.
  • Customer facing functionality needed to enable online selling e.g. basket and checkout.
  • Bespoke features supporting customer service and online selling e.g. community forums.
  • Features and data feeds that marketing campaigns are reliant upon e.g. Google Shopping feed.
  • Integration with essential 3rd party tools e.g. postcode validation software.

A common approach is to define the full scope for an ecommerce platform, then split this out into the MVP view (which is what must be delivered for go-live) and then package non-critical elements into a phased release plan.

For example, a basic Wishlist would make the MVP list but a shoppable Wishlist which can be shared with friends, who can then buy directly from the Wishlist and this be made visible to other people on the list, isn’t critical to launching the new website.

Top tip:

Agree a clear and consistent criteria for rating requirements to help you prioritise ‘essentials’ for MVP. Many use MoSCoW but it can be highly subjective – most stakeholders consider their requirements to be ‘must’ haves!

Define project team structure & RACI

A project without a well defined roles & responsibility matrix is like a house of cards; it will fall down.

Your project manager will help you define the core project tasks and then you can align stakeholders to map the RACI roles:

  • Responsible – the person who will do the work and must complete the task.
  • Accountable – the stakeholder who owns the task; they must ensure the ‘Responsible’ people complete the task as planned.
  • Consulted – subject matter experts who need to give input before a task can be completed.
  • Informed – stakeholders who need to be kept in the loop with task progression, even if they’re not directly involved in the task.

The table below gives a basic example.

RACI table

Define project governance

Governance isn’t sexy but we’re hard-wired to respond to authority (just ask Robert Cialdini), so governance structures help control project delivery.

What is governance for ecommerce replatforming?

It’s the controls put in place to enable the project manager to monitor progress and take appropriate action if there are any issues. Governance requires:

  • A project Sponsor with the authority to make project decisions.
  • For larger organisations/projects, a Steering Committee to oversee project delivery.
  • Chain of accountability for core tasks (RACI).
  • Reporting standards and process.
  • Project communication protocols, tools and documentation.
  • Project RAID log (to document Risks, Actions, Issues & Decisions).
  • An escalation process to manage exceptions, including decision gates.

Set-up documentation and reporting controls

Accurate and reliable communication is essential for a complex project. Stakeholders need to understand what is happening at each stage and have a clear view of what’s expected from them.

Do the following:

  • Set-up project collaboration tools e.g. Sharepoint, Basecamp, Trello, Slack etc.
  • Create project report templates.
  • Appoint report owners.
  • Check: do the right stakeholders have the right access permissions to tools & documents?
  • Agree frequency and distribution lists for reports.

Phase 2 – Vendor selection

I recommend selecting your technology partner first before considering an implementation (SI) partner.

Why?

If you run an RFP to select both at the same time, you risk either reaching a dead-end or having to make an unnecessary compromise.

The last time I worked on a project where this was the approach taken, the client was left choosing between an SI partner they loved (with a platform that wasn’t the right fit) vs. a platform that ticked the right boxes but they didn’t like the SI partners in the pitch.

It’s much easier to select the ecommerce platform that best aligns with your business needs first because then you only review SIs who can implement your chosen technology.

Business requirements capture

You need a clear understanding of what the business needs, and why. There are six steps to achieving this:

  1. Map functional ecommerce areas & align stakeholders.
  2. Run face-to-face meetings to understand their ‘as is’ needs and ‘to be’ vision for ecommerce.
  3. Document all requirements; play back to stakeholders for review and approval.
  4. Review requirements against project prioritisation criteria: flag what’s critical for MVP, deprioritise others into phases, filter those poorly defined and/or not aligned with ‘to be’ ecommerce strategy.
  5. Review with project team and sponsor, amend as appropriate and agree final set of requirements.
  6. Share back to full stakeholder set and communicate reason for prioritisation and why any requirements have been removed.

Top tip:

Have an experienced ecommerce person lead these stakeholder meetings. Get them to set realistic expectations from the start and influence people by advising on ecommerce good practice. For example, if people want to customise the platform to do something bespoke, there needs to be a clear business case for doing so.

In terms of which topics to focus on, some are essential for any organisation regardless of size, for example:

  1. Back office integration: CRM, ERP, Finance, ESP etc.
  2. Payment gateway integration.
  3. Product catalogue management
  4. Pricing & promotions.
  5. Product data management.
  6. Search and merchandising.
  7. Returns & refunds.

Vendor shortlisting

By this stage you know:

  • Your project goals
  • Your scope and budget
  • Your operational, technical and ecommerce requirements.

This is enough to review the vendor landscape and shortlist a maximum of 2-3 viable platforms. A good staring point is to use Gartner’s Magic Quadrant for Commerce. You can find a summary version free of charge on most vendor’s websites e.g. https://www.episerver.com/learn/resources/analyst-content/gartner-magic-quadrant-for-digital-commerce/

If you have no clue about the vendor landscape, work with someone who does. This isn’t a shameless plug (well partly!) – it will help you save time and effort by focusing you on the right questions and a sensible commercial approach to filtering.

For example, if you have an experienced internal IT team that has the resource and desire to own as much of the platform support, maintenance and development as possible, and needs a highly flexible platform that provides a loosely coupled architecture, you may want to consider API and micro service based platforms like CommerceTools, Elastic Path and Skava.

Budget and time to live also play a major role. If you’ve got less than £100k to spend on the build and want to be live in 3-4 months, you won’t look at vendors like SAP Hybris, IBM Websphere and Oracle; you’re more likely to be looking at vendors like Shopify, Shopware and BigCommerce.

Vendor evaluation

Don’t do anything until you’ve defined your evaluation criteria. Ask yourself:

  1. What are the critical elements of our MVP scope?
  2. What information do we need to know to compare platforms?
  3. How important is each of these elements to our ecommerce strategy?

Below is an example from a weighted score card I’ve used on a client project. We worked together as a project team to define the capabilities that would influence the decision, then weighted them based on level of importance to the business e.g. integration with an existing ERP has a bigger business impact than social media data feeds.

replatforming vendor scorecard

Create a vendor brief around your scoring matrix. Ensure they come in and focus the product demo on the elements that are of most importance, avoiding a platform beauty parade. Generic sales pitches don’t achieve anything – the best way to evaluate vendors is to give them specific scenarios to demo against. Below is an example from a retail ecommerce replatforming project:

Scenario: Consolidated Baskets.

Customers can buy a mixture of different product types and depending on the type, the order flow can vary. Currently the website can’t consolidate baskets; users have to place separate orders. Please explain how your platform could achieve the following using native functionality and flag where customisation is required.

  • Customer buys a standard product (fulfilled direct from the DC) and a subscription product that is paid for by direct debit (fulfilled via a 3rd party supplier).

  • For the standard product, they can specify a substitute product, for the others product they don’t.

  • They add both items to the same shopping basket.

  • The website processes the order and:

    • Takes payment for the in-stock item and pushes through to ERP for processing for dispatch
    • Pushes the user through a direct debit set-up process for the subscription item, and sends the order data into ERP.
  • The customer account is updated with the new order, with each product showing the payment type.

  • If the customer is allocated the replacement item because the main item isn’t in stock, this is flagged on the order summary.

Preferred vendor selection & due diligence

After the demos you now have insights into how the platform will enable your business requirements, and a clear idea of the ballpark budget to enable a like-for-like cost estimation comparison.

You now need to decide which is the best option, or better put: which set of problems are you most happy investing in!

No platform is perfect for any business, so you now need to be honest with yourselves and don’t just think about the shiny new tool. Ask the following questions:

  1. Why wouldn’t I choose the platform?
  2. What isn’t clear that needs more investigation?
  3. What will we be losing from our old platform?
  4. How will our ways of working change and what is the impact?

Speak to existing clients (and not just testimonials – testimonials are always positive!).

Ask them about:

  • Quality of the vendor after the contract was signed.
  • Reliability and level of support.
  • Any unforeseen complexities or problems.
  • Anything they discovered that surprised them.
  • Any functional gaps that the vendor hadn’t made clear.

Top tip:

Take your time doing the due diligence. You’re about to make a big investment, so don’t rush it. If something doesn’t sound right, explore it until you’ve understood it better. If it represents a risk, ensure there’s a clear mitigation plan.

Phase 3 – SI partner selection

For most COTS platforms, you will need to appoint an SI partner for the implementation work, even if you intend to take on support & maintenance in the long-term.

The process for selecting the best-fit SI partner is very similar to vendor selection but the criteria for selection are different. A good SI partner will:

  1. (Ideally) Be certified as a solution partner by the vendor you have selected.
  2. Have a rigorous and proven process for ensuring their technical teams stay up-to-date with the vendor’s product roadmap.
  3. Be a good cultural fit with your project team – take time to get to know the key stakeholders!
  4. Have experience of implementing the platform for a variety of existing clients, including organisations similar in size and complexity to yours.
  5. Have the technical and operational resource to handle multiple projects simultaneously without compromising timelines.
  6. Have a proven and coherent process for managing the transition from development phase into site launch and stabilisation.
  7. Have an account management team with ecommerce experience, able to demonstrate how they help clients to maximise their use of the platform.
  8. Have existing Clients who like them and speak positively about their technical skills.

A few tips on what to ask and check for:

  • Standard support SLA – what are they responsible for, what are the response times, how are incident levels defined?
  • What’s the division of responsibility between the SI and the vendor and how do they ensure there is no breakdown in the support process?
  • What work tasks are covered in the support agreement vs. what would be additional billable time?
  • What team will be working on your project for implementation and will this change after go-live?
  • How do they manage the go-live transition to ensure the site is stable and performant?
  • What site monitoring do they provide in their standard SLA & how do they minimise site performance interruptions and downtime?

Phase 4 – Discovery

You’ve selected the platform and your SI partner, so it’s job done right?

Wrong!

This is just the start of the fun 🙂

The Discovery phase is an insurance policy to protect the next phase, development.

It involves a series of in-depth workshops with business and technical stakeholders to translate the high-level project scope into a comprehensive set of use case models and a functional specification.

These outputs are approved by the senior stakeholders and sponsor, then fed into the development phase by the Project Manager(s) to build out the user stories for the sprints.

Ensure there is a separate cost line in the project cost model for Discovery. Typically this is between £10,000 and £30,000 but on complex projects it can be £50,000+.

Top tip:

Set this up as a SoW (statement of work) that is independent of the main contract, with initiation of the main contract dependent on successful completion of Discovery.

Why?

If you isolate the main contract (service agreement) from Discovery, if anything happens during Discovery that causes you to rethink the vendor or SI decision, you aren’t then committed to the full project costs and it’s much easier to exit and rethink the project delivery. The outputs will be reusable by another vendor and/or SI partner, so it’s not sunk cost.

Phase 5 – Development

I’ll keep this brief as this is where the technical teams take over. A few key points:

  • Development is split into sprints – mini phases to release functionality continuously.
  • Each sprint follows a strict control process and is reviewed in detail to ensure any functional issues are flagged and fixed.
  • Reports are provided to flag progress against the project plan and identify if additional resource is required to meet milestones.
  • UAT (User Acceptance Testing) is often aligned to sprints, so the business stakeholders do UAT for functionality released in each sprint.

The most important insight for business users is this; development is not the time to switch off, sit back and wait until pre-launch UAT.

You need to stay engaged, check that business functionality is being delivered according to the agreed user stories and functional specification, and check if there are any changes to the in-scope deliverables that impact your area of the business.

Phase 6 – Go live stabilisation

Warning:

Set realistic expectations!

All new platforms experience a degree of turbulence when they move from development into live production.

Why?

It’s a complex code base with integrations into other systems and it’s the first time it’s in the wild with real users hammering the database and features.

Don’t panic!

This is where your Change Management work stream comes to your rescue. You can’t avoid issues but you can identify risk and put smart mitigation plans in place to minimise disruption. For example, having an end-to-end roll back plan that enables you to roll back to the old platform if there are any business critical failures e.g. users can’t place orders.

Read this article for more details on what Change Management is for ecommerce replatforming projects and why you need it.

Top tip:

Ensure the project sponsor sets clear expectations with all stakeholders, communicate regularly in the approach to launch and hold daily ‘stand up’ sessions every morning to update people.

Phase 7 – Continuous deployment

Once the new platform is stable and performing well, you will fall back into your business as usual (BAU) cycle of continuous development, working with your SI partner and internal IT team to deliver the business roadmap.

The level of involvement of your SI partner depends upon the scope and capabilities of your internal IT team. Some organisations outsource all technical support to an SI partner, others prefer to self-serve in-house and select a platform that gives them a rich suite of dev ops tools and direct access to control and update the presentation layer (the customer facing website).

Summary and take-aways

Well done, you made it through in one piece!

It’s a lot to take in but that’s deliberate; ecommerce replatforming projects are complex and time consuming. It pays to have a clear understanding of the process flow and the work streams required to do this well.

Key learning points:

  • Replatforming projects can be split into distinct phases.
  • Each phase has a different set of requirements and challenges.
  • Multiple stakeholders are involved, which means managing expectations.
  • Losing focus risks losing time or compromising outputs.
  • Good governance is essential to minimise risk.
  • An experienced project manager is required to ensure the project is kept on track and adheres to the agreed governance criteria.

Learn more about enterprise ecommerce replatforming by reading my other guides:

If you have any questions, please contact me using the online form, by LinkedIn or Twitter.