Lean: A3 Reporting and Hoshin Kanri


Pumps and gear at the Scienceworks Melbourne

A part of Lean is Hoshin Kanri (HK). It is a form of policy development or strategic planning.

Like any good strategic planning process it deals with the mapping out of how the business can get to the desired outcome.

Translating the long term vision into manageable objectives and actions.

Hoshin Kanri is based around the idea that we are all domain experts within your own fields, and hence have something to contribute no matter where we stand in the organisation.

For it to work effectivity, senior and middle level management must be prepared to delegate some authority and trust.

It’s about participation by everyone from the CEO to the lower ranks of the organisation, providing a top down and bottom up directions of communication of measurables.

A3 Reporting

A3 Reporting is a way of implementing Hoshin Kanri, it forms the communication process.  Now don’t consider this as a top down stepped approach but a cyclic iterative approach.

Diagram of Hoshin Kanri process in a circle showing senior, middle and implementation teams

Hoshin Kanri Process

Simply put a CEO will want to implement a critical business direction change based on improved customer service.  This direction change has to be backed up with research and empriical evidence, not just a gut instinct or a previous way of doing things.

If it’s the later the CEO can expect to be called out to explain why.

  • The CEO outlines his request on one A3 page, this the “What” that is required. It’s distributed to the next level of management.
  • The next level then considers the “what” in terms of their division and sends out various focused “what” requests to the divisions middle level management.
  • In turn the middle level management send another A3 page with their specific focused “what” request.
  • This continues with A3 page requestes with increasing granularity until it reaches the lowest level of the organisation.
  • At this point a report on “how” the request would be done or not done or alternatives is sent on a single side of an A3 page  back up to lower management and so on.
  • Management collecting and summarising the approaches as they go up the corporate structure.
  • At the end of the process the CEO is presented with a single sided A3 page from each division on “How” they would implement the outcome.
  • This allows the CEO to review the directions and make informed planning decisions.

The major fall back with this is the element of trust that is required up and down the communication chain and the acceptance of peoples domain expertise by management.

Traditional management and organisational structures will not like this approach as it’s not about wins and achievements on a personal level but collaborative team efforts.

The key to A3 Reporting is limiting the reporting space. It all has to happen on one side of a single A3 sheet of paper.

Some place even reduce this by having the downwards “what” in the top A4 (half) of the A3 page and the “how” on the bottom of the page.  There is no limit to how the material is displayed: text, tables figures, graphs, drawings or storyboards.

As you can see the “what” can become the goals, sub goals and objectives,  with the return being process, measurements and review points to achieve the goal.

UX usage

Application of Hoshin Kanri into the UX process is a little harder.

Communication and design discussion documentation aside, which is most of what we produce, the A3 Reporting at its core could to used in terms of restriction of the reporting process.

However the core of Hoshin Kanri is the movement up and down the structure of the translation of the long term vision.   In UX environments the movement is to almost socialistic agile teams where there is no king, no management. So this maybe an issue in adapting this.

If we take  an issue and breaking it down into components for process and then returning a solution all within a limited spacial scope that may have merits to allow us to focus on the facts and outcomes alone.  Using system cards and only allowing a solution or outcome item (say research) or the like to be expressed on a small card would simulate this somewhat.  However this is very similar to existing agile processes as well.

Mind you the entire process of Hoshin Kanri is very close to the UX cycle anyway – well kind of.

So does Hoshin Kanri or A3 Reporting have anything we can steal for UX, or are we already doing the good parts.  You tell me?

Tags: , , , , , , , , , , , ,

1 comment