I'm a developer who enjoys the process of coding; it's both enjoyable and intellectually stimulating.
However, in my role as CEO of Odoo, I recognize the importance of minimizing custom developments in ERP implementation projects.
It's not always straightforward, especially when customers believe they require custom developments. Conversely, implementation service providers are inclined to profit from these additional customization requests. However, I must caution both parties: custom developments may not be beneficial for you!
What's the Rationale Behind Minimizing Custom Developments?
For clients, custom developments introduce additional expenses and extend the duration of the implementation project, potentially jeopardizing its success. Moreover, custom development incurs a technical debt that must be addressed in the ensuing years, resulting in increased maintenance and upgrade expenses. This technical debt typically amounts to around 25% of the development costs annually (approximately 17% for maintenance and 8% for upgrades).
While individual developments may appear straightforward and economical, the project's complexity escalates exponentially rather than linearly with the addition of each customization. You may be inclined to address the shortcomings of your previous software, but wouldn't it be more advantageous to standardize your business processes and execute the project twice as quickly and cost-effectively?
For partners, custom developments often entail substantial expenses for relatively low customer value. How frequently have you estimated 10 days for a feature development, only for the customer to deem it excessive for a basic feature, prompting you to charge for only 8 days? Yet, in reality, the task ends up consuming 12 days. Moreover, when issues or changes arise later due to the rushed development, the customer refuses to cover the additional day, attributing fault to you. Consequently, what was supposed to yield a service margin of 35% now results in a 6% loss.
To facilitate growth, it's more advantageous to concentrate on providing high-value services with superior margins while minimizing the risk of non-billable hours. These services encompass project management, business analysis, customizations without extensive development, change management, and training.
Failure to cultivate a mindset geared towards minimizing custom developments will inevitably lead to loss of competitiveness. Competitors adept at effectively managing customer expectations will incur lower project implementation costs. Have you ever lost a project because the customer deemed your services "too expensive," only to realize that the customer ultimately acquired significantly less than what you would have delivered?
Certainly, custom developments are occasionally indispensable for business operations. However, based on my experience, the majority of customer requests either do not justify the cost, become irrelevant once they begin using Odoo, or are unnecessary as they do not form a part of their core usage. Whether or not you choose to accept these requests hinges on your implementation methodology and your company's mindset.
The customer is typically not well-versed in the product or implementation projects. Consequently, they may struggle to assess the cost of a particular feature against the revenue it generates. Customer requests often stem from the challenges they encountered with their previous software or existing workflows. However, many of these issues are mitigated or become irrelevant once they transition to using Odoo.
Striking the appropriate balance between standard and custom developments can be challenging. What may not be worthwhile for one customer could be highly valuable for another.
If you inquire with service companies, they will unanimously assert that they only develop what is necessary for the customer (and sincerely believe they do so). However, in reality, it's extremely challenging to accurately gauge one's own capabilities and determine proficiency in evaluating returns on investments, as well as addressing issues through business advice rather than development.
To grasp the varying mindsets, let's examine the implementation frameworks of two service companies.
CASE 1: When a company allocates 8 developers for 2 project managers, their primary emphasis is on executing custom developments. They likely adhere to methodologies like Scrum or another agile approach, with project managers dedicating a significant portion of their time to drafting specifications and testing developments. While this approach satisfies customers in the short term by fulfilling their requests, it inadvertently contributes to escalated project costs and timelines. Consequently, customers may experience dissatisfaction as expenses and delays mount.
CASE 2: In contrast, a company comprising 2 developers and 8 business professionals (such as analysts or project managers) prioritizes business-oriented services. This entails activities like change management, business process engineering, identifying standardized solutions to business challenges, and conducting training sessions. Their team may include individuals with expertise in accounting, inventory management, or other domains, capable of scrutinizing customer requests. By delivering substantial value at competitive rates, they effectively meet customer expectations. While the majority of customers appreciate this approach, some may experience short-term frustration as their requests are challenged. However, in the long run, these customers tend to exhibit high satisfaction levels as the project progresses.
Determining the optimal balance between CASE 1 and CASE 2 is challenging as there is no standard benchmark to guide this decision.
At Odoo, our service department comprises developers, project managers, and business experts. Throughout the years, our emphasis has been on enhancing project efficiency rather than simply increasing upfront service sales.
Below are the team sizes for our direct implementation projects:
- For small customers (1-50 users), our team consists of 11 developers and 80 project managers & business analysts. This means that 12% of our team members have a developer profile.
- For large projects (>500 users), our ratio is approximately 50% developers and 50% non-developers.
Alternatively, you could interpret it this way: for small to mid-size projects, the average breakdown of our billed time is 12% for development and 88% for business services.
As a customer, employing this straightforward method of examining team sizes will aid you in evaluating potential partners based on your expectations. As a service company, crunch the numbers with your own team sizes. This ratio will indicate whether you have opportunities to enhance your margins and project velocity.
If your ratio is double this figure, it's worth considering your methodologies, business model, and the profiles of your upcoming hires. A solid starting point is Odoo's own "implementation methodology."
Managing Customers' Unique Requests
In customer interactions, it's crucial to distinguish between stakeholders' overarching goals and the specific requirements of key users. Decision makers often emphasize time and budget constraints, while key users focus on feature specifics. With these conflicting objectives, you'll need to prioritize: which group do you aim to satisfy?
I think you should always do what you think is good for the project; that means challenging what key users asks, to the point of refusing to do it if you think it’s not worth it. Trying to satisfy key users demand by doing everything they ask is a very short-term mindset; it’s better to focus on the on the project success.
I employ the subsequent framework to address requests for custom development:
- Do we truly need it?
- Is investing in the expenses (for its development and upkeep) worthwhile?
- Is the level of benefit substantial?
- Is it possible to achieve the same goal using an alternative method?
If you determine that developing a particular feature isn't worthwhile, it's essential to make a strong case to the customer. Various strategies can be employed for this: providing a clear rationale ("Why"), postponing it until after the initial launch, or escalating the issue to a manager (although not ideal, it may be necessary at times).
Is it truly essential?
Imagine you've received a request for the subsequent custom development:
The client has a Magento Commerce website and prefers not to alter it due to prior investments. However, they desire full integration of Odoo with their Magento site, encompassing products, coupons, abandoned cart follow-ups, and more.
The most effective approach to determine necessity is by examining whether the customer already possesses this feature in their previous software. If the customer manually records all orders in their old software, they can continue to do so with Odoo. In this case, I would suggest proceeding to production without developing a Magento integration, utilizing Odoo for three months. Afterward, we can reassess priorities and determine if further investment is warranted. By then, there's a 50% chance that the customer will favor Odoo eCommerce over a Magento connector due to their positive experience.
When it comes to change management, it's preferable to implement business process changes gradually rather than all at once. Leveraging Odoo's modularity, it's logical to deploy in multiple phases: initially focusing on what the customer absolutely requires to sustain operations, and subsequently integrating additional features to enhance efficiency.
In practice, the customer's development priorities are likely to shift upon entering the production phase. This can occur for several reasons:
- During software usage, they uncover new developments that take precedence and consequently reevaluate their priorities.
- After investing in the implementation, they are satisfied with the outcome and opt to reduce expenses on superfluous features.
- As the customer begins utilizing Odoo in a production environment, their perspective shifts as they gain proficiency with the product.
Does it justify the expense?
Additionally, it's essential to assess the advantage: how many man-days per month will the customer save due to this feature? Frequently, the customer only considers the time they currently spend on such tasks and their anticipated future savings. However, in practice, they will still need to input all the required data for calculations, handle exceptions manually, etc. (For instance, even with a Magento connector in place, they'll still need to resolve conflicts, record price discounts in both software solutions, manage inventory conflicts due to the lack of real-time synchronization, etc.)
Next, it's crucial to assess costs effectively. Frequently, the customer focuses solely on the initial development expense. However, in reality, this cost can easily double or triple when considering various factors: time for testing, addressing bugs and project delays, adapting documentation as it's non-standard, and accounting for future maintenance and upgrades over the next five years.
Please keep in mind that employing a community module can save time during initial development. However, you'll still need to allocate resources for testing, maintenance, project delays, and upgrades, all of which contribute to the overall cost. Additionally, utilizing a community module also introduces technical debt.
Does the benefit justify it?
Suppose there's a request for the subsequent custom development:
Upon confirming a sales order for a construction project, our aim is to generate a sequence of tasks according to a predefined set of rules, which are contingent upon the products, customer, and locations involved.
When faced with a customization request, your initial response should be to evaluate the scale: how many construction projects are typically won per month? Assuming the customer secures 10 such projects monthly, it likely requires around 10 minutes to create and update tasks by duplicating and adjusting project templates.
Is it justified to initiate a complex development to economize less than 2 hours of work per month? Certainly not. Implementing this feature would entail approximately 10 days of development initially, plus 25% of this effort annually for maintenance.
Is it possible to achieve the same goal using an alternative method?
Suppose you receive the following customer inquiry:
I'd like to integrate our Outlook calendar with Odoo CRM.
Odoo offers a standard connector with Google Calendar, but not with Outlook. However, developing and maintaining a connector for Outlook could incur significant expenses. Fortunately, there are numerous services available that synchronize Google Calendar with Outlook, such as IFTTT. Therefore, one potential solution would be to subscribe to and set up such a service for each employee.
Although it's not ideal since you'll need to adjust your setup whenever you hire a new employee, the solution can be implemented in just 2 hours initially, with subsequent adjustments taking only 10 minutes per new employee. This is considerably less effort than embarking on a new development project, particularly for companies with fewer than 100 employees.
Please be aware: Odoo actually offers an Outlook connector within the community apps. Therefore, we recommend utilizing this connector instead. The previous statement was purely theoretical.
Frequently Asked Questions for Partners
Will reducing custom developments result in a significant loss of revenue for me?
If 80% of your team consists of developers and 20% are project managers, you may feel that developments are essential to maintain your revenue. However, companies with only 20% of their teams as developers hold the opposite perspective: they prioritize business services to sustain revenues and margins.
In practice, customers often require functional services more frequently than developments. It's just a matter of finding the right approach to market and deliver them. Typically, once the customer is operational, the number of development requests decreases, while the demand for business services can persist, provided your approach is effective.
Certainly, transitioning overnight isn't feasible; shifting a company's mindset and implementation methodology requires time. However, by gradually moving from an 80/20 ratio to 70/30, you can enhance your margins. Further progress can be achieved by aiming for a 60/40 ratio, taking another step forward.
I would suggest:
- Focus on refining your implementation methodology (begin with ours if you lack one).
- Retain your current team members while gradually hiring additional business analysts or project managers who don't possess a developer profile.
Points to consider:
- Steer clear of developers who also handle project management duties. Mastering development requires extensive practice and years of experience, while excelling as a project manager similarly demands time and expertise. Promoting developers to project managers risks having individuals who are average in both roles rather than excellent in one. This can have adverse effects on your implementations, as having average project managers may hinder success.
- Avoid involving developers in customer relations. Developers possess versatile skills and can quickly solve technical issues, making it tempting for them to approve custom developments without fully understanding the implications. During Odoo's early stages with only 10 employees, primarily developers, I accelerated growth by refraining from using developers in customer relations. Instead, I began recruiting project managers without development expertise and restructured everyone's roles more effectively.
If the customer selected Odoo, wouldn't it be because they desire all these customizations?
Odoo is an exceptional software. Simply by utilizing Odoo's standard features, the customer's company will undergo significant transformation for the better. Most departments will experience increased efficiency, providing employees with a tool to enhance their productivity. This is where the true value lies; custom developments will only constitute 5% to 10% of the features that the customer will utilize from the platform.
Even before presenting an offer, it's essential to proactively manage customer expectations. By challenging their requests, you're providing what they typically expect from excellent project managers. This proactive approach not only allows you to reduce the initial budget and enhance competitiveness but also helps in limiting costly developments. Instead, you can focus on high-margin business services. This strategy ultimately benefits both you and the customer.
After the customer is operational and satisfied, they are far more inclined to purchase additional services due to the excellent value you provide. With numerous apps available for deployment on Odoo, the potential is nearly limitless, allowing you to continually expand the scope of services offered.
Many companies believe they are unique and special, which often leads them to justify their desire for customization. However, this mindset is not conducive to a successful project. It's your responsibility to guide the project towards a value-focused direction that truly benefits the customer, beyond their initial requests. In the long term, they will appreciate this approach. Odoo isn't just a platform; it embodies "best business practices" distilled from extensive experience gained over many years of working closely with customers.
Would it be worthwhile to develop custom features if they could be reused in multiple upcoming customer projects?
Previously, we attempted multiple times to develop custom features for customers, aiming to reuse these features for future clients. Unfortunately, this approach proved unsuccessful in most instances.
- People often assume that a feature is generic enough and will be desired by many. However, in reality, other customers will typically want it in slightly different ways, resulting in the management of multiple versions of custom code.
- This argument is frequently employed by customers to negotiate sharing the cost of a custom feature or by our internal team to justify an "unbilled" feature. However, in both scenarios, it adversely affects the company's margins.
Creating features for sale to multiple customers is the business model of a software vendor (such as Odoo SA), which differs significantly from that of a service company. In this model, high margins of around 80% on products are necessary to offset the substantial R&D costs. Moreover, in this model, over 50% of charges are attributed to developers engaged in R&D, which are not directly billed to customers.
A proficient service company aims for a billing rate of approximately 80% to maintain robust growth. However, achieving this billing rate becomes challenging with a mixed business model that combines software development and services.
I apologize.
I understand that this blog post may not resonate with everyone, and for that, I apologize. My intention is not to cause harm but rather to provide assistance. To be helpful, I believe it's important to be straightforward and transparent.
Please view this blog not solely from the perspective of a "Software Vendor." Rather, consider it as insights gleaned from our service department's experiences over the past year. Our focus has been on project velocity and competitiveness, prioritizing actions we believe are conducive to project success rather than solely complying with key user requests. Remarkably, this service department has become as disruptive and efficient as our product, evolving into a significant competitive advantage.
By sharing our learnings, I aspire to aid certain partners in accelerating their growth, akin to how SAP did with ASAP, the Accelerated SAP implementation methodology, a few years ago. ASAP played a pivotal role in SAP's development and their capability to execute complex corporate implementations in the early stages. A fundamental aspect of their approach is adhering to the standard, known as "best business practices." If their methodology can achieve success with a challenging product like SAP, envision the possibilities with an exceptional software like Odoo!
We possess a vast partner network comprised of highly intelligent individuals. Our primary weakness lies in our relative youth and immaturity. However, if we manage to mature and evolve, we have the potential to disrupt the market more rapidly than any product has done previously. In just a few years, we've already transformed the lives of 3.7 million users. Yet, to reach 100 million users, having a great product alone is insufficient. We must collectively build the best partner network ever.