14 Feb

Zero Efforts

Zero Efforts


“In theory, there is no difference between theory and practice. But, in practice, there is.” 
~ Jan L.A van de Snepscheut

This article is a precious part of the hybris Project Patterns series.

Every software project is unique. Even if we follow renowned design and implementation patterns, common practices and guidelines, each project requires understanding, exclusive care, and customizations.

The hybris Suite offers myriad of features and configuration abilities. Therefore it is a highly flexible platform, which serves as a blueprint for possible solutions. The platform covers most of the needs a high-volume web shop or a PIM hub would require. 

However, the platform itself is not the final solution. There is always a need of adjustment, configuration or custom development.

One of the faulty perceptions, we see, is that if a feature is out-of-the-box then it must be zero effort to acquire or use it. Hence, during the Request for Proposal process, companies – in attempt to lower bidding price – estimate those features as “0 man-days” i.e. no effort involved. Especially prominent, this problem is seen with Young Partners.

Projects experience the same difficulty also during the Inception and Construction phases, when teams evaluate workload for the implementable requirements.


Features, which seem to be “out-of-the-box” are estimated with zero efforts and are not accounted for in the overall workload or the budget. 


After understanding the Business’ requirements, perform a careful gap analysis and suitable estimations. Pay attention to features, which seem out-of-the box because they might require additional efforts. Be prepared to demonstrate the default features and point out possible adjustments. 

Related patterns

Client, hybris Functional ConsultantVirtual ProductPIM AwarenessGlossary,  Workshop, Domain MethodologyYoung Partner, Platform Expectations, System Actor Inventory, UED planning, Project Estimations, Business User Enablement, Internationalization

A big motivator for the Business Client to decide on purchasing software is the benefits, which they acquire. Mapping Client’s requirements to the capabilities of the software is an important exercise, which influences the outcome of the acquisition.

On average, during the initial presales rounds, our Clients are happy to realize that the hybris Suite is capable of covering – as out-of-the-box – around 60-70% of their requirements.

This is an indicator, which we achieve by a thorough Gap Analysis. The higher this percentage is, the more convinced the Client becomes in their purchasing decision.


Before and during the project, a Consultant should be able to qualify the gap between desired functionality and the default hybris offering.

Having in mind that even the most trivial hybris feature might require simple label change or translation, a minor tweak, a deployment step or validation job – the effort around all that is not nil.

Here are few examples from our projects:

  • Managing user roles in hybris is a core platform feature. Nevertheless, exploiting that feature requires the creation of client-specific user roles, before using them. After their creation, the user roles need to be associated with access privileges. It comes handy also to create one or two default users, to validate the desired user roles, as explained in the pattern System Actor Inventory.
  • Supporting catalogs and categories in hybris does not mean that the platform “knows” about the Client’s specific categories; someone must create or import them, give them names, adjust attributes, localize, link to Products, define synchronization rules, and so on.
  • Having a media as a product feature requires somebody to make this media available or upload it in the system, on the first place. Thus, that would require using an automatic import of media or a manual process, which, in turn, demands analysis and realization.
  • Internationalization, which is the foundation for multi-national sites, is a standard platform mega-feature. However, before benefiting from it, the team should define languages, study number- and metric formats, define currencies and locales, link catalogs to web sites, and so on...

And these seemingly innocent changes still require certain efforts and time to accomplish, not to mention the analysis and discussions around.


Therefore, if you need to estimate 10 such features, consider that 10 times (almost) zero is not always a zero.

Gap analysis is not only a “one-off” effort. Rather, it is a continuous exercise, because - in the lifecycle of a project - requirements change and evolve. Thus, remaining agile upon change, we should be prepared to re-do the gap analysis when needed. Moreover, we often advice the Client to remain close to the default behavior of the hybris Suite in order to fully benefit from the power of the hybris software. 


Adjust the Expectations

During the gap analysis, justifying the effort workload is essential for gaining the trust of the Business Client. Therefore, next to the gap analysis, demonstrate the default capabilities of the platform and identify possible modifications.

As with the other project challenges, understanding the meaning of "out-of-the-box" also affects the expectations of the Client: the “out-of-the-box” discussion often comes to light when the business users expects to use the “default” features “now” and “immediately”. To cope with this misbelief, as a Consulting party, make sure you explain what “default” really means through your estimations and client-enablement discussions.

Usually, in early Workshops with the business teams, we demonstrate default hybris installation and have a healthy discussion about standard offering vs. desired functionality.

Note that this demo is different than the demo the Client normally follows during the sales phase – because it links directly to Client’s own business case and specific requirements. We use this approach to go beyond the demo basics and discuss further details. After a couple of sessions, the business people are well aware of what is “default”. 


Further on this topic, managing the Platform Expectations of the Client is the obvious answer, but this is not necessarily an easy task – particularly, if the Client is led to believe (from their own research into hybris) that the functionality should be out of the box and cost-free.

The Client would well consider the hybris Company as “The” authority on the issue. Hence, by giving out a different message, as a Consultant, you may be risking your own credibility – the Client may wonder if it is a trick to get more budget out of them, or doubt your competence and suspect that the real issue is a lack of expertise on your side.

Well, this topic is a real challenge, due to its delicateness: on one hand you have the hybris Suite’s release notes about what is out-of-the-box, on the other hand, as a skilled hybris Practitioner, you have the expertise (and experience) that particular features still require efforts.

Therefore, consider approaching this scenario as follows: 

Make an open discussion with the client, explaining why you consider that even some default features demand efforts. In complement to your valid explanations, this approach actually proves your knowledge in hybris and further shows how Business’ requirements can be linked with hybris features.
After making your estimations, engage hybris Company to validate them – this approach has been used in several occasions, when the client has been in doubt about the estimated efforts. That also invites hybris to recognize the proposed efforts and confirm them. 

In all cases, regardless of the approach, the formula is: stay transparent and honest – this will gain you more credibility and respect than anything else! 


  Continue reading:

 Thank you for reading. Let us know how you liked it ...  



Total votes: 0