---

Yes. No. Wait, let me think!

Feasibility
Notice that the question is whether it's "feasible," not "possible." While so many things are "possible," most of us realize that the cost of doing certain things is prohibitive-which makes feasibility problematic. Rather, we try to create value in a practical manner.

Maybe
When a project includes labs that all do the same thing, speak the same language, and can find a software product that can equally support each country's implementation, chances are good that the project can be successful. That's before factoring in the high failure rate of software projects, of course.

At the other extreme, consider a massive, multi-national company with many divisions and labs that perform complex and widely varied testing (large pharmaceutical firms are a good example). Add to the equation employees speaking different languages and who do not share a common second language. On top of that, suppose that there are no "appropriate" software products supplied by a software vendor that can support every country and time zone effectively. Can this company have a successful global project? If this is defined as every user across the globe logging into an identical system, the answer is, "unlikely."

This leads one to wonder how such a company could expect to have any kind of global strategy. Yet, some do succeed by their own definition.

Let's analyze the issues involved.

Global
First of all, what does "global" mean? Does it refer to the entire company, to the worldwide personnel within one division or group, or possibly to the worldwide personnel for each type of lab? The larger and more varied the grouping, the more difficult it will be to implement a single solution.

Support
How do you support groups across many time zones and languages? For implementation, it's important to have software vendor support for every team doing implementation work, unless you can create an effective internal mechanism for cross-team support. Then, the question is whether the software vendor can support the time zone and language for every team and do a reasonably good job. For day-to-day user support, the ideal is to have someone local for every implementation's support, but in today's global marketplace, that may be accomplished by having people available at the "right" time who speak the "right" language.

Type of Lab Different labs have different needs. Two labs with totally different needs may each stretch an implementation to where it's difficult to accommodate both with an identical solution. Even two labs doing the same work may have different workflows, possibly based on physical layouts or some other practical reason, with the result that they cannot be merged easily, if at all.

Strategies
It's not mandatory that a "global strategy" be defined to mean that every lab gets the same thing across-the-board. Where there is a wide variety of tasks to perform and languages to support, maybe a global strategy can simply mean cost containment by sharing resources and implementation only where practical and possible. Such a limited strategy still can potentially cost less than having each laboratory do an entirely separate implementation. Such a limited strategy results in controlling and sharing both internal and external resources, and may result in better license discounts by grouping those labs using the same product under one licensing agreement.

Finally, and Back to "Maybe"
When an organization defines its global strategy to be a one-size-fits-all solution, its laboratories must be easily defined in a limited way for that to work; otherwise, this will be one more in the multitude of failed "global strategy" projects that we see every year.

Additionally, the corporate structure must promote true understanding and flexibility among the people in charge of the projects and the labs that will be implemented. If the internal politics of the corporation don't facilitate this approach, the project will almost surely fail.

On top of all that, this type of project requires staffing by absolute top-notch people, both internally and externally. Because these projects tend to be massive, any schedule slippage is likely to be the one and only nail needed to seal the project's coffin.

---

---