The Right Concept

Meike Jung's picture
Blogpost by: Meike Jung

It all depends on proper planning: from meeting the budget to deciding for the appropriate content management system.

Compare a web project to the building of a house: You won‘t be asking the architect without further explanation: How much does a house cost?

Also, you won‘t ask him to make drafts for a spacious luxury villa, if all you can afford is a modest terraced house really. You are wondering who would come up with such ideas? - Any service provider in this field will confirm: Such expectations are very common among clients. To be fair one should add: because they don‘t know any better.

Of course it is legitimate that for the time being you do not know yet to which price categories CMS projects belong to. Two pieces of advice that you should stick to:

  • Set yourself a realistic budget.
  • Get professional advice when drafting the concept.
  • And don‘t be all too distrustful.

The budget

The budget is the most important tool for consultancy since it narrows down the possibilities. Maybe you will miss out on the opportunity to find out everything that can possibly be done with a content management system, but you will also spare yourself much disappointment because your wish list was too expensive.

It is not too rare that clients show an inclination to not talk about their budget – apparently out of fear that it would actually be spent although one could get the desired scope of functionalities for less than that.

Far more often, though, it is the case that service providers – without knowing the budget – spent a lot of time and effort on an estimate that does not fit the client‘s expectations.

Typical CMS projects cost between a few thousand to several hundred thousand Euro. It really all depends whether you are asking for a small cottage or a hotel complex. 

Concept development as professional service

An independent consultant can also help you in budget-related matter, but most importantly, he or she will assist you in terms of developing a reasonable scale for your requirements. Just like with any architect, you will need to pay for their service, but it is worth the investment.

You could very well hire an agency that is experienced in implementing CMS projects. Simply make clear that you intend to commission someone else with the actual implementation. In this way there will be no conflict of interest. Your consultant will not try to ‚talk you into‘ something, but work with you on a concept that fits your needs.

The requirements are defined in a specification sheet – a document, that will serve as a basis when requesting estimates from vendors.

Standard functions do not require epic descriptions, but functions that could be interpreted differently in terms of scope are defined precisely. When your architect is asking estimates for windows, he includes measurements and points out a tilt functionality.

“If all you have is a hammer, everything looks like a nail.”

It is helpful, if your consultant is familiar with different CMS. Each system has different strengths and weaknesses, and a feature that one system offers ‚out of the box‘, could take considerable programming work for another. It is therefore important that an expert eye casts over the ‚bigger picture‘: What is crucial in the beginning, and which further steps are predictable? For example, in the beginning only one editor will be working with your CMS, but in two years different departments should be able to edit their own (and only their own) content. Or, are you giving your clients password-protected access to documents? It would be good if, in two years, you will still be able to use the same content management system. 

Comparable estimates

It is ancient wisdom that one should not compare apples and oranges. Well, it all depends. Maybe all you like to do is eat some fruit – then go ahead and buy whatever is on discount. Or, sticking with our architecture example, you do not mind whether the roof windows can be opened.

With regard to content management systems it means: They all perform the basic functionalities. Users can log in and create content, change and delete it. Images and links can be inserted, site structures are built semantically correct and meta data can be added. None of them is imposing a static design or the labeling of the menu items.

Another ancient wisdom says: The devil is in the detail. If the requirement is that ‚users should be able to register‘, every vendor will say ‚no problem‘. One is allowed to interpret it in such a way that editors can register at the backend (a basic function of every CMS), another understanding could be that site visitors will be able to register and create and edit a ‚profile‘ about themselves. Hardly anyone at this point will inquire whether a registered user should be identified as the creator of his or her content and what should happen to this content in case the user will delete the account later on.

Here are several other examples of requirements that often lead to misunderstandings and how such requirements can be specified in order to get comparable estimates:

Vague More precise
‘Search function‘

The search function should meet the following requirements:

  • List content results only once, even if the term shows up multiple times in a piece of content
  • It should be possible to exclude individual content categories from the search (e.g. user profiles)
  • Advanced search: It should be possible to limit the search to certain content categories (information, catalogue, contact person)
  • Search results: results should be sorted according to content categories marked by corresponding headlines
  • Relevance ranking of search results should be displayed in per cent. Ranking is done according to relevance (descending) within categories (see above)
‘Slideshows’

Slideshow:

Any number of images should be assigned to a ‘topic‘ (e.g. an event). Images grouped in such a way should be automatically displayed as a slideshow and the slideshow should be placable on various pages.

The slideshow has a fixed size of 800x600 pixels. Other formats should be scaled to that size while maintaining their proportion.

Displayed elements:

  • Image, caption, photographer, CC license
  • Navigation buttons: next/back, start, pause
  • One button per image (thumbnail or circle, active one stands out) for direct navigation (arrows to skim through a large number of images)
‘Publishing process‘

Publishing workflow:

Content is published following the four-eyes principle. A user with the role ‚editor‘ can save content only as a draft and submit it for ‘approval‘, but not publish. A user with the role ‚editor-in-chief‘ has the same permissions, but, in addition, is able to publish all content – or disapprove it with an explanation. ‚Editorial‘ then receives a notification (in the backend or via E-mail) about the disapproval.

Exception: Job offers can be published without approval.

‘Shop function for publications‘

Order function for publications:

  • For the time being orders shall be made exclusively ‚on account‘ and via e-mail to shop@ourcompany.com. A complete shop system is not intended.
  • Each publication can be added to the cart from the overview page as well as from the full content page. Feedback is displayed, but the user stays on the current page.
  • The cart is accessible through a well-visible link. The subtotal is displayed above the link.
  • While viewing the shopping cart, users can delete publications or change the quantity for each one. Display of prices, total amounts and VAT, cancellation policy etc., are in accordance with legal provisions (adaptable).

Billing and shipping address information can differ from each other. Orders received from other countries have to include their sales tax identification number.

‘Responsive design‘

Responsive design:

See attached screen design. There should be 3 breakpoints.

Please note: the mobile version does not display all content. The menu unfolds via a button.

With regard to the latter, one should add, that it does not make much sense to leave a service provider on their own, stating ‘responsive (or adaptive) design’ as a requirement. You do not want to imagine all the creative arguments proving that this requirement is met once someone attempts to come up with a competitive estimate. On the other hand you do not want to imagine how expensive it can get if a designer feels free to be really creative.

Once you have (if possible) concrete requirements you are equipped to ask for estimates from different service providers (common practice are 3, more than 5 different providers would be unfair and harm the economy). When evaluating the estimates you can refer to your consultant for advice. Unless personal trust between the two of you got this good that all of a sudden you are requesting an estimate from your consultant. Which would be similar to the architect who also takes over the site supervision: trust provides the best basis.

Tagging

Blog relation: 

Thanks to our supporters