With
the completion of the discovery process and documentation of the
results, it should now be very clear what you have to work with in terms
of the foundation the new solution will be implemented upon.
Essentially, the research is all done, and many decisions will now need
to be made and documented.
By now, a dozen
documents could be written; however, the most important document that
needs to be created is the design document. This document is a log of
the salient points of the discussions that have taken place to date; it
should make very clear why the project is being invested in, describe
what the scope of the project is, and provide details of what the
results will look like. A second document that needs to be created is
the migration document, which provides the road map showing how this end
state will be reached.
Often, companies strive for an
all-in-one document, but as explained in the next section, there are
specific advantages to breaking up this information into two key
components. A simple analogy is that you want to agree on what the floor
plan for a house will look like (the design) and what the function of
each room will be before deciding on how to build it (the
migration/implementation).
Collaboration Sessions: Making the Design Decisions
The design team is most
likely not ready to make all the decisions yet, even though quite a bit
of homework has already been done. A more formal collaborative and
educational process should follow to ensure that the end state of the
project is defined in detail and that the design team members fully
understand the new technologies to be introduced. The collaborative
process involves interactive brainstorming and knowledge-sharing
sessions, in which the stakeholders work with facilitators who have
expertise with the technologies in question.
Ideally, a consultant
with hands-on experience designing and implementing Windows Server 2008
R2 will provide leadership through this process. Well-thought-out
agendas can lead the design team through a logical process that educates
them about the key decisions to be made and helps with the decisions.
Whiteboards can be used
to illustrate the new physical layout of the Windows Server 2008 R2
environment, as well as to explain how the data will be managed and
protected on the network. Notes should be taken on the decisions that
are made in these sessions. If the sessions are effectively planned and
executed, a relatively small number of collaboration sessions will
provide the key decisions required for the implementation.
With effective
leadership, these sessions can also help establish positive team
dynamics and excitement for the project itself. Employees might feel
negative about a major upgrade for a wide variety of reasons, but
through contributing to the design, learning about the technologies to
be implemented, and better understanding their own roles in the process,
attitudes can change.
Through
these sessions, the details of the end state should become crystal
clear. Specifics can be discussed, such as how many servers are needed
in which locations, which specific functions they will perform (file and
print or application servers, firewalls, and so on), and which key
software applications will be managed. Other design decisions and
logistical concerns will come up and should be discussed, such as
whether to use existing server and network infrastructure hardware or to
buy new equipment. Decisions also need to be made concerning secondary
applications to support the upgraded environment, such as tape backup
software, antivirus solutions, firewall protection, and network
management software.
Ideally, some of the details of
the actual migration process will start to become clear. For instance,
the members of the testing and deployment teams, the training they will
require, and the level of involvement from outside resources can be
discussed.
Organizing Information for a Structured Design Document
The complexity of the project
will affect the size of the document and the effort required to create
it. As mentioned previously, this 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 devices
have been implemented. The amount of detail can vary, but it should
include key design decisions made in the discovery process and
collaboration sessions.
The following is a sample table of contents and brief description of the design document:
Executive Summary— Provides a brief discussion of the scope of the Windows Server 2008 R2 implementation (what are the pieces of the puzzle).
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 will be 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 Windows
Server 2008 R2.
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.
The 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, what the scope of the work is. 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.
The 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 very confusing, so this information might
better be recorded in the migration document and the detailed project
plan for the project.
The 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 extremely useful to have as a reference to come
back to later in the project when the infamous question “Who made that
decision?” comes up.
The Approach
The approach section
should document the implementation strategy agreed upon to this point,
and will 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.
The End State
In the end state section,
the specifics of the Windows Server 2008 R2 implementation should be
spelled out in detail and the high-level decisions that were summarized
in the background section should be fleshed out here. Essentially, the
software to be installed on each server and the roles that Windows
Server 2008 R2 will play (global catalog servers, domain controllers,
DNS services) are spelled out here, along with the future roles of
existing legacy servers. Information on the organizational unit (OU)
structure, group structures, and replication sites should be included.
Diagrams and tables can help explain the new concepts, and actually show
what the solution will look like, where the key network devices will be
located, and how the overall topology of the network will change.
Often, besides a standard physical diagram of “what goes where,” a
logical diagram illustrating how devices communicate is needed.
The Budget Estimate
The
budget section will not be 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 with 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.
Windows Server 2008 R2 Design Decisions
As the previous section
mentioned, the key Windows Server 2008 R2 design decisions should be
recorded in the design document. This is perhaps the most important
section of the document because it will define how Windows Server 2008
R2 will be configured and how it will interact with the network
infrastructure.
Decisions should have been
made about the hardware and software needed for the migration. They
should take into account whether the existing hardware will be used in
the migration, upgraded, left in place, or retired. This decision, in
turn, will determine how many server software licenses will be required,
which will directly affect the costs of the project.
The level of redundancy
and security the solution will provide should be detailed. Again, it is
important to be specific when talking about data availability and
discussing the situations that have been planned for in the design.
The server and other
infrastructure hardware and software should be defined in this section.
If upgrades are needed for existing hardware (more processors, RAM, hard
drives, tape drives, and so on) or the existing software (upgrades from
the existing NOS, server applications, and vertical market
applications), they should be detailed here.
Other key technologies such as
messaging applications or industry-specific applications will be
included here, in as much detail as appropriate.
Agreeing on the Design
The final step in the design
document process actually takes place after the document has been
created. When the document is considered complete, it should be
presented to the project stakeholders and reviewed to make sure that it
does, in fact, meet their requirements, that they understand the
contents, and to see whether any additional concerns come up that
weren’t addressed in the document.
Although it is unlikely that
every goal of every stakeholder will be met (because some might
conflict), this process will clarify which goals are the most important
and can be met by the technologies to be implemented.
Specific decisions
made in the design document that should be reviewed include any
disparities between the wish lists the stakeholders had and what the
final results of the project will be. Also, the timeline and high-level
budget should be discussed and confirmed. If the design document
outlines a budget of $500K for hardware and software, but
the stakeholders won’t be able to allocate more than $250K, the changes
should be made at this point, rather than after the migration document
is created. A smaller budget might require drastic changes to the design
document because capabilities in the solution might need to be removed,
which will have ripple effects throughout the project.
If the time frame
outlined in the design document needs to be modified to meet the
requirements of the stakeholders, this should be identified prior to
expending the effort of creating the detailed implementation plan as
well.
Bear in mind as well that the
design document can be used for different purposes. Some companies want
the design document to serve as an educational document to inform not
only what the end state will look like, but why it should be that way.
Others simply need to document the decisions made and come up with
budgetary information.
Having this level of detail
will also make it easier to get competitive bids on the costs to
implement. Many organizations make the mistake of seeking bids for
solutions before they even know what the solution will consist of.
