Bentley Systems publishes the world’s leading infrastructure software for construction professionals. With over 3,000 employees in more than 45 countries and $500 million in annual revenues, Bentley produces the engineering design software behind such landmark projects as the Channel Tunnel and the Bird’s Nest Olympic Stadium in Beijing. As director of release services at Bentley Systems and especially known for his lean localization, John Papaioannou is an Enterprise Innovator par excellence. Thanks to innovations in vendor management and machine translation, Papaioannou is able to support the localization of hundreds of releases per year with one of the industry’s leanest localization teams. He works from Bentley’s new offices near St. Stephen’s Green in Dublin.

Thicke: What is your role at Bentley Systems?

Papaioannou: Currently, I am responsible for the localization group as well as the product release group, which produces the official builds for all the languages, including English.

Thicke: What is the localization group responsible for?

Papaioannou: We handle up to 100 different products into as many as 19 different languages, with a total of around 440 releases in 2010, and we do it with a fairly small team. The localization team comprises three full-time localization project managers and two part-time, dispersed across five countries. The team is responsible primarily for the translation and localization of our products, including graphical user interface and online help, as well as all courseware.

Thicke: In our work with Bentley, we’ve seen your strong interest in lean localization. What do you mean by lean?

Papaioannou: Lean means doing more with less, not just during crises and cutbacks, but year after year. No two years remain unchanged in terms of process, productivity and performance. The question is never “Are we doing well enough?” but “What is next?” Instead of throwing more resources onto a problem, we throw more process improvements on it. We have an average annual growth rate of 24% in the number of releases, and we are able to achieve this without a corresponding increase in head count or budget.

Vendors as project managers

Thicke: 24% more releases each year for the same budget is the kind of result many enterprises would like to see. How do you achieve this?

Papaioannou: Basically, we have created a model that involves outsourcing the project management (PM) function altogether, with the client-side managers taking on a role of vendor manager, facilitator and escalation path. Instead of all communications being funneled via the client-side project manager, only exceptions involve some activity for him or her. Since not all projects involve some sort of escalation or exception, the manager is therefore able to handle a much larger volume of projects. With this model, the client simply gives the vendor a purchase order number for the project, and the vendor gives the client the build to release.

Thicke: Isn’t that a dangerous approach, outsourcing PM activities?

Papaioannou: It is just a task like any other. It is not strategic, it does not need to be done by a specific resource and it does not yield control to the vendors. The leanest approach that works for Bentley is simply to outsource it.

Thicke: So your managers facilitate the process rather than micromanage it. What other client-side staff do the vendors directly deal with?

Papaioannou: The vendors deal with developers, product managers and reviewers, whether these are internal or third party — everyone, really, except budget holders, finance and any VPs.

Thicke: So let’s get into the nitty gritty. How are files picked up and delivered back to Bentley?

Papaioannou: The vendors use a self-service approach to pick up complete transkits, which ideally will enable them to produce test builds themselves. They then deliver the production-ready translated files directly into our source code control system, tag them and organize a build for review or for release.

Thicke: OK, that’s lean! What happens when things go wrong?

Papaioannou: That is when the client project manager steps in. The vendors are supposed to make a reasonable effort to be independent, then escalate.

Thicke: How does it work with the reviewers? If they interact directly, how are preferential changes handled?

Papaioannou: Vendors are required to challenge reviewer corrections when these are in conflict with other products or when the changes would conflict with released versions and interdependent products. For such global changes, vendors need to coordinate with all reviewers affected by the global change request.

Thicke: That sounds like a lot of work, not to mention responsibility. How do your vendors react to such a burden being placed upon them?

Papaioannou: Some mechanisms are in place to make this manageable, as reviewers are generally more demanding with external contractors. For example, we aim for a single review cycle to avoid scope creep, to help focus the reviewers, and to control the review costs when the reviewers are contractors. Instead of asking the reviewers to verify the corrected build, vendors carry the responsibility to ensure that the corrections are in the release candidate.

Thicke: What if corrections cannot be made due to transkit limitations?

Papaioannou: Again, the vendors take up such issues with development, using a public database on our collaboration portal. In addition to communicating the issue, this mechanism has a reference — a knowledge base value, if you will — for the remaining vendors who come across the same issue.

Thicke: We notice that you split production by language rather than by content type. Why?

Papaioannou: Core to our sourcing strategy is using multiple vendors in parallel, for the same project into different languages. This enables us to compare productivity and leverage statistics.

Thicke: There can’t be that much variation among professional vendors, can there?

Papaioannou: We have seen the same vendor propose five times as much engineering in one part of the world than in another — exact same project, different language.

Thicke: What are the bottom-line benefits of your production model?

Papaioannou: The fundamental objective was to increase internal capacity by removing the PM bottleneck. We have actually tripled capacity over two years without an increase in project manager head count. Vendor engineers can communicate more effectively when they deal directly with developers. The supply chain is more efficient when queries are addressed directly to the person who knows, and the client-side managers are free to focus on process improvements and knowledge management.

Thicke: What about the vendors? What is the benefit for them?

Papaioannou: With the vendors so closely integrated with various Bentley groups, they are harder to replace. New vendors would have a tough time competing given the scope of services and responsibilities they would need to carry. Further, better understanding of the customer opens up opportunities for tools and services development. And, of course, experience in this production model reveals an opportunity for such a service for other vendor clients.

Thicke: What about disadvantages for your vendors? It can’t all be good?

Papaioannou: The range of services is increased and also the required skill-set. It is more difficult for the vendors to cope. In addition to the traditional services, they need to cope with new contact points, new requirements and new constraints. The vendors are more exposed to the client organization. Failures are more visible, as they are not buffered by the client-side manager. More touchpoints means more relationships to build and maintain.

Vendors as collaborators

Thicke: Tell us more about how your vendors collaborate. First of all, who are your vendors and how do you work with them?

Papaioannou: We use a mix of larger multilanguage vendors and small to medium-sized enterprises (SMEs), as we are finding that commercial vendors struggle to recruit suitable resources cost-effectively. To manage the communication with the vendors and to maintain all reference information centrally, we use a simple homegrown collaboration portal for all production work. The goals of the portal are really quite similar for most portals: to centralize all production and process information, to facilitate many-to-many communications, to reduce the number of e-mail transactions, to capture knowledge for immediate leverage and to provide a clear assignee at each project phase.

Corrections are directly entered into the system, and everyone can see everyone’s corrections and even calculate the quality assurance scores of any other vendor. Private areas are available for each vendor to post their bids.

Thicke: Your transparent model is quite unique in the localization industry. Can you tell us how this open collaboration works?

Papaioannou: First, there is almost full visibility. Vendors can see what projects they have and which ones they do not have. If vendors happen to lose a project, they can see who got it. Vendor engineers raise issues or queries through the collaboration portal, where the queries can be seen and leveraged by all vendors.

Thicke: How do you get the vendors to agree to collaborate? That can’t be the most natural thing for them.

Papaioannou: It is not as hard as it sounds. Vendors come across issues or problems at different times. It is not always the same vendor not knowing the answer or doing the work of reporting a problem. The relationship works well since they do not need to share information about their internal processes. The production staff on the vendor side is initially hesitant. However, once their management recognizes the benefits of our model for their companies, they are happy to encourage collaboration in the ranks.

Thicke: How do you know that your vendors give you a good deal?

Papaioannou: Day to day, we compare the productivity of the current vendors. Given that each vendor handles different languages, it makes sense to compare productivity rather than rates.

Longer term we compare the rates of current against potential vendors. We aim to be in the lower half of the scale, but not necessarily using the absolute cheapest vendors; many other factors are important for us, especially linguistic quality, and engineering capabilities and capacity.

Thicke: What are the main challenges you face today?

Papaioannou: The first is time-to-market. While our end users do not update their software mid-project, a good time-to-market is a strong marketing tool for Bentley. Also, our products are often too specialized for generic translation vendors. SMEs have the domain expertise, but are hard to manage.

Machine translation

Thicke: Our experience with Bentley is that while everyone is talking about machine translation (MT), Bentley has been doing it — for years. How did you make the leap when so many hesitate?

Papaioannou: MT was proposed to us by various vendors over the years, but invariably as a paid pilot. These vendors were eager to state with certainty that MT would be wonderful for us; however, we would have to carry all the risk, and the vendor would take none.

The last global financial crisis emerged as an opportunity, as crises often are. Not keen to let the crisis go to waste, when in 2008 we were offered a free pilot, we took the opportunity and discovered that MT did indeed work well for us; we have never looked back since.

Thicke: Tell us what sort of content and languages you use MT for.

Papaioannou: We have standardized MT for online help and courseware translations. Because these need to be publication quality, we only use MT with postediting. Currently, we are up to six languages in production (French, Italian, German, Spanish, Dutch and Japanese), with Russian now in the pilot phase. Generally, any new language is added as an MT translation.

Thicke: What benefits have you seen?

Papaioannou: We are seeing a 25% to 35% cost savings, in addition to the 30% translation memory (TM) savings. Other vendors still come to us, now finally proposing free pilots, but with a top-end target savings of just 10%.

Thicke: What about MT quality?

Papaioannou: While quality was not negotiable, we were surprised to see an improvement in quality using MT. We ran blind tests with each major language, with reviewers not knowing the translation was MT-generated. In each case they found the translations equal or better than the TM-based translations. On two occasions the reviewers came back with more corrections than we would have expected. It turned out to be traditional TM matches, not the new MT content! As a result, we are now thinking about updating our legacy translations using an MT process.

Thicke: It all sounds quite positive. What benchmarks have you achieved in terms of improving productivity and lowering costs in accordance with lean principles?

Papaioannou: In terms of scope we have seen a threefold productivity improvement over nine years. We have gone from 100 releases with three project managers in 2001, corresponding to 33 releases per project manager per year, to 440 releases with four managers in 2010, corresponding to 110 releases per manager per year. That is one release per project manager every two working days!

Regarding cost, we now have half the budget than we did ten years ago in absolute terms. Adjusting for inflation, we have achieved a 40% reduction in unit rates over the last seven years.