Data is omnipresent....is god (Part 2)

Another example of the increasing prevalence of data capture and the challenges associated with its use was observed recently in my local McDonalds drive through.

While waiting for my McHappy meal (I wanted the Monopoly game...) I observed a screen detailing the "throughput" rate (target vs actual) of every Maccas store in the region categorised in red (below target), orange (border-line) or green (above target) as to how quickly drive through customers were served. At any one time a branch employee (or customer) could identify how they compared to other branches in thier region in real-time.

This in itself is not overly unusual - McDonalds are well known for thier quantitative and systems approach to managing thier business. And while the exercise is impressive in terms of the infrastructure investment and commitment to data capture, what was interesting was the management implications of the data capture.

I button-holed a junior manager and asked them what effect the (newly installed) performance tracking system had on employees - e.g. Did they look at it regularily, did they care about the performance targets, did the threat of being nationally/regionally exposed as poor performers stimulate production? I had expected that in the compliance / systems orientated "high pressure" environment of a fast food restaurant this type of tool would have a significant impact on junior staffer's work output. The highly transparent traffic-light system is easily interpreted regardless of level of training, experience or relative intelligence level and therefore one would be forgiven for it being frequently viewed by those responsible for drive-through throughput.

erm.... wrong apparently!

The manager cheerfully advised me that it was them (supervisory staff) that took most notice of the data and that in her opinion front-line staff were more or less indifferent to what was displayed on screen. The manager implied that they took the data and then translated it into operational terms - e.g. "we're in the red!! pull your finger out!" Unfortunately the place was so packed with customers that I wasn't able ask the operators their opinion (and besides...I would feel bad about slowing them down!)

One wonders whether the architects of the whole process intended it to be an explicit control mechanism or whether they had intended in a more empowering sense. A cynic would probably say yes, that to use data in this way as a control mechanism is a perfect example of the neo-Taylorist approach that Maccas have (successfully) adopted for years. However the transparency of the data belies a potentially higher purpose, to drive camaraderie (at least at a branch level) and to encourage some degree of ownership in the (hamburger) process. My N=1 interview indicates that the dominant control and compliance culture has informed the use of the tool but it would be interesting to see if this is really the case!

Needless to say I will be frequenting Maccas a bit more in the future to investigate this issue further!

Data is omnipresent....is god (Part 1)

The Australian newspaper paper discussing the latest taser death reported that investigators were able to verify the victim was shocked repeatedly 28 times.... in contrast to the officer's reported statement that he was shocked 3-4 times. This post isn't about the use of Tasers...but it is a nice (if not macabre) example of the ubiquitous nature of data in contemporary society and the (sometimes surprising) way in which it is used and treated.

As we know data... regardless of how "quantitative" is not infallible, despite popular opinion on the matter. The distributor of Taser units in Australia is quoted as saying "the data taken off the weapon is very accurate" - only if it's measuring what it's supposed to surely? For example - did the taser malfunction and produce 4-5 shocks per one pull of the trigger? Would the data record this, does the software measure trigger pulls as well as shocks? Are investigators able to correlate this type of data? Was the officer accurate in their recollections? The ability to determine whether an event is the result of "operator error" or "technology malfunction" is one most visibly observed in the aviation industry but is also evident in other incidents involving engineering and infrastructure assets (Hatfield, Piper-Alpa etc.) As Prof Andy Koronios has repeatedly highlighted, effective management and utilisation of meta-data would allow increasing confidence in the data we are relying in to make decisions and conclusions about previous actions.

What this incident does highlight for me is the need to be better educated about data and to collectively move beyond simple data capture and use. On the whole most people are relatively comfortable with the idea that data is important and "good data" is a desirable thing. However providing people with the capacity to evaluate data, determine its "quality", recognise its limitations and how determine how to best to utilise data is required across all levels of the organisation... especially those not directly involved in the technical aspects of the organisations - the data consumers and data collectors of this world.

The grey engineering army?

This has been an issue rolling around in my head for a while and anyone who knows me will probably have heard me going on about this.... and that's the value associated with encouraging "soon-to-be-retired" or retired engineering and technical personnel to participating in volunteering mentoring roles.

A massive deal was made of Australia's quite unique volunteer culture in 2000 during the Sydney Olympics and just recently we've again seen the amazing work that the rural fire & SES volunteer personnel carry out on an all too regular basis. And of course we should acknowledge the bloody awesome job that Engineers Without Borders (EWB) do. Despite our apparently love of the "sickie" Australia appears to have a high amount of people willing to work for free! Gasp!

During the gala dinner at ICOMS 2008 we sat in the MCG members area and were told that the empty stadium seats easily represented the number of engineering vacancies, which at that time were unfilled in Australia. And while the urgency of available skilled technical personnel has eased due to the events of the last 12 months the future still holds challenging times for organisations wishing to resource their projects. The prospect of an economic upturn (hopefully in the not too distant future) and the spectre of an ever aging population suggests that the need to manage the wealth of technical knowledge and retain our skill base continues to be a key priority for organisations.

There are a number of knowledge transfer interventions, structural changes, job design strategies and technological solutions that can be put in place to mitigate the effects of an aging brain drain. However it would seem fairly obvious to tap into our admirable volunteer culture and encourage more of our experienced engineering and technical personnel to remain within the field, mentoring our less experienced, and encouraging them to continue to lift the bar in term of our engineering capability and national competitiveness.

Now I'm sure this is happening within some organisations on an ad-hoc basis (and we would be very interested to hear from any that do)... but a nationally funded project around this area would likely yield some real advantages - not only to engineering asset organisations but to the community as a whole. Continuing to engage our older workers has a range of benefits both physical and mental on top of the knowledge base that they offer.

Easy to say, harder to do, as effective mentoring would require a level of capacity both at an individual and organisational level to produce the desired outcomes.

At an individual level very few are natural mentors and would probably need a level of training in mentoring techniques, listening and communication skills as well as advanced elements such as leadership and motivation skills. Another significant challenge lies with participating organisations and their ability to incorporate a volunteer mentoring workforce. In the first instance organisations would have to possess a willingness to participate and see real value in the exercise. In addition it is likely that the presence of a sucession or talent management plan would help identify individuals or teams likely to benefit from the interaction. Other issues concerning the extent to which the mentoring process is considered part of the organisation's formal training and development process are also likely to arise...I'm sure you can foresee a number of others relevant to your organisation!

The challenges acknowledged I still feel that an established program driven by a peak body such as Engineers Australia and federally funded would offer significant benefits to the field....keen to hear from others on this and to share their experiences in this area!

bloody tradespeople can't fill out forms....

A successful month so far with an article accepted in Reliability Engineering & System Safety (RESS) based around the work we've been doing in Manual Data Acquisition. As non- engineers we were quite surprised as to the amount of engineering data still collected by human beings! At the same time we heard a constant stream of complaints from people within the engineering field concerning the generally poor quality of data provided by engineering and technical personnel.

This obviously led to a research project looking what might be done to improve the quality of manually acquired data.... hence the RESS article. We had originally intended to apply the VERY well known model of Theory of Planned Behaviour to the issue but our research highlighted to us the significant effects of organisational structure, job design and institutional factors in determining data quality and its utilisation.

We identified that at a localised level specialist groups were highly effective in collecting, recording and using data considered to be high quality. The manner in which this data was collected was variable from "little black books" to relatively sophisticated MS Access databases. In simple terms... data that was considered relevant and useful to them in their day-to day activities was given a high priority and a high level of investment in the data acquisition process was evident.

A different story emerged for data required outside the immediate boundary of the group (e.g. for centralised reporting requirements and QA). In these cases the relevance and criticality of the data was questioned and in some instances dismissed as irrelevant, worthless and a waste of valuable time. It became quickly apparent that a lack of feedback as to the use of the data's outcomes and consequences was a key factor in the level of commitment to the quality of the data collected.

While these are early days and the research is on-going it's fair to say that our results indicate that too often "bloody operators" or "lazy tradespeople" are perhaps scapegoats for poorly designed policy, procedure and organisational structure that fail to effectively utilise data that is captured or worse, require people to collected data that is never used!

Blog guidelines - How far should you go?

As part of the process for setting up this blog we had to draft up some guidelines to ensure that our discussions didn't compramise any of our research partners or current employers. For the most part we adopted many of the recomendations that IBM uses for its staff. One of the key issues is how restrictive can you / should you make them? At what point do your guidelines restrict the sharing of ideas and content and then make the whole excersise mute?

Any thoughts on what we could add or anything you feel is too restrictive?

1. A statement must be provided that the contents of the blog represent only the individual concerned and not their employer or any affiliated organisations.

e.g. "The postings on this site are my own and don't necessarily represent CIEAM’s positions, strategies or opinions”

2. Any mention of CIEAM or associated stakeholders must be cleared using the standard “request to publish” for required of all CIEAM personnel

3. CIEAM representatives given access to the site to review content if required

4. Respect your audience. Don't use ethnic slurs, personal insults, obscenity, or engage in any conduct that would not be acceptable in the CIEAM or participating organisation’s workplace. You should also show proper consideration for others' privacy and for topics that may be considered objectionable or inflammatory—such as politics and religion.

5. Don't pick fights or “flame” those who comment on your blog content,

6. Be the first to correct your own mistakes

7. Do not alter previous posts without indicating that you have done so

8. Don't provide CIEAM’s or any participating organisation’s confidential or other proprietary information. Ask permission to publish or report on conversations that are meant to be private or internal to CIEAM or its participating organisations.