The 16 Rules of DMAIC

01/07/2022:

The 16 Rules of DMAIC

All projects, by definition, are a temporary effort to create value through a unique product, service, or result. They are all about some kind of process change that can then be operationalized to one extent or another.

In over 20-years of all sorts of projects: data development, GUI development, software development, hardware installations, data governance, risk analysis, and contingency planning, and straight process improvement and business transformation efforts, these are the lessons I've learned. Each deserves my attention as an individual article, or perhaps an entire book of their own.

It makes me feel tired all over just thinking about that possibility. In the meantime, I share them to stimulate discussion and thought:

1. Manage your customer, don't let the customer manage you. If they knew how to do it, they wouldn't need you.

2. Don't make the DMAIC process into a waterfall project; resist attempts by others to interject unnecessary complexity to the DMAIC process (Ref #1). Use Agile and Conflict Resolution techniques (Ref #8 and #15) to keep everything as simple, straightforward, and as objective as possible (Ref #5).

3. Use the data and metadata at hand. Resist the impulse to create new data. If absolutely necessary conduct a small defect or time study - 30 to 40 data points to make it statistically significant - to establish a preliminary process baseline (Ref #1 and #2).

4. Keep your tools as simple and straightforward as possible: rely on rudimentary process mining, Control and Pareto charts, and Ishikawa diagrams, and the 5 Whys process as much as possible (Ref #1).

5. Establish context. Ask lots of focused questions. Listen to the responses, and in particular, listen for what's not being said. Think before you speak and keep it simple.

6. Use Jay Arthur's 4-50 Rule to narrow the problem scope, the problem definition, and the problem complexity (Ref. # 2).

7. Don't pick the team until you have identified the problem. Team members deserve and demand care and feeding. The larger the team, the greater the care and feeding required. The more care and feeding required, the greater the complexity and the greater the "Necessary Non-Value Added" (NNVA) work that is created. If the team is too large, then you haven't narrowed the scope sufficiently (Ref. # 6).

8. To keep process discussions non-threatening and clinical, anonymize your data and minimize the use of technical jargon, as much as possible. Keep the original, unmodified data in backup storage.

9. Insist on upfront time and scheduling commitments from Leadership, Product / Process Owners, Stakeholders, and SMEs. Insist on product/process and stakeholder alternates that are empowered to make decisions on behalf of their Principles.

10. Run your meetings (Ref. # 1) insist on a simplified meeting agenda and meeting note-taking process. Keep discussions focused and on-point. Place distractions and time-consuming discussions to the Parking Lot. Facilitator, Principles, and Stakeholder talk. SME and other support personnel take and share notes. If you're not talking, take and then share notes to be rolled up into meeting minutes effectively and efficiently.

11. Manage Leadership and Product / Process Owners separately (Ref #1). Speak truth to power

12. Avoid time-consuming eye-candy reports and presentations (Ref. #4).

13. Don't overwork your process improvement team, they have regular daytime jobs to perform (Ref. #2).

14. Look for the upstream and downstream suboptimization consequences of your new improved process to identify your next process improvement effort.

15. Forget about sigma belts and certifications; think instead in terms of tools that can be used and understood by everyone (Ref #4).

16. Projects - all projects - fail because of people. Make every effort to reason, facilitate and negotiate to resolve all conflicts, before escalating to an arbitrated decision.

© Mark Lefcowitz 2001 - 2024
All Rights Reserved