Build Application Documentation Template Sections from Each Critical Stakeholder's Requirements

This chapter explains how to build the Application Documentation Template from the documented requirements of the stakeholders who depend on Application Documentation, and how those stakeholders then review it.

Who the Critical Stakeholders Are

Application Documentation is used by many groups, each of which depends on particular information to do its job. Typical critical stakeholders include:

• The business organizations the Application serves.

• IT leadership.

• Enterprise Architecture.

• Software Development and Engineering.

• Quality Assurance.

• Security.

• IT Operations and Support.

• Business Continuity and Disaster Recovery.

• Risk and Compliance.

Each enterprise should identify its own critical stakeholders; the list above is a common example that IF4IT recommends and that enterprises can customize.

Establish Template Sections from Stakeholder Requirements

Have the template owner collect, from each critical stakeholder, the specific information that stakeholder needs about every Application in order to do its work. Each stakeholder’s requirements then become a section, or a set of fields within a section, of the Application Documentation Template. For example, Operations and Support’s requirements shape the operational sections, Security’s shape the security sections, and Business Continuity and Disaster Recovery’s shape the recovery sections.

Stakeholders should state what they genuinely need, not everything that might conceivably be useful. Requirements that place an unreasonable burden on Application teams, for example by duplicating information held elsewhere or demanding detail no one will use, should be challenged by the template owner and resolved before they become part of the template.

Document and Share Stakeholder Ownership of Each Section

Record, in the template itself, which stakeholder owns the requirements for each section. That stakeholder then reviews its own section of each Application’s documentation at every Release, to confirm that it has received the information it needs from the Application Manager. Because each stakeholder checks only its own section, reviews stay focused and fast.

Best Practice: Build Template Sections from Documented Stakeholder Requirements

It is a best practice to both establish and document the solution for what the template requires: collect each critical stakeholder’s documentation requirements, turn them into template sections, record which stakeholder owns each section, and have each stakeholder review its own section at every Release.

Benefits: Building the template from stakeholder requirements ensures that it asks for information someone actually depends on, which makes completing it worthwhile rather than bureaucratic. Giving each stakeholder ownership of its own section means that the people best qualified to judge each kind of information are the ones who check it.

Common Antipatterns

Advance Maturity Deliberately: Crawl, Walk, Run

• Crawl. Stakeholder requirements are collected informally; each stakeholder signs off manually on its section for each Release.

• Walk. Stakeholder requirements are documented and versioned with the template; stakeholder reviews are built into the Release process as checklist items.

• Run. Completeness of each stakeholder’s section is checked automatically at each Release, and stakeholders review only the content that has changed.

Connections to Related IF4IT Practices and Inventories

The Release Management Best Practices describes the Release process into which stakeholder reviews are built. The Systems Development Lifecycle (SDLC) Best Practices addresses roles and accountability across the lifecycle.