Jose Ferro

José R. Ferro is a senior advisor to the Lean Enterprise Institute and president of Lean Institute Brasil, a nonprofit organization founded in 1999 to disseminate the principles and practices of Lean Thinking in Brazilian companies.

Ferro authored chapters for the Brazilian edition of the following books, all published by Editora Campus, Rio de Janeiro: Lean Thinking, Mentalidade Enxuta nas empresas, by James Womack and Dan Jones, 1998; Collision, Colisão – GM, VW e Toyota, by Maryann Keller, 1994; The Machine That Changed the World, A máquina que mudou o mundo, by James Womack, Dan Jones and Daniel Roos, 1992. He is co-author of “Brazil: a New Pattern of Industrial Relations” in After Lean Production, coordinated by MacDuffie, Kochan and Lansbury (Cornell University Press, 1998). Ferro has worked with Autosector, an association of labor, industry, and government that aided the auto industry in Brazil. He also has worked with the National Association of Automotive Manufacturers, the Brazilian Association of Vehicle Importers, and the Union of Metallurgy Companies, and the State of Bahia government.

Ferro received Ph.D. and master’s degrees in business administration, Getulio Vargas Foundation, and in production engineering from the University of São Paulo in São Carlos. Since 1992, he has been a professor in the Economics Department, School of Business Administration at São Paulo, Getulio Vargas Foundation. Ferro has also held positions as professor, University of Campinas, Statistics and Computer Science Institute Master’s Course in Quality Management (1992-1998); and Visiting Scholar at the Massachusetts Institute of Technology (1988-1990).

How Obeya Improved Our Product Development Efforts

As we embark on another year of our lean product and process development (LPPD) journey, our biggest success to date has been the application of obeya in our organization. As a follow up to John Drogosz’s article, Developing Your Obeya, Stage-by-Stage, we would like to share how we grew and evolved obeya into our organization over the past year.

We are a part of TechnipFMC, an oil and gas service and equipment provider. Our business unit, Schilling Robotics, where this journey is taking place, designs and manufactures the remotely operated vehicles (ROVs) that are used to assemble sub sea oil and gas infrastructure. At the Schilling Robotics business unit, we have a long history of highly complex engineered products and we are very familiar with conventional project management tools and techniques for running such projects. In March of 2016, we started an experiment using obeya on our latest development project to see if we could improve our product development performance.

At the start of the year, the development team created their obeya in a high-traffic area near the critical mass of the product development team. The visual schedule was the first element to be created on a blank wall, so everyone could understand the overall value stream and identify their key issues related to schedule. Shortly after the schedule went up, space was given for sub groups to post what they thought was most relevant to share with their team members.

Early in the project, the biggest benefit was the increase in organizational alignment. We define “alignment” as people knowing exactly what they must do to achieve their next goal. This was achieved via:

  • Cross-functional attendance – this fostered direct communication to all levels of the organization, all at the same time.
  • Visual schedule – this helped people keep cadence and adjust dynamically to changes.
  • Connecting people – the obeya meetings became a consistent place to find and discuss issues with people.
  • Catching issues early – identifying, communicating, and assigning them to the right person.

The team chose a weekly cadence to gather the entire product development team in the obeya to review the schedule and subgroup dates. The early meetings were crowded, messy and long. At times the meetings exceeded an hour and there were grumblings about having to stand for so long! The project leadership team immediately started weekly reflections to improve the obeya, and how it was used at the weekly meeting. Through a series of PDCA cycles, the team started defining their best practices and standards to keep the flow and focus of conversation on the elements most important to the project. At first this was a challenge, as the team had to learn to focus on the right level of detail in their discussions (i.e. what are their major technical challenges and timeline risks) and avoid long discussions on completed items. The weekly meeting quickly shrank to 45 minutes, with an increase of quality information conveyed.

Toward mid-year, the project progressed and PDCA on how we used the obeya continued. Unprompted, groups other than designers began to claim wall space. People continued to become more succinct when conveying information. The project leader, a diehard digital Gantt chart user, abandoned his secret schedule in favor of the paper wall calendar. Several other positive side effects occurred by having the obeya in place, including:

  • Post-obeya meetings – Small group huddles, around specific issues, started to spontaneously occur after the formal obeya stand-ups ended.
  • Quick recognition of success – While obeya is meant to highlight and focus on issues, feedback from the teams show that recognition of successes helps drive better morale and teamwork.
  • Posting a legend so stakeholders could understand the visual standards and the meeting rules.
  • Training new team members in obeya by having them vet their obeya speech with a peer prior to the meeting.
  • People started experimenting with videos and photos to share obeya with others offsite.

At the end of the year, the team had prototype hardware arriving that needed to be assembled and tested. As the hardware arrived, there were the usual minor hiccups associated with a prototype; missed tolerances, fit issues, software bugs, etc. All easy to address. What were conspicuously missing were the major issues; late parts, last minute scrambles, frayed nerves. Team members were verbally wondering when the “unforeseen emergency” was going to hit. There were a lot of moving parts at the end of the year, and to keep it all aligned the team leaders moved the obeya to the shop floor where the action was. The cadence changed to daily to ensure the program was on track. The focus also narrowed to the task at hand, completing the tests required to validate the design direction. This became affectionately known as the “test obeya” for the few months it was in use.

As the team met daily during the test phase, it became clear that the emergency was not going to materialize. Then, all of the sudden, it was over. The last set of tests were complete two weeks early. Upon reflection, the team credited the obeya, and the actions it drove, as the main factor for our smooth prototype delivery. The end of the year helped cement the benefits obeya can bring to all members of our product development community. It has become an integral part of how we run our projects, and will continue to evolve with future projects.

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.