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.