Engineer and machinery from Shutterstock
Experience has shown that the most effective tenders for a content management system (CMS) focus on the business requirements, not implementation details.
Unfortunately, too many tenders in the past have become caught up in the technology aspects of the systems. This generates a number of problems:
- While many requirements are included, they still fail to encompass the actual business needs for the CMS.
- The number of potential products is substantially reduced, due to them not following the technical details outlined in the tender.
- This invariably eliminates some products that are capable of meeting the business needs, perhaps at a lower cost.
- The opportunity to innovate the technology solution is missed.
In short, by focusing on the technology aspects, these tenders often fail to select the best product, and don’t deliver the desired business benefits.
For this reason, we encourage those developing tenders to concentrate on the business requirements, and minimise the technical details.
That being said, there is a legitimate need to specify specific technology issues. This briefing presents some guidelines for doing so, in a way that will generate the best outcomes.
Many organisations have a single coherent IT platform, such as Microsoft, Linux or Oracle. If this is the case, it should be specified as a precondition in the tender.
The same goes for the corporate-wide database standard, and it is reasonable to expect that the CMS will use this database to store its content repository.
Note, however, that these aspects should only be specified if there is a clear corporate standard or direction. If this is not the case, the purchase of the CMS presents the opportunity to innovate, or at least explore different technology options.
‘Black box’ solutions
To most practical intents, content management systems should be treated as ‘black box’ systems, where the internal details are irrelevant, as long as the business requirements are met.
For this reason, arbitrary restrictions on the implementation of the CMS should be avoided, without a clear business reason.
For example, “Must be implemented using .NET” should not be used in most tenders. Even the enterprise-scale CMSs are typically implemented in a mix of languages internally, while still delivering considerable functionality.
Integrating with other systems
Where the technology does become relevant is when the CMS is integrated with other business systems.
The key thing to avoid is specifying requirements such as “the CMS should integrate with existing systems”. (There is only one answer a vendor can sensibly give to this question: “yes”.)
If there are systems that must integrate with the CMS, clearly specify what these are, what information will be shared, and via what protocols.
Presenting this as a diagram is often an effective way of presenting the overall business environment, and where the CMS will fit within it.
If you have a large number of in-house programmers skilled in a particular development language, it may be meaningful to select a CMS that uses the same language. This will make it easier to customise and maintain the system.
Be aware, though, that there will be a steep learning curve for the developers, as every CMS is very different internally. Knowing the right language is only a small advantage, and the easiest part to learn.
While a CMS tender should focus on business requirements, technology issues will need to be specified, but in a way that ensures the best system is not knocked out of the running.