Flexibility and standardization: friends or foes?

Flexibility and standardization: friends or foes?

Scrum seems to be the magic word for a lot of projects. The underlying thought is one of flexibility, to adapt to advancing insights and to deliver an optimized product at minimal cost. Furthermore, there’s a demand for standardization. In many situations, this call is driven by a need to realize the project quickly, at an acceptable cost, without too many issues.

The question is: can standardization and flexibility go hand in hand?

I would like to explain this by comparing it to the development of a car. During the development of a car, you could assume maximum flexibility, which means all parts are produced by the factory itself. But that doesn’t only cost a lot of time and money, it also increases the chance of problems occuring. Another option is the standard car, which doesn’t allow for customization. However, daily practice is to opt for a ‘base’-model, whereby customization is possible through variation of the car parts. This only works when the parts are tailored to fit properly. Imagine, for instance, choosing a different engine, only to notice all connectors are on the wrong side, or that the crankshaft turns the wrong way. Worst case scenario is that, after many modifications, you end up with a car that can drive at a high speed, but only backwards.

This comparison holds true for IT solutions too, it’s just a little less appealing. IT solutions can be just as flexible, while using standard parts. And it is of equal importance to properly tailor these components, in order to deliver not just the right functionality, but also to allow for the components to fit and work together.

Going back to the question of ‘flexibility and standardization: friends or foes?’

Flexibility and standardization can not only go hand in hand, but they can amplify each other, to deliver a better product quicker. It’s important, however, to adhere to the following conditions:

  • Have the right functionality in the right composition (functional decomposition)
  • Make sure the parts have a ‘common language’ and are tailored to fit together (reference architecture)

An example of this is ‘Programme Management for Non-Profit Cloud’, a solution developed by g-company. The general objective is to provide programme management for non-profit organizations. But there are many different non-profit organizations, with just as many different target demographics, focus points and ways of working. This means flexibility is needed here, too. However, this flexibility should be realized without the high costs of initial software-development, or the accompanying issues. ‘Programme Management for Non-Profit Cloud’ is made up of different modules, which focus on functional fields of attention, which can be combined to interact perfectly. Depending on the wishes of the organization, optional parts (modules) can be implemented as well.

Would you like to learn more about this subject? Be sure to contact

Gerard Gijsen

Salesforce Consultant
Gerard is part of the Salesforce Squad and has a role within g-company as a Salesforce Consultant.