Brainstorming – effective tool, or comfort blanket?

I found this article about the reasons why brainstorms fail the other day and it got me thinking. Parker Smith raises some very vaild points about this tool. When I trained to be a facilitator, brainstorming is about the first thing you learn and it’s probably the tool I have used the most over the years. People can get to grips with it easily, there’s no maths to do or consensus to reach so it’s pretty user friendly.

Sometimes it’s the small things that make the difference…..

Yesterday I was delivering a training course as a refresher to people who regularly organise meetings at a government organisation. As often happens in these situations there were complaints about the poor chairing of meetings, normally by those higher up the organisation.

It never ceases to amaze me how some senior managers forget the importance of all those little things that smooth the way with your team – saying hello in the morning, having a bit of a chat about the weekend, sometimes even fetching the coffees!  In this case what was missing was a bit of time spent with the meeting organiser or minute taker and probably some preparation time.

It seems to be accepted in many organisations that by the time you reach a certain level you’ve picked up a range of skills, including how to effectively chair a meeting. As most people experience many times, this is not always the case! You are unusual if you’ve never sat in a meeting and thought “Why am I here? What’s the point of all this? I’ve got better things to do with my time!”

Meetings should be the life blood of an organisation, events where people learn from each other, decisions are made and new ideas aired and developed. But good meetings rely on several good habits – knowing the aims, good control from the chair, ensuring all the information is available and respecting each other. Get it wrong and you end up with frustrated, disillusioned staff and much wasted time and effort. None of this is easy as we’re dealing with that most unpredicatable commodity – the human being!  However all is not lost, it’s possible to develop the necessary skills and set up a culture that fosters the required behavoiurs. Take an honest look at the behavours in your organisation and even at yourself and make a committment to improve the situation. Your whole organisation will thank you in the long run.

Do you agree with the generalisation that senior staff  often chair meetings badly?

How can we sell the message that they may need to take a different approach to meetings?

There is no such thing as a data quality problem…

Over the last couple of days I have presented at a couple of conferences on the subject of Asset Information Management. When discussing with a delegate on Tuesday the nature of data quality problems, they asked:

Are data quality problems often user problems?

My immediate response was that all data quality problems are user/people problems. If we recognise this fact, then solving data quality problems involves solving people problems.

Approaches to data quality issues from suppliers

I recently came across two examples of how to handle poor quality supplier data, one good and one bad, in the same business unit of a large organisation.

The organisation concerned is reliant on contractors supplying accurate data for the work they have undertaken. Due to the complexity of data entries, in particular where different ‘layers’ of data interact, the likelihood of data error is high. Additionally, there are cost and safety implications if any one had to physically check the data, and that this same data has cost and possible long term safety implications if incorrect, it is essential that data supplied for input is correct.

One team member  demonstrated a very poor approach when recieving data that they believed to be incorrect – they entered data into the system to represent what they thought the correct data should be! This is decidedly risky in that they may actually be making the error worse, by changing data supplied by the contractor they are taking over liability for the accuracy of the data and the contractor will tend to repeat the errors in future, as they know the data is likely to be checked. If the data had been entered as supplied, then this team member would have retained some liability for the data, as they knew it to be wrong, additionally, the contractor would have retained the majority of the liability.

A different team operated the correct process for addressing data that was supplied with errors – they rejected the batch of data stating that there were data errors, but did not state the nature of the errors.  In this case the supplier would have to ensure they understood the data requirements in order to correct the data, which in turn would lead to better quality data in future.Additionally, the team recieving the data would not have picked up any liability for data errors.

The second approach takes less effort for less risk, whereas the first took more effort and assumed a lot of the risks – so why did they do it?