Effective business analysis before Magento implementation
Today, we’ll tackle the functional approach to business analysis. Is investing more in business analysis at the beginning of a project, or is a smaller-scale analysis sufficient, with most issues being resolved during project execution?
Is investing more in business analysis at the beginning of a project?
What is business analysis?
2 approaches to business analysis in the world of ecommerce implementation
Which approach is better for ecommerce?
Summary
As always, let’s begin with a simple answer to this difficult business question.
When discussing the implementation of B2B ecommerce or online stores using Magento, considering the current economic environment, where ecommerce managers and business owners face greater uncertainty, we should conduct a more extensive business analysis upfront to increase our financial security.
This is the simple answer to this complex business question. I encourage everyone to keep reading to deepen their knowledge.
P.S. Sometimes, business analysis is referred to as the discovery phase. In this article, these terms are used interchangeably.
Business analysis is a project stage where we precisely define the desired system—its appearance, function, and behavior.
I would say there should be several outcomes of business analysis.
We should understand which tools, applications, and solutions are responsible for what, how they connect, and what kind of data is transferred from one system to another.
In short, these are descriptions of functionalities and business requirements that should be understandable to everyone at any level of experience and by the entire project team (yours and the ecommerce agency).
We should know how each functionality is supposed to operate and how it should function so that we can say that it meets the criteria we set at the beginning.
A reasonable minimum is that these graphic designs should be prepared in at least two resolutions, i.e., for mobile and desktop. Let’s say around 368 pixels and around 1280 pixels.
We should have a homepage, listings, search results, product pages, shopping carts, checkouts, my account pages, thank you pages, CMS page templates, and views covering all the necessary states, such as hovers, validations, empty filter results, etc.
These are the bare minimum outcomes of business analysis.
Here, we encounter a question and two camps across the market.
Some say that what’s necessary at the beginning is the basic architecture and the most critical user stories. These are enough to start coding. Then, we can refine the assumptions during the programming and create graphic designs.
There’s no need to produce vast documentation since the e-commerce system will likely change during discussions and collaboration as the team gains experience.
Moreover, a whole year of implementation is quite a bit long in the world of e-commerce. Many new things can happen, and new functionalities that need to be accommodated may appear. So why create all the documentation if the project vision will change anyway?
This approach has quite a few advantages and is valid in some respects.
The second approach is somewhat different, suggesting we should define as many things as possible upfront.
Besides knowing what the system’s architecture should look like and the functionalities and acceptance criteria of individual features, we should create graphic designs immediately and predict as much as possible from the start.
This way, later during project execution, we won’t waste time and will avoid the situation where, at the end of the day, we’ve coded something that does not align with our initial vision.
Most people say that an agile methodology is an approach where we only have general assumptions at the beginning and immediately start working.
I believe it is suitable for projects where we introduce an entirely new service or product to the market.
We want to launch them quickly, test them on real users, and, based on the usage analysis and qualitative feedback, determine the future direction of system development.
If we were designing Uber for the first time, as it didn’t exist before, this approach would be great.
We would have only the main assumptions initially; we would begin coding, quickly testing it on real users, adding new functionalities, etc.
In this case, it makes sense, especially since, for start-ups of this kind, several different companies are probably working on a similar idea, and the one who enters the market first wins it. There’s no time for detailed planning.
However, ecommerce is not as innovative a solution as it was 20 or 15 years ago. Ecommerce processes are similar across businesses.
Of course, there are various functionalities we can add, but generally speaking, ecommerce is predictable, and we already know the main processes. It’s an incredibly valid point because we understand how users will use the ecommerce. It is not inventing a new process.
Therefore, we can predict more things from the start.
I’m a strong proponent that, in the case of ecommerce, a full-scale business analysis should be performed.
Especially in current times, with substantial economic uncertainty, the financial predictability of a project is very important. We should start by preparing all user stories, carefully describing acceptance criteria, outlining the architecture, and creating all the graphic designs. Only after this phase should we move on to coding.
There is an option to speed up the work. If we have an accepted discovery phase for the main elements of implementation (type of Magento version, basic configuration), we can start these initial coding tasks. This can be done right after accepting the first stories and acceptance criteria.
By determining more upfront, the implementation budget will be more secure, and the implementation time will be shorter (we won’t waste time coding, correcting, and recoding the same element).
If we spend more time performing the discovery phase, the final implementation budget will diverge by about 10% from our estimate. However, we won’t be faced with an unhappy situation where, after the discovery phase, someone estimated the implementation at 80.000 EUR/USD. Still, after 14 months of work, the budget exceeded 250.000 EUR/USD, and there’s no end in sight. Additionally, if determinations are refined during project execution, the project magically tends to gain mass uncontrollably.
That’s precisely why conducting a more thorough (better) business analysis is much better. As a result, we’ll have more control over the project budget and implementation time.
In short, more detailed business analysis = greater financial security and predictability + shorter implementation time.
I hope you will be more knowledgeable when deciding on the scope of business analysis.
To summarize, in my opinion, if we are concerned with greater security and predictability, we should perform a comprehensive business analysis right from the start, during which we should establish:
In my opinion, in these uncertain economic times, when everyone cares about financial security and predictability, this approach is much more sensible.
Finally, one more important piece of information—user stories and acceptance criteria will have to be prepared regardless of whether during the business analysis phase or the coding phase, whether it’s for an online shop or B2B ecommerce.
The first approach gives us greater control over the implementation timeline and budget.
If the topic of business analysis has piqued your interest, I hope you will also enjoy the topic of Magento implementation costs, which will complement the knowledge gained today!
By the way—if you aren’t subscribing to our newsletter yet, you don’t know what you’re missing 😉 I write about news from the world of ecommerce that you simply cannot miss!
