project management

1. 1
MANAGING VIRTUAL TEAMS
School of Management
University of Surrey
Author:
Carlo Vallebona

2. 2
CONTENTS:
PART A:
Virtual Teams 8
Literature Review 9
Managerial Implications 11
Conclusions 11
References 12
PART B:
Introduction and Background 14
Project Requirements and Solution Choice 14
Prime Objectives 15
Risk Identification 16
Structure and Stakeholders 16
Cultural/Human Issues 17
WBS 18
Milestones and Schedule 18
Monitoring and Control 19
Conclusion and Recommendations 19
References 21
Appendix 1 23
Appendix 2 24
PART B Presentation Slides: 25

3. 3
PART A:
Virtual Teams:
“Coming together is a beginning; keeping together
is progress; working together is success.” Henry Ford
Over the past decade we have witnessed dramatic macro-economic changes
in the world. Under the push of forces such as Globalisation, a constant
technological advancement and deregulation, the world has accelerated a
number of transformations leading to major changes in the socio-economical
landscape (Grotton, 1999).
These forces have direct consequences in the way organisations are
redefining and restructuring the workforce and the way teamwork is carried
out. Advances in technology, in particular, have dramatically altered the basis
of workforce organisation (Grotton, 1999). The rate of technological change
that is, the introduction of new technology such as personal computers,
mobile phones, fibre optics, the Internet, massive databases, LANs, artificial
intelligence, virtual reality, satellites, and teleconferencing has created new
opportunities. These opportunities have transformed the integrated
organisation into a network-based style (Scase, 2002). Advances in
communication and information technology have created new opportunities
for organisations to build and manage virtual teams (Kirkman et al., 2005)
Although the majority of the workforce continue to work side by side, it is
increasingly common to work with colleagues based in different departments
or even different parts of the world. Lipnack & Stamps (1999) highlight that
unlike conventional teams, a virtual team works across space, time and
organisational boundaries with links strengthened by webs of communication
technologies.
It is no secret that organ duct development teams or cohesive supply chain
partnerships to compete in their respective markets (Brennan & Braswell,
2005).
The trend towards virtual team working has been further strengthened by the
new employment policies to improve work-life balance.
In the UK, for instance, in April 2003 the British Government introduced new
flexible working rights and according to the Chartered institute of personnel
and development this has had a major impact on working arrangement (CIPD,
2004). Besides the improved work-life balance, Virtual Teams offer a better
sharing of information and knowledge across organisations and freedom to
allocate projects to the best people regardless of their location (Willetts,
2004). Furthermore organisations increasingly face high levels of dynamic,
complex change and environmental uncertainty (Champy & Nohria, 1997).
Because virtual teams can rapidly respond to business globalisation
challenges, their use is expanding exponentially (Kirkman et al., 2005).

4. 4
The main concerns regarding VTs are associated with time and distance.
Team leaders typically find that achieving alignment and commitment to the
team’s purpose are far more challenging for virtual teams, especially those
that cannot meet face-to-face at the outset (Kerber & Buono, 1984). This has
proven to be one of the major causes of misunderstandings across VTs.
Carl A. Singer (1999), a senior program manager at IBM Global Services
described, for instance, how global time zones were used to complete a time
intensive project. They realized that since the most valuable subject matters
experts (SMEs) available were scattered around the globe, they had to use
“time” to their benefit. A virtual team was put together taking advantage of
electronic communication systems to create a virtual 24-hour workday for
quick responses and accelerated reviews (Gray & Larson, 2003).
A virtual team, as in the example above, utilises a number of technologies to
share information and facilitate teamwork. Most of the time, teamwork is
carried out by means of web-based project management software. On the
market there are a number of well-established suppliers of web based project
management software. Main features include:
• Managing Multiple Project Management
• Multiple User Management
• Tasks Management
• Project Statistics and Reports
• Gantt Chart
• Calendar
• Employee Time Sheet Tracking and Approval
• Email Notification
• Discussion Forum
Literature Review:
According to Peterson & Stohr (2005) a Virtual team is a group of individuals
who work across time, space and organisational boundaries with links
strengthened by webs of communication technology. For Krill & Juell “A virtual
project is a collaborative effort towards a specific goal or accomplishment
which is based on collective yet remote performance” (1997).
Lipnack & Stamps (1999) stress the fact that the main differences between
normal teams and virtual team is the means through which they communicate,
hence technology. Peterson and Stohr list 7 Basic Types of Virtual Teams
(2005):
• Networked Teams consist of individuals who collaborate to achieve a
common goal or purpose; membership is frequently diffuse and fluid.
• Parallel Teams work in short term to develop recommendations for an
improvement in a process or system; has a distinct membership.
• Project or Product-Development Teams conduct projects for users
or customers for a defined period of time. Tasks are usually non-routine,
and the results are specific and measurable; team has
decision-making authority.
• Work or Production Teams perform regular and ongoing work usually

5. 5
Project
Worker
Project
Worker
Project
Worker
Project
Worker
Project
Worker
Project
Manager
PROCESSES
INPUT
PROCESS
OUTPUT
PROCESS
in one function; clearly defined membership.
• Service Teams support customers or the internal organisation in
typically a service/technical support role around the clock.
• Management Teams work collaboratively on a daily basis within a
functional division of a corporation.
• Action Teams offer immediate responses activated in emergency
situations.
According to the literature review a proposed typology of virtual team based
on the classic four dimensions: people, purpose, links and time is suggested.
.
In our view the virtual has to be considered as a normal team office-based.
The main difference lies in the means through which information flows.
Although at a first analysis of the different “patterns of communication” may
seem less effective than the traditional ones, we believe the introduction of
new channels or patterns of communication is a key winning feature.
As highlighted by the System Theory and Ashby (1956) An Introduction to
Cybernetics and its law of requisite variety: “The larger the variety of actions
available to a control system, the larger the variety of perturbations it is able to
compensate”.
In other words, according to Ashby (1956) in any cybernetic system the
element in the system with the widest range of behaviours or variability of
choice will control the system. This concept has been successfully applied in
several contexts, for what concerns virtual teams we believe that the
variability and richness offered by different channels and patterns of
communications available to the system-VTs is the very feature that allows
the team to have a wider variety of choices to respond to the very dynamic,
and complex environment in which they operate, hence a wider variety of
ways/choices to achieve a given scope.
As in the example cited at the beginning of this paper, IBM, in order to meet
urgent customer needs, a team of SMEs was quickly identified, recruited, and
assembled (Singer, 1999). IBM put together a dispersed number of experts
into a virtual team.

6. This allowed IBM to maximize its resources in terms of subject matter experts
(SMEs), gathering them from all over the globe; and at the same time this
dispersion was utilized to put together a 24-hour workday taking advantage of
the time differences.
6
Managerial Implications:
Companies through VTs can achieve competitive advantage and great
effectiveness. However with great opportunities, often come great challenges.
Traditional management practices have to be adjusted to the new situation.
Managers need to get the hang of leading across distance and time zones,
and must be aware of technology and multi-cultural sensitivities. In a recent
article, Couzins et al (2005) suggest that in order to cope with the challenges
of managing a dispersed team managers should focus on the following areas:
• Communication skills and patterns: They should master
communications and the new technologies: instant messaging, web-based
project management software, video calling etc. They should
make clear times and methods of communications and make the team
members stick to them (Harvard, 1997; Galpin, 2005). Communication
should freely flow in any direction.
• Trust: The old low-trust management that sees employees as a cost
that has to be supervised and managed must give way to
empowerment and trust, where each core employee embraces the new
psychological contract made of reactivity and entrepreneurial attitude
on the employees side, and more commitment towards the creation of
a compelling workplace where innovation and creativity are fostered on
the management side.
Conclusions:
The biggest challenge for all organisations is identifying, securing and
maintaining competitive advantage. Virtual Teams can give competitive
advantage if properly organised and managed. Globalisation and
Technological advancement are reshaping organisations especially through
de-layering to achieve a more nimble structure such as the Handy’s shamrock
organisation (1988). Companies that want to stay competitive should aim to
unleash this huge potential through the creation and constant re-invention of
VTs where individual’s potential is facilitated and fostered through a high trust
positive management style.

7. 7
References:
Ashby, W. R., (1956): “An Introduction to Cybernetics”, Chapman & Hall,
London)
Brennan, M., Braswell, P. (2005) “Developing and Leading Effective Global
Teams”. Chief Learning Officer, Mar2005, Vol. 4 Issue 3, p44, 4p; (AN
16212671)
Champy, J., & Nohria, N. (1997). Fast forward: The best ideas on managing
business change. Boston: Harvard Business School Press.
CIPD www.cipd.co.uk/subjects/wrkgtime/wrktmewrklfbal/worklifeba.htm
(Accessed 15 April 2005)
Couzins, M. & Beagrie, S., (2005) “How to... successfully manage remote
team”, Personnel Today, 09595848, 3/15/2005, Database: Business Source
Premier
Galpin, M. (2005) Remote teams: How to successfully manage remote teams.
Personnel-Today, -
www.personneltoday.co.uk/Articles/2005/03/15/28639/How+to+successfully+
manage+remote+teams.htm (Accessed 06 April 2005)
Gray, C. F., & Larson E. W. (2003), “Project Management”, 2nd Edition:
McGraw-Hill
Grotton L, et al, (1999) “Strategic Human Resource Management” Oxford
Harvard University, (2005) “Project Management Manual”, Harvard Press
Handy, C (2002) “Leader to Leader” No.24, Spring
Kirkman B. L., et al, (2005), “The impact of team empowerment on VT
performance” Academy of Management Journal, 2004, Vol. 47, No. 2, 175–
192. http://www.cor.web.uci.edu/ufiles/calendar/Gibson_et_al_AMJ.pdf
Accessed 13 April 2005
Krill, Terry & Juell, P (1997) “Virtual Project Management”, Proceedings of the
Small College Computing Symposium (SCCS’97), North Dakota State
University, March (quoted by Mike Rolfes – see reference)
Lipnack, J., & Stamps, J. 1999. Virtual teams: The new way to work. Strategy
& Leadership, 27(1): 14–19.
Peterson, S. & Stohr, V. “Management Assistance Programs for Non-Profits”
available at http://www.mapnp.org/library/grp_skll/virtual/virtual.htm ,
(Accessed 10 April 2005)
Rolfes, M. “Virtual Project Management”,
www.umsl.edu/~sauter/analysis/488_f01_papers/rolfes.htm, (Accessed 09

8. 8
April 2005)
Scase, R. (2002) “Living the corporate zoo” Capstone Publishing Ltd
Singer, C.A. (2001) “Leveraging a worldwide project Team” , PM Network,
http://www-03.ibm.com/ibm/palisades/assets/pdf/singer.pdf (Accessed 12
April 2005)
Weber, K & Buono, A. F. “Leadership Challenges in Global Virtual Teams:
Lessons From the Field”, EBSCO Database (Accessed 20 April 2005)
Willetts, M., (2004) “Is anyone out there? A Guide to Virtual Team Working
and Leadership”, MaST International Group plc.
www.trainingreference.co.uk/skills/team_development/virtual_teams_1.htm,
(Accessed 15 April 2005)
http://l2li.org/leaderbooks/l2l/spring2002/handy.html (Accessed 20 October
2004)

9. 9
PART B:
Introduction and Background:
Orbis Technology is a software development company that services regulated
Gaming companies such as Ladbrokes as well as Media companies such as
BSKYB (www.Orbisuk.com). It was acquired by NDS, a subsidiary of News
Corporation, in December 2000. Orbis currently employs 110 people and has
grown from 25 employees in 3 years. This rapid expansion had implications
for all areas of the business including use of systems. In the early years of the
company project management barely existed and invoices were based purely
on estimation of time spent. Over time the reporting requirements of Orbis’
customers became more demanding, and the co-ordination of timesheets
more complicated.
A timesheet system was developed in-house in August 2000 by resident
developers to record estimates of time spent on particular projects and was
necessary for the purposes of invoicing primarily; it was barely utilised as a
project management tool. The WBS was poorly defined and the web portal
used for entering weekly timesheets could not cope with the demands of
increasing numbers of users and project data. Performance became
unacceptably slow, the system often crashed causing severe frustration to
users. Much of the reporting and existing functionality became irrelevant and
outdated, and as an information source for project management it was
completely inadequate. It was decided in July 2003 that a new timesheet
system would be required by the end of the financial year in June 2004.
Project Requirements and Solution Choice:
Initial requirements were drawn up (Stephens, 6/11/2003) through
consultation with the Financial Director, Operations Director and Business
Administration Manager. A GAP analysis was conducted and key criteria for a
new system were identified as follows:
• High Performance
• Scalability (for up to 500 employees)
• Robustness and Supportability
• User-friendliness (for time entry and data extraction)
• Ease of Administration (for adding projects/employee records)
• Remote Access for travelling employees
• Access from both Windows and Linux platforms
At the same time NDS were also developing a time recording system (TRS)
for implementation on 1st July 2004 across many of its international sites
including France, Denmark, USA, India and 2 sites in the UK.
As a consequence of the GAP analysis and research into several solutions, 3
final options were considered:
a) Further development of the existing system in house – resources were
limited for this

10. b) Obtaining one of the many off-the-shelf products and having it suitably
10
tailored. No ‘out of the box’ product could be identified that did not
require substantial tailoring and therefore cost.
c) Joining the NDS global TRS either as a region or standalone system
which had a number of benefits – the time frame for delivery was
identical; Costs were minimal – only licences were chargeable as NDS
would absorb all of the development costs at £130,000 (Hofstein,
2004). NDS would also perform much of the project management and
liaison with the supplier. The financial and resourcing risks were
therefore transferred to NDS. This option was the logical choice.
NDS had performed much of the initial work in choosing a supplier, Panam
Information Systems, having also produced a very detailed set of
requirements (Jones, 5/3/2004), which initially required some alignment with
Orbis. Many Orbis employees refused to use Microsoft Windows, preferring a
Linux platform, meaning that any system implemented would have to be
functional on both and be accessible through both a Microsoft and non-
Microsoft web browser (Stephens, 6/11/2003). NDS finally agreed to add this
requirement and that the system would be accessible through both IE 6.0 for
windows users (www.microsoft.com) and Netscape 7.0 for Linux users
(channels.netscape.com).
Despite pressure from NDS to join an integrated system and become a
‘region’ in their TRS, Orbis decided to implement a separate standalone
version of the NDS system. Orbis wanted to retain control over the TRS and
its administration so was opposed to accessing a remote system hosted
elsewhere. There were concerns about slow performance as well as potential
cross-contamination of Orbis and NDS projects. Orbis wished to determine its
own WBS and project naming convention rather than fall in line with NDS
protocol.
Prime Objectives:
• To accurately record employees time without being overly time-consuming,
intrusive or complicated. Making the user interface and
WBS as user-friendly as possible, whilst ensuring high performance on
both windows and Linux platforms
• To create a means of clearly differentiating and monitoring customer
work, R&D work and Admin
• To allow Project Managers to better control Projects including
increased efficiency in tracking overruns, budgeting and delivery
• To make the extraction of information for the purposes of invoicing and
reporting simple and convenient
• To streamline projects and implement a uniform WBS
• To ensure greater accuracy and integrity of data
• To decrease administration time for Project Managers and Project
Administrators
• Prevention of data changes after financial month end deadlines to
ensure consistency of information with invoices
(Stephens, 25/7/03)

11. All of the objectives above were achieved as a consequence of implementing
the TRS, and to that end the project was a success. The initial alignment of
core objectives with those of NDS was important in ensuring that the strategic
business aims of the project were achieved for both companies. The scope
(Turner, 2005) was well defined. Poor scope definition for major segments of
a project have the greatest negative impact on cost and schedule (Smith and
Tucker, 1984)
11
Risk Identification:
The obvious risk identified by scenario analysis (Larson and Gray, 2003) was
that the project would not be delivered as specified, on time or to budget. The
launch date of 1st July 2004 was ambitious; timescales were tight and left little
room for error. From sign-off on design in March 2004 to launch was 3
months! This fear was well founded. The actual ‘go-live’ date was 5th January
2005 for NDS and 4th April 2005 for Orbis!
The chances of a project risk occurring are often in the early phases
(Newtown Square, 1994) however it wasn’t until the acceptance-testing phase
that major problems were found. These risks could have been reduced by
increasing acceptance-testing in the schedule (Appendix 2) and setting a
realistic delivery date. The quality of the software was the most important
factor and the rush to meet the deadline contributed to mistakes being made
and the majority of the delay.
The project was sold on Fixed-Price terms and therefore the financial risk was
transferred to the supplier (Gray and Larson, 2003). This was shrewd, and
Panam ultimately suffered as final payment was delayed by 9 months.
The main risk to Orbis was in allowing NDS to primarily project manage their
implementation. The lack of control over project delivery and quality of
software was a valid concern. This is common of working in a virtual team
scenario as 2 of the biggest challenges in managing a virtual project are
developing trust and effective patterns of communication (Adams & Adams,
1997) The possibility of misunderstandings, response delays and lack of
control were extremely plausible, and ultimately true. The physical location of
Panam in Israel made it impossible to monitor ‘actual’ progress of the project
on a daily basis, despite daily telephone or e-mail updates. Fundamentally
this led to the projects late delivery.
Structure and Stakeholders:
The project was achieved through working as a virtual team across 3 different
sites. The major stakeholders in the project were the supplier Panam, NDS
the primary customer and Orbis the secondary customer. There were key
individuals in each organisation who were responsible for the TRS delivery.
NDS:
The Project Manager for NDS wrote the initial requirements (Jones, 5/3/2004)

12. and was responsible for delivery of the entire global project. She had an
integral role in delivering the TRS as well as facilitating communications
between Orbis and Panam. In September 2004 she spent 3 months in Israel
overseeing the project after the launch date on 1st July and then 1st
September were missed. It was clear that a much more hands on approach
was required. Whilst her attention to detail and sense of urgency were ideal
qualities required for project management, ultimately the unrealistic
timescales set and poor relationship management, through assumptions
about Panams capabilities, contributed to the late delivery.
A senior technical assistant was appointed for testing and delivery of the TRS,
and making technical changes to the project.
A team of 10 users from each NDS region piloted the new TRS. Over 1000
users were required to use the new system worldwide, their adaptation to and
acceptance of the new system was key to the projects success.
12
Orbis:
The Business Admin Manager was responsible for project managing and
implementing the TRS at Orbis. Other full-time projects were also running
concurrently and the TRS project was not given full attention and this
contributed to some project slack. After the NDS launch in January 2005 a
full-time Project Administrator was recruited specifically to look after the new
system and to assist in getting the TRS live, training users and maintaining all
the data records.
The Operations Director was responsible for restructuring projects and their
breakdown to create a uniform WBS suitable for the new system.
A team of 15 people piloted the Orbis TRS, consisting of Windows and non-windows
users, 2 project managers, and 2 senior software engineers.
Ultimately all110 users at Orbis were required to adopt the new system.
Panam:
The Project Manager for Panam was responsible for liaison with NDS and
project delivery whilst a senior software architect was responsible for
developing and delivering the functionality. After the launch date had been
moved several times the Project Manager was replaced. NDS were unhappy
with the lack of honest communication and apparent understanding of the
project requirements and deadlines. Often, reported defects were referred
back to NDS as ‘not our fault’, when they were technical faults only repairable
by Panam.
Cultural/Human Issues:
Panam was chosen primarily because of the BuzzWeb (www.Panam.com)
software being the most appropriate for the project despite the Israeli
connections of NDS. Problems of culture were encountered early on due to
working practice differences including a 4-hour time difference, Israel not

13. working on Fridays (www.amcham.co.il). Employees from Panam, NDS and
Orbis were required to work at unconventional times. Some language barriers
were also encountered where miscommunications were common through lack
of face-to-face interaction (Coutu, 1998).
13
WBS:
The WBS allows identification of all the work elements required to deliver the
project, it also establishes a basis for control (Gray & Larson, 2003). Orbis
completely restructured their WBS for the new system as shown below:
(Bridgen, 25/3/2004)
Customer
Dependent on Specific User
Project
PID driven (Piece of work instructed)
Dependent on Customer
Subproject
(Application associated with Project)
e.g Admin Screens, Web Screens, DB
Activity
(Type of work done)
e.g Coding, Delivery, Testing, Support etc.
Work Record
(Time allocated by person/project/activity)
Work progressed rapidly at Orbis on structuring the existing timesheet system
to fit in with the new TRS WBS – including shortening project names, adding
subproject budgeting figures, reducing the number of activities and limiting
access of certain functionality to Project Managers and administrators.
Problems arose when it was discovered that there was no way to
automatically upload existing WBS information into the new system without
manually entering every record. With over 800 active projects containing more
than 5 subprojects each this was a significant set back as resources were not
available at Orbis to input this data manually.
For the purposes of the TRS project WBS was defined as in the Project Plan
(Appendix 2). All areas of the project were broken down and analysed
effectively, thanks to the production of detailed requirements.
Milestones and Schedule:
Orbis agreed to implement the NDS ‘TRS’ after revision of costs and final
sign-off on design by NDS, in March 2004. The expected launch date was
then offset from the NDS launch to allow for any problems to be resolved
before putting Orbis live.

14. The project was scheduled using MS Project and was followed by means of a
Gantt Chart (Appendix 2) which is a favourite tool for communicating project
schedule status due to the ease of its use (Gray & Larson, 2003).
14
A milestone plan was designed and updated fortnightly (Appendix 1). These
were effective ways of monitoring the project as well as clarifying tasks and
scheduling events.
The initial delivery of functionality was 2 weeks late – it was hoped at this
stage that the launch date would not be affected. Many defects were found in
the system during acceptance testing and it rapidly became clear that 1st July
was unachievable. On 28th May a decision was taken to delay the launch until
1st September 2004 (Jones, 1/6/2004). The milestone plan was completely
revised once it was clear that the September launch would not be achievable
either. Acceptance testing was finally completed on 10th December and the
TRS finally launched on 5th January 2005.
The Orbis delivery encountered problems due to late delivery of the Linux
module that had been an essential requirement. Orbis refused to implement
the system without it. This delayed the launch for 3 months and Orbis
eventually launched on 1st April 2005.
Monitoring and Control:
Fortnightly updates were sent via e-mail from NDS to all regions implementing
the system, including Orbis. This communication included an updated
milestone plan, statement of progress achieved during the period, plan for the
next fortnight and major defects identified (Appendix 1). This is fairly typical
(Gray & Larson, 2003).
A Gantt tracking chart was used to measure actual progress against the
original project plan (Appendix 2). A tracking control chart could have been
used to exactly plot the difference between the original schedule and the
actual situation this may have given further control.
Panam gave NDS daily progress updates. Until the trip to Israel in September,
however, there was no physical monitoring of the project by NDS. This made
a major contribution to the late delivery.
Conclusion and Recommendations:
Whilst implementation of the new TRS at Orbis was welcomed, constant
delays to the launch and limitations to functionality meant the project could
have been delivered more successfully. The scope was well defined and
potentially Orbis could have exerted greater influence over NDS initially to get
the desired functionality delivered earlier. Despite common objectives and
requirements Orbis were forced to concede on minor functional points in order
to implement an identical system, this could have been avoided by including
Orbis much earlier in the design phase.

15. 15
Whilst the delay in launch of the TRS did not directly cost Orbis financially,
inefficiency in the existing system cost time and resource to fix, as well as
administrate.
The risk analysis did not reveal a realistic picture in terms of the greatest
possible delay to the project, which for Orbis was 9 months! Setting a realistic
launch date from the outset would have ensured less technical errors were
made in meeting deadlines. Establishing a project priority matrix could have
been a useful exercise in setting expectations.
The virtual structure of the project made delivery and communication more
complicated. This could have been resolved by Panam sending a resource to
work on the project face-to-face (Coutu, 1998). Issues in development would
have been raised earlier and the NDS project manager would have had better
visibility and control of the projects progress. A full time resource could have
been assigned at Orbis from project inception to establish priority and prevent
some of the delay in communications and data entry.
80% of projects have imposed duration dates (Gray & Larson, 2003) as is the
case here, and it is known that this increases the chances of activities being
late. Technical risks were high in this project and earlier testing could have
prevented the subsequent delays (Smith & Reinertsen, 1995)

16. 16
References:
Websites:
http://www.change-management-toolbook.com/home/introduction.html
http://www.panam.co.il/viewPage.aspx?menu=0&PageID=73
http://channels.netscape.com/ns/browsers/sysreq.jsp#
http://www.Microsoft.com
http://www.amcham.co.il/main/siteNew/index.php?page=41#hours
Primary Sources:
Adams, J.R and Adams, L.L (1997) “The Virtual Projects: Managing
Tomorrow’s Team Today”, PM Network, (January) p. 37-41
Bridgen, J. (25/3/2004) “Project Structure and Breakdown”
Coutu, D.L. (1998) “Organization: Trust in Virtual Teams”, Harvard Business
Review, vol. 76, no. 3 (May-June) p. 20-21
Jones, E. (05/03/2004) “Corporate Time Recording Reqs Issue 2 Rev 3-
Phase1”
Jones, E. “Acceptance Test Plan”
Jones, E. (28/2/2004) “Project Plan”
Jones, E. (30/4/2004) “Status Report Period to 30/4/04”
Jones, E. (1/6/2004) “Status Report Period to 30/5/04”
Smith, P.G and Reinertsen, D.G (1995) Developing Products in Half the Time
(New York: Von Nostrand) p 218-9
Smith, M.A. and Tucker, R.L, (1984) “Early Project Problem – Assessment of
Impact and Cause” Proceedings (Newtown Square, PA: Project Management
Institute) p 226
Stephens, J. (25/7/2003) “Timesheet System Objectives”
Stephens, J. (5/9/2003) “Timesheet Portal Time plan”
Stephens, J. (19/11/2003) “Administration Interface Requirements”
Stephens, J. (06/11/2003) “User Interface Requirements”

17. 17
Hofstein, A. (28/3/2004) “Time Recording Panam Quote Orbis Q2”
“Project Management Body of Knowledge” (1994) Newtown Square, PA:
Project Management Institute, p.6
Secondary Sources:
Gray, C.F. and Larson, E.W (2003) “Project Management: The Managerial
Process”, 2nd edition
Project Management Module, University of Surrey Learnware January 2005
Turner, J.R (2005) ”Handbook of Project-based Management: Improving the
Process for Achieving Strategic Objectives”

18. 18
Appendix 1 (Jones, 30/4/2004)
Milestone Plan
Milestone Original
Planned Date
Revised
Completion Date
Remarks
Design Complete 19 Dec 2003 13 February 04 Complete
Implementation/ customisation
29 March 2004 31 March 2004 Complete
complete
NDS acceptance test plans
complete
12 April 2004 23 April 2004 Complete
Panam internal QC complete 12 April 2004 22 April 2004 Complete
System installation at NDS
19 April 2004 30 April 2004 Complete
complete
Panam QA at NDS complete 26 April 2004 2 May 2004 Complete
Train the trainer complete 26 April 2004 11 May 2004
Administrator training complete 14 May 2004 14 May 2004
NDS acceptance tests
complete
10 May 2004 21 May 2004
CBT training complete 24 May 2004 24 May 2004
NDS pilot complete 14 June 2004 25 June 2004
NDS go live – UK, Israel,
1 July 2004 1 July 2004
France, Copenhagen, India, US
(part).
Orbis Go live 1 July 2004 5 July 2004

19. 19
Appendix 2 (Jones, 28/2/2004)

20. 20
PART B Presentation Slides:

21. 21

22. 22

23. 23