When I talk to authoring teams about changing the way they work, most have a pretty good idea of what they want to do differently. Structured content is not new any more and the benefits of reuse, multi-format publishing and modern modes of delivery have been discussed in publications like Communicator for a long time. The most common obstacle to achieving this is getting buy-in from the business to invest the time, the money and the will in a content project. But developing a persuasive, robust business case is not always easy.
Traditionally, a business case looks at the current position and makes a prediction on how a particular course of action will either increase revenue or reduce costs (or, ideally, both). That sounds simple, but we’re actually being asked to answer two quite tough questions:
- How much does content cost?
- What is its value to the business?
Superficially, businesses get a good deal from their technical communication teams. They pay authors’ salaries, invest in a little affordable software and, mostly, everything that seems to need documenting, seems to get documented. The investment needed for even a modest content management system can seem huge compared with maintaining the status quo. But the true cost of content, and the effort required, is often greater than anyone realises, and the business case needs to bring that true cost out into the open.
As writers we have a strong instinct that what we do has impact and value – but quantifying that, placing an actual financial value on it is hard, because there isn’t a really clear relationship between volume, quality and the bottom line. Alyson Riley and her colleagues at IBM pointed out that:
“Our industry as a whole is starved for data that prove the business value of content—particularly post-sales technical content—using facts that resonate with our colleagues in business strategy, finance, sales, product management, and marketing.”
Faced with this lack of ‘true stories’ Riley and her colleagues set about surveying IBM prospects and customers and found that customers put a great deal of weight on the importance of technical information. Ninety percent of respondents agreed that good quality documentation was ‘Important’ or ‘Very important’ in making a purchasing decision.
But surveys of this kind are problematic, because they don’t tell us how good quality documentation fits into the other criteria a purchaser may be weighing up. It may be important in isolation, but is it more important than product capabilities, support, price or development of custom features? How good does technical content need to be to attract and retain customers, and, in terms of missing, inaccurate or hard to read documentation, how little can you deliver before customers vote with their feet?
But don’t despair – a content business case may be slightly different, but there is still compelling information you can pull together to make your case:
Metrics don’t need to be complex
There are some very sophisticated ROI (return on investment) models that have been developed, especially relating to DITA and content reuse, but they sometimes require a lot of information that you may not have, or that is difficult to acquire (the salaries of your work colleagues, for example).
But it’s never too late to begin gathering metrics – and as the project takes shape, you will need to be able to monitor the status of the project against baselines.
It may be useful to assess:
- Time spent on new content: for writers to be using their time well, we want them to be working on new material – the material that will explain the new features and improve user understanding of existing ones. All too often, however, authors spend a disproportionate amount of time on the administration of content – chasing and managing review content, uploading finished documents to multiple storage locations. It may not sound much, but one organisation I worked with had a publications process that was so complex and error prone that we worked out they were losing an entire person-year to admin.
- Support call impact: If you have a support organisation, ask them if they already track cases of ‘user error’. The classification they use may vary, but we are looking for calls that have been triggered by misunderstanding or misuse of the product, that could have been prevented by documentation. Whether they have the data to hand or not may depend on their knowledgebase solution and current priorities – but it’s potentially an easy proxy for document quality and effectiveness. Building relationships with the support organisation is a great way to understand whether your content is doing its job – but when it comes to building a business case it’s a valuable source of tangible data.
These two factors are easy to measure, easy to track and quickly start to create a picture of the costs and the value of content.
Take a holistic view
It can be very frustrating when the business can’t see the relevance of issues that affect you every day. Your concerns need to line up with company goals if they are to get the ear of a decision-maker, but thinking long term your concerns need to line up with company goals because if they don’t, they’re a bad choice for the company.
So we need to look outward, and upward, when we think who is involved in creating content. It’s rare that technical authors work in isolation – typically they need the support of engineers, developers and product managers, all of whose time is valuable. The division of labour varies – sometimes subject matter experts (SMEs) draft the bulk of the content for technical authors to ‘tidy up’ sometimes the authors drive the process and SMEs are responsible for fact checking and filling in the gaps. Whatever the process, time spent checking and contributing to documentation somehow falls through the cracks, not significant enough to make it onto a timesheet or register as a major cost – even though it is time spent by valuable personnel. And often these valuable personnel are not given the tools to do the job efficiently – so time is wasted moving Word documents around or ‘translating’ the content from one particular presentational format to another. With a recent client, we calculated that 30 support engineers were spending 20% of their time contributing to content. If we accept typical industry figures that around 30-50% of a knowledge worker’s time is spent making their documents ‘look good’ (or, rather, using the presentation to make sure it says what they want it to say) that equates to two person-years that could be spent on more fruitful tasks.
Look to the internal customer
It’s slightly paradoxical that the metrics we seek, to justify a content solution, could be provided by that very solution. Modular XML content, supported by taxonomy and delivered dynamically, can give us invaluable insights into what customers do, and do not find useful.
Meanwhile though, the age-old problem of user feedback continues to plague authors. If it feels like content disappears into the ether when authors have finished writing it, look to internal customers, who are often more numerous and easier to contact. A field service engineer whose KPIs (key performance indicators) are based on how quickly they can close a service request; a support agent; a salesperson who needs to give an accurate account of a product’s capabilities, or details of a procedure to give a product demo. All of these people can help provide feedback and add value to your content.
Being right is not enough
Gathering and preparing evidence is just one part of building a business case. Business cases can be rejected for very good reasons – the level of ROI is not appealing, or the business just does not have sufficient cashflow to enable such investment. That can be a matter of timing or luck, but there are other reasons for an apparently valid business case being rejected. Thinking about the project as a real project (rather than a beginning and an outcome) gives your business case a better chance of becoming a reality – but it also gives the project itself a fighting chance of becoming successful. Depending on which research you read, the percentage of IT projects that fail varies – some sources suggest a failure rate of 87%, and many of those failures can be traced back to a business case that should never have been signed off in the first place.
Here are some additional points to consider:
Validation: the ‘spotlight effect’ is a phenomenon in human thinking that makes us give undue focus to the options we’re aware of – leading us to leave out other, possibly better options we have ‘missed’. An example of this would be options you may have seen but discounted, which results in their exclusion. The business case process however, often allows other stakeholders more time to reflect on all the options; this can lead to them challenging your thinking.
Scope: when the brief is to ask for investment, with a particular result in mind, it’s easy to focus on the ‘What’, the ‘How Much’ and the ‘Why’ – and miss the ‘When’, the ‘Who’ and the ‘How’. But unclear scope is often cited as a reason that business cases get rejected. Last year, when Mekon was putting together the business case for a large manufacturing customer, we were careful to include:
- Our methodology behind choice of the tools
- How the solution could be rolled out – and which business areas were out of scope
- What the overall benefits could be for each phase
- How long we felt it was likely to take
- What the potential limitations were
These are things you may need to refine as the project progresses, but thinking in advance and articulating them means you have something to work from and provides some founding principles that will allow you to measure success and anticipate problems.
Audience: as with any piece of writing or communication it’s important to know your audience – not just in terms of level of detail or terminology, but also because you need to put your case in ways that resonate. You may also need to choose your audience carefully. Business cases often get trapped in a chain of command – it gets past your manager, and your manager’s manager but then gets stuck, either because it’s not getting sufficient time and consideration or because the person being asked to assess it can’t relate it to their immediate concerns.
Buy-in: often when we think of business cases, we think of something that’s directed upwards – towards the decision makers. But for a project to actually succeed you need buy-in from all directions. If a project is supported by content creators on the ground, but not by managers, it is unlikely to be funded. But, if a project is supported by management but not by users, it may get funded but is likely to fail at implementation. Another aspect of buy-in to consider, is to examine whether you could form alliances with other parts of the business who would benefit from your project going ahead – for example technical support or sales and marketing.
Laying a secure foundation
IT projects often fail because of a disconnect between what everyone thinks is going to happen, what actually happens, and what really needed to happen. Working through the options, scope and requirements as well as the cost and benefits in your business case is an immunisation against that sort of common crisis.
If you have gathered robust evidence, validated your requirements, presented them effectively, and if there is the funding available to get the green light, your project will hopefully go ahead. That does not mean, however, that you can pull away from the traffic lights and leave the business case behind. Keep it as a live document and apply the PDCA model to it:
- Plan what needs to happen next
- Do what you planned
- Check the outcome
- Adjust your course if necessary
As author and business thinker Jed Simms says: “The business case is not a ‘hurdle’ to overcome, but (should be) a mechanism by which you explain, quantify and justify the true benefit and value of your project.”
This article was originally published in the ISTC Communicator, Summer 2016
About Rachel
Rachel Johnston MISTC is a consultant for Mekon, helping businesses to negotiate the changing landscape of information development and modernise their content, whilst keeping their sanity.
References and further reading
Riley A, Ames A L, Jones E‘Telling the Right Story: Proving the Business Value of Content’ Intercom http://intercom.stc.org/2013/05/telling-the-right-story-proving- the-business-value-of-content (accessed April 2016)
Potts R (2012) ‘Communicating value: part 1’ Communicator, Summer 2012: 17-19
Potts R (2013) ‘Communicating value: part 2’ Communicator, Spring 2013: 28-31
Potts R (2013) ‘Communicating value: part 3’ Communicator, Autumn 2013: 22-25 Simms J (2007) ‘Why Projects Fail Part 5: Poor Business Case’, CIO, July 2007