Ecommerce is the first Imperative among a myriad of others (IOT, social, analytics etc) in running your business DIGITALLY.

If you are a retailer and not yet online let me tell you that it takes time and patience to build it before you see the business impact on your top line, it is very important that you keep checking if you are not heading for a disastrous or broken outcome.

How do you know that you have chosen the right team to take you on the next-gen commerce journey which they promised? How do you understand the so called checkpoints? What do these checkpoints indicate about the health of your project implementation and what is the likelihood of it delivering an outcome that you aimed for?

A self evaluation framework on these lines is a good starting point. Whether you are just starting off or midway through the process of building your e-commerce platform or have gone live but looking for a litmus test to ‘RESET’. It’s never late to evaluate and re-evaluate. Introducing an evaluation framework which can help businesses to self rate their e-commerce platform initiatives and verify their alignment to their Omni Channel Commerce strategy.

This framework is based on a self evaluation questionnaire with scores which can be weighted against its business priorities. What you get is a multidimensional score chart across multiple parameters. Each tells you where you stand.

There are two broad categories of self evaluation to keep in mind.

1. Global Standards & Best Practices
   1. Customer Centricity of your Platform
   2. Branding , Visuals and content Marketing approach
   3. Heuristic Evaluation
   4. Omnichannel Capabilities
   5. Alignment to Business Operations (merchandising, publishing process, creatives)
2. Project Planning & Delivery
   1. Project Scope Control and Optimisation
   2. Project Test Plan and Coverage
   3. Project Planning and Execution
   4. Project Risk Planning and Performance Assessment

 

Global Standards & Best Practices

It is clear that no ecommerce platforms are alike and what applies to your competitors should ever be considered AS IS. It is also very important that the scope of your ecommerce platform features is keeping in mind the customer base that you are trying to impress and the geography you sell to. This sounds common sense but a lot of companies do ‘copy paste’ the website of their closest rivals (or business threats). Add to that situation the ‘productised’ solutions who promise faster time to market often standardise far too much and compromise customer experiences. Result – a ‘me too e-commerce store’ which neither creates a great customer experience nor delivers on the promise of sales which it aimed to provide to begin with.

It is important to remember that –  the functionality could be same as any ecommerce store the CUSTOMER EXPERIENCE SHOULD BE UNIQUE TO YOUR BRAND.

“Does the designed system consider optimal navigation paths to place an order”? Does the website communicate to the customer it does offline? Does it convey to the customer – I am here (anytime), I am awesome easy and I will be here to listen to you?

Heuristic evaluation should consider questions like “Does the system keep the error avoidance approach instead of error message approach?

“Is the user proactively informed about everything about the most important things in an ecommerce store aka “product, price and orders”?

“Is the system focusing on the balance between visual appeal, right content and ease of order conversions?” Even one aspect being compromised leads to poor customer experience.

Do you have clearly defined key metrics to chase e.g. average order value, unique visitors, conversion rates etc ?

Does your product data from the Product Masters consider the ‘digital catalog essentials’? Digital catalog essentials include three primary requirements (a) customer friendly product title and product information(including pictures) (b) extensible product data structure which can evolve with time and covers aspect of inventory, price and promotions too. (c) Alignment of this product data structure to match the overall experience of the stores. Are the publishing workflows understood by your business teams?

“Are you focusing enough on the complete experience (physical and digital channel) or just focusing too much on order capture? Did you consider ways to help customer get updates about his order and products with the same rigour with which you incited him to place his order?”

Are you making your click and collect or BOPIS customers wait for their orders in stores? Did you forget to train your staff for these orders and the related process of delivery and service in your stores? Did you explain this process well enough to customers and do they know what to expect? What if customer wanted to cancel one of those items ordered online when they come to collect in store? What if they want to convert it to a gift?

Did you plan to ensure that the web platform does not miss out on the minimum security standards like PCI, Privacy Standards (PII), COPPA, OWASP top ten security vulnerabilities etc ? What’s more critical to your country and it also depends on what you sell.

Have the Business Operations beefed up to support the upcoming ecommerce platform? Have the teams been identified, trained and engaged at a deeper level to enrich product data, support customer service requests both for online and physical stores – (overlapping scenarios). By the way it makes a lot of sense to bring up cross functional teams  as champions of the new environment.

Depending on the size of your product catalog, what is the readiness of your teams in achieving the following for your ecommerce platform?

(a) product feed file preparation for product, price and inventory information
(b) product data enrichment process on PIM
(c) product photography and banners
(d) test data readiness for those testing cycles
(e) test data verification and agreements for the vendor teams to test them and time

Project Planning, Testing & Delivery

Scope

In any new technology (platform) adoption, defining a right fitting project scope (aka minimum viable product) and executing it till it delivers through a 1^st launch– lays the foundation of an application which is built to last for your current and future customers. If you fail here, you are starting off on a shaky vessel. A shaky vessel never go the distance – it’s just a matter of time. Very soon you will be out scouting for an alternative service provider or an alternative technology platform. Anyways the rate of technology change rivals the timeframes applicable for phased developments today.

But before the application is built, was there a consensus among all the business stakeholders and IT teams about the scope of the project. Was there a collaboratively created business requirement document / user stories? Did the user stories evolve into a visually stunning and content rich and useful web pages or mobile app experience? Did you identify who and how would you create that engaging content? Did you mobilize those resources? Did the creative process align to the technical? Did these teams understand what is critical for your business?
You would have changed a lot of business requirements from the point you started to the time teams were brought together to verify the said application. Were these changes tracked carefully to ensure no business requirements are missed?

Did your vendor also cover non-functional software requirements. Examples like ‘expected concurrent users, page views per second, other performance benchmarks, global configuration settings, internationalisation, data migration, archiving rules’ etc? Did you participate in completing the loop?

Did project WBS cover important milestones, demos, common dependencies between its tracks? Did the plan get updated due to unmet dependencies? Did the plan get updated to cover up for the scope creep which cropped up ;-)? Did you add a new third party relationship during the project execution (e.g. a new ratings and review platform? Did you realign project plan and the deliverables to cover this new component of the application? Did you plan for setting up this business and technical relationship?

Architecture & Testing

Were the key architectural decisions discussed and taken through consensus? Did you ensure that a functional as well as a technical roadmap was placed on the table for atleast a 3 year horizon? Did they converge well? Were the resources required for those upcoming projects were made available and put in place today?

Test Planning and Strategy

The test strategy highlights important feeder checkpoints in the development lifecycle where a certain part of the application is verified. (e.g. dummy credit cards and white labeled cards need to be available to testers to verify your loyalty account payment transactions). Availability of data for these feeder checkpoints is critical for verifying application delivery on time. Availability of related third party system for it’s sandbox servers should be committed and made available early during the ‘construction/creation’ phase of the application.

There is nothing like a working piece of application. So even if you are following a standard RUP or Agile based delivery, a working piece of the application is always an important part of the plan. It creates fantastic engagement opportunities and also reference point for the business stakeholders. For RUP processes, demos should be proactively planned and given its importance for any solution delivery. Agile method assumes this.

Peak load performances should be based on

• deployment frequency
• number of assets involved
• size of assets applicable at each performance test time.

The system test plan should be upto-date and should be revised periodically to accommodate all the change requests initiated during the course of the project

Automated workflows to publish the content are great but they should consider all the failure scenarios (as in the real world) (e.g. auto deployment of minor catalog updates could have a failure scenario where manual deployment should be considered and that should be tested)

The testing strategy must cover all the aspects of the project. Most commonly missed activities in testing approach are

• Browser Compatibility Testing
• Multi Lingual Testing
• Multi Site Specific (difference) testing
• Planning for A/B testing for specific business initiatives.

 

Too often IT/Business managers have a lot of these in their mind and challenges are plenty in ensuring that all of these fall in line at the same time. The orchestration of all of these activities is life and blood of an IT business manager. A trusted program advisor, a domain expert and a hands on project manager can ensure that the surprises during the execution of the application delivery can be minimised and bring the business outcome you aimed for. Using the fundamentals of this framework is relevant to any typical e-commerce implementation in an RUP based delivery cycle. However there are different models of application building/delivery/execution which creates its own set of unique challenges and checkpoints and needless to say it requires its own set of checkpoints.

As i write this, I am wondering on ‘how would you apply these checkpoints in an Agile delivery model’? What would you say are very relevant for each sprints? When and how in the project lifecycle would you ensure coverage of aspects like PCI, PII etc? How would you ensure you would ensure compliance of these standards during each sprints?