Maybe not a term that is commonly known, the term “Goals Translation” covered a process in the Corus days whereby the general goals of the management team are to be translated into the underlying goals at a lower level which are supposed to contribute to the goals at the higher level.
The process is supposed to give direction to the projects maintained at middle management and shop floor level, and if the goals at this level are properly aligned with those at the higher level, a proper handling of the local projects should ultimately contribute to the successful achievement of the general goals of the management team.
The problem is that the whole goals translation system was supported using Excel spreadsheets. Meaning that the systems did not enforce a proper alignment of the goals at the various levels. For instance, there was a clear disconnect between level 2 (the lowest level for the management team) and level 3 (the start of the Works Manager’s domain), meaning that projects at the lower level tended to contribute to the goals of the Works Manager, and support of the higher level goals amounted to mere lip service.
As part of the Operational Research team, we were looking at ways to automate the goals translation process, in order to improve the alignment between the various levels. At first we looked into getting specialised software bought in, but this proved too expensive for the tastes of our management team, so that idea died a quick death.
As an alternative solution we decided to explore the concept in-house using our own web-based solution, using a database on one of Process Control’s SQL servers. This was sufficient to prove the concept, but also highlighted the lack of a suitable method for connecting various levels linked by functional location and time dimensions.
This led to the development of what we used to call Single Source, a process which would allow key performance indicators (KPI) to be calculated at the most basic level in space and time, and leaving it up to the time and location dimensions tables to perform the calculation of the same KPIs or their parent KPIs at higher levels. It proved its usefulness when applied to the Engineering Excellence dashboards, and showed that it could in principle be applied to OGSM (objectives / goals / strategies / measures), which is in essence a modification of the goals translation model.
However, the powers that be decided that a different SAP-based software would support OGSM, and that was the end of our involvement in goals translation. Single Source continued to support Engineering Excellence and similar lower level initiatives, but was not really involved in anything that amounted to goals translation. At the same time, OGSM did not reinstate goals translation at the levels where it really mattered, since it only applied from the chief executive’s level down to the individual Business Management Teams, and did not impinge on the levels from the individual Works Managers areas down.
The lesson ? Make sure that you have an interested party in the business to whom you can hand over your project or system on completion. Otherwise you’ll find that it’s no good developing something and then trying to find a buyer for it. But that is the topic for a different blog.