The assessment team members
consist of all stakeholders in the computing environment. There is no
magic checklist here that will cover all businesses and situations. I
have conducted assessments for large companies that filled a large
conference room with participants, as well as for a small government
entity where the entire team consisted of two people. You simply must
involve all stakeholders in the project; that is, those who can add
value to the total project. In addition to adding value, this team
becomes part owners in the project. Because they have ownership in the
project, they have incentive for it to be successful. The list shown
here includes the areas of responsibility that were included in typical
assessments I've been involved in:
Consultant:
No, this isn't a marketing statement! A knowledgeable consultant is
important to the success of the migration. This is a person who has had
verifiable experience in conducting a migration, has a few battle scars
that you can learn from, and can guide the project. This person also
serves as a valuable third party who can see things from an unbiased
viewpoint and render an opinion without any preconceived ideas. The key
word of course, is knowledgeable. One
of the most frequent calls coming to our support center begins, “We
hired a consultant to set this up and we can't find him and we don't
understand what he did.” You must verify the consultant's credentials.
Network administrator:
This might include more than one person. Depending on the size of your
organization, you might have different individuals responsible for the
physical network (hardware, routing, and so on), another for Dynamic
Host Control Protocol (DHCP) administration, another for DNS (Domain
Name Server), another for Windows Internet Name Service (WINS), and so
forth. Although you want to avoid a cast of thousands that will
complicate the meeting, you also want to make sure you have the right
people involved. One company identified two people who had a good
knowledge of the network infrastructure, and included only those two
individuals rather than the 10 or so who worked under them. They could
contact others if needed or invite them to the meetings.
System Administrators:
This should be limited to a single Administrator if possible. This
person has a good overall view of the enterprise and is responsible for
gathering security practice standards and identifying trouble spots, and
has a good overall view of the enterprise. The system Admin can be an
invaluable asset, and in fact might well be the person charged with the
migration, especially in small organizations.
Workstation manager:
Medium and large organizations typically have a person who is
responsible for the workstations in the user community. This is a key
role in the migration because it involves developing a staging plan to
migrate the users, as well as identifying users that can assist in the
pilot. If the end users are not satisfied with their workstations after
being migrated, then a whole migration can be unsuccessful. Involving
someone with intimate knowledge of the workstation environment and the
users will mitigate this problem.
Mail and messaging:
Whether you are using Exchange of some flavor or another mail and
messaging system, the Administrator for those systems must be on the
team.
Development team:
If your organization has a development team that builds applications, it
has a stake in the migration. These team members will provide input for
critical or mission-critical apps that they are responsible for
maintaining and testing in the new environment.
Projects:
Leaders of special projects, such as research groups, should be involved to minimize the impact on current projects.
Management:
Others you might want to involve include members of quality assurance
(if there is one), human resources (HR), information technology (IT),
and corporate management. A key member of the project team, the
management sponsor, has a role on the assessment team to ensure that the
data is gathered without interference.
The following lists contain descriptive titles of
members of migration teams used by three different companies. There is
no set list of people who should be on the team as this varies with each
organization. However, these lists should give you an idea of whom you
might want to include in your organization. Note that no association
exists between these titles and the type of industry the company is in.
So, although Company B is a hospital, it doesn't necessarily mean that
other healthcare organizations would use this list of titles to form the
team. Rather, it is simply intended to give you an idea of staff
positions that others have used to get you started on filling your
design team.
Company A:
Consultant Desktop Architect Security Administrator PKI Administrator DNS, DHCP, WINS Administrator Windows NT Administrator Desktop Help Desk Lead Network Administrator Network Security Director Network Manager Mail and Messaging Administrator
Company B:
Windows NT Administrators (and Exchange Admins) Manager, Network Infrastructure Manager, Information Technology Director, Information Technology Project Manager, Research & Development Domain Administrator, Research & Development Manager, User Workstations Network Administrator (Infrastructure, DNS, DHCP) Security Administrator Application Development Manager
Company C:
Project Manager Management Sponsor Consultant Remote Access Administrator Application Development Help Desk Director IIS Administrator Security Director Transition Team Lead DNS, DHCP, WINS Admin SMS Admin Manager, Desktop Group Network Infrastructure Manager Domain Administrator Change Management Manager Policies/Standards/Implementation Director
Note that Company C, a large global corporation,
lists titles or group names of its design team, rather than individual
titles used in the other companies. Note the inclusion of Project
Management and Project Lead for Company C, as well as Change Management
and Policies/Standards/Implementation. Company C also assigned team
members to fill Windows 2000-related roles, such as Enterprise
Administrator, Organizational Unit (OU) Structure Manager, and so on.
Thus, the Windows 2000 administration roles were filled during the
design phase of the project.
Your design team is responsible to set goals and
define deliverables as a result of the design. This provides focus and
allow you to set measurable criteria when reporting progress to upper
management. Some of these goals might include solutions to certain
problems, greater capacity, cost savings, Return on Investment (ROI),
and improved security. Be as specific as you can in setting these goals.
With the goals established here, you will then
perform the assessment, identify Windows 2003 benefits, and make
recommendations. The goals should be specific enough to be measurable
for ROI calculations as well as specific enough to help you identify the
recommendations you want to make. If you do it right, the
recommendations will simply be a list of “How To” instructions on
achieving the goals in this section. Some examples of goals include
Reduce support costs by upgrading clients to Windows XP Reduce
domain and network administration costs by implementing a sophisticated
(third-party) management tool, and training the IT staff on its use Improve
disaster-recovery process to restore a DC or GC by implementing the
Install from Media (IFM) feature in the recovery process Reduce
network bandwidth requirements and thus improve overall network
performance by implementing Windows Server 2003 and its more efficient
AD replication algorithms Reduce need for
GCs at remote sites, or reduce network traffic caused by user logons at
sites without GCs, by implementing Universal Group Membership Caching
I have taken Windows Server
2003 features that I believe will give specific benefit to the
infrastructure, and stated them as goals and how the goals will be
achieved. These goals can now be assigned to specific members of the
design team to incorporate in their action plan.
|
