How many hours of your work will it take to implement Magento?
In this article, I will answer the question that a person deciding to implement Magento should ask himself: how much time of my work will it take to implement Magento? How many hours should I reserve in my calendar for activities on this project?
How much of your time is needed to implement Magento?
Size of implementation matters
What does the number of hours of your Magento implementation work depend on?
4 Magento implementation scenarios
What should be kept in mind when implementing Magento?
Summary – How many hours of your work will it take to implement Magento?
If we take Magento implementation, which will cost about 112,000 USD/EUR, which roughly means that the software house will spend 1,600 hours of work on it, and divide this implementation into at least 2 stages, that is, the initial business analysis before implementation and the development (codign) work, we should assume that for the business analysis, we should engage at the level of 15 to about 20 hours per week, for the implementation (development) stage from 11 hours to about 31 hours per week.
So, as you can see, this can mean a commitment from a day and a half a week to practically a full-time job.
If you are curious about where these values come from, why they present themselves in this way, when you will have to devote more time and when you can devote a little less time, – I will describe this later in this article.
Let’s start by defining the size of the implementation I am writing about here. It is known that if we are implementing a 84,000 USD/EUR implementation, we suspect that we will have to engage a little differently than in the case of a 560,000 USD/EUR implementation.
To simplify reality and be able to discuss specific cases, let’s imagine that the online store we want to implement on Magento costs roughly 1,600 hours of software house work. If we recalculate this by the average rate, which is 70 USD/EUR, we get an implementation worth about 112,000 USD/EUR.
Now this implementation, in a nutshell, we can divide it into 4 stages.
The first stage is the business (pre-implementation) analysis, from which the whole project starts (often named discovery stage). Next comes the implementation stage, during which front-end and back-end are coded, and integrations are implemented. Then comes the final testing of the e-commerce platform by the client. We call this stage UAT, (user acceptance testing) followed by the final stage, production launch. The goal is to make the coded and checked store, with errors corrected of course, available to end users.
The course of the process is as follows (with an implementation of 1,600 developer hours): the first stage, the analysis stage, takes about 2 months. Then there is the implementation stage, which takes 6 months. After 8 months, the store is put to final testing by the company that ordered the online store (or B2B platform). After these tests, which, let’s assume, can take about 2 weeks, a date is set for the production launch of the site.
This is what the whole process looks like.
Let’s now go through different scenarios and you will find out where the different values of your time required to implement an online store come from.
In summary, we have these main stages:
In each of these cases, I have described the various tasks that are more or less doable on your part.
During the business analysis you definitely need to attend workshops, there are weekly meetings, at least one per week. You need to accept the user stories and graphic designs. On top of that, we have communication and billing to keep track of.
In the context of implementation, there is again communication, weekly meetings, acceptance of tasks, and billing, but there is also an additional element, which is called Testing (with a capital letter because we are talking about a serious process and not a quick clickthrough performed by the Project Coordinator).
Some Software Houses perform only code review (checking the code by a more experienced programmer), which shouldn’t be called testing. The Project Coordinator, who in such situations often has multiple roles and tasks in the company, performs quick “tests”. He or she simply checks quickly the functionality and hands it over to the client for verification. As you can see, the tester does not appear in this process. This is a costly mistake.
If there is no tester in the process, the quality of the system drops. In such a case you must become the testers of such a Software House. In other words, you become an external department of the Software house responsible for testing. In simple words, the testing costs will be transferred to you.
I have prepared 4 scenarios. These are situations when:
There is a tester in the project, manual tests are carried out, and later, at the end of the project, automated tests are carried out. The tester is also at the business analysis stage to check the correctness of assumptions as early as possible. The goal is to identify any errors that may occur at the coding stage. If the error is detected at the business analyse’s stage then we safe much (we don’t code something that won’t work properly anyway).
I won’t exaggerate if I write that in the majority Software Houses don’t have quality assurance processes. This means that apart from the execution of a code review by a more experienced programmer and quick check by the Project Manager from the agency’s side, nothing more is done.
As you can guess, if we created a matrix, we have two dimensions. On one axis would be whether the Software House embraces quality assurance and on the other axis would be whether we have a lot of integration (and thus whether a large number of different companies are involved in the project).
Integrations in the project context often involves intensive cooperation and the involvement of many different companies. The more companies involved in a single project, the more time is consumed by communication, setting up and synchronizing activities, which in turn increases the time needed for testing.
Now let’s look at the time we should commit to business analysis. If we consider different scenarios, we find that on average we should devote from about 15 to about 20 hours per week, as shown below.
Please consider these figures as approximations – not everything agrees down to the minute, but you should assume about this amount of time to work with the Software House when performing the business analysis.
I would add that this business analysis will take about 2 months. So such a commitment will be needed for 8 weeks.
The choice of Software House depends not so much on its quality, but on the processes that guarantee quality. Depending on whether you choose a Software House with good processes, the number of working hours may vary. For business analysis, the difference between 15 and 20 hours is not so significant, although it is always better to have 5 hours more than less. At the implementation stage, this difference is BIGGER.
You will devote about 12 hours per week, and sometimes as much as 31 hours per week (i.e. almost full-time) to work with Software House at this stage.
Testing makes the biggest difference here. If you are dealing with a Software House that doesn’t quite handle testing and provides half-finished products, then you become an external department of quality assurance for your Software House. In this case, you should assume that you will spend about 16 hours per week on testing alone (with a Magento deployment size of about 112,000 USD/EUR, or roughly 1600 deployment hours).
As you can see, this is not a small amount of time. Someone who coordinates the project from your side and coordinates this collaboration should reserve two full days just for testing. This is a lot. I’d rather allocate that time to something else, especially since if it’s done internally by a Software House and the Software House has processes, he’ll test the same elements not in 16 hours, but in, say, 8 hours, so he’s 2 times more efficient at this kind of work.
Next, we move on to UATs (User Acceptance Testing). This is the stage during which you do a final check of the store before acceptance.
Of course, if there are still bugs, you have to describe and report them again. If you were an external quality assurance department during the project, you would really have a lot of work at this stage. You will have to test the whole service again.
So you should assume that you will have to allocate about 2 FTE for this.
If you would like to complete this process in about 2 weeks, it is realistic that it will take you about 2 FTEs for that period.
If a tester from the Software house side participated in project then it would take 1 FTE for 2 weeks.
In case the project is complex and requires multiple integrations, that is, various external companies are involved, not only you and the software house, but also, for example, the company responsible for the ERP, the person responsible for the implementation of the PIM, someone responsible for the implementation of marketing automation, or the digita analytics company that is waiting to prepare the data layer, you should assume more time. 100 hours is a bit of an underestimate, but let’s assume just that much…
Finally, there is the production launch, where most of the work is done by the software house.
You are in a situation where you are simply waiting, impatiently, champagne in hand, ready to celebrate the moment when the service becomes available to final users.
Let’s assume that this is the end of the implementation (so as not to complicate the topic unnecessarily).
In summary, if we take some general principles, it follows that if the offers from the software house you are considering include very little time for testing-for example, only 40h for the entire project – then there is probably no testing (no quality assurance) at all.
In that case:
First – the project coordinator is responsible for quick check, without an extensive and effective testing process. So before the functionalities get to you, they are not properly tested.
If you do not have a tester in the software house, then you will become an external testing department for that software house.
Second – the more testing is on your side, the longer the project will take. If you are dealing with a company that has developed internal quality assurance processes and implements them on a daily basis, knows how to document bugs and knows what the task should look like after corrections, it will simply be more efficient.
Third – the more people and different companies are involved, the more you will have to commit to the project and spend more time during the implementation phase.
This cannot be avoided.
My recommendation is that you should choose a company that has quality assurance processes and is familiar with (and executes) testing. This is simply more efficient.
In summary, how much time will it take you to implement Magento? How much work do you need to commit to a Magento implementation project?
At the analysis stage, roughly 15 to 20 hours (I described the differences above) per week.
When it comes to development stage, the differences are definitely greater, it is roughly from 11 hours, to about 31 hours per week.
If you are at the stage of thinking about Magento implementation, I encourage you to read the article about how much it costs to implement Magento. You’ll find specific information there.
