Hỏi: Làm sao tôi tự cải tiến mình hàng năm để là người làm phần mềm tốt hơn? Tôi muốn đặt mục đích cho năm mới sao cho tôi có thể theo được. Thầy khuyên điều gì?

Đáp: Trong khi một số người đặt mục đích của mình hàng năm, nhiều người làm phần mềm không biết cách làm và nghĩ đặt mục đích là khó. Thực tế, nó là dễ nếu bạn hiểu cách đo phần mềm. Giống như bất kì doanh nghiệp nào, người làm phần mềm phải nghĩ về làm sao chúng ta có thể tốt hơn từng năm và đạt tới tiềm năng cá nhân riêng của mình. Nó bắt đầu với việc đặt các mục đích có nghĩa và xây dựng các kế hoạch hỗ trợ cho cá nhân, doanh nghiệp và những kết quả bạn hi vọng đạt tới với khách hàng của mình. Bạn phải đặt các mục đích và kế hoạch trải rộng khả năng của bạn, thách thức bạn và đưa bạn ra ngoài vùng thoải mái của mình để cung cấp những bước ngoặt lớn nhất cho sự phát triển cá nhân của bạn. Tất nhiên, mục đích của bạn cũng nên hỗ trợ cho mục tiêu doanh nghiệp cho tổ của bạn và cho công việc. Tôi sẽ bắt đầu với những điều sau:

1.      Bắt đầu với phát biểu “Tôi sẽ.”

2.      Thêm từ hành động. Dùng động từ như “sử dụng” hay “cung cấp.” Điều này cho bức tranh trực quan về điều bạn dự định làm.

3.      Thêm kết quả mong đợi của bạn (điều bạn lập kế hoạch thực hiện) và chắc chắn nó đo được.

4.      Phải chắc chắn mục đích của bạn có thể được gắn với kết quả công việc xác định.

5.      Nói với người quản lí của bạn về đạt tới từng mục đích sẽ giống như cái gì.

6.      Nhận sự hỗ trợ của những người có ảnh hưởng then chốt.

Khi đặt mục đích, bạn cần chú ý tới các mục đích đó nên là:

1.      Xác định: Phát biểu mục đích của bạn theo thuật ngữ chính xác mô tả kết quả.

2.      Đo được: Mô tả cách kết quả có thể được đo bằng việc dùng chuẩn, đặc tả và cột mốc.

3.      Đạt tới được: làm cho mục đích của bạn đạt tới được để cho nó là thách thức cần hoàn thành thay vì là điều không thể đạt tới được.

4.      Liên quan: Gióng thẳng mục đích của bạn với mục đích và mục tiêu của nhóm công tác hay công ti của bạn.

5.      Chia pha theo thời gian: Đưa vào ngày tháng đúng thời gian và những cột mốc để giữa bạn đúng tiến trình.

Hiểu cách bạn thực hiện theo các mục đích của mình cũng là quan trọng nữa. Phản hồi bạn nhận được từ người quản lí trên cơ sở tiếp diễn sẽ giúp bạn chỉ đạo lại nỗ lực của mình và cho bạn biết bạn phải làm gì để đáp ứng, và thậm chí vượt quá các mong đợi. Vì bạn đang làm việc cho một công ti phần mềm, điều quan trọng là bạn hiểu các mục đích chiến lược của công ti, các mục tiêu của tổ bạn cũng như trách nhiệm của bạn bên trong tổ và năng lực của bạn (tri thức, kĩ năng và khả năng). Nhớ rằng mục đích phải hội tụ vào kết quả, không vào nhiệm vụ và tốt hơn cả là hội tụ vào một số giới hạn các mục đích (chẳng hạn ba tới bẩy mục đích).

Hỏi: Khi chúng tôi đang cải tiến chất lượng phần mềm, tỉ lệ lỗi mong muốn sẽ là gì cho kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận?

Đáp: Tôi đã thu thập dữ liệu lỗi cho nghiên cứu của mình và thấy rằng khi người lập trình phát triển phần mềm dùng qui trình được xác định họ tất cả đều có lỗi thấp trong kiểm thử đơn vị, điển hình ít hơn 5 lỗi trên một nghìn dòng mã (KLOC). Trong kiểm thử tích hợp, số trung bình là ít hơn 1 lỗi trên KLOC.  Lỗi trong kiểm thử hệ thống trung bình ít hơn 0.5 lỗi trên KLOC và sản phẩm được chuyển giao có lỗi trung bình ít hơn 0.1 lỗi trên KLOC trong kiểm thử chấp nhận của người dùng.

Bằng việc tuân theo qui trình được xác định, người lập trình có thể loại bỏ ít nhất 70% lỗi trước lần dịch đầu tiên. Bằng phân tích những dữ liệu này, tôi cũng thấy rằng 15% lỗi là lỗi lập trình thuần (như thiếu chấm phẩy, ‘=’ chứ không là ‘==’, v.v.)”. Trong lớp lập trình C++ của mình, tôi yêu cầu sinh viên theo dõi dữ liệu này và viết chúng ra trong vở của họ để họ có thể thấy họ mắc phải loại lỗi nào cũng như tần xuất của nó. Bằng việc có loại nhận biết này, phần lớn sinh viên cải tiến các kĩ thuật lập trình của họ một cách có ý nghĩa.

Qua phỏng vấn với những người quản lí dự án, tôi cũng thấy rằng bằng việc dùng qui trình ước lượng tốt dựa trên dữ liệu lịch sử, người quản lí dự án có thể ước lượng với độ chính xác lớn về thời gian, chi phí, lịch biểu và chất lượng cho các dự án của họ và biến thiên trung bình của chúng là: 15% về lịch biểu, 23% về chi phí và 17% về công sức. Có những bằng chứng rằng việc phát triển phần mềm tuân theo qui trình kĩ nghệ phần mềm thực sự cung cấp sản phẩm chất lượng. Tầm quan trọng trong cải tiến là đầu tư vào chương trình huấn luyện.

Hỏi: Tôi muốn trở thành một người lãnh đạo đánh giá CMMI tốt. Tôi cần loại kĩ năng nào? Xin cho lời khuyên.

Đáp: Để trở thành người lãnh đạo đánh giá CMMI tốt, bạn cần là:

1) Người quản lí khủng hoảng, có thể vẫn còn bình thản dưới sức ép lớn;

2) Người kĩ sư phần mềm có nhiều năm kinh nghiệm về quản lí dự án, đảm bảo chất lượng, quản lí cấu hình, kiểm thử và trắc nghiệm phần mềm.

3) Nhà giáo dục, người có thể vượt ra ngoài hiểu biết hàn lâm về các mô hình và có khả năng giải thích tại sao mọi sự lại quan trọng trong hoàn cảnh của tổ chức;

4) Tác nhân thay đổi, người có thể giúp tổ chức hội tụ không chỉ vào đánh giá, mà còn vào thực hiện nữa.

5) Người quản lí doanh nghiệp, người hiểu và có thể giải thích giá trị của cải tiến qui trình và cách đo dưới dạng người quản lí cấp cao có thể hiểu được và đặt thông tin này liên quan tới kinh doanh của tổ chức trong hoàn cảnh các mục đích kinh doanh chiến lược của họ; và

6) Người hành nghề thông thường, người có thể thấy ra ý nghĩa từ các hoạt động của tổ chức và dịch cách nghĩ “phát triển” mô hình thành các thuật ngữ áp dụng được khớp cho mọi dự án, từ phát triển tới bảo trì, bao gồm cả điểm khối đưa ra, hoạt động di chuyển, bảo trì và quản lí hệ thống, và các nỗ lực sáng tạo khác.

Bên cạnh đó, bạn phải có khả năng lãnh đạo, hướng dẫn, quản lí và điều khiển qui trình phân tích, điều có cấu phần then chốt là biến thiên gần như vô hạn của thực tế, các tuỳ chọn thực hiện, và sự sao lãng của tổ chức.  Và điều này được thực hiện với một tổ từ bốn tới bẩy cá nhân duy nhất, đại diện cho hàng nghìn tổ hợp cá tính khác nhau, phỏng vấn xấp xỉ hàng trăm cá nhân khác nhau, và hỏi các câu hỏi liên quan tới xấp xỉ ít nhất 1200 thực hành con trên 316 thực hành trong CMMI trong thời kì 10 ngày.  Vậy nó có vẻ dễ dàng không nhỉ?

Hỏi: Sai lầm chung mọi người thường mắc phải là gì khi cải tiến qui trình phần mềm?

Đáp: Đây là danh sách ưa thích của tôi về những sai lầm mà mọi người thường mắc:

1)    Đánh giá bây giờ, cam kết về sau: Tổ chức nhảy vào tiến hành đánh giá để tìm ra mức độ trưởng thành CMMI của mình trước khi có bất kì cam kết nào của cấp quản lí.

2)    Thiết lập nguyên trạng trước khi hết ngân sách: Không có tiêu chí lựa chọn, hay nhận diện đúng người cho việc này, tổ chức phong “người sẵn có” làm người lãnh đạo cải tiến, người quản lí SEPG trước khi hết ngân sách.

3)    Tranh cãi liên tục mà không hành động: Tổ được thành lập để cải tiến qui trình phần mềm nhưng dành hết tháng nọ tới tháng kia trong thảo luận liên tục thay vì triển khai bất kì hoạt động cải tiến nào.

4)    Tuyên bố thành công trước khi người quản lí tìm ra: Không làm cải tiến nào, tổ tuyên bố thành công và viết tài liệu qui trình dài dòng về điều họ đã đạt tới rồi nhảy sang sáng kiến khác.

Trong 20 năm qua, tôi đã thấy rằng nhiều tổ chức bày tỏ ước nguyện của họ để cải tiến qui trình phần mềm nhưng thực tế chỉ muốn làm đánh giá để tìm ra sự trưởng thành của họ. Phần lớn họ đều ở CMMI mức 1 rồi khi tìm ra điều đó thì sự sẵn lòng của họ đột nhiên biến mất. Đây là cách tiếp cận sai, phí thời gian và tiền bạc và không thực sự có nghĩa “cải tiến qui trình.”

Hỏi: Tổ chức của tôi cố gắng cải tiến qui trình phần mềm mà không thành công. Chúng tôi dường như bị mắc kẹt tại CMMI mức 1 mãi mãi. Chúng tôi có thể làm gì khác đi đây?

Đáp: Có nhiều lí do cho tổ chức không cải tiến: nó có thể do thiếu hỗ trợ của cấp quản lí, thiếu kết cấu nền để quản lí các hoạt động cải tiến, hay thiếu kĩ năng để làm cho việc cải tiến xảy ra.

Tổ chức ở CMMI mức 1 có thể tiên tiến hơn mức 2 bằng việc thực hiện kiểm soát dự án cơ sở như sau:

1) Thực hiện kỉ luật quản lí dự án: Vai trò nền tảng của người quản lí đự án là đảm bảo kiểm soát có hiệu quả các cam kết.

Điều này yêu cầu việc lập kế hoạch thích hợp theo cấp độ của việc được thực hiện. Thu được tài nguyên nhân lực, kĩ năng và xác định vòng đời nào, chuẩn nào, công nghệ nào và công cụ nào được dùng trong dự án và ước lượng lịch biểu tốt nhất, điều có thể được đáp ứng. Tất cả những điều này đều cần được làm tài liệu trong kế hoạch dự án nơi dự án được quản lí đúng tương ứng.

2) Thực hiện giám sát của cấp quản lí (tuyến sản xuất): Mọi tổ chức đều phải có người quản lí giám sát. Điều này bao gồm kiểm điểm và chấp thuận tất cả các kế hoạch dự án chính trước khi có cam kết chính thức về chúng. Kiểm điểm hàng tháng hay hàng quí phải được tiến hành, tại đó các cột mốc, cam kết lịch biểu, hiệu năng chất lượng, xu hướng chi phí được thảo luận và ánh xạ trở lại với chất lượng, thời gian, chi phí của tổ chức. Hành động sửa chữa phải được tiến hành khi các kế hoạch và thực tế khác biệt đáng kể.

3) Thực hiện trắc nghiệm đảm bảo chất lượng: Chức năng đảm bảo chất lượng được ban hành để đảm bảo với cấp quản lí rằng công việc phát triển phần mềm thực tế được thực hiện theo cách nó được giả định cần thực hiện.

Để hiệu quả, người thực hiện đảm bảo chất lượng phải có nhiều kinh nghiệm, được kính trọng trong môi trường nơi họ thực hiện việc trắc nghiệm của họ.

4) Thực hiện kiểm soát cấu hình: Kiểm soát những thay đổi trong phần mềm là nền tảng cho kiểm soát doanh nghiệp và tài chính cũng như cho sự ổn định kĩ thuật. Để phát triển phần mềm chất lượng theo lịch biểu dự kiến được, các yêu cầu phải được thiết lập và duy trì với sự ổn định hợp lí trong toàn thể vòng phát triển. Thay đổi bao giờ cũng xảy ra nhưng nó phải được quản lí và đưa vào hệ thống theo cách có trật tự. Trong khi thay đổi là bản chất, bằng chứng lịch sử chứng minh rằng nếu thay đổi không được kiểm soát, việc kiểm thử có trật tự là không thể được, và không mục tiêu chất lượng, lịch biểu, chi phí nào có thể được đáp ứng.

Hỏi: Hai năm trước, tổ chức của tôi đã được đánh giá ở CMMI mức 3. Từ đó chúng tôi đã KHÔNG làm gì cả. Chúng tôi có còn ở CMMI mức 3 hay không?

Đáp: Tổ chức của bạn cần có việc đánh giá để tìm ra xem liệu bạn vẫn còn ở mức 3 hay không. Mức độ trưởng thành chỉ là “cái nhìn” vào qui trình hiện thời vào lúc đánh giá, nếu tổ chức không liên tục cải tiến thì cơ may duy trì mức trưởng thành đó qua thời gian là rất mong manh. Nó có thể trở về CMMI mức 1 bây giờ.

Hỏi: SEPG của chúng tôi cứ áp đặt các qui trình mới mà họ phát minh ra và buộc chúng tôi tuân theo. Có phải cải tiến là buộc mọi người phải tuân theo qui trình “tư duy mong muốn” không?

Đáp: Cải tiến qui trình phần mềm không áp đặt các qui trình mới, nó chỉ đảm bảo rằng bạn có tất cả các qui trình cần để làm việc, và rồi cung cấp cho bạn hướng dẫn về cách cải tiến chúng. Giống như bất kì công nghệ mới nào, việc chấp thuận bất kì qui trình mới hay cải tiến nào đều yêu cầu cách tiếp cận gia tăng như thử nghiệm, thử chúng trên qui mô nhỏ, để xem cách nó làm việc trước khi làm nó theo qui mô lớn hơn. Việc áp đặt “giải pháp không được thử nghiệm” lên mọi người không phải là cách tiếp cận tốt. Nó tạo ra nhiều chống đối lại thay đổi và những nỗ lực không cần thiết. Có thể bạn cần nói lên ý kiến của mình cho người quản lí của bạn.

Hỏi: Mức độ trưởng thành cao hơn CMMI mức 4 yêu cầu Kiểm soát qui trình thống kê – Statistical Process Control (SPC) nhưng tôi nghĩ nó là một khái niệm được thiết kế cho chế tạo chứ không cho phần mềm. Tôi có đúng không?

Đáp: Kiểm soát qui trình thống kê – Statistical Process Control (SPC) đã chứng tỏ là ích lợi, hợp thức và áp dụng được cho kĩ nghệ phần mềm và các hoạt động quản lí như ước lượng chi phí phần mềm, quản lí dự án, lập lịch biểu, tuyển cán bộ, quản lí yêu cầu, thiết kế, giám định, kiểm thử, ước lượng chất lượng, làm mô hình và thầu khoán phần mềm, tạm nêu vài tên vậy. Trong khi đúng là việc hiểu về SPC trong phần mềm có lẽ là không thích hợp, và phần lớn là không đúng, vẫn có nhiều ví dụ và trường hợp nghiên cứu về các tổ chức rất trưởng thành được lợi từ kĩ thuật này.

SPC đã được dùng để xác định, ổn định hoá, và làm cải tiến lớn trong các qui trình của tổ chức. Nhiều người tin không đúng rằng SPC yêu cầu các qui trình được xác định và ổn định để thành công (điều mâu thuẫn với mục đích của việc dùng SPC như một cách để ổn định một qui trình đang bất ổn).

Phần lớn các tổ chức đã không kinh nghiệm hay xem SPC được dùng thành công bởi các tổ chức chưa trưởng thành không có nghĩa là nó không áp dụng được. (Có nhiều mức 4 và 5 trong công nghiệp). Tôi tin SPC không phải là một khái niệm trừu tượng mà là kĩ thuật đơn giản, mạnh đã được các kĩ sư và người làm thống kê dùng trong nhiều năm.

—-English version———–

CMMI-23

Question: How do I improve myself each year to be a better software person? I like to set goals in the New Year so I can follow. What do you advice?

Answer: While some people set their goals yearly, many software people do not know how and think goal setting is hard. Actually, it is easy if you understand software metrics. Like any business, software people must think about how we can get better each year and achieve our own individual potential. It starts with setting meaningful goals and development plans that support personal, business and the results that you hope to achieve with our customers. You must set goals and plans that stretch your abilities, challenge you and take you outside of your comfort zone to provide the greatest returns to your personal development. Of course, your goals should also support the business objectives for your team and business. I would start with the following:

1.      Start with the statement “I will”.

2.      Add action words. Use verbs such as “utilize” or “provide.” This gives a visual picture of what you intend to do.

3.      Add your expected result (what you are planning to accomplish) and make sure it is measurable.

4.      Make sure your goal can be tied to a specific business outcome.

5.      Talk with your manager about what it will look like to meet each goal.

6.      Get the support of key stakeholders.

When set goals, you need to pay attention that goals should be:

1.      Specific: State your goal in precise terms describing an outcome.

2.      Measurable: Describe how results can be measured using standards, specifications and milestones.

3.      Achievable: Make your goal achievable so that it is a challenge to accomplish rather than impossible to reach.

4.      Relevant: Align your goal with your work group or company goals and objectives.

5.      Time-phased: Include timely dates and milestones to keep you on course.

Understanding how you’re performing against your goals is important, too. The feed back you receive from your manager on an ongoing basis will help you redirect your efforts and let you know what you have to do to meet, and even exceed, expectations. Since you are working for a software company, it is important that you understand the company strategic goals, your team’s objectives as well as your responsibilities within the team and your competencies (knowledge, skills, and abilities). Remember that goals should focus on outcomes, not tasks and it is better to focus on a limited number of goals (e.g., three to seven goals).

Question: As we are improving software quality, what would be a desirable defect rate for Unite test, Integration test, System test and Acceptance test?

Answer: I have collected defect data for my research and found that when programmers develop software using a defined process they all have low Unit test defects, typically less than 5 defects per thousand lines of code (KLOC). During Integration test, the average is less than 1 defect per KLOC.  Defect in System test averages less than 0.5 defects per KLOC and delivered products have on average less than 0.1 defects per KLOC in User acceptance testing.

By following a defined process, programmers can remove at least 70% of the defects before the first compile. By analyze these data, I also found that 15% of errors are plain programming errors (e.g.. missing semicolons, ‘=’ not ‘==’, etc.)”. In my C++ programming class, I ask students to track this data and write them down in their personal notebook so they can see what kind of mistake they made as well as its frequency. By having this kind of awareness, most students improve their programming techniques significantly.

By interviewing project managers, I also found that by using good estimating process based on historical data, project managers can estimate with great accuracy the time, cost, schedule and quality for their projects and their average variances are: 15% on schedule, 23% on costs and 17% on efforts. These are evidences that software development following a software engineering process really provide quality products. The important in improvement is investing in a good training program.

Question: I want to become a good CMMI Lead appraiser. What kind of skills do I need? Please advice.

Answer: To become a good Lead CMMI Lead appraiser, you need to be:

1) A Crisis manager that can remain calm under significant stress;

2) A Software Engineer with several years of experience in project management, quality assurance, configuration management, software test and verification.

3) An Educator who can go beyond the academic understanding of models and be able to explain why things are important in the context of the organization;

4) A Change Agent who can help organizations focus not only on the appraisal, but also on the implementation as well.

5) A Business manager who understands and can explain the value of process improvement and metric in terms that senior managers can understand and relate this information to the business of the organization in the context of their strategic business goals; and

6) A Common-sense practitioner who can make sense out of an organization’s activities and translate the “development” mind-set of models into applicable terms that fit all projects, from development to maintenance which included block point release, migration activities, systems maintenance and management, and other creative endeavors.

In addition, you must be able to lead, guide, manage and control an analytical process that has as its key components an almost infinite variety of practices, implementation options, and organizational distractions.  And this is done with a team of four to seven unique individuals, representing thousands different personality combinations, interviewing approximately hundred different individuals, and asking questions regarding approximately at least 1200 sub practices over 316 practices in the CMMI within a 10 day period.  Sound so easy doesn’t it?

Question: What are the common mistakes people made when improving the software process?

Answer: Here is my favorite list of mistakes that people made:

1)    Appraisal now, commitment later: The organization jumps into conducting an appraisal to find out their CMMI maturity level before any management commitment is in place.

2)    Establishing Status Quo before budget run out: Without selection criteria, or identify the right person for the job, the organization named an “available person” as improvement leader who manage the SEPG before budget runs out.

3)    Continuously Debate without Acting: A team is formed to improve the software process but spend months after month in continuous discussion rather than deploy any improvement activities.

4)    Declare success before manager find out: Without any improvement, the team declare success and write a lengthy process document on what they have achieved then jump into another initiatives.

In the past 20 years, I found that many organizations express their wishes to improve software process but actually only want to do appraisal to found out about their maturity. Most of them are CMMI level 1 then when found out their willingness suddenly disappear. This is the wrong approach, waste of time and money and not what “Process improvement” really means.

Question: My organization tried to improve the software process without success.  We seem to get stuck at CMMI level 1 forever. What can we do differently?

Answer: There are many reasons for organization not improving: It could be the lack of management support, lack of an infrastructure to manage the improvement activities, or lack of skills to make the improvement happen.

Organization at CMMI level 1 can advance to level 2 by implement basic project controls as follows:

1) Implement project management disciplines: The fundamental role of a project manager is to insure effective control of commitments.

This requires adequate planning on the magnitude of the job to be done. Obtain adequate resources, skills and determine what life cycles, standards, technologies, and tools to use in the project and estimate the best schedule, which can be met. All of this needs to be documented in a project plan where project will be managed accordingly.

2) Implement Line management oversight: Every organization must have line management oversight. This includes review and approval of all major project plans prior to their official commitment. A monthly or quarterly review must be conducted where milestones, schedule commitments, quality performance, cost trends be discussed and mapped back to quality, time, cost, schedule goals of the organizations. Corrective actions must be taken when plans and actuals significantly differ.

3) Implement Quality assurance verification: A Quality assurance function is chartered to assure management that the software development work is actually done the way it is supposed to be done.

To be effective, people perform quality assurance must have a lot of experiences, well-respected in the environment where they perform their verification.

4) Implement Configuration control: Control of changes in software is fundamental to business and financial control as well as to technical stability. To develop quality software on a predictable schedule, the requirements must be established and maintained with reasonably stability throughout the development cycle. Changes will always happen but it must be managed and introduce to the system in an orderly way. While changes are essential, historic evidence demonstrated that if change is not controlled, orderly testing is impossible, and no quality, schedule, cost target can be met.

Question: Two years ago, my organization was appraised at CMMI level 3. Since then, we have NOT doing anything. Are we still at CMMI level 3 or not?

Answer: Your organization needs to have an appraisal to find out if you are still at level 3. A maturity level is only a “view” of the current process at the time of the appraisal, if organization does not continuously improve then the chance of maintaining that maturity level over time is very slim. It could return to CMMI Level 1 by now.

Question: Our SEPG kept impose new processes that they invented and force us to follow. Is improvement forcing people to follow a “wishful thinking” process?

Answer: Software process improvement does not impose new processes, it only insures that you have all of the processes needed to do the job, and then provides you with the guidance on how to improve them. Like any new technology, the adoption of any new or improve processes requires an incremental approach such as pilot, try them on a small scale, to see how it works before doing it in a larger scale. Imposing an “untested solution” on everybody is not a good approach. It creates more resistance to change and unnecessary efforts. Maybe you need to voice your opinion to your manager.

Question: The higher maturity CMMI Level 4 requires Statistical Process Control (SPC) but I think it is a concept designed for manufacturing not software. Am I correct?

Answer: Statistical Process Control (SPC) has proven to be useful, valid, and applicable to software engineering and management activities such as software cost estimation, project management, scheduling, staffing, requirements management, design, inspections, test, quality estimation, modeling and software subcontracting to name a few. While it is true that the understanding of SPC in software is probably inadequate, and largely incorrect, there are many examples and case studies of very mature organizations benefiting from this technique.

SPC has been used to define, stabilize, and make dramatic improvements in organization processes. Many incorrectly believe that SPC requires a defined and stable processes in order to be successful (Which contradict the purpose of using SPC as a way to stabilize an unstable process).

Just because most organization have not experienced or seen SPC used successfully by immature organizations does not mean it does not apply. (There are many levels 4 and 5 out there in the industry). I believe SPC is not an abstract concept but a simple, powerful technique that has been used by engineers and statisticians for years.