Project Plan Mainx

rebelhammerSoftware and s/w Development

Nov 2, 2013 (4 years and 6 days ago)

335 views





C
LOUD
C
ONVERSION


P
ROJECT

M
ANAGEMENT
P
LAN








4/23
/2012

Version 1.0

MSIS 5133,Spring 2012

Vidal Jefcoat, Ramya Radhakrishnan, Rick Kennedy, Britt Gathright








Prepared for:

Progmanosu
i


Contents

List of Figures:

................................
................................
................................
................................
....
1

Charter:
................................
................................
................................
................................
..........
1

Scope:

................................
................................
................................
................................
............
1

Schedule:

................................
................................
................................
................................
.......
1

Cost:

................................
................................
................................
................................
..............
1

Quality:

................................
................................
................................
................................
..........
1

Human Resources:

................................
................................
................................
..........................
1

Communication:

................................
................................
................................
.............................
1

Risk:

................................
................................
................................
................................
...............
1

Procurement:

................................
................................
................................
................................
.
1

Executive Overview

................................
................................
................................
............................
2

Introduction to Project Plan

................................
................................
................................
................
2

Business Case

................................
................................
................................
................................
.....
3

Executive
Summary
................................
................................
................................
.........................
3

Issue/Problem Statement

................................
................................
................................
..............
3

Project Overview
................................
................................
................................
.........................
3

Solution Overview
-

................................
................................
................................
......................
4

Cost Benefit Analysis
-

................................
................................
................................
..................
6

CRITICAL ASSUMPTIONS AND RISKS
................................
................................
..............................
7

SWOT Analysis

................................
................................
................................
............................
8

Recommendations

................................
................................
................................
......................
8

Project Charter

................................
................................
................................
................................
...
9

Project Overview

................................
................................
................................
............................
9

Impact Statement

................................
................................
................................
.........................

10

Constraints and Assumptions
................................
................................
................................
.........

10

Project Scope
................................
................................
................................
................................

11

Financial Summary
................................
................................
................................
........................

12

Project Scope

................................
................................
................................
................................
...

16

Solutions Architecture
................................
................................
................................
...................

16

Architecture Overview

................................
................................
................................
...............

16

ii


Archit
ecture Decisions

................................
................................
................................
...............

16

Architecture Templates

................................
................................
................................
.............

18

Business Context Diagrams

................................
................................
................................
........

19

Use Case Model

................................
................................
................................
........................

20

Systems Context
................................
................................
................................
........................

21

Scope Management Plan
................................
................................
................................
...................

21

Introduction

................................
................................
................................
................................
.

21

Scope Management Approach

................................
................................
................................
.......

22

Roles and Responsibilities

................................
................................
................................
.............

23

Scope Definition

................................
................................
................................
...........................

23

Project Scope Statement

................................
................................
................................
...............

24

Work Breakdown Structure

................................
................................
................................
...........

25

Scope Verification

................................
................................
................................
.........................

28

Scope Control

................................
................................
................................
...............................

28

Schedule Management Plan

................................
................................
................................
..............

29

Schedule Management Approach:

................................
................................
................................
..

29

Milestones for the project:

................................
................................
................................
.............

29

Roles and Responsibilities:

................................
................................
................................
............

30

Schedule Control:

................................
................................
................................
.........................

30

Cloud Proj
ect Time Line Phase One:

................................
................................
............................

34

Cloud Project Time Line Phase Two:
................................
................................
............................

38

Project Quality Management Plan

................................
................................
................................
.....

42

Cost Management Plan

................................
................................
................................
.....................

45

Roles and Responsibilities

................................
................................
................................
.............

45

Cost Planning and Estimating
................................
................................
................................
.........

47

Cost Tracking

................................
................................
................................
................................

49

Human Resources Plan
................................
................................
................................
......................

53

Staffing Management Plan

................................
................................
................................
............

62

Communication Management Plan:

................................
................................
................................
...

65

Roles and Responsibilities
-
................................
................................
................................
............

65

Standards of Communication
-

................................
................................
................................
........

68

Channels of Communication

................................
................................
................................
..........

68

iii


Risk Management Plan:

................................
................................
................................
....................

69

Risk M
anagement Approach
................................
................................
................................
..........

70

Risk Assessment:

................................
................................
................................
..........................

71

Risk Monitoring and control Implementations:

................................
................................
...............

73

Procurement Management Plan

................................
................................
................................
.........

75

Introduction
................................
................................
................................
................................
..

75

Procurement Management Approach
................................
................................
..............................

75

Pre Project Procurement Items

................................
................................
................................
.......

75

Contracts

................................
................................
................................
................................
......

79

Contract Closure:

................................
................................
................................
..........................

82

Team Member Contributions

................................
................................
................................
............

83

















1


List of Figures:

Charter:

Ch.1
.
Ch.2
,
Ch.3
,
Ch.4

Scope:

S.1
,
S.2
,
S.3
,
S.4
,
S.5
,
S.6
,
S.7
,
S.8
,
S.9
,
S.10

Schedule:

Sch.1
,
Sch.2
,
Sch.3
,
Sch.4
,
Sch.5
,
Sch.6
,
Sch.7
,
Sch.8
,
Sch.9
,
Sc
h.10
,
Sch.11

Cost:

C.1
,
C.2
,
C.3
,
C.4
,
C.5

Quality:

Q.1
,
Q.2

Human
Resources:

HR.1
,
Hr.2
,
Hr.3
,
Hr.4
,
Hr.5
,
Hr.6

Communication:

CM.1
,
CM.2

Risk:

R1
,
R2
,
R3
,
R4

Procurement:

P.1
,
P.2
,
P.3
,
P.4
,
P.5
,
P.6
,
P.7




2



Executive Overview


This project plan will detail the project being performed at Progmanosu

by the outside firm
Cloud Conversion Enabler (CCE). The project will consist of converting the current Information
Technology (IT) architecture from its current state to a private cloud architecture. This new
architecture will provide Progmanosu a multi
tude of benefits to include improved agility for
future expansion and growth, a decrease in cost for management of the architecture as well a
decrease in the power and space consumption of the hardware. Along with these benefits the
new architecture will
enable Progmanosu the ability to share computing resources across all the
different applications currently in use. This will result in a very noticeable increase in the user
environment for the employees and will help them to better execute their job duti
es on a daily
basis.


The private cloud architecture was chosen because it gives Progmanosu complete control over
the cloud and does not require them to store any information on hardware they do not own or
control. The proprietary nature of the games Prog
manosu creates requires them to keep
information securely within the company. With the private cloud they will be able to utilize all
the benefits of the cloud without having to worry about unauthorized access to proprietary
information.


Introduction to
Project Plan


The purpose of the project plan is to ensure that all aspects of the project are planned before
execution to minimize the chances of any mistakes or improper planning. The project plan is a
very important part of the project and without a pr
oper project plan project success is much
harder to achieve. The objectives and goals of the project along with a definition of the project
will be presented in detail. The plan also serves as an agreement between Progmanosu and CCE
along with all projec
t participants as to what will be accomplished during the project and the
scope, budget, and time restraints that will be put on the project.


The following project plan will detail every aspect of the Cloud Conversion Project being
performed at Progmanosu

by CCE. All work being performed will be presented along with a set
schedule and budget. The different people involved in the project along with their roles and
responsibilities will clearly be laid out. Detailed explanations of how time management, co
st
management, quality management, human resources management, communications
management, risks management, and procurement management will be presented. All these
sections put together will cover all aspects of the plan and how each aspect will be manage
d to
ensure the project is a success.

3


Business Case

Executive Summary

This business case outlines how the Virtualization Project will address current business concerns,
the benefits of the project, and recommendations and justification of the project. The

business
case also discusses detailed project goals, performance measures, assumptions, constraints, and
alternative options.

Issue/Problem Statement

Due of the rapid expansion and growing popularity of the gaming technologies, ProgmanOSU

has expanded proportionally and globalized. As a result the need has come to speed up the
internal operations and improve the IT infrastructure and its efficiency in the organization to lay
the road map for long term plans. The studies shows that currentl
y the company invests
considerable amount of its capital on hardware costs and maintenance, labor costs etc. .The
increasing demand necessitates that every product have a shorter launch window and in order
achieve this, we need to reduce the deployment ti
me
which currently takes about 45 days right
from ordering the hardware to completing installation
. Also the load of data has increased
over years and the company has added more servers to handle the space. Also some of the
applications run in its own serv
er which does not occupy the entire storage space resulting in
server
underutilization. With over 12

servers,

almost three quarters of them remain
underutilized because most servers were only running dedicated applications
. Also some of
the servers were generations old
and were time consuming to deploy and expensive to
maintain
. In order to reduce the operational cost owing to physical infrastructure the
organization must adopt a
Virtualization model

as discussed in this bu
siness case.

It needs a
virtualization solution for its IT operations.

Project Overview

Project Description

This project is focused migrating the local IT framework to private cloud using
Infrastructure
as a Service (IaaS)
; by this we mean, the computing

services like in
-
house datacenters are
delivered on demand to the customer over network independent of device location. Constructing
a cloud infrastructure using proven technologies from experienced vendors will increase the
Information System efficiency
through scalable hardware and software resources and also
improves business agility. This model offers delivery of dynamic
compute, storage ,
networking

to application development teams and business units. This allows provisioning of
resources (elastical
ly scalable compute) on demand, and enterprise could potentially migrate the
existing system without having to change existing applications .Currently ProgmanOSU
experiences high operational cost right from hardware purchases and problems arising from
hard
ware
Quality of Service
(QoS).The The cloud implementation would give ProgmanOSU
competitive advantage over the others and could be a major milestone for organization’s revenue
and strength. Moreover it boosts opportunities for innovation and new technology

road map.




4


Goals and Objectives

The Virtualization model supports several goals and objectives supported by ProgmanOSU.
These include



Ease of Management



Reduced Operational Costs



Speed up deployment time



Increased Productivity



Increased Network performa
nce, scalability and capacity



Ubiquitous connectivity



Built in security and data protection



Competitive advantage



Lower Capital Expense(CapEx)



Ability to better service customers and clients

There are several vendors which offers

cloud services that will be evaluated


Project Performance

The project plans to reduce its deployment time by 90%, increase its data center density, and
reduce energy consumption of server while increasing its utilization by 30%.The time to market
will thus be accelerated by 90%. The cloud conversion addresses the

following areas


Key Resource/Process/Service

Performance Measure

Deployment

The cloud conversion will reduce the deployment time and hence
release to the market is accelerated. The estimated deployment time is
4 days from 45 days.

Software and System
Maintenance

An estimated 15 percent annual savings in server operating
costs and 66% reduction in IT storage management costs.

Network Capability


Enhanced connectivity including connectivity to mobile devices to
respond in real time independent of the lo
cation.

Aging Servers

Replacement generations old server and its elimination of its
maintenance cost.

Data security

Provide built in security and data integrity across firewall.


Solution Overview
-

ProgmanOSU will partner with

Cloud Conversion Enabler (CCE)

for consulting solution to
implement the cloud migration. There are different Service modals to choose from the industry.
In order to evaluate this migration, Progmanosu needs to consider the risk, benefits and effects of
cl
oud computing. The implementation will be carried in phases in order to provide ample time
for testing and attaining stability. The cost of in house computing is compared against cloud
model.

The National Institute of Standards and Technology (NIST) class
ifies the cloud computing
services into three models. These are identified in relevance to our implementation
-

5


Infrastructure as a Service (IAAS)
:
Allows users to manage processing, storage, networks and
other computing resources so that they can run and deploy the software such as Operating
Systems and applications. Leading providers of this model include Amazon, Linode, Rackspace,
Joyent and IBM bl
ue cloud.

Platform as a Service (PAAS)
:
Provides platform on which users can build, test their cloud.
Examples include GoogleAppEngine, Windows Azure and Joyent.

Software as a Service (SAAS):

Allows users to access applications through browser. Examples
of

this are Google Apps and Salesforce CRM.

In order to carry out the migration, a cloud committee will be formed distinct from the current IT
set up which will work closely with the vendor. The success will be measured not only in
monetary terms but also in

competitive advantage it attains. The rollout will be carried in phases
keeping the backup 0 in place.

Concept Overview

Since ProgmanOSU is the kind of organization that is concerned with data security and privacy
issues, the implementation would be a pri
vate cloud infrastructure. There are several potential
vendors available. The vendors are responsible for all activities starting from maintenance,
administration, capacity planning, troubleshooting and backups
.


Solution Detail
-

There are several factors

that needs to be considered when migrating to cloud.


Vendor selection
-

The vendors identified for migration were narrowed down to Flexpod from
NetApp and Vblock from EMC. The following table compares the two vendors
-


Flexpod

Vblock

Uses NetApp

storage and distributed
through existing channels

Uses EMC corps. Storage and
distributed through joint venture of
three vendors
-

Virtual Computing
Environment coalition

Includes multitenancy feature which
allows for creation of multiple storage
arrays.

Multiple storage arrays not supported.

Flexible and very scalable

Rigid and requires purchase of another
whole unit when additional storage is
needed.


On the basis of above evaluation, Progmanosu will choose Flexpod as its cloud
provider.


Technology
Analysis
-

Progmanosu will partner with CCE to provide expertise on design, build and manage
infrastructure. Flexpod is flexible long term data center solution created by collaboration of
NetApp and Cisco. It is a pre
-
validated and standardized data
-
center
that eliminates guess work
and simplifies the transition to cloud.

1) The assets to be converted to private cloud are identified (servers that will be migrated)

2) Determine the compatibility of hardware and operating system and assess the impact of
migrat
ion in other functional areas

6


3) Prepare case study and research on estimated cost for final implementation

4) Installation of the equipment

5) Time
-
phased conversion of servers

6) Testing

Solution Alternatives
-
Few alternatives were considered before consi
dering this approach. These
are listed below:

Alternative Option

Reasons For Not Selecting Alternative

Maintain the status quo
providing in house
server computing.

Very slow and we are losing to competition. Also not able
to withstand huge load. Costs are

high for maintenance and
labor.

Public cloud instead of
private.

Though cost is low compared to private, not suitable as
ProgmanOSU would need a more reliable, secured
environment and that which has more agility


Cost Benefit Analysis
-

Factors
contributing to cost during migration:

Integration and testing costs
-
The current applications need to be tested before migrating to
cloud and after; if we don’t consider this factor, we may bump into unforeseen economic
circumstances.

Data Lifecycle costi
ng
-
As the applications grow, network bandwidth cost must also be
accommodated since there are large number of cloud instances that needs to be managed.
Accurate estimate of CPU, capacity and storage can yield us better estimate.

Some tangible costs like po
wer and utilities must also be considered. When we migrate the
infrastructure and platform, more parameters will be considered like installation costs and data
usage costs.



Action

Action
Type

Description

First year costs (
-

indicates anticipated
savings)

Purchase Licenses and pay per
use. (5000 per mth*12)

Cost

Initial investment Cloud Migration.

$60,000
/378,000
Yuan

Software installation and training

Cost

Cost for IT group to install new software
and for the training group to train all
employees

$54000
/340, 200
Yuan

Hardware costs includes
purchasing hardware and
maintenance costs

Savings

Since hardware is not purchased from
outside and service is through cloud, it
can be eliminated.

Electricity costs: $3000

-
$700,000
/4,200,000Y
uan

Operational
expenses, includes
labor costs and cost of adding in
more data.

Savings

System administrator cost
-
$45000

Space cost: $5000


-
$50000
/315,000
Yuan

Net First Year Savings



$636,000
/4,006,8000
Yuan

7



Based on the cost benefit analysis above we see that during

the first year alone we save
$636,000 and over the span of years the cost is bound to decrease and we can thus see that
the project has the potential to reap benefits. In calculating the ROI (Return on investment
for cloud migration)



ROI =

Increased

Profit
-

cloud costs

=
Cost saved
-

Investment

= 6% on the first year



Cloud costs




Investment


Cost saved = (Initial no. of servers


Present no .of servers)*(Electricity costs +cooling costs
+Maintenance costs +Manpower costs +software costs

+costs of backup)

CRITICAL ASSUMPTIONS AND RISKS



The vendor will provide the technology adoption Program (TAP) and are responsible for
implementation and integration and if the phases go well, all the applications will
eventually be migrated to
Flexpod

to adopt overall cost optimization strategy.



Training will be provided at high level by the vendor since the IT team needs to know
what is happening inside the cloud.



Network and bandwidth cost should be taken into account for online streaming



Hardware co
st Ignored/assumed to be null.


Risk Assessment
-



The information security risks that are caused by virtualization model are subject to
assessment. This aims to assess the threats, impact and vulnerabilities of the
information systems and likelihood of the
three. Following are the levels of risks
identified.



Organizational Level
-

Risk due to organizational change. Examples include but not
limited to Organizational change that can happen to the provider (termination,
acquisition, failure).



Technical Risk
-
Pr
oblems or failure associated with provided services or technologies.
These include data leakage issues, malicious attack on the cloud provider, issues caused
by downtime in cloud provider.



Legal Risks
-
These are the risk that results that certain regulatio
n and privacy laws
different for each country dealing with the data traversal that needs to be assessed
before.



Note
-

Classification of risks based on
European Network & Information Systems Agency
(ENISA)


8


SWOT Analysis



Recommendations

The discussion ab
ove makes it clear that there are certain challenges that should be considered
when moving to cloud. The staff can concentrate on the application development without
caring about the infrastructure. The adoption of virtualization model through cloud compu
ting
aligns the organizational with its goals and strategy by

1.

Increase in productivity by speeding up the deployment.

2.

Better utilization of available resources and energy consumption.

3.

Demand provisioning and increase in data center density.

4.

Cost savings
proposed to be $1 million by end of 2013.


Although the cloud migration shows positive ROI, the benefits can be better achieved only if it
is carried in phases, i.e. shifting part of the data center to cloud and maintaining the other part
in house .Progman
OSU must adopt a cloud
-
based strategy in order to plan a
time
-
phased

implementation after thorough evaluation the TCO (Total Cost of Ownership) including the
socio
-
technical issues.



9


Project Charter


Project Overview


Progmanosu is

a software company located in Beijing, China that develops and sells video
games.

Progmanosu states its mission to be to develop larger than life, epic, video games
through talent, leadership, diversity, and, most of all, innovation.



Due to the succes
s of Progmanosu’s video games Progmanosu has been steadily growing over
the past few year. Currenlty, Progmanosu is nearing 1000 employees and is projected to grow to
1500 employees by 2015.

To plan for this growth it has been proposed that the current
i
nformation technology (IT) architecture be updated.

Currently the IT infrastructure is the
traditional server based architecture with each server performing a certain function.

The problem
is that most of the servers are becoming very outdated and with t
he recent growth more resources
are needed.

It has been decided that rather than adding to the current architecture a private cloud
based architecture would better suit the business needs of Progmanosu.

The project outlines
what is needed to migrate to t
he new architecture as well as the order in which the steps should
be performed.

All servers will be migrated to the new architecture along with all other resources
to include networking and storage.

The final result will be a shared architecture where a
ll
resources will be allocated as needed and will provide end users a very fast and stable computing
environment.


Project Goal and Objectives


The goal of the project is to enable future growth and provide a stable, fast computing
environment to the end u
sers to enable them to effectively complete their job duties.

This goal is
achieved by using a private cloud based architecture.

The architecture is very scalable and can
be tailored to fit the business needs of the company very quickly and easily.

The
architecture
also provides a very fast user environment by sharing all the resources across all systems
enabling the systems that need the most resources the ability to access them in real time.

These
two enhancements fulfill the overall goal of the proje
ct.


A secondary goal is to reduce maintenance and power costs over time.

The cloud architecture
also achieves this goal.

The smaller footprint made by the private cloud based system requires
less power and the decrease in physical systems will require m
uch less maintenance than the
current architecture.

The decrease in maintenance and energy costs will in the long run pay for
the new architecture while delivering a much more user friendly computing environment.



All users will benefit from this archit
ecture.

The computing environment will be much more
responsive and overall much quicker.

The software developers will the see the most benefit from
the system.

The programming environment they use will have access to many more resources
than it currentl
y does which will increase its speed and help all developers code and test in a
faster environment.


10


A final objective is to make the transition as invisible as possible to the end users.

We do not
want to hinder any employee’s ability to complete their j
ob in an efficient manner.

While this is
a top priority to us it must not be expected that some type of hindrance might occur.

With such a
large undertaking there are always kinks that need to be worked out but these kinks will be
avoided as much as poss
ible.



Impact Statement



Potential Impact

Reason

Implications

Application
compatibility

All applications have not been
completely tested in the cloud
environment

Some applications might not function
properly and will need to be fixed or will
not be
available to users.

Current IT
projects

Some current IT projects might
be affected

Projects might have to be put on hold or not
started until after the conversion

Down time during
migration

All servers will have to go down
to migrate to the new
environment

Downtime could affect some users but will
tried to be minimized as much as possible

Figure Ch.1
,
Potential Impacts


Constraints and Assumptions


The following is a table listing the constraints and assumptions that will be assumed when
executing this project. The implications of those constraints and assumptions is also listed along
with how significant the constraint or assumption is to the project.


Constraint/

Assumption

Significance

Implications

Date

Cloud will integrate with
existing
technology and hardware

Other technology changes
will have to be made

Scope will be
changed if
applications, network
architecture,
hardware etc. need to
be updated


3/12/2012

Company has resources involved
in deployment.

Possible hiring of emplo
yees
with proven technical skills
in cloud deployment

Determine if staff can
handle, do we need to
hire, or outsource?

3/12/2012

Private cloud architecture will be
used


No other infrastructures will
be used

Once determination is
made on architecture
it
will not change

3/12/2012

Vendors can meet cloud
deployment needs

Cloud project cancellation if
internal technical skill or
vendors skills are not
Research outside
vendors

3/12/2012

11


adequate

Managing the cloud’s security and
control

Given that the server

is
moving to new model, some
controls may need to be
compromised and analysis to
be made up to what extent
they can be compromised

Research and collect
references /studies
from companies that
already implemented
cloud

3/12/2012

New architecture does not
change
the end user perspective i.e. the
implementation will be abstract to
the end user and they will not need
any specific instructions/manual

The system should not
change the way end user sees
it as it would take more time
and they would not be
willing
to invest time in
learning the “New Way”

Make it clear in the
requirement
documents

3/12/2012

The staff needs training on the
administrative front that needs to
be undertaken.

After migration, all
employees should be
comfortable and able to
operate it
with speed


3/12/2012

Figure Ch.2
,
Constraints/Assumptions


Project Scope


DOMAIN OF STUDY:


The transition to the private cloud architecture will include all current servers and
applications.

End user workstations will not be included in the project at this time but when a
workstation needs to be replaced or upgraded it will only be upgraded und
er the new terms of
acceptable workstations to be used in the new architecture.

All other pieces of IT equipment will
stay in place and be used as a backup/legacy system after the conversion to the private cloud is
complete. No change to the current netw
ork setup will be implemented along with no other
changes than the ones outlined above.


DOMAIN OF EFFORT:


The following is a list of all the current servers housed and utilized by Progmanosu currently.
The project will include changing the below servers

to a virtual format then migrating those
virtual servers to the new private cloud architecture:




Microsoft Exchange Server (email)



Microsoft Active Directory Server



Secondary Microsoft Active Directory Server



Anti
-
virus Management Server



Web Server



Backup

Server



File/Print Server

12




NAS (Network Area Storage) Server



BlackBerry Enterprise Server



Application Server



DNS Server



Fax Server



Application Server



Development Server


Networking equipment as well as any other pieces of IT equipment in place that can be
reused in
the new architecture will be used whenever possible. No networking or other equipment will be
bought or added during this project.


DELIVERABLES/OUTCOMES:


The outcome will be that all servers will be included in the new private cloud architectu
re.

All
networking equipment will stay in place and will work seamlessly with the new
architecture.

The current workstations will stay in place until there is a need to replace them and
when that occurs they will only be replaced with approved thin or fa
t clients depending on the
specific job function needs. All current servers in place will stay in place and be used for legacy
applications as needed.


Affected Knowledge Assets


The following are the knowledge assets that must be created during the proje
ct to document the
new architecture.
Figure Ch.3
, Knowledge Assets


Knowledge Asset

WHY IS THIS ASSET SIGNIFICANT TO
THE ORGANIZATION?

IMP.

Location

Type of
Use

Private Cloud
Architecture Outline

Needed for IT reference

V

IT
department

C

New Network
Map

Needed for IT reference

V

IT
department

C

Old Architecture
Outline

No longer needed

C

IT
department

D



Financial Summary


The budget for this project is set at $650,000
/4,100,454 Chinese Yuan
. The budget includes all
necessary purchases of hardware or software as well as all the consulting and man hours that are
needed to complete the project. The budget has been approved by Progmanosu and will be
discussed in more detail in the project plan
.

13



Project Approach


The approach to this project will be phased.

The first step will be the planning phase and will
consist of compiling a list of all assets that will be included in the project. Once all assets are
identified the list will then be broken down into groups o
f critical servers and non
-
critical
servers. Critical servers are those servers that Progmanosu needs to effectively function and
perform their business duties. Non
-
critical servers offer applications that are needed but would
not result in a complete st
op to business if they were not available. Once the list of assets is
compiled and broken down an analysis to determine the required hardware to support all assets
will be done and the result will be a list of resources required.


The next step after det
ermining the assets and hardware requirements is to begin the search for a
vendor solution. This will consist of identifying all potential vendors and analyzing those
vendors to compile a list of vendors for further review. Using this list a more detail
ed review
will be conducted until a final vendor is chose.


Once the vendor is chosen the project will move into the execution phase. This phase involves
working with the vendor to install all the required hardware. Once all hardware is installed and
r
unning correctly the next step will be to setup the required software to run each of the virtual
servers on the hardware.

All of these steps will be completed with close support from the
vendor.


With the cloud infrastructure in place the next step is to
test the hardware with the current
network setup. If testing goes well the migration phase will begin.

If testing does not go well
there will need to be a determination on what actions will be taken to ensure the current network
setup will work with the
cloud architecture.

When the network is setup and working with the
new hardware the migration phase occurs.

A list stating the order of the server migration will be
compiled by the IT department and heads of all other departments to determine when the op
timal
downtime will be for each server.

Every effort will be taken to not interrupt normal business
operations during the server migrations.

Once all servers have been migrated more testing will
occur and training will be offered to all employees on an a
s needed basis.

The goal is to make
this transition as invisible as possible to the end users.

If all goes smoothly the end user won’t
even realize a change has been made except by noticing the increase in performance on their
systems.


Project Organizat
ion


The
Project Owner

for this project is Mei Dong.


ROLE:

The Project Owner is the ultimate trustee for this project to the larger
organization.

When needed, the Project Owner may appoint a
Project Steering Entity

to help
make ownership decisions.

RES
PONSIBILITIES:

An actively engaged Project Owner plays two distinct roles during a project.

They help
initiate

the project by…

14




Evaluating the total organizational implications of the project.



Determining that the project is worth the expenditure of money
and time.



Authorizing the project to begin.



Communicating project expectations to the Project Manager.



Certifying the initial Project Charter and Base Project Plan.



Insuring adequate resources are available to the Project Manager for this project.

The Proj
ect Owner
sustains
the project by…



Championing the project to the total organization.



Reviewing project status with the Project Manager.



Insuring critical issues so they may be resolved.



Ruling on changes to the Project Charter, allocating any additional n
eeded resources.



Verifying that assigned resources are available to this project.



Helping the Project Manager resolve resources issues.



Authorizing the project to continue.


The
Project Manager

for this project is Michael Chang.

ROLE:

The Project Manager
is the individual responsible for organizing, planning, controlling
and leading this project.

A Project Manager reports to and has access to the Project Owner.

He
or she is authorized to act for the Project Owner.


RESPONSIBILITIES:

A Project Manager…



Communicates the Project Goals and Objectives to the Project Team.



Creates the Project Charter and Project Plan.



Facilitates project planning activities with the Project Team and other needed
participants.



Communicates issues and changes to the Project Own
er.



Communicates status to the total organization.



Verifies the quality certification of all project deliverables.



Updates the Project Charter and Project Plan components when authorized.

The
Project Team

is an interdependent collection of individuals who
have been selected to
perform the work of the project.

ROLE:

The core Project Team may come from many organizational units.

They work
collaboratively to accomplish the goals and objectives of the project.

They report functionally to
the Project Manager.

RESPONSIBILITIES:

Each member of the Project Team…




Is skill matched to the project.



Will work with the Project Manager to define their specific responsibilities on the project.



Is available to work on the project.



Will participate in planning activities
.



Will alert the Project Manager of any factors that prevent them from performing their
assigned role on the project.

15




Will perform their work in a professional manner.



Will account for the effort, duration and cost of their participation.


Core Project Tea
m members for this project are:

TEAM MEMBER

ORGANIZATION

EMAIL

PHONE

Rick Kennedy

Cloud Conversion Enabler

rickkennedy7@gmail.com

9188506354

Ramya Radhakrishnan

Cloud Conversion Enabler

ramya.ibt@gmail.com

9188045469

Vidal Jefcoat


Cloud Conversion
Enabler

jefcoatv@yahoo.com

9187404398

Britt Gathright


Cloud Conversion Enabler

britt.gathright@okstate.edu

9187206125

Michael Chang

Progmanosu

mchang@progmanosu.com

01064035511

Cynthia Lau

Progmanosu

clau@progmanosu.com

01064035511

Yang Teoh

Progmanosu

yteoh@progmanosu.com

01064035511

Figure Ch.4
, Core Team Members












16


Project Scope

Solutions Architecture


Architecture Overview


The purpose of this project is to implement a private cloud architecture at Progmanosu
. This
architecture provides a computing environment based on virtualization technology that shares all
resources over all systems. A storage area network (SAN) is coupled with processing and
memory resources via virtualization software to create an envi
ronment with the ability to allocate
and remove resources to different aspects of the architecture as needed. This architecture
provides Progmanosu a very agile IT environment that can not only support their current IT
needs but enables Progmanosu to rapi
dly grow their IT environment in the future.

While the final goal is for Progmanosu to move to a full private cloud architecture this project
only entails the first steps to moving to that full private cloud architecture. That first step
involves installi
ng all the necessary hardware needed for a private cloud as well as migrating all
physical servers to virtual servers residing on the private cloud. The final result will be exact
replicas of the current physical servers in a virtual format that share all

storage, processor, and
memory resources. The end user will see no difference in their current computing environment
except for a noticeable increase in the performance and responsiveness of all systems.

Architecture Decisions


There are numerous decisio
ns that must be made once the decision to completely change
architecture designs. Not only are there multiple cloud architectures but there are also many
different ways to implement those architectures. The following is an explanation of each of the
clou
d architectures that were taken into consideration:


Public cloud: All hardware and resources are hosted off site at a vendor location and offered to
companies for a fee. The resources can then be accessed by the employees of the organization
over the int
ernet or a virtual private network.


Private cloud: All hardware and resources are located on site and are owned by the company.
The employees of the company then access the resources over the internal network.


Hybrid cloud: A combination of a private cl
oud that is linked to an external public cloud.


There are benefits and drawbacks to each of the above architectures. The public cloud enables
the use of resources without having to manage those resources. The organization would not have
to invest in the hardware or personnel to setup and manage the cl
oud environment. The problem
with this approach is the resources are then owned and managed by an outside company so the
ability to control the resources within the organization is lost. There are also security concerns
17


with storing data on equipment and

at locations that are not owned by the company. Most
companies like to have control over their data and resources as well as the way in which the data
and resources are protected.


An alternative to a public cloud is the private cloud. This architectu
re addresses some of the
security and control concerns that arise with a public cloud. Private cloud architectures give
companies the ability to personally manage their own resource and have much more control over
those resources. The tradeoff is that th
e hardware and resources would sit within the internal
network of the company and would require staff along with space and power requirements.


A final option is hybrid cloud architecture. This architecture combines the public cloud and
private cloud and
enables companies to use external cloud resources for some functions while
using internal cloud resources for others. The advantage to this architecture is letting the
company choose where they would like to obtain their resources.


















18


Archit
ecture Templates


The following are high level diagrams of the different architecture templates that were
considered when determining the best architecture to fit Progmanosu’s business needs:




Figure S.1, Public Cloud
Architecture



Figure S.2, Private Cloud Architecture


Figure S.3, Hybrid Cloud Architecture

19


Business Context Diagrams


The following high level Progmanosu network and high level business context diag
rams show
how the current network infrastructure would be converted into the above templates:



Figure S.4, Current Progmanosu Architecture


20



Figure S.5, Progmanosu Private Cloud Architecture


Use Cas
e Model


The following use case model demonstrates the agile private cloud architecture being
implemented. When a developer performs a resource intensive activity such as compiling code,
querying data, or executing code, the private cloud environment auto
matically shifts resources to
the developer to complete those tasks. Once the resource intensive task is complete the private
cloud architecture then has the ability to reclaim those resources and shift them to areas as
needed.


Figure S.6, Resource Allocation Use Case

21


Systems Context


From a systems context no changes will be made. The final result will contain all the same
systems that are currently implemented at Progmanosu

with no addition or subtraction of
systems. The following is a list of all the servers that will be included in this project and the
systems those servers support:




Microsoft Exchange Server (email)



Microsoft Active Directory Server



Secondary Microsoft A
ctive Directory Server



Anti
-
virus Management Server



Web Server



Backup Server



File/Print Server



NAS (Network Area Storage) Server



BlackBerry Enterprise Server



Application Server



DNS Server



Fax Server



Application Server



Development Server


After the conversi
on to the private cloud architecture these systems will be virtualized and will
sit on the private cloud rather than on physical separate servers.

Scope Management Plan


Introduction


Scope Management is the process of ensuring that the tasks needed to be accomplished in a
project are accomplished as well as ensuring that tasks are not added or altered during the
project. Scope Management also deals with how the scope for a project is
developed as well as
detailing each task and providing a start and end date for each task.


The Scope Management process is very structured and contains five steps. The first step is to
collect the requirements for the project. Before you can develop t
he scope you must first
understand what is trying to be accomplished as well as set some requirements and objectives for
the project.


Once the requirement and objectives of the project are set the next step is to define the scope.
This is a very import
ant step for the entire project. The scope must be written in a way that not
only includes what will be involved in the project but also what will not be involved in the
project. The scope must be as detailed as possible and draw clear lines as to how th
e project
22


goals and objectives will be accomplished as well as what will not be included to accomplish
those goals and objectives.


Once the scope is defined a work breakdown structure (WBS) is developed. The work
breakdown structure is a collection of
th
e entire

task in the project along with a schedule as to
when those tasks must be completed. The WBS is created by starting with large overall tasks
then breaking those tasks down into their sub
-
tasks until they are broken down enough that they
can be ass
igned to different groups. The final WBS will encompass all the tasks that will be
included in the project as well as any deliverables expected from those tasks.


The final two steps in the Scope Management Plan are scope verification and control. Duri
ng
scope verification the scope is reviewed by the project team and agrees to the tasks and
deliverables. Scope control, however, is a much more complicated process of monitoring the
scope throughout the project and ensuring that it doesn’t change or move

as the project
progresses. Scope control is very important to a project because without a solid scope
management plan the scope could change very quickly and the result of the project could end up
very far away from the projects intended purpose or goal.

Changes to projects scope can quickly
result in drastic changes to time and budget constraints put on a project. It is a well
-
known that
fact that a large reason that many failed projects fail is because of scope creep or a gradual
change in scope over
time.

Scope Management Approach


The Project Manager will have the sole responsibility for scope management throughout the
project. The Project Manager will work with the Progmanosu’s management team to define the
scope as well as develop the scope statem
ent. Once the scope statement has been created the
Program Manager will then work with Progmanosu’s IT department as well as the Flexpod
vendor to determine the tasks needed to accomplish the project as well as develop the WBS. The
WBS will then be revie
wed by Progmanosu’s management team as well as Progmanosu’s
Project Lead for scope verification.


Once the scope has been verified it will be the Project Manager’s responsibility to monitor and
continue to verify the scope during the project. The Projec
t Manager will do this by utilizing
forms and questionnaires to be distributed throughout the project. Checklists will also be created
for use when major milestones are completed to ensure that all aspects of the milestone are
complete.


The Project Manag
er will also be in charge of the scope change process. The scope change
control process defines how changes to the scope can be requested as well as the process the
request must go through to be enacted. The process is described in detail below.


Scope M
anagement will also detail who is responsible for receiving and verifying the
deliverables. The Project Manager will be in charge of making sure those that are responsible
for verifying the deliverables sign off on the deliverables but those parties respo
nsible for the
deliverables must verify them.

23


Roles and Responsibilities


All project participants must play a big part in the project for it to be successful. Those
participants must understand what is expected of them if they are to perform all their du
ties. The
following table lists the roles and responsibilities for all participants in the project. All
participants are expected to agree to and perform all roles and responsibilities listed in the table
below:

Name

Role

Responsibilities

Mei Dong

Sponsor

-

Approve or deny scope change requests as
appropriate

-

Evaluate need for scope change requests

-

Accept project deliverables

Michael Chang

Project Manager

-

Measure and verify project scope

-

Facilitate scope change requests

-

Facilitate impact assessments
of scope
change requests

-

Organize and facilitate scheduled change
control meetings

-

Communicate outcomes of scope change
requests

-

Update project documents upon approval of
all scope changes

Cynthia Lau

Lead Engineer

-

Measure and verify project scope

-

Validate scope change requests

-

Participate in impact assessments of scope
change requests

-

Communicate outcomes of scope change
requests to team

-

Facilitate team level change review process

Yang Teoh

Design Technician

-

Participate in defining change resoluti
ons

-

Evaluate the need for scope changes and
communicate them to the project manager
as necessary

Figure S.7, Scope Management Roles and Responsibilities

Scope Definition


The scope for this project was defined by reviewing the current architecture at
Progmanosu then
a determination was made as to what needed to be done to convert that current architecture to the
new proposed private cloud architecture. Progmanosu’s internal IT department as well as
Progmanosu’s Lead Engineer and Design Technician were

heavily involved with this process
24


along with CCE team members. The project requirements documentation was used heavily in
determining the scope of the project along with the goals and objective of the project.


Once the project scope was determined a di
scussion about what would not be included in the
project was held and a determination was made as to where the lines would be drawn for the
project. The Flexpod vendor was utilized during this aspect of developing the scope to ensure
that nothing was left

out that the vendor required to install and operate their Flexpod solution.
The final result was a very detailed scope statement that covered what the project would
accomplish.

Project Scope Statement


The following project scope statement will provide a

detailed explanation of the project as well
as outline deliverables and what the final outcome will look like. The scope statement will not
only include the work that will be performed but also the work that will not be performed and
will cover all addi
tional aspects that could be included in the project with a statement as to if
they will be included or not.


This project will include completing the first stage of converting the current network architecture
at Progmanosu to
private

cloud architecture.
The first stage of the conversion includes installing
all Flexpod components as detailed by the Flexpod vendor. All current servers will be converted
to a virtual format and will be moved to the Flexpod. No change in the software will be made on
the serv
ers unless needed to integrate with the Flexpod. The current network will stay in place
with no changes except small running configuration changes as needed to support the Flexpod.
No services provided by the current servers will be added or removed duri
ng this project. End
user workstations will not be altered during this project and the end user will see no difference in
their computing environment except for an increase in performance. No lapse in service to
employees will occur during this project a
nd all servers will be migrated over weekends and non
-
business hours to minimize any inadvertent lapses in service. No personnel will be added or
removed during this project and no offices or departments will be restructured. All virtual
servers and appl
ications will be tested to ensure proper functionality and the project will not be
completed until all applications and servers function properly on the Flexpod.


The final deliverable will be a fully functioning Flexpod installed on location at Progmanosu
’s
office. The Flexpod will offer all current servers and applications to Progmanosu’s employees
and mirror the current server
configurations
.


It is assumed that Progmanosu has suitable space in their server room as well as power and
cooling resources to

support the Flexpod architecture. It is also assumed that the internal IT
department will be involved in all testing and will assist in making the final determination as to if
all services on the virtualized servers act and function the same way as they
did on the physical
servers.


The time constraints on this project from start to finish will be 32 weeks with 4 weeks flex time
built in if needed. The budget for this project is $650,000
/ 4,100,454 Chinese Yuan

for the entire
25


project to include any neede
d acquisition of resources as well as the cost of man hours and
consulting.

Work Breakdown Structure


The following is a list of all the work that will be done to accomplish the project. The tasks as
well as the deliverables from these tasks will result in the finished project and the final outcome

will be the implementation of a private cloud architectu
re at Progmanosu



Figure S.8, Work Breakdown Structure

26


Level

Element Name

Description of Work

Deliverables

1


Cloud
Conversion
Project

Convert Progmanosu current
architecture to a private cloud
architecture.

Fully functioning private cloud
architecture installed on site at
Progmanosu.

1.1

Planning Phase

Prepare for conversion.

List of Servers/Resources to
convert to new architecture
along with vendor that will be
used for the project.

1.1.1

Compile List of
Assets to Convert

Identify and compile list of
current assets to convert to the
cloud architecture.

Complete list of assets to convert
to cloud.

1.1.1.1

Compile List of
Critical Servers

Compile list of all servers
critical to operations at
Progmanosu.

Lis
t of critical servers.

1.1.1.2

Compile List of
All Other Assets
to Convert

Compile list of all assets that
will be converted to the private
cloud architecture.

List of all assets to be converted
to cloud architecture.

1.1.1.3

Identify
Resources
Needed to

Support List of
Assets to Convert

Using the lists complied above
compile all resources that will
be needed to support the assets
being moved to the private
cloud.

List of resources needed to
support all assets moving to
private cloud.

1.1.2

Review Vendor
s

Research and select a vendor.

Vendor that will be used to
accomplish the project.

1.1.2.1

Identify Vendors

Research private cloud
vendors.

List of vendors to be reviewed.

1.1.2.2

Compare
Vendors

Compare all vendors against
each other.

List of pro’s

and con’s of each
vendor and vendor’s solution.

1.1.2.3

Request Quotes

Request quotes from vendors.

List of quotes from vendors.

1.1.2.4

Identify
Hardware
Requirements

Work with vendor to identify
hardware needed.

List of hardware needed.

27



Figure S.9, WBS Dictionary

1.1.2.5

Selec
t
Vendor/Solution

Make a selection on which
vendor to use.

Statement as to which vendor
will be used along with their
proposed solution.

1.2

Execution Phase

Install and convert current
architecture to private cloud
architecture.

All hardware installed and

servers converted to the new
private cloud.

1.2.1

Install Hardware

Install all necessary hardware
at Progmanosu.

All hardware installed on site at
Progmanosu.

1.2.2

Convert Servers
to Virtualized
Format

Convert all servers to a
virtualized format.

All
servers in a virtualized state
and ready to be moved to the
private cloud.


1.2.3

Test/Verify
Functionality

Test that all servers still
function properly in a
virtualized format.

All servers in a virtualized
format and in working order.

1.2.4

Move Virtua
lized
Servers to Cloud

Move all virtualized servers to
the cloud.

All servers residing on the
private cloud.

1.3

Closing Phase

Closing out the project and
verifying everything is in
proper working order.

The first step of moving to a
private cloud infrast
ructure with
all servers virtualized on the
private cloud.

1.3.1

Verify/Test All
Severs

Test functionality of all
servers.

All servers functioning properly
on the private cloud.

1.3.2

Verify/Test All
Applications

Test functionality of all
applications on

the servers.

All applications function
properly on the private cloud.

1.3.3

Close Project

Close out the project and
deliver final deliverable

A functioning private cloud with
all servers on the cloud
hardware.

28




Scope
Verification


The Project Manager will have the responsibility of scope verification during the project. Each
deliverable must be checked against the scope and the Project Manager will work with the
Project Sponsor to review each deliverable. If it is
verified that the deliverable fits within the
project scope then the sponsor will formally sign for the deliverable. The Project Manager will
oversee this process to ensure that deliverables are reviewed and accepted correctly.

Scope Control


The Project
Manager has the main responsibility to control the scope of the project but the
Change Control Board (CCB) must review and approve/deny any requests for change to the
scope of the project. The Project Manager will review the deliverables throughout the pr
oject
and ensure that they align with the scope of the project and the WBS. The project team must
follow the WBS throughout the project and provide the deliverables listed. The Project Manager
has the authority to request changes to any deliverables that

do not conform to the scope
statement of the project.

All changes to the project can be requested by submitting the change request form to the Project
Manager. The Project Manager will then review the change and convene the CCB to review the
request and
make a determination as to if the change is needed and can be included in the project
or not. The CCB is the final authority and is the only entity that can approve a change to the
scope of the project. If the CCB determines the change can be included in

the project the Project
Manager will then be in charge of implementing the change and communicating the change to all
participants of the project. The Program Manager must also make the proper adjustments to the
time and cost estimates for the project as

a result of the change.


The following is a list of all the members of the CCB along with their functions:


Name

Position

CCB Role

Mei Dong

Project Sponsor

CCB Chair

Michael Chang

Project Manager

CCB Member

Cynthia Lau

Project Lead Engineer

CCB
Co
-
Chair

Yang Teoh

Project Design Technician

CCB Member


Figure S.10, Change Control Board Members

29




Schedule Management Plan


The Schedule of the project describes how the project will be sequenced and details how the
activities will be carried out.
Schedules can give the project manager and team immediate
feedback as to the progress of the project. Schedule management provides direction on how the
project team will determine scheduling and sequencing activities. The schedule provides a base
time li
ne for the project. Using this baseline the project Schedule Management plan sets forth
actions to change this timeline/ or corrective action to bring the project back into the time
baseline. The Schedule Management plan covers the following areas: id
entifying, analyzing,
documenting, prioritizing, approving, and documenting all schedule changes.

Schedule Management Approach:

MS Project will be used by the Project Manager to create the schedule utilizing the Work Break
Down Structures from the Scope of

the project. The Activity Definitions define specific work
items that are required to complete each deliverable. The Project Manager will determine the
critical path for the project and sequence activities to stay on the time baseline. Activities wi
ll
be assigned to individuals. One individual will be responsible for delivering one Work activity.
This helps with management of the activity. The individual will be responsible for managing his
or her team involved in the completion of the activity.


Once the critical path and schedule are determined the project team and project sponsors will
review the schedule and approve it. Once the schedule is approved the more planning can take
place and resources can be allocated to each work activity. T
he allocation of resources to each
activity creates helps to create our cost baseline along with the initial cost of any hardware,
software or services procured.

The project has already been approved and WBS defined. They will not be included in the
p
roject Milestones.

Milestones for the project:



Project kick
-
off



Acceptance of final deliverables



Id Servers to Cloud



Vendor Selection



Testing of equipment



Completion of Phase One



Conversion of Servers

30




Testing of Servers



Completion of project and acceptance

of final deliverables.




Roles and Responsibilities:

The project work activities, sequencing and time line will be completed by the project manager
with the assistance of the project team. The schedule will be documented using MS project and
posted to the project repository. The project team, sponsor, and

stakeholders will approve the
time line. Once the time line is approved it the schedule baseline will be set. No changes to the
schedule can be made without following the schedule change plan.

The project team will assist the project manager in defining project activities, sequencing and
time line and setting the project schedule baseline.

The stakeholders will assist the project manager in defining project activities, sequencing, time
line and

setting the project schedule baseline.

Schedule Control:

Twice a week the schedule will be updated and posted into the repository. The process of
updating will be to show start dates of activities. If the activity is completed then the end date
will b
e displayed. If the activity is not complete then the % complete will be updated.

The project activity owner will be responsible for reporting on the progress of the activity. The
progress will be reported using the following template. This template wi
ll be filled out twice
weekly and emailed to the project manager. (
Figure SCH.1
)

Figure SCH.1

31



The project sponsor is responsible for approval of project schedule changes and must be aware of
the progress. The sponsor will be responsible for reviewing th
e schedule weekly to approve
changes and review progress.

Schedule Changes:

If it is determined by an activity owner that there will be a slip in the schedule of the activity the
project manager and the owner will meet. The meeting will consist of identif
ying the cause of
the slip and documenting it in the repository for future reference. Next the team members will
examine any other areas that will be impacted due to the slip. What corrective action can be
taken to return the project to schedule will be

determined? If no corrective action can bring the
schedule back into the base line the scope, schedule, and cost will have to be update. The project
manager and team

member will have to determine h
ow these will be affected. The change
request will be
submitted to the sponsor for approval. The change request will be documented
using the standard change request form
SCH.2

and logged using the standard change request log
SCH.3
.

32













33


Figure SCH.3 Standard Change Request Log




Scope Change:

Once the Schedule change has been approved and update the project manager will have to
determine whether or not to move the schedule baseline. If the cause of the slip was out of the
control of the project manager and project team then the baseline may b
e changed.


Schedule Baseline:

The following sections deal with the actual time frame of the project. First Gantt charts for each
phase are provided to give an overview of the time duration for each phase. Then Each activity
is given an expected time
in weeks and variance. The estimated time for each phase is totaled
along with the variance. Next a network diagram or pert chart is provided to show the critical
path of each phase. Finally each activity is described and an updated WBS is provide to r
eflect
changes.

Change Log

Project:

Date:

Change
No.

Change
Type

Description
of Change

Requestor

Date
Submitted

Status

Comments

Each
change
request is
assigned
a
reference
number.

This may
be a
design,
scope,
schedule or
other type
of change.

The change
request
should be
described in
detail.

Who
initiated
the change
request?

When was
the request
submitted?

Is the change
request open,
closed or
pending?
Has it been
approved,
denied or
deferred?

This section
may describe
why the change
request was
rejected,
deferred or
provide any
other

useful
information.

34



Cloud Project Time Line Phase One:

Figure Sch.4

The conversion project will be a two phased project. The first phase will end with the Selection of the Vendor.


35


Phase One Activity Duration Estimation:

The expected duration for the time of each activity in the phase is derived by adding the
pessimistic, optimistic and 4 times the most likely, Then Dividing by 6.
t

= (a + 4m + b)/6.

Figure Sch.5

is an estimate of the amount of time in each activity alon
g with the variance. The
total expected time and variance is shown. Phase one of the project is expected to finish in 16.65
weeks with a variance of .75.




Pessimistic

Optimistic

Most
Likely

Expected

Variance

A. Compile List of Critical
Servers

3

1.5

2

2.10

0.0625

B. Compile list of other assets

4

1.5

2

2.25

0.173611

C. Identify Resources to Convert

3

1

2

2.00

0.111111

D. Identify Vendors

3

1.5

2

2.10

0.0625

E. Compare Vendors

3

1.5

2

2.10

0.0625

F. Request Quotes

3

1

2

2.00

0.111111

G.
Identify Hardware
Requirements

3

1.5

2

2.10

0.0625

H. Select Vendor

3

1

2

2.00

0.111111







Total

16.65

0.756944


36



Figure Sch.6

Shows the Critical Path/Network Diagram of the first phase of the project. The critical path is highlighted in Red. All
activities are on the critical path except Activity B. However if Activity B goes over 2.25 weeks it will move into the crit
ical
path and
delay the project.



37



Phase One Activity Definition:

This list and defines all activities in the phase 2.

Figure Sch.7

Activity Name

Activity Description

Activity Name

Activity Description.

Compile List of Critical
Servers

List of Critical Servers to
operations at
Progmanosu

Compile List of other
Assets to Convert

Compile list of Assets
that will be converted
to private cloud
architecture

Identify Resources
Needed to support list
of Assets to convert

Using list compiled
abo
ve list all resources
needed to support
assets being moved to
private cloud

Identify Vendors

Research Private Cloud
Vendors

Compare Vendors

Compare all vendors
against each other

Request Quotes

Request quotes from
vendors

Identify Hardware
Requirement

Work with vendor to id
hardware requirements

Select Vendor

Make a selection of
which vendor to use


38


Cloud Project Time Line Phase Two:

The second phase will begin at the end of phase one and start with a detailed timeline of the Conversions. Next the project

with work through
the physical conversions and begin Testing of the architecture once several servers have been converted.

Onc
e Hard Ware has been installed Server Group A can begin to be virtualized. Once this is completed testing can start. The t
esting phase does
not have to wait for Servers in group B to be completed. This helps to shorten the length of the project.

Fig
ure Sch.8


39



Phase Two Activity Duration Estimation:

The expected duration for the time of each activity in the phase is derived by adding the
pessimistic, optimistic and 4 times the most likely, Then Dividing by 6.
t

= (a + 4m + b)/6.

Figure Sch.9

is an estimate of the amount of time in each activity along with the variance. The
total expected time and variance is shown. Phase two of the project is expected to finish in 16.15
weeks with a variance of 1 week.



Pessimistic

Optimistic

Most
Likely

Expected

Variance

A. Install Hardware

4

1.5

2

2.25

0.173611

B. Convert Server Group A to Virtualized
Format

4

1.5

1

1.6

0.173611

C. Convert Server Group B to Virtualized
Format

3

1.5

1

1.4

0.0625

D. Test Verify Functionality

3

1

2

2

0.111111

E. Move Virtualized Servers to Cloud

4

1.5

2

2.25

0.173611

F. Verify and Test Server Group A in Cloud

2

1

1

1.2

0.027778

G. Verify and Test Server Group B in Cloud

2

1

1

1.2

0.027778

H. Verify/Test all applications

4

1.5