posted 8 Apr 2005 in Volume 1 Issue 9
Writing a statement of requirements
At the heart of any software-procurement process is the development of a statement of requirements (SoR). By Martin White
Organisations use a variety of different designations for writing a statement of requirements, including a request for proposal (RFP), an invitation to tender (ITT) or a functional specification. In essence, an SoR is a document that outlines the business objectives for the CMS that can be used to evaluate the technology options and support the vendor-selection process.
Despite the current level of interest in content management, the installed base of CMS applications is still quite low, compared with, for example, financial applications and HR applications. As a result, few IT managers have been involved with the specification and implementation of a CMS and may well use as a boiler plate a specification that might have been written previously for the procurement of a financial system or a business-reporting system. This can be dangerous for a number of reasons and I will use a financial-reporting system as an example:
There is usually a financial system in place, so the new software will be a replacement rather than providing totally new functionality;
If the implementation of the replacement system is delayed the organisation could probably manage;
The transaction volumes are usually well understood (such as the number of posts to the purchase ledger every month);
The software is deeply embedded in existing and well established workflows;
The systems are based on highly structured data sets (invoices, for example) that have known file sizes, are consistently presented and, if required, could have their format changed without the knowledge of non-finance department staff.
The direct impact on the company outside of the specific departments ranges from small to invisible;
Relatively little software customisation is required, though there may be some substantial integration issues with other applications such as payroll;
There is a reasonable body of knowledge on what functionality is required, as both IT and business managers will have undertaken such a procurement in the past;
None of these apply to CMS procurement and are unlikely to for a number of years. This is obvious when talking to vendors who have received yet another incomprehensible document on which they are requested to submit a proposal within ten working days. The vendor then has to decide how much effort they put into pre-sales consultancy, with the danger that the organisation then rewrites the SoR and sends it to all their competitors.
The fundamental problem is that too many SoRs are written in terms of what functionality is required, rather than what the CMS is supposed to achieve. Organisations then expect the vendor to tick the boxes so that they can count the number of ticks and award the contract to the vendor with the greatest number of ticks. This assumes that both the functionalities are relevant and that the vendor understands the description of the functionality. One SoR that I was involved with had a specific section on search requirements, which included the requirement to be able to undertake what was described as a fielded search. The intention of the requirement, which could have been worded more clearly, was that the search engine could be asked (subject to metadata tagging) to look for the search terms in just the title, or the abstract, or the text of the document. One vendor replied that they did have a field implementation team that could install the search software!
Probably a record was a SoR that had over 200 functionality requirements, requiring the vendor to assess whether they fully met, partially met or failed to meet the requirements. The procurement process wasted a year and ended as a complete disaster, despite the fact that the need for a CMS was business critical.
Ironically, the situation is exacerbated by the existence of two very good publications that comprehensively list selection criteria, the Content Management Bible, by Bob Boiko, and CMS Watch.
The extent to which organisations can get it wrong is illustrated by a pre-qualification document circulated in early 2004 by an academic organisation that set out nearly 140 questions that they expected the vendor to answer in some detail. Figure 1 provides some examples and should act as a warning to others.
The overriding issue here is that unless the project is substantial, vendors will not take the time to respond and may even cut and paste the responses from other documents. Second, most of the leading vendors will be able to provide plausible answers to most questions, so the responses will not help the organisation select a vendor.
The objectives of an SoR
The primary objective of an SoR is to set out what the organisation wants to achieve through the effective management of content. This in itself is difficult if there is no business case that has been prepared and, in general, if there is no business case then it is pointless moving straight to an SoR. It is important to note that a simplistic checklist will not cover all of the functionalities of even low-end CMS products, nor will it reveal the benefits that a particular vendor can offer by combining several functionalities.
An SoR is thus of fundamental importance in either selecting a vendor or providing the basis for the procurement and development of an open-source solution, or even an in-house solution. Indeed, the less ‘productised’ the CMS product is, so that it is in effect just a toolkit, the greater the care needs to be taken in defining what the system has to enable and deliver.
Included in an SoR should be the core criteria for selection of the vendor and an outline of any specific implementation issues that could affect the choice of vendor.
The structure of an SoR
Some organisations have agreed formats for an SoR and thought will need to be given at the outset as to whether this format, either in part or in total, is appropriate to the purpose of selecting a CMS. The format that I have set out below is one that I have used on a number of occasions. In the end, the exact structure does not matter so long as all the information that is required by a vendor or a software house is presented clearly and in appropriate depth.
a) Executive summary
Given the length and complexity of many SoRs, it is useful both to the organisation and the vendor to provide a one or two-page summary of the key elements. The discipline that this requires can often highlight problems in the body of the SoR.
b) Business case
Since there will have been a business case for the selection and implementation of the CMS it is useful to present it in the SoR. It should highlight the basis on which the organisation decided to move to the publication of an SoR, so the vendor has a sense of the expectations of the organisation at the outset and can form a view as to whether these expectations can be met by any CMS software, let alone its particular project.
c) Content-enabled business processes
This section should outline in detail the core content-enabled business processes set out in principle in the business case. This might include the supporting documentation for conferences, adding project summaries to an intranet project database or providing non-executive directors with information on board meetings. It is useful to quantify these descriptions, which could include the number of documents or the size of a typical project summary. Providing examples of the documents or content elements can be valuable, even if they are mocked up for reasons of confidentiality. An indication of the workflow inherent in these processes should be provided, even if not in diagrammatic form. The most important element is how, and by whom, content is added to the current website or intranet, and ideally how the organisation wants this to change with a CMS.
As well as quantifying the documents, the number of people involved in content contribution and the use of content, especially in an intranet environment, should be set out as this could have a major impact on the total cost of implementation.
d) Implementation issues
All implementation requirements should be set out at this stage, highlighting any specific timelines that need to be met. An example of this is a
It also worth stating how the roll out would ideally be managed. Many vendors now offer a ‘quick start’ approach to reduce the initial implementation time, and being explicit in the SOR about implementation issues will assist them in deciding on whether a quick-start approach is appropriate. Vendors will have much more implementation experience than any organisation and tapping into this experience could be very valuable, rather than presenting a set of milestones based on a rather arbitrary view of a date for full implementation.
e) ICT platform architecture
The information and communications technology (ICT) architecture of an organisation is a strategic issue, setting out the desktop environment, the network and server architecture, the preferred database environment and any remote-access issues. Server architecture could have an impact on licence costs for some vendors. An important issue to consider is whether a client-based system can be used. Some organisations are happy with a client-based approach, whereas others, particularly in high-security situations prefer desktops with minimal features.
f) Selection criteria
The selection-criteria component of an SoR is often the most problematic. An intense focus on functionality often results in a long list of functional requirements. The problem with this approach is that different vendors may have different approaches to solving the same problem, so opting for a tick-box approach and totalling up the number of ticks is not necessarily indicative of a vendor’s true capabilities.
Specific requirements, such as the ability to preview a page without checking the content back into the system, should be clearly set out with supporting reasons for inclusion. This will provide vendors with additional problem solving opportunities and an opportunity to showcase their understanding of the stated requirements. In the event that a case cannot be made for the inclusion of specific functionality, then the question needs to be asked whether it is important to the selection process.
The selection criteria should cover:
It is important to remember that an SoR is there to assist both client and vendor. If a vendor is unimpressed with a prospective client’s SoR and business case for a CMS, then it may decide not to bid for the work and pursue more attractive prospects. This happened in the case of a university in the UK which, to its surprise, found that a number of major vendors decided that the risk to their reputation was greater than the possible profit margin. Bad news travels fast and no CMS vendor wants to be in the position of being seen as the cause of a poor implementation when the fault lies with the expectations of the client.
g) Selection process
The timetable for the selection process should be clearly set out, covering:
Date for a meeting with prospective vendors;
Date for receipt of proposals;
Date when vendors will be informed as to whether they will be shortlisted;
Date(s) when the vendors will be asked to present their proposals;
Date when a decision will be made on a preferred vendor;
Date when the organisation could be in a position to support a scoping study;
Date by when the organisation intends to confirm the vendor.
This process requires careful forward planning, particularly if the tender has to go through public procurement. The purpose of a tender meeting is to give vendors an opportunity to clarify any issues in both an open meeting and in one-to-one meetings with project staff. It also gives vendors notice as to who else is in the frame, and it has been known for vendors to drop out of the running when they see the nature of the competition. However, this might not be to the advantage of the organisation and the reasons for the opt-out should always be explored. Any issues that come up in the one-to-one meetings that are of generic value to all the vendors should be circulated. The permission of the vendor that raised the issue should always be sought, although the decision of the project board should be final.
h) Background information
It is important to request background information that is relevant to both client and vendor. The key issues to explore are:
The legal situation in the country of purchase;
Number of staff with the expertise of the product to be offered;
The current installed base;
The ratio between licence fees and consulting.
Determining the legal situation can be important, as the local office may well be a branch or an agency and not wholly owned by the vendor. In the case of many public-sector organisations, there may be a requirement to place business with a company registered in the country concerned.
Another important issue to explore is the extent to which the vendor uses third-party software. This is common with workflow software (Microsoft Visio is a favourite), text-editors (Ektron, for an example) or search software (Verity or Convera). The vendor will not be in full control of these relationships and a list of third-party software products that are embedded in the CMS product can be quite revealing.
i) Project-management methodology
Effective project management is so important in the implementation phase, and a check at this stage can provide useful insights into how effectively the project will be managed, particularly if a systems integrator is involved. A key component of the methodology should be the skills and contribution that the vendor expects from the client.
j) Reference sites
Vendors will have reference sites that they will point clients to, which are invariably model examples of CMS implementations. It is worth pushing the vendor on the relevance of the reference site to your specific proposal, and to ensure that you are not presented with
a cut-and-paste job from another proposal. Make sure that the implementation is of the version of the software you will be buying, unless you want to be at the leading edge.
k) Staff profiles
The implementation will be carried out by people, not computers, so it is valuable to garner the thoughts of staff who may be involved in the project, and to ascertain the turnover in development and support staff over the past year.
Managing the response
The organisation needs to appoint a member of the team to deal with queries from vendors. It is useful to record such queries and to note how they were resolved. Many organisations circulate corrections and clarifications to an SoR based on this feedback. It is important to be even handed in the relationship with prospective vendors to avoid suggestions of improper behaviour further down the line.
Each vendor will respond to an SoR differently, often supplying copious amounts of background information on how wonderful the company is. Of course, you will only be interested in knowledge that is relevant to you and not just a list of every customer for the past three years. It may be a challenge to get the vendors to present their responses in a stipulated format, but it can be beneficial to ask them to send the responses in both electronic and hard-copy formats.
An executive summary of the response is also useful, and this should be cross-referenced with the main document. This will give the selection panel a concise overview of the proposal and provide an overview of the key features once the selection process gets underway.
A useful tip if the document is in Microsoft Word is to turn on track changes and/or to look at the properties box to see if the tender is in fact just a modified version of one that was presented to another organisation.