Developing Your Obeya, Stage-by-Stage

In my travels I have coached many teams through the obeya process and have seen that while each team’s journey is somewhat unique, most teams do go through several stages of evolution before obeya becomes an embedded ritual.

Rationalizing: Do we really need this?

For many, just getting started on the journey can be a challenge. With all the project management tools, meetings and professional project managers involved in product-development projects today, many teams question upfront whether they really need obeya. It seems like an overlap as many say:

• “We already have all that information online that everyone can access.”
• “That is the project manager’s job.”
• “We already have too many meetings.”
• “Our team is spread out all over the place so why have a space?”

Others have also balked about past times they used war rooms for key projects, only to have the obeya end up a dog-and-pony show for senior managers and a time-drain for the people. 

So the first step is to work with the team to define what team challenges they are trying to solve and how the obeya fits the situation in question (sometimes it will not and that is okay).  However, despite all the tools, meetings and managers involved, most large teams still struggle with the fundamentals of projects – staying aligned, escalating issues, rapidly solving problems and making decisions in a timely manner.  So, the first step is for the team to identify how obeya can help them improve the execution of their projects.

Start up: Where are we going to find the space?

Getting the obeya started should not be a large undertaking; yet most teams will encounter some obstacles that need to be overcome. Some of these include:

• Finding a space. At the beginning, many organizations face the fundamental challenge of finding a space for obeya. Many say, “We already have enough problems finding a conference room for given meetings, and now you want to dedicate room for just one project?” In some instances, it may take some creativity to create a space for the first obeya – look for open areas that can be enclosed with temporary walls, use a space in a corner of the prototype shop, double up on offices to free up a room. If there is a will, a solution will present itself.  
• Taking the time to stop and set up the space. The initial setup of the obeya is a team sport. It will take a half to a whole day but it is the first demonstration by team members that they are committed to trying to work in obeya. In fact, it is a great teambuilding exercise for a project kickoff.
• Deciding what’s most relevant/useful. Creating meaningful visuals to manage the project is easier said than done. Initially, team members are uncertain about what to display. In the beginning, they will frequently overdo it and post way more information than they or their team needs. Not to worry – as the team continues to work in obeya the visuals that are most value added will show themselves and the others will gradually fade away. Similarly, obeya meetings in the beginning will take more time but as teams practice their rituals, the discussions will become more focused. Before this happens the team needs to go through a phase of experimentation.

Experimenting: Trial and Error

The first month of obeya is a challenging time for most teams. They are both learning new ways to interact with one another while still trying to get their project work done. In many cases, while teams are experimenting there will be lively debates on various visuals – which ones work, which ones don’t. People will also be editorializing how much detail to share during obeya stand-up meetings.

A best practice for the first few months of a new obeya is to build in a 10-minute debrief at the end of every other stand-up meeting to ask the team how the space and meeting rituals are working and what needs to be improved.

From Statusing to Collaborative Problem Solving

A common challenge in the early stages of implementing obeya is using the visuals and stand-ups to focus the conversation on the important subjects affecting the customer, the product and the project. All too often, teams start by plastering the walls with all the deliverables and metrics that are specified in their PD procedures and provide status on each one, as they have done in the past. Team members then struggle to see how obeya is any different from their old project status meetings done on the screen. In fact, if the team stops there with how they will use the obeya, there will be no difference!

The obeya needs to become the andon system for the project team where they can make issues (technical and business) visible and get help from the right team members and management to resolve them quickly so the project can keep moving forward. When people meet frequently in the obeya, it helps them all stay on the same page and see the bigger picture of how their work fits in and how they can help

Stalling and then evolving

A common speed-bump that teams encounter when working in obeya is that they eventually hit a plateau and the team feels like the obeya is not giving them the same level of information and collaboration as it did in the past. This is a sign that the obeya is actually working. The walls are telling us that we need to change as the product and project is evolving and consequently so does the visual management in the space. For example, in the early stages the team is typically speaking about feasibility of concepts so we would likely see many renderings on the walls that the team is evaluating. Later in the project, when they are making tools and preparing the plant for the new product, the conversation is much more execution-focused – thus we would expect to see tooling timelines and factory layouts on the walls. In other words, the obeya is a living canvas that needs to change as the product and project is evolving. Typically, at the end of each major phase of a project, the team should have a reflection to see how they need to adapt the room as they proceed into the next phase.

Standardizing and Continuously Improving

A common pitfall of many teams (and continuous improvement agents) is to try to define the visual standards and meeting protocols from the beginning. Unless you have already applied obeya on a few projects, it is best to wait until the team has learned enough about which methods and visuals work best in their environment. Similar to product development, we need to try a few prototypes and simulate them before we have the proof of concept. Once there is consensus, then the team can define the best practice and propose it as a standard for future projects.

In fact, I have seen in many cases that the standards start showing up organically in the obeya as team members provide feedback to each other and simply start adopting the visuals that work best for them. Other teams visiting the obeya then see what is working and will adopt and or adapt them to their own obeyas.

As you work through implementing obeya in your organization, recognize that it will take time and patience as teams go through the stages above. Each stage is a learning opportunity for the team and the organization so don’t rush it – as the people grow, the obeya will grow. 

Editor’s Note: Next week we will feature a follow-up piece from a manager at TechnipFMC who learned about and created an obeya under John Drogosz. Tune in next week for a fascinating look at how the obeya room has improved their product development operations.