MINISTRY OF EDUCATION IT INFRASTRUCTURE UPGRADE · MINISTRY OF EDUCATION – IT INFRASTRUCTURE UPGRADE Page | 6 CONFIDENTIAL 2. WORK BREAKDOWN STRUCTURE & DICTIONARY Project team

MINISTRY OF EDUCATION IT INFRASTRUCTURE UPGRADE

PROJECT FILE

Version 1.2, October 22, 2012

By: Dennis Suhanovs PMP, CISSP, MCITP:EA, MCITP:EMA, MCSE

IMPORTANT! CONFIDENTIAL UNPUBLISHED WORK. THIS PROJECT FILE AND ALL ASSOCIATED DOCUMENTS WERE

USED AS PROJECT DELIVERABLES AT THE UNIVERSITY OF TORONTO, PROJECT MANAGEMENT FOUNDATIONS

CLASS FPM1860. REUSE OF ANY PORTIONS OF THIS WORK IS PROHIBITED. THIS WORK IS NOT CONNECTED IN

ANY WAY WITH THE ACTUAL MINISTRY OF EDUCATION; ANY POTENTIAL SIMILARITIES ARE PURELY

COINCIDENTAL. THIS WORK IS PUBLISHED AT WWW.FLEXECOM.COM TO PROVIDE SAMPLE PROJECT

DOCUMENTATION AND DEMONSTRATE THE USE OF PMI/PMBOK PRINCIPLES IN IT PROJECT MANAGEMENT.

Microsoft, Softchoice, Dell Computers, MGS, MOE, and other trade names are used without permission but in

the spirit of advancing formal project management practices in the field of IT.

http://www.flexecom.com/

MINISTRY OF EDUCATION – IT INFRASTRUCTURE UPGRADE

Page | 2 CONFIDENTIAL

CONTENTS 1. Project Scope Statement ........................................................................................................................................... 3

Project Scope Description .......................................................................................................................................... 3

Project Acceptance Criteria ....................................................................................................................................... 3

Project Deliverables ................................................................................................................................................... 4

Project Exclusions ...................................................................................................................................................... 4

Project Constraints .................................................................................................................................................... 5

Project Assumptions .................................................................................................................................................. 5

2. Work Breakdown Structure & Dictionary .................................................................................................................. 6

3. Activities List .............................................................................................................................................................. 8

4. Network Diagram ....................................................................................................................................................... 8

5. Milestone Chart ....................................................................................................................................................... 10

6. Gantt Chart .............................................................................................................................................................. 11

7. Project Cost Estimates ............................................................................................................................................. 11

8. Project Budget ......................................................................................................................................................... 13

9. Cumulative Cost Curve............................................................................................................................................. 14

10. Earned Value Analysis ............................................................................................................................................ 15

11. Responsibility Assignment Matrix ......................................................................................................................... 16

12. Resource Histogram ............................................................................................................................................... 17

13. Stakeholder Communication Plan ......................................................................................................................... 19

14. Quality Assurance Plan .......................................................................................................................................... 20

15. Quality Control Plan ............................................................................................................................................... 20

16. Risk Register ........................................................................................................................................................... 23

17. Procurement Plan .................................................................................................................................................. 25



1. PROJECT SCOPE STATEMENT The purpose of this document is to provide a holistic view of project boundaries. This document draws from the

information presented in Project Charter and Project Charter Appendix, and progressively elaborates it to remove

any remaining ambiguity related to what work and deliverables should be considered to be part of the project.

PROJECT SCOPE DESCRIPTION

The Ministry of Education is undertaking an upgrade of desktop equipment in 25 administrative offices across the

province. The project is targeting client side of the infrastructure, i.e. desktop hardware and associated peripherals

and cabling, as well as software. The project is going to improve productivity of end users and reduce volume of

calls into Helpdesk, lowering IT support costs at the Ministry.

The project will achieve its stated goal by delivering 250 modern desktop stations to the Ministry’s offices. These

desktops will be running the latest Microsoft operating system and the latest version of Microsoft Office

productivity software.

The project must establish a repeatable, low-cost way of delivering standardized operating system environment

(OSE) image to the desktops, in the event that a newly deployed desktop would need to be quickly “reset” or

reimaged to its initial state. This delivery mechanism should be used in mass delivery of standardized (identical)

OSE images to all 250 desktops in this project’s scope.

Similarly, this project must establish a software packaging and delivery mechanism that would allow the Ministry

to deploy additional applications, configured identically, to any subset of desktops in a short time interval. This

mechanism must be used to deploy Microsoft Office and MacAfee antivirus as part of this project.

Ministry’s Helpdesk must be trained in basic operation of both image and application delivery mechanisms and

also be brought up to speed to be able to support the latest OSE being deployed. Developing in-house expertise is

not the purpose of this training, but transferring the knowledge specific to the Ministry’s environment/project is.

We would also like to see training recommendations as a result of this training, which would be helpful in

identifying subsequent career development path for the Helpdesk staff.

During deployment of new desktops, existing user data needs to be transferred from the existing desktops to the

network servers maintained in the Ministry’s datacenter. This effort should be coordinated with Helpdesk staff, as

they are most intimately familiar with current user habits when it comes to storing data in this less than organized

environment.

PROJECT ACCEPTANCE CRITERIA

Project acceptance criteria will be established as follows:

1. All deliverables are met in full

2. All technical work is completed by August 20, 2012

3. All paperwork/training is completed by September 15, 2012 at the latest

4. The project is on budget; variance of up to 5% is considered undesirable but acceptable

5. Project sign-off can be obtained only from project sponsor

6. Lead project manager must confirm that all deliverables are met prior to recommending sign-off



PROJECT DELIVERABLES

The project deliverables are:

1. Deployment of a desktop imaging system (Microsoft System Center Configuration Manager, SCCM)

a. SCCM design document

b. SCCM build document

c. Functional SCCM installation

d. Desktop imaging process document

e. (One) standard desktop image configuration document

f. (One) standard desktop image

2. Deployment of a software package delivery system (SCCM)

a. SCCM application packaging process document

b. Microsoft Office package

c. MacAfee antivirus package

3. Deployment of 250 imaged desktops to the 25 Ministry locations, 10 desktops per location

a. All machines have standard image deployed

b. All machines have Microsoft Office software package deployed

c. All machines have MacAfee antivirus software package deployed

d. All machines passed basic QA test, test criteria TBD

4. Migration of user data from existing desktops to network server

a. User files moved from My Documents folder to network server

b. User files moved from Desktop folder to network server

c. User bookmarks moved from Favorites folder to network server

d. User state on new machines redirected to network server using Group Policy

5. Old hardware disposal

a. All hard disks must be physically destroyed according to government data disposal standards

b. All remaining assets must be disposed of by recycling or donating, disposal criteria TBD

6. One month standby support

7. Training sessions provided to internal Helpdesk team to be able to field level one support calls

8. Software licensing compliance must be achieved and maintained through the project

For a more detailed description of work considered to be in scope, please refer to the Charter Appendix, Input

section, Statement of Work.

PROJECT EXCLUSIONS

The following activities are deemed out of scope for this project:

1. Hardware acquisition process, including tender/RFP, budgeting, and logistics

2. Software licensing and media acquisition, including vendor negotiations and budgeting

3. Parallel summertime network server upgrades that are planned at the Ministry

4. Decision-making and logistics associated with recycling vs. donation of the old equipment

5. Any other software installation not mentioned in this scope statement

6. Any other desktop configuration not mentioned in this scope statement

7. Any other user/data migration assistance not mentioned in this scope statement

8. Any work related to replacement of defective new hardware or obtaining correct software versions



PROJECT CONSTRAINTS

This project is conducted during seasonal staff holidays, so its primary constraint is time-based. All technical work

must be finalized by August 20 2012, which is when staff quorum is expected to report to the Ministry and

commence administrative work.

The next most important constraint is of budgetary nature. The Ministry has allocated a budget of $400,000 CAD to

this initiative and it expects the project to more or less fit within this budget. Since the project selection criteria

was based on certain parameters that were based primarily on this budgeted amount, the project cannot deviate

materially from this budget without receiving a thorough review and go through an approval process.

PROJECT ASSUMPTIONS

This project makes the following assumptions:

Assumption Potential Impact if False

The Ministry will remain a Microsoft shop, meaning that OSE will be Windows 7, and imaging and package delivery system of choice will be Microsoft System Center Configuration Manager (SCCM)

Critical

Hardware acquired through an out-of-scope process will be sufficient to meet user demands

Significant

Hardware acquired through an out-of-scope process will be sufficient to comfortably exceed minimum software requirements of Windows 7

Significant

Hardware to run Microsoft SCCM will be made available to the team of SMEs outside of the desktop provisioning process

Minor

Software licensing agreement signed through an out-of-scope process will provide access to the desired software versions

Minor

Helpdesk staff will be available for training and knowledge transfer in August 2012

Minor

Access to the facilities will be provided to the project team as required Critical Access to the Helpdesk team will be provided for May consultations Significant Access to the MGS SMEs team will be provided for May consultations Significant WAN and server upgrade in progress at the Ministry will not materially interfere with desktop deployment and user state migration phase of this project

Significant

SCCM SMEs on the labor market are not in a very short supply Significant



2. WORK BREAKDOWN STRUCTURE & DICTIONARY Project team has analyzed project requirements and scope statement, and developed a work breakdown

structure, WBS. WBS chart (next page) shows the project decomposed into deliverable-based work segments of

varying lengths.

WBS Name Description

1.1 Procurement First phase of the project that consists in analyzing procurement requirements in order to acquire hardware and software.

1.1.1 Hardware Selection Select hardware configuration based on software requirements and expected life cycle of 3 years. While hardware procurement itself is outside our scope, we have to ensure that hardware procured for the project comfortably meets software and operational requirements.

1.1.2 Hardware and Software Procurement

Assisting with hardware acquisition from DELL Inc. Executing volume licensing agreements with Microsoft. Acquiring third party software licensing and media. Cataloging and tagging of equipment.

1.2 Software Preparation Create a virtual network environment and set up Windows Deployment Services or System Center Configuration Manager (as determined by the experts) in order to prepare software packages for mass distribution.

1.2.1 Standard Image Development

Install operating system, updates, device drivers and other software in a reference computer in order to create an image installation file to be applied to all computers.

1.2.2 Standard Image Testing Apply the standard image to several test computers to collect data about any issues that might affect the mass distribution of the image to all computers. Test user data migration procedures. Ensure in-house software is working properly on the new operating system.

1.3 Upgrade Execute the upgrade, four offices per week, following the defined schedule (items 1.3.1 through 1.3.7). Four teams will be upgrading four offices concurrently, one team per office.

1.4 Training Provide the users training sessions in order to minimize the negative impact on productivity caused by the adoption of the new operating system software environment.

1.4.1 Prepare Training Materials

Develop training materials according to user needs and functional work. Provide access to online wiki resource for later reference.

1.4.2 Deliver Training Sessions Schedule the training sessions and communicate to all employees. Deliver the training sessions based on employee functional work.

1.4.3 Collect and Analyze Feedback

Develop feedback questionnaire to track progress of the training sessions and percentage of skills learned by employees. Recommend future training or individualized skills development tracks based on feedback collected.

1.5 Finalization Closing phase of the project that consists of ensuring all quality control, equipment disposal, and initial post-upgrade support as requested by the Ministry.

1.5.1 Provide Post-Upgrade Assistance

Allocate a team of supporting staff to answer user inquiries pertaining to the new equipment or software, assist with potential data migration issues, etc.

1.5.2 Perform Quality Control Monitor network bandwidth usage and collect performance and event data from sample computers across all offices to ensure the upgrade meet or exceed the project success criteria. Register and analyze user complaints (if any) using a ticketing system.

1.5.3 Manage Disposal of Old Equipment

Analyze residual value of old equipment. Sanitize storage on old computers. Ensure disposal of equipment complies with government standards.



{replace this page with Page06-WBS.pdf}



3. ACTIVITIES LIST With the scope baseline established, the team has identified the following key activities and dependencies:

WBS Name Duration Predecessors

1.1 Procurement 19 days

1.2 Software prep 23 days

1.3 Upgrade 35 days

1.3.1 Main Office - 10 PCS 5 days 1.1, 1.2

1.3.2 Offices 1 to 4 - 40 PCS 5 days 1.3.1






1.4 Training 20 days 1.3.1

1.5 Finalize 30 days 1.3, 1.4

During team meetings an argument was made that Office Upgrade steps don’t actually depend on each other, and

that they will be executed sequentially simply out of resource constraint (we have only so many teams, working so

many offices at a time) and that therefore the dependency should be removed. In other words, activity 1.3.3

should not depend on 1.3.2.

The team came to a consensus to leave the dependencies as shown in the table above, due to the overall desire to

avoid unnecessary risks. The upgrade team should not be starting the next office until there is a confirmation

(certainty) that previous office was upgraded successfully. Hiring more teams to avoid scheduling constraint would

not resolve this dependency, because the team does not want to run into a situation where a large number of

offices would be rendered non-functional by an upgrade process that could prove flawed as we go through it.

4. NETWORK DIAGRAM The next page shows the network diagram, which is based on the activities list. The diagram shows that for the

team to be on time, we must ensure that software preparation goes as planned, and that we adhere strictly to the

office upgrade schedule. These activities are the critical path of the project (shown in light-red). Any delay with

these efforts will force the team to consider crashing or fast tracking, or risk being late with the final delivery.

Activities shown in light-blue have slack (4 days for activity 1.1 and 20 days for activity 1.4) and therefore have

buffer to work with, in case delivery is delayed.



{replace this page with page08-network.pdf}



5. MILESTONE CHART Milestones – significant project events – were identified as follows:

Date Milestone Workstations

May 1, 2012 Project officially under way -

May 31, 2012 Standard image and software packaging is developed -

June 8, 2012 The main administration office is upgraded 10

June 15, 2012 5 administration offices upgraded 50



July 6, 2012 17 administration offices upgraded 170



July 20, 2012 Training delivered to Helpdesk -

July 27, 2012 QA / User Acceptance Testing completed -

August 3, 2012 All deliverables are finalized -

August 20, 2012 Staff reports to work; one month support begins -

September 21, 2012 One month support ends -

September 21, 2012 Project closeout meeting and signoff -

This milestone list departs slightly from the list proposed in the project charter. As a result of progressive

elaboration, the team has identified potential for fast-tracking and now plans to deliver training to helpdesk

personnel during the upgrade, using one of the upgraded offices as a training facility.

This resulted in minor reshuffling of the closing phase activities, and the team now expects to complete the project

20 days earlier than initially thought.

This delivery date change does not affect the total cost of the project but may affect the budget (training may need

to be funded in June or July, depending on Helpdesk staff availability, and not in August as initially planned).

As a result of this scheduling opportunity, the team has no activities planned between August 3 and August 20. The

team will use this window to verify deliverables and will remain available but in vacation mode. Support team will

report back to the Ministry on August 20 to begin one month onsite support.

The executive team was pleased with the milestone review and made a decision to postpone project closeout to

coincide with the last day of onsite support. The rationale is their desire to review severity and frequency of post-

implementation issues, since that affects overall impression of quality of the project deliverables. Therefore,

closeout date moved from August 31 originally, to September 21. However, this does not count as being late.



6. GANTT CHART Gantt chart summarizes scheduling information and presents an opportunity to perform resource leveling. Gantt

chart is presented on the next page.

Note that duration of the final activity on the chart, 1.5 Finalize, is shown as 50 days. It merely reflects the fact that

some of the nested activities (quality control) will be performed right after the last office is upgraded, but the last

activity (onsite support) will not end until 1 month from August 20. There is an idling gap within this activity, which

is not shown on the network diagram intentionally.

7. PROJECT COST ESTIMATES The following table provides an overview of cost estimates envisioned by the project team. These costs represent

expenses on outside contractors. Software and hardware are capital costs which will not be sourced from this

project’s budget.

Days/Cost Resources Total Scope Total Cost % of Total

WBS Items

1. Procurement $ 1,000,000.00 N $ - 0%

2. Software Prep 30/$135 ph 1 $ 32,400.00 Y $ 72,000.00 19%

30/$165 ph 1 $ 39,600.00 Y

3. Office Upgrade 35/$80 ph 8 $ 179,200.00 Y $ 179,200.00 47%

4. Training 26/$100 ph 1 $ 20,800.00 Y $ 20,800.00 5%

5. Finalize 25/$80 ph 4 $ 64,000.00 Y $ 64,000.00 17%

HST on Labor Y $ 43,680.00 12%

Total Project Cost $ 379,680.00 100%



{replace this page with page12-gantt.pdf}



8. PROJECT BUDGET Project budget shows how funding will be allocated over time. This estimate reflects scheduling adjustment which

has training delivery happening concurrently with office upgrades. Training funding will now be requested in July.

$-

$81,360.00

$115,712.00 $110,288.00

$28,928.00

$43,392.00

$- $-

$20,000.00

$40,000.00

$60,000.00

$80,000.00

$100,000.00

$120,000.00

$140,000.00

April May June July August September October



9. CUMULATIVE COST CURVE Cumulative cost curve is shown on the next diagram. The team will use this diagram throughout the project

lifecycle in order to perform earned value analysis.

April May June July August September

Series1 0 $81,360.00 $197,072.00 $307,360.00 $336,288.00 $379,680.00

0

50000

100000

150000

200000

250000

300000

350000

400000



10. EARNED VALUE ANALYSIS Earned value analysis is a cost control mechanism that the team is employing throughout the project. It allows the

team to determine where we are relative to the plan, both in terms of money and in terms of time. This evaluation

is numeric and not at all subjective.

To demonstrate how this team might apply this control, let’s consider a hypothetical scenario. During the month of

May, the two resources that were brought on to develop a software image did not work out. Termination of their

contract cost the team $20,000 in penalties, which came out of our contingency reserve. This set us back a little in

terms of being on budget.

Hiring the new resources somehow sped up creation of image deliverables, and allowed the technicians to start

upgrading offices sooner – so the first week of upgrades happened during the last week of May. This again set us

back a little in terms of being on budget, however this time we got further ahead on the project timeline.

Series1 shows Planned Value, Series2 shows Earned Value, Series3 shows Actual Cost. PV comes from the budget

plan and does not change. EV reflects the fact that we completed activity 1.2 (imaging) and started activity 1.3.1

(first office upgrade) in May, unexpectedly. AC reflects the fact that we absorbed $20K in unplanned expenses.

CV = EV – AC = $110,288 – $132,888 = -$22,600 (negative cost variance = we are over budget) SV = EV – PV = $110,288 – $81,360 = $28,928 (positive schedule variance = we are ahead of time) CPI = EV / AC = $110,288 / $132,888 = 0.83, cost performance indicator looks bad SPI = EV / PV = $110,288 / $81,360 = 1.36, schedule performance indicator looks good $20K charge can be considered as unpredictable one-time occurrence; EAC = AC + BAC – EV = $402,280

April May June July August September

Series1 0 $81,360.00 $197,072.00 $307,360.00 $336,288.00 $379,680.00

Series2 0 $110,288.00

Series3 0 $132,888.00

0

50000

100000

150000

200000

250000

300000

350000

400000



11. RESPONSIBILITY ASSIGNMENT MATRIX The team has analyzed responsibilities of each key participant of the project and determined the following.

R = Responsible A = Accountable C = Consult I = Inform

RACI Chart

Activities - TEAM VP

of

IT S

ervi

ces

Hel

pd

esk

Lea

d

Mac

aren

a -

Pro

ject

Man

ager

Den

nis

- E

xter

nal

Inp

uts

PM

OSE

IM

AG

ING

EX

PER

T -

Mar

k

PA

CK

GIN

G E

SPEC

IALI

ST -

Ste

ve

TRA

INER

- M

att

Gab

riel

- I

mag

ing

tea

m P

M

Sid

- T

ech

nic

ian

tea

m P

M

TEC

H0

1 -

Pau

l

TEC

H0

2 -

Sim

on

TEC

H0

3 -

Liz

TEC

H0

4 -

Ju

an

TEC

H0

5 -

Car

l

TEC

H0

6 -

Ted

dy

TEC

H0

7 -

Ash

ley

TEC

H0

8 -

Sar

ah

Procurement

Hardware selection C C A R C C I I I I I I I I I I I

Hardware and Software Procurement C C A R C C C I I I I I I I I I I

Software prep

Development of Standard Image I C A C R R C C I I I I I I I I I

Testing of Standard Image I C A C R R C C I I I I I I I I I

Upgrade

Main Office - 10 PCS

Hardware Assembling I C I I I A C R R I I I I I I I I

Computer Imaging I C I I A I C R R I I I I I I I I

On site equipment set up I C I I C C C A R I I I I I I I I

Main Office and Offices 1-24 (250 PCS)

Hardware Assembling I C I I I C C C A R R R R R R R R

Computer Imaging I C I I C I C C A R R R R R R R R

On site equipment set up I C I I C C C C A R R R R R R R R

Training

Prepare training material I A I I C C R C I I I I I I I I I

Deliver Training Sessions I A I I C C R C R R R R R R R R R

Collect and Analyse Feedback A R I I C C R C C C C C C C C C C

Finalize

Provide Traning Support I A I I C C R C C I I I I I I I I

Performe Quality Assurance I C I A R R R R R I I I I I I I I

Manage Disposal of old equipment I R A C I C I I I I I I I I I I I



12. RESOURCE HISTOGRAM Resource histograms are drawn to show overall workload placed on the project team during various stages of the

project. The histogram shown below gives an idea of how work distribution looked before minor changes were

introduced into the plan (training moved from August to July and onsite support extended into September).

0

50

100

150

200

250

300

350

W18

W19

W20

W21

W22

W23

W24

W25

W26

W27

W28

W29

W30

W31

W32

W33

W34

W35

May May May May May Jun Jun Jun Jun Jul Jul Jul Jul Jul Aug Aug Aug Aug

Resource Histogram Ministry of Education IT Upgrade Project



Work

Resources Total

External Inputs PM 232

Imaging and packaging team PM 40

Project Manager 232

Melissa Caretaker - VP of IT Services 8

Nick Handy - Helpdesk Lead 120

OSE IMAGING EXPERT - Mark 184

PACKGING ESPECIALIST - Steve 184

Technician team PM 40

TECH01 - Paul 240

TECH02 - Simon 240

TECH03 - Liz 240

TECH04 - Juan 240

TECH05 - Carl 240

TECH06 - Teddy 240

TECH07 - Ashley 240

TECH08 - Sarah 240

TRAINER - Matt 40

Grand Total 3000

Month Week Total Hours/ Week

May W 18 128

May W 19 160

May W 20 160

May W 21 160

May W 22 80

Jun W 23 144

Jun W 24 240

Jun W 25 320

Jun W 26 320

Jul W 27 320

Jul W 28 320

Jul W 29 320

Jul W 30 0

Jul W 31 0

Aug W 32 40

Aug W 33 48

Aug W 34 120

Aug W 35 120



13. STAKEHOLDER COMMUNICATION PLAN Stakeholder communication plan represents our team’s understanding of what communication is expected from

us, by whom, and how often. Communication is arguably the most important aspect of a successful project - we

have to ensure that our customers are well informed of the progress.

Stakeholder communication plan was prepared by performing analysis of the stakeholders in the project charter,

as well as their communication preferences (format, channel, frequency).

The team believes that the table below accurately captures the outcome of communication analysis.

Stakeholder Document Name Document Format Contact Person Due

Minister of Education (Representative of deputy)

Monthly status report Steering committee, PowerPoint

presentation, copy and file John Enlighten Veronica Cox

First Tuesday of each month

Financial Controller

Every two weeks status report

Meeting, PowerPoint presentation and minute, files.

Sarah Beancounter

Mondays


presentation, copy and file Sarah

Beancounter First Tuesday of

each month

VP of IT Services



Melissa Caretaker

Mondays


presentation, copy and file Melissa

Caretaker First Tuesday of

each month

PMO Coordinator



Monty Pathfinder

Mondays


presentation, copy and file Monty

Pathfinder First Tuesday of

each month

Helpdesk Lead

Weekly status report Meeting and minute by email Nick Handy Every Friday


presentation, copy and file Nick Handy


Facilities Manager

Weekly status report Meeting and minute by email Mary Keymaker Every Friday


presentation, copy and file Mary Keymaker


Datacenter Lead

Weekly status report Meeting and minute by email Robert Byte Every Friday


presentation, copy and file Robert Byte




14. QUALITY ASSURANCE PLAN The Quality Assurance plan is an important part of the project because we want to ensure that the upgraded

environment is fit for use before users come back to work on August 20. We have to ensure that they can log in to

the new workstations, that they can access their files in a similar manner as they did prior to the migration, and

that they are able to open new Office applications and work. So fit for use requirements will be established as

follows:

1. Ensure that all users can successfully log in to the new system

2. Ensure that all users can launch the new software

3. Ensure that all users are able to access their content (My Documents, Favorites, etc)

4. Ensure that performance of the new systems as measured by login wait time and application start time is

better than on the old systems

5. Ensure that users are able to print to the network printers

Justifying selection of these top 5 quality metrics is really simple: failing any one of the checks results in immediate

user dissatisfaction and helpdesk calls. This is unacceptable (and with some users, likely unavoidable during a

“forklift” upgrade like this one) but we must do everything we can to measure fitness for use for each office as a

whole. One user calling in on Monday is unavoidable; entire office not able to work because of some process flaw

during migration is unacceptable.

These 5 metrics were also matched to the top 5 user issues as reported by the Helpdesk ticketing system, so the

team knows that addressing these top 5 user concerns will result in immediate perception win for the team,

increasing not only productivity but also user satisfaction and overall happiness with the quality of IT services.

In order to measure conformity to these requirements, we will:

1. Log on using user ID/password on the new workstation (able to log in: YES/NO)

2. Launch the new applications (able to launch office apps w/o errors: YES/NO)

3. Double click on My Documents and confirm:

o permissions are set correctly (user able to access content YES/NO)

o file count and size matches to pre-migration numbers (COUNT and GB match)

o access works instantly without any delays on the network server side (YES/NO)

4. Stopwatch logon time / Outlook startup time (quicker than old systems: YES/NO)

5. Print a test page to the default network printer (page prints: YES/NO)

Failing any one of the checks will trigger investigation and remediation at migration time.

15. QUALITY CONTROL PLAN The Quality Control Plan is meant to identify and analyze patterns, in several key processes of the project, which

may indicate errors and failures in order to prevent delays in the schedule or quickly respond to them if they occur.

Since our QA metrics collect pretty low-definition data (YES/NO), we would rely on run charts and aggregate QA

data to understand if there are any process deficiencies. Such low definition data is not sufficient for scatter

diagrams, for example.



1. Successful logons – run chart showing how many logon failures were seen per office

2. New software launches – same as above

3. Being able to access content – same as above

4. Stopwatch test data can present more depth and will vary from desktop to desktop. We could plot this

quality area using a control chart, with higher threshold being defined as pre-upgrade average time to log

on (upgraded desktops must perform under that threshold or we have a quality issue)

5. Printing tests likewise present low-definition measurements and would be plotted using run chart

A Run Chart showing the number of mismatched file counts or file migration errors per user, per office, can also be

useful in identifying possible design issues in the user data migration process. We could gather this QA metric from

migration logs generated by the migration script. In this scenario, the Run Chart will be a powerful troubleshooting

tool because provides a visual overview of the migration process and the ability to quickly narrow down problems

(was this an isolated incident, or do we have a consistent pattern where 1-2% of all files fail to migrate? If the

latter, is this normal; i.e. are those files temporary/unneeded, or do we need to rework migration script and

therefore fix a problem in the process?)

We could plot logon times (stopwatch tests) on either a control chart, or using histogram approach. A Histogram

chart showing past and actual log on times, per user, or per office, could be created to show problem resolution

for one of the main issues outlined in the Project Justification Section of this document. The chart will be a visual

confirmation of the improvement in logon times (in seconds) when the upgrade is fully completed.

0

10

20

30

40

50

60

70

80

User1 User2 User3 UserX

File Corruption Error

File Count Error



This histogram could show sampling of logon times from 10 workstations in each office. New logon times need to

be A) non-random, B) below threshold (average pre-upgrade logon time). Violation of B would be deemed as a

failure to meet requirement and would be caught at QA level. Violation of A would indicate that there is some

issue elsewhere – maybe network, maybe defective image installation, maybe something else occurred randomly

on one or two systems. This would be of interest to QC: if this randomness is consistent, there is room for process

improvement; if it was one-off case, it can be dealt with as an exception.

Finally, if we determine that there is a process issue (flawed code logic in the migration script, or a software image

that did not include all desired configuration settings) and it has to be corrected, we could use flow diagram to

describe corrective workflow:

0

50

100

150

200

250

User 1 User 2 User 3 User X

Past Log on Times

Acctual Log on Times



16. RISK REGISTER Among the risks that could materially impact the outcome, the team identified the following:

External consultants may become unavailable due to last-minute scheduling issues

o The team will discourage double-booking at the contractual level, by establishing financial

remedies, and verifying that adequate notice requirements are set forth

External consultants may have overestimated their ability to perform the work on time or on budget

(happens frequently, due to perception in the consulting community that low bid wins)

o The team will deal with this issue at the contractual level. Finalists will be invited for in-person

interviews, at which point the project team will be able to question bids viewed as being

unrealistic, to understand the nature of the variance

Inherent to all software, hardware, and IT systems in general, bugs and unforeseen (unforeseeable) issues

do come up. Their severity and impact on timelines are difficult to estimate given inherent

unpredictability

o The team will ensure that vendor support contracts and warranties provide access to vendor

support in a timely manner

o One risk still remains in the area of user state and data migration from old desktops to new

desktops; given our existing approach to storing user data (i.e. decentralized and non-

standardized), various issues are expected to come up during migration

Labour action was considered and dismissed as a risk

o No collective bargaining contracts are coming up for renewal during our project

Funding availability is not a significant risk in this project

o Funds have been allocated and will be approved for payment when milestones are reached

o Furthermore, expectations will be set with all vendors that payments will be made in arrears

MGS resources may not be available for consultations during summer vacations period

o The team will reach out and request availability and time commitments from MGS as soon as

possible

Microsoft or Dell resources may not be available on a short notice for architecture consultations

o This is a minor risk, since our MGS consultations will help us determine general approach to IT

architecture, and our external SMEs will provide high quality services that will leverage the

functionality of the products

WAN and server upgrade at the Ministry may overlap with our project work

o The team will reach out to our server-side counterparts to clarify their scheduling

Ministry employees (helpdesk and/or end users) will still be out on vacation during training

The team has also reviewed Assumptions listed in Scope Statement and Risks listed in the Charter.



{replace this page with risk register PDF}



17. PROCUREMENT PLAN The following procurement items and/or services have been determined to be essential for project completion and

success. Make or buy decision is not relevant for this project, we will buy the hardware and software. We will

however bring outside contractors to perform the upgrade and provide post-upgrade support.

The following list of items/services, justification, and timeline are pending PMO review for submission to the

contracts and purchasing department:

Item/Service Justification Needed By

Hardware Requirement of 250 new computers and network cables that needed to be distributed to all 25 offices

31 May 2012

Software Access to media is required for the imaging process. Software licenses are required for the deployment phase

1 May 2012

Technicians Need 8 technicians for hardware assembly, on site equipment set-up and computer imaging and to perform stand by support and QA after implementation

4 June 2012

Trainers Needed to prepare training material, deliver training, and analyze feedback

2 July 2012

General Labor To dispose of the old equipment, requesting internal ministry resources

20 August 2012

While the purchasing and contracts department has their own internal metrics for procurement, the following

vendors were recommended based on their existing relationship with the Ministry and satisfactory review of the

service history and pricing level relative to the current fair market prices. Standard equipment (common vendor) in

IT lowers total cost of ownership by reducing support costs (training, familiarity, fewer or common issues, etc).

We have recommended to the hardware procurement team a fixed price contract with our vendors. SoftChoice

will provide software licensing, and hardware will be contracted to Dell Computers:

Vendor Product Quality

On Time

Delivery

Documentation Quality

Development Costs

Development Time

Cost per Unit

Transactional Efficiency

Dell Computers

Good Avg Good Good Good Good Good

SoftChoice Good Good Avg Avg Good Avg Good