Abstract
International projects and programs are far more complex to manage than a completely local effort. They require the ability to clearly define and document the scope of the product across multiple languages, multiple cultures and time zones, and often multiple contractors. Achieving the desired end result as effectively as possible requires far more advanced processes in scope development and management than most projects need. Any misinterpretation of a requirement will create confusion and problems that can have a great impact on the work. For a software project, when the programmers speak Urdu and the client speaks only Arabic, there is a quantum gap in the communications. For construction projects in Dubai, when the engineers are from Britain or Germany, the government contacts are from the UAE, the funding comes from Saudi Arabia, and the construction crews are from India and Malaysia, significant problems can occur in defining and communicating the requirements.
As a result of increasingly international projects, significant problems have arisen that either did not exist before or were easy to remedy when the work was done locally. Many of these problems can be traced to poor or missing requirements. This paper discusses how to avoid or reduce the most significant problems. Rather than just gathering functional and performance requirements, project managers must now develop an entire requirements encyclopedia in order to provide enough detailed information in a manner and format that workers in various and multiple cultures can understand exactly what needs to be done. In this paper we use the term project throughout even though many of the examples we discuss are more accurately defined as programs.
Background
While major construction projects have included international aspects for many decades, the pace of international work has been increasing geometrically around the world in many sectors, with huge, multi-billion euro construction projects being undertaken in the UAE (particularly in Dubai and in Abu Dhabi), Saudi Arabia, Bejing, Mumbai, and other growing areas around the world. In addition to construction projects, the growth in wealth around the world has led to a large increase in projects to create the infrastructure and to provide the basic goods and services that are needed.
Rapid economic growth is quickly going to deplete the resources in that geographic area: personnel, facility, supplies, and economic resources. Once an organization has reached the stage where local resources have become scarce, it will begin importing them from other areas and eventually from other countries. In the UAE 80% of the people living and working there are expatriates, most from India, Malaysia, and the Philippines but also from other countries. All of the major construction projects in the area are being done using foreign managers, labor, and supplies.
A perfect example of such relationships is the Burj Dubai. This 800+ meter, US $4B+ development is designed to be the world's tallest manmade structure. It is a multinational effort on a huge scale. The tower's architect is Adrian Smith, an American who worked with Chicago-based Skidmore, Owings, and Merrill, the architecture and engineering firm in charge of the project. The primary builder is the Korean firm Samsung Engineering & Construction, along with the Belgium firm Besix and the Middle Eastern firm Arabtec. Third-party peer review has been performed by CBM Engineers based in Houston, Texas. The primary local construction company, Arabtec, employs 40,000 workers, virtually all of whom come from Asia, Southeast Asia, and the Indian subcontinent.
While large construction projects have been international for many years, the internationalization phenomenon is not limited to major construction projects. Boeing's new aircraft, the 787 Dreamliner, uses supplies and contractors from several other countries. Similarly, Airbus was originally founded as a consortium of Airbus France, Airbus Deutschland, BAE Systems, and Airbus Espana. In 2006 BAE Systems sold off its shares and the companies from France, Germany, and Spain merged to form the European Aeronautic Defence and Space Company (EADS) which now owns Airbus. Around the world Airbus has five spare parts centres, 160 field sites, and two final assembly plants (in Toulouse, France, and Hamburg, Germany). The company draws on a global network of more than 1,500 suppliers in over 30 countries
Another field that has become common for international work is software development. Major development facilities have been growing in India and in China as well as in eastern Europe and in Russia to satisfy the “offshoring” needs of many companies to reduce short-term costs. Outsourcing software development virtually did not exist in the early 1990s. It began seriously in the late 1990s and in the first few years of 2000 grew exponentially.
In an article in CIO magazine (Overby, 2003) Ron Beaver, CIO of Otis Elevator, stated “When you're outsourcing (software development) to India, you need the rigor in your QA organization to be tenfold over what it was before to make sure what gets built is what was agreed upon.” This is a strong indication that a company as experienced at outsourcing overseas as Otis Elevator is has found significant problems in the deliverables they get back. The same CIO article showed that the hidden costs of outsourcing can run more than 55%.
At the top level of the requirements hierarchy we have the business needs that are driving the project to start with. Satisfying these needs is why we're spending all this time and money. If these are not well understood and agreed to by all the primary stakeholders, the project is almost guaranteed to run into problems later or will be a complete failure. A classic case is the Concorde Supersonic Transport, the SST. While the combined British/French effort was being developed, political goals overcame the technical analysis and development continued even when the plane ran into such severe technical problems that the business case no longer made sense. The initial budget of 500 planes at a cost of US $10M per plane skyrocketed to only 16 planes being built at a cost of US $2B each. Prior to beginning the project no market research was done to see if it would be commercially feasible. It wasn't and the Concorde lost money every year it flew.
Common Problems Encountered
A number of articles have appeared in the past few years in magazines such as CIO, CSO, Forbes, and others studying the recent changes in outsourcing being done by industry. Common problems can be broken down into categories. These are:
| Category | Issue | Construction | High Tech | Software |
| Requirements | Poor deliverables due to poor requirements | |||
| Lack of integration of final package | ||||
| Changing requirements/scope creep | ||||
| Intellectual Property | Strong potential for theft of developed product | |||
| Designs stolen | ||||
| Security/Privacy | Potential for theft of data | |||
| Potential for hooks being put into software | ||||
| Potential for hidden surveillance equipment | ||||
| Legal and Contractual | No/inadequate intellectual property laws in contractor's country | |||
| Inability to sue or recover damages if problems arise |
|
|||
| Different interpretation of contract wording | ||||
| General Management | Lack of adequate documentation | |||
| Different expectations | ||||
| High turnover rate of contractor | ||||
| personnel | ||||
| Conflicts due to different management styles | ||||
| Late deliverables | ||||
| Inadequate resources | ||||
| Widely varying prices of planned supplies |
Many of these fall into management, contractual, or legal arenas. Prior to signing outsourcing contracts, the specific business goals of the outsourcing need to be carefully determined by upper management and sufficient safeguards put into place to reduce the risk of intellectual property theft, failure of the vendor to deliver a quality product (or to deliver at all), ensure privacy laws regarding data are understood and adhered to, and so on.
As project managers we learn quickly that our entire project depends on having a thorough set of requirements. Without those we don't understand what we're developing. We need to understand what we're creating before we start creating it, not discover it as we go along. Any missing requirements will be added in later by stakeholders writing change requests, and every change request costs us time, effort, and money whether it's approved or not.
Any international work involves contracts. These contracts are written in the language and under the laws of the country where the contracting agency is located. However, they are interpreted within the cultural and legal context of the country in which the contractor is located. Even though neither the laws nor the culture are going to be the same, both sides are fully confident in their expectations.
Does this matter? It most certainly does to the project manager. If I write a contract to do development work in Brazil and I'm located in the U.S., the contract must be far more detailed than if it was written for two U.S. companies. If the contract includes milestones, in the U.S. we interpret those milestones as hard deadlines. Other countries often don't interpret them the same way. If I have a milestone that's due in one week, to a Brazilian that milestone is not due tomorrow, it's not due a month from now, but can be delivered successfully in between those two dates. While Brazil is an example, many other cultures have the same approach to schedules.
This same interpretive approach is applied to almost everything in a contract, not just to the milestones. In many places in the Middle East, just because a contract is signed does not mean that the negotiations have ended. Far from it. Often a signed contract is used as a starting point to continue negotiations to get more of what you want. This is readily expected by anyone doing business in the Middle East, but can come as a shock to someone who has never done any work outside the U.S. or a European country.
Doing projects and work internationally has always had such problems associated with it. Even the outsourcing of manufacturing, which has been done on a large scale in the U.S. since the early 1970s, continues to have problems. Consider the case of Gibson Greetings, the oldest U.S. greeting-card producer. In the early 1990s it began to run short on cash due to a recession. In a failed attempt to cut costs, they chose to outsource their manufacturing processes, but soon developed supplier-management problems that lost them significant shelf-space at nationwide retailers. While they were outsourcing, their competitors were investing in more efficient printing and production facilities. One of these competitors soon bought Gibson.
The recent outsourcing of application software has caused additional problems that outsourcing of manufacturing did not. A programmer at Geometric Software Solutions Ltd. who was fired from his job stole the source code for a SolidWorks Plus 3-D CAD package and offered it to the company's competitors for a high price. Under Indian intellectual property (IP) laws he might never be convicted of a crime because at that time (2003) India had no laws against trade theft. A poll done by CSO magazine in January 2003 asked the question, “Does offshore outsourcing of code development constitute a significant security risk?” Eighty-five percent of chief security officers who responded said yes. While IP theft is not as major an issue in construction projects, similar concerns exist when a vendor steals a architect's design.
These problems are minimal when the vendor is a neighborhood supplier of specialized products such as accounting. You could always meet with them to discuss issues. Everyone understood both the local laws and customs in dealing with problems and they could be resolved. When the vendor is overseas there are significantly more issues and problems that occur and less opportunity to resolve them.
The Airbus A380 serves as a poster child for the problems that can be encountered. Delays cost EADS more than US $6B and pushed back the delivery date of the first aircraft by a year and a half. While the goals of producing the world's most advanced passenger airplane through international cooperation are laudatory, the practical difficulties of doing created unforeseen headaches in the rosy glow of the goals. Much analysis has been done to show that the pivotal cause was the wiring harnesses. With over 350 km of cabling, 100,000 wires, and over 40,000 connectors, there is no question the wiring harnesses are highly complex. Under pressure from aircraft purchases the interior design was made as flexible as possible so the airline could reconfigure the aircraft to their specifications, adding to the complexity.
The A380 is an extremely complex program and also illustrates that major problems in such large-scale efforts are never simple. While the wiring harnesses were the straw that broke the camel's back, a more detailed analysis shows other more fundamental problems. Serious weight issues caused a late decision to change the wires from copper to aluminum to save weight. This simple change in a detailed technical requirement had profound impacts. In order to carry as much current as copper, aluminum wires need to be approximately 50% larger, thereby making the cables more rigid, less flexible, and more difficult to install. Shouldn't the software design program have laid the harnesses out so they could be installed? Probably. But here's where senior management, in an effort to curtail climbing costs, made a decision that created the wiring problem. French designers were using CATIA V5 to design the airframe, while the German engineers were limited to the previous version, V4, because management saw no reason to spend the additional money to upgrade. The differences in the two versions were pointed to in multiple articles as the root cause of the problem. Would these problems have existed if the entire development had been done within Germany or within France? Most likely not, since there would have been far more local oversight and control and less politics.
Language can also be a problem. There is a small software development firm in Dubai that produces software for airports in the Middle East—passport, visa, and security software. Most of the programmers are from India, a very common situation, and speak Urdu. Their clients, airports, are run by the government and their official language is Arabic. The programmers speak reasonable good English, but their clients are not permitted to in a formal conversation. So the company has hired a translator to help collect the requirements from the client. While this is a workaround, translation is never perfect and adds an additional level of complexity, schedule delays, and added cost to the project. Poorly stated requirements are the most common problem cited by the project managers for late and over-cost projects.
English is the most commonly used language for business around the world. But as we all know, there are multiple varieties of English and the same word can mean different things in different countries. It would be great if we could just write contracts as explicitly as possible, but there is no perfect contractual solution to language problems. The best approach to both language difficulties and to the other management problems is to develop strong, long-term working relationships and team-building among all the stakeholders. The best relationships are those that are long-term and transcend multiple contracts. The British Airport Authority (BAA) discovered this simple rule during the development and construction of Terminal 5 (T5) at Heathrow Airport in London. After a very rough beginning to the terminal they decided that the best approach to development of large facilities would be to establish long-term working relationships with their vendors to ensure that everyone had the same goals (Brady, Davies, Gann, & Rush, 2007).
The T5 project clearly illustrates another aspect of international projects—they have major stakeholders and there is no assurance that the stakeholders will agree with each other, a situation that Hancock (2002) called a “wicked mess” in describing the development of T5. As with virtually all major projects, there are multiple stakeholders involved. For T5 these included the local Council, environmental groups, the rail operating companies, the highways agency, and primarily British Aerospace and BAA itself. The two major stakeholders, BA and BAA, had opposite needs for the terminal. BA wanted to make the terminal a pleasant throughway to get people from check-in to either the aircraft or the waiting lounge as quickly and efficiently as possible. By contrast, BAA wanted the T5 design to keep passengers in the retail area as much as possible to maximize revenues from sales.
Scope Definition
As a result of their long experience, the construction industry has learned many lessons that, if applied, can make their projects highly successful. PMI's Project of the Year in 2004, Saudi Aramco's Haradh gas project, is a perfect example. The $2 billion, three-year long project was completed 27% under budget and six months ahead of schedule. How was this done? Requirements were locked down early and changes not related to safety were not permitted. In 1929 the world's tallest building, the Empire State Building, was erected in 15 months and millions of dollars under budget. Yet a typical IT project that's four months long and takes 20 people struggles to finish on time and within budget and has as much as an 85% chance of failure, much of it traceable to not gathering the requirements or to changing requirements.
The U.S.-based Construction Industry Institute (CII) developed its Project Definition Rating Index (PDRI) to facilitate the gathering of requirements for industrial and construction projects. Using a pre-designed checklist, the rater assesses the various aspects of a construction project and rates them on their completeness. This allows a quick verification that all aspects have been adequately defined and highlights areas where more details are needed. Any areas that require more planning are risk areas that can harm the project in the future.
Industry segments such as software development have only gotten into the outsourcing process relatively recently. Outsourcing software development took off seriously less than 10 years ago, driven by the perceived costs savings of doing work in India as calculated by the programmer salary per line of code A variety of articles in magazine such as CIO have long pointed out that this perceived cost savings is the result of very narrow analysis and that a broader perspective would show that there is very little cost savings and there may actually be an overall cost penalty in software outsourcing.
We know, and have known for a long time, that doing a thorough job gathering requirements is absolutely necessary to accurately plan the project and to prevent scope creep. This is just as true in the IT world as it is in construction, public works projects, or the aerospace industry.
In the aerospace world this has been the province of systems engineering, the group that was responsible for developing the technical requirements, analyzing and modeling the system, and ensuring it was integrated into a coherent whole. The professional society for systems engineering, the International Council on Systems Engineering (INCOSE) has developed strong guidelines for gathering and managing requirements.
This strong need for thorough requirements was recently rediscovered by business analysts after a history of IT projects failing to meet business needs. The International Institute for Business Analysts (IIBA) is in the process of developing a Business Analysis Body of Knowledge (BABOK), with a significant portion of the document being devoted to business needs and requirements.
In the construction industry, the requirements are developed by the architect once the client has approved the design. Requirements definition and management are centrally located and generally clearly understood. The benchmark of clear and unambiguous requirements was the statement made by John Jacob Raskob to his architecture firm, Shreve, Lamb, and Harmon when starting the design of the Empire State Building in 1929: “Make it the tallest building in the world.” Just that, no other requirements.
The need for definitive and thorough requirements applies equally to other projects, such as maintenance projects. Qatar-based QAFCO (Qatar Ammonia and Fertilizer Company) is one of the world's largest single-plant producers of ammonia and urea. Their main facility in Messaieed is a typical international endeavour, with engineers from Norway, equipment and engineers from Germany and Norway, operations people from South Africa, plant personnel from India and other places. When one production line is shut down it costs a large amount of money in lost production, yet each line must be shut down on a regular basis for planned maintenance. Prior to a planned shutdown, a revamp project, the specific requirements that will be addressed during the revamp are well defined and locked down. Only unexpected safety issues and undiscovered problems can affect the plan.
Back when the author was a senior systems engineer on satellite systems at Martin-Marietta Aerospace, systems engineering consisted primarily of building good solid requirements, system modeling and analysis, risk identification and management, and systems integration. The requirements work was entirely technical requirements (with some operational requirements for the satellite controllers)—functional, performance, operational, and maintainability. This is not the case any longer. Now the field of requirements is much richer and more varied. In order to successfully complete projects today there is a much larger set of requirements that must be captured. A partial list includes the following:
- Functional
- Interface (both internal and external)
- Usability
- Man/Machine Interface, Look and Feel, GUI
- Data
- Implementation/Initiation
- Performance
- Safety and Security
- Operational
- “-ilities” (maintainability, reliability, scalability, upgradeability, etc.)
- Verification and Test
- Legal and Privacy.
Project managers, who are held accountable for meeting all of these requirements, worry about all of them, both technical and non-technical. All of these requirements must be captured completely and thoroughly in order for the project to succeed.
Requirements gathering begins with the organization's needs—“This is the problem that we're trying to solve, the new product we're going to sell, or the highway we're going to build.” This is the most critical stage of requirements definition because everything else flows from this. Architects, engineers, and other technical people generally can do a good job decomposing the requirements to the required level of detail. Where the process runs into problems is at the initial stage of gathering these early requirements. This is one area where dealing with the U.S. Federal government is refreshing compared to most organizations. Their RFP or SOW is as clear a statement of need as is possible for them to give you. From these documents the process is mostly a matter of decomposing the requirements into increasing levels of detail, asking clarification questions as the need arises.
A requirements matrix is often shown as a tree, similar to the tree format for a WBS. A more visually accurate representation is an inverted pyramid, with the core requirements, the ones from which everything else is decomposed, at the bottom (see Exhibit 1). If any one of these is missing or badly stated, everything derived from it will cause problems later in the project and the pyramid will topple.
Exhibit 1 – Requirements Pyramid
Getting the stakeholders to sit down long enough to collect their requirements is difficult enough for most projects. Writing the requirements in such detail that they can be clearly understood and correctly interpreted by teams that speak other languages requires additional time and people. This can be facilitated by involving staff from each of the teams and contractors in the process. Plan on having them travel to a central location and spending anywhere from a week (for simple projects) to a month for larger and more complex projects. The time spent in having every group gain a thorough understanding of the requirements will be paid back with interest later in the project by avoiding errors, misunderstandings, and rework.
This is usually where the problems in product development occur. We don't completely gather all of the requirements that are necessary to develop the product efficiently and end up overlooking critical items. When we're developing internally this is not a big issue. If we don't understand something we can just walk down the hallway and talk to the people who have the answers. Drawing flowcharts on a whiteboard is a wonderful way to talk through how the business operates and what the product should do.
Recommendations
Many, perhaps most, of the problems that we have mentioned in this paper can be alleviated by defining requirements to the level of detail where there is no question about what is being asked for in a contract. While physical, functional, and performance requirements can be so defined, more detailed technical specifications are generally developed during the design phase. These more detailed requirements are then fed back into the overall program requirements so that their potential impact on other areas of the product can be examined and problems identified.
The construction industry has one significant advantage over some other industry segments—the majority of the work is done at one site. When creating software development projects using international partners, the work is often done far from where it will be sold. In this case a much more thorough requirements definition process is required. It is very difficult and costly to fix missing or misunderstood requirements when the development team is 10,000 km away.
Too many companies have not done a thorough job in defining their requirements and discovered that they were delivered a poor product. Since they eliminated their existing staff in order to take advantage of the “cost savings” in outsourcing overseas, they had no ability to fix the problems. As a result, they have to outsource the product fixes to yet another company.
Keith Franklin, president of Empowered Software Solutions in Burr Ridge, Ill., loves offshore outsourcing because it means more work for his 40-person company. In 2003, ESS, which specializes in developing applications for Microsoft's .Net platform for Web services, earned $500,000 in revenues from fixing buggy software written in India. It took ESS five months to repair a glitch-filled application for a Web portal. Most pages on the site weren't connected, turning updating into a nightmare. Some functionality was missing (Kharif, 2003). The shoddy work didn't come cheap, either: the Indian outsourcer went $1 million over budget. Franklin says he could have done the project for less than $900,000.
The final recommendation, and it is a strong one, is taught us by the construction industry. Lock down the requirements well in advance so that thorough planning can be done and do not permit any changes unless they are related to safety or driven by late regulatory changes.