Documenting the Plan
After all the various requirements have been determined and the options thought out and decided on, put these decisions and requirements into a design document. The complexity of the project affects the size of the document and the effort required to create it. The intention is that this design document summarizes the goals and objectives that were gathered in the initial discovery phase and describes how the project’s result will meet them. It should represent a detailed picture of the end state when the new technologies and clients are implemented. The amount of detail can vary, but it should include key design decisions made in the discovery process and collaboration sessions.
The following list gives a sample table of contents and brief description of the design document:
• Executive Summary—Provides a brief discussion of the scope of the Lync Server 2013 implementation. It should also include a high-level overview of the business value.
• Goals and Objectives—Includes the 50,000-foot-view business objectives, down to the 1,000-foot-view staff-level tasks that will be met by the project.
• Background—Provides a high-level summary of the current state of the network, focusing on problem areas, as clarified in the discovery process, as well as summary decisions made in the collaboration sessions.
• Approach—Outlines the high-level phases and tasks required to implement the solution (the details of each task are determined in the migration document).
• End State—Defines the details of the new technology configurations. For example, this section describes the number, placement, and functions of Lync Server 2013.
• Budget Estimate—Provides an estimate of basic costs involved in the project. Whereas a detailed cost estimate requires the creation of the migration document, experienced estimators can provide order-of-magnitude numbers at this point. Also, it should be clear what software and hardware are needed, so budgetary numbers can be provided.
When developing the document further, one will want to add details in various sections to lay out the costs and benefits, as well as provide a long-term vision to the project. Consider including these details in the various sections of the document:
• Executive Summary—The executive summary should set the stage and prepare the audience for what the document will contain, and it should be concise. It should outline, at the highest level, the scope of the work. Ideally, the executive summary also positions the document in the decision-making process and clarifies that approvals of the design are required to move forward.
• Goals and Objectives—The goals and objectives section should cover the high-level goals of the project and include the pertinent departmental goals. It’s easy to go too far in the goals and objectives sections and get down to the 1,000-foot-view level, but this can end up becoming confusing; so it might be better to record this information in the migration document and the detailed project plan for the project.
• Background—The background section should summarize the results of the discovery process and the collaboration sessions, and can list specific design decisions that were made during the collaboration sessions. Additionally, decisions made about what technologies or features not to include can be summarized here. This information should stay at a relatively high level as well, and more details can be provided in the end state section of the design document. This information is useful as a reference later in the project when the infamous question “Who made that decision?” comes up.
• Approach—The approach section should document the implementation strategy agreed upon to this point, and should also serve to record decisions made in the discovery and design process about the timeline (end to end and for each phase) and the team members participating in the different phases. This section should avoid going into too much detail because in many cases the end design might not yet be approved and might change after review. Also, the migration document should provide the details of the process that will be followed.
• End State—In the end state section, the specifics of the Lync Server 2013 implementation should be spelled out in detail, and the high-level decisions that were summarized in the background section should be fleshed out. Essentially, the software to be installed on each server and the roles that will be installed on each server are spelled out here, along with the future roles of existing legacy servers. Information on the clients that will be supported, policies that will be enforced, and so on should be in this section. Diagrams and tables can help explain the new concepts and show what the solution will look like, where the key systems will be located, and how the overall topology of the implementation will look. Often, besides a standard physical diagram of what goes where, a logical diagram illustrating how devices communicate is needed.
• Budget Estimate—The budget section is not exact but should provide order-of-magnitude prices for the different phases of the project. If an outside consulting firm is assisting with this document, it can draw from experience with similar projects of like-sized companies. Because no two projects are ever the same, there needs to be some flexibility in these estimates. Typically, ranges for each phase should be provided. The goal is for the audience of the document to understand what the project will cost and what they are getting for that money. This is also a great place to point out anticipated returns on investment (ROI) because these often act as the primary justification for a Lync Server 2013 implementation. See Chapter 4, “Business Cases for Lync Server 2013,” for a full list of business cases and value propositions for Lync Server 2103.