In many countries, especially those located in the Middle East and North Africa (MENA) region in general and the Gulf Corporate Council (GCC) countries in particular, the formal language in construction contracts tend to be the English language rather than the formal language of the country which is Arabic. Further, the large number of non-Arabic speaking nationalities who work on construction projects In the GCC countries select the English language as the formal language of construction contracts is a requirement. Nevertheless, executive project stakeholders and other senior leaders need to receive performance reporting using the country’s standard language of communication as the Arabic language.
Translating progress performance reports from English to Arabic is not the right solution. Not only much of the critical performance information might be lost in the translation, but the time and effort that this translation will take makes this approach ineffective.
To overcome this challenge, visuals and colors need to be used as the common communication language. For example, it can be agreed by regardless of the language they speak that Red is Critical or Not-Favorable Performance, Yellow is Alerting Performance, whereas Green is Good or Favorable Performance. Using gauges visual with those color zoning for each project performance objective like schedule, cost, quality, health and safety, sustainability, and overall would communicate the needed performance status to all projects’ stakeholders. Adding a numerical score would also provide those stakeholders with an understanding of how their projects are performing. Other similar visuals like pie charts, donut charts, line charts, histograms, etc. can also be used by adopting the same color and display concepts.
For fields that are used for selecting information, there are two requirements to be considered. For date fields, use the numeric value like 01/10/2020 instead of October 1, 2020. For areas with text values, a predefined list of values must be used on all applications for each value provided in both languages: English or Arabic. For example, project facility type will be defined as “Clinic عيادة,” “School مدرسة” among others whereas for project phases it will be described as “Design مرحلة التصميم,” “Handover مرحلة التسليم” and so on. This will enable the dashboard or report reader to select the needed filters without taking the risk of choosing the wrong filter field.
In addition, having a map visual will provide an understanding of where those projects are located to all stakeholders regardless of their preferred communication language. This needs to provide the latitude and longitude values for each project. The only remaining challenging fields are the fields where a text narrative needs to be provided. For those fields, there is no other choice but to ensure that the text in Arabic truly conveys the required message.
By adopting those practices, project stakeholders will be assured that they are receiving a single version of the truth regarding monitoring, evaluating, and reporting their capital construction projects’ performance regardless of their preferred communication language. Of course, the dashboard layout for both languages will be identical, and the stakeholders can toggle between the two versions when needed.
Achieving this multi-language performance reporting requires having a Project Management Information System (PMIS) like PMWeb to ensure the trustworthiness, validity, and comprehensiveness of the reported performance information. Project management processes will be implemented to enforce transparency and accountability in executing those processes during the complete capital construction project life cycle stages.
Nevertheless, before implementing those processes, there are few requirements for setting PMWeb to manage, monitor, evaluate, and report performance in multi-language environments. The first of those requirements is that their names need to be added in both English and Arabic language for all projects that need to be addressed. The same could also apply to the project scope work, which must be defined in both languages. Using PMWeb user-defined fields, the Project Name and Project Scope of Work in Arabic fields will be added to the project definition module. Those fields will be set as required fields to ensure that needed text values are added.
For project management processes that require to be managed and communicated in both English and Arabic language, PMWeb visual custom form builder will be used to create those forms. Those usually are the forms that involve permitting authorities and other authorities whose communication language is Arabic.
For input forms for the other project management processes and, in particular, PMWeb default ready-to-use forms, PMWeb allows each user to select his/her desired interface language, whether this was English or Arabic. Since the Arabic language used in different Arabic-speaking countries and even on other projects could differ within the same country, PMWeb allows defining the desired Arabic translation text value for each PMWeb field.
The last challenge is the text narratives for the reported performance dashboards, which would usually provide stakeholders with a comprehensive overview of how the projects’ portfolio performs. There could be different progress narrative forms as some could be specific to a project, program, or a portfolio of projects.
PMWeb, a custom form builder, will create those forms for which each text narrative will have two fields, English and Arabic. The individual responsible for reporting the performance will write the narrative. Assuming that this individual is not Arabic-speaking, the Arabic translation of the narrative will be done by another individual assigned by the project manager. Permission fields will be given to both areas, English and Arabic, to ensure that no one can manipulate the written content nor the translated version.
To enforce accountability in reporting the English and Arabic versions of the progress narrative, the text narrative form will be assigned a workflow to formalize the language translation. When the initiator of the text narrative form completes the content, he/she will submit for translation to the individual assigned to translate the content. When this individual completes the translation, he/she will submit the translation to the text narrative content provider for his/her final approval. The workflow tasks will be aligned with the permission rights set in the input form.
The translation form coupled with the workflow will provide the content creator as well as the project stakeholders who will be receiving this information with the confidence that what has been translated was done in a process that could be traced and audited should there be a conflict in what communicated.
