Table of Contents

ABBREVIATIONS 4
1: EXECUTIVE SUMMARY 5
1.1 COMPANY AND INDUSTRY DESCRIPTION 5
1.2 PROJECT DESCRIPTION 5
1.3 CASE STUDY FINDINGS 5
1.4 CRITICAL EVALUATIONS AND RECOMMENDATIONS 6
1.5 CONCLUSION 7
2: DATA SOURCES, REFERENCES, METHOD OF ANALYSIS 8
2.1 PEOPLE 8
2.2 INFORMATION AND REFERENCES 8
2.3 METHOD OF WORK 9
3: PROJECT DESCRIPTION –BACKGROUND AND HISTORY 9
3.1 BACKGROUND 9
3.2 OBJECTIVE 11
3.3 DETAILED DESCRIPTION 12
3.4 MAJOR MILESTONES 13
4: PRODUCT AND PROJECT CHARACTERISTICS 13
4.1 PROJECT SCOPE 13
4.2 PROJECT SIZE AND DURATION 15
4.3 TECHNOLOGY ADOPTION LIFE CYCLE (TALC) 15
4.4 LEVITT’S WHOLE PRODUCT 17
4.4.2 WHOLE PRODUCT - FEATURES 18
4.6 SHENHAR UCP CLASSIFICATION 20
4.7 WHEELWRIGHT AND CLARK (W&C) 24
5. PROJECT SUCCESS MEASURES AND BUSINESS PERSPECTIVE 28
5.1 BUSINESS PERSPECTIVE 28
5.2 OVERALL SUCCESS 29
5.3 EXPLICIT OR IMPLICIT OBJECTIVES 30
5.4 SUCCESS DIMENSION OBJECTIVES AND RESULTS 30
5.5 UNEXPECTED RESULTS 31
6. PROJECT STRATEGY AND COMPETITIVE ADVANTAGE 31
6.1 COMPETITIVE ADVANTAGE 31
6.2 VALUE TO THE COMPANY 32
6.3 PRODUCT DEFINITION PROCESS 33
6.4 STRATEGY ALIGNMENT 34
6.5 STRATEGY AND COMPETITIVE ADVANTAGE/VALUE 35
6.6 PROJECT VISION 36
6.7 CLAIM STATEMENT – USING CROSSING THE CHASM STYLE 36
6.8 CLAIM STATEMENT – USING REVISED PROJECT STRATEGY STYLE 37
6.9 STRATEGIC FOCUS 37
7. PROJECT SPIRIT AND LEADERSHIP 39
7.1 ORGANIZATIONAL CULTURE 40
7.2 PROJECT SPIRIT 40
7.3 POLICY 41
7.4 LEADERSHIP 41
7.5 PROJECT TEAM EMPOWERMENT 44
8. ORGANIZATION 44
8.1 PROJECT ORGANIZATION 44
8.2 PROJECT STRUCTURE 45
8.3 TEAM SELECTION 46
8.4 WORK ASSIGNMENTS 47
8.5 TOP MANAGEMENT INVOLVEMENT 48
8.6 PROFESSIONAL ADVICE AND REVIEWS 48
8.7 ORGANIZATIONAL PROBLEMS 48
8.8 TRAINING 49
9. PROCESSES 50
9.1 PROJECT PHASES 50
9.2 PMBOK PROCESSES 51
9.3 WORK BREAKDOWN STRUCTURE (WBS) 52
9.4 RESOURCES ESTIMATIONS 52
9.5 SYSTEMS ENGINEERING 53
9.6 REDUCING MARKET UNCERTAINTY 54
9.7 REDUCING REQUIREMENTS UNCERTAINTY 54
9.8 RISK MANAGEMENT 55
9.9 REDUCING TECHNICAL UNCERTAINTY 55
9.10 SYSTEM INTEGRATION AND TEST 56
9.11 PROJECT MONITORING AND CONTROLLING 56
9.12 COMMUNICATION MANAGEMENT 56
9.13 CUSTOMER READINESS 57
9.14 VENDOR MANAGEMENT 57
10. TOOLS 58
10.1 COMMON PROJECT MANAGEMENT APPLICATIONS 58
10.2 SPECIFICALLY DEVELOPED TOOLS FOR THE PROJECT 58
10.3 DOCUMENTS 58
11. ADAPTATION TO SPECIFIC PROJECT TYPE 59
12. LEARNING 60
12.1 PRE-PROJECT LEARNING 60
12.2 ON-GOING LEARNING 61
12.3 POST PROJECT LEARNING AND LESSONS LEARNED 61
13. SUCCESS FACTORS 61
13.1 PROJECT MISSION 62
13.2 TOP-MANAGEMENT SUPPORT 62
13.3 PROJECT SCHEDULE/PLAN 63
13.4 CLIENT CONSULTATION 63
13.5 PERSONNEL 63
13.6 TECHNICAL TASKS 64
13.7 CLIENT ACCEPTANCE 64
13.8 MONITORING AND FEEDBACK 64
13.9 COMMUNICATION 65
13.10 TROUBLE-SHOOTING 65
14. MAJOR PROBLEMS AND CHANGES 65
14.1 MAJOR PROBLEMS 65
14.2 CHANGES 66
15. CRITICAL EVALUATION 67
16. RECOMMENDATIONS 70
17. CASE STUDY ANALYSIS LESSONS LEARNED 72
APPENDICES 1
ORGANIZATION CHART 1
INTERVIEW NOTES WITH PROJECT PARTICIPANTS 1

ABBREVIATIONS
Description List Your ALIASES Below Abbreviation Used
Company 1 Vancouver Banking Group VBG
Company 2 New Amsterdam Securities NAS
Project Name New Amsterdam Securities Technology Integration NASTI
Product Name PowerTrade PT
Deliverable Disaster Recovery Facility DR
Location 1 Uptown, Manhattan (VBG US) UT
Location 2 Wall Street, Manhattan (NAS) WS
Project Manager 1 Project Manager (VBG US) PM
Project Manager 2 Project Manager (VBG US) PM2
Project Coordinator Project Coordinator PROJ.CRD
System Administrator System Administrator (formerly NAS) SA
Leader of System Administrators group Leader of System Administrators group (f
ormerly NAS) LSA
1: Executive Summary
Start the case study with an Executive Summary that can be used for organization
al learning.
Make this section compelling enough such that an executive will want to read you
r case study.
1.1 Company and Industry Description
Give a brief history of the company and the industry.
Vancouver Banking Group (VBG) is a growing global financial services company hea
dquartered in Vancouver, Canada. VBG had a significant presence in New York and
decided to bolster its capital markets portfolio with a purchase of Wall Street
broker-dealer called New Amsterdam Securities (NAS).
1.2 Project Description
Give a brief description of the project.
VBG had experience with prior acquisitions and knew it would realize significant
cost savings by reducing technology spending, if it merges NAS IT infrastructur
e with its own. NAS Technology Integration (NASTI) project was created to conve
rt NAS desktops, servers, telephones, network and PowerTrade (PT) trading enviro
nment back-end to VBG standards and merge them with VBG systems and support stru
ctures. A disaster recovery environment would also be created for NAS systems,
which previously did not exist.
1.3 Case Study Findings
Summarize the main points in your case study.
The NASTI integration project was successful because it was planned, executed, m
onitored, controlled and completed well. The project was an early majority. Ac
cording to Levitt’s whole project framework it was a generic product. Customer
type was internal according to the TALC. This project was typical to the organi
zation and only involved incremental change and addition to the family, making i
t a derivative project according to the W&C framework. The Shenhar UCP classifi
cation places NASTI into medium uncertainty due to previous experience with simi
lar projects, and an array complexity because it entailed upgrading multiple sys
tems, all of which had multiple subcomponents. Pace was regular because some ot
her projects took priority. Careful planning and successful completion were mor
e important than finishing a project in a short time. Corporate, business, and
operations strategies were clearly stated and aligned. The project has achieved
competitive advantage. The project’s strategy was to achieve cost advantage.
This was done by leveraging operational efficiencies, incorporating strict corpo
rate standards, and realizing cost-savings. The NASTI project aimed to succeed
in two dimensions: impact on business and building for the future. The competit
ive advantage was pursued relentlessly and strategically.
1.4 Critical Evaluations and Recommendations
Describe your top three recommendations in prioritized order, why they are impor
tant and how they can be implemented.
NASTI was completed successfully but not flawlessly. VBG should concent
rate on the following three areas to improve future projects.
1. Capacity planning. NASTI ran into delays when it became apparent that e
xisting UT data center couldn’t support an addition of 110 new servers. Capacit
y planning is a required discipline that VBG needs to follow meticulously and ro
utinely. Better project planning is also needed to avoid such pitfalls in the f
uture.
2. Lessons Learned. Lessons learned were not documented – this is a major
oversight. This documentation should be created for every project, updated thro
ughout the project’s life and made searchable and available and to the entire or
ganization. Lessons learned help avoid repeating old mistakes and accelerate fu
ture success by mapping out prior paths to it.
3. PM presence on site. VBG is a global organization that leveraged its Ca
nadian project management talent for NASTI. While this didn’t seem problematic
at first, a careful analysis of the project shows that having the PM on site wou
ld have prevented some mistakes, increased PM’s availability to the team and cre
ated efficiencies. Having a PM on site of the project is highly beneficial.
1.5 Conclusion
What conclusions can be drawn from this case study?
NASTI was completed successfully. It owes its success to the following factors.
The project was well planned out. It had strong support of the sponsor and th
e upper management. Project goals were well defined and understood by all the p
roject participants. There was good communication between the project managemen
t team and the project participants. The latter were highly skilled professiona
ls, knowledgeable in their field and highly committed to teamwork, knowledge sha
ring and project success. The project was well executed.
2: Data Sources, References, Method of Analysis
This is a critical section. It should be short, but clear. Describe your sourc
es of information – people and documents, how these sources were used, and your
method of analysis.
2.1 People
Identify the interviewees. Include a list of the people who provided informatio
n about the project – it is not necessary to include their names, instead, inclu
de their position or role in the project, how long they involved, how long were
the interviews. You must talk to the Project Sponsor and Project Manager. You
should also interview some Project Team Members, Customers, Functional Managers,
and Vendors. Use these titles throughout the case study. Do not use real names
or fictitious names for people. Identify people by their title. Insert additiona
l lines if there was more than one person that held the same title on the projec
t. Number the title holders Project Manager 1 versus Project Manager 2. The more
interviews you include, the better. You should document the dates and durations
of your interviews. You must include copies of your handwritten interview notes
in the Appendix.
TITLE YEARS IN
INDUSTRY YEARS IN
COMPANY MONTHS ON
PROJECT INTERVIEW DATES (MM/DD)
(DURATION - MINUTES)
PROJECT SPONSOR MM/DD(NN)
PROJECT MANAGER 14 8 39 02/23: 35MIN, 03/25: EMAIL 04/10: 75MIN
SYSTEM ADMINISTRATOR 10 2 21 02/20: 25MIN, 03/25: EMAIL 04/01
: 90MIN
LEADER OF SYSTEM ADMINISTRATORS 22 11 39 02/20: 35MIN, 02/27: EMA
IL 03/20: 15MIN
PROJ. CRD 10 3.5 36 03/19 E-MAIL
FUNCTIONAL MANAGER
VENDOR
OTHER (DESCRIBE)
2.2 Information and References
Include a table of project documents, meeting minutes, e-mails, guidelines, arti
cles, books and other references that you were allowed to review or that you wil
l reference in the case study. Do not include copies of these documents in this
case study. Indicate “Kept Up-to-Date” by ‘Yes’ or ‘No’, by whether there were r
evisions. “Assess Usability” as ‘Yes’ or ‘No’, if the document was readable, cle
ar and detailed. “Assess Value” with ‘Yes’ or ‘No’, by asking the interviewees i
f they found the document valuable. If you did not see a specific document and y
ou felt it should have been made available to you indicate “MISSING” in the “Kep
t Up-to-Date” column.
DOCUMENT TITLE DATE ISSUED LENGTH KEPT UP-TO-DATE? ASSESS USABILITY
ASSESS VALUE
MOVE PLAN STRATEGY N/A 12 YES YES YES
STATUS REPORTS DIFFERRENT DATES 1-5 YES YES YES
MIGRATION TASKS AND SCHEDULE DIFFERRENT DATES 8-20 YES YES
YES
CONSOLIDATED ACTION ITEMS DIFFERRENT DATES 4-13 YES YES
YES
INTEGRATION PLAN 06/2006 26 YES YES YES
MEETING NOTES DIFFERRENT DATES 1-5 YES YES SOMEWHAT
INFRASTRUCTURE PLAN 08/2006 35 YES YES YES
ISSUES LOG 01/2007 8 YES YES YES
2.3 Method of Work
Describe the kind and type of data you collected. How was this data collected?
Describe your method of analysis. Mention the theoretical background for your a
nalysis, the frameworks that were useful for your work, and their references. Es
pecially include those that were not part of the syllabus of this course.
The data that I collected was administrative documentation prepared and provided
to me by the PROJ.CRD. These documents tracked planning and scheduling of move
s and migrations. The data listed in the consolidated action items recorded all
the changes that were done on the project and it also described how the executi
on process worked. Status reports and meeting notes provided project status, an
d facilitated monitoring and controlling the project. The theoretical backgroun
d for my analysis and the frameworks that were useful for this case study came f
rom Dr. Poli’s dissertation and other articles that were provided throughout the
semester. All other information was extracted from the documents that were col
lected for my case study and through class discussions.
3: Project Description –Background and History
3.1 Background
Describe the environment and the background of the project. Why was it done? W
hat was the motivation? How was it initiated? Who came up with the idea? What
happened before the project was initiated? How did the idea evolve? Who pushe
d it? How did it turn into a formal project? How long did it take to turn it i
nto formal project?
In November 2005 Vancouver Banking Group made financial news headlines when it a
nnounced its acquisition of New Amsterdam Securities, a Wall Street broker-deale
r known for its electronic trading platform – PowerTrade. This purchase allowed
VBG to expand its US presence and create a more complete and compelling capital
markets product portfolio.
It was determined from the start that all technology operations of NAS should be
merged and folded into the existing infrastructure of the larger VBG. This wou
ld include the migration of the PT back-end and supporting infrastructure, as we
ll as desktops, servers, networks and telecommunications equipment. This would
result in many operational efficiencies and financial benefits. Firstly NAS wou
ld move into the Uptown (UT) office building used by VBG. This would allow for
significant savings in network and market data feed costs. Standardization on c
ommon technology and procedures would result in fewer technicians needed to supp
ort the environment. Future technology expenditures on upgrades, licenses and n
ew products would cover a unified larger organization and would result in vendor
discounts. In addition to all of these benefits, financial companies are bound
by a myriad of regulations from several federal and state agencies, as well as
industry associations. Maintaining one technology platform removes a lot of com
plexity from compliance with all the laws and regulations.
VBG was a big and long established firm; it had significant experience with prev
ious mergers and acquisitions. Benefits discussed above were already realized i
n previous deals and didn’t require a long feasibility study in this case. Once
the acquisition of NAS was completed in January 2006, Capital Markets division’
s management contacted the project management team and created the project with
the above stated goals. The project was officially sponsored by the Managing Di
rector (MD) of the Equities division.
3.2 Objective
What was the objective of the project result (product, process, service, improve
ment, etc.)? What does the customer or user need? How will the project result
be used and serve this need? What are the expected advantages from the project?
The objective of this project was to migrate phones, desktops, servers and netwo
rks to VBG standards, consolidate NAS Wall Street (WS) data center at UT and fac
ilitate the setup of a DR site. The project was completed strategically; the mo
ve strategy was in place and consisted of four main objectives to achieve final
goals:
• Migrate end-user equipment and move the WS data center to UT
• Setup a DR facility as part of the move
• Minimize affect on clients
• Minimize risk to clients and to the reputation of VBG
The objective of the project result was to move technology operations and suppor
t to the parent company’s location. It was extremely important that this move h
appen as transparently as possible to minimize any down time or disruptions to t
he users and customers of NAS and PT. As discussed in 3.1 this would result in
significant cost savings in the IT budget. Migration to VBG standards would als
o prevent a creation of the patchwork of technologies that are difficult to supp
ort, upgrade and keep in compliance.
Due to federal regulations and the need for the resiliency of the business, it w
as also imperative to create a functional DR site. This site would house redund
ant systems, connections and office space and had to support full operations of
PT in case of any problems at the UT facility, such as a terrorist attack, power
or network outages, flood, fire or any other natural or man-caused disaster.
3.3 Detailed Description
Include a detailed description of the project’s enfolding history, process, and
timeline. Describe main events, milestones, decisions, difficulties, and crises
, and the way they were handled. Include interesting and relevant quotes as expr
essed by interviewees.
Ever since the purchase negotiations it was clear to the top management of both
firms that the purchase of NAS would involve tight integration with VBG on all l
evels and departments, including and especially IT. When the purchase was compl
eted there was full buy-in from the management for the NASTI project.
During the project execution phase it became evident that a lot of existing infr
astructure at UT would need to be expanded before it can support the added requi
rements of PT. New desktops and phones would need to be purchased for all NAS e
mployees as their original equipment didn’t meet VBG standards. Network routers
and switches needed to be purchased and new fiber and copper wiring needs to be
laid to handle all the extra traffic. The most challenging part of the expansi
on involved the UT data center. The existing one was not capable of handling ab
out 110 new servers needed, not to mention future organic growth. Per SA: “Expa
nding the data center was very challenging. Building out the extra space requir
ed construction work and permission from the building. More power, cooling and
UPS (Uninterruptible Power Supply) capacity had to be installed. New server rac
ks had to be purchased and installed. All of this was expensive and time consum
ing and had a potential of causing significant delays to the project. A separat
e project was created to handle the data center expansion.”
3.4 Major Milestones
Include no more than 10 of the major project milestones. List them from the earl
iest to the last.
MILESTONE DATE (MM/DD)
1 PHASE 1 – PARTIAL DESKTOP INTEGRATION
SECURITY, LEGAL AND COMPLIANCE REQUIREMENTS
FIREWALLED NETWORK ACCESS
VBG LOGINS AND CITRIX ACCESS 1/9/06 – 7/14/06
2 PHASE 2 – DESKTOP & PHONE MIGRATION 2/6/06 – 9/26/07
3 PHASE 3 – PT MOVE
NETWORK
MARKET DATA
FACILITIES
SERVERS
DISASTER RECOVERY PLANNING, IMPLEMENTATION & TESTING
CLIENT & USER PT MIGRATION 1/9/06 – 12/12/08
4 PHASE 4 – NAS DATA CENTER DECOMMISSIONING & CLEANUP 1/5/09 –1/30/09
4: Product and Project Characteristics
Characterize the project according to different classification schema.
4.1 Project Scope
Which functions of the organization were involved on this project? Which functio
ns were included in the core team? Which functions were included in the extended
team? Which functions were called upon infrequently? Which functions did not pa
rticipate in this project? Should any of those functions have been represented o
n this project? Why were they excluded? Were any outside organizations or consul
tants used? What was the extent of their role versus the role of internal staff?
Did all of the functions and consultants participate in the project from the be
ginning? If not, why not?
13 IT business units worked on NASTI project. Project’s successful completion d
epended on the following teams: information security, helpdesk, storage area net
work, network, sever, telecommunications, desktop, service quality management, P
T development, data center, business requirements, business continuity planning
and project management. Three project managers, information security team, serv
er team, business continuity planning team, PT developers, and data center team
comprised the core team. Storage area network team, business requirements team,
and desktop team made up the extended team. Functions of facilities, helpdesk
analysts, service quality management team, business requirements team and teleco
mmunications team were called upon infrequently. All the business units from NA
S were incorporated into VBG, but their involvement was not necessary in the int
egration project. As stated by the system admin “all relevant areas of IT were
involved”.
Two consultants were hired temporarily for the maturing phase of the project. P
roject coordinator consultant was hired to assist with planning and coordinating
administrative activities of the project. System administrator consultant was
hired to write scripts for desktop migration, but was removed from his duties sh
ortly, due to the quality of work that he produced. Some of his scripts were us
ed, but most of the desktop migration process wound up being manual.

4.2 Project Size and Duration

TOTAL BUDGET IN US$ ~4MM
DURATION – IN MONTHS ~39
NUMBER OF PEOPLE INVOLVED
AT THE PEAK? 44
ON AVERAGE? 30
NUMBER OF ORGANIZATIONS AND SUBCONTRACTORS INVOLVED
DOMESTIC? 13
GLOBAL? 0
4.3 Technology Adoption Life Cycle (TALC)
4.3.1 TALC Customer Type
Apply Rogers’ Technology Adoption Life Cycle. Was the customer an Internal or Ex
ternal customer? Identify and describe the customer’s Customer Type: Innovator,
Early Adopter, Early Majority, Late Majority or Laggard. Was the project for th
e government, industrial, or consumer market? Was there a formal customer who c
ontracted for the project? Was the project internally funded? What were the so
urces of funding?
The customer was internal. Customer type was early majority. One of th
e main reasons VBG was attracted to the NAS is because of their trading software
(PT) that was well established and well supported. Prior to NAS purchase VBG d
idn’t have their own trading platform and had to do their trading through other
companies. That was costly and the company wanted to have its own solution to c
ut costs and facilitate better customization. PT was a solution they were looki
ng for. PT had almost all the features VBG wanted and it was easy to use. This
project was industrial. Project was internally funded by the equity division.
Internal budget was the source of funding.
4.3.2 TALC User Deployment Strategy
Describe the user deployment strategy. Were there several clients or users? List
the users in the sequence that they were deployed to. Identify the Customer Typ
e of each of the users. Was the Deployment Strategy consistent with Rogers’ Tech
nology Adoption Life Cycle diffusion of innovation theory? For example, was the
first user deployed to an Innovator, was the second user an Early Adopter, etc.
Was a user deployed to out of sequence? Why? Did this cause any problems for the
project? Could that user just as easily have been deployed to in the proper TAL
C sequence?
The Deployment Strategy of PT application to VBG users and end-user equipment (P
Cs and telephones) to NAS employees was consistent with Roger’s Technology Adopt
ion Life Cycle diffusion of innovation. The bulk of NASTI project including dat
acenter, server, network and telecomm back-end migration wasn’t consistent with
TALC. It was almost completely transparent to the users and therefore didn’t ne
ed to follow TALC.
PT Deployment Strategy followed TALC, see chart below:
USER TALC TYPE FEATURES INCLUDED
INNOVATOR • PT DEVELOPERS
EARLY ADOPTER • SYSTEM ADMINISTRATORS
EARLY MAJORITY • FUNCTIONAL MANAGERS/TESTERS
LATE MAJORITY • END-USERS
4.3.3 TALC User Features
Did different user types get different versions? Were different features include
d that appealed to the different user types? Provide at least two features for e
ach User Type. Determine what the features would or will be for each User Type
regardless of current project stage.
Everyone got the same version of PT software and equipment. PT was a very matur
e and comprehensive product. While some changes were made to the product, such
as changing names, logos and adding Canadian exchange feeds and trading, they we
re outside the scope of this project. These changes or feature updates were han
dled early on as part of the SDLC or Systems Development Live Cycle. NASTI was
only concerned with infrastructure integration, not application development.
USER TALC TYPE FEATURES INCLUDED
INNOVATOR • NAS PT WAS RENAMED INTO VBG PT AND ITS ICONS & LOGO WERE
CHANGED
EARLY ADOPTER • CANADIAN ECHANGE FEEDS WERE ADDED
• EXPORTING AND PLUGIN OPTIONS WERE UPDATED FOR APPLICATIONS LIKE MS EXCEL
TO PROPERLY SUPPORT THESE FEEDS
EARLY MAJORITY • TRADING ON CANADIAN EXCHANGES WAS ADDED
LATE MAJORITY • NO SPECIAL FEATURES ADDED
4.3.4 Identification of TALC Risks
Did this discussion of TALC elicit discussion of potential risk identified by th
e project participants? Was that risk identified at the time of the project? If
not, why not? What was done to mitigate these risks?
Justify and include Stakeholder quotes to support your TALC Risk discussion.
As stated earlier, the bulk of the NASTI project didn’t follow TALC as it didn’t
need to. There were no TALC risks.

4.4 Levitt’s Whole Product

4.4.1 Whole Product - Product Scope
Use Levitt’s Whole Product Model. What kind of work was done? What was included
? What was not included? Was it a development of a new product? Did it involv
e building just a prototype? Or building the production facility and process fo
r the product? Did the results/deliverables of the project require changes to t
he product, the process, or both? How many items were produced on this project?
Describe the product/service, documentation, training, equipment, or other del
iverables.
According to Levitt’s Whole Product Model the integration systems projects, such
as NASTI are called generic product for the reasons below:
“Bring Together Components or Systems
Make Them Cooperate Properly
Achieve Desired Functionality
Phased Implementation”
o Phase 1 dealt with “Day 1” compliance/legal IT requirements
o Phase 2 addressed the desktop integration
o Phase 3 dealt with moving the servers/data centre to VBG
Changes to PT and the integration of PT software was not included in this projec
t. All the VBG standards and existing technologies were retained; no new produc
ts or processes were introduced. The integration project produced a single stan
dard environment in one location. Combined environment removed overlaps and ass
ociated expenses and offered systems that are easier to support, upgrade and kee
p legally compliant. There were not any changes to the processes or to the prod
uct. NASTI integration was successful due to careful planning and execution. T
he project deliverables included successful integration of NAS technology infras
tructure into VBG’s technology infrastructure. Per PPOJ. CRD: “The project produ
ced savings in the areas of salaries/headcount, facilities, market data, data ce
nter, telephone and computer equipment. Employees from NAS were integrated into
VBG employee directory and new location maps of where employees are located wer
e designed.” Lessons learned were not produced officially, but should have been
.
4.4.2 Whole Product - Features
What features were included in each of the Whole Product packages?
Provide at least two features for each Whole Product category.
Determine what the features would or will be for a category regardless of curren
t project stage.
LEVITT’S WHOLE PRODUCT FEATURES INCLUDED
GENERIC PRODUCT • MIGRATION OF NAS DATA CENTER TO VBG UT
• UNIFIED IT ENVIRONMENT UNDER VBG STANDARDS
EXPECTED PRODUCT • MINIMUM DISRUPTIONS TO CLIENTS & USERS
• MINIMUM RISK TO CLIENTS AND TO THE REPUTATION OF VBG
AUGMENTED PRODUCT • EASIER TO SUPPORT, UPGRADE AND KEEP LEGALLY COMP
LIANT
• COST SAVINGS FROM NETWORK AND MARKET DATA FEED CONSOLIDATION
• SETUP A DR FACILITY AS PART OF THE MOVE
POTENTIAL PRODUCT • COST SAVINGS FROM REDUCED IT PERSONNEL
• COST SAVINGS FROM VENDORS ON LICENCES, FUTURE UPGRADES & NEW PURCHAES

4.5.1 Project Deliverable Life Cycle

Did the project deliverables go through each of the four distinct project types,
one project at a time or did the project deliverables go through multiple proje
ct types in a bundled project execution? Did this help or hinder the development
of the project deliverables? Did this help or hinder the customer acceptance of
the project deliverables? Did this help or hinder the user acceptance of the pr
oject deliverables?
Per Dr. Poli’s dissertation “Add-ons, new packaging, materials, cost-reduction o
r manufacturing efficiencies can result from this (derivative) type project”. N
ASTI is a derivative project that involved an addition to (VBG IT) product famil
y. The project deliverables did not go through the four distinct project types,
one life cycle at a time. The project deliverables did not go through multiple
project types in a bundled project execution. This didn’t hinder the developme
nt of the project deliverables or their acceptance by the users or customers bec
ause NASTI was an internal project and involved only incremental change.
4.5.2 Project Deliverable Life Cycle - Features
What features were included in each of the project types?
Provide at least two features for each Project Life Cycle stage.
Determine what the features would or will be for a stage regardless of current p
roject stage.
Were multiple project types attempted in this project?
If yes, indicate which ones by placing an X in the first column.
PROJECT LIFE CYCLE FEATURES INCLUDED
R&D PROJECT • •
BREAKTHROUGH PROJECT • •
PLATFORM PROJECT • DATA CENER MIGRATION
• DR
DERIVATIVE PROJECT • TELECOM
• DESKTOP
• SERVER
• NETWORK
4.6 Shenhar UCP Classification
You MUST justify and include “Stakeholder quotes” to support your classification
s.
4.6.1 Technological Uncertainty
Relative to your company classify the Technological Uncertainty of this project
as
• Low Tech
• Medium-Tech
• High-Tech
• Super High-Tech
Justify and include Stakeholder quotes to support your Uncertainty classificatio
n.
NASTI was a medium-tech project. VBG had experience with purchasing smaller fir
ms and integrating them into its operations. On the other hand, NAS was a high-
tech financial company and their PT system was technology-heavy and its integrat
ion would involve a certain degree of complexity and risk.
The interview with LSA: “There was no doubt that NAS systems work or that they m
eet basic regulatory standards. What was not clear, was which parts of PT and i
ts infrastructure would have to be changed to comply with VBG standards or what
variances would have to be granted or new standards introduced. Whatever change
s would come, all systems would have to work well and be interoperable.”
4.6.2 Complexity or System Scope
Relative to your company classify the Complexity of this project as
• Assembly or Component
• System
• Array
Justify and include Stakeholder quotes to support your Complexity classification
.
NASTI involved array complexity. It entailed upgrading of multiple systems such
as telephony, networking and server operations. Each of these systems has had
multiple subcomponents: software, hardware, networking, licensing, facilities, e
tc…
From follow up e-mail from LSA: “Integrating each of these systems had its own c
omplexity, take our servers for example: VBG standardizes on IBM servers, all of
NAS servers were from HP. To reduce complexity of support and upgrades, VBG wa
nted all servers to be replaced with IBM models. For Phase I of the project 40-
something IBM servers were purchased and configured for PT. At that point, it w
as expected that HP servers that were freed up could be sold back, so that more
IBM servers could be purchased. It turned out that we were offered very little
money for our existing HP servers and that this trade-in would not be cost effec
tive. It was decided to keep our newer and more powerful HP servers for the sec
ond phase of the migration and simply to upgrade their memory and to configure t
hem for VBG operating system standards. Other systems had their own complexitie
s and problems.”
4.6.3 Pace
Relative to your company classify the Pace of this project as
• Regular
• Fast Competitive
• Time-Critical
• Blitz-Critical
Justify and include Stakeholder quotes to support your Pace classification.
The pace for NASTI was regular. VBG expected NAS to be integrated with its own
IT infrastructure as soon as possible, but some other projects were more importa
nt. Per LSA: “As the project was getting started, VBG’s US operations were grow
ing and were involved in multiple other projects. Some of the other projects to
ok priority and at times resources were not available because they were involved
on other projects.” Integrating NAS did not go exactly according to plan or sc
hedule.
4.6.4 Identification of UCP Risks
Did this discussion of UCP elicit discussion of potential risk identified by the
project participants? Was that risk identified at the time of the project? If n
ot, why not? What was done to mitigate these risks?
Justify and include Stakeholder quotes to support your UCP Risk discussion.
Risk breakdown structure was developed and potential risks were identified prior
to the PT system move. VBG had vast experience with integration projects of th
is nature. They knew the complexity of the move and what needs to be done to mo
ve such a massive system as a data center. VBG also wanted to get PT integrated
and running promptly. Their biggest concern was delay of the project. To miti
gate the risk of delay they planned to have enough experienced staff at both loc
ations, production and back up equipment, ensured that all paperwork is complete
d, their lease does not expire before the move. VBG was also concerned with the
equipment move. They knew that if equipment is damaged or lost in transit, the
y will need time to restore applications and data onto spare servers in UT. The
y did equipment moves on Friday nights to mitigate the risk of such occurrence.
From the phone interview with PROJ.CRD on Complexity, Pace and Uncertainty:
“Complexity:
Before PT servers could be moved to UT there were many prerequisites. The netwo
rk had to be setup in UT. Data center and its racks, power, cooling and UPS had
to be expanded. Any delays in these tasks would result in project delays, and
in fact they did.
Pace:
There was a risk of delays. PT was a production system in a constant state of c
hange due to the following reasons:
1. Addition/deletion of firms and clients, and changes in client trading pa
tterns
2. New features, functions, and capabilities were continuously being added
to the system
3. External requirements (especially those affecting market data bandwidths
and format) required the system to be enhanced and/or reconfigured as required.
In general, these requirements took precedence over other move plans. Items 1 a
nd 3 were largely beyond PM’s control and had to be accommodated as necessary.
Likewise the rollout of new features and functions was mostly not delayed to acc
ommodate move plans; rather move plans had to be adjusted to accommodate various
business requirements.
The only way to mitigate risk associated with delay was to plan for continuation
of existing WS operations as they were, until completion of migration was defin
itely in sight. No contracts or leases were terminated prior to the end of the
move.
Technological uncertainty:
There was also a risk of damage to the equipment during the physical move. Once
the servers were removed from WS data center they were shipped by currier to UT
. They were bubble wrapped to protect against bumps. However this was not fool
proof as a bad road accident could possibly destroy the servers and/or data on
them during the transit. To mitigate that risk all moves were done on Friday ev
enings. If the servers were destroyed during the move SAs would have had all we
ekend to build spare servers in UT and restore data to them from daily backups.”
4.7 Wheelwright and Clark (W&C)
4.7.1 Product Change
Relative to your company classify the product change required on this project as
:
• Derivatives or Enhancements to Existing Product
• Addition to Product Family
• Next Generation Product
• New Core Product
Justify and include Stakeholder quotes to support your Product Change classifica
tion.
As I found out when I interviewed the LSA, VBG was already involved in e
quities trading and it used the trading systems of outside vendors and partners.
Hence PT was going to become either a replacement or a complimentary trading p
latform for several departments within the Equities division. This places NASTI
project into an addition to product family category.
4.7.2 Process Change
Relative to your company classify the process change required on this project as
• Incremental Process Change
• Single Department Process Change
• Next Generation Process
• New Core Process
Justify and include Stakeholder quotes to support your Process Change classifica
tion.
As previously mentioned VBG was experienced with migration and integrati
on projects such as NASTI. While every project of this nature has its own speci
fics and intricacies the overall processes of the move and integration are very
similar. Therefore this project involved incremental process change.
4.7.3 Project Type
Highlight your classifications for 4.6.1 Product Change and 4.6.2 Process Change
on the Wheelwright and Clark framework, on the following page.
Which Project Type do they map into?
• Derivative (incremental change in an existing product/service)
• Platform (new generation of an existing product/service)
• Breakthrough (new to the company product/service)
Justify and include Stakeholder quotes to support your Project Type mapping.
NASTI product and process changes make it a derivative project. The product (PT
) was to become a cost-reduced version of the systems that were already in use i
n VBG. Some new features and functions unique to PT were going to get introduce
d to VBG and branding was going to change from NAS PT and their logos to VBG PT
and their logos. Other systems were going to follow existing VBG standards.
The process also involved incremental changes. Most of the work was done by exi
sting employees of both firms and only a couple of consultants had to be hired f
or this project.
4.7.4 White Space Project
If the Project Type fell into one of the White Space Project Types on the Wheelw
right and Clark framework, which Project Type would you suggest that the project
be moved to? Which dimension, Product Change or Process Change would need to b
e modified? What affect would that have had on the project, customers, developm
ent, scope, etc.
This project fits neatly a definition of derivative type and is not a white spac
e project.

4.7.5 Identification of W&C Risks

Did this discussion of W&C elicit discussion of potential risk identified by the
project participants? Was that risk identified at the time of the project? If n
ot, why not? What was done to mitigate these risks?
Justify and include Stakeholder quotes to support your W&C Risk discussion.
There were a few features and functions available in existing VBG trading system
s that were not available in PT. There was a risk that a lack of these function
s would make PT unacceptable to the user base. Business studies were conducted
to mitigate this risk by identifying features that were missing or could use imp
rovement and adding them to the future PT releases.
From the phone interview with PROJ.CRD:
PT was a dynamic, growing product and making changes to it was standard practice
. “We performed business analyses on our existing systems and compared current
functions and future requirements with PT capabilities. One of the problem area
s we identified was that VBG, a Canadian financial company did trading on the Ca
nadian exchanges and the PT did not have hat capability.” This became a priorit
y feature request for PT and was implemented in one of the major update releases
several months later.
Some process improvements involved risk as well. New technology from VMware was
 used to consolidate and migrate some servers. While this technology was mature
in the marketplace, it was relatively new to both technology teams and carried
higher than usual risks. These risks were mitigated by creating a new VMware sp
ecific backup process and leaving migrated servers at WS data center on standby
longer in case of any problems.
From the interview with SA:
“VMware ESX allowed us to migrate infrastructure servers quickly without rebuil
ding them from scratch. However it did have a couple of glitches and we lost a
print server one evening during a basic patch-and-reboot cycle. It was a good t
hing we had the old print server still racked and ready at WS. We powered it on
immediately and suffered no loss of service.”
4.7.6 Wheelwright and Clark Framework Project Type Map

Wheelwright and Clark

Framework
More
Product Change
Low
New Core
Product Next Generation
Product Addition To
Product Family Derivatives and
Enhancements
.
|
More New Core
Process Breakthrough
Project
New Core
Product
New Core
Process White Space
Project
Next Generation
Product
New Core
Process White Space
Project
Addition To
Product Family
New Core
Process White Space
Project
Derivatives and
Enhancements
New Core
Process

Process
Change Next
Generation
Process White Space
Project
New Core
Product
Next Generation
Process Platform
Project
Next Generation
Product
Next Generation
Process Platform
Project
Addition To
Product Family Next Generation
Process Platform
Project
Derivatives and
Enhancements
Next Generation
Process
Single
Department
Upgrade White Space
Project
New Core
Product
Single
Department
Upgrade Platform
Project
Next Generation
Product
Single
Department
Upgrade Derivative
Project
Addition To
Product Family Single
Department
Upgrade Derivative
Project
Derivatives and
Enhancements
Single
Department
Upgrade

Less
|
V Incremental
Change White Space
Project
New Core
Product
Incremental
Change Platform
Project
Next Generation
Product
Incremental
Change Derivative
Project
Addition To
Product Family Incremental
Change Derivative
Project
Derivatives and
Enhancements
Incremental
Change
5. Project Success Measures and Business Perspective
5.1 Business Perspective
How was project success assessed? What was the business perspective of the prod
uct? Was there a business plan? Who developed it?
The project success was based more than on triple constraints, it was based on e
fficiency, impact on business and most importantly it was based on building for
the future. Per PM: “The business perspective of the integration project will b
e known in a year or two. Project was recently completed, of course we and our
top management want to see immediate results, but everyone understands that reve
nues, ROI can be measured after a year or two after the project completion. We
were already able to reduce facilities costs and realize market data savings. W
e also created a DR system and as well as completed data centre & PC integration
.” VBG head of North America technology operations, representative of the head
of the Equities division and the PT architect have developed the business plan.
5.2 Overall Success
What was the overall perception of different stakeholders about the project’s su
ccess? Did they view the project as an unqualified success, unqualified failure,
or as a mixture of success and failure? Justify their perceptions with quotes.
From the interviews that I’ve conducted with LSA, PM, PROJ.CRD and SA it is evid
ent that the stakeholders were pleased with the project results.
LSA:”I believe that the project was a success. NASTI did pay off in the short-t
erm and I am sure it will pay off in the long term. The new trading application
that VBG acquired from NAS has great potential and will meet long-term goals su
ch as revenue, ROI, etc.”
PM:”Project success should not only be measured by savings or profits it generat
ed, but also by the talent that VBG has acquired. Project architect and his tea
m provided great support during the migration and met Project Sponsor’s every de
mand, even if it was a last minute change.”
PROJ.CRD:”I believe that project was successful based on the speech from a Proje
ct Sponsor and the generous bonus the team has received every year during the pr
oject and after the project completion.”
SA:”This project has met all the goals. Not all the goals were completed within
the scheduled timeline or on budget, but that was not the priority. Building f
or the future was the priority. Merging NAS into VBG and positioning the combin
ed company for future success was essential.”
5.3 Explicit or Implicit Objectives
Were the Success Dimension objectives explicitly or implicitly determined up-fro
nt (i.e., were the expectations set in advance)? Was there a discrepancy about t
he Success Dimensions between the interviewees? What were they? Describe problem
s this caused during project execution.
Success Dimensions were determined up-front. The main goals were to prepare for
the future and minimize the impact on the business. From the quotes in Section
5.2 it seems that everyone was on the same page. Success dimension objectives
were a part of the business plan and were presented to the team members.
5.4 Success Dimension Objectives and Results
Objectives: What were the target objectives for each of the selected Success Dim
ensions?
Results: In retrospect, how did the project do on each of the Success Dimensions
?

Success Dimension Objectives Results

Success Dimension #1 Efficiency
Schedule Goals 12/2007 1/30/2009
Budget Goals $3.7MM ~$4.4MM
Other
Success Dimension #2 Impact on the Customer
Meeting Requirements N/A N/A
Satisfying Customer N/A N/A
Delivering Expected Quality N/A N/A
Other
Success Dimension #3 Impact On The Business
Meeting Business Goals NAS Technology Integration Completed Successfully
Expected Revenue N/A N/A
Profitability/ROI/ROE <33% Not known yet
Other
Success Dimension #4: Preparing For The Future
Building Infrastructure Data Center Build-out for future growth Successful, afte
r delayed completion
Building Core Competencies N/A
Market/Product Extension N/A
Expected Savings Add company value by saving <7MM Not known yet
5.5 Unexpected Results
Describe any unexpected results that were achieved during project execution. Wer
e these results good or bad and what impact did they have on the project? On th
e company?
During the project execution phase it became apparent that a lot of existing inf
rastructure at UT would need to be expanded before it can support the added requ
irements of PT. 50 servers had to be purchased for the phase 1 of the server mi
gration. All hardware needed to be purchased including desktops, network router
s, switches and phones. New fiber and copper wiring needed to be laid to handle
all the extra traffic. Data center expansion was the most challenging part. T
he existing Data Center could not handle 110 new servers that were needed. More
power, cooling and UPS capacity had to be installed. Extra space was required.
Permission from the building was required to start construction work. New ser
ver racks had to be purchased and installed. All of this was expensive and time
consuming and a new and separate project was started to expand the data center.
This caused significant delays to the NASTI project.
6. Project Strategy and Competitive Advantage
6.1 Competitive Advantage
Identify the specific competitive advantage of the product (process, service).
What exactly was the reason why customers preferred this product? Was it one or
more of the following variables: cost, feature/functionality, performance, time
of introduction, availability, response time, or another advantage, or a combin
ation of advantages? Be as specific as possible and explain. Was the desired c
ompetitive advantage achieved? Why or why not?
NASTI was initiated because it would result in many operational efficiencies and
financial benefits. Significant savings were expected in network and market da
ta feed costs, in hardware and software, technologists and other support costs,
as well as removed complexity. As per PROJ.CRD: “The desired competitive advant
age was achieved as the infrastructure was combined and simplified, and costs we
re reduced, although due to some cost overruns not by as much as originally hope
d.”
6.2 Value to the Company
What was the value of the project’s deliverables to the company: revenue, profit
, ROI, ROE, cost savings, productivity gains, other? How did they support or fi
t the company’s strategy? Did they address short and long term value separately
? Was the desired value achieved? Why or why not?
NASTI resulted in cost savings and productivity gains. Cost savings and product
ivity gains were closely aligned with the company’s strategy of having one unifo
rm technology infrastructure that adhered to corporate standards. Integration w
ould bring significant cost savings in the IT budget and uniformity would result
in the productivity gains. Short and long term goals were not separately defin
ed. The desired cost savings value is projected to be achieved within three yea
rs of the project completion. Project was completed in January 2009. Productiv
ity gains were achieved because the standardization on the common technology was
achieved, there are now fewer technicians supporting the combined infrastructur
e than there were in two separate companies before the merger.
6.3 Product Definition Process
How was the product defined? Who and what functions were involved (cross-functi
onal involvement)? What was the contribution of top management? What informati
on was collected? How was market data and customer communication performed? Wa
s there a competitive analysis – comparing competitors’ products and positions?
Were there technology, market and risk assessments? Who did them? How were th
e requirements and specifications defined? Was there a use of maps and trends,
QFD, or other methods to define requirements and specs? Would you recommend usi
ng any of the missing elements? Why?
The product was defined as a merger and conversion of NAS technology infrastruct
ure into the VBG environment, in accordance with VBG standards, while minimizing
user disruptions and achieving maximum cost reductions. The following particip
ated in the definition process: project managers, VBG head of North America tech
nology operations, representative of the head of the Equities division and the P
T architect. Head of the Equities division sponsored and funded the project. H
e appointed a representative to work with the project managers and IT groups. T
he PT architect along with the VBG head of North America technology operations c
reated a project definition that briefly described the reason for undertaking th
e project and the mission of the project, project objectives and deliverables, a
s well as the major stakeholders. Customer communications were handled in meeti
ngs, telephone conference calls, e-mails and through a SharePoint website. The
latter also hosted project documents that were updated with status on weekly bas
is. No competitive analysis was performed as VBG was sure that their operations
were efficient and cost-effective and that the only alternative to NAS migratio
n and conversion was to leave their IT infrastructure as it was, and that wouldn
’t produce the kind of cost saving that were expected from the merger. There we
re some technology risk assessments completed by one of the project managers. T
o manage risk effectively, a risk breakdown structure (RBS) was created and a si
mple list of risk sources was defined in the work breakdown structure (WBS). NA
STI requirements and specifications were defined in meetings and documented in m
eeting minutes, project definition, project plan, WBS, RBS and statement of work
(SOW). Other methods of defining requirements and specifications included the
following documents: migration tasks and schedule, move strategy, IT consolidate
d action items, VBG PT Migration – system access requirements and IT infrastruct
ure plan. All essential tools to gather business and IT requirements were used.
6.4 Strategy Alignment
Was there an alignment with company strategy? Was there an alignment with busin
ess strategy? Was there an alignment with marketing strategy? Was there an ali
gnment with operations strategy? How were and who communicated the strategies f
rom level to level in the organization? Was this alignment achieved implicitly
or explicitly?
Project strategy was a part of the project plan. Corporate, business, and opera
tions strategies were in alignment and were clearly expressed and defined to man
agement and team members. There was no marketing strategy. The strategies were
communicated from top-bottom. VBG head of North America technology operations,
representative of the head of the Equities division and the PT architect have c
ommunicated the project mission and the project strategy to the functional manag
ers through the business plan. Once the lead project manager was selected for t
he project, the project strategy was clearly defined and communicated to all the
stakeholders. The project strategy was not part of a separate formal document;
it was a part of the project plan. PROJ.CRD stated: “I did not want to leave a
ny of the team members in the dark. I believe that everyone in the team needed
to know that the project had to be completed strategically and what steps had to
be undertaken to successfully integrate NAS into VBG.” Project strategy was al
igned explicitly.
6.5 Strategy and Competitive Advantage/Value
Was the Project Manager involved in strategy setting and strategic planning whic
h lead to the project launch? Who did the strategic analysis, and who was invol
ved? Was the customer part of the process? Was the competitive advantage/value
clearly defined? Was it clearly articulated and written down? Was it well com
municated to management and the Project Team? Was the Project Team aware of the
competitive advantage/value, understood it, and accepted it?
The Project managers were directly involved in the strategic planning. VBG head
of North America technology operations, representative of the head of the equit
ies division and the PT architect were involved in strategy setting. Strategic
analysis was done by the three project managers who participated in this project
. Functional managers and the customer (sponsor) – head of the Equities divisio
n were involved in the strategic analysis and were able to do modifications to s
trategic analysis. The competitive advantage was a part of strategy. Project s
trategy specified what the competitive advantage was and how it would be achieve
d. Per PROJ.CRD: “Everyone who was involved in NASTI was given access to the pr
oject’s SharePoint site and encouraged to read the project plan, which included
well-defined project objectives, project mission, and project strategy. Each te
am member, functional manager and project manager knew and understood what needs
to be done to achieve overall success and competitive advantage.”
6.6 Project Vision
Was there a project vision – a statement that expressed an emotional appeal of t
he project and its advantage? What was it? Was such a vision clearly articulat
ed, by whom, when, and how? Did the vision change during the project? When and
why? In retrospect, if there was no stated project vision or you disagree with
the published vision, how would you articulate such a vision (i.e., include you
r Claim Statement here)?
Formal project vision was never articulated.
My vision statement would have read:
Information Technology group is a key partner in achieving VBG’s vision of becom
ing the world’s premier financial institution. As VBG grows its business we wil
l leverage our size and resources to keep IT costs down, operations streamlined
and systems consistent with standards throughout the enterprise.
6.7 Claim Statement – Using Crossing the Chasm Style
For VBG Equities management
Who are dissatisfied with high IT costs and weary of needlessly dealing
with multiple complex systems
We offer a single standard environment
That removes overlaps and associated expenses, and offers systems that a
re easy to support, upgrade and keep legally compliant
 Unlike a current non-standard environment at NAS
VBG technology infrastructure is proven, scalable and ready for growth a
nd accommodation of NAS
6.8 Claim Statement – Using Revised Project Strategy Style
For VBG Equities management
Who are dissatisfied with high IT costs and weary of needlessly dealing
with multiple complex systems
We offer a single standard environment in one location
That removes overlaps and associated expenses, and offers systems that a
re easy to support, upgrade and keep legally compliant
Unlike a current non-standard environment at NAS
VBG technology infrastructure is proven, scalable and after a data cente
r expansion will be ready for growth and accommodation of NAS
6.9 Strategic Focus
This is a CRITICAL section of Project Strategy. What was the strategic focus of
the project: Cost Advantage, Customer Focus, Product Advantage, or Time Advanta
ge? Describe in detail the Strategic Focus. Were there Strategic Foci? Describ
e them in detail. If you could choose only one Strategic Focus, what should it
have been? Was the Strategic Focus clearly associated with the competitive advan
tage or the value? How was it articulated, by whom, and when? Were there speci
fic guidelines for behavior and decisions that would support the strategic focus
? What where they? Was there a clear project policy that supports the strategi
c focus? What was it? How was the policy communicated and explained to Project
Team members? Did the Project Manager and Project Team members manage the proj
ect with the strategic focus in mind – explicitly or implicitly? What actions d
id the Project Manager take to guarantee strategic project success? What action
s did others take to guarantee the strategic focus? How would you characterize
the behavior that was needed to properly support the strategic focus? Was this
behavior present?
NASTI’s strategic focus was on cost advantage. Cost advantage was obtained by a
chieving operational efficiencies and realizing significant savings. VBG wanted
to integrate NAS IT functions with its own while incorporating strict corporate
standards and conventions. One uniform platform helped to reduce network and m
arket data feed costs, as well as the number of support personnel. Additionally
all future upgrades: new hardware, software and licenses will cover one expande
d organization and will result in vendor discounts. The project was recently co
mpleted and is expected to pay for itself within three years and yield additiona
l savings of more than $1 MM per year after that. Strategic focus was associate
d with the competitive advantage and was articulated by the project sponsor. Al
l the project guidelines and policies were communicated to the team members by t
heir respective functional managers and the project managers. There was no clea
rly defined document for behavior and decisions that would support strategic foc
us. Project plan described what needs to be achieved at the project completion.
Project managers guided the team members through all the phases of the project
. Team meetings, meeting minutes, status reports, work breakdown structure, sta
tement of work and teleconferencing were used as communication tools by project
team members.
Strategic focus was managed explicitly. All PMs worked well together, they were
good team players, communicators and motivators and had experience with this ty
pe of projects. They kept communications channels open with all team members, s
olicited feedback, provided a lot of help and guidance and kept meticulous docum
entation that was shared with the entire team. Top management and functional ma
nagers had strong commitment to this project and their teams responded and worke
d hard to make this project a success, contributing long hours and on many occas
ions working on weekends doing server moves, workstation migrations, etc… VBG a
nd NAS employees were professionals and quickly learned to work well together.
Of course not everything went smoothly. Per PROJ.CRD: “Once in a while some tea
m members did butt heads or did not complete their tasks on time due to over com
mitment to other projects or other reasons. There were also times when we had t
o negotiate and beg some functional managers for resources. However a look at t
he big picture will show that everyone who worked on this project, managers, emp
loyees and consultants put in a good effort and effectively carried out this pro
ject to successful completion.”
As detailed above, the project management team was very dedicated and used every
tool at their disposal to successfully support the project’s strategic focus.
7. Project Spirit and Leadership
7.1 Organizational Culture
What is the organizational culture within the home organization in which the pro
ject was executed? Is it a strong culture? Does top management emphasize cultu
re? Does it act frequently to strengthen the organizational culture? and how?
NASTI’s organizational structure was based on trust, teamwork and effective comm
unication. Interests of stakeholders and clients took the priority. Top manage
ment has maintained an unautocratic approach. They were available when problems
came up. Project manager and functional managers were able to resolve all the
conflicts when they arose in the team. Everyone on the team has developed stron
g and unified culture. PM, together with functional managers advised the entire
team on their first meeting that the team structure needs to be strong, that ev
eryone has to strive for success of the project, and work together to achieve ex
cellent results. Top management emphasized the importance of cooperative cultur
e. Team members understood that their hard work is appreciated and will be rewa
rded. Team members received year-end bonuses, comp days for weekend work and pr
aise and recognition from top management.
7.2 Project Spirit
Did the project develop a separate culture – a project spirit? What was it? Ho
w did it develop? Was it influenced by product vision? Did the project name pl
ay any role? How was the name chosen, and by whom? What was the attitude in th
e project? What actions did the Project Manager take to create and enhance proj
ect spirit? What actions did the Project Team take to enhance project spirit?
How was top management involved? Were there project-specific newsletters, logos
, slogans, coffee cups, tee shirts, picnics, pizza parties, etc.? What was the
project slogan? Include an image of the logo on the cover.
NASTI project did not develop a separate project spirit. It followed a familiar
pattern for VBG. The project team had a common purpose and things were usually
done in the spirit of cooperation. The project name did not have any significa
nce (NASTI is just an alias for this paper). It was chosen by the lead project
manager, with the goal of accurately describing the purpose of the project – NAS
Technology Integration. There were no project memorabilia, parties or slogans.
Nonetheless the project had a “get it done” atmosphere and was a success. The
Project Manager used his expertise and leadership qualities to lead the project
. The project team used a collaborative approach and relied on technical skills
to make this project a success. Top management showed commitment and support i
n directing NASTI.
7.3 Policy
Was there a specific policy that supported the strategy and spirit? What was it
? Was it clearly articulated, by whom and when? What was the risk taking attit
ude and policy? Did it fit?
There was no specific policy supporting the strategy and spirit. The PM did a g
ood job of articulating the project strategy and the IT professionals at both VB
G and NAS understood the goals of the project, the need for its success, and the
ir tasks and responsibilities to achieve that success. Because NASTI was a stan
dard project for VBG, team members did not have to take risks or do something th
at was not done before.
7.4 Leadership
How was the Project Sponsor selected? How was the Project Manager selected? Wh
o picked them? What was the criterion for selection? How much industry experie
nce did they each have? How much experience did they have with this company? W
hat management levels were they: executive, middle, first-level management or no
n-management. Was this the Project Manager’s first project? How much support d
id the Project Sponsor give? What were the leadership styles of the Project Man
ager and the Project Sponsor? What type of leadership actions did each take?
The Project Sponsor has selected the project because it was VBG’s policy to full
y integrate purchased companies and to leverage economies of scale. Keeping NAS
IT as a separated entity was not a cost efficient option. The Project Manager
was selected by the Project Sponsor. The Project Sponsor used to work with the
Project Manager on previous projects. PM has also worked on integration project
s in the past. Project Manager was well respected by the top management for his
ability to lead projects. In a LinkedIn recommendation his colleague wrote tha
t he “has a knack for getting projects done quickly and without excuses. He s v
ery efficient and a valuable asset to any team.” The criterion for selecting PM
was his previous experience with projects of the same nature, industry experien
ce, his ability to lead, communicate and delegate the tasks and his no-nonsense
approach.
The project sponsor started with VBG right after his college graduation
and has been with the firm for over 25 years. He has handled many roles through
out his tenure. The project sponsor was a Managing Director of the Equities div
ision. The project sponsor has provided guidance throughout the project to the
functional managers and project manager and made sure that functional managers p
rovide sufficient resources for the project.
The PM has been working in the industry for 14 years. He has started as a PM wi
th VBG 8 years ago. PM was promoted to a Senior Project manager after his 3 yea
r tenure with VBG. He was promoted to the Program Manager position after NASTI
completion.
The PM’s charismatic leadership was manifested in his diplomatic behavior, he wa
s able to make all team members feel important, promoted his vision, was determi
ned to achieve his goals and was able to resolve problems effectively with team
members once they arose. The PM was able to lead all the team members and two j
unior PMs and succeed in the project due to his charisma, organizational skills
and diplomacy. The PM took the following leadership actions: he took responsibi
lity for his actions and actions of his team members, he was technical and had a
great tolerance of ambiguity.
The Project Sponsor has provided transactional leadership. He was a senior exec
utive with a busy schedule and he was usually represented by his chief of staff.
The sponsor and his representative were involved in major decisions, like thos
e concerning timelines and budget, but they were not micromanaging and were not
involved in day-to-day project activities. The project sponsor used “active man
agement by exception style - actively monitoring output and enforcing rules to a
void mistakes. ” The leadership actions that the Project Sponsor took were reco
gnizing great work, communicating the needs of the project well, and being bold
and decisive.
7.5 Project Team Empowerment
Describe how the Project Team and the team members were empowered to make decisi
ons and implement them? How did this contribute to team and project spirit?
Input and suggestions from everyone on the team were always welcome. When diffe
rent parts of the project were being planned or implemented the PM team held mee
tings and conference calls with the team(s) responsible for that part of the pro
ject, such as desktop, telecom, network and others. Some of these meetings incl
uded the entire team(s) and everyone was given an opportunity to speak up if the
y had any concerns or suggestions. Other meetings included only the functional
managers involved in a particular migration. As can be expected, these managers
were frequent recipients of their team members’ feedback and they included it i
n the discussions.
“NAS server team had intimate knowledge of the PT system design and their input
was frequently sought during all phases of the server migration and integration.
” – Interview with an LSA
This open atmosphere helped develop team spirit and made everyone feel as though
they are an important contributor to the project’s success.
8. Organization
8.1 Project Organization
How are projects typically organized in the company (functional, matrix, pure pr
oject, or other)? Was this project organized in the typical way? If not, expla
in why, and what is the difference (provide an Organizational Chart in the Appen
dix).
The organizational structure was functional. All projects in VBG follow this st
ructure. Functional managers report to senior managers and they in turn are hel
d accountable for the team members’ performance on the project.
8.2 Project Structure
What was the specific project structure used on this project (functional, matrix
, pure project, or other)? Was this structure unique in the organization? Was
there a Project Management Office? What was the relationship with subcontractor
s? Were there formal contracts with external and internal subcontractors? How
did the project organization function? Was there a core team and a larger team?
How many people were involved in each? What functional organizations were inv
olved? Was the team stable throughout the project or did it change? Describe.
The project structure was functional. This structure was typical in the
VBG. VBG does not have a Project Management Office. NASTI project had only a
few consultants at different stages of the project. System Administrator and PR
OJ.CRD were hired temporarily for the maturing phase of the project. PROJ.CRD w
as hired to assist with project planning and coordination on site, and System Ad
ministrator was hired to write scripts for desktop migration, but was removed du
e to poor quality of his work. Per SA: “we had a good working relationship with
subcontractors. PROJ.CRD did a great job and became a right hand for the PM wh
o frequently worked from the off-site location. The temporary System Administra
tor was unfortunately a bad hiring decision. The automation scripts he was writ
ing didn’t work consistently and due to that the desktop migration process wound
up being manual.” All the contracts with subcontractors were formal.
The Project organization was functional and all the team members reported to the
ir respective line managers. Three project managers, information security team,
server team, business continuity planning team, PT developers, and data center
team comprised the core team. Storage area network team, business requirements
team, and desktop team made up the extended team. Per SA: “There were about 75-
100 people involved in this project at different times. I would say 35-40 peopl
e were on the core team and the rest were on the extended team.” The functional
teams involved in the project were the following: information security, helpdesk
, storage area network, network, sever, telecommunications, desktop, service qua
lity management, PT development, data center, business requirements, business co
ntinuity planning and project management. The team was mostly stable throughout
the project. NASTI project was running for four years and several team members
left the company and were replaced by existing or new employees. It was functi
onal managers’ responsibility to allocate resources and arrange replacements for
the NASTI project. Some team members were replaced because they were pulled in
to other projects. Some VBG or NAS employees joined NASTI in the middle or even
end of the project – as their expertise was needed or when they finished other
projects they have worked on. It was desirable to replace an existing team memb
er with an experienced employee due to the sizable learning curve.
8.3 Team Selection
How was the team assembled and team members picked? Who picked them? What was
the criterion for selection? Was there external hiring for the project? How lo
ng did it take to get the team up-to-speed? Was there a team building process?
Was it formal or informal?
The functional managers have selected the team. The PM also had some input in s
electing the team due to his experience with integration projects and the respec
t he had of the sponsor and of the functional managers. The criterion for selec
tion was team members’ subject-matter expertise. External hiring was minimal an
d included only a temporary system administrator and a project coordinator. It
took the team about 2-3 months to get up-to-speed. Most team members worked sim
ultaneously on NASTI and other projects. Some worked together before, and many
on VBG team had prior integration project experience. The informal team buildin
g process such as empowerment, cooperation, communication and trust were engrain
ed in this project. This worked, as the team strived for success and completed
the project well. Per SA: “Project sponsor set this project up for success by p
romising everyone on the team that they will be rewarded when project is complet
ed successfully. Frequent team meetings, recognition and encouragement worked w
ell and contributed to project success.”
8.4 Work Assignments
How were tasks and responsibilities allocated? and by whom? Were people involv
ed in setting their own assignments? Did they accept their assignments?
Per SA: “The tasks and responsibilities were allocated by the functional manager
s, as well as PM and team members. During team meetings everyone reported their
status, what milestones were reached, what remained to be done and how long eac
h task would take to complete. Team members were encouraged to volunteer and ta
ke ownership of tasks. Most did, others were assigned their tasks and accepted
them.”
8.5 Top Management Involvement
How was top management involved in the project? Was there a Project Sponsor fro
m top management? Was there a formal management committee that approved the pro
ject launch and major milestones? Was top management involved on a constant bas
is or only at major events such as phases or gates?
Top management had minimal involvement in the project. They approved the projec
t launch, resources, budget, time line and major milestones. The Project Sponso
r was a senior executive with a busy schedule and he was usually represented by
his chief of staff. There was no formal management committee that approved the
project launch and major milestones.
8.6 Professional Advice and Reviews
Was there an individual or a team of experts who escorted the project and provid
ed advice throughout? or on an occasional basis? Was it technical, managerial,
or both? What was the cost?
Functional managers and project manager had prior experience leading integration
projects. They frequently offered guidance and encouraged team members to ask
questions. Internal project team expertise was leveraged and there was no added
cost.
8.7 Organizational Problems
Was the Project Manager changed? Why? Was the sponsor changed? Why? Was top
management aware of organizational problems? Did they work with people to make
the organization more effective? What were the organizational difficulties? Ho
w were they handled? Were organizational changes made during the project? Why
and by whom? Were they clearly communicated? How and by whom? Did the project
 suffer from turnover? Why and how much? Was there any organizational churn?
What was done to stop it?
The same project manager and sponsor were in charge for the entirety of the proj
ect. There were no major organizational issues that had to get escalated to the
top management. The top management was not involved in making the project orga
nization more effective. They only provided support if more resources were need
ed or when budget had to be revised. Some of the organizational difficulties in
cluded: some team members were not getting along and some team members had to be
replaced because they could not commit to the workload due to involvement on ot
her projects. Replacements were needed when team members left the firm and more
resources were needed at certain stages of the project. Most of the difficulti
es and organizational changes were handled by the functional managers, the PM or
both. Organizational churn was minimal, mirroring the entire IT organization o
f VBG. Competitive pay, collegial atmosphere and effective communications were
major factors in this. PM and functional managers were encouraging and understa
nding and were able to resolve members’ issues without escalating them to the to
p management. Replacements or schedule changes were clearly officiated during m
eetings and by e-mail, changes were also made in WBS.
8.8 Training
What kind of training was given to the Project Manager and Project Team? When w
as it given? Who did the training? Was the training given by internal or exte
rnal personnel? In what areas, and how long did it last? What was the cost? D
id it help the project?
No formal training given to the PM or project team specifically for this project
. New employees joining the project were familiarized with it by their peers an
d were encouraged to ask their line managers or PM for help. The training was i
nformal and bore no measurable cost. Per SA: “I started with VBG half a year af
ter the project started. I was encouraged and motivated by my peers, management
and PM. Employees who demonstrated strong commitment and quality work were rec
ognized, rewarded and promoted.”
9. Processes
9.1 Project Phases
What were the major project phases (such as, concept, design, development, imple
mentation, production, etc.), milestones, reviews, and decision points? Was thi
s process typical to the organization or unique to the project? If the process
was unique, why? Were phases determined in advance or did they emerge? Did pha
se definition change during the project? Was there a clear definition of the de
cisions needed at each phase? Were stage gates (review gate) used? What docume
ntation was needed? Who was involved in the decision making? How were these ch
anges handled?
Per PM: “Planning, requirements and execution processes are the most important p
rocesses on any project. Processes for NASTI project were not different.” NAST
I integration project was typical for VBG organization. Per PM: “Getting the ri
ght specifications and requirements from the major stakeholders and project spon
sor, right from the project inception is very important for successful planning.
Careful planning, execution and making sure that every team member understands
what is needed were the recipe for success for NASTI. Key project activities w
ere planned in advance and were clearly documented for everyone to see. They in
cluded: telecom build-out, desktop integration, server migration, Data Center co
nsolidation, DR build-out and set up.” Stage gates were not used, project statu
s reports were used and updated weekly. Top management was only involved in cri
tical decision making; all other decisions were made by the functional managers,
PT architect and PM. Changes were handled through the standard change manageme
nt process. Decisions were made by the functional managers, PM and PT architect
with input from the other team members when appropriate.
9.2 PMBOK Processes
How did the project handle the traditional processes of planning, monitoring, bu
dgeting?
Per PM: “NASTI used non-traditional project management processes because documen
ting each and every step would be time consuming and expensive. However, projec
t did go through the five PMBOK processes: initiating, planning, executing, moni
toring and closing. Budgeting process was included in all five stages.” Initia
ting process included clear and brief documentation of project objectives, proje
ct deliverables and approximate budget was set. Project Charter and scope state
ment were developed. During the planning process, business plan, project schedu
le and activity duration were identified, statement of work, WBS and RBS were de
veloped, cost estimation and cost baseline, key milestones and project deliverab
les became more defined and developed; project team was recruited. Execution p
rocess involved producing deliverables, QA testing, change requests and implemen
tation of corrective actions, resource leveling, performance assessment, and bud
get assessment. Monitoring process involved checking how well the project is pe
rforming against the project plan. During this phase all the approved and rejec
ted requests were documented, all the deliverables were assessed and documented.
Change management meetings were in full swing. Cost/budget control, quality c
ontrol and all the risks were monitored, new ones were defined and evaluated. S
cope verification and scope control were also done during this phase. Closing p
rocess involved finalizing all the administrative closure procedures, project in
tegration was assessed.
9.3 Work Breakdown Structure (WBS)
Was there a formal WBS? If not, why not and how was the project work effort mana
ged? How was it done? Who was involved? How many activities and levels were in
the WBS? Was the WBS used as a base for scheduling, budgeting, and planning?
Was the WBS changed during the project? By whom and why?
Formal WBS was designed by the PM to manage the work. WBS was edited frequently
with project updates and changes. WBS was saved to a server and only PM, PM2 a
nd PROJ.CRD were authorized to make changes to it. Per PM: “There were hundreds
if not a thousand of activities and twice as many levels in the WBS.” WBS was us
ed for planning, executing and monitoring.
9.4 Resources Estimations
How did the project determine time and budget estimates for each task? Was it a
top-down or bottom-up process, or both? How were disputes resolved (e.g., betw
een the Project Manager and Functional Managers)? How was the Critical Path tre
ated? Did the project use the Critical Chain instead? How and by whom? Did th
e Project Manager reserve contingency time and budget (project buffers)? How la
rge were the buffers? Were they helpful? Did senior management accept the use
of buffers?
Time and budget estimates were determined by the functional managers and the PM.
For the PM, functional managers and many team members, NASTI was not their fir
st integration project, which tremendously helped them in setting the time line
and budget. Budget approval process went through the project sponsor. Time est
imates were set by the PM with approval of the project sponsor. Per SA: “Time w
as not a major constraint. Many team members were involved in other projects th
at took priority. NAS had a lease for WS office from which they could not get o
ut of and had a hard time finding anyone to sublease the floors to. Due to some
technical issues and reasons above, the project was completed two years later t
han originally planned, but it was still considered a success.” Per PM: “The cr
itical path was a part of WBS and summarized the various interrelated action ite
ms and owners in order to highlight the urgency of tasks and to assist implement
ers in scheduling their work load. A separate issues list has been created and
was used in conjunction with this document.” Contingency buffer for time and bud
get were used. PM was hoping to complete this project within 1.3 years and proj
ect buffer was set to 2 years, project was completed almost 2 years later than i
t was originally planned. Budget buffer was about 500,000, but it went over by
1.3MM partially due to project running 2 years later than originally planned. P
roject buffers were not helpful in this case, but senior management approved the
m.
9.5 Systems Engineering
Were the techniques of systems engineering (techniques for design and build of l
arge-scale multidisciplinary systems as used often by defense contractors) used?
Per SA: “This was a highly technical project and several systems engineering dis
ciplines were involved: network engineering, windows system engineering, and tel
ephony engineering.”
9.6 Reducing Market Uncertainty
Was the Voice of the Customer (VOC) heard? Were focus groups used? Were custom
er surveys used? How important was the customer to defining the project deliver
ables?
Was there continuous customer and user involvement? How did the project use cus
tomer and user input? Was the customer involved in decision making? How did th
e customer influence the project? Were customers considered part of the Project
Team? Did they attend project meetings?
The project was not focused on obtaining direct user feedback. PT clients were
represented by the PT architect. Internal users were represented by the help de
sk and system administrators, as well as other managers or team members in their
respective discipline. One of the goals of the NASTI project was to minimize e
ffect on clients during the migration and integration process. The project spon
sor was the main customer. Focus group and customer surveys were not used. Pro
ject sponsor was involved in determining project deliverables. Project sponsor’
s involvement was minimal; he was only involved in setting the budget and attend
ed major meetings, such as key milestones completions.
9.7 Reducing Requirements Uncertainty
How many requirement cycles were there? When were requirements frozen? Was thi
s part of the plan? What information was collected? How many times were Requir
ements changed before the freeze? Who was involved?
The requirements cycle was somewhat long. There were two requirements cycles.
Requirements were frozen 6-8 months after project was started. Requirements wer
e a part of the business plan and WBS. Time line, budget, resources, equipment,
all the processes, testing, project scope, assumptions and deliverables were a
part of the requirements process. Per PM: “Requirements were changed a few time
s.” The functional managers, PM and the project sponsor along with a few team l
eads we involved in reducing requirements uncertainty.
9.8 Risk Management
How was risk handled? Was there a formal process for risk management? Was ther
e a risk analysis phase? Who defined the risks? Did they use probabilistic ass
essments of risks? What risk mitigation actions were taken? Were they added to
the project plan? Were trouble-shooting mechanisms included? If yes, in which
areas?
Risk was identified through formal RBS and risk management plan. There was a ri
sk analysis phase. Risk analysis was a part of the risk management plan. The r
isks were defined by all the team members, functional managers and PMs. Probabi
listic assessments were a part of RBS. Per SA: “Some risk mitigation actions in
cluded extensive testing, time buffers for complex tasks, dividing complex tasks
into small subtasks, recognizing problems as soon as they occurred so that reme
diation can be done immediately. Risk mitigation actions were a part of risk ma
nagement plan. The troubleshooting mechanisms were included in every area, if n
eed arose.”
9.9 Reducing Technical Uncertainty
How many Design-Build-Test (DBT) cycles were used? Were these in the initial pr
oject plan? How was design conducted? Were design-to-cost, design-to-manufactu
rability, design-to-serviceability, etc. employed? How many design reviews were
there? When were design reviews conducted? How were they conducted? Who part
icipated? Who approved designs? What documents were used for design reviews? W
hen was the design frozen? Who made the decision to freeze the design? When and
how?
This project did not involve creating a new product. VBG had existing systems d
esigns that NAS had to migrate to.
9.10 System Integration and Test
How was system integration performed? By whom? Was there an integration plan?
Was there enough time in the project plan for integration? How was testing con
ducted? Was there a test plan? Was there enough time in the project plan for t
esting?
System integration was performed by both sides (VBG and former NAS) of all teams
: desktop, server, networking, helpdesk and telecom. All NAS teams were integra
ted into organizational structure of VBG. Testing was conducted in the lab envi
ronment. After successful migrations were piloted on a small number of systems
or users migrations were expanded to larger and larger groups until the migratio
n process has reached full speed.
9.11 Project Monitoring and Controlling
How was monitoring and control conducted? How was project progress, budget spen
ding, cash flow, specification control, risk, etc. monitored and communicated?
How did the project identify problems? How were control decisions made?
Monitoring and control were conducted to measure performance and reconci
le it against the project plan. The project progress was communicated through m
eetings, WBS and e-mail. Problems were usually identified and worked on immedia
tely by the subject matter experts as soon as they were given ownership of the i
ssue. Control decisions were made collaboratively.
9.12 Communication Management
How was communications managed? How and what means were used to communicate wit
h customers, team members, other functions, top management, subcontractors, etc.
? Was the communication open, guarded (limited), or closed? What were the comm
unication techniques – meetings, reports, memos, e-mail, web, phone, etc.? What
specific actions were taken to enhance communications? Were there informal com
munication channels? Were there communication problems? How were they addresse
d?
Per SA: “I believe that communications of this project were managed well. PM wh
o was based out of Canada has communicated by teleconferencing, phone, e-mail an
d in person when he visited New York. PM2 and PROJ.CRD had done a great adminis
trative job. They’ve been updating WBS and other documents, always had hard cop
ies for meeting participants and shared updates through SharePoint site and e-ma
il. There were informal communications channels between team members, functiona
l managers and PMs. They included everything from dropping by someone’s desk to
phone calls, e-mails and one-on-one meetings. Communications were enhanced by
either availability or quick response of most project participants. There were
some communication issues between some functional managers and their subordinate
s, but they were addressed effectively and were not a disruption to the NASTI pr
oject.”
9.13 Customer Readiness
Did the project take action to make the customer ready for using the project’s r
esults/deliverables? Did the project prepare proper documentation, simulations,
 training and other materials? How were training and documentation tested?
Customer readiness was not a part of this project.
9.14 Vendor Management
Who selected the vendors? How were they selected? Was this the first time a sp
ecific vendor was used? What was the previous history with the company? What w
as the quality of the vendor’s products/work? How and who interacted with vendo
rs? Were they involved in the project’s initial planning, decisions, etc.? Wha
t impact did the vendors have on the project? Were vendors considered part of t
he Project Team?
No vendors were involved in this project.
10. Tools
10.1 Common Project Management Applications
Did the project use common project management tools for scheduling, budgeting, e
tc.? What were they? How often and for what were they used? Who picked the to
ols? Were they common tools used in the organization? or were they specificall
y picked for the project?
The project used Microsoft Project for scheduling and Excel for budgeting. MS O
ffice and MS SharePoint applications were used for meeting notes, document shari
ng and maintenance of tasks lists. These generic tools were used on daily basis
. These tools are generally used by everyone in the firm who works on projects,
and they were used for the NASTI as well. The tools were picked by the functio
nal managers and PMs because they are used for planning throughout the firm.
10.2 Specifically Developed Tools For The Project
Did the project use specific tools that were developed for this project? What w
ere they? Who developed them?
A system administrator was contracted to write scripts to automate and speed up
desktop migration. These scripts proved unreliable and only a small subset of t
hem was used.
10.3 Documents
List the documents (reporting, monitoring, progress assessment, etc.) that were
used in this project – types, description, extent of use, and usability. Did th
e bureaucratic level employed fit the project type and problems encountered?
Consolidated action items were presented to team members at meetings and conveye
d what is on the agenda for the next couple of days/weeks/month. These were rec
orded in WBS and included task names and numbers, owners of tasks and when they
are due. Items in red indicated critical path. Consolidated action items were
used for monitoring.
Status reports were used for progress and assessment. NAS move strategy, migrat
ion tasks, migration agenda, infrastructure plan, server migration, desktop migr
ation, WBS, overall VBG IT infrastructure integration, IT integration and requir
ements agenda were used for planning.
IT infrastructure issues list, meeting minutes, project initiatives list, chan
ge calendar, issues log, reporting list, program plan, project master, WBS were
used for progress assessment, monitoring and controlling.
RBS was used for risk identification, progress, monitoring and controlling. The
routine level employed fit the project type.
11. Adaptation to Specific Project Type
In retrospect, did the project management style fit the Shenhar project type? H
ow was this project managed differently from other projects in the organization?
Were there problems with wrong “fit”? Speak to Shenhar’s UCP Management Style
guidelines. Please describe in detail.
The Shenhar project type fit medium-tech project. Per SA: “the project had a ve
ry small risk exposure and use of the new technology was minimal.” This was a g
eneric project for the VBG because company had integrated acquisitions successfu
lly in the past.
Shenhar’s UCP Management Style guidelines are proportional with the project type
. The uncertainty is medium-tech, complexity is array, and pace is regular. Co
mplexity is the array because project involved integrating multiple systems such
as telephony, networking, desktop migration, server migration, etc. Each of th
ese systems had subcomponents: software, hardware, licensing, facilities, etc…
The pace was regular because some other projects took priority and consequently
resources were sometimes scarce.
To help you make the above analysis use the following table. Using the “Format”
drop down, and “Borders and Shading”, shade one box in each of the rows that “BE
ST” describes your case study project. Highlight the Technical Uncertainty of yo
ur case study project too.
Adaptation to Fit Low
Tech Medium
Tech High
Tech Super
High Tech
Managerial
Approach
Firm Moderately
Firm Moderately
Flexible Flexible
Project Manager
Skills
Good
Admin Some
Technical Good
Technical Exceptional
Tech Leader
Strategy Build to
Print Build to
Spec Build to
State-of-
the-Art Build to
Advanced
Need
Attitude
Stick to
Plan Some
Changes Many
Changes Look for
Trouble
Communication
Pattern
Formal
Periodic Some
Informal Extensively
Informal Enormously
Informal
12. Learning
12.1 Pre-Project Learning
Did the project benefit from past lessons on previous projects? Were these less
ons available to the organization and shared with team members?
The project had a great advantage because projects of similar nature were conduc
ted before. PM and some project members had previous experience with the integr
ation projects. Per PM: “Projects, such as NASTI are not complex, they are pret
ty straightforward and at this point can be done with our eyes closed, therefore
we do not keep lessons learned. We have a few documents such as status reports
and consolidated action items from previous projects and other planning documen
ts that we could have referenced, but there was no need for expanded lessons lea
rned documentation in my opinion. Existing documents were available for the tea
m members, but it’s not known if anyone used them for reference.”
12.2 On-Going Learning
How was the on-going learning in this project? Did the Project Team conduct pro
ject learning during project execution? Were lessons-learned and mistakes made
accumulated and archived throughout the project? How was it done? Who did it?
Was it documented? How were these lessons learned shared during the project?
Per SA: “I started working with NAS, when the NASTI project was running
for a year. My line manager made sure that I am familiarized with the project.
I was given access to all the SharePoint documents and was encouraged to ask qu
estions. I was up to speed within days because project used standard processes
and the tasks at hand involved common technology requirements. The project team
did not record lessons learned, but the major issues were documented by the PRO
J.CRD. That document was posted on the SharePoint website.”
12.3 Post Project Learning and Lessons Learned
Did the team do a post project learning assessment and/or lessons learned sessio
n? Were these summarized in writing? How were they shared with the rest of the
organization?
Per PM: “The lessons learned session was not recorded. Only major issues docume
nt was logged.”
13. Success Factors
Use Pinto and Slevin’s ten Success Factors from the Meredith and Mantel textbook
.
What are the specific success factors that are relevant for this project?
Was management aware of them? How did the project do on each of them?
What were the major reasons of success or failure of the project?
Success factors relevant to this project include project mission, top-Management
, Project Schedule/Plan, Personnel, Technical Tasks, Monitoring and Feedback, Co
mmunication and Troubleshooting. Per SA: “Top Management provided their support
when needed, but mostly used a hands-off approach throughout the duration of th
e project.” Project did fairly well in the aforementioned success factors. The
main reason of success was that many VBG employees were very familiar with integ
ration projects from their previous experience, the communication, scheduling, m
onitoring and troubleshooting were done extremely well.
13.1 Project Mission
Initial clearly defined goals and general directions.
The mission of the NASTI project is to reduce costs and streamline operations.
NASTI will integrate NAS phones, desktops, servers, networks, data center and PT
environment into the proven and scalable VBG technology infrastructure. Implem
entation will minimize affect on clients and minimize risk to clients and to the
reputation of VBG.
13.2 Top-Management Support
Willingness of top management to provide the necessary re- sources and authority
/power for project success.
The Top-management used hands-off approach, but has shown support, provided the
necessary resources and allowed the project to run its course.
13.3 Project Schedule/Plan
A detailed specification of the individual action steps for project implementati
on.
The NASTI schedule was defined in the WBS and through the milestone list. The a
ctivity sequencing was collaboratively determined and tentative schedule was for
med. All the tasks in the WBS were decomposed into the smallest subtasks. Perc
entage completed was documented in the WBS. Activity sequencing through PDM dia
gram was helpful in determining sequence. Resource diagram showed technicians’
availability. Critical path was identified and documented through the WBS. Req
uested changes were done through change management meetings and corrective actio
ns were introduced. Per PM: “Carefully scheduled implementation process was a m
ajor contributor to project success.”

13.4 Client Consultation

Communication, consultation, and active listening to impacted parties.
Client consultation does not apply to this project.
13.5 Personnel
Recruitment, selection, and training of the necessary personnel for the Project
Team.
Two consultants were brought in from outside. A few employees from the team wer
e replaced because they were needed on other projects. Few techs left the firm
and needed to be replaced. There was no formal training for personnel because t
he project utilized experienced technology professionals and subject matter expe
rts. New employees joining the project were given a brief “project orientation”
to familiarize them with the current status and what needs to be done. Employe
es were encouraged to ask questions to complete the necessary tasks.
13.6 Technical Tasks
Availability of the required technology and expertise to accomplish the specific
technical action steps.
Technical tasks were scheduled in advance, although many times team members had
to stay late or work on weekends on a very short notice. Disturbance to users h
ad to be minimal. Per PM: “No NAS or VBG users should feel that integration pro
ject is in progress. Server shutdowns and all the moves had to be completed aft
er business hours. Users from NAS had to be able to conduct their regular activ
ities on day one after their move to UT.” Per SA:”We had a team of very diligent
technical people who volunteered to stay and work late or work on weekends when
need arose unexpectedly.”
13.7 Client Acceptance
"Selling" the final project to its ultimate intended users.
This was a typical integration project and did not need to “sell” the final proj
ect to its ultimate intended users.
13.8 Monitoring and Feedback
Timely provision of comprehensive control information at each stage in the imple
mentation process.
Monitoring and controlling of the implementation process was done through WBS by
PM, PM2 and PROJ.CRD on regular basis and communicated in status meetings. Fun
ctional managers, leads, team members and PMs were encouraged to provide feedbac
k.
13.9 Communication
The provision of an appropriate network and necessary data to key actors in the
project implementation.
Communication tools throughout the project entirety were e-mails, read-only acce
ss for all the team members to all planning tools (write access for PMs), face-t
o-face and phone meetings as well as teleconferencing. Everyone’s constructive
criticism, ideas and suggestions were welcomed.
13.10 Trouble-Shooting
Ability to handle unexpected crises and deviations from plan.
All parts of operations had clear supporting structure; problems were troublesho
t by their usual support technology personnel.
14. Major Problems and Changes
14.1 Major Problems
Did the project suffer from major problems? Was there a mid-course crisis? Why
did it happen? How were these major problems handled? Who was involved in sol
ving them? Was the project scope, design, or plan changed as a result of the pr
oblem? Include no more than 3 major problems.
The project did not suffer from major problems. Noteworthy problems included un
expected delays caused by the data center expansion project and by other project
s taking higher priority, but these were not considered to be major problems and
they did not require extensive changes to NASTI. These problems impacted the t
ime line and delayed expected cost savings. The PM, the project sponsor and the
head of New York technology operations worked on these problems.
14.2 Changes
Were there changes that were initiated by the customer, management, or new infor
mation? How were these changes handled? How did they impact the project succes
s or completion date? In retrospect, were these changes justified?
NAS occupied two floors in WS and had interconnected data centers on each floor
(previously referred to as a single data center for simplicity). There was a lo
g-term lease signed on the property and the VBG realty group was actively trying
to find a client to sublease one or both floors. In the spring of 2008 they fo
und one such client and entered into serious negotiations for one of the floors.
This meant that that floor and its data center would have to be emptied soon.
Most of the users already moved from this floor into VBG UT office, but the dat
a center was full of PT and infrastructure servers. Server moves recently start
ed into the UT data center, but the current strategy called for server moves bas
ed on functionality and not on physical location at WS data centers, and would h
ave had both data centers migrated at approximately the same time. Project team
needed to make a big change in the server migration process to empty out the da
ta center in question first. The LSA and the manager of the server team worked
with the PT architect to come up with a new strategy, timeline and a solution ba
sed on VMware. When the strategy was decided on and approved, and the time came
to order extra equipment to implement this strategy, the deal for sublease fell
through and the client pulled out. The team reverted to the original migration
plan and did not suffer any delays or incur additional costs.
15. Critical Evaluation
Summarize the main lessons you have learned about project management as practice
d in your organization. What are the implications for the future? How can the
organization benefit (learn) from these lessons? Limit the number of lessons le
arned to no more than 3 and make sure you include only those lessons that have v
alue and are not trivial.
VBG has a strong project management organization. It is leveraged on all projec
ts that involve significant investment of time or money. As mentioned earlier,
a part of VBG’s growth came from acquisitions and it had the benefit of experien
ce with integration projects such as NASTI. This experience covered everything
from standards, documents and procedures to knowledgeable employees, relationshi
ps with contractors and consulting companies.
Despite its comprehensive experience with integration projects, VBG encountered
some problems with NASTI. The biggest problem was the delay caused by the unpla
nned but necessary data center expansion. VBG assumed that because their curren
t needs were being met and that since they were able to easily absorb previous a
cquisitions their infrastructure was ready. That was the case with most of thei
r technology systems, but not so with the data center. It could not handle 110
new servers and supporting equipment. In retrospect VBG should have performed a
more detailed capacity planning analysis of their existing infrastructure to de
termine if it can easily scale up and handle more growth.
The PM and the NASTI team kept mostly good documentation but failed to create le
ssons learned documents. This is a considerable oversight. Lesson learned help
organizations detail their success and failure. Understanding how previous pro
blems were overcome helps accelerate and assure future success in similar situat
ions. Documenting failure helps future projects avoid the same mistakes and pro
vides insight into other solutions that may work. Lessons learned should be a p
art of every project.
Here you need to assess the quality of project management. Describe the stronge
st attributes of management and how did they contribute to project results? The
n discuss the weak points in management and why they happened? Identify differe
nt levels in your evaluation, such as project management, top management, sponso
r, customer, etc.
The quality of project management was very good. The PM and his team had years
of experience in project management and with technology integration projects in
particular. They were good communicators and kept the project team well informe
d, motivated and on track to success. The PM was a charismatic leader, respecte
d by top management and technical community alike. He was also technically savv
y and had high tolerance of ambiguity. These qualities allowed him to understan
d the requirements, tasks and processes, to participate fully in planning and gu
iding this project with technology leaders, and to influence important decisions
and timelines.
While the strengths listed above are impressive, the project management also had
some weaknesses. The biggest one was that the PM lived in Canada and did most
of the work on this project remotely. He was also following the Canadian holida
y schedule which mostly didn’t match US holidays. He traveled to New York frequ
ently and always kept lines of communication open, but in reality his presence o
n site would have added value to the project in certain situations.
Per PROJ.CRD “When a phone migration was being piloted at WS office, the PM requ
ested a floor plan for the department in question. Since he was not on site, he
had a large format layout printout delivered directly from the facilities group
to the telecomm (both in NYC). They took a quick look at it but didn’t confirm
that all the users were indeed seated as shown on the floor plan. When the mig
ration started in the evening the telecomm group quickly found out that the layo
ut they had was outdated. The migration had to be cancelled that night and resc
heduled after all correct seating locations were found and confirmed. The PM wa
s very meticulous and I’m sure that had he been on site he would have confirmed
the seating chart well in advance of the pilot rollout.”
There were also a couple of cases when the project team needed guidance but the
PM away on a holiday. Per SA: “In the summer of ’08 we ran into a connectivity
problem in the data center. The data center team was short-staffed due to the p
roximity of the Independence Day holiday and was busy with other projects. They
couldn’t provide us with proper support on this issue until after the holiday w
eekend. This would cause a delay to our project and we wanted to get help from
the PM to expedite this issue. The problem was identified on July 1st, which ha
ppened to be a Canadian national holiday – Canada Day. The PM was away and coul
dn’t be reached at home or on his cell phone.” The server team sought help from
 their line manager who eventually worked out an arrangement with the manager of
the data center team. Had the PM been available that day, the issue would have
been rectified sooner and with less political heavy-lifting.
16. Recommendations
Based on your critical evaluation of the project, what recommendations would you
suggest to the project management and to the organization at large? Assess if
these recommendations can be implemented by the relevant organization. Tell how
the organization can specifically implement them. Limit your recommendations t
o no more than 3. Prioritize them in order of impact from highest to lowest pos
itive effect on the organization (i.e., which ones should the organization do fi
rst). What is the cost, in dollars, staff, and schedule for implementing your r
ecommendations? These recommendations should be actionable and not just “nice t
o have.”
While NASTI project was a success its analysis yields valuable lessons that VBG
can learn to improve future projects. Firstly – improve capacity planning. The
fact that VBG didn’t anticipate early on that a major addition to the infrastru
cture such as PT and other NAS systems wouldn’t fit into the existing data cente
r is inexcusable and caused significant project delays. Capacity planning and a
ccurate routine measurements are a must. As I learned from the interview with t
he SA this was already implemented as a result of the problem that was encounter
ed during NASTI’s implementation.
Second lesson – create and keep current official lessons learned documentation t
hroughout the life of their projects. Lessons learned should be searchable and
accessible to the entire project management organization and implementation team
s. This documentation will prove invaluable and aid in success of future projec
ts. This will be easy to implement as VBG already does a good job of creating a
nd managing other project documentation. PMs should start creating lessons lear
ned documents and insist that project teams use them and contribute new informat
ion to the database. Existing document management systems such as SharePoint ca
n be used for the Lessons Learned database and would incur minimal, if any cost.
Implementation of this proposal would of course require some time and effort o
n behalf of the PMs and implementation teams, but would be a very worthwhile inv
estment.
Third lesson – having a project manager on site throughout the life of major pro
jects is highly desirable. VBG is a global organization with a strong project m
anagement organization in Canada and smaller PM teams in other locations such as
New York. If a local PM can’t be used for a project, VBG should consider askin
g for a PM from a different location who would be willing to relocate for the du
ration of the project. Having a PM on site will improve efficiency, help preven
t mistakes and eliminate issues such as disparate holiday schedules. Implementi
ng this proposal would incur costs only if it becomes necessary to relocate a PM
from another location. However given that VBG already had significant travel a
nd lodging expenses associated with frequent travel of a Canadian PM to New York
, this proposal may not increase costs significantly or may actually lower them.
17. Case Study Analysis Lessons Learned
As a student, what have you learned from using this case study analysis process?
If you had to do another case study, how would you handle the case study and h
ow would you improve the case study process? What is your assessment of the Rea
l Life Project Case Study Guidelines? What is your assessment of the classifica
tion models? How would you improve the models or change them?
I have learned how to become a better interviewer and communicator. I’ve learne
d to read and apply my knowledge on Shenhar’s UCP Models and project types. I’v
e educated myself on writing a claim statement using “Crossing the Chasm” method
ology and I’ve learned more about success models. I’ve also learned a great de
al about technology integration projects, how to lead them successfully and the
organizational culture where NASTI took place. The most important lesson that I
’ve extracted from this case study is that projects have to be planned strategic
ally to achieve ultimate success. If I had to do another similar case study, I
would have tried to interview more people and I would have tried to get access t
o more data. This case study is great because a student learns a lot about proj
ect management methodologies and can apply the theoretical knowledge to the case
study. I do believe that some of the questions are very similar and it is diff
icult to stay within the page limit. I find