All two way communication is feedback
One of the things I've come to realize about feedback management is that almost any two-way communication is potentially feedback generating in some way. Under this standard hardly any feedback that could be captured in a business actually is. Now, I grant that it would be overwhelming, not to mention pointless, to try and capture all the feedback that a business could conceiveably capture. I merely point out that most organizations don't think about feedback from a "Big Picture" standpoint. Most only look at feedback in the context of a very specific business problem, often one caused by a lack of specific feedback.
Very few businesses (I've never heard of any) try to break down their feedback into all the different kinds of feedback they get (or should get). They don't collect and organize enough feedback to really understand what's happening with their businesses. As a result, most still react too slowly to change. And, when they do react they often overreact. The lesson: more frequent and timely feedback helps an organization learn sooner and react better to business change.
What's needed is a methodology for understanding an organization's feedback management needs.
Given that no one I've seen has proposed a comprehensive methodology for understanding a businesses needs for feedback, I think that the approach QuestBack has come up with is worthy of a discussion.
QuestBack has coined the term "Event Driven Feedback Management". Event Driven is a way to break down the "Big Picture" - the overwhelming amount of feedback a business receives - into those highly manageable and very valuable nuggets of knowledge that are distillable from the daily life of a process. The theory behind event driven feedback is that any business process lifecycle can be broken down into a series of events that define its life history. Each event is a key point at which feedback is highly relevant and value producing. In an event driven world collecting the right amount of feedback is a simple matter of defining your events then collecting feedback after each of those events during the normal operation of the process you are in.
Interestingly, most businesses (and particularly large businesses with I/T architects in their I/S departments) already understand their key business events. Large businesses have mostly mapped their business events as part of their enterprise architecture models. They've had to, in order to develop databases and data warehouses that support their key business processes and store the information relevant to each event occurring within those processes.
I think applying the same methodology for breaking down a business' data and processes can be used to break down a businesses feedback collection and analysis needs.
An interesting thought indeed that your corporate Information Architect may be the key to an effective resolution of your company's feedback managment challenges.
One of the things I've come to realize about feedback management is that almost any two-way communication is potentially feedback generating in some way. Under this standard hardly any feedback that could be captured in a business actually is. Now, I grant that it would be overwhelming, not to mention pointless, to try and capture all the feedback that a business could conceiveably capture. I merely point out that most organizations don't think about feedback from a "Big Picture" standpoint. Most only look at feedback in the context of a very specific business problem, often one caused by a lack of specific feedback.
Very few businesses (I've never heard of any) try to break down their feedback into all the different kinds of feedback they get (or should get). They don't collect and organize enough feedback to really understand what's happening with their businesses. As a result, most still react too slowly to change. And, when they do react they often overreact. The lesson: more frequent and timely feedback helps an organization learn sooner and react better to business change.
What's needed is a methodology for understanding an organization's feedback management needs.
Given that no one I've seen has proposed a comprehensive methodology for understanding a businesses needs for feedback, I think that the approach QuestBack has come up with is worthy of a discussion.
QuestBack has coined the term "Event Driven Feedback Management". Event Driven is a way to break down the "Big Picture" - the overwhelming amount of feedback a business receives - into those highly manageable and very valuable nuggets of knowledge that are distillable from the daily life of a process. The theory behind event driven feedback is that any business process lifecycle can be broken down into a series of events that define its life history. Each event is a key point at which feedback is highly relevant and value producing. In an event driven world collecting the right amount of feedback is a simple matter of defining your events then collecting feedback after each of those events during the normal operation of the process you are in.
Interestingly, most businesses (and particularly large businesses with I/T architects in their I/S departments) already understand their key business events. Large businesses have mostly mapped their business events as part of their enterprise architecture models. They've had to, in order to develop databases and data warehouses that support their key business processes and store the information relevant to each event occurring within those processes.
I think applying the same methodology for breaking down a business' data and processes can be used to break down a businesses feedback collection and analysis needs.
An interesting thought indeed that your corporate Information Architect may be the key to an effective resolution of your company's feedback managment challenges.
