Why we bill you by the hour and why you should love it

In November 2011, we opened our office in Sydney – Australia; since we are passionate about the Magento Community, our first move was to contact the local Magento Partner companies with the objective to get to know people, learn more about the market and share information. One of my conclusions: most companies work on fixed-bid projects and some were very skeptical about our time estimate modality.

Don’t worry, I am not talking about time-tracking or ticketing tools. I will only give you the three main reasons why you should love our methodology.

1. Achieve More in Less Time

At Inchoo, we accept the fact that the client’s knowledge about the solution and our knowledge about their business will grow exponentially throughout the project’s life. While, working on a fixed-bid project, it means committing to the first solution that was envisioned when the project was originally quoted for.

Ask yourself how many times you started with a single idea for a project and how it looked like at the end? Usually it looks a little better than what you first imagined due to the additional ideas or the compromises that were made along the way in order to achieve efficiency. The final product is hardly ever the same as the original concept.

Web-development is no different: a problem given has many possible solutions. The technology is changing every day and time is always a critical factor.

It is impossible to foresee and prepare for every possible scenario and challenge that will be encountered along the way.

Fixed-bid projects require extensive scoping/planning tied to legal arrangements. The hours invested in discussions and adjustments to keep the project in touch with reality costs more time and money – resources that could be better utilised in the actual development of the solution.

Since the knowledge will grow over the lifespan of the project, we need the flexibility to adjust the course of the project on the fly in order to achieve the best solution, with less effort. Instead of committing to early decisions where the knowledge around the solution was at an embryonic phase.

2. Quality Comes First

I will provide an example. Throw the first stone – or the first troll comment, if you have never been in similar situation.

After signing a fixed-bid contract, the client has a new idea or would like to change a completed feature in order get in front of a competitor; or the developer realises that the feature is not as easy to develop and has just discovered a conflict with a 3rd party web-service.

Whatever the reason is, the fact is that the project is not going to be delivered within time and budget. The pressure is on.

The client wants the product that is better aligned to his business, while the company wants to be rewarded for their work. The developer is already eating his lunch at his desk while the project manager – who has already discussed one supplementary payment is reluctant to negotiate a second one.

In such scenario, workarounds, hacks and all sorts of quality dumpers are bound to happen.

I agree that it does not apply to every company – nor do all the clients get angry with under-deliveries or supplementary payments.

Every professional naturally aims at delivering the best quality – that’s how they get the achievement fix. However, due to the human factors and conflicting interests, when the pressure is on, quality is always the first sacrifice.

Having a Magento website, you want to make sure that all custom features respect the system’s upgradeability and theme hierarchy while keeping the Magento core files untouched. The best Magento coding practices have to be in place: from the minor front-end tweak to the most complex extension you can think of.

When quality is compromised, your online business starts creating what we call a technical debit.

3. Avoid the Technical Debt

Companies in the service industry use the same negotiation logic that fruit-stands use: the more features offered for less money, the higher the chances are of converting the deal. This is a dangerous game.

Unlike fruit and vegetables that you can inspect, touch and smell to make sure it’s suitable, it is hard to say what might appear under the hood of your Magento Storefront, which may look ok in the browser window. Unless you are having a major stability problem or performance issues, you will only know that everything is alright (or not) when it is time for a version upgrade.

A Magento version upgrade in installations with rather standard features should not need more than a couple of hours. However, if your theme and custom features didn’t follow the Magento architecture from the beginning, everything you did so far and paid for is likely to require more corrections every time you are required to upgrade your Magento installation. In some cases it may require a complete rewrite.

You will need to upgrade to take advantage of a new feature, for including extensions or keeping the compatibility with your hosting or a 3rd party system that you use for inventory and managing your warehouse or point of sale.

There are many reasons why this technical debit will need to be resolved sooner or later and the only way to avoid it is to ensure quality from the beginning.

With that in mind: even if you need to leave a couple of features out the first launch, you should make it a priority to work with Certified Magento Developers. A feature can be included later if you budget doesn’t allow for it for the first launch.

If your Magento Installation is not following the Magento architecture and theme structure, chances are you will get in a snowball of technical debt.

Conclusion

These are the three main reasons why you should love estimates rather than fixed-quotes: achieve more in less time, keep the quality and avoid the technical debit.

I understand that many don’t feel comfortable with this flexibility and I can’t stress enough that a partnership must work both ways and trust must be established.

In order to create such an environment, we provide our clients with access to the Magento development installation and promote a great level of involvement between the client and the developers. Our client sees everything taking shape, which also reduces the re-work and revisions.

Lastly, flexibility has nothing to do with not having budget constraints. If leaving a feature out of the first launch will allow you to keep the quality of the solution, while keeping the project within budget, this is better than crippling scalability and getting into technical debt.

Working with this time and material methodology brings about an enhanced experience to both parties and better cooperation terms between two businesses whose ultimate objective is to make a great case and grow.