Commendable Comments (Part 5)

 Thank You

Photo via Flickr (Creative Commons License) by: toettoet

Welcome to the 100th Obsessive-Compulsive Data Quality (OCDQ) blog post!

Absolutely without question, there is no better way to commemorate this milestone other than to also make this the 5th entry in my ongoing series for expressing my gratitude to my readers for their truly commendable comments on my blog posts. 

 

Commendable Comments

On Will people still read in the future?, Don Frederiksen commented:

I had an opportunity to study and write about informal learning in the past year and one concept that resonated with me was the notion of Personal Learning Environments (PLE).

In the context of your post, I would regard reading as one element of my PLE, i.e., a method for processing content.  One power of the PLE is that you can control your content, process, objectives, and tools. 

Your PLE will also vary depending on where you are and even with the type of access you have.

For example, I have just spent the last two days without WiFi.  As frustrated as I was, I adapted my PLE based on that scenario.  This morning, I'm sitting in McDonald's drinking coffee but wasn't in a place to watch your video.  (Thank goodness you posted text.)

Even without my current location as a factor, I don't always watch videos or listen to podcasts because I have less control of the content and/or pace.

In regards to your questions, I like books, I read e-books, online content, occasional video, audio books, and Kindle on the iPhone.  Combine these items with TweetDeck, Google Reader, the paper version of the Minneapolis Star Tribune, Amazon, and the Public Library, and you have identified the regular components of my PLE.  To me the tools and process will vary based on my situation.

I also recognize that other people will most likely employ different tools and processes.  The richness of our environment may suggest a decline in reading, but in the end it all comes down to different strokes for different folks.  Everyone motivated to learn can create their own PLE.”

On Shut Your Mouth, Augusto Albeghi (aka Stray__Cat) commented:

“In my opinion, this is a very slippery slope.

This post is true in a world of good-hearted people where everyone wants the best for the team. 

In the real world, the consultant is someone to blame for every problem the project encounters, e.g., they shut their mouth, they'll never be able to stand the critique and will be fired soon.

The better situation is to have expressed a clear recommendation, and if the the customer chooses not to follow it, then the consultant is formally shielded from any form of critique.

The consultant is likely to be caught in no man's land between opposing factions of the project, and must be able to take the right side by a clear statement.  Some customers ask the consultant what's the best thing to do, in order to blame the consultant instead of themselves if something goes wrong.

However, even given all of this, the advice to listen carefully to the customer is still absolutely the #1 lesson that a consultant must learn.”

On OOBE-DQ, Where Are You?, Jill Wanless (aka Sheezaredhead) commented:

“For us, the whole ‘ease of use’ vs. powerful functionality’ debate was included in the business case for the purchase.  We identified the business requirements, included pros and cons of ease of use vs. functionality and made vendor recommendations based on the results of the pros vs. cons vs. requirements.

Also important to note, and included in our business case, was to question if the ease of use requires an intensive effort or costly training program, especially if your goal is to engage business users.

So to answer your questions, I would say if you have your requirements identified, and you do your homework on the benefits/risks/costs of the software, you should have all the information you need to make a logical decision based on the present situation.

Which, of course, will change somewhere down the line as everything does.

And for goodness sake (did I say goodness?), when things do change, always start with identifying the requirements.  Never assume the requirements are the same as they used to be.”

On OOBE-DQ, Where Are You?, Dylan Jones commented:

I think the most important trend in recent years is where vendors are really starting to understand how data quality workflows should integrate with the knowledge workforce.

I'm seeing several products really get this and create simple user interfaces and functions based on the role of the knowledge worker involved.  These tools have a great balance between usable interface for business specific roles but also a great deal of power features under the bonnet.  That is the software I typically recommend but again it is also about budget, these solutions may be too expensive for some organizations.

There is a danger here though of adding powerful features to knowledge workers who don't fully understand the ramifications of committing those updates to that master customer list.  I still think we'll see IT playing a major role in the data quality process for some time to come, despite the business-focused marketing we're seeing in vendor land.”

On The Dumb and Dumber Guide to Data Quality, Monis Iqbal commented:

Pretty convincing post for those allergic to long term corrective measures.

And this spawns another question and that is directed towards software developers who come and work on a product/project involving data manipulation and maintaining the quality of the data but aren't that concerned because they did their job of developing the product and then move on to another assignment.

I know I may be repeating the same arguments as presented in your post (Business vs IT) but these developers did care that the project handles data correctly and yet they aren't concerned about quality in the long term, however the person running the business is.

My point is that although data quality can only be achieved when both parties join hands together, I think it is the stakeholder who has to enforce it during all stages of the project lifecycle.”

Thank You

In this brief OCDQ Video, I express my gratitude to all of my readers for helping me reach my 100th blog post.

 

If you are having trouble viewing this video, then you can watch it on Vimeo by clicking on this link: OCDQ Video

 

Thanks for your comment

Blogging has made the digital version of my world much smaller and allowed my writing to reach parts of the world it wouldn’t otherwise have been able to reach.  My native language is English, which is also the only language I am fluent in. 

However, with lots of help from both my readers as well as Google Translate, I have been trying to at least learn how to write “Thanks for your comment” in as many languages as possible.

Here is the list (in alphabetical order by language) that I have compiled so far:

  • Afrikaans – Dankie vir jou kommentaar
  • Croatian – Hvala na komentaru
  • Danish – Tak for din kommentar
  • Dutch – Bedankt voor je opmerking
  • French – Merci pour votre commentaire
  • German – Danke für Deine Anmerkung
  • Italian – Grazie per il tuo commento
  • Norwegian – Takk for din kommentar
  • Portuguese – Obrigado pelo seu comentário
  • Spanish – Gracias por tu comentario
  • Swedish – Tack för din kommentar
  • Welsh – Diolch yn fawr am eich sylw chi

Please help continue my education by adding to (or correcting) the above list by posting a comment below.

 

Related Posts

Commendable Comments (Part 1)

Commendable Comments (Part 2)

Commendable Comments (Part 3)

Commendable Comments (Part 4)