IA Project Phase I Information Plan

Phase I - Information Plan

Table of Contents

• 1. Information Plan
  • 1.1. Goals and Objectives of the Development Project
  • 1.2. Goals and Objectives for the Publications
  • 1.3. Preliminary User Profile
  • 1.4. High-Level Task Analysis
  • 1.5. Design Implications and Publications Strategy
  • 1.6. Preliminary Media Selection
• 2. Project Plan
  • 2.1. Estimate of Scope and Complexity
  • 2.2. Estimate of Time and Budget
  • 2.3. Estimate of Required Resources
  • 2.4. Milestone Schedule
  • 2.5. Roles of Responsibilities of Team Members
  • 2.6. Production Plan
  • 2.7. Localisation & Translation Plan
  • 2.8. Testing Plan
  • 2.9. Maintenance Plan

1. Information Plan

The Information Plan ... is the primary document you will use to plan how to manage the publications project, providing the basis for your preliminary estimates of the schedule and budget needed to complete the project.

1.1. Goals and Objectives of the Development Project

The project is intended to improve the overall quality, readability, and usability of the existing documentation suite. There is no associated development project.

1.2. Goals and Objectives for the Publications

The current publications contain a significant amount of information, across four books. However, over time, the books themselves have become disorganised and content is now broken up in sometimes unpredictable ways. This has resulted in significant duplication of content, as well as making it difficult to identify areas of missing content.

This project intends to reassess the documentation suite from a user perspective. Once the primary personas have been identified, a user task analysis will need to be performed in order to determine the best possible organisational structure for the content.

Additionally, the books need to have a good structure in order to aid eventual contributions from the Uyuni open source community. This will have an impact on the way the books are developed, as there is a requirement to maintain both community and enterprise versions of the same documents.

While it is noted that the eventual goal of this suite is to have it operate under a fully reusable topic-based system, following the Every Page is Page One model developed by Mark Baker, this is somewhat outside of the scope of this project. If this project is successful, however, moving to this documentation model will be significantly easier in the future.

1.3. Preliminary User Profile

There are two main audience types for this documentation: users of the product, and those seeking general information about the product. The majority of the audience falls into the former category, and this category are also more likely to be spending large amounts of time with the documentation, and return to the documentation again and again.

For those seeking general information about the product, it could be that they will later turn into users of the product, or are in a position of influence to grow the number of users of the product. For this reason, it is important that the documentation begins with clear descriptions about the product, the underlying technologies, and how the product works, in order to assist these readers with their decision making.

For users of the product, the documentation must be accurate, and well organised. This will assure these users that the documentation is a canonical source of truth, aid them will navigating the documentation, and ensure they continue to refer to it as they use the product.

There is also a certain halo effect here: documentation quality reflects product quality. Therefore, good documentation can help users perceive the product in a better light. Conversely, poor documentation is likely to cast the product in a poor light also.

1.4. High-Level Task Analysis

• Product Research

• Planning for installation

• Creating an account/signing up with SUSE

• Installing base software

• Installing clients

• Updating base software

• Managing clients

• Managing base software

• Other client administration tasks

• Troubleshooting

1.5. Design Implications and Publications Strategy

Options:

• Standard publications strategy, as previously used (Book suite, published as PDF, HTML, HTML-Single using adoc and Daps toolchain)

• Standard pubs strategy + improved search (Algolia)

• Publication using a static site generator (Antora), incorporating CI and improved search, maintaining existing adoc/Daps toolchain where possible.

• Topic-based/EPPO publication, with full CI.

Considerations:

• Consider impact on external, community-based contributors

• Quality internal search can reduce our reliance on great IA

• Quality internal search & CI are imperative for a complete topic-based/EPPO style publication format, even if we don’t implement that format immediately, but intend to in the future

• Static site generation allows us to implement CI, which can greatly improve the time lag between having access to new information, and making that information available to readers …​

1.6. Preliminary Media Selection

TODO: Joseph

2. Project Plan

The Project Plan takes the creative ideas of the Information Plan and sets a course for their development ... A Project Plan that carefully specifies what can be built in the allotted time and at the designated level of quality removes some of the risk.

2.1. Estimate of Scope and Complexity

On the face of it, this project contains no new content, merely a reorganisation of existing content. However, that view is somewhat misleading. A preliminary review found that, while there is a significant amount of task and reference content already in existence, there is very little concept information. For that reason, it must be assumed that the rework will identify areas of content that need to be written from scratch. This is likely to be offset by the fact that there is almost certainly some duplication of existing content, which can be streamlined in the rework.

Therefore, we can make some assumptions:

• The Reference Guide will remain as-is, with no further modifications

• The existing Getting Started and Best Practices Guides will be rearranged into three new books, with the preliminary titles Getting Started Guide, Installation Guide, and Client Configuration Guide.

• The three new guides will be roughly equivalent in size to the existing two guides (noting earlier caveats)

• The main complexity of this project will stem not from writing new content, but primarily from rearranging that content effectively. Tracking that work is likely to be time consuming, and will require a novel approach.

2.2. Estimate of Time and Budget

Ideally, this work will be completed for the release of SUSE Manager 4. We do not currently have an expected release schedule for this, but can make the assumption that it will be around the middle of 2019. Therefore, we have scheduled 11 months for this project, beginning in August 2018 and completing in July 2019.

Budget is not being tracked in dollar terms for this project.

2.3. Estimate of Required Resources

Very little in additional technical resources are required at this stage, as existing test suites and equipment can be used. However, the technical delivery details may require additional resources, as follows:

TODO: Joseph

2.4. Milestone Schedule

Table 1. Overview of Project Schedule and Major Milestones

Milestone	Start	End
Phase 1	6 Aug 18	31 Aug 18
Phase 2	3 Sep 18	2 Nov 18
Phase 3	5 Nov 18	26 April 19
Phase 4	29 April 19	28 June 19
Phase 5*	1 July 19	26 July 19

Note that Phase 5 is an evaluation phase, and can be completed after publication. This plan assumes an end-June 2019 release date.

2.5. Roles of Responsibilities of Team Members

Joseph Cayouette: Tool-chain and production Lana Brindley: Writing and project management Karl Eichwalder: (80%) Additional assistance as required

Note that other documentation tasks are of greater importance than this project, and will always be prioritised.

2.6. Production Plan

TODO: Joseph

2.7. Localisation & Translation Plan

There are no localisation or translation planned for this project.

2.8. Testing Plan

• Document to be distributed internally to both the SUSE Manager and general documentation teams for review prior to release

• Limited beta review period for Uyuni community members and VIP SUSE Manager customers to be considered

2.9. Maintenance Plan

• After completion, this documentation suite will form the main bnody of documentation for SUSE Manager and Uyuni, and as such maintenance will become the primary focus of this team.