CMMI-6

Hỏi: Là một tổ chức phần mềm, chúng tôi biết cách phát triển phần mềm và tin rằng chúng tôi ở mức cao trên thang CMMI, nhưng chính người dùng của chúng tôi mới cần giúp đỡ. Họ không biết điều mình cần và cứ thay đổi yêu cầu của mình mọi lúc. Họ cần CMMI hơn chúng tôi. Thầy nghĩ gì?

Đáp: Làm sao bạn biết rằng bạn ở mức cao trên thang trưởng thành mà không có thẩm định? Trách người dùng là hành vi điển hình của tổ chức ở mức trưởng thành 1. Hình dung ra điều người dùng muốn, chắc chắn rằng tổ phát triển hiểu các ưu tiên của người dùng, và thương lượng điều người dùng có thể có với điều họ muốn trả tiền mới thực sự là Lĩnh vực qui trình then chốt mức 2 – Quản lí yêu cầu tất cả là gì.

Có được hiểu biết rõ ràng về điều gì là quan trọng cho người dùng là điều bản chất trong doanh nghiệp phần mềm. Bạn cần biết rằng những người trả tiền cho sản phẩm của bạn muốn và đảm bảo rằng khách hàng hoàn được hoàn toàn thoả mãn bằng không họ có thể dẹp doanh nghiệp của bạn đi đâu đó khác. Tổ chức phần mềm thành công là tổ chức không chỉ tạo ra sản phẩm chất lượng mà còn đạt tới sự thoả mãn của khách hàng. Khi thực hiện cải tiến qui trình bạn không chỉ nhận diện bất kì vấn đề doanh nghiệp gay cấn nào mà còn đem cả qui trình phần mềm nội bộ của mình mở ra để cho bạn có thể tạo ra viễn kiến chia sẻ về cách các hệ thống được hoàn thành sẽ vận hành và hoạt động thế nào để thoả mãn người dùng. Tôi thực sự nghĩ tổ chức của bạn cần CMMI hơn người dùng của bạn.

Hỏi: Làm sao SEPG trợ giúp cho tổ chức để cải tiến qui trình của họ được? Họ có tuân theo qui trình không?

Đáp: SEPG tốt phải tuân theo qui trình đã được xác định. Khi một tổ chức yêu cầu hỗ trợ, các thành viên SEPG phải:

(1)       Họp với cấp quản lí của tổ chức để xác định cam kết với việc cải tiến qui trình. Nhận diện chiều hướng, mục đích doanh nghiệp, nhu cầu tổ chức, mong đợi và lịch biểu.

(2)       Tạo ra nhận biết cải tiến qui trình cho toàn tổ chức (kể cả cấp quản lí). Giải thích rõ ràng từng bước của lộ trình (mô hình IDEAL) và cung cấp thông tin về sự khẩn thiết phải cải tiến (Tại sao chúng ta cần cải tiến) mong đợi từ cấp quản lí (Cải tiến chất lượng và giảm chi phí v.v.) và nhận diện mọi vấn đề gay cấn bên trong tổ chức.

(3)       Hỗ trợ cho tổ chức thành lập ban chỉ đạo để chỉ đạo và quản lí các hoạt động cải tiến qui trình. Giải thích rõ ràng vai trò và trách nhiệm của từng thành viên (Cung cấp chỉ đạo, ngân quĩ, tài nguyên và giám sát các hoạt động cải tiến) và mong đợi của quản lí cấp cao (Giảm chi phí, cải tiến chất lượng, đạt tới mức trưởng thành v.v.)

(4)       Hỗ trợ cho tổ chức trong việc thiết lập kết cấu nền cho cải tiến qui trình. (Nhóm SEPG hay tổ công tác thực hiện các hoạt động cải tiến.) Điều này rất quan trọng vì phần lớn mọi người được phân công thực hiện các hoạt động cải tiến đều phải được huấn luyện và hiểu vai trò của họ bên trong tổ chức.

(5)       Trợ giúp cho tổ chức lựa chọn thành viên tổ thẩm định. Đây là những người làm việc với dự án phần mềm, ưa chuộng hơn cả là người quản lí dự án hay người lãnh đạo dự án, người hiểu các vấn đề gay cấn bên trong tổ chức.

(6)       Cung cấp huấn luyện thẩm định cho tổ thẩm định.

(7)       Lãnh đạo việc thẩm định để nhận diện những điểm mạnh và yếu của tổ chức. (Thẩm định điển hình nên diễn ra quãng hai tới ba tuần, tuỳ theo kích cỡ của tổ chức)

(8)       Tóm tắt cho tổ chức về các phát kiến của thẩm định và các khuyến cáo. (Thành viên quản lí cấp cao và ban chỉ đạo cũng như cấp quản lí phải có mặt trong buổi tóm tắt và cho ý kiến chỉ đạo và bình luận về kết quả thẩm định và nhấn mạnh vào cam kết của họ với việc cải tiến qui trình)

(9)       Trợ giúp cho tổ thẩm định về hành động lập kế hoạch cho cải tiến qui trình. (Việc lập kế hoạch hành động điển hình không nên mất hơn một tuần để hoàn tất)

(10)    Trợ giúp cho tổ chức thiết lập tuyến cơ sở cách đo (tức là lập kế hoạch cách đo).

(11)    Cung cấp huấn luyện về thực hiện các nhiệm vụ cải tiến.

(12)    Tạo điều kiện thuận lợi cho việc điều phối các nhiệm vụ cải tiến trên cơ sở hàng tháng.

(13)    Liên tục hỗ trợ cho tổ chức về cải tiến qui trình qua huấn luyện, tư vấn, và đo, và tạo điều kiện cho việc chia sẻ “Thực hành tốt nhất”

(14)    Cung cấp phản hồi cho cấp quản lí.

(15)    Thúc bẩy thành công và chia sẻ về “Thực hành tốt nhất” trong toàn tổ chức.

Để thành công, các thành viên SEPG phải có kỉ luật tự giác và xu hướng qui trình bởi vì họ là mô hình vai trò cho người hành nghề phần mềm. Nếu họ không tuân theo qui trình đã xác định làm sao họ có thể thuyết phục được người khác làm cùng điều đó?

Hỏi: Tổ chức của chúng tôi muốn cải tiến qui trình nhưng người quản lí cấp cao của chúng tôi không muốn chi tiền cho điều đó. Làm sao chúng tôi có thể cải tiến được kĩ năng của mình nếu người quản lí không muốn trả tiền cho huấn luyện?

Đáp: Nếu người quản lí cấp cao của bạn có mối quan tâm tới cải tiến tổ chức của bạn, họ sẽ trả tiền cho việc huấn luyện thêm về kĩ năng và tri thức. Nếu họ từ chối trả tiền thì họ không nghiêm chỉnh với việc cải tiến. Bạn có thể nhắc họ rằng cải tiến là “chi phí căn bản của chất lượng”:

(1)   Những người hài lòng về việc phát triển nghề nghiệp của mình đều muốn ở lại với tổ chức.

(2)   Việc luân chuyển nhân viên cao dẫn tới cả năng suất và chất lượng đều thấp, tác động tương ứng tới chi phí cao.

(3)   Huấn luyện là việc gia tăng giá trị bởi vì nó làm tăng kĩ năng của mọi người làm việc

Tôi không thể thấy được làm sao một tổ chức muốn cải tiến mà người quản lí cấp cao lại không muốn chi tiền cho huấn luyện. Cấp quản lí nên hỏi câu hỏi “Chúng ta cần gì để cải tiến doanh nghiệp của mình, để sản xuất ra sản phẩm tốt hơn, nhanh hơn và nắm được thị trường”. Theo ý kiến của tôi, bạn có thể hỏi liệu đây là công ti tốt để mình làm việc không vì người quản lí của bạn dường như không tin vào cải tiến và từ chối trả tiền cho huấn luyện kĩ năng.

Hỏi: Tại sao chúng ta cần các mức độ trưởng thành phần mềm? Ích lợi tài chính là gì cho việc ở mức 3?

Đáp: CMMI đặc trưng cho tổ chức phần mềm theo năm mức trưởng thành, từ mức 1 tới mức 5 với mức 1 là thấp nhất và mức 5 là cao nhất. Từng mức chỉ phục vụ như cột mốc trong cuộc hành trình cải tiến lâu dài. Có những ích lợi có nghĩa nếu tổ chức cải tiến qui trình phần mềm của mình để đạt tới mục đích doanh nghiệp như hạ thấp chi phí phần mềm, tăng chất lượng phần mềm và thị phần. Dựa trên dữ liệu tôi đã thu thập trong vài năm qua, chất lượng phần mềm về căn bản cải tiến quãng 20% cho từng mức độ trưởng thành và chi phí phần mềm có thể được giảm đi quãng 60% giữa mức 1 và 3. Mức độ trưởng thành là chỉ báo và nó chỉ có nghĩa nếu bạn gióng thẳng với mục đích doanh nghiệp bằng không nó chỉ là con số vô nghĩa.

Hỏi: Với tôi dường như là nhiều người không muốn thay đổi hay làm việc vì khác với điều họ đã làm. Sao mọi người chống lại thay đổi? SEPG có thể làm được gì để thay đổi xảy ra?

Đáp: Phần lớn mọi người không thích thay đổi. – Một khi chúng ta học cái có tác dụng, chúng ta dính vào nó. Đó là phần nền tảng của bản tính người. Chúng ta nhập tâm các qui trình cá nhân của mình và chúng trở thành thói quen của chúng ta và kĩ năng của chúng ta. Điều đó cũng giống như cách chúng ta ăn, ngủ, đi, nói. Thay đổi là khó, thường đe doạ và đau đớn, và khi không bị vấn đề khẩn cấp nào đó, chúng ta thường bám dính lấy cách thức cũ và chỉ thay đổi chút ít khi được cần tới. Hàng thế kỉ trước đây, Plato, một triết gia Hi Lạp đã nói: “Nếu nhiều đau đớn được liên kết với thay đổi hơn trong việc để mọi thứ không đổi, thay đổi sẽ không xảy ra.”

Thách thức lớn nhất cho Nhóm qui trình kĩ nghệ phần mềm Software Engineering Process Group (SEPG) là vượt qua sự chống cự lại thay đổi này. SEPG không chỉ phải đem thay đổi tới cho tổ chức, mà các thành viên tổ còn phải sẵn lòng thay đổi thói quen riêng của họ và học chấp nhận cách thức mới làm doanh nghiệp. Chúng ta phải sẵn lòng làm điều chúng ta muốn người khác làm. Nhìn vào trong và thay đổi bản thân mình là chìa khoá cho thành công. Dễ nhìn cách người khác phải thay đổi nhưng không dễ nhìn cách chúng ta phải tự thay đổi mình.

Vì nhiều thành viên tổ SEPG làm việc một phần thời gian cho các nhiệm vụ cải tiến, được có chọn lựa giữa các công việc dự án như thiết kế, lập trình và cải tiến tổ chức, mọi người có xu hướng tắt các nhiệm vụ cải tiến lâu nhất có thể được. Tôi biết một số thành viên SEPG có thể coi các hoạt động cải tiến là quan trọng, nhưng chúng không cấp thiết, do vậy chúng thường bị quên lãng. Nếu tình huống này mà được phép tiếp tục, và không có hậu quả gì cho các nhiệm vụ cải tiến không được thực hiện, chung cuộc mọi nhiệm vụ cải tiến sẽ bị cảm nhận như không quan trọng và cuối cùng bị bỏ qua.

Thách thức lớn nhất cho SEPG là thay đổi cách mọi người đáp ứng với các hoạt động hàng ngày, và bắt đầu đặt sự lành mạnh tương lai của nó khá xa trước đòi hỏi ngắn hạn. SEPG cần chứng tỏ cam kết của mình làm công việc chuẩn bị từ trước như lập kế hoạch, huấn luyện và động viên người khác trước khi yêu cầu những người hành nghề phần mềm trì hoãn viết mã cho tới khi họ đã hoàn thành các yêu cầu và đặc tả thiết kế.

Sau nhiều năm quản lí cải tiến qui trình, tôi đã quan sát đa dạng hành vi như sau:

(1)                   Thách thức và yêu cầu khẩn thiết về đặt ưu tiên cao hơn đối với các nhiệm vụ cải tiến thường được đáp ứng với những cái cớ hay ho và dửng dưng từ những người hành nghề phần mềm.

(2)                   “Bài nói và bài giảng” của cấp quản lí là tốt về tinh thần, nhưng chúng không làm cho nhiệm vụ cải tiến được thực hiện nhanh hơn.

(3)                   Trong một số tổ chức, cấp quản lí thường phân công cho các thành viên của SEPG làm việc về những hoạt động cải tiến nhưng họ lại không thay đổi ưu tiên hay độ khẩn thiết nào, cho nên hành vi của các thành viên SEPG cũng chẳng thay đổi mấy.

(4)                   Một số tổ chức lập ra cách tiếp cận “Tổ chuyên trách” nơi những người hành nghề phần mềm sẽ thay đổi luân phiên là “thành viên chuyên trách”, người dành phần lớn thời gian của họ để làm việc với các hoạt động cải tiến qui trình. Trong khi đó là ý tưởng tốt, chẳng ai cảm thấy họ có thời gian để làm “thành viên chuyên trách”.

(5)                   Một số tổ chức có kế hoạch cải tiến với các nhiệm vụ và lịch biểu, mà SEPG kiểm điểm chúng một lần một tháng. Mặc dầu đây là qui trình được xác định tốt, phần lớn những người hành nghề đều đặn giải thích rằng ưu tiên khác lấy mất thời gian dành cho nhiệm vụ cải tiến của họ và lịch biểu bao giờ cũng bị trễ.

Có năm yếu tố quan trọng có thể làm cho thay đổi xảy ra. Thiếu bất kì yếu tố nào cũng sẽ không cho bạn kết quả mong muốn. Bảng logic sau giúp minh hoạ cho tình huống này: (  ______ chỉ ra yếu tố thiếu)

Viễn kiến + Kĩ năng + Khuyến khích + Tài nguyên + Kế hoạch hành động    = Thay đổi

________ + Kĩ năng + Khuyến khích + Tài nguyên + Kế hoạch hành động   = Lẫn lộn

Viễn kiến + _______ + Khuyến khích + Tài nguyên + Kế hoạch hành động = Lo âu

Viễn kiến + Kĩ năng + __________+ Tài nguyên + Kế hoạch hành động = Thay đổi chậm

Viễn kiến + Kĩ năng + Khuyến khích + _______ + Kế hoạch hành động  = Thất vọng

Viễn kiến + Kĩ năng + Khuyến khích + Nhân lực + ________________  = Bắt đầu sai

Nhiều người nghĩ rằng yếu tố thiếu hiển nhiên nhất là tài nguyên (tức là con người & thời gian), nhưng sau nhiều năm quản lí cải tiến qui trình tôi thấy rằng yếu tố thiếu thực sự là khuyến khích thực tế. Được cho đủ khuyến khích, mọi người sẽ dành thời gian của họ để làm công việc cải tiến, do vậy cung cấp tài nguyên thiếu.  Một yếu tố quan trọng khác là vai trò và trách nhiệm của cấp quản lí. Được cho đủ khuyến khích, cấp quản lí sẽ dành nhiều thời gian hơn để điều phối các hoạt động cải tiến và lấy hành động cần thiết để làm nó làm việc và cải tiến doanh nghiệp.

Với các nhân tố này được nhận diện, tôi đề nghị các qui tắc sau để giúp tổ chức thực hiện hoạt động cải tiến hiệu quả hơn:

(1)       Mọi thành viên của SEPG phải hiểu bản lộ trình IDEAL (năm pha) của cái tiến qui trình và tuân theo chúng chặt chẽ nhất có thể được. Đặc biệt Pha khởi đầu nơi cấp quản lí cam kết và kết cấu nền của SEPG dành cho cải tiến được nhận diện. SEPG phải có cam kết từ cấp quản lí rằng nhiệm vụ cải tiến phần mềm sẽ được coi như có ưu tiên ngang với phát triển sản phẩm phần mềm. SEPG sẽ được cấp quản lí trao đảm nhiệm hoàn thành những dự án cải tiến này.

(2)       Cấp quản lí nên chỉ ra rằng nhiệm vụ cải tiến là rất quan trọng và phải được thực hiện không chậm trễ nào.  Bên cạnh việc hỗ trợ nhiệm vụ cải tiến bằng tài nguyên, thời gian, và khuyến khích, cấp quản lí phải đặt ra trông đợi rõ ràng, điều phối tiến bộ, và nhấn mạnh hiệu năng.

(3)       Tất cả các nhiệm vụ cải tiến qui trình đều phải được người quản lí kiểm điểm và nâng lên cùng mức như các công việc phần mềm khác, do vậy cung cấp khuyến khích cần thiết để tạo ra thay đổi văn hoá mong muốn.

Về tổng thể, SEPG phải thừa nhận rằng nhiệm vụ đầu tiên của nó là tự thay đổi mình. Vậy thì nó có thể lãnh đạo tổ chức trên cuộc hành trình lớn lao hơn của cải tiến qui trình.

Nhiệm vụ cải tiến phần mềm phải không kém quan trọng, không kém khẩn thiết hơn là công việc phát triển sản phẩm của tổ chức. Bằng không, việc cải tiến sẽ chẳng bao giờ được thực hiện.

Không chỉ cần có hỗ trợ của cấp quản lí mà việc tăng cường quan tâm tiếp diễn của cấp quản lí mới là chìa khoá để thuyết phục các thành viên SEPG, và người hành nghề phần mềm rằng thay đổi là TỐT.

Hỏi: Quản lí rủi ro là gì? CMMI có phải là mô hình quản lí rủi ro không?

Đáp: Trong môi trường nhiều khủng hoảng, nhiều người quản lí thường tập trung vào các vấn đề kĩ thuật và mất cái nhìn về tầm quan trọng của tư duy chiến lược và ra quyết định. Quản lí rủi ro là cách tiếp cận hệ thống tới việc ra quyết định chiến lược trong khi giải quyết khủng hoảng. Nó làm cho các quyết định có am hiểu bằng việc liên tục thẩm định điều có thể đi sai và hành động dựa trên tính có thể và tác động của nó. Để thành công, người quản lí phải làm việc chọn lựa có am hiểu về các cơ hội trong sự không chắc chắn hay điều kiện rủi ro. Những thực hành quản lí rủi ro hiện thời chủ yếu là không thể thức hay bị coi như chỉ từng lúc một. Tuy nhiên, rủi ro không tĩnh mà động trong toàn bộ vòng đời dự án. Người quản lí thành công bao giờ cũng canh chừng rủi ro và hành động tương ứng. CMMI thực sự là mô hình quản lí rủi ro dựa trên giả định là tổ chức càng trưởng thành, có kỉ luật thì càng có thể làm giảm rủi ro tốt hơn là tổ chức chưa trưởng thành.

Hỏi: Chúng tôi lập kế hoạch dự án xây dựng công cụ kiểm thử. Chúng tôi đã tìm loại công cụ này bên ngoài công ti, nhưng không tìm thấy cái gì đích xác khớp với nhu cầu của chúng tôi. Quan điểm của thầy là gì về việc làm hay mua? Thầy có khuyến cáo gì không?

Đáp: Khuyến cáo của tôi là MUA, MUA, và MUA. Sẽ không bao giờ có “công cụ hoàn hảo” cho mọi môi trường. Phần lớn các tổ chức thực hiện phân tích bù trừ và ra quyết định dựa trên đó công cụ nào khớp nhất với nhu cầu của họ. Việc phát triển công cụ thường tốn chi phí đáng kể và lịch biểu bị quá hạn; phần lớn các dự án phát triển công cụ không tuân theo qui trình được xác định rõ và người sai được chọn vào để phát triển công cụ. Có hàng trăm công cụ kiểm thử trên thị trường và một số trong chúng có thể thoả mãn cho nhu cầu của tổ chức của bạn.

Tuy nhiên, nếu bạn phải xây dựng, đây là khuyến cáo của tôi:

(1)     Nhấn mạnh vào lập kế hoạch dự án, lập ngân sách và theo dõi chính thức.

(2)     Sử dụng đặc tả hình thức cho công cụ.

(3)     Sử dụng quản lí cấu hình phần mềm chặt chẽ.

(4)     Lựa cẩn thận cán bộ phát triển.

(5)     Nhấn mạnh vào ngày tới hạn, ít nhất là một tháng trước khi công cụ được cần tới.

(6)     Đảm bảo sự tham gia của người dùng cuối vào qui trình này.

Hỏi: Trong nhiều năm, người lập trình máy tính đã từng lập trình mà không có vấn đề gì. Sao chúng ta cần kĩ nghệ phần mềm?

Đáp: Ngày xưa, phần lớn chương trình phần mềm đều nhỏ và vài người lập trình có thể lập trình và gỡ lỗi chẳng có vấn đề gì mấy. Tuy nhiên, kích cỡ phần mềm đã tăng lên đáng kể trong vài năm qua và chúng ta cần nhiều người lập trình hơn để phát triển phần mềm và vấn đề bắt đầu với việc thiếu trao đổi và phối hợp giữa họ. Ngày nay, sản phẩm phần mềm có nhiều lỗi và dự án phần mềm bị chậm hầu hết thời gian. Chúng ta không thể tiếp tục cách truyền thống “Viết mã rồi sửa lỗi” như chúng ta vẫn làm thêm được nữa mà chúng ta cần một cách tiếp cận có kỉ luật và nó được gọi là kĩ nghệ phần mềm. Người kĩ sư phần mềm không chỉ lập trình mà còn tham gia vào mọi khía cạnh của qui trình phát triển phần mềm, từ thu nhận yêu cầu, kiến trúc hệ thống, thiết kế sản phẩm, viết mã, kiểm thử và đưa ra.

Hỏi: Sự khác biệt giữa tài liệu yêu cầu và tài liệu thiết kế là gì và tại sao chúng phải được làm tài liệu?

Đáp: Yêu cầu phần mềm làm tài liệu về nhu cầu của người dùng, nó giải quyết về điều là “chấp nhận được” cho người dùng. Thiết kế phần mềm giải quyết với điều là “đạt tới được” qua việc ứng dụng công nghệ. Yêu cầu bao giờ cũng phải được làm tài liệu bởi vì người dùng thường đổi ý của họ, không có tài liệu làm tuyến cơ sở, bạn không thể kiểm soát được thay đổi yêu cầu. Yêu cầu là nền tảng để thiết kế được dựa lên, không có cơ chế kiểm soát xác định rõ tại chỗ bạn không thể theo dõi được dấu vết nguồn gốc của thiết kế hay điều xảy ra cho sản phẩm phần mềm trong khi phát triển.

Hỏi: Tại sao lại hội tụ vào chất lượng khi mục đích tối thượng của doanh nghiệp là tạo ra sản phẩm phần mềm?

Đáp: Mục đích của doanh nghiệp phần mềm không phải là tạo ra sản phẩm mà là nhu cầu về nó.

Sản phẩm phần mềm vẫn là một cơ hội tiềm năng không có giá trị nào chừng nào chưa có nhu cầu về nó hay ai đó sẵn lòng trả tiền cho nó. Khách hàng xác định doanh nghiệp gì và cái gì là chất lượng khách hàng cảm nhận như thuộc tính tốt mà họ sẵn lòng trả nhiều tiền cho nó. Chất lượng không phụ thuộc vào việc sản xuất ra nó phức tạp hay tốn kém thế nào mà vào cách khách hàng chấp nhận và sẵn lòng trả tiền cho nó.  Trong kinh doanh, khách hàng là mọi thứ.

—–English version——

Question: As a software organization, we know how to develop software and believe that we are at a high level on the CMMI scale, but it is our users that need help. They do not know what they want and keep changing the requirements all the time. They need the CMMI more than us. What do you think?

Answer: How do you know that you are at a high level on the maturity scale without an assessment? Blaming users is a typical behavior of a level 1 maturity organization. Figuring out what users want, making sure that the development team understands user’s priorities, and negotiating what users can have for what they want to pay is really what level 2 Key Process Area – Requirements Management – is all about.

Getting a clear understanding of what is important to the user is essential in the software business. You need to know that the people who pay for your product want and ensure that the customer is totally satisfied or they may take their business elsewhere. A successful software organization is the organization not only produce quality product but also achieves user satisfaction. When implementing process improvement you are not only identifying any critical business issues but also bringing out your internal software process to the open so you can create a shared vision of how the completed systems should function and operate to the satisfaction of users. I really think your organization need the CMMI more than your users.

Question: How does SEPG assist the organization to improve their process? Do they have to follow a process too?

Answer: A good SEPG must always follow a defined process. When an organization requests for support, SEPG members should:

(1)            Meet with organization management to determine commitment to process improvement. Identify direction, business goals, organization needs, expectations and schedule.

(2)            Create a process improvement awareness for the entire organization (including management). Clearly explain each step of the roadmap (IDEAL model) and provide information about the urgency to improve (Why do we need to improve) expectations from management (Improve quality and reduce cost etc.) and identify any critical issues within the organization.

(3)            Assist the organization to form a steering committee to direct and manage process improvement activities. Clearly explain role and responsibilities of each members (Provide direction, funding, resources and oversight of improvement activities) and senior management‘s expectations (Reduce cost, improve quality, achieve maturity level etc.)

(4)            Assist the organization in establishing an infrastructure for process improvement. (The local SEPG group or working team to implement improvement activities) This is very important since most people assigned to implement improvement activities must be trained and understand their roles within the organization.

(5)            Assist the organization to select assessment team members. These are people who work on software project, prefer to be project manager or project leader who understand critical issues within the organization.

(6)            Provide assessment training to the assessment team.

(7)            Lead the assessment to identify strengths and weaknesses of the organization. (A typical assessment should take about two to three weeks, depend on the size of the organization)

(8)            Brief the organization on assessment findings and recommendations. (Senior management and steering committee members as well as management must be present during the briefing and provide direction and comment on the assessment results and to emphasize their commitment to process improvement)

(9)            Assist the assessment team on planning action for process improvement. (A typical action planning should not take more than 1 week to complete)

(10)         Assist the organization to establish a measurement baseline (i.e., measurement planning).

(11)         Provide training on the implementation of improvement tasks.

(12)         Facilitate the monitoring of improvement tasks on a monthly basis.

(13)         Continue to support organizations on process improvement via training,   consulting, and measuring, and facilitate the sharing of “Best practices”

(14)         Provide feedback to management.

(15)         Leverage successes and sharing of “Best practices” throughout the organization.

To be successful, SEPG members must be self-disciplined and process-oriented because they are the role-model for the software practitioners. If they do not follow a defined process how could they convince others to do the same?

Question: Our organization wants to improve the process but our senior manager does not want to pay for it. How can we improve our skills if the manager does not want to pay for training?

Answer: If your senior manager has an interest in an improvement of your organization, they would pay for additional training in skills and knowledge. If they refuse to pay then they are not serious about improving. You may want to remind them that improvement is a “basic cost of quality”:

(1)            People who are happy about their professional development are likely to stay with the organization

(2)            High employee turnover leads to both low productivity and quality, with a correspondent impact of high cost

(3)            Training is value-added because it increases the skill of the people doing the work

I cannot see how an organization want to improve but senior manager does not want to pay for training. Management should ask the question “What do we need to improve our business, to produce better, faster product and capture the market”. In my opinion, you may want to ask whether this is a good company to work for since your manager does not seem to believe in improvement and refuses to pay for skill training.

Question: Why do we need software maturity levels? What are the financial benefits of being level 3?

Answer: The CMMI characterizes software organization into 5 levels of maturity, from level 1 to level 5 where 1 is the lowest and 56 is the highest. Each level only serves as a milestone in the long improvement journey. There are significant benefits if an organization improves its software process to achieve business goals such as lower software cost, increase software quality and market share. Based on the data that I have collected in the past several years, software quality typically improves about 20% for each maturity level and software cost can be reduced about 60% between level 1 and 3. A maturity level is an indicator and it only has meaning if you align it with a business goals or else it is only a meaningless number.

Question: It seems to me that many people do not want to change or do anything differently from what they have done. Why do people resist change? What can a SEPG do to make change happen?

Answer: Most people do not like to change. – Once we learn what works, we stick with it. It is a fundamental part of human nature. We internalize our personal processes and they become our habits and our skills. It is like the way we eat, sleep, walk or talk. Changing is difficult, often threatening and painful, and in the absence of some urgent matters, we usually stick with the old ways and only change a little bit as needed. Centuries ago, Plato, a Greek philosopher said: “If more pain is associated with a change than in leaving things unchanged, the change will not take place.”

The greatest challenge for a Software Engineering Process Group (SEPG) is to overcoming this resistance to change. Not only must the SEPG bring change to the organization, but also team members must be willing to change their own habit and learn to adopt new ways of doing business. We must be willing to do what we want other people to do. Looking inward and changing ourselves is a key to success. It is easy to see how others must change but it is not easy to see how we must change ourselves.

Since many SEPG team members work part-time on improvement tasks, given a choice between project works such as designing, programming and improving the organization, people tends to put off improvement tasks as long as possible. I know some SEPG members may regard improvement activities are important, but they are not urgent, thus they are often neglected. If this situation is allowed to continue, and there are no consequences for improvement tasks not being done, eventually all improvement tasks will be perceived as unimportant and eventually ignored.

The biggest challenge for the SEPG is to change the way people responds to the day to day activities, and begin to put its future well-being ahead of short term demands. The SEPG needs to demonstrate its own commitment to do up-front work such as planning, training and motivating others before asking software practitioners to delay coding until they have completed the requirements and design specifications.

After many years of managing process improvement, I have observed a variety of behaviors as follows:

(1)                   Challenges and pleas to give higher priority to improvement tasks were often met with indifferent and good excuses from software practitioners.

(2)                   Management “Talks and lectures” were good for morale, but they did not get the improvement tasks done any faster.

(3)                   In some organizations, management often gives SEPG members assignment to work on certain improvement activities but they did not change any priorities or urgencies, so the SEPG member’s behavior did not change much.

(4)                   Some organizations establish a “Dedicated team” approach where software practitioners would rotate as “Dedicated members” who would spend most of their time to work on process improvement activities. While it was a good idea, nobody felt they had the time to be a “Dedicated member”.

(5)                   Some organizations have improvement plans with tasks and schedule, which the SEPG reviews once a month. Although this is a well defined process, most practitioners regularly explain that other priorities took time away from their improvement tasks and the schedule is always delayed.

There are five important elements that can make change happen. Missing any will not give you the desired result. The following logical table helps to illustrate the situation: (______ indicates a missing element)

Vision + Skills + Incentive + Resources + Action plan    = Change

_____ + Skills + Incentive + Resources + Action plan   = Confusion

Vision + _____ + Incentive + Resources + Action plan = Anxiety

Vision + Skills + ______+ Resources + Action plan = Slow change

Vision + Skills + Incentive + _______ + Action plan = Frustration

Vision + Skills + Incentive + Resources + _________= False start

Many people think that the most obvious missing element is resource (i.e., people & time), but after many years of manage process improvement I found that the real missing element is actually incentive. Given sufficient incentives, people would allocate their time to do improvement work, thus provide the missing resources.  Another important element is management’s roles and responsibilities. Given sufficient incentives, management would spend more time monitoring improvement activities and take necessary actions to make it works and improve the business.

With these factors identified, I am proposing the following rules to help organization implement improvement activities more effectively:

(1)       All SEPG members must understand the IDEAL road map (five phases) of process improvement and follow them as close as possible. Particularly the Initiating Phase where management commitment and the SEPG infrastructure for improvement are identified. The SEPG should secure from management a commitment that software improvement tasks will be treated with equal priority to the software product development. The SEPG will be held accountable, by management, for completing these improvement projects.

(2)       Management should indicate that improvement tasks are very important and must be implement without any delay.  Beside support improvement tasks with resources, time, and incentives, management should set clear expectations, monitor the progress, and insist on performance.

(3)       All process improvement tasks should be reviewed by managers and elevate to the same level as other software works, thus providing the necessary incentive to create the desired cultural change.

Overall, an SEPG must recognize that its first task is to change itself. Then it can lead the organization to the greater journey of process improvement.

Software improvement task must not be less important, no less urgent, than the organization’s product development work. Otherwise, the improvement will never get done.

More than just management support is needed but ongoing reinforcement is the key to convincing SEPG members, and software practitioners that it is OK to change.

Question: What is risk management? Is the CMMI a risk management model?

Answer: In a crisis rich environment, many managers often focus on technical issues and lose sight of the importance of strategic thinking and decision making. Risk management is a systemic approach to making strategic decisions while dealing with crises. It is making informed decisions by continuously assessing what can go wrong and acting based on its likelihood and impact. To be successful, managers must make informed choices of opportunities in uncertain or risky conditions. Currently risk management practices are largely ad-hoc or treated as one-time only. However, risks are not static but dynamic throughout a project life cycle. Successful managers are always on the look out for risk and acting accordingly. The CMMI is really a risk management model based on the assumption that a more matured, disciplined organization can reduce the risks better than an immature organization.

Question: We are planning a project to develop a testing tool. We did look for this kind of tool outside of the company, but could not find anything that exactly fits our needs. What would be your view on build vs. buy? What do you recommend?

Answer: My recommendation is to BUY, BUY, and BUY. There will never be a “perfect tool” for any environment. Most organizations perform trade-off analysis and make decisions based on which tool fits their needs most. Tool development usually incurs significant cost and schedule overruns; most tool development project do not follow a well-defined process; and the wrong people are chosen to develop the tool. There are hundred of testing tools in the market and some of them may satisfy your organization’s needs.

However, if you have to build, here are my recommendations:

(1)     Insist on formal project planning, budgeting, and tracking.

(2)     Employ formal specifications for the tool.

(3)     Employ strict software configuration management.

(4)     Carefully select development staff.

(5)     Insist on a due date, at least one month before the tool is needed.

(6)     Ensure end-user participation in the process.

Question: For years, computer programmers have been programming without any problem. Why do we need software engineering?

Answer: In the old day, most software programs are small and few programmers can program and fix errors without much problem. However, software size has grown significantly in the past few years and we need more programmers to develop software and the problem begins with the lack of communication and coordination between them. Today, software products have a lot of defects and software projects are late most of the time. We cannot continue the traditional of “Code then Fix” as we go along anymore but need a discipline approach and it is called software engineering. The software engineer does not only program but also involves in every aspects of the software development process, from obtaining requirements, architect the system, design the product, code, test and release.

Question: What is the different between requirement and design document and why they must be documented?

Answer: A software requirement document the needs of users, it deals with what is “acceptable” to users. A software design deals with what is “achievable” through the application of technology. Requirements must always be documented because users often change their mind, without a document serve as a baseline, you can not control requirements changes. Requirement is the foundation where design is based on, without a well-defined control mechanism in place you can not trace the original of the design or what happen to software product during the development.

Question: Why focus on quality when the ultimate business goal is the creation of software product?

Answer: The purpose of software business is not creating product but the demand for it.

A software product remains a potential opportunity without any value until there is a demand for it or someone willing to pay for it. Customers determine what a business is and quality is what the customers perceive as a good attribute that they are willing to pay more for it. Quality does not depend on how complicated or expensive it is to produce but how a customer accepts and willing to pay for it.  In business, customer is everything.