Project Management Institute

Global IT projects--reapplying what works

Ian Koenig, PMP, Quality IS Projects, Inc.

There are an increasing number of global organizations and alliances that require significant investments in information technology. Information Technology can provide the key to:

• Increased market access

• Global/Euro branding

• Global customer service

• Supply chain savings and responsiveness

• Decisions based on current global data

• E-business.

With the potential for great rewards come new challenges:

• Overcoming distance and communication barriers

• Resource commitment problems

• Dealing with people way outside a project manager's usual scope of influence

• Dealing with language difficulties such as multilingual IT development and support

• Addressing cultural nuances and sensitivities

• IT standardization barriers on global projects with various organizations having ownership

• Financial constraints around moving off regional standards

• Additional risks and stakeholder issues associated with multicountry projects

• Contractual, licensing, tax, and legal issues that come into play with a global project.

The efficient and effective implementation of these global IT projects will always be a major challenge, but there are some key lessons learned that could be reapplied. Before we review these key lessons learned, there are some prerequisites of IT project management that must not be overlooked on these megaprojects.

Additional Methodologies

For mega-IT projects, project management is not enough; you need to apply strategic planning techniques (e.g., force field analysis, SWOT analysis, portfolio selection) at the front end. Strategic Planning as a discipline and function within a company has fallen out of favor; the techniques are now enjoying a rebirth. To understand how to apply these techniques, a general understanding of Corporate Strategy is required (Johnson & Scholes, 1999) before applying within an IT context (Tozer, 1996). Communication between IT provider and business management is needed early to set expectations. The importance of this front-end work cannot be overemphasized; for example, the Iridium global telecommunications project applied good project management practices but still failed.

Global IT projects require that you fully test and freeze the products you are going to deploy, testing and release management now have their own methodologies, tools, and techniques. Testing methodologies have been around for some time and are now incorporated in automated tools. Software release management has more recently become a formalized approach (Bays, 1999), it can greatly assist the scope management process. Also, the use of proven development/deployment methodologies is crucial; if you don't have them, get them. The acid test for a methodology is that it clearly shows “how to” execute the scope of work and there is documented evidence of its successful use. Many of the early SAP R/3 implementations failed for lack of a proven methodology.

Technical Prerequisites

It's the architecture, stupid! You would not build a house without a set of plans. Enterprise technology architecture provides a road map for global IT projects and can prevent various different IT projects from colliding. There is now an IEEE standard for technology architecture planning (Armour, Kaisler, Lui, 1999), and several third party frameworks, so there is no excuse. Overlooking this area causes major rework and often project failure. Although this work may be viewed as additional overhead, it has proved highly beneficial in large-scale web development projects, an area where speed is an imperative. The need for speed also means that you cannot neglect “downstream” groups (e.g., Security, Training, Support) who need to be involved from the start. Don't believe the vendor(s), as in “accept as true,” verify, visit other companies, and seek predictability. Track planned versus actual software release dates, planned versus actual features included in a software release. As third party solutions become the norm, this is even more important. The acid test, the system must be available, not vaporware (Suskind, 1999). And last but not least, only deploy when it works—establish this principle at the start of the project and remember—testing takes time, allow for it.

Organization Prerequisites

Global IT projects must have a strong business case that addresses at least one of the following: Improve Customer Satisfaction, Gain Market Share, Improve Profitability, Develop New/Improved Products, Develop New Markets—it is not enough to just save money (reduce costs). Insist that the business leads the project, at both the sponsor and project manager level. On major IT projects it must be business led, only the business has the span of control to address scope changes and major deployment issues. As more IT project managers become absorbed within the business areas, this will become a less contentious item. The project management principle of single point accountability must be maintained, with no co-sponsors or co-project managers. Full time resources are required, nobody ever completed a global system with 20% allocated resources, as a rule co-locate resources that are in one office. Develop a skills inventory; this is a prerequisite to assigning resources based on skills and experience not availability. The competency of the project team must be addressed, we want to take good techniques and give them to people who can use them. When the organization structure has been determined, a communications plan can be finalized, normally a two-page document that describes the “who, what, when, and how” you will communicate.

Assuming your project meet these prerequisites, there are some key lessons learned from global IT projects that can be reapplied.


The University of Texas maintains an excellent web site for global project management that details the many cultural issues that arise on a global IT projects. It would be easy to conclude that one can never be quite ready to deal with every situation. Based on many actual projects, the answer was immortalized by Aretha Franklin in the song, “R.E.S.P.E.C.T.” You cannot hope to master all the cultural differences on a global project, so focus on respecting the individual in all the different situations that occur. One very simple illustration of this, rotate meeting times for tele/video conferences to suit local site office hours. Do team building exercises as soon as possible in the project; early involvement is the key. Check for comprehension of the roles and responsibilities of each person and their expectations of the project. Think global, act local—many cultural problems can be avoided a the project organization chart, use “regional” managers to deal with local stakeholders, provide regular feedback on the project's deliverables and practical assistance on the deployment. The insight that, “it's not the same everywhere” is so often overlooked. For example, some cultures are process driven and appreciate detailed methodologies others prefer thorough checklists. If possible, get regional resources from the last project involved in planning the next, even when the technology differs.

Take account of the organization's culture in determining the project approach. One model is—The Cultural Web which examines—Rituals and Routines—“the way we do things here,” Stories—organization's history, Symbols—logos, titles, offices, terminology, Power Structures—not based just on seniority, Organizational Structure—tribal and formal, Controls—key measures and reward systems (Johnson & Scholes, 1999). Using a formal model can help ensure that you identify all the major traits of the organization's culture that will either help or destroy your project. The existence of a globally deployed project management methodology reduces the friction caused by some of the cultural differences associated with the application of project management. If the project involves several companies, this may not be possible beyond agreeing to common terminology.


Put the work in the “best” place; consider developing in the “regions.” So many global IT projects are based at the corporate head office; consider other company locations that may have more extensive experience in the type of project being undertaken. It may even be preferential to base the work at a new location to address the following factors:

• Office requirements, e.g., security or technology infrastructure

• Company culture

• Proximity to key customers or key third-party suppliers or partners.

Offshore development has mainly been driven by cost factors and limited to the construction phase of IS projects. The interface between developers and the rest of the project team will often determine the level of success. Having one or more members of the offshore development team based at the project team site(s) greatly improves communication and coordination. One other consideration, there have been successful IT projects that included complete offshore development; for example, the Hong Kong Mass Transit smart card system developed in the Philippines (Dempsey, 1998).

There may be four core project management functions (scope, quality, cost, and time) but for global IT projects—speed is the key. Time limited projects can succeed before the business needs and/or technologies change. By focusing on specific business requirements (see strategic planning) and not just the desire for common systems and business practices, the project gains a window of opportunity. To increase speed, package solutions are chosen allowing the organization to focus on implementation. Although some companies view outsourcing as ineffective, many organizations have the capability to effectively monitor a third party but not to execute the work in-house. An example of this is the ability to adhere to a zero modification policy for changes to package software; internal control of scope changes is significantly more difficult than having a third party submit change requests for every proposed customer modification. Release management is critical to maintaining the speed of development, testing, and deployment, especially where technologies are changing rapidly. There is a renewed interest in this approach and it can be very easily applied to most global IT projects. By freezing the development of a product, testing it, then deploying globally, many version management problems are simplified. The deployment teams also benefit from a more stable environment with less rework. The “think global, act local” credo applies to testing; always test in the “regions.” Test, test, and test again. This includes customer surveys and focus groups.


Marketing is key on any global IT project. A formal marketing plan needs to be developed, with resources in place to handle the marketing activities defined in the plan. Third-party marketing/public relation's assistance can provide immediate help and provide a more objective view of what needs to be communicated. It is important to market the business benefits and be up-front and direct when dealing with user expectations, oversell the product and the deployment will fail. The project team can develop marketing documents and these templates can be customized to suit local requirements.


There are some real surprises out there waiting for your project, e.g., wars, mergers, and regulatory changes, the default is the project will fail. Global IT projects can succeed, e.g., the Euro conversion in December 1998. Apart from some problems with the Target clearing system, due to insufficient end-to-end testing and people adapting to new operating practices, over 30,000 people involved in the final conversion weekend experienced the result of good IT project management, peace and quiet. Reapplying the prerequisites and key lessons learned will increase the probability of success.


Armour, Frank J., Kaisler, Stephen H., & Lui, Simon Y. (1999, January/February). A big picture look at enterprise architectures. IT Professional, 35–43 (IEEE publication).

Bays, Michael E. (1999). Software release methodology. Prentice Hall. ISBN0-13-636564-7.

Dempsey, Michael. (1998, December). Bullet proof approach to complex projects. Financial Times 2.

Johnson, Gerry, & Scholes, Kevan. (1999). Exploring corporate strategy, fifth edition. Prentice Hall Europe. ISBN 0-13-080740-0.

Suskind, Richard. (1999, October). A simple test of IT viability. Financial Times 1 (

Tozer, Edwin E. (1996). Strategic IS/IT planning. Datamation Professional Series. Butterworth Heinemann. ISBN0-7506-9666-4.

University of Texas. Global Project Management. Web site address: (

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA



Related Content