How to keep your E-commerce project from becoming a nightmare

Building an E-commerce site has a lot of similarities to building a brick-and-mortar store. There is a lot that goes into building a store. You have to choose a good location, lay a foundation, get all of the infrastructure, utilities and all other things that work in the background constructed, and then finish with the curb-appeal to attract customers. An E-commerce store is much the same. The choice of the E-commerce platform is an important one (same as building location), all of the planning and details of the infrastructure, backend integrations and logic isn't flashy but it's what keeps the the site functional and stable (much like the building infrastructure and utilities in a building). To cap it off, you need a frontend that is both fast, appealing, and flexible (the curb appeal).

Just like building a brick-and-mortar, an E-commerce site is a large undertaking and there are plenty of pitfalls that can turn a site build into a nightmare. Here are some common ones that are often encountered and ways that Binary Anvil works to mitigate them.

1. Building for minimum viable product
2. Scope creep
3. Ever expanding cost
4. Communication

Minimum Viable Product:

Given that a site built is a large undertaking, it is always best if the site requirements are narrowed down to what is called the Minimum Viable Product (MVP). The MVP captures all of the requirements the client needs to function, but may not cover all of the functionality that they want. By whittling down to the MVP, the site build will be as quick as possible. Some of the reasons to guard the timeline are:

1. If the timeline is super lengthy, there is a risk of needing to upgrade to a newer version of modules or the platform mid-project (this incurs additional cost)
2. A faster build provides a quicker return to the client
3. Client fatigue is real and sometimes even if its their choice to length the build time, it can cause friction internally for the client's organization

While going through discovery, often the client's minds (especially the people in marketing) are running full tilt in creative mode. There are a hundred new features that can make the site better. This type of creativity is fantastic. At Binary Anvil, we capture all of these requirements. We capture the MVP requirements and the "oh wouldn't this be cool" features. We work through the list with the client and determine which of the features are MVP and which are phase 2. The phase 2 items then have their own post-launch timeline and various milestones.

By pushing the "oh wouldn't this be cool" features to post-launch, the client is able to get their site up fast and then expand its functionality through the phase 2 features.

Scope Creep:

Scope creep is a term used to describe features being added mid-project. As the MVP features are being built, the client sometimes sees the feature and thinks "this feature also needs...." or "that is great but we also need....". These are typically fantastic ideas for expanding the appeal, conversion or general functionality of the site. The complication with adding these scope creep features to the project goes back to the timeline (same as the MVP discussion above). By adding new feature after new feature, additional time (and money) is added to the project. Sometimes these new ideas are a part of MVP that was missed or not considered. Often though, they are items that can be pushed to the post-launch (phase 2) list.

The first way to combat scope creep is to be thorough during the discovery phase of the project. If the dev agency is thorough in capturing all of the site requirements and clearly walks the client through various options and choices, the chances for scope creep mid-project are mitigated. In the discovery process, the goal is to to bring all necessary decisions for the client upfront (not mid-project). And if that goal is reached, any new ideas that come up mid-project will automatically be listed as post-launch.

Ever Expanding Cost:

The cost of the project ballooning is probably one of a client's worst nightmares. In my experience, project cost increases for one of two reasons.

First, the client adds scope mid-project. This type of additional cost is at least within the client's control. Second, the project is being billed in a "time & materials" fashion instead of "fixed cost".

Many agencies give high-level estimates for features, but ultimately the client pays for the actual time needed to develop the feature. The project cost is then at the mercy of the accuracy of the estimates. Although some projects do end up within the estimate range provided at the beginning, many projects expand far outside of the original estimate range. In these situations, no one is happy. The client is upset because they don't know what the final cost of the project is going to be (and it feels like it won't ever stop) and they feel like they are trapped and have no control over their own project.

To circumvent this pain point, Binary Anvil takes the fixed-cost approach for projects. After discovery is finished, all features are defined and a cost is given for each. Unless the client changes a feature requirement, the cost of the feature will remain fixed. This allows clients to have confidence in the project cost and the amount they need to budget for the build. The client is then in full control over the cost of the project and thereby the timeline.

Communication:

Lack of communication in any situation can be very frustrating. Clients sometimes don't feel like they are adequately informed or can't seem to get the details they need to make an informed decision in a timely manner. It's a large and expensive project and they aren't getting any timely information from the agency. They feel like they have to bug the agency for a week to get a simple answer. Something as simple as communication can cause so many frustrations. To keep clients informed Binary Anvil does the following:

1. Create a project charter at the beginning of the project detailing how communication should take place and how the client can escalate issues or concerns
2. Create a client/binary anvil slack channel for the project
3. Have weekly meetings with both teams
4. Provide a weekly status report that acts as both a meeting agenda and an update
5. Provide Service Desk access to Jira tickets to work through specific issues/tasks

Binary Anvil is also flexible if additional (or different) communication methods are needed.

Summary:

Just like building a brick-and-mortar store, the client wants and needs to know how things are going, what the final cost will be, and generally be in control of the project. The agency on the other hand is there to facilitate and guide the client. Throughout the entire process, the agency should strive to provide information and options to the client in a way that ensures the client is well informed and able to make decisions in a timely manner. If a client doesn't feel they are in control of their own project, it is probably time to find another agency.