Continued from previous post...
The company's global research and engineering council, sponsored by executive leadership, approved transformation plan for product development process. Leadership of two development organizations, together with supply chain and production operations management (now already consolidated) had several meetings to get familiar with the framework being proposed. IT representatives solicited consulting support and finally everyone accepted the three-fold plan:
- establish common phase-gate model that is applicable to all development programs;
- establish common metrics based on the global business strategy;
- standardize on tools and practices that are common across entire scope of development efforts.
Transformation champion was selected amongst five senior engineering managers and he was teamed with an IT project manager in charge of systems integration (and migration).
With the stage set, and greatly encouraged by chosen consulting firm, the group decided to follow their standard Business Process Re-engineering methodology - same one that has been greatly received by supply chain organization. The order of steps had it like this: define "as-is" process map in both development organizations, reconcile two processes into a common set of activities and procedures, assess metrics critical for success according to corporate strategy, evaluate and benchmark two processes according to the metrics, determine "to-be" common process and propose final solution. Information technology part of the team had to, in parallel, map out information flow and functional system coverage of the process to propose consolidation strategy in lieu with "to-be" process. And finally, a roadmap of well defined process changes would be committed to by both organizations.
As the saying goes "devil is in the detail", the team encountered a formidable challenge right at the beginning. Although each team had detailed documentation with process flows and practices ("cost driven" team even had an exhaustive quality documentation for each step and each deliverable), there could not be obtained a common set of definitions that can be used for fair comparison of two processes. Early attempts at reconciled view delivered overly abstract process map that was too trivial for comparison. Subsequent deep dive into details only reinforced "nay-sayer" camps at both "poles of wisdom". Sentiment of a futile effort quickly plagued the team, and majority of interviewed engineers started asking for being taken off the team. Stuck in this predicament for almost few months, the team reported back to the committee a recommendation to either abandon the effort or reinforce project criticality (hoping that engineers will start converging pressured by fear of prolonged disturbances to their daily efforts).
However, engineers knew better how critical it is to change process and realign resources into an unproven management paradigm. The push-back this time was even worse with few influential "gray hairs" leading the pack. Left with little to ponder with, the team gave up, with a significant dose of resignation and an overwhelming archive of deliverables - few dozens pounds of maps with flowcharts and interview recordings. Blame it on culture said the consulting arm, their cheque collection going undisputed.
Nevertheless, corporate strategists could not accept one of three pillars of globalization efforts to be undermined - that is - reusing brand and consolidating product portfolio. One of executives attended a workshop (invited by their large customer) where she heard of a reference model that she understood was "a Rosetta stone of value chains", enabling comparison and reconciliation of any number of processes with same purpose, from corporate governance to customer service (of course, research and development included).
Her e-mail went to by now disillusioned project champion (otherwise a highly respected colleague from many years back) and after a coffee break and few web pages searched, he decided to reconsider his efforts, but this time in a stealth mode. No fanfares, no large consulting budgets, just trial and error on a limited sample. Being a manager of a fairly large simulation and validation team himself, he decided to talk to his peers overseas and agreed to map out computer aided engineering, simulation and validation activities between two organizations. If limited effort comes to a success, he was willing to propose an all around refresh of the failed initiative. His idea was accepted, and both the executive that proposed the effort and the senior executive in charge of global development agreed. They knew that if this moves forward with success, their job of convincing others on the executive team would not be too difficult. Let's do it from within, they agreed.
Quickly, our change champion realized differences in methodology. One difference seemed very clever to him: Rather then asking selected groups of cross-functional professionals to sit together and model their processes jointly while listing any issues they think are causing lower efficiency, he would sit down with each functional group separately and ask them to, using a dictionary with their own terminology, describe what is it that they do for the company. Because, he would use same dictionary for every conversation, the deliverables chosen as one group's outputs would eventually end up as different group's inputs and so on. That way he would connect the dependencies wherever same inputs/outputs get explicitly mentioned by both connected groups, while also outlining any loose ends - inputs or outputs that have no consensus producers or consumers, or agreed upon level of quality and timing. He would then pursue these gaps in another round of clarifications until there is simply a set of well defined gaps.
The only missing link in this plan, otherwise very logical, was - dictionary. Well, he still had that large pile of documentation that consultants left behind. Buried somewhere within these pages, he hoped, were elements to build his starting dictionary. Quickly scanning through documents he observed various ways of classifying and organizing captured information. Documents had a mixture of items in each diagram - activities, swim-lanes, inputs/outputs, practices, systems and databases, rules, some also had issues as notes, etc., but for most part were consistently charted, obviously coming from same flowcharting tool. Forget the flow - he thought, let me just scrape off all repetitive activities and inputs and outputs. He hired a student to structure data in excel spreadsheet and in a week he had over a hundred activities with close to four hundred unique inputs and outputs. Sorting and comparing data, he eliminated roughly a quarter of activities as being duplicates or inconsistent with what he defined an activity (e.g. a deliverable, an event or simple some reported metrics), and also close to a third of inputs and outputs due to same sort of semantic noise.
Equipped with what he believed was right dictionary to start with, he called first group of engineers into discussions - his own team. "Here are rules he said: using this dictionary, you will list all our activities and for each activity inputs and outputs that apply. Give me also idea where you think inputs come from and where outputs go to, but do not worry about that if you make a mistake." It took them roughly forty five minutes to agree on list of activities and I/O-s within their scope of work, with several items added to the dictionary and few other re-named and/or re-defined. The champion asked his colleague overseas to do same exercise using same dictionary and to actually do interview by themselves. So they did. Interestingly enough, other team took also around an hour to complete the task. Results were astounding - total count of activities between two groups was eleven, out of which only three were unique to either organization, eight being common. Total count of I/O-s was 27, with nine unique ones, eighteen being common. Everyone agreed that level of detail was not the lowest, but very applicable for the purpose - mapping out dependencies between organizational teams. They also determined that their understanding of who provides them inputs and who consumes their outputs was very sketchy at best (what sparked curiosity for the next set of interviews).
Not only did the trial group obtain consensus on similarities and on differences, they could hardly wait to find out how the entire flow connects. Further interviews with other groups involved same approach - using a common dictionary each group, one at a time, was asked same questions: What do you do, how do you add value, what inputs you need and what outputs you produce?
Let me fast forward several weeks... The resulting efforts produced not only a consensus "as is" map at proper level of detail for fair comparisons. They also produced a very important list of gaps and defined all iterative loops. They also determined true cycle times between various deliverables in the process, as well as variances of cycle times. The assessment led to much more realistic placement of gates (around clusters of major iterations) and recognition of true value streams of achieving integrating events (a.k.a. milestone). Each I/O was then mapped to information systems authoring it, their common meta-schema was defined and opportunity to support common activities and I/O-s with same set of tools was determined. Total efforts took a fraction of time and cost originally planned for previously failed initiative. The company now guards its process know-how tightly, evolving its dictionary and mapping various value stream scenarios to continuously seek root causes of under-performance and new ideas for improved performance.
PLM framework is not difficult to obtain, it starts with recognition of specifics of product development and avoidance of forcing other frameworks more applicable to transactional and sequential processes. It also requires keen interest in letting engineers express themselves with their own lingo, letting them describe their activities as an integrated system of value added elements connected by explicit dependencies (interfaces), not as a snapshot of most likely sequence of deliverables captured on a piece of paper. Engineers know systems - they design them, they are also fully aware that they operate as an integrated system themselves. Let engineers manage their efforts with devices they understand, while ensuring their integration with the rest of the organization based on consistent set of principles for measuring and continuously improving performance.
Join us on June 27, for a webinar on the PLM frameworks. Link to the event announcement is here https://cpd-associates.com/download/index.cfm?download=Process0607&company=
