Based on our e-commerce experience, we’d like to highlight some of the factors that need to be taken into consideration for implementing a successful e-commerce integration project as part of this blog. However, please note that the approach would need to be tailored to meet the customer’s individual requirements as one size does not fit all. We would be more than happy to help you on this journey. I’ve also tried to refrain from using IT Jargon; keeping it as simple as possible.
Before the start of any e-commerce project, it’s crucial to map out the criteria that will define the success of the project and this should be in line with the business case. This will also be required to define the scope of the project and the follow-on activities as laid out below:
Choosing a relevant delivery methodology
There are several delivery methodologies, each with its own set of pros and cons. A number of points should be carefully considered before choosing the appropriate one – here are a few:
- Is this an implementation project or a change project?
- Is this an ‘e-commerce only’ website project or does it require ‘core’ design changes/ developments across several software solutions (ERP, CRM, Marketing, etc.)?
- Is this project dependent on other project deliverables/ timelines? If yes – what kind of delivery methodology does the project follow?
- Is the integration scope significant?
- How complex is the design? Is the implementation split into multiple phases with the initial phase being more ‘out of the box’?
- Multiple POCs (Proof of concepts) required?
- Are we using any accelerators?
- What is the project scope – Is it a ‘big’ implementation or a ‘small’ implementation?
- Are multiple implementation partners involved?
- Experience and expertise of the resources available?
- What kind of offshore/ onsite split?
- Project timelines?
- Documentation and sign off requirements?
Based on our experience, we have evolved a ‘hybrid’ delivery methodology involving a combination of waterfall, ASAP and agile methodologies to provide a dynamic, ‘incrementally’ iterative approach which is at the same time robustly structured with various project gates.
Putting the right team structure in place
Irrespective of the chosen delivery methodology and approach, it’s important to have resources working in tandem from the following areas in the project:
- Solution Assurance – This will encompass solution architects from the customer side as well as solution architects from the various implementation partners. It will be responsible for governance and will provide the steer if any cross-team design issues arise
- Functional Design – This team will be responsible for the design and preparation of the functional and integration specification documents
- Technical Design & Development – This team will be responsible for the technical design and preparation of technical specification documents. Plus also the subsequent development based on the functional/ integration specification documents. This team will comprise of technical architects, back-end technical consultants and Integration experts
- UX Design – This team should work along with the business, functional consultants and technical architects to produce wireframes that satisfy the business requirements. The UX design should reflect in the functional specification documents
- Quality Assurance & Control – Will be responsible for putting the test plan, monitoring strategy, defect resolution SLAs, quality standard of the deliverables, etc. They must liaise with the functional team to understand the functionality and to write the test scripts
- Project Management – Will be responsible for building the project plan and keeping it updated in line with the project status, stake holder updates, co-ordination across teams, status review meetings, RAID Logs, dependency logs, monitoring the various project gates etc. The PM should have prior experience in managing ‘integration’ projects – otherwise, it just doesn’t work!
- Team Leads/ Project Leads/ Scrum Masters – To manage a combination of resources in a specific part of the overall project – It could be based on systems, functional area etc.
- Change Managers – It’s crucial to get the buy-in from the end users and as such it is important to constructively engage with the end users/ product owners and to make them a part of this journey
The importance of Discovery workshops
The insights gained in these sessions will be crucial for the high-level design/ blueprint. The discovery workshop ‘calendar’ should be planned based on logically grouping together similar high level requirements. It’s also important to get the ‘right’ people into these sessions to get the required business clarifications.
- Proof of concepts can be initiated in parallel should the need arise
- Document the assumptions, dependencies and any outstanding clarifications with owners
- If the project involves integration with back-end systems (ERP, CRM, Marketing etc.), it would be essential to understand the touch-points with the e-commerce system from an integration perspective. This needs to be ‘black and white’ to avoid any scope creep and misunderstandings
- Any need to modify the back-end systems would have to be agreed and scope confirmed. In general, back-end developments can be segregated into the following categories:
- ‘Core’ configurations and functionality not currently implemented
- Enhancements to existing ‘core’ functionality
- ‘Provider’ module requirements for integration
- ‘Consumer’ modules requirements for integration
- Initial data load of master as well as transactional data related developments
- In general, B2B implementations are relatively more complex when compared to a B2C implementation – so you might have to make some tactical decisions as you go along
- Discuss on the plan to manage ‘technical debts’ if any
- Understand if a phased implementation will help with mitigating risks and if it could benefit the overall programme
- Get a steer on the UX design requirements and initiate the wireframe design
- Segregate and finalise the requirements into various categories: ‘out of the box’, enhancement required etc.
- Capture non-functional requirements
An integrated project plan
Many e-commerce projects get delayed because due attention is not paid to managing the dependencies across the various teams. The project plan must take into consideration the cross-team dependencies when setting start and end dates for each deliverable. It is also crucial to break a ‘user story” into as many meaningfully small pieces as possible. This will ensure that progress can be shown on a weekly basis rather than having to wait for a full month (or more) before showing any progress.
Let me illustrate by taking an example: If the requirement is for a customer to be able to place an order. This requirement can be broken down into smaller pieces of work:
- Design for the ‘order page’ by the UX design team
- Development of the UX by the e-commerce team
- UI development
- Integration work to send the data to the middleware
- Error handling
- Development of the UX by the e-commerce team
- Development of the ‘provider’ module by the backend ERP team
- Asynchronous interface design & development by the middleware team
- Integrated testing and delivery of the ‘umbrella’ user story
As you can see from the above example, to complete this functionality in a single sprint might not be possible – so it’s important to sequence the cross-team tasks into the plan so that it can be carried across multiple sprints by creating ‘technical’ user stories where relevant. Note that the illustration provided is just a sample, as ‘placing an order’ is a much more complicated process
Highlighted below are a sample of other issues that are typically faced and should be factored in and constantly monitored to avoid a cascading effect:
- Functional & technical design agreed without a final UX design sign off from the business
- SLAs not clearly defined for business to sign off functionality, providing clarifications
- Resource planning issues on the customer side. Even if it is the customer’s responsibility, we will need to educate them on the importance of dedicatedly involving ‘in-house’ business representatives, solution architects, technical team etc. throughout the project
- Cutting corners in testing. Test scripts must be detailed and we should be able to map to the requirements. Contingency would have to be built into the plan
- Not a sufficient testing of negative scenarios
- Siloed data migration approach. Design does not take into consideration the overall integrated architecture if relevant
- End user training manuals & work instructions being provided for sign off at the very last moment
- End user training plan put up at the last moment and not clearly structured
- User readiness assessment not properly defined
Note(s) on change management
- Change managers should have a ‘change management action plan’ in place and this should feed into the overall project plan in terms of timelines, goals and milestones
- We are inherently selfish (Hmm…). This aspect should be leveraged. Get end user buy-in by demonstrating how the functionalities delivered by this project will aid them in their day to day activities
- Have regular stakeholder engagement sessions and feed this back to the project managers/ steering group
- Communication is crucial. Updates can be sent across various in-house media channels on a regular basis to create project awareness and to re-iterate the business benefits
- End user solution acceptance and training: This is often given the least importance but this could potentially delay the go-live if user readiness is not at an acceptable level.
- Do not squeeze in the trainings in a hurry and bombard the end users with a tightly packed schedule – haphazardly conducted sessions will only alienate them
I hope this blog has provided some insights into planning an e-commerce implementation project. Please do not hesitate to contact us for any clarifications if you are planning to embark on an e-commerce integration journey.
