Making a business case for documentation, post 7 - Build your business case step-by-step
Ravi Murugesan — 
Lana Novikova This is the seventh post in a series about making a business case for documentation. We provide a step-by-step guide to building your business case.
In the previous posts, we discussed gathering all the data and doing the groundwork to create a business case. Now, it’s time to assemble your business case.
Define the scope and audience
-
Clarify whether the business case is for internal or external documentation.
-
Identify the primary users of the documentation.
-
Determine your role: a project member, an organization employee, or a community contributor.
Describe the current state and problems identified through research
We strongly recommend that you provide tangible facts about the current state of software documentation in your organization or project and how it affects various stakeholders based on the groundwork done previously.
In particular, describe the current processes around documentation, which framework or approach is used and what are the strengths and limitations of it. This could be anything from a formal standard like IEEE 829 to a more informal or ad hoc approach.
Answer the following questions:
-
Who is responsible for creating and maintaining documentation?
-
When is documentation created or updated in the software development lifecycle?
-
How is documentation reviewed and approved?
-
What tools and technologies are used for documentation?
-
How is documentation stored and accessed?
-
How does the current state of your documentation affect various stakeholders (developers, testers, users and support staff)? This could include impacts on productivity, efficiency, and overall satisfaction.
By providing concrete facts and figures about the current state of software documentation, we can build a strong business case for improvement. This will enable you to identify areas where investment in documentation can yield significant benefits for the organization and its stakeholders.
Propose solutions
-
Brainstorm and write down potential strategies to address identified challenges.
-
Consider improvements to:
-
Documentation processes and strategies.
-
Collaboration between developers and writers.
-
Tools and workflows.
-
-
Empower developers to contribute (e.g., through the use of templates and guidelines).
-
Outline any training or workshop needs.
Empower developers to write
One particularly useful strategy is to empower developers to write initial documentation by creating or using standardized templates and guidelines. This approach not only makes it easier for developers to contribute but also ensures consistency across all documentation efforts.
Regular workshops and training sessions on the best documentation practices can further help improve the quality of contributions from non-writers. These sessions should emphasize structured approaches, such as using templates to guide the documentation process, ensuring that even those without a writing background can produce high-quality content.
In addition to this, pre-commit or deployment checks, including project-specific Vale rules or checks by automated tools like Ekline, could act as an automatic docs reviewer or an additional quality gate.
For more insights, you can explore this slide deck on the writing process, which covers the importance of standardized documentation practices.
Outline expected outcomes and benefits
-
Detail specific improvements expected from implementing your proposed solutions.
-
Break down benefits by stakeholder group (e.g., developers, end-users, support team, management).
-
Define measurable success indicators (e.g., Reduce support tickets related to documentation by 30% within 6 months).
-
Describe how these outcomes will positively impact broader business goals (e.g., increased developer productivity leading to faster time-to-market for new features).
-
Provide estimated return on investments (ROI) or cost savings from the proposed improvements.
At this point, you’ve built a compelling business case for investing in documentation and aligning it with business goals. But to truly solidify your argument, you need numbers. Decision-makers often rely on concrete financial metrics to justify investments.
That’s where ROI comes in. How do you demonstrate the real value of documentation in ways that resonate with leadership? How do you quantify its impact on efficiency, cost reduction, and revenue?
In our next post, we’ll break down how to calculate the return on investment for documentation, so you can present a clear, data-driven case.
Text of article ©2025 Ravi Murugesan, Lana Novikova
Released under Creative Commons Attribution 4.0 International (CC BY 4.0)