Organisations often make the selection of a CMS much harder than it needs to be. They do this by running into common pitfalls that impact not just on the selection process, but on the overall success of the CMS project. Over the past ten years, we have worked with many organisations on content management systems, and have seen a huge number of tenders released to the marketplace. Across these projects, the same issues are seen again and again. These most often relate to how the requirements are documented, or how the overall tender is structured. They may also arise from
Perhaps the single greatest pleasure of the work that we do is the opportunity to conduct "needs analysis" that involves getting out into the front-line environment of organisations. Following an "ethnographic" approach, we're able to spend time with the staff who do the actual work, building an understanding of their real needs and issues. While we use a range of techniques (such as one-on-one interviews, workplace observation, contextual inquiry), the basic approach is incredibly simple. At its heart, it just involves going out with eyes and ears open, asking naive questions, and getting amazing answers. Front-line environments are endlessly fascinating,
This keeps coming up: one of the benefits that is sold for portals is that users can "personalise" (or tailor) what content and functionality is displayed on their home page. The problem is that users don't personalise, despite the hopes (and optimism) of the IT team. Now, I "know" that the real-life statistic is that only 5-10% of users personalise. This means that 90-95% of staff will leave the portal as-is, leaving the portal owners with the same design, usability and IA challenges they had with the intranet. The problem is that I don't have an official source for this
Today I completed the draft of what will be our next report: the 6x2 methodology for intranet planning. This is something that I've hinted at for the last few months, but I can finally unveil what it actually consists of: Step 1: Give the intranet a version number Step 2: Scope the first six months Step 3: Determine a new version number Step 4: Review the in-scope list Step 5: Create a detailed project plan Step 6: Sketch out the following six months Step 7: Create an executive briefing Step 8: Create an 'intranet concept' Step 9: Implement the six
The design of intranets can be pretty standard, with many sites following the same basic layout. The diagram above shows a typical intranet page, consisting of the following elements: page header, containing global navigation left-hand navigation, containing local navigation body of the page page footer This is all pretty standard, nothing that anyone wouldn't immediate recognise. By default, new intranet designs tend to automatically follow this model. All that being said, I'm nonetheless starting to wonder: is left-hand navigation evil? The good Left-hand navigation is obviously not inherently evil. There is a clear need to help users to navigate their
There’s been a bit of discussion recently about the central role of the WYSIWYG editor in a CMS solution. Considering that the primary purpose of a web content management system …
It has to stop. The current metaphor of the intranet as an "internal website for staff" is crippling us. This metaphor is a direct cause of our unhealthy focus on just the usability, information architecture and content of the "site". We spend endless amount of time working on maintaining intranets, and yet intranets today are little different from the way they were ten years ago. Along the way, the road is littered with burnt out intranet teams, wearied by the struggle to get organisations to finally "recognise the value of the intranet". Instead of the "intranet as website" metaphor, we
There are two major elements to most web redevelopment projects: the redesign of the existing site, and the selection of a new (or replacement) content management system (CMS). These two elements reflect the underlying issues that typically drive web projects: the problems with the structure and content of the published site, and issues with the management and publishing of the site. The temptation can be to select a single provider to deliver both the redesign of the site and the underlying CMS. This would, however, be a mistake. Instead, organisations are almost always better served by separating out the design
Many intranet teams see themselves as battling resistance to change when attempting to grow the intranet or deliver new functionality. The challenge is perceived as overcoming these barriers to a successful intranet. In practice, though, the real enemy of intranets is apathy. While at some level the organisation (and staff) recognise the need for an intranet, it is never an immediate enough issue to warrant significant resources. Without a sense of urgency or a real mandate, intranet teams often limp along, targeting individual needs but never capturing the interest of the organisation as a whole. This briefing identifies the impact
The intranet homepage can be the most coveted piece of online real estate in your organisation. Everyone will have their own firm view as to how the homepage should be used to drive organisational imperatives. Managing these competing priorities is difficult and intranet managers are often placed in the position of defending the homepage from its own popularity, In doing so they are ensuring that it is able to perform its primary task of directing users to the material that they require to perform their day-to-day jobs. This is often an unpopular stance to take and is often assumed with