Phase I: Preparation 1
Introduction 1
Project Overview 1
Mission Statement 2
Define Prioritized Project Goals 2
Create Business Plan 3
Identify Project Team Players 5
Identify the Sub-team Members 9
Milestone I: Review Preparation and Approve Planning Phase 10
Introduction
The dramatic explosion of the PC industry has had a tremendous effect on the business computing and information services needs for large corporations. The demand for more information, faster, to a wider range of employees within a corporation has rapidly moved the corporate computing environment away from mainframe-based terminal sessions. The current environment uses client-server computing with intelligent, graphical desktops and workstations, which communicate with local and divisional PC-based servers. These servers store data and communicate with the mainframe and network systems in the corporation. Today, with the rapid expansion of the Internet and Intranet services, once again the computing metaphor is being reinvented. Information services now may be published within the department, the division, or the enterprise on the Intranet, or external to the corporation on the Internet. How can a large corporation keep up,and anticipate the changes to meet these demanding business needs?
The accelerating changes in the computing environment are often diametrically opposed to the schedules, the structure, and proven methods of corporate computing standards. There are a number of different ways that corporations choose to beta test, evaluate, pilot and deploy new technology. However, at a macro level, the deployment strategies tend to be relatively similar across corporations.
The goal of this document is to help the network administrator, the information services professional, and the consultant to assist corporations in their planning for a large deployment of Microsoft® Windows NT® Server-based technologies. Many different topics and strategies are offered for consideration. Based upon the authors’ many years of working with corporate computing environments, the greatest concern of network administrators planning a corporate rollout is not necessarily about what they have documented. It is more likely, what they fear they have forgotten to consider. Experience can be an unforgiving teacher. This document will present a number of different things that may need to be considered for your own deployment. Certainly, there will be topics that do not directly apply to your specific situation, however, it will provide another point of view against which to check your own plans. For those network administrators moving toward a standard deployment process, perhaps this document can provide you with some template information.
P t
Project Overview
Before embarking on this project, you will want to carefully review your own project goals and objectives, to keep them in mind, so that the information you read can be directly applied. In some cases, readers have elected to write notes in the margins to start outlining their own specific plans for their project(s). We will want to start at the beginning, with a mission statement that can be used to keep the focus on the project. Then we will itemize our project goals, once again to keep a very clear view of what will be accomplished (and those issues that will not be addressed). In some cases, the definition of what will not be addressed is as important as the definition of what will be addressed.
Once we have our objectives, we will create the business plan and identify the probable resources of the team for the project.
Mission Statement
The mission statement for the project needs to be a clear and concise definition of the project goals and priorities. It needs to be clearly articulated by members of the team, and make meaningful sense to external individuals, especially senior management. Avoid using acronyms and jargon whenever possible.
Define Prioritized Project Goals
Due to the number of different people and departments affected by any change to the computing platform, it is important to have a clearly defined set of project goals that closely map to the overall mission statement. By having these project goals defined, the process of either approving or rejecting any requests for changes becomes a much quicker and simpler task. An easy, standard response to those requesting changes is that their request does/does not fall within the defined project goals, and will/will not be reviewed further. The goals should be measurable, and the intangibles should be estimated. By defining the goals in this manner, the process of the project review can rate the measurable and estimate the intangible benefits.
Although the process of defining project goals may seem a bit formal, or belaboring, the benefit of the process is realized during the course of the last-minute changes, and requests for special handling. It allows the project to stay on-track without offending those making requests, as they can recognize the process and organization that is in place.
Measurable
The measurable goals should map first to the overall goal of the company, and second to the direct customer benefit, be that the employee customer, or the ultimate consumer of the company’s product or service.
Business benefit
This goal should be focused on the overall goal of the company, such as:
“The ability of the marketing teams to have direct access to sales and competitive data will reduce the response time for the team’s pricing model from 7 days to no more than 3 days.”
“The ability for the research and development teams to have direct, secure access to the Internet will reduce the research time by 20%, the lost time due to travel by 33%, and a cost savings of $36,000 per annum.”
“77% of information employees thought they were at least adequately trained for using their computer services. Only 10% thought they were proficient at their electronic desktop. We will have over 50% agreeing that they are “proficient” at their desktop skills, and over 90% stating that they are at least adequately trained on their desktops.”
Goals such as these listed are clearly measurable, and can be tracked as hard data.
Customer benefit
The customer benefit depends on the project’s definition of the customer. Goals may be defined as:
“An employee survey in [Month/Year] showed that 47% of the employees felt that [computer project] helped them be more efficient in their work. Our goal with this updated project is to reach 75% of employees responding favorably to the survey 3 months after the completion of this project.”
“A customer survey in [Month/Year] indicated that 22% of customers thought that our customer service was “outstanding”, and that 31% rated our service as “satisfactory.” The goal of this project is increase the efficiency of our customer service to have a rating of 35% as “outstanding”, and 50% as “satisfactory.” This survey is being issued 4 months after the conclusion of the project.”
“Customer call tracking over the 3-month period of [Months/Year] shows that we have a call-dropoff of 13% in the peak call volume hours of 11a.m. - 2p.m., with an average wait time of 7 minutes, and a total call time of 13.2 minutes. The increased efficiency of this new system will reduce the call-dropoff to no more than 5%.”
Intangibles
The intangible benefits are, by definition, more difficult to measure. However, their value should not be underestimated. In some areas, the specific project does not directly affect their position to the same extent as other areas. However, general surveys by the company can reflect the overall attitude of the employees towards the IT/IS group. Definitions of intangibles might be defined as follows:
“June’s semiannual employee survey found that 18% of employees thought that Information Technology Services made them more productive at their jobs. Our goal is to increase that level to 36% in the next review period, and 50% by next June’s survey.”
“General attitude toward Information Services has been one of hostility and frustration. Within 3 months of the project completion, the general attitude will be one of respect and cooperation.”
Create Business Plan
The business plan for the project is going to be widely read, by all kinds of audiences. It needs to contain articulate, factual, and brief information. Depending on the corporate format, there may be an executive summary section. However, many good business plans are brief enough not to need an executive summary.
Situation
The Situation is just the facts about the current condition. For example,
We are presently supporting four different network operating systems, and five networking protocols.
XXX Network Operating System has been classified as “obsolete,” and YYY NOS has been degraded to “legacy.”
Training costs have soared 75% over budget to cover additional courses for different networking systems.
System Down/Crash reports for XXX NOS servers have increased 25% in the last 3 months, at an estimated cost of $250 per incident for a total increase of $10,000 in a 3 month period.
The Network ’99 plan directs us to consolidate file, print, and application servers on the Windows NT Server platform as soon as reasonably possible.
Opportunity
Opportunity is the response to the current situation. It is not the plan, just a specific note to highlight the practical, possible solutions that are being recommended.
“We can migrate from supporting four different network operating systems to two, and from five protocols to just two (TCP/IP and SNA™), which will reduce our overall network traffic by 12%.”
“Migrate the NetWare® 3.x servers to Windows NT Server 3.51. Estimated administrative cost reduction of 20%, reduce the number of servers by 29%, reduced software cost of 38% versus upgrading to NetWare 4.x.”
“Reduce training costs by reducing the number of new technicians trained on legacy and obsolete systems.”
“Stabilize the network by using more reliable, fault-tolerant systems.”
“Move forward on the Network ’99 plan by reducing the number of supported network operating systems, consolidating networking services on larger, multipurpose, scaleable, and fault-tolerant servers.”
Risk
Risk is the identification of key unknown factors not obvious in the situation or opportunity sections. Oftentimes this is where specific issues to the company or scheduling may surface.
“Moving away from the legacy, obsolete systems could produce unexpected problems due to the complexity of some of our custom, legacy applications.”
Plan
This section of the business plan is not to give detailed information about the deployment or other specifics. Rather, it is the high-level summary of the planned changes to the computing environment. For example:
“Get primary support staff certified on Windows NT Server and Microsoft SQL Server™ within the next 3 months. Estimated cost is $15,000.”
“Have the secondary support staff trained on supporting Windows NT Server, SQL Server and SNA Server. Windows NT Server training will be completed in 2 months, SQL and SNA will be completed within four months of project start. Estimated cost is $21,000 for outsourced group training on-site.”
“Migrate the NetWare servers to Windows NT Servers in a staged process over a 6 month period. Cost is ~$1350 per server, for 120 servers, for a total cost of $162,000.”
“Migrate the database servers to Windows NT Servers in the customer service areas. This project may take 8 months, due to business-critical periods where no changes will be made to their computing environment. Cost is ~$ 1,500 per server for 25 servers, for a total cost of $ 37,500.”
|
