Getting On the Same Page … Literally

“I thought this has been worked out by your group…”, “I have the feeling that you did not make the same assumptions as we…”, “Where did you take these numbers from? they are clearly not from us...”, “…yeah, we will look into this next month, our plate is full…” Does this sound familiar??

New Product Development can get messy very soon, very fast, especially with complicated products where several highly specialized stakeholders need to align their work in order to progress the development. Misalignment invariably leads to trouble - already made decisions need to be revisited, resulting in: late configuration changes that drive higher costs and schedule slippage or loss of product performance leading to less revenue. More stakeholders involved, more risk for this to happen.

“All we need is better / more governance” is the most common answer I heard in response to this situation. These governance forums though (mostly weekly meetings with strong emphasis on status), are not as effective as someone would think, even when all the items on the agenda are completed and attendance is 100%. Why? They do not foster the proper environment for common understanding. Meeting once a week and talking for 1 to 2 hours is largely insufficient to cover complicated technical inter-dependencies.

There are alternatives to “better / more governance”: visual management, co-located multidisciplinary teams ... and the A3 Methodology, which is a simple, proven way to help establish and maintain both collaboration and alignment while delivering robust design solutions. How is this achieved? Following a structured process with clear roles and responsibilities and using a “common understanding placeholder”, the A3 sheet while communicating frequently. Based on one-on-one interactions, this approach proves to be very effective when followed properly, as it enables meaningful exchanges between the ones involved on a when-needed-basis.?

A3 Methodology = (Process + R&Rs + Sheet of paper) x Communication

In complicated, multi-functional New Product Development environments, ownership is key. This is why the A3 Methodology main roles and responsibilities are clearly stated and assigned: the Owner is responsible to execute the development mandate; the Champion gives the mandate to and coaches the Owner, while removing roadblocks; the Stakeholders perform analysis and design work, providing expertise.

The Owner relies on the Champion for guidance and support and on Stakeholders for expertise through a continuous dialogue, while following the A3 Methodology steps and using the A3 sheet as the main communication vehicle. This is how everybody gets literally on the same page. More the key players interact, faster the common understanding grows. Better common understanding, better basis for making the right decisions.

This is how it works:

Tom Z is a system development manager and his executive, Bob H gives him the mandate to lead the development of the 123 System for the new FLYBIRD program. This happens around the A3 sheet, following the first step:

1. Initial Situation –Together, they start by briefly capturing what the mandate is all about: who the main stakeholders are, what the timeline is, what are the impacts to the customer, to the business. As this brief mandate description is shared by Tom with

Stakeholders via the A3 sheet, their contribution is captured, growing the common understanding around the subject. During this step, Bob makes sure (through coaching) that Tom understands all the mandate critical elements and does not jump directly into a proposal. Critical elements include: existing knowledge, historic pain points and novelties. As you can see, the structure of the one sheet of paper allows you to quickly grasp: the subject, the main players, what conclusions were reached so far, what the next steps are. Tom compiles the information on the sheet, with a clear objective: Making it easy for the reader to understand – the quality of the feedback depends on it. Once the Initial Situation is well understood, Tom is ready to conclude with a Risk Statement. After validating it with the key players, he performs synthesis work to summarize the Initial Situation in a concise way, which will make space available for the next step. Remember: the use of graphs and schematics makes it easier to synthesize - as you can see in the figure, key graphics and schematics were kept.

2. Objective and Measure – with a good understanding of the Initial Situation and with a clear Risk Statement, it is easier to formulate an Objective for the mandate. This is the

place to state what’s expected from this mandate, in terms of product performance, quality, timeline … After gathering the pertinent information, Tom and Bob draft a first version of the Objective and Measure. This version is validated then with the Stakeholders.

A quick look at the A3 sheet allows all the key players to grasp the current mandate state: In our case, we’re at the end of stage 2, we can see what work has been done and what comes next.?With a clear Objective and Measure set, Tom enters the next step:

?3. Analysis and Hypothesis – this is the step where Tom is going deeper into the System design, integration risks, with the different Stakeholders performing analysis and design work and providing insightful information about the system requirements, the key

interfaces, critical parameters, the constraints. Contributing factors, interactions impacting the System performance are established. Related Knowledge Gaps are identified and plans for closure are put in place and executed. Again, the use of graphs and schematics is highly recommended, as visual representations make it easy for the reader to understand, improving the common understanding. When collaboration issues arise, Tom is using the escalation process with Bob, who helps addressing them properly.

As Knowledge Gaps are closed and design, analysis is performed, alternatives emerge. After performing a configuration selection exercise with key players, Tom is ready to recommend. The recommendation is brought to the FLYBIRD leadership team and a decision is made. Because of the common understanding built through continuous involvement, Bob, as a decision-maker, has a high level of confidence in the recommendation. Questions like: “Have you done this, or have you checked that??Did you talk to X or to Y?” become unnecessary.

4. Execution / Implementation – this is the step where the detailed work around the approved solution(s) starts. Detailed requirements are finalized, models are created, and

simulations are run. Design and manufacturing work is performed. Parts for the rig test are ordered, and the qualification test plan is elaborated. All this time Tom updates the A3 sheet and coordinates the work performed by the Stakeholders through it. The validation point is reached:

5. Hypothesis Verification – the main questions answered during this step are: Is the Objective met as per the Measure? Does the System works as per requirements? During

this step, Tom uses the A3 sheet to coordinate with Stakeholders the testing activities and to continue the dialog with Bob for guidance and issue escalation.

Because of the common understanding achieved by involving all the key players since the beginning, the risk of not meeting the expected results is low. What is important though: this step is not exited until there’s proof that the Objective is met as per the Measure. Once there is proof that the System works as required, the last step is performed.

6. New Standard - The summary of the learning that occurred during the development is compiled by Tom, including the list with identified Knowledge Gaps (both closed and not closed), the new established relationships between design parameters and the standards that need to be updated. This is the contribution that the 123 System of the FLYBIRD program makes to the company becoming a learning organization.

Common understanding is the basis for developing designs and elaborating design alternatives with low rework risk. As we’ve seen in this example, common understanding is achieved through timely and diligently contribution from all the required key players, with the Owner and the A3 sheet being the central point.

The most frequent A3 failures that I've observed:

·????????Filling the A3 sheet without actually following the process. Usually, someone from leadership asks for an A3 and of course, the request is fulfilled ... at the end, when all the work was done. At this stage, filling the A3 sheet is a real nightmare, no surprises to hear this kind of comment: "this is insane - where do I fit all the stuff I've been working for the past 6 months?". The predictable outcome is, of course eyes rolling when people talk about A3s. But there's a deeper consequence: presenting the results from a possible chaotic approach on an A3 - giving the appearance of Lean, but no substance underneath.

·????????Working on an A3 in isolation. This can include several situations: 1. no Champion. Usually, the one mandated is well intentioned and tries hard to align Stakeholders, but without the escalation mechanism that a Champion provides, the chances to have everybody on board are slim. "I tried at least ten times to have these people in the meeting, but they are continually ignoring me" is the most likely complaint we can hear. 2. not involving Stakeholders. Sometimes the one mandated takes things personally and does the entire work based on its personal experience, without involving anybody. Not that having personal experience is a bad thing, but complicated environments make it such that it's unlikely for someone to cover all the possible technical dependencies. Working without having the required expertise is a recipe for failure.

One simple method to verify if the A3 Methodology is properly followed: Ask the one working on the A3 to show the previous versions ... to see the progression. If there's no previous versions, or if they're not annotated by various stakeholders, chances are this is a "fill in the template" exercise...

I'll be very interested to hear how you use the A3 Methodology in complicated work environments.

For more about complicated work environments and how to deal with them, please visit