|
Replaced in title only, that is. In traditional Six Sigma, the role of a Master Black Belt (MBB) was developed to provide leadership and tool coaching across multiple Six Sigma projects as they focused on reactive problem solving and cost savings. The MBB managed complexity within and across interrelated problem-solving projects and served as a mentor to Black Belts (BB) and Green Belts (GB). The Master Black Belt can teach, guide and has mastery of the complete DMAIC tool set.
In contrast to the traditionally reactive problem-solving Six Sigma projects, consider the paradigm shifts associated with integrating Design for Six Sigma (DFSS), Lean Product Development, Agility and Flexibility into the technology and product development process. How does the role of an MBB relate to these?
Technology and product development processes guide strategic projects through a set of phases and gates (rather than the steps of Six Sigma's Define-Measure-Analyze-Improve-Control). These are not problem-solving, cost reduction projects - they are opportunity exploitation projects, typically focused on growth and margin. The tasks in each phase are assessed for potential problems so the focus shifts from problem solving to problem prevention. Problems are handled in one of three ways: 1) they are foreseen and prevented from happening, 2) they are foreseen and early-onset leading indicators are identified to initiate pre-planned contingency actions, and 3) they are not foreseen and are dealt with after they have been discovered, (the 3rd is the typical Six Sigma DMAIC project).
Technology and product development processes can have many projects running through them at the same time, with projects residing in different phases. Projects are staffed by a project manager and a cross-functional team of appropriate development engineers and various supporting team members. Tasks are numerous, complex and can be enabled by selecting from a broad set of tools, methods and best practices. The product and production processes comprise complex systems requiring architecture, engineering and integration - clearly the domain of that special breed known as a Systems Engineer!
Take the Systems Engineer; their role appears to have many similarities to that of traditional Six Sigma Master Black Belts:
- They provide coaching, guidance and collaborative integration services across numerous cross-functional development teams. Their tool set is the systems engineering body of knowledge and their engineering domain knowledge, as well as DFSS, Lean Product development, Agile / Flexible development knowledge.
- They apply their skills across multiple projects. They collaborate with Engineering Team Leaders as well as subject matter experts (SME) and individual contributors within and across the phases of development.
- They manage complexity down through the system, subsystem, subassembly, part, material and production process levels. They allocate requirements down through the system's hierarchy and help develop capability all the way back up to the integrated system level. They own, lead and document the Critical/Key Parameter Development and Management process across projects.
- They supervise the preparation of summary data, primarily on technical performance and product / production costs for risk management during technical and gate reviews.
But, is it appropriate to call a Systems Engineer a MBB and call other development team members BB's and GB's? From my experience in over 35 companies over 16 years of working in the business of integrating DFSS and associated best practices into both technology and product development processes, the answer is no, it's not really appropriate. To subject the development community to Six Sigma paradigms that were designed for reactive, problem-solving project work is to change their intent and mission of pro-active problem prevention. Some companies adopting what would be called "Design for Six Sigma" avoid any reference to "Six Sigma" at all and instead refer to it as Design Excellence.
DFSS is often a hard pill to swallow in the best of cultures and the more smoothly it is integrated into the development paradigm, the quicker it becomes an everyday way of life where its tasks and enabling best practices are embraced. Take all the great attributes of MBB's, BB's and GB's and integrate them into the roles and responsibilities of the time-tested development community's existing job titles, and all the advantages DFSS and its associated best practices have to offer will quietly accrue to continuously improve your development processes. |
