ATEST-10 Critical Factors for a Successful Delivery of Complex Digital Commerce Programs

According to the eMarketer 2019 Global eCommerce Forecast, by 2021 we expect global eCommerce to approach $5 trillion in sales.  Our overall global economy is experiencing a slowdown and period of uncertainty which is also reflected in the retail digital commerce space.  However, a projected 14.9% growth rate in 2023 is still far better than most of our personal investments these days.

In my experience of 20+ years in multiple roles in commerce implementations for large companies, my hit list of Top 10 critical success factors would include:

1. A Unified Core Team. The most successful projects have always been those where the Core Team are all working towards the same goal.  This core team may include internal resources and consultants in key roles:  

• • Product Owner – point person for functional requirements
  • IT Project Manager – point person for technical implementation
  • QA Lead – point person for testing and quality assurance
  • Integration Lead – point person for integrating the commerce system to other systems in the enterprise, such as ERP, PIM, CRM, and so forth.

2. Strong Executive Sponsorship. There will likely be critical decisions at various points in the project that, if delayed, could have significant impact to budget and timeline.  The Core Team needs to be able to escalate and get to a decision as quickly as possible.  The problem statement and options should be presented in a succinct manner so that the Executive sponsor(s) have the information they need to make the decision quickly.  Not everyone may agree with every decision that is made but the team needs to agree to disagree and move on.
    
3. Weekly Check-ins with the Core Team to discuss status, budget, plan and risks. These check-ins need to bust down the barriers that impede progress or have the potential to become a project roadblock. Transparency is key.  As a consultant, I am always upfront with my client.  We’re in it together as one team (see point #1!).  If there is an issue maybe with resources or timeline, I’ll surface that and provide a plan that gets us back on track or ask for help from the Core Team as a whole in terms of priorities.  No one throws anyone under the proverbial bus–just get the job done and escalate/resolve issues early before they become a roadblock.
    
4. Foundational Documentation. During the start-up phase of the program, standards need to be set in place that will hold for the rest of the project. This includes the typical Project Management Standards: organizational charts, communication plans, resource plans, risk logs, RACI diagrams, etc., as well as development and implementation standards along with an initial scope statement.  A starting high level architecture gains clarity and should be documented in whatever format makes sense.  I like to see a high level context diagram that shows the main users of the system and how they interact, possibly an application component diagram that also declares any integration needs and a physical architecture diagram that addresses any security constraints.  This foundational documentation set can then be given to anyone who joins the project to give them a baseline understanding of where the project is headed.  Ideally, any consulting company that you may choose to work with will have a standard set of foundational documentation and templates that can be re used.   Re-inventing the wheel each time is just not fun.  Of course, Client requirements may dictate slight changes or require certain toolsets which are reasonable adjustments.
    
5. A Well Understood Development Methodology. Part of the foundational documentation should be around the development methodology that the team will use and what tools will support that methodology.  At AAXIS, we utilize a Hybrid Agile approach that looks something like the following and can work regardless of technology:
    
   
    
    
6. Focus on Performance and Security. In today’s world, performance and security are paramount.  Both of these topics need to be incorporated into the development methodology, training, and architecture from the onset of the program.  Meet with client security teams to determine any specific requirements.  System Integrators should have clear and documented security policies and should have performance planning and testing incorporated early on in development.
    
7. Clearly Defined Features and User Stories. Agile can sometimes be used as an excuse to not define everything up front.  And that is partially true–Agile needs to allow for flexibility and continuous collaboration.  However, some key requirements do need to be well understood up front.  This is especially true when working with an offshore development team.  A high-level Story Map is always a good idea to help ground the team and provide overall context for large programs.  User Stories need to be consistent and clear and planning needs to allow for review and clarifications as necessary.
   
   
8. A Backlog of Stories that are ready or close to ready for development. It is important to have a backlog of User Stories that can continuously be groomed.  Once the development team gets to the performing stage of maturity, they can be very efficient and can start to work ahead a bit.  Today’s tools and continuous development easily allows for multiple concurrent branches of work.
    
9. Project requirements must be traceable from the point of inception to final deployment.  There are many good toolsets that support this type of traceability, e.g., Atlassian has a solid suite of tools, as does Microsoft.  What is important is that the product requirement or feature gets tied to a series of User Stories.  Each User Story can have linkages to code checkins and peer reviews, test cases, performance results and security scans.  In this way, the application becomes somewhat self documenting.  If you can tie a new requirement to a parent User Story – you can see the evolution of that functionality.  You also remove the dependence on tribal knowledge which often plagues legacy systems.
    
10. Measurement is key to continuous improvement.  For each measure, at least one mechanism must be defined. Here are a few examples:
     
    • effectiveness of the functionality implemented via Google Analytics
    • customer satisfaction via online ratingsn and surveys
    • application performance via JMeter, LoadRunner, and Selenium
    • quality of software development via defect count, static code analysis, code complexity
    • project metrics such as team velocity and sprint burn-down should also be reviewed to identify improvement opportunities
       

Each project will bring its own set of unique challenges.  Hopefully, the above list gives you some concrete items to think about as you start up your own digital commerce initiative.