A A A

Archive for the 'web strategy' Category

CMS Planning and Prioritising

By Dan Jackson, on 5 July 2013

Being somewhat shamefaced that we haven’t blogged for 15 months, it’s tempting to start with a list of excuses for the pregnant pause (big organisational changes, workload – the usual suspects.) However, instead of being introspective & retrospective, this post is about looking forward to where we want to be – and we’re certainly doing a lot to get there; constructing a digital strategy and the governance framework that needs to go with it; thinking about how to position our Web and Mobile Services team as a ‘Digital Agency for UCL’; working with Mark Boulton Design on a common Design Language that will enable us to develop visually consistent, responsive websites for the University; undertaking a rigorous process of service improvement.

Our CMS review process

Another critical activity that’s well underway is a review of our Content Management System (CMS). We know that the performance and scalability of our existing CMS is a concern, and that we’ve got work to do in order to get it up-to-date and make the underlying server and application stack more performant and resilient. From a recent survey of our CMS users, we also know that the content editing process is often a frustrating one; performance issues and  poor usability are frequent causes for complaint.

More strategically, however, we’ve also been thinking about what functional and non-functional capabilities we want from a CMS, and how to enable ourselves to be future friendly; after all, it’s impossible to establish whether our current CMS is fit for purpose until we we know what we want it to do – both now, and in the future.

CMS planning workshop

To assist us in this process of CMS analysis, and to help validate our decisions, we’re working with the digital consultants and CMS experts from J.Boye. Over the summer we’ll be eliciting the opinions of a representative pool of UCL’s content editors, but we kicked off our investigations this week with a workshop for senior stakeholders from Information Services and Communications & Marketing to review CMS best practices and trends, and to define and prioritise our digital / CMS activities with some MoSCow analysis.



Our priorities

CMS worksop: prioritising

So what did we conclude?At the top of our prioritised  list of “must haves” was a mix of activities that must happen in order to support our process of change and improvement, and a set of features that our CMS must offer as core capabilities:

  1. Digital Strategy & Governance (inc. senior management understanding of importance, central web funding)
  2. UX (optimal UX for all user groups, intuitive CMS editing interface)
  3. Mobile (responsive design, mobile first)
  4. Performance (inc. need to define performance budget & establish fit-for-purpose server architecture)
  5. Content & Metadata (structured for re-use, social/CMS integration)
  6. Compliance with corporate branding
  7. Security
  8. Actionable measurability
  9. CMS flexibility & extensibility
  10. System / data integration & interoperability

CMS worksop: prioritisingMeanwhile, our “should haves” and “could haves” listed those items that we felt we should strive for, but that either may not be possible in the short term, or were not perceived to be core capabilities for a CMS:

  1. One UCL website with a global IA
  2. Standardisation of design & development processes / assets
  3. Focus on search
  4. Maturity of CMS vendor
  5. Controlled flexibility (controlled by Web & Mobile Services, flexible for editors)
  6. Capable of being UCL’s single CMS
  7. Skilled, professional content editors (federated model)
  8. Integrated, central DAM (digital asset management) system
  9. Simple, usable, integrated authentication
  10. CMS technology appropriate to UCL
  11. Scalable solution
  12. URL namespace defined
  13. Content review capability

It was a good, well facilitated session (thanks Brian), and was really encouraging to see Directors & Heads working together to ponder on our CMS requirements and to deliberate on, and help prioritise, those tasks and issues at the heart of our web service improvement plans. We’ll be using this information to inform our Digital Strategy and CMS decision-making processes – watch this space.

Fight the system!

By Neil Martin, on 30 July 2010

Earlier this week a few of the Web Services team ‘attended’ a free webinar presented by Paul Boag of Headscape. For those who haven’t heard of Paul before (and who hasn’t?!), Paul is a bit of a guru for the web development community. For many years he’s been blogging and podcasting on all things web. What’s particularly great is that he completely understands that web-related work is often all about people and relationships.

The webinar was titled ‘Fight the system’ and was targeted at internal web teams in large organisations. Large organisations, by their very nature, can create an environment that occasionally leads to issues of conflict between interested parties, departments, etc. and the web team have to negotiate their way through these difficult waters. This can then potentially lead to tricky relationships, poor decision-making, scope creep and an outcome where nobody is really very happy with the website.

Paul focused on four key areas that web teams should consider. These were:

  • Raising the reputation of the web team
  • How to deal with conflicts, politics and problem people
  • How to get signoff
  • How to avoid scope creep

Reputation

In terms of reputation, some internal web teams (not necessarily this one!) feel undervalued and lacking the ability to steer a web project in the right direction. Paul suggested that we could all do a lot more to improve our standing and reputation. He suggested to consider some of the following:

  • Charge – even if it’s only for a small amount to add value to the work. We have a basic and extended service which does have a charging component. We’ve introduced this because we think it will better define the service that we offer. It should also add value to the extra work we do, such as additional edits that aren’t part of existing templates.
  • In your demeanour, be upbeat and positive – try not to say ‘no’ just for the sake of it. If a piece of work is going to be difficult to implement, explain the consequences and consider a phased approach.
  • Establish yourself as an expert – be willing to cite other experts as well, and make much better use of facts and figures. For instance a green banner with red text isn’t going to be great, because of accessibility issues, so rather than just saying it’s a stupid idea, show the ‘client’ links to an ‘expert’ article which explains why this won’t be ideal.
  • Celebrate good pieces of work – debrief after projects, and don’t be afraid to tell others about how well projects have gone.

Conflicts, politics and problem people

One thing that’s wonderful about web, but can also be frustrating, is that it produces an emotional response from users. Most of the time people do have strong opinions as to how their website looks. This doesn’t, however, mean that they understand best practice and user-centric design. In larger organisations there is obviously going to be politics between various silos, e.g. between technology and marketing teams. Also during meetings there may well be an individual that through sheer presence of personality can force through their ideas even if it’s not beneficial to the website. Paul recommended the following:

  • Accept it – learn to live with it, and find better strategies to deal with it.
  • Keep talking – problem people sometimes just want to have their voice heard, and will be most frustrated if no-one listens.
  • Avoid confrontations - there’s no positive outcome from such situations
  • Empathise with stakeholders – share their pains and concerns.
  • Show, rather than tell – web teams can sometimes use a lot of jargon which is unhelpful to the client. If you want to demonstrate, for example, a cool jQuery carousel, go off to a website that has one that you like, rather than talk about it using terms like ‘jQuery’ and ‘carousel’.

Signoff

Getting decisions made about web projects can be quite challenging as it’s sometimes not easy to identify who the decision maker is. This is, dare we say, a particular problem within HE, with its traditional committee structures. Paul gave us some food for thought and we may well adopt some of the following approaches:

  • Establish the decision maker – quite often this can be quite a senior member of staff, which does present its problems, as they are often very busy people. However trying to make decisions with an intermediary or a group of people tends to end with fuzzy results. Paul suggested meeting with key individuals, rather than groups, as you’re possibly going to get a much clearer picture of goals and objectives.
  • Try and adopt some of the processes that are used in agencies, in other words, set clear milestones and timeframes for each key decision. Explain this process to the client from the offset and make them aware of their responsibilities in meeting deliverables within the timeframes set (for example, delivering content on time).
  • Capture requirements – and be comprehensive!
  • Include them in the development process. Ask them to consider stuff on the fly during meetings. Collaborate, and also refer to earlier decisions where perhaps new ideas conflict with those agreed earlier.
  • Get them to focus on business objectives and less on opinions, such as what the website colours should be. Remind them of the user exprience when conversations steer more into subjective territory.
  • Manage feedback – ask the client to identify problems rather than solutions. Instead of asking for the homepage to be bright green, ask the question: what is the problem that this decision solves? Is the user base going to specifically benefit from having such a colour scheme?

Scope creep

The bane of all web developers is when a project changes considerably from its original objectives. This can be unnoticeable at first, but obvious half way through. For example a client changes their mind about design elements like fonts, colours, number of pages, site structure, ad nauseum. To avoid this happening Paul offered some advice:

  • As mentioned above use an agency approach. Detail the scope of work from the offset and set key milestones and deliverables.
  • Explain the process so that it’s well understood with no surprises later on. Establish roles and responsibilities of all parties. Make sure they concentrate on their role and not someone else’s!
  • Have a phased approach. If a client comes up with a great idea that is out of scope, mention to them that this is possible, but will have to be shifted to a new phase of the project. Collect the ideas there and then and spec them for later.
  • If everything fails fall back on charging!

There was  a lot in Paul’s webinar that has given us plenty of ideas as to how to both better manage ourselves, and our stakeholders, and we’d like to thank Paul for sharing his insights – it was a really worthwhile event to be part of!

If you’d like to find out more, it is available (although there is a small charge):