Tag Archives: Operational Research

Office Banter

Office banter has been part of my working life on a number of occasions, but what I noticed what’s required for banter to work and take hold of the atmosphere in the office is that you need at least 3 and possibly 4 or more people to keep the banter going.

Meaning that the many times that I had an office to myself, or shared one with one other person was not the times that I remember much in the way of banter. The two periods that stand out was when there was four of us sharing the Process Development Team office in Ebbw Vale, and during my time with the Operational Research team office in the Abbey General Offices in Port Talbot.

Banter can take many shapes and form, but must stay light-hearted to work. So when Phil Owens announced that he was about to get married, and a few days later entered the office with the question “guess what?”, my blurted-out response “you’re pregnant” was both hilarious and not far off the truth, because the “guess what?” was obviously that his girlfriend was pregnant, and hence the decision to get married. Potentially this could come across as offensive, but if the atmosphere in the office is open and lighthearted, then it just gets laughed off.

Just like the time when I said “I’m getting old” to which the reply came “no, you ARE old”. It would be hurtful if you knew there was any malice in it, but given the right level of lightness this just becomes water off a duck’s back.

If any of the banter was ever filmed as part of a reality TV show, I’m sure that some people would find reason to find certain parts offensive. For instance, when Karl Koehler became the new CEO for Tata Steel in Europe, references to Fawlty Towers “don’t mention the war” could have been taken as offensive or racist by those who feel so inclined, but in reality most of this type of banter is more silly rather than intended to harm.

In fact, at one point John Madill poked his head around the corner and stated “I can’t believe intelligent people like you can talk such shit”, to which my reply was “it takes intelligence to make up this kind of shit”. Or the time in Ebbw Vale when we all got into giggles but making up sentences where we mixed up the use of metric and imperial units (e.g. a few millimetres short of 2 inches) – it may not sound all that funny, but once you’re on a roll, the insiders can collapse with laughter whereas an outsider would merely look bemused.

The funny thing about it is that most of the banter is fluff, here today and most of the time forgotten tomorrow. But then again, isn’t that the essence of banter ?



Although I’ve taken part in many interviews as an interviewee, I’ve only been on the other side of the table on two occasions: in my capacity as Team Leader in Tinplate R&D, and later as part of the Operational Research team.

There was a clear difference in approach between the two sets of interviews. In Tinplate R&D the interviewing team consisted of David Jones, one or two Team Leaders and an HR representative. In a way it gave you the feeling that, whatever the outcome, you had at least selected your preferred candidate. The best example was when we were recruiting for two technicians: There were between 8 and 10 candidates, of which both Brian Bastable and myself selected our own preference, and both of us were eminently satisfied with these additions to our team.

In contrast, the graduate and functional trainee recruitment process was both far larger, more amorphous, and more regimented in its approach. It took place in place like the Millennium Stadium in Cardiff, the Liberty Stadium in Swansea, and in the later days an outbuilding of Margam Park. On all occasions there had been a pre-screening by HR, both from the CVs and completed forms, and from subsequent telephone interviews. The recruiting day itself consisted of the candidate giving a presentation to 2 interviewers, a group discussion and a proper interview where 2 interviewers subjected the candidate to a standardised set of questions.

Each of the components of the interviewing process (including the telephone interview conducted prior to the recruiting day) were given a number of points, the candidates ranked, and then given over to those who had positions on offer for the final selection of their preference.

I must say that I have my reservations of at least three parts of the whole process. First of all, anyone who doesn’t have a good telephone manner is likely to do badly, and consequently may not even make it to the final recruitment day. In the case of Operational Research this has the potential of weeding out geek-type candidates who may be very good at the technical side of the job, but lack the social finesse to make the grade in the interview.

Secondly, the group exercise makes it very hard for anyone to come out of it smelling of roses: it’s very easy to come across as overbearing, not being a team player or being too passive and get marked down for each of those perceived defects. And last but not least, standardised questions, whilst good to make an easy comparison between various candidates, does not allow for looking for specific abilities that might highlight a candidate with a specific ability in Operational Research.

In addition, I’ve seen how certain interviewers frigged the system to bring their preferred candidate up in the rankings by changing their ratings in the subsequent analysis. In short, whilst the process may be designed to recruit a generalised graduate, it is far less suitable to identify someone with specific abilities useful to Operational Research: from three graduate and two functional trainee interviews we added over time two graduates and one functional trainee, none of whom lasted more than a year before they moved elsewhere for jobs that they found more to their liking.

Presumably this deficiency in the recruiting process must be known (although maybe not officially acknowledged) in senior management circles, and my replacement must have been identified using a route that was specifically designed for someone who would not only be comfortable with, but also thrive on the type of IT work I had been doing throughout my time in Llanwern and Port Talbot.

Goals Translation

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.

Strip UK Wiki

It all started when Lianne Deeming wanted a document library for the Process Development Group. It would contain copies of and references to reports and documents of interests to her department. A group of relevant people was convened to try and establish what format this type of library should take.

To my horror the consensus gradually converged on a Lotus Notes Team Room. I say to my horror because anyone in the know should realise that Lotus Notes at this stage (we’re talking 2009-2010) was old technology which did not lend itself very well to integration with modern browsers. Despite my protestations the library took the form of a Team Room and as I suspected it disappeared without a trace without ever coming anywhere near realising the purpose for which it was created.

I still had the idea that a library of some sort might be a useful thing to have, and continued to search for alternative vehicles to try. That’s when I found out that IJmuiden were investigating the use of MediaWiki (the software use in Wikipedia). I managed to have a personal space created for myself, and started to place a couple of articles in it. Finding that this was a fairly simple process, I started to read up on how best to use wikis for consolidating knowledge and fighting what I saw described as “corporate amnesia”. The latter is a reference to the fact that companies often have to re-invent the wheel because knowledge is mostly held in people’s heads, which disappears when they leave the company.

I also looked at how the IJmuiden people were trying to use the wiki and saw that they totally missed the raison d’être of a wiki, which is to act as a collaboration tool (hence the motto “if it’s wrong, change it – if it’s missing, add it”). What they were looking for was something like SharePoint or Lotus Notes databases, which allow you attach existing documents, rather than the wiki which forces you to spell out in words how things fit together.

Not surprisingly, given this misunderstanding, IJmuiden decided to pull the plug on MediaWiki just when I, together with a small number of enthusiasts, were starting to get the hang of how to extend the wiki. Fortunately Andrew Griffiths, then with Process Control and in charge of their servers, knew of a stopgap solution which was the SharePoint wiki. The latter comes free with Microsoft servers, so that’s what we settled for, even though it lacked a number of features that make MediaWiki so user-friendly.

That’s probably one of the reasons why the number of active contributors remained rather small, but for this small group it contained a treasure trove of information from what acronyms meant to explanation of mainframe tables and field names. In the end I also used it to create user guides for systems I had developed, which helped substantially in transferring the data systems I had created for the Occupational Health and Internal Audit teams to the care of Tata Consulting Services (TCS).

In the end, however, I failed in my main objective to see the wiki become a mainstream instrument of information useful to the business. Was it the cultural discordance between how Strip Products UK does things and the approach required for a successful wiki ? Or maybe only a small percentage of people feel comfortable using and contributing to a wiki, and in an organisation of 4000 people that limits the pool to a small number of active contributors.

Whatever the case, the Strip UK wiki (it’s unlikely you’ll be able to access this, unless you manage to overcome the firewall) was useful for myself during the time it was up and running – I can’t say what happened to it since then, and how it will fare in the upheaval of future developments. I can only hope that it will remain useful to some extent to the people who remain in the South Wales part of Tata Steel.