Single Sourcing Greece's Default

Greece is now dangerously close to defaulting on its national debt. Despite the recent bailouts, many financial experts believe that the situation is unsustainable. Greece simply cannot afford to pay its bills. Its debt to GDP ratio is a staggering 140%, meaning it owes almost one and half times the value of all its goods and services. It could only be a matter of time before Greece defaults.

Defaulting, while certainly undesirable, does not necessarily mean the end of a country. Argentina, Russia, Ukraine and many other countries have also defaulted, and have gone on to have healthy and vibrant economies.

Still, the European Union is desperate to save Greece from default because they believe that if Greece defaults, it could plunge the entire region into financial chaos and destroy the value of the euro. Therefore, you could say that the decision to unite the currencies of Europe caused this problem in the first place. If Greece had never joined the euro, they still would be in a mess, but it would have been their own mess.

Single-sourcing in technical communication refers to the process of storing a piece of information once and then reusing it as needed. The euro is a political and economic example of single-sourcing. Seventeen different European nations use it, instead of maintaining separate currencies.

When the euro was first introduced, Europeans were hopeful that by single-sourcing their currencies, they would eliminate the disadvantages of multiple currencies, namely the inefficiencies of currency conversion. But as we've now seen, these advantages have been decimated by the Greek fiasco, costing billions of euros to fix.

It is very easy to make the object to be single-sourced too large. For example, you may have a complex procedure containing ten steps that appears in three separate guides. As long as the procedure does not vary, there is no problem. However, what if later you need add a new step to only one of the guides? You could add the step and then conditionalize it so that it is hidden in some of the guides but appears in the necessary guides.

But what if later the situation becomes even more complex? What if you need to hide or add certain steps to certain guides? By choosing to single source the entire procedure, you have essentially backed yourself into a corner, much like Europe with Greece.

The only effective long-term solution is to store each step as a separate object, then assemble each step in each document as needed. This gives you the full flexibility to include or omit steps as needed.

In essence, you need to "default" on your original documentation architecture, declare informational bankruptcy, restructure and begin anew.

To choose not to would be a Greek tragedy.