Category Archives: James Robertson

Existentialnet

Posted on by David
1

James Robertson asks:

The time is right for us to stop focusing inwards on the management of the “intranet as website”, and to ask: what are we going to deliver to the organisation in the next six months?

Good question. A better question: What does the organization need to deliver in the next six months and how can the intranet be aligned to support those efforts?

Intranets will always be viewed as a commodity (low value) when all they focus on is the processing of mundane tasks. There is huge opportunity for your intranet to help make a breakthrough in achieving your organizational goals. It will only happen when intranet managers, consultants and advisors focus on achieving the goals of the organization first and foremost.

I guarantee that you will get more resources and attention if your intranet makes tangible contributions to achieving your organization’s business goals. Policies and time sheet applications will not impress senior executives.

The Knowledge Sharing Toolkit

Posted on by David
Reply

David Bartholomew has released a Knowledge Sharing Toolkit that he has developed over the past 2 years.

The ‘Knowledge Sharing Toolkit’ is the result of a two-year DTI-funded project carried out by innovation consultancy David Bartholomew Associates (DBA) and nine of the UK’s leading architectural and engineering practices – Aedas, Arup, Broadway Malyan, Buro Happold, Edward Cullinan Architects, Feilden Clegg Bradley, Penoyre & Prasad, Whitby Bird and WSP.

A concise 49 page how-to manual accompanied by nine detailed case studies, the Toolkit shows building design practices how to develop a knowledge strategy to support their business objectives, and explains the main tools and techniques for learning and sharing knowledge, and how to use them.

I haven’t had a chance to read it yet (just spotted it today) but thought I would go ahead and share the link for those of you interested in facilitating knowledge sharing.

(Via James Robertson.)

Content Management Requirements Toolkit 2.0

Posted on by David

James Robertson has announced the release of the second version of his Content Management Requirements Toolkit:

The first version of the Toolkit has been used by organisations the world over, from Fortune 500 companies to government agencies and small businesses. This new version builds upon these successes, and delivers even greater value.

I highly recommend picking up this report if you are embarking upon a CMS selection. It was very helpful to us when we conducted our last CMS selection.

Column Two: CMS Myth #1: Installing a CMS must be hard

Posted on by David

James Robertson takes a stab at busting some CMS myths. First up: Installing a CMS must be hard.

Installing the CMS software can be easy. It should be easy. If isn’t easy, ask why.

During our last CMS selection we required that our web admin be given demos to install from the finalists in our list. That ended up ruling out a couple of companies who couldn’t provide installable code without sending their own engineer over to do it.

Our theory was that if the company had not thought about how to make the initial installation easy then there were probably lots of other areas that had not had proper attention either. I couldn’t find a specific post on his site, but I’m pretty sure I picked up the idea of an effective installer as a sign of quality from reading Joel on Software.

Successfully deploying a content management system

Posted on by David

James Robertson has posted another great article on content management systems: Successfully deploying a content management system. This quote sums up what the piece covers:

Our experience has shown that there are five key elements that must be addressed in a content management project:

  • strategy
  • change & communications
  • content
  • design
  • technology

The following sections discuss each of these five key elements, and give some examples of activities that should be considered.

Recommended reading.

The Role of Technology in a CMS Selection Process

Posted on by David

James Robertson has published a briefing on Specifying technology in a CMS tender. I agree with his overall premise but have a few comments on some of the specifics. First a quote:

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.

The main point, that the technology is irrelevant if you don’t have criteria that will support your overall business objectives, is right on the money. Assuming you have that part down, I think it is very important to play to your IT strengths if at all possible.

One factor not mentioned specifically in the article is that CMS’ are typically high-maintenance beasts (in my experience). If it is running on a platform for which you already have experienced admins, your life will be much easier. There are a lot of not very well documented tweaks and tricks to keep servers and systems running optimally. You’ll need knowledgable admins for a CMS that bears significant load.

Also, staff expertise in the CMS coding language is more important than given here, I think. Without it you are completely at the mercy of contractors to make modifications, no matter how minor. If you have one or more staff who know the language you can make the minor adjustments that tend to come up pretty frequently without having to spend consulting money nor take the time to secure the resources. You can be more nimble by making those small adjustments yourself and save the cash for major development and integration projects.

Batch vs. Dynamic Publishing

Posted on by David

James Robertson has published a concise review of the pros and cons of dynamic vs. batch publishing in web content management systems. He also covers the hybrid of the two, which is what we now have in place with our systems at work.

The major con under the dynamic system that I have experienced directly is the server load issue. Dynamic systems cannot scale up for additional traffic as efficiently as batch or hybrid systems. Authoring activities are very processor and database intensive operations. Mix a few active editors along with heavy end user traffic and your server may quickly succumb.

About 18 months ago, we were in the unenviable situation of limiting editing activities to a small number of staff during low-traffic time periods. Without those restrictions our site constantly crashed and/or timed-out due to the unmanageable load of end users and editors hitting a single server. Not a popular measure with staff, to say the least. The dynamic CMS we were using at the time eventually came out with an update that allowed us to move to the hybrid approach and lift our editing restrictions. Moving authoring to a separate server dramatically improved the stability of our production web site.

Article on Basic Definition of CMS

Posted on by David

James Robertson has published an article that provides a concise and basic introduction to content management systems. This is a great piece to refer to management and others who you need to get up to speed on what exactly a CMS is and the general business problems to which it can be applied.

So, what is a CMS?

A content management system (CMS) is critical to the success of almost every website and intranet, and yet many organisations are not familiar with this technology.

So, while we have written many articles on a range of specific CMS issues and strategies, we now take a step back to answer the question: what is a content management system?

In this article we will focus on web content management, and will only touch upon broader content issues at the end of the document.

Finding the Knowledge in a CMS

Posted on by David

James Robertson: Where is the knowledge in a CMS?

Interestingly, the knowledge is not in the content itself. Instead, it’s in the processes and practices that surround a content management system.

This article puts forth the idea that the configuration and design for a content management system deployment contains valuable knowledge, more so than the raw content that is loaded into it. In order to deploy a complex system like this you have to learn about how your organization operates, what it is trying to achieve, and collaborate to develop a solution to support those efforts. Very valuable knowledge that should be preserved.

The lesson I take away from this: document your CMS deployment processes and research and archive it for reading later by those who follow you (or yourself five years later). You need to capture the ‘why’s of how you designed things since they may not be obvious to someone maintaining or updating the system who was not involved in the original project. A project blog would do this nicely.