Pros and Cons of Content Versioning in WCM

Professional success in creative industries depends heavily on your confidence. With confidence, ideas take shape quickly, projects get delivered, clients are happy. Without confidence, creativity feels like a journey through a cloud of thick fog and produces results that lack clarity and direction.

Early in my career I worked with an experienced, outgoing and remarkably confident creative director Andy Hutchinson, who is now CEO of a brand and design digital agency called Incredible (Leeds, UK). Back then Andy asked me to make minor amends to the web design concept I developed, in response to client feedback. I made the changes, clicked ‘Save As’ and modified the filename to include ‘v2’ so that if we ever needed to go back to version 1, it would still be available. “We don’t do that here,” said Andy. “No need for confusion”. Sometimes, knowing what not to do is just as important as doing the right thing.  

In web content management, versioning presents similar challenges. How many versions of content should we store, how frequently and for how long? Is it really worth storing every comma added, every auto-save created by the system? Are some versions of the content more important than others? What media types should we keep? And just as importantly, why?

Historically, content versioning was one of the core, out-of-the-box features in web content management systems. It was just there, switched on by default, with minimal or no configuration settings. Organisations used, and continue to use, content versioning for the following reasons.

  1. Legal and regulatory compliance.
    Records of published web content are important in the event of a dispute over misleading or inaccurate information. For industries such as financial services and healthcare ability to restore content published in the past is a legal and regulatory requirement.
  2. Editorial ease of use.
    Rolling back to the previous version can be an easy way for content editors to remove the most recent edit. This can be useful for adding, and then removing, seasonal content or temporary announcements with a limited shelf-life.
  3. Accountability.
    Content versioning allows easy tracking of who has made changes when. This can be particularly important in media industry where corrections and improvements to news stories happen frequently and may need to be checked for accuracy.

Despite all the benefits, content versioning also has its limitations.

  • Storage limitations.
    The most obvious constraint is storage space. The volume of web content that organisations push out continues to grow at a staggering rate, so keeping multiple versions of each content asset comes at a price. If versioning and rollback is important for your organisation, do not expect these requirements to be met through out-of-the-box, default configuration. Modern web content management systems started to impose limits on how much old content you can store.
  • Impact on performance.
    For coupled Web CMS platforms versioning can cause website performance issues. Coupled architecture means that the admin, back-end part of the CMS that content editors use in order to create, manage and store content (along with all its versions) resides on the same server as the front-end part, i.e. the website itself (as viewed by the end users). For this reason, WP Engine, one of the leading providers of managed WordPress hosting, has versioning disabled by default for its customers. Versioning (which is called ‘revisions’ in WordPress) can be switched on by WP Engine support team but even then it is limited to 5 revisions per post, with old revisions automatically deleted after 60 days. WP Engine recommends to use a separate tool for managing content versions prior to publishing. (Source: https://wpengine.co.uk/support/platform-settings/#Post_Revisions)
  • Lack of context.
    Content versioning in most web content management systems (including for example Drupal, Episerver and Sitecore) is limited to storing and rolling back a single content asset. Whilst reverting one specific piece of content to an earlier state can be useful, it often falls short of reproducing a full snapshot of a webpage as it existed in the past. If other elements that make up the webpage such as the template, stylesheet, sidebar content, configuration settings and so on, also changed, then these will not be rolled back at the same time. Recreating what a webpage looked like in the past requires a lot more detective work than just using a content versioning feature.  

Conclusion

For better or worse, we live in the digital world where web content can be updated, improved or deleted every minute of every day. Content versioning capability in web content management systems allows organisations to keep track of these updates and to view or revert to content assets saved at an earlier date. Whilst this feature is useful, it has its limitations. Reproducing the webpage in it’s entirely rather than reverting a single content asset isn’t easy, and the number of versions stored by default by modern web content management systems is typically limited. For long-term, reliable ways of storing legally binding web content organisations should consider record management systems, document management systems or archival tools specifically built for this purpose.

How to Select and Work With a Digital Agency

Selecting a competent, reliable digital agency for a web content management project can be both exciting and daunting. On the one hand, teaming up with an external partner can open up new possibilities, enable innovation and increase sales. On the other hand, if things go wrong and the relationship breaks down half way through the project, the resulting mess can be a very expensive mistake to fix.

In my career I have been involved in dozens of digital agency selections for website redesigns and web content management projects. Whilst some of these projects went over time and over budget, most of them still delivered great value and the decision to engage an external agency paid off. The very best outcomes emerged from partnerships with a strong focus on business goals and a high degree of flexibility with regards to approach.

In over 15 years of working in digital, I can remember only one web content management project involving a digital agency that happened to be an outright failure. This project had red flags all over it from day one, and the relationship with the agency broke down completely after a small 50-page pilot website was finally delivered after months of delays at a whopping cost of $5,000 per webpage. Legal action followed.

When I look back on all those numerous partnerships that worked well, and the very few that didn’t, I find that it helps to break down the experience of selecting and working with a digital agency into four key stages: discovery phase, selection process, project delivery and ongoing maintenance. Each of these stages requires attention and commitment to get it right.

1.      Discovery

Prior to communicating project goals to external agencies, it helps to clarify them internally. The purpose of the discovery phase is to capture the vision, strategy, and high-level requirements for the project. In addition to supporting the agency selection process, the discovery phase also ensures internal buy-in.

Discovery phase focuses on questions such as:

  • What is the overarching business strategy?
  • What problems does the project aim to solve?
  • What skills and insights are missing?
  • What role will the agency play?
  • What does success look like?

It is important to strike the right balance between exploring these questions at an appropriate depth, and not letting the discovery phase become so all-consuming that it stalls the project. That’s why it can be useful to have an agreed structure and timeline to all the meetings, such as the three-step process outlined below.

Step 1. Discovery workshop is an open discussion about the high level project goals and objectives. Disagreements, when they happen, can be acknowledged and noted, rather than resolved, at this early stage.

Step 2. Stakeholder interviews with up to 12 knowledgeable individuals whose insight, feedback, and buy-in are essential to the success of the project. Stakeholder interviews validate the vision, emphasize priorities, and help to build consensus about the direction and approach.

Step 3. Discovery findings meeting is designed to secure final validation and approval on a small number of core requirements (less than 20) that will be essential to delivering the project. These core requirements will become the integral part of the brief and will be used to identify the capabilities and competencies that the selected agency partner needs to bring to the table.

Selection process

Selecting a digital agency can be broken down into the following steps:

  • Shortlist
  • Agency presentations
  • RFP
  • Scoring
  • Decision-making
  • Respectful negotiation

Shortlisting is typically based on a mixture of information provided by industry analysts and customer references. If you can get hold of first-hand experiences of customers working with a particular agency in the recent past, that’s even better. Including 3 to 5 suitable agencies in your shortlist is about right. Having more than 7 is not recommended because it drastically reduces the chances of each agency to win the tender and will put off many competent but busy agencies from participating in the selection process.

It is useful to schedule meetings with each shortlisted agency prior to sending out requests for proposal (RFP). This way each agency will get an opportunity to understand the project and the requirements better, and will be well placed to provide a good quality response.

Once agency presentations are done, it’s time to write a Request for Proposal. This document includes information about the key aspects of the project, such as:

  • Background information about the company
  • Competitors overview
  • Proposed sitemap, navigation, Information Architecture
  • Design moodboards and preferences
  • Brand: imagery, tone of voice, primary message
  • Content strategy, copywriting, editorial calendar
  • Digital marketing requirements
  • Technical requirements
  • Key members of the team put forward
  • Budget
  • Timescales

You should also communicate selection criteria upfront. This could be, for example:

  • Feasibility of a long-term partnership
  • Understanding of the requirements
  • Previous experience of delivering similar projects
  • Proven ability to innovate
  • Cost

With clearly defined selection criteria, decision making shouldn’t be difficult. If at the end of the selection process you need to negotiate, try to do this based on negotiating defined packages of work that you can exclude from the project. Bluntly negotiating down the daily rate is unlikely to give you a reputation of a valued customer.

Before signing the contract, remember to take references. Discussions with past clients provide valuable insights into how the agency performs in the real world.

Project delivery

When planning a project, it’s useful to have a small-scale pilot stage in order to prove the viability of the proposed approach and to establish a trusting relationship with the agency with minimum risk. The pilot stage makes it possible to identify any issues before more substantial resources are committed.

Throughout the project, it helps if all parties are responsive, transparent and welcome an open debate. A good agency will challenge the way things are done and often for a good reason. Don’t be resistant to the new ideas and opportunities to learn.

Ongoing maintenance and support

A typical contract with a digital agency includes a warranty period of up to 3 months for bug-fixing and minor amends to the website. After that, the ongoing maintenance of the website can be either done by the agency under a separate maintenance contract, or it can be handed over to the in-house team. Consider who is best placed to perform the following maintenance tasks:

  • Server and system upgrades, security patches
  • Digital marketing
  • Analytics, reporting and analysis
  • Continuous improvements
  • Emergency fixes

When the website is well supported, it’s hardly noticeable – the website simply works as expected! It’s only when the maintenance is not in place that problems start to build up really quickly, undermining success of the project.

Conclusion

When selecting a digital agency, start with asking the right questions internally. A clear brief is critical to an effective selection process. Build a trusting relationship with the agency by setting clear expectations and being open to feedback and new ideas. Once the website is live, remember to have a maintenance plan in place that will make the project a long lasting success.

Investing in Technology: How to Make the Right Choice

Technology is evolving faster than ever. New software products, frameworks, and methodologies emerge all the time, making old platforms and ways of working obsolete. With so many options available that are constantly changing, making the right choice is a challenge. Large, complex organizations usually have procurement processes in place that emphasize due diligence, risk management, and cost-effectiveness. A typical technology selection process looks like this:

  • Needs recognition and validation
  • Requirements gathering
  • Stakeholder interviews
  • Financial analysis and ROI
  • Business case
  • Shortlist
  • RFPs
  • Vendor demonstrations
  • Scoring against the selection criteria
  • Decision making
  • Negotiations and contracts

With all of the steps in the process well-defined, what can possibly go wrong? Why is the success rate of technology investments so poor? Let’s look more closely at some common mistakes.

Common mistakes

Herd instinct —Some organizations are overly influenced by the choices their competitors make. They assume that what worked well for another similar organization will work well for them. This is particularly common in verticals serviced by industry-specific solutions, such as health, ecommerce, and higher education. However, intimate understanding of the sector often comes at the price of slower pace of innovation. Software vendors that tailor their solutions to a specific industry don’t typically offer the most innovative, cutting-edge capabilities.

Overbuying —It’s easy to get carried away by a compelling presentation delivered by an A team of experienced sales professionals. However, if too many product features are above and beyond what’s actually required, it’s worth asking if the organization is ready to adopt the proposed vision at the time of investment.

Death by requirements —Interviewing all stakeholders in a large organization and writing down every single requirement can slow down or even stall the selection process. The more requirements vendors have to consider, the longer their responses are—and the longer it will take to evaluate them. Technology selection must be a pragmatic process, prioritizing vision over completeness.

Often, these pitfalls reflect the personality of the individual assigned internally to lead the selection process, such as:

  • Someone who is outgoing and well-connected with industry professionals is likely to lean on advice from more experienced peers, thus falling into the herd instinct approach.
  • A visionary leading a selection process is likely to be influenced by slick product demonstrations showing true leadership and innovation and may end up overbuying for the organization’s current needs.
  • A loyal, hard-working perfectionist may get stuck at exploring all of the options and all of the requirements at the expense of moving the project forward, which may result in death by requirements.

If people leading the process internally had a chance to do a similar project again, they would no longer need to rely on their instincts as much and would adopt a more balanced approach. Unfortunately, by the time the organization selects similar technology again (usually in 5 years or more), people involved in the previous technology selection move on to other roles. Information captured in lessons-learned materials becomes out-of-date. Hanging on to this obsolete knowledge is not a good idea.

External consultants

The only way to address the issue of knowledge decay is to involve an external industry expert who selects and buys technology day in, day out (rather than once in 5 years). By hiring an external consultant, organizations can achieve a number of benefits.

Current knowledge of the marketplace —The main and most obvious benefit of using an external consultant for technology selections is to acquire current knowledge of the marketplace. This kind of expertise cannot be replicated internally.

Broader perspective —Previous experience of working on similar projects makes it possible for external consultants to either validate or challenge organizations’ own findings. It adds weight to recommendations and gives the organization confidence to proceed in a certain way. Occasionally, it also makes a competitor’s name pop up randomly in the vendor’s proposal when proofreading didn’t quite happen as it should have.

Clarity —Good consultants bring clarity. They are firm and don’t shy away from articulating the problems their clients face. They stick to what’s really important. They surface conflict and disagreement in ways that help the organization to move forward and grow.

Focus —Organizations get caught up in internal politics, whereas external consultants retain a ruthless focus on the timeline and help internal employees concentrate on the most important steps and actions.

A word of warning

While working with external consultants brings many benefits, managing the relationship between the consultants and internal employees requires extra care. Here are some typical challenges.

Lack of trust —Relationships between external consultants and internal teams are often fraught with difficulties. External consultants provide an opportunity to learn and improve. They are hired specifically to change things for the better and address problems that internal teams are unable to solve. However, internal teams may see this intervention as a threat to existing processes, roles, and responsibilities. In the worst-case scenario, implementation of the new technology may even result in layoffs. Clarity around how the changes will be implemented and who will be affected is essential for establishing trust and effective knowledge-sharing between external consultants and internal teams. Shawn Engbrecht dedicates a full chapter (“The Outside Consultant: Learning to Love the One You Hate”) to this issue in his book Invisible Leadership.

Missing the point —Consultants have limited time to collate all of the information required to fully understand the intricacies of how the organization operates. It’s not uncommon for consultants to apply similar scenarios from previous experience to cases where they don’t quite fit, because of some misinterpreted data. Validate a consultant’s understanding of the problem early and often.

Longer-term transformation path —External consultants typically work in short, high-impact engagements. After the final presentation is delivered, there is a risk that the organization isn’t ready or can’t afford to follow the transformation path to move the organization forward in the longer term.

Telling you what you already know —As the saying goes, “A consultant is someone who borrows your watch to tell you the time, and then keeps your watch.” While collating information and reflecting it back can be useful, this activity alone cannot justify expensive consultants’ fees. Recommendations must be substantiated with data and analysis that are based on broader experience across the sector.

Conclusion

In some organizations, selecting and buying technology is a case of the least-qualified people leading the way. It is not uncommon for a staff member in charge of the decision to have no prior experience with conducting technology selections. Lessons learned, which are documented by predecessors, are often past their expiry date.

Organizations looking to achieve competitive advantage as part of their technology investment must engage external consultants and industry analysts in order to acquire the most reliable, up-to-date knowledge of the marketplace. If the relationship between external consultants and internal staff is managed well, the combined effort will ensure that the technology investment meets the needs of the organization and delivers a lasting success.

Being Yourself at Work: Notes on Equality and Diversity in Tech

When I got British citizenship in 2010, it felt like winning a lottery. Going through the immigration process was a long, nerve-wrecking and expensive journey, but through hard work and a healthy dose of luck I got through to the finish line when so many people with similar skills didn’t make it. My degree, work experience and age (yes, age) meant that I scored enough points to qualify for Highly Skilled Migrant Programme during the brief time of its existence (2008-2015). Had I been one year older at the time of applying or in a different profession, the stars wouldn’t align for me so well.

Once my family became British, I threw away six large bin bags of shredded payslips, bank statements and tax returns that I previously collected for immigration purposes, left my job and changed my name. By and large, British employers just weren’t able to cope with my Ukrainian name, Mar’yana Kolodiy. It was misspelled more often than not, usually with multiple typos. So as soon as my immigration process was over, I decided to adopt a new name, Marianne Kay, for professional purposes. It was a pragmatic decision. I was hoping that the new name would enhance my career prospects; and it did. I can now introduce myself in one sentence, anywhere, no questions asked. There is no need for awkward moments, geography lessons, or lengthy detours into the history of Chernobyl. Today, ten years after I changed my name, I am also confident that it better reflects my identity of a British immigrant. It makes me happier and more at ease. If anything, I regret I wasn’t able to change my name earlier in my career.

Research backs up my concerns over foreign sounding names. In 2017, BBC Inside Out asked a question: is it easier to get a job if you’re Adam or Mohamed? Predictably, in response to 100 identical job applications, Adam was offered 12 interviews, while Mohamed was offered only four. In the same vein, a study conducted by the British Academy in 2019 concludes that on average 24% of job applicants with British sounding names receive a positive response from prospective employers, against only 15% of minority ethnic applicants (whilst submitting identical CVs). It appears that a significant percentage of hiring managers don’t progress the recruitment process much further when they get stuck on the fact that they can’t pronounce the applicant’s name.

Name bias is just one of the many possible factors that lead to inequality at work. Consider these recent figures on diversity:

·       Female employees take up less than 25% technical roles at America’s largest tech companies: Google, Apple, Facebook and Microsoft. Lack of women is even more obvious at the senior level and in leadership roles. (Statista, 2020)

·       Lesbian, gay, bisexual and transgender staff in the UK earn on average 16% less than straight workers. 35% of LGBT+ staff in the UK choose not to disclose their sexuality at work for fear of discrimination. (YouGov, 2019)

·       Only 15% of the people working in tech in the UK are from black, asian and minority groups. (TechNation, 2018)

·       Disabled employees earn on average 12.2% less than those without impairments. (Office for National Statistics, UK, 2018)

·       66% of tech professionals are stressed by their work. People in tech are five times more depressed than the national average. (BIMA, UK, 2019)

·       More than 40% of older tech workers are worried about losing their jobs due to their age. (Indeed, 2017). A book by Dan Lyons “Disrupted: My Misadventure in the Startup Bubble” is a true story about ageism in tech industry which is sad and funny in equal measure.

Despite the challenges associated with overcoming stereotypes and biases, the business case for greater diversity at workplace is overwhelming. Diversity gives organisations access to a wider range of talent, and provides the ability to understand the needs of all of their customers rather than certain customer groups as determined by race, gender or some other restrictive characteristic. Boston Consulting Group found that companies with above average diversity in management teams have 19% higher revenues due to innovation.

The case for professionals to be themselves, even if they don’t ‘fit in’ with the team in the traditional sense, is just as convincing. Being your true self at work is associated with higher levels of well-being, engagement and motivation, which in turn has a positive effect on performance.

Nevertheless many people feel cautious about exposing their vulnerabilities at work, particularly at the start of their career. Being yourself feels natural and right when you are a child – you just don’t know any different. It is also easier to be true to yourself in later life, when most of us develop superpowers to no longer seek other people’s approval as much. However being open and honest at a time when we are actively developing our personalities and careers is much more risky – there is so much pressure, so much struggle, and so much is at stake.

“Being different makes you stand out from the crowd and can help you to progress your career, but it also opens you up to criticism, judgement and discrimination.” – says a web designer working for a large retail company in the UK. “You have to be confident and sometimes you’ll have to align yourself with others who may not agree or appreciate your differences in order to succeed or to get a task done. You have to access the situation and make a conscious decision on how and when you show the different sides of your personality.”

Sameera Rafiq, the equality and diversity lead for the School of Food Science and Nutrition in the University of Leeds (UK), encourages students and staff to be proud of who they are. “The world is so much bigger than you think, it is filled with all kinds of quirky, mysterious, passionate, intelligent people. You admire them for their energy, so why not give yourself the same love and respect? When you spend too much time trying to do the right thing, as defined by your peers, teachers, family, you end up being pulled in so many different directions. The only right thing to do is to be you. Say what you really think and how you really feel. It will change your life.”

In the book “The Glass Closet: Why Coming Out Is Good Business” Lord John Browne, former CEO of BP promotes self-disclosure as the best approach both for the staff themselves and for their employers. John’s deepest regret to this day remains not being able to come out as gay earlier in his career.

True diversity, such as the racial diversity we see in the ‘Good Place’ series on Netflix, is rare. When we come across it, it feels good and right, but the reality isn’t always as agreeable as it’s pictured in the movies. 

Diverse teams perform better than homogeneous groups but, ironically, due to such a wide range of perspectives and ideas, they also have lower confidence in the results of their work. Initially, diversity feels uncomfortable. If nothing is done to counteract this awkward moment, diversity has limited benefits and amounts to nothing more than tolerating differences, because even though diversity is in place, inclusion, the “how” of diversity, is not.

Every organization is unique, but some generic principles of advancing diversity and inclusion apply to most workplaces. These are:

·       Clearly communicate business goals and performance objectives, to alleviate anxiety over possible discrimination when it comes to rewards and promotion;

·       Ask employees what they need in order to be the best they can be at work. Listen. Don’t assume. Everyone is different and everyone deserves to be treated as a person with their own needs and preferences;

·       Have formal processes in place to achieve equality and diversity objectives, including for example name-blind recruitment policy and support for staff through gender transition;

·       Enlist help from independent third parties who can advise your staff on equality and diversity matters in a safe, confidential manner;

·       Foster openness, honesty and tolerance.

Nothing worth having comes easy. Just as talented, motivated professionals step out of their comfort zones to share their vulnerability with their team mates, organizations should embrace and advance their diversity and inclusion objectives, in order to achieve success that truly sets them apart from competition.

Ethical dilemmas behind web accessibility compliance

‘I, Daniel Blake’ is a British drama film about a 59-year old widower who worked hard all his life but became unemployable following a sudden heart attack. In order to keep the roof over his head Daniel had to make a claim for employment allowance at the local Job Centre. Despite Daniel’s inability to fill in the online form without help, he is given no alternative ways of completing this application because UK government services are ‘digital by default’.

This heartbreaking scene is a stark illustration of how the internet has become an integral part of our lives, whether we like it or not. We use websites and mobile apps for studying, banking, shopping, booking holidays, registering to vote, staying in touch with friends and family, and so much more. A day without the Internet is hard to imagine. Often we use online services not as a matter of personal preference but simply because that’s the only sensible way to complete a task quickly and efficiently. Isn’t it reasonable to expect that everyone in our society should be able to do the same without too much difficulty?

What is web accessibility?

Web accessibility is a practice which enables people with disabilities and other barriers to use the Internet. Web accessibility also benefits other users, for example older people, non-native speakers and people accessing websites on small screens.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG; pronounced ‘wuh-kag or ‘double-u-kag’) are published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) and consist of a number of criteria that need to be satisfied for a website to be accessible. The first version of WCAG guidelines was published in 1999, and the most recent version WCAG 2.1 which is the current best practice, was published in 2018.

One of the most well understood examples of web accessibility criteria is the WCAG 2.1 criterion 1.1.1 stipulating that all images should have a descriptive ‘alt’ text attribute specified. Alt text enables blind users to access the description of the image using a screen reader. Without the description, a blind user will not understand the purpose of the image.

Web accessibility issues

The most common accessibility issues today are:

  • Non-responsive design
  • Inconsistent navigation
  • Image sliders and carousels
  • Content presented as images
  • Privacy notices and cookie banners difficult or impossible to get to using a keyboard
  • Inaccessible Word and PDF documents

Web accessibility legislation

Web accessibility legislation is different in different countries.

  • In the United States, Americans with Disabilities Act (ADA) became law in 1990, and applies to businesses, government institutions, and non-profit organisations. Section 508 specifically covers government websites and online services.
  • In Europe, The EU Web Accessibility Directive came into force in September 2018, requiring all public sector websites and applications to implement, enforce and maintain accessibility standards.
  • In Australia, the main web accessibility law is the Disability Discrimination Act 1992.

WCAG guidelines are widely respected as providing a path to legal accessibility compliance, and are often referenced in web accessibility law.

Businesses involved in the most notable recent legal cases around web accessibility are:

  • Domino Pizza
    A blind man was unable to order a customized pizza using a screen reader on Domino’s Pizza website and mobile app.
  • Beyonce
    A visually impaired woman claimed that she couldn’t access key features of Beyoncé’s website because it didn’t meet accessibility standards.
  • Harvard
    Harvard websites failed to make their video content (including courses and open lectures) accessible to people who are deaf.

The majority of legal cases to date involve visually impaired users, however in meeting web accessibility requirements you should always cover all types of disabilities: visual, auditory, cognitive and physical.

Roles and responsibilities

Website accessibility is fundamentally an ethical responsibility shared between:

  • Business owner;
  • Web accessibility specialist with technical and legal expertise;
  • Content editor;
  • Web developer;
  • Tester.

In large organisations these roles can be owned by teams or departments.

Business owner is accountable for web accessibility compliance from legal point of view. Accessibility specialist is responsible for conducting web accessibility audit, monitoring the levels of compliance and advising the web developer and content editor what actions to take. Some of the WCAG guidelines such as ‘consistent and predictable navigation and user experience’ are open to interpretation. It is the job of the accessibility specialist to consult with the business owner, interpret legislation and provide the necessary advice to the web developer, tester and content editor.

Ethical dilemmas

Although some businesses leave web accessibility to web developers, it is a mistake to see it purely as a technical exercise. Below are three ethical dilemmas that require high level decision-making.

  1. Challenge 1: Web accessibility by design vs fixing in place
    Many digital agencies specialising in web accessibility offer packages of work essentially consisting of applying ‘accessibility fixes’. Under the pressure to make a website compliant by a certain date, organisations may be tempted to accept this approach as a short term solution to their regulatory problem. Accessibility fixes may reduce the risk of being sued, but they achieve little to establish long-term compliance where accessibility is built into business processes by design. There is a very real danger that these fixes will not survive your next code release or software upgrade.
  2. Challenge 2: Abandoned, legacy websites
    Government and non-profit organisations often own web content that is no longer actively maintained due to staff turnover or lack of funding. For example, it is not unusual for a university research project website to outlive its content owners. In the cases where there’s no money and no staff available to upgrade the website to meet accessibility requirements, is it better to shut it down or leave as is (in its admittedly inaccessible format) for the benefit of the academic community? That’s not a question that a developer can answer.
  3. Challenge 3: Disproportionate burden
    In some cases the cost of meeting accessibility requirements is unreasonably prohibitive. For example, many large organisations own a huge number of old PDF documents. Making all of them accessible to screen reader software is too expensive, but converting some of them to accessible PDFs upon request as well as producing any new PDFs in an accessible way in the future is feasible. Assessing whether a specific situation falls under ‘disproportionate burden’ terminology is a business decision, not a technical one.  

Despite many challenges, web accessibility is an integral part of developing websites that make the Internet a better place. Prioritising accessibility benefits everyone. Accessible websites are often impactful, easy to use and inspire trust. Accessible code is cleaner code, so an investment in accessibility is an investment in more reliable, future-proof underlying technology. Everyone who owns a website has a legal obligation and a moral duty to achieve and maintain accessibility compliance.

How to Avoid Common Pitfalls in Web Content Management Projects

There is no shortage of IT projects that ran over time, over budget or under-delivered on value. Managing web CMS projects is hard because it relies on using new unproven technologies, ambiguous terminology, and requires agility in order to accommodate changing requirements. 

Here are some tips that will help you to avoid common mistakes.

Engage with stakeholders and users early and often

In the rush to deliver the project on time, it can be tempting to jump straight into implementation. Whilst this can give a false sense of security early in the project, the risk of not involving the right people from the start can backfire further down the line. User research and stakeholder interviews are essential steps of the discovery phase and can reduce the overall time to reach a viable solution.

Ironically, too many consultations before any action is taken can stall progress. In large, complex organisations the key is to engage with different groups of stakeholders in a way that’s manageable. It may not be possible to meet with every user and every stakeholder face-to-face and satisfy everyone’s needs but it is possible to reach out to everyone who will be impacted by the project in some way – for example through blog, email newsletters and feedback forms.

Say no to poor requirements

There are three major types of bad requirements to watch out for:

  1. Ambiguous, poorly defined requirements;
  2. Over-ambitious requirements;
  3. Unnecessary requirements.

An easy-to-use web content management system is an example of a poorly defined requirement. What kind of audience should find this system easy-to-use? What user scenarios should the system be tested against to ensure it is easy-to-use? Without this context the requirement is open to interpretation and can lead to costly misunderstandings.

Bug-free code and 100% availability are examples of over-ambitious requirements – challenge these unrealistic expectations and substitute them with achievable alternatives.

Have you ever come across a requirement for the new website to look and function exactly like the old website but running on a new CMS platform? This is a classic example of an unnecessary requirement, which is rooted in the organisation’s reluctance to change, rather than business goals. This ‘requirement’ solves a problem that doesn’t exist. Check rigorously that all requirements are linked to business objectives and allow as much flexibility as is necessary to achieve them.

If not addressed, poor requirements can lead to scope creep and ultimately project failure.

Address skills and competencies gaps

All digital projects rely on multidisciplinary teams. Core skills needed for a successful delivery of a Web CMS project span across multiple areas and include:

  • user research, user experience;
  • business strategy;
  • business change;
  • content strategy, content writing, content editing;
  • analytics;
  • technical skills (web development, servers, enterprise architecture);
  • design.

Lack of competence or lack of resources in one or more of these areas can severely impact the overall success of the project. Consider hiring contractors or partnering with an agency, if some of these skills are not available in-house.

Do not underestimate technical complexity 

One of the reasons organisations invest in Web CMS projects is to make their operations more efficient. Standardised processes for web content production and consistency introduced through the use of templates result in reduced cost of running the company’s web presence. The more websites follow the same set of principles, the cheaper it is to run each website.

What organisations sometimes fail to acknowledge is that custom web development does not produce similar economies of scale. Introducing more and more custom features does not make them cheaper to develop or maintain – in fact, the opposite is true. A project 10 times as large in terms of features will take significantly more than 10 times effort to build.

Underestimating complexity introduced by customisations is a common issue in web content management. Be ruthless in critically evaluating the value of custom development required for your project.

Transition into business-as-usual gracefully

Web content management projects never deliver full value on the day the website goes live. Consider closing the project 3 to 6 months after the website is launched, to allow for bug fixes and smooth transition to business as usual. Make sure that the new processes are documented and appropriate training is in place for developers and content editors. In a way the day the new website goes live is just the beginning.

Digital Project Success Checklist

There is no shortage of high profile digital projects that have run over time, over budget or both. Managing digital projects is hard because it relies on using new unproven technologies, terminology is ambiguous, expectations are high and the desire for constant change of requirements is relentless. 

Digital Project Success Checklist presentation covers the complete project lifecycle from writing the business case to project closure. We’ll cover both traditional methods such as RAID log and RACI model, and new trends in digital project management such as kanban boards, product vs project management  and emotional intelligence.

  • What is a digital project? 
  • Business case
  • The importance of executive buy-in
  • Stakeholder interviews as a requirements gathering and relationship building tool 
  • Requirements, scope and deliverables 
  • The dark art of estimating digital projects
  • Project methodology – waterfall, agile or hybrid?
  • Project plan 
  • RAID log – Risks, Assumptions, Issues and Dependencies
  • Managing the team using RACI model
  • Project closure

Real world examples and an interactive exercise on software estimation will make this talk a dynamic and inspiring experience.

Find out more

The Web CMS Project Lifecycle

One of the reasons web CMS projects are so hard is that organizations don’t do them very often. Lessons learned are forgotten a year or so after the project is finished, people move on, and, by the time the web CMS is under review again, most of the previously acquired knowledge of the CMS marketplace is out-of-date.

Lack of experience in running web CMS projects often leads to sketchy planning. Not seeing clearly how the project will develop and what challenges each of the project stages brings makes accurate estimates difficult.

Here is a quick overview of the lifecycle stages of a typical web CMS project and some ideas to help you avoid pitfalls in order to put your project on a less stressful path to success.

Stage 1: The Business Case

A business case typically includes the following:

  • Problem statement
  • Options and recommended solution
  • Benefits and impact
  • Implementation approach, timeline, and resources
  • Required investment

Building a business case for a new web CMS is hard because the project can be easily mistaken for a technology upgrade with no real sense of urgency attached to it. To avoid this fate, make sure that your business case is in line with the overall business strategy. Not only should it explain why the project is important in general, but it should also answer the question, “Why now?”

When writing an executive summary, and particularly when articulating the business case in person, enhance the credibility of your message by covering relevant aspects of the proposal: main point, breadth, depth, height, and sight (for more on this concept, see Allen Weiner’s book So Smart But…: How Intelligent People Lose Credibility—and How They Can Get it Back).

Your main point for a web CMS project business case will be the key strategically important outcome. If a university is migrating all faculty websites to a single central web CMS, the main point is the need to surface interdisciplinary content that doesn’t neatly belong to one faculty. To illustrate breadth, consider several specific examples of the problem (i.e., cite research centers that are not currently promoted on the central university website and are difficult for prospective students and researchers to find as a result of the current setup). Depth means more detail on one of these problematic instances—perhaps one of these research centers represents the area in which the university has gained a lot of publicity recently and is uniquely placed to attract large numbers of world-famous researchers. (Substantiate your claim with numbers if you can.) Height is about the big picture—the effect on the whole organization, such as an increased number of applicants—and sight is about the future. In the case of the university web CMS project, the sight aspect can be communicated as “all research opportunities and research centers will be easily findable using the central university website in 2 years’ time.”   

Stage 2: Business Analysis

Stakeholder interviews help to get a real sense of the project requirements, constraints, differences of opinion, and the severity of the internal politics in the organization. They inform the project, clarify issues and priorities, and prepare the business for change.

You should interview senior decision makers, support staffers (such as those at the service desk), CMS users (content editors), and website visitors. The optimum number of stakeholder interviews varies depending on the complexity of the project, but as a rough guide, 12–26 interviews typically provides sufficient insights. Further interviews don’t usually provide additional information, but they can continue to help to foster buy-in.

When gathering requirements for a web CMS project, prioritize vision over detail. CMS projects are chronically prone to over-engineered, overly complex functionality that is requested and rarely used. Workflow and form builders are prime examples—they are useful features, but they are used much less frequently than is anticipated by the business at the outset of the project.  

Stage 3: CMS and Implementation Partner Selection

Once the business case is approved, it’s time to start web CMS selection and procurement. It is not uncommon for web CMS selections in large, complex organizations to take 6–12 months. Here are some tips that can help you to speed up the selection process without compromising due diligence.

  • Write CMS scenarios to shape the evaluation process. Scenarios help contenders to focus on requirements that are relevant and important to your organization.
  • Engage with an industry analyst who is actively covering WCM market space.
  • Organizations select a new web CMS once every 5–7 years; analysts do it every day. They will have information and insight that you don’t.
  • Create a shortlist of three to five web CMS platforms.
  • Select an implementation partner as an element of this process, rather than separately, as an afterthought. Look for partners that have experience of three or more completed projects using the CMS in question. Don’t be tempted to upskill your in-house team for the initial implementation—external expertise with significant platform-specific experience will offer you both better quality and better value for money.
  • Organize meetings with shortlisted vendors before you finalize the RFP. This will give you an opportunity to clarify or even reconsider some of the requirements based on the initial feedback you get from the vendors. It will also reduce your chances of receiving canned proposals.

Make the decision-making group six people or fewer. Larger groups are not more effective and will cause delays.

Stage 4: Web Development, Content, Design, and User Experience

In an attempt to reduce risk, it can be tempting to separate the technology part of the project from the redesign, content edits, and content governance. This is a bad idea—technology, content, design, and governance are inextricably linked in a web CMS project. Technology alone cannot deliver great customer experience, elevate content quality, or improve content governance. Technology can facilitate these outcomes, but using the new web CMS in the same way as the old system was used will deliver marginal benefits at best. Successful web CMS projects are always multidisciplinary and require all departments to work together as a team.

Stage 5: Project Closure and Transition Into Business as Usual

Perfect is the enemy of good. No matter how much time and money are allocated to the project, new ideas will keep coming. A wishlist, a web CMS road map, and a business-as-usual service definition are important actions at the end of the project to ensure lasting success.  

Assembling a Winning WCM Project Team

EContent Magazine - Summer 2019Assembling a Winning WCM Project Team, Marianne Kay

The roles and skills required for a successful Web CMS project completion can be divided into three groups: business, content and technical. These groups often work in different departments with conflicting priorities. The first two (business and content) typically belong to marketing, and technical roles are staffed by IT.

When a web CMS project goes well, it’s because of the hard work of people behind the project, who are able to surface and deal with the challenges, not only individually, but also as a team that builds on each other’s expertise.

When a web CMS project goes wrong, it’s usually for the following reasons: 

  • Underestimated technical complexity and implementation costs
  • Excessive focus on technology and not enough focus on people and processes
  • Poorly defined requirements
  • Lack of support at the senior level
  • Silos, internal politics, and a lack of trust

When a web CMS project goes well, it’s because of the hard work of people behind the project, who are able to surface and deal with the challenges mentioned above, not only individually, but also as a team that builds on each other’s expertise.

The roles and skills required for a successful web CMS project completion can be divided into three groups: business, content and user experience, and technical. These groups often work in different departments with conflicting priorities. The first two (business and content and user experience) typically belong to marketing, and technical roles are staffed by IT. 

  • Project sponsor
  • Business lead
  • Project manager
  • Business analyst
  • Business change manager
  • Industry analyst
  • Web designer
  • Usability specialist
  • Content strategist
  • SEO expert
  • Analytics analyst
  • Social media specialist
  • Front-end developer
  • Back-end developer
  • Mobile developer
  • Technical architect
  • Product manager
  • Tester

Let’s see what these roles involve in more detail.

Business

Project sponsor secures funding and provides executive-level support for the project. This position is the living proof that the project is recognized as strategic to the business.

Business lead ensures that the project aligns with the overall business strategy and is the voice of the business users (usually, content editors and marketing staffers).

Project manager is responsible for planning, monitoring, and closing the project. He or she ensures that what is delivered is right for the business and prevents the project from becoming a never-ending series of scope creep. Being able to afford a project manager on a small content management project can be a luxury, but large organizations with web CMS project teams of 10 people or more significantly improve the chances of successful delivery with a dedicated project manager on board.

Business analyst defines, analyzes, and documents requirements. Without a business analyst, WCM projects end up delivering against a laundry list of nice-to-haves that are poorly defined, poorly prioritized, or both.

Business change manager facilitates change to business processes, systems, and technology, often through modifying job roles and organizational structures. Change is hard; new systems and processes take time to learn. Unmanaged change can lead to the premature deconstruction of deliverables before they even start to bring business benefits.

Industry analyst is invaluable if the project includes a web CMS selection and procurement. Organizations tend to select new technology every 5–7 years, while industry analysts deal with web CMS selections every day, so it is wise to source this expertise externally.

Content and User Experience

Web designer—once the initial concept is designed and signed off on—works closely with front-end developers to build a design patterns library for a wide range of use cases and devices. The BBC’s Global Experience Language (GEL) is one great example of such a library.

Usability specialist is responsible for continuous data-driven improvements. A usability specialist can also help to prototype proposed solutions and evaluate them from the user experience angle.

Content strategist organizes content and manages content writers, recognizing content as a business asset. A good content strategist scrutinizes every webpage, asking, “What should this page make you think, feel, or do?” If it’s not working toward the business goals, it has to be rewritten or removed.

SEO expert minimizes the impact of the technology change and content migration on search engine visibility. Writing good content is always a good basic approach to SEO, but at the time of significant technical change, special attention is a must.

Analytics analyst informs some of the prioritization and decision making of the CMS project, as it is also  important for measuring the project’s success.

Social media specialist is involved in communicating change to the customers after the launch of the new site.

Technical

Front-end developer’s role is becoming increasingly challenging due to the constant evolution of technologies and proliferation of devices (including mobile). Maintaining a stable front-end codebase requires more than just the knowledge of HTML, CSS, and JavaScript. It also requires appreciation of software engineering principles in a broader sense.

Back-end developer for a web CMS project should have previous experience of working with the chosen system. In the absence of this, experience with similar enterprise-level CMSs can be sufficient.

Mobile developer is desirable for managing complexity that the responsive web design brings, and it’s a must for projects that include native mobile apps.

Technical architect or enterprise architect takes care of the bigger-picture technical implementation issues such as systems integrations, servers, security, hosting, and bandwidth.

Product manager is necessary when the need for the web CMS customizations is so high that the customized platform effectively becomes a software product in its own right. Some media and higher education organizations (such as the BBC, The Guardian, and the University of Edinburgh) go down this highly customized route. The product manager protects the system from the feature bloat and ensures long-term maintainability.

Tester in software development ensures higher standards and better user experience. For large-scale projects, a separate testing team is vital.

Team Size

In a small company with limited resources and budget, some of the roles can be combined. For example, a business lead could take on project management and business analysis tasks, as well as be responsible for driving business change. A web developer can be a full-stack developer responsible for front end, back end, mobile development, security, and testing. A web designer can take on usability as part of this role. A content editor can be responsible for content strategy, content writing, SEO, and social media.

Large organizations that can afford to hire individual staffers for each role benefit from high-quality, specialized expertise. At the same time, the larger the team, the more effort it takes to keep people organized and productive. Some web CMS projects go over time and over budget due to excessive time spent in committee-type meetings that lead the project nowhere. The core decision-making project team should never be dozens of people; it should be limited to six people or fewer and include key team members: a project sponsor, a business lead, a project manager, a technical lead, and a content lead.

Senior vs. Junior Roles

Completing a web CMS project requires a lot of knowledge and experience. That said, there is also a lot of tedious lifting and shifting along the way that would benefit from the energy and enthusiasm of junior-level staffers. Experienced CMS specialists are harder to find and easier to lose than junior colleagues. As with any other project, a mix of junior-level and experienced staffers is key to success.

Conclusion

Every WCM project requires business, content, and technical skills. If you break these broad categories of skills down into specialist roles, it may seem like a lot of people. However, not all roles require a separate dedicated resource, and many can be covered by someone already employed by your marketing, communications, or IT department. The gaps in skills can then be filled by recruiting permanent staff in-house, employing a contractor, or partnering with a digital agency.   

Web Content Management systems in Higher Education (UK)

What content management systems (CMS) do Universities use? Here are some examples.

University of Aberdeen  OpenText
Abertay University TERMINALFOUR, Umbraco
Aberystwyth University TERMINALFOUR
Anglia Ruskin University Cambridge Sitecore
University of the Arts London TERMINALFOUR
Aston University Easysite
University of Bath Bespoke system, developed in-house
University of Birmingham Contensis
University of Bolton Contensis
Bournemouth University Drupal
University of Bradford TERMINALFOUR
University of Brighton  Contensis
University of Bristol TERMINALFOUR
Brunel University London Contensis
University of Buckingham WordPress
University of Cambridge Plone, Drupal
Canterbury Christ Church University Contensis
Cardiff University  Squiz Matrix
Cranfield University Sitecore
University of Cumbria TERMINALFOUR
De Montfort University Leicester Contensis
University of Derby TERMINALFOUR
University of Dundee TERMINALFOUR
Edge Hill University WordPress
University of Edinburgh EdWeb (Drupal)
University of Essex Sitecore
University of Exeter TERMINALFOUR
University of Glasgow  TERMINALFOUR
Glasgow Caledonian University  TERMINALFOUR
University of Hertfordshire Squiz
University of the Highlands & Islands TERMINALFOUR, Plone
University of Huddersfield TERMINALFOUR
University of Hull Contensis
Imperial College London TERMINALFOUR
University of Keele TERMINALFOUR
King’s College London Contensis
Lancaster University TERMINALFOUR
University of Leeds  Jadu, WordPress
Leeds Trinity  SharePoint (moving to TERMINALFOUR)
University of Leicester Plone
University of Lincoln  TERMINALFOUR
University of Liverpool TERMINALFOUR
Liverpool Hope University  TERMINALFOUR
Liverpool John Moores University  Sitecore
University of London Goldsmiths College TERMINALFOUR
London Metropolitan University TERMINALFOUR
London School of Economics and Political Science  Contensis
University of London School of Oriental and African Studies  Percussion
Loughborough University  TERMINALFOUR
University of Manchester  TERMINALFOUR
Newcastle University  TERMINALFOUR
Northampton University WordPress
Nottingham Trent University  Squiz Matrix
Nottingham University  Contensis
Oxford University  Drupal, Plone
Plymouth Marjon University  TERMINALFOUR
Queen Mary University of London TERMINALFOUR
Queen’s University Belfast  TERMINALFOUR
University of Reading Activedition
Royal Holloway University of London  Contensis
Southampton Solent University Contensis
St George’s, University of London Drupal
Staffordshire University Contensis
Stirling University  TERMINALFOUR
University of Strathclyde  TERMINALFOUR
University of Portsmouth TERMINALFOUR
University of Sheffield Polopoly / Drupal
University of Southampton SitePublisher (previously TeamSite)
University of South Wales Wagtail
University of St Andrews  TERMINALFOUR
University of Suffolk Drupal
University of Sunderland TERMINALFOUR
University of Swansea TERMINALFOUR
University of Wales  Contensis
University of Wales Trinity St. David TERMINALFOUR
University of West London Drupal
University of Winchester  Contensis
University of York TERMINALFOUR
York St John University TERMINALFOUR