Content Management

All of the prior project stages that commonly involve consultation and review of existing material have organized a folio that includes:

• a vision,
• a list of assets and resources that are needed to flesh out the vision,
• a strategic diagram of how those pieces work together and how they function,
• a list of team actors to fill those roles and the actions they take to create value, and
• a list of content that is ready for use, scheduled for upgrade or set aside.

With these things in place, we can talk about the Content Management aspect of the project, and this is where the technology pieces come in to play.

There are really two common approaches to the integration of technology to existing people and processes. Most technology adoption rests along the continuum of these two points of view.

On one end of the spectrum, there is the attitude that limiting and contouring technological implementation transforms business culture and that people’s behavior will adapt as new technology is brought into their routine. On the other end is the attitude that technology should bolster existing processes exclusively, and that we should have to change how we do things just because technology comes along.

There are positives and negatives to taking either approach too far. The content management platform that is used should be able to adapt to process and workflow for you and it should make resources available with a certain level of control.

When it comes to how we choose what designs or software to implement for a given solution, our preference is to use systems that are flexible in terms of information storage, but also allow restrictions to be put in place to prevent mistakes or distractions from hampering the effectiveness of the whole organization. When there is too little freedom to expand, personnel tend to bend the rules of what already exists in order to complete their work. When there is too much freedom or too many ways to do something, personnel get confused and require more oversight to give them the confidence they need to be able to complete their tasks correctly.

When it comes to picking out the right system, we take the following into account:

• familiarity with any of the platform choices
• technology skills in an office setting
• desktop tools commonly used daily
• access to more advanced writing, editing or drawing tools
• the size and scope of the project being managed
• access controls requirements for sensitive information
• editorial workflow roles and requirements

Here we start digging into how things are done now within your organization - what workflows may or may not yet formally exist, and what scale is the current project at.

Simple projects that are new may not need a full-scale content management deployment beyond the basics provided by many free website builders and monthly subscription services. Basic catalogs, menus and other relatively non-interactive plans do not require extensive or custom tools.

Interactive systems that connect various systems together or have complex data storage or workflow organizational needs will likely need something more fully developed. Here the feature requirements of the project will dictate which system we recommend or will use to build.

Regardless of the content management system being deployed, there are some things that should really be standard:

• it should be easy to enter data from desktop or mobile devices
• it should be possible to constrain how certain types of special information get entered in order to reduce errors and incomplete records
• it should be possible to restrict access to entering and modifying certain kinds of data for certain roles
• it should be possible to create drafts and revisions of information entered into the system, rather than force saved information to be exposed to the public immediately
• where necessary, it should be possible to develop content for an international audience with multiple language and locale support
• content should be extensible and have fluid organization so that expansions and design modifications can be implemented as the project grows or its needs change
• there should be contingency plans in place to be able to provide data recovery if errors are made or security incidents occur – whether internal or external to the organization

We’ve got our opinions as to what systems have worked well for our clients when it comes to fulfilling these needs. You can find them in our ‘Build With Us’ section of the website.

Last modified on Sep 3, 2023 (2 years ago)