Hỏi: Tôi đã đọc một báo cáo nói rằng trên 70% tổ chức được đánh giá dùng CMMI đều thất bại khi thực hiện kế hoạch hành động cải tiến và chỉ 14% tổ chức đã thực hiện việc cải tiến của họ trong một năm, khá đủ để tiến hành việc đánh giá lại, chẳng thấy thay đổi hay cải tiến gì cả. Tại sao nhiều cải tiến qui trình lại thất bại thế?

Đáp: Tôi tin nhiều tổ chức thất bại bởi vì họ không tuân theo các pha cải tiến của mô hình IDEAL (Initiating – Khởi đầu, Diagnosing-Chẩn đoán, Establishing-Thiết lập, Acting-Hành động, và Leveraging-Thúc bẩy). Phần lớn đã bỏ qua pha Khởi đầu (Pha quan trọng nhất hội tụ vào việc thu được cam kết của cấp quản lí và thiết lập nhóm để cải tiến qui trình) và đi thẳng vào pha Chẩn đoán (Tiến hành đánh giá). Không có cam kết của cấp quản lí, mọi sự sẽ thất bại không đưa mọi người vào thực hiện kế hoạch hành để giải quyết các vấn đề gay cấn.

Tôi cũng tin rằng nhiều tổ chức thất bại bởi vì họ không có kĩ năng và kinh nghiệm cần thiết để thực hiện hành động cải tiến. Nhiều người nghĩ họ biết cách làm mọi sự xảy ra vì họ đã đọc sách, tham dự các xê mi na và có khả năng nói một cách thông minh về chủ đề này. Cải tiến qui trình là về thay đổi và thay đổi là gian nan, bạn không thể thay đổi được ai đó chừng nào bạn chưa thay đổi bản thân mình trước. Nếu bạn không dịch chuyển cái nhìn của mình lên mức cao hơn bạn không thể trợ giúp được cho bất kì ai dịch chuyển cái nhìn của họ. Đó là lí do tại sao đôi khi người tư vấn có thể có ích ở đây. Dựa trên kinh nghiệm của tôi, sau đây là một số lí do tại sao việc cải tiến qui trình thất bại, theo thứ tự ưu tiên:

1)     Không có cam kết dài hạn của cấp quản lí

2)     Thiếu kinh nghiệm và kĩ năng trong cải tiến qui trình

3)     Không có tầm nhìn rõ ràng về kết quả mong muốn

4)     Kế hoạch hành động quá tham vọng

5)     Không có phản hồi định lượng về tiến bộ (không đo)

6)     Diễn giải sai về CMMI

7)     Quá nhiều hội họp và thảo luận mà không hành động

8)     Văn hoá sai (thất bại nhiều lần trong quá khứ, sợ thay đổi)

9)     Người sai trong SEPG (quá nhiều thời gian dành cho làm tài liệu và không có thời gian để thực hiện)

10) Không phải tất cả mọi người đều tham gia vào quá trình thay đổi

Hỏi: Bao nhiên ngân sách cần dành cho việc cải tiến qui trình CMMI? Làm sao thầy chia nhỏ và biện minh cho nó được?

Đáp: Cải tiến qui trình điển hình là vào quãng 3%-5% ngân sách hàng năm. Nó có vẻ nhiều nhưng đó là đầu tư mà, nếu được thực hiện thành công, có thể đem lại lãi đáng kể. Đây là việc chia nhỏ ngân sách:

1) Bước đầu tiên cần bắt đầu là nhận biết về các hoạt động cải tiến. Mọi người bao giờ cũng muốn biết lí do (tại sao), qui trình (thế nào), mục tiêu (cái gì) và lộ trình nào (khi nào, ở đâu) mà họ phải theo. Cách tốt nhất để làm cho tất cả mọi người trong tổ chức nhận biết về các hoạt động là đào tạo họ về khuôn khổ CMMI.

“Nhập môn về CMMI” là lớp học được thiết kế cho hoạt động này. Xét tới kích cỡ của tổ chức điển hình có xấp xỉ 300 – 600 người, và từng lớp sẽ có xấp xỉ 60 người. Bạn cần lên lịch biểu ít nhất từ 5 tới 10 lớp cho tổ chức và cũng thiết lập nên một lớp đặc biệt cho cấp quản lí. (Họ cần biết về CMMI nữa.) Có chi phí liên kết với việc làm cho tất cả mọi người học một lớp; nhưng dựa trên dữ liệu tôi thu thập được từ 10 năm qua, đây là đầu tư rất tốt.

2) Bước thứ hai là thiết lập một nhóm toàn thời chuyên dành cho việc hỗ trợ hoạt động cải tiến. Cái tên thông thường nhất của nhóm này là Nhóm Qui trình Kĩ nghệ Phần mềm – Software Engineering Process Group, hay SEPG. Các thành viên của SEPG cũng cần được huấn luyện thêm để làm việc của họ, điều này cũng đòi hỏi tổ chức phải chi tiêu thêm ngân sách.

3) Bước thứ ba là trao đổi về mọi hoạt động cải tiến, thành tựu, độ đo, mục đích và mục tiêu. Điều này nên được thực hiện trên cơ sở đều đặn để giữ cho cấp quản lí và mọi người trong tổ chức được thông tin. Quản lí thay đổi yêu cầu trao đổi tốt về thay đổi, thừa nhận tiến bộ đã đạt được, và đo xem tổ chức đã cải tiến được đến đâu so với mục đích của mình. Hoạt động này cũng đòi hỏi thời gian và nỗ lực.

Cũng có chi phí liên kết với việc đánh giá, thiết lập kế hoạch hành động cải tiến, và thực hiện các hoạt động cải tiến. Phần lớn mọi người trong tổ chức sẽ tham gia vào những hoạt động cải tiến nào đó cùng với công việc hàng ngày của họ và nó cũng phải được tính cần nỗ lực và chi phí phụ thêm. Có chi phí liên kết với việc quản lí, theo dõi, thu thập dữ liệu, và đo tất cả những hoạt động cải tiến này nữa.

Như bạn có lẽ thấy, phần lớn chi phí đều được chi tiêu để đầu tư vào người của bạn, để huấn luyện họ, trao đổi với họ, đo việc thực hiện của họ, kiểm điểm công việc của họ, và vượt qua sự chống cự lại thay đổi. Đó là đầu tư chính cho tổ chức nhưng tôi thực sự tin nó đem lại phần thưởng trong tương lai.

 

Hỏi: “Tôi là một người quản lí phần mềm thành công nhưng sau khi dự xê mi na của thầy về kĩ nghệ phần mềm toàn cầu, tôi sợ tất cả những thay đổi đó đang xảy ra bây giờ.  Tôi nên làm gì để tiếp tục thành công của mình?

Đáp: Là người quản lí dự án, bạn có lẽ biết rằng nguyên tắc về quản lí đã không thay đổi trong nhiều năm nhưng công nghệ đã thay đổi vượt bực trong vài năm qua.  Cái nhìn truyền thống “Quản lí dự án mới cũng giống như chúng ta đã làm lần trước” không còn tác dụng thêm nữa. Đó là lí do tại sao người quản lí dự án phần mềm cần liên tục nhận diện và phân tích rủi ro. Để là người quản lí thành công, bạn có thể cần nhận biết về công nghệ thay đổi thường xuyên, cần linh hoạt với ý tưởng mới và thực sự thích ứng với cách thức mới về quản lí dự án phần mềm.

 

Hỏi: Tôi đã đọc sách CMMI nhiều lần và vẫn còn lẫn lộn về các thuật ngữ “chính sách, thủ tục, và chuẩn”.  Liệu CMMI có ngụ ý rằng “chuẩn” như thầy sẽ làm nó? “Thủ tục” như thầy sẽ làm nó và “chính sách” như thầy phải làm nó?

Đáp: Có nhiều cách để mô tả điều này. Cái nhìn cá nhân của tôi xác định cái gì sẽ xảy ra; nó là chỉ đạo từ quản lí cấp cao (tức là chính sách công ti). Chuẩn xác định chất lượng của điều sẽ xảy ra, còn thủ tục xác định cách nó sẽ xảy ra. Chính sách lập ra các trông đợi của tổ chức – rằng cách chúng ra làm mọi thứ ở đây. Chuẩn có xu hướng sản phẩm (cả về chức năng và chất lượng) – sản phẩm công việc kết quả sẽ như cái gì, còn thủ tục có xu hướng qui trình (thế nào) – một tập nhiều bước để làm cái gì đó.

 

Hỏi: Thầy nghĩ gì về quản lí cấp cao nói rằng vì hầu hết các công ti đã đạt được ISO 9001 trong vài tháng nên chúng ta cũng có thể có được CMMI mức 3 trong một năm? .

Đáp: ISO 9000 là chuẩn mức rất cao và áp dụng cho nhiều lĩnh vực (phần mềm, phần cứng, chế tạo v.v.) nhưng CMMI là rất chi tiết và hội tụ vào kĩ nghệ phần mềm. Vì ISO là chuẩn, nó giải quyết với câu hỏi chỉ có câu trả lời hai trị “có” và “không”, (hoặc bạn làm hoặc bạn không làm liệu bạn có kế hoạch, thủ tục hay tài liệu không). CMMI là khuôn khổ để cải tiến cho nên nó đề cập tới “thực hành kĩ nghệ phần mềm” như cái gì đó được dùng tương ứng với kế hoạch và nó tốt thế nào? Nó có được đo không? Nó có được trắc nghiệm và liên tục được cải tiến không?

Dựa trên dữ liệu thu thập của tôi, thời gian trung bình để chuyển giữa các mức là từ 24 tới 36 tháng cho nên điều đó còn tuỳ thuộc vào tổ chức của bạn được đánh giá ở mức nào để bạn có thể xác định sẽ mất bao lâu thời gian để lên mức 3.

Hỏi:  Trong xê mi na “Nhập môn CMM” mà thầy dạy tại CMU, thầy có nhắc rằng tài liệu qui trình nên vắn tắt, ngắn gọn, cỡ hai tới ba trang. Làm sao việc làm tài liệu qui trình có thể ngắn thế được? Chúng tôi đã dành nhiều tháng làm tài liệu cho một qui trình – vào quãng vài trăm trang, và chúng tôi vẫn chưa kết thúc. Chúng tôi có làm điều gì sai không?

Đáp: Làm tài liệu qui trình là bước đầu tiên để cải tiến qui trình đó. Do đó, điều rất quan trọng là tài liệu phải đơn giản và ngắn gọn bởi vì bạn sẽ cải tiến nó.

Bạn phải chống lại cám dỗ phát triển bất kì cái gì khác hơn là qui trình mức cao bởi vì đằng nào bạn cũng sắp thay đổi nó. Lời khuyên của tôi là giới hạn xác định qui trình vào vài nhiệm vụ then chốt và giữ nó không nhiều hơn hai tới ba trang giấy. Nếu bạn đặt giới hạn hai trang thôi, bạn sẽ khử bỏ đi mức chi tiết không cần thiết và không thích hợp. Cải tiến là quá trình tiến hoá mà có nghĩa là nó bắt đầu từ một thủ tục đơn giản để đảm bảo rằng mọi người dùng nó, đồng ý với nó, tuân theo nó, đo nó, cải tiến nó và duy trì nó. (Lập kế hoach-Thực hiện-Kiểm tra-Hành động – Plan, Do, Check, Act tới mức chi tiết mịn hơn). Trong nỗ lực đầu tiên, dừng đi vào nhiều chi tiết bởi vì bạn không biết qui trình bạn đang xác định thực tế có tác dụng không hay sẽ được mọi người dùng không? Qui trình tốt nên ngắn gọn, tới từng vấn đề, dễ đọc, và nó phải rõ ràng chỉ ra điều cần được hoàn thành. Chỉ khi mọi người dùng nó theo cách nhất quán thì bạn mới có thể thêm mức độ chi tiết vào (Đó là điều Mức 3 và 4 trong CMMI tất cả là gì).

Làm tài liệu cho điều đơn giản trước hết và bổ sung thêm mức chi tiết khi cần thiết là chìa khoá cho thành công trong cải tiến qui trình. Làm tài liệu cho cuốn sách khổng lồ mà không ai dùng sẽ thực sự là phí thời gian.

 

Hỏi: Tôi đã thấy nhiều công cụ được quảng cáo là cải tiến các mức độ trưởng thành CMMI. Tôi cũng gặp một số nhà tư vấn có công nghệ và khuôn mẫu có thể làm cho tổ chức đạt tới mức 5 trong vòng một năm. Sao chúng ta không lấy các công nghệ đó bây giờ?

Đáp: Mọi công nghệ mới bao giờ cũng tới cùng những hứa hẹn kì diệu. Đây là loại giải pháp đã tới theo nhiều hương vị như 4GLs, AI, CASE, RAD, OOP, DCE, và công nghệ Web. Ngược với huyền thoại phổ biến, những công nghệ này đã không đem lại cải tiến có ý nghĩa về phẩm chất, năng suất mà cộng đồng phần mềm tìm kiếm. Cải tiến qui trình là công việc gian nan và đòi hỏi cam kết dài hạn – không phải là cái gì đó có thể mua được từ nhà cung cấp trong “siêu thị công nghệ”.

Tôi tin rằng nhảy từ công nghệ này sang công nghệ khác, thay đổi từ công cụ này sang công cụ kia, là thủ phạm chính giữ chúng ta không đạt tới chính ích lợi mà chúng ta hi vọng đạt tới.

 

Hỏi: Tổ chức mức 1 của chúng tôi đã quyết định chấp nhận tổ chức qui trình chuẩn phần mềm từ tổ chức được thẩm định ở mức 3 và huấn luyện cho mọi người tuân theo qui trình đó. Việc đó có tăng tốc cải tiến của chúng tôi và thoả mãn các yêu cầu mức 3 không?

Đáp: Đây là một sai lầm thông thường mà tôi đã từng thấy nhiều công ti mắc phải: Tổ chức CMMI mức 1 vay mượn các qui trình từ tổ chức CMMI mức 3 hay đôi khi từ tổ chức CMMI mức 5 và hi vọng rằng họ có thể đạt tới mức đó. Liệu một học sinh phổ thông cơ sở có thể mặc quần áo của sinh viên đại học và có thể trở thành sinh viên đại học được không? Tôi đã thấy nhiều công ti mua các qui trình từ công ti mức cao rồi dành nhiều thời gian viết lại các qui trình đó thành qui trình riêng của họ, buộc mọi người phải tuân theo các qui trình đó, và tuyên bố thành công. Trưởng thành cần thời gian và không thể bị ép buộc theo cách đó được. Cho nên với loại công ti muốn tăng tốc trưởng thành của mình, tôi muốn hỏi:

• Làm sao bạn biết rằng các qui trình được nhận vào sẽ có tác dụng cho tổ chức của bạn?
• Qui trình được nhận vào đó có ích và có chấp nhận được cho người trong tổ chức của bạn không?
• Có bằng chứng về việc khi tuân theo qui trình được nhận vào đó, chất lượng, thời gian và chi phí dự án của bạn đã được cải thiện không?
• Tổ chức của bạn có dữ liệu chỉ ra rằng chất lượng sản phẩm của bạn, mối quan hệ với khách hàng, chỉ số thoả mãn của nhân viên, và mục đích nghiệp vụ là được thực hiện không?
• Bạn có tin bằng việc có các qui trình chuẩn được làm tài liệu, tổ chức của bạn tự động được cải thiện lên không?
• Bạn đang huấn luyện người dùng qui trình được nhận vào không? Hay bạn đang huấn luyện họ để cho họ có thể trả lời được những câu hỏi nào đó trong việc thẩm định?

Chừng nào qui trình chuẩn được nhận vào đó còn chưa thực sự được tích hợp vào cách tổ chức thực hiện nghiệp vụ, chừng nào mọi người còn chưa hiểu nó, chưa chấp nhận nó, chưa đón nhận việc huấn luyện để tuân theo nó, chưa dùng nó, chưa sửa đổi nó cho khớp với nhu cầu dự án của họ, chưa đo nó, chưa cải tiến nó theo cách họ xây dựng và bảo trì phần mềm – Chẳng cái gì sẽ thay đổi đâu.

Tôi tin sẽ là sai lầm mà ép buộc thay đổi lên các dự án bằng việc đem một qui trình bên ngoài vào thay cho việc phát triển qui trình từ bên trong và thiết lập việc huấn luyện dựa trên qui trình riêng của bạn.

Tôi cũng tin rằng cấp quản lí của bạn đã vi phạm vào khái niệm then chốt của CMMI: “Không nên nhảy qua các mức”. Tổ chức CMMI mức 1 nên hội tụ vào việc thiết lập môi trường quản lí có kỉ luật trước khi thiết lập các qui trình chuẩn xuyên qua toàn tổ chức. Một qui trình được xác định tốt từ một tổ chức CMMI mức 3 hay CMMI mức 5 chắc chắn là điều tốt, nhưng nó thường không có tác dụng tốt cho tổ chức CMMI mức 1. Làm cho tổ chức chấp nhận một qui trình chuẩn mới, có thương hiệu, dường như là logic, nhưng không đủ trong môi trường hỗn độn của CMMI mức 1. Bạn phải có huấn luyện và kỉ luật tại chỗ để đưa mọi sự vào kiểm soát bởi vì việc cải tiến qui trình bao gồm việc thay đổi cách mọi người làm nghiệp vụ và thay đổi thái độ của kĩ sư; đây là lí do tại sao điều then chốt là làm cho mọi người tham gia vào việc tạo ra qui trình chuẩn dựa trên những thực hành tốt nhất hiện có. Thay vì mua qui trình tốt, bạn nên dành thời gian huấn luyện cho người của mình về kĩ nghệ phần mềm, về các kỉ luật và nguyên lí để cho mọi người hiểu vai trò của mình, trách nhiệm của mình và điều họ cần để làm cho công việc của mình được thực hiện, đúng thời gian và có chất lượng. Xin đừng nhìn ra ngoài về cái gì đó mới như công cụ mới, qui trình mới, phần lớn những điều tốt đều đã có bên trong công ti bạn rồi, đó là người của bạn và tài năng của họ. Họ cần hướng dẫn, huấn luyện để làm việc của mình. Phần lớn những người phần mềm cần giúp đỡ trong kiểm soát yêu cầu, điều phối thay đổi, quản lí kế hoạch dự án, nhận diện những phụ thuộc tương hỗ, và giải quyết các vấn đề thiết kế hệ thống. Đây là chỗ người quản lí có thể thực sự giúp đỡ được bằng việc đưa ra quyền lãnh đạo.

Bởi vì công nghệ thay đổi quá nhanh, ít người phần mềm được chuẩn bị thích hợp để dùng các ngôn ngữ và công cụ mới họ được trao cho, cho nên mới có nhiều việc học bằng “thử và sai”, điều này thực sự là lãng phí thời gian và tiền bạc và thường bao gồm nhiều lỗi trước khi mọi sự sẽ có tác dụng. Huấn luyện có thể là đắt nhưng không đắt bằng KHÔNG huấn luyện. Tôi tin tưởng mạnh mẽ vào huấn luyện bởi vì việc học không bao giờ dừng lại cho nên thay vì mua qui trình CMMI mức 5, tổ chức của bạn phải đầu tư vào huấn luyện bởi vì đó là đầu tư tốt nhất vào cải tiến qui trình mà tôi biết tới và tôi biết rằng điều đó bao giờ cũng có tác dụng.

—-English version—-

 

CMMI-2

Question: I have read a report stated that over 70% of organization being appraised using CMMI  failed to execute an improvement action plan and only 14% of organization implemented their improvement over a year, far enough to conduct a re-assessment, found no change and no improvement. Why so many process improvements failed?

Answer: I believe many organizations failed because they do not follow the improvement phase of IDEAL model (Initiating, Diagnosing, Establishing, Acting, and Leveraging). Most skipped the Initiating phase (The most important phase that focus on obtaining management commitment and establish a group to improve the process) and go straight to Diagnosing phase (Conduct appraisal). Without management commitment, things will fall apart which lead to people not executing the action plan to solve critical issues.

I also believe that many organizations failed because they do not have the necessary skill and experience to implement improvement activities. Many people think they know how to make things happen since they have read books, attend seminars and be able to talk intelligently about the subject. Process improvement is about change and change is hard, you cannot change someone until you change yourself first. If you have not shift your view to a higher level you cannot assist anyone to shift their view. That is why sometime a consultant maybe helpful here. Based on my experience, following is some reasons why process improvement failed, in priority order:

1) No long-termed management commitment

2) Lack of experience & skill in process improvement

3) No clear vision of the desired results

4) Too ambitious action plan

5) No quantitative feedback on progress (No measurement)

6) Wrong interpretation of CMMI

7) Too many meetings and discussions and no action

8) Wrong culture (Failed several times in the past, fear of change)

9) Wrong people in SEPG (Too much time spent on document and no time to implement)

10) Not everybody participate in the change process

 

Question: How much budget should be set aside for CMMI process improvement? How do you break down and justify it?

Answer: Typical process improvement budget is about 3%-5% of the annual budget. It may sound like a lot but it is an investment that, if successfully implemented, can bring significant returns. Here is a breakdown of the budget:

1) The first step in getting started is the awareness of the improvement activities. People always want to know the reason (Why), the process (How), the objectives (What) and what roadmap (When, Where) that they must follow. The best way to have all people in the organization aware of the activities is educating them on the CMMI framework.

The “Introduction to CMMI” is a class designed for this activity. Consider the size of a typical organization which is approx. 300 – 600 people, and each class will hold approx. 60 people. You need to schedule at least 5 to 10 classes for the organization and also set up a special class for managers. (They need to know about the CMMI, too.) There are costs associated with having all people take a class; but based on the data that I collected from the past 10 years, this is a very good investment.

2) The second step is to establish a full-time group dedicated to support improvement activities. The most common name for this group is Software Engineering Process Group, or SEPG. The SEPG members also need additional training to do their job which also incurs additional cost to organization.

3) The third step is to communicate all improvement activities, achievement, measurements, goals and objectives.  This should be done on a periodic basis to keep management and people in the organization informed. Managing change requires good communication of the changes, acknowledgment of the progress made, and measurement of how far the organization has improved toward their goal. This activity also requires time and effort.

There are also costs associated with having an appraisal, establishing an improvement action plan, and the implement of improvement activities. Most people in organization will participate in some improvement activities along with their daily work and it also incurs additional effort and cost. There are costs associated with managing, tracking, collecting data, and measuring all improvement activities too.

As you probably see, most of the cost is spent on investing in your own people, to train them, communicate with them, measure their implementation, review their work, and overcome the resistance to change. It is a major investment for the organization but I really believe it does pay-off in the future.

 

Question: “I am a successful software manager but after attended your seminar on global software engineering, I was scared of all the changes happening now.  What should I do to continue my success?

Answer: As a project manager, you probably know that the principle for management has remained unchanged for many years but technology has changed radically in the past few years.  The traditional view “Manage new project just like we did last time” does not work anymore. That is why software project manager need to continuously identifying and analyzing risks. To be a successful manager you may need to be aware of the ever changing technology, be flexible for new idea and really adapting to the new way of managing software project.

 

Question: I have read the CMMI book several times and still confuse about the terms “Policy, procedure, and standard”.  Does the CMMI implies that “Standard” as you shall do it? “Procedure” as you will do it and “Policy” as you must do it?

Answer: There are many ways to describe this. My personal view is: Policy specifies what will happen; it is a direction from senior management (i.e. Company policy). A standard specifies the quality of what will happen, and procedure specifies how it will happen. A policy sets the expectations of the organization – That the way we do thing here. A standard is product-oriented (Both functional and quality) – what the resulting work product will look like, and procedure is process oriented (How) – A set of multiple steps for doing something.

 

Question: What do you think of a senior management stating that since most companies achieved ISO 9001 in a few months we can also get CMMI level 3 in a year? .

Answer: ISO 9000 is a very high level standard and applies to many domains (Software, Hardware, Manufacturing etc.) but CMMI is very detailed and focuses on software engineering. Since ISO is a standard, it deals with the binary question of “yes” and “No” answer only, (either you do or don’t whether you have a plan, a procedure or a document). The CMMI is a framework for improvement so it addresses “software engineering practices” as something being used according to a plan and how good is it? Is it being measured? Is it verified and continuing to be improved?

Based on my collected data, the average time to move between levels is 24 to 36 months so it depends on what level your organization is appraised at you can determine how long it will take to be level 3.

 

Question: In the “Introduction to CMM” seminar that you taught at CMU, you mentioned that process document should be brief, short, about two to three pages. How could a process document be that short? We are spending months to document a single process- about few hundred pages already, and we are not finish yet. Are we doing the wrong thing?

Answer:  To document a process is the first step to improve that process. Therefore, it is very important that the document be simple and brief because you are going to improve it.

You must resist the temptation to develop anything other than a high level process because you are going to change it anyway. My advice is to limit the definition of a process to a few key tasks and keep it to no more than two to three pages. If you set a two-page limit, you will eliminate the level of detail that is unnecessary and not appropriated. Improvement is a evolution process which means it starts from a simple process to ensure that everybody understand it, agree with it, use it, follow it, measure it, improve it and then maintain it. (Plan, Do, Check, Act to a finer level of detail). In the first attempt, do not go into much detail because you do not know the process you are defining will actually work or will be used by everybody? A good process should be short, to the point, easy to read, and it must clearly show what to be accomplished. Only when people use it in a consistent way then you can add more level of detail (That’s what Level 3 and 4 on the CMMI is all about).

To document the simple thing first and add more level of detail when necessary is the key to success in process improvement. To document a huge book that no body will use is really a waste of time.

 

Question: I have seen many tools advertised to improve CMMI maturity levels. I also met some consultant who has technologies and templates that can make an organization achieve level 5 within a year. Why don’t we obtain these technologies now?

Answer: Every new technology always comes with a wonderful promise. This kind of solution has come in many flavors such as 4GLs, AI, CASE, RAD, OOP, DCE, and Web technology. Contrary to popular myth, these technologies have not bought the significant improvement in quality, productivity so sought by the software community. Process improvement is hard work and requires long-term commitment – not something one can buy from vendors in a “technology super market”.

I believe that jumping from one technology to another, changing from this tool to that tool, is the main culprit for keeping us from achieving the very gains we hope to achieve.

 

Question: Our level 1 organization has decided to adopt the organization software standard process from an organization assessed at level 3 and train all people to follow that process. Will that accelerate our improvement and satisfy the level 3 requirements?

Answer: This is a common mistake that I have seen over and over: A level 1 organization borrows processes from a level 3 or sometime a level 5 and hope that they can make that level. They spent a lot of time re-write these processes into their own process, force people to follow that process, and declares success.

I would like to ask:

• How do you know that the adopted processes will work for your organization?
• Is the adopted process useful and acceptable to the people in your organization?
• Is there evidence that by following the adopted process, your project’s quality, time, and cost has improved?
• Does your organization have data to indicate that your product quality, customer relationship, employee satisfaction index, and business goals are realized?
• Do you believe by just having a documented standard your organization is automatically improving?
• Are you training people to use the adopted process? Or are you training them so they can pass certain questions during the assessment?

Unless the adopted standard process is really embedded in the organization’s culture, unless people understand it, accept it, receive training to follow it, use it, modify it to fit their project needs, measure it, improve it and institutionalize it as the way they build and maintain software – Nothing will ever change.

I believe it would be a mistake for the SEPG to force changes onto projects by bringing in an external standard process rather than to collect “best practices” from within and establish the standard process based on these best practices.

I also believe that your SEPG has violated the key concept of CMMI: “You shall not skip a level”. A level 1 organization should focus on establishing a disciplined project management environment before establishing standard processes across the organization. A well-defined process from a higher-level organization is surely a good place to establish a standard process, but it usually does not work well for a level 1 organization. Getting an organization to adopt a new standard process by providing training is good, but not sufficient nor effective in a chaotic environment. Improving the process involves changing the culture and the way people do things; this is where it is critical to get everybody participating in creating a standard process based on existing best practices.