1

MANAGING VIRTUAL TEAMS

School of Management

University of Surrey

Author:

Carlo Vallebona

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

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

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

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.

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

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

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

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 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) 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. 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). 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)

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.

Work Record

(Time allocated by person/project/activity)

Activity

(Type of work done)

e.g Coding, Delivery, Testing, Support etc.

Subproject

(Application associated with Project)

e.g Admin Screens, Web Screens, DB

Project

PID driven (Piece of work instructed)

Dependent on Customer

Customer

Dependent on Specific User

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). 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

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

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

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

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 complete

29 March 2004 31 March 2004 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 complete

19 April 2004 30 April 2004 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, France, Copenhagen, India, US (part).

1 July 2004 1 July 2004

Orbis Go live 1 July 2004 5 July 2004

19

Appendix 2 (Jones, 28/2/2004)

20

PART B Presentation Slides:

21

22

23