The topic du jour is still terminology lifecycle management, specifically governance and maintenance – if you missed the first part, you can catch up here.
Last week we have cut the development and architecture bits short, because they are intertwined with the concept of governance. If you wish to see all the work put into creating, authoring and structuring last another day, factor in roles, responsibilities, communication structure, collaboration model, permissions and transparency.
Paths and Pause Points
One of the major issues with managing terminology is scope creep and overlapping states, often as a result of product and content development which are usually heavily parallelized. Serial management is not productive in most cases, and while easier to set up, the disadvantages are dire. A comprehensive framework can offer mature dependency-management, serving as a robust backbone to satisfy simultaneous processes from both the technical and management perspective. In a scenario when multiple threads can progress at the same time, it is even more crucial to find pause points to allow all the different updates/modifications to be synchronized in terms of both content and status.
A company-wide terminology database is accessible to diverse parties. Some update or modification cycles are parallelizable without worrying about entanglement or version issues, because the overlap is insignificant or non-existing. A good example for this can be marketing and software development content, and with the proper permission model the odd discrepancy can be found and fixed manually. On the other hand a UI element update can only be done in parallel to a certain extent, and the pipeline has to have previously defined pause points to ensure the desired synchronization. While linguistic quality assessment can be even crowdsourced (if one would wish doing to so in spite of all the hard evidence against it), it is best not be done along with validation and/or localization, because modifications are co-dependent.
In brief, pause points and well-defined paths, if set up properly, can reduce overhead and render management more transparent, while ensuring that mistakes can be spotted on the fly.
Needless to say, any organization-wide resource needs to have flexible permission management to boot, preferably as fine grained as possible. The permission structure can either rely on a collaborative or hierarchical model, or even on a mix of the two, but it is always best to appoint a single group to oversee and also catalyse processes to avoid mismanagement.
While not directly related to permission management, vendor lock-in is also worth a note here. Vendor lock-in is one of the drawbacks of deciding to go with lifecycle management instead of focusing on detached projects. Usually it’s not a show-stopper though, but it can cause an acute headache as it generates dependencies which are not trivial to abandon, and hence it may unbalance the process. Apparently, these posts incessantly harp on thinking ahead and considering all the pros and cons – you already know the gist, we cannot suggest otherwise about this issue either.
In spite of being the ultimate buzz word of all the armchair philosophers (us included), collaboration never goes out of style and holds tremendous value. Nowadays there seems to be an insatiable need for permanent collaboration, and while it can certainly boost productivity and ensure a rapid deployment timetable, it’s not necessarily the hallmark of quality as well. In itself the option for collaboration can turn into an uphill battle, if the scope and communication channels are not specified. Networks, collaboration and simultaneous processes can only truly blossom in a controlled environment. Distribution of work has to be managed, which doesn’t mean that we opt for an authoritarian model. To the contrary, process management in this case means that the concepts, policies and outlines are defined globally, perhaps along the lines we have visited in our previous post, allowing every party to contribute their ideas about terminology in a centralized place, but their decisions are best made locally. Having said all this, collaboration is a key concept to lifecycle management, but success does not come naturally, there are many pitfalls in the actual implementation.
We have only scratched the surface, but these last two posts (here and here) are already quite a readful. In case you worry, terminology lifecycle management is coming back in 2013. If you don’t agree with any of the points we made, have any comments or would like us to go into more detail, please share your thoughts. The floor is open, and we hope to see you next week for a holiday issue!
Pingback: Ode to Terminology Lifecycle Management – Part 3 | espell LABS blog