Hỏi: Tôi không phải là “Tác nhân thay đổi” hay thành viên SEPG. Làm sao tôi có thể giúp cải tiến qui trình được?

Đáp: Tác nhân thay đổi không phải là chức danh hay chức vụ và SEPG không phải là câu lạc bộ dành riêng. Bất kì ai cũng đều có thể là tác nhân thay đổi. Khi bạn để ý thấy cái gì đó có thể được cải tiến trong tổ chức của mình, bạn có cơ hội để là tác nhân thay đổi. Cấp quản lí bao giờ cũng đánh giá cao những người sẵn lòng giúp cải tiến qui trình.

Tuy nhiên, khi bạn nhận diện một nhu cầu thay đổi, xin lấy các bước học thêm về qui trình.  Có thông tin thích hợp là rất quan trọng để ra quyết định đúng bởi vì đôi khi một khuyến cáo thay đổi có thể thất bại khi người đưa ra gợi ý nhưng không đầu tư đủ thời gian để hiểu tại sao mọi sự được làm theo cách đó. Bạn cần điều tra xem ai sẽ bị ảnh hưởng bởi thay đổi này và giá cho việc làm thay đổi là gì. Bạn cần lắng nghe mọi quan điểm, và xem xét hỏi ý kiến mọi người trước khi đưa ra khuyến cáo của mình. Hãu học từ kinh nghiệm của người khác và bao giờ cũng lễ phép, kính trọng và trên hết, kiên trì.

Hỏi: Vai trò của người phát triển phần mềm là gì trong các hoạt động cải tiến mức 3?

Đáp: Người phát triển phần mềm là người đóng góp chính vào việc cải tiến qui trình ở bất kì mức nào. Không có họ việc cải tiến sẽ không bao  giờ xảy ra.

Người phát triển cần tuân theo các thủ tục phần mềm và chuẩn trong tổ chức để đảm bảo sự nhất quán. Họ cần chứng tỏ hiểu biết sâu về phương pháp và công cụ được dùng trong tổ chức cũng như khuôn khổ CMMI.

Ở mức 3, Qui trình phần mềm chuẩn của tổ chức – Organization Standard Software Process (OSSP) tồn tại để cung cấp hướng dẫn và đảm bảo sự nhất quán. Người phát triển cần tuân theo qui trình phần mềm đươc dự án xác định, đó là phiên bản được điều chỉnh của qui trình được xác định OSSP. Họ cần đảm bảo rằng sản phẩm phần mềm mà họ tạo ra là có chất lượng cao nhất có thể có bằng việc loại bỏ lỗi (Tiến hành nhiều phiên kiểm điểm, giám định). Họ cần tuân theo kĩ thuật nào đó để đảm bảo tuân thủ chính xác và kịp thời về dữ liệu kích cỡ, nỗ lực, lịch biểu và lỗi gửi cho Người quản lí dự án. Vì cải tiến là liên tục, người phát triển cũng cần tham gia vào việc cải tiến OSSP bằng việc đệ trình các yêu cầu thay đổi và đề nghị các ý tưởng cải tiến cho qui trình cải tiến tổ chức để làm cho nó thành chỗ làm việc tốt hơn.

Hỏi: Tổ chức của tôi mới bắt đầu dùng CMMI và tôi đang thành lập SEPG. Tôi nên dùng cách tiếp cận nào?

Đáp: Có nhiều cách tiếp cận tới việc bắt đầu cải tiến qui trình bằng việc dùng CMMI nhưng sau đây là khuyến cáo của tôi:

Là một thành viên SEPG, bạn cần đảm bảo rằng mọi hoạt động cải tiến đều được gióng thẳng với mục đích, mục tiêu kinh doanh của tổ chức. Rồi bạn có thể điều phối, tạo điều kiện cho các hoạt động cải tiến giữa các nhóm hay dự án và theo dõi các hoạt động nàu bên trong SEPG.

Nếu tổ chức của bạn lớn (trên 1,000 người) bạn có thể cần chia nó thành nhiều nhóm nhỏ hơn dựa trên miền hay nghiệp vụ chuyên môn và cải tiến từng nhóm mỗi lúc. Làm mọi thứ ngay một lúc là khó và rủi ro, vì thay đổi yêu cầu nỗ lực và cam kết lớn.

Trước khi bạn bắt đầu, bạn cần có cuộc họp với lãnh đạo cấp cao để thảo luận về cải tiến qui trình, ước lượng  tài nguyên và nỗ lực, mục đích và mong đợi, đầu tư và thu hồi vốn đầu tư v.v. Chỉ khi bạn có cam kết dài hạn (vài năm) từ quản lí cấp cao, bạn mới có thể bắt đầu hoạt động cải tiến.

Bước tiếp sẽ là huấn luyện mọi người quản lí liên quan tới hoạt động cải tiến để thu được sự hỗ trợ của họ. Họ phải hiểu, cam kết và hỗ trợ điều bạn đang lập kế hoạch thực hiện là chỉ khi tất cả các nhà quản lí đồng ý với bạn thì bạn mới có thể bắt đầu việc huấn luyện thêm cho mọi người trong tổ chức. Bạn cần giải thích qui trình cải tiến bắt đầu từ việc thu được cam kết của họ, tiến hành đánh giá để biết tổ chức đang ở đâu cùng những điểm mạnh điểm yếu và kế hoạch hành động có việc đo. Sau khi mọi người thực sự hiểu cải tiến tất cả là gì và đồng ý hỗ trợ bạn thì bạn có thể bắt đầu hoạt động đánh giá, xây dựng kế hoạch hành động và triển khai các hoạt động cải tiến. Bạn cũng cần thiết lập cách đo tuyến cơ sở theo mục đích kinh doanh và bắt đầu theo dõi mọi hoạt động cải tiến. Sau rốt, bạn cần dữ liệu chứng minh rằng hoạt động cải tiến quả thực tạo ra khác biệt.

Hỏi: Khi nào chúng tôi cần thu thập thực hành tốt nhất cho Thư viện tài sản qui trình (PAL)?

Đáp: Bất kì lúc nào bạn thấy “thực hành tốt nhất” hay cái gì đó có tác dụng trong tổ chức của mình. Về căn bản, Thư viện tài sản qui trình (PAL) nổi lên khi tổ chức đi từ mức 1 lên mức 2. Chừng nào còn có “thực hành tốt nhất,” người ta còn phải thu thập và để chúng vào chỗ mọi người có thể chia sẻ và sử dụng.

Hỏi: Tại sao phải bận tâm tới tuyển  tập qui trình cũ, cái giới hạn sự sáng tạo cá nhân như CMMI khi phần mềm là qui trình canh tân cao?

Đáp: Ngược lại, tôi tin CMMI là khuôn khổ mạnh tạo khả năng cho tổ chức sản xuất ra sản phẩm tốt hơn trong khi cung cấp cho nhân viên của nó môi trường làm việc được cải thiện.

CMMI không phải là qui trình được yêu cầu. Không có các bước, hay các hoạt động, mà phải tuân theo nghiêm ngặt. Cải tiến qui trình thực sự là việc thích nghi và hành động sửa chữa bằng việc dùng thông tin dự án quá khứ. Bằng việc tuân theo một qui trình được xác định rõ, tổ chức có thể giảm sự không chắc chắn và rủi ro. Đó là lí do tại sao tổ chức phải làm tài liệu và trắc  nghiệm điều được làm. Nếu cái gì đó đi sai đối với dự án, thông tin sẽ được dùng trong dự án tiếp để  tránh việc phạm phải cùng sai lầm.

Vài năm trước, tôi đã làm việc trong một tổ chức không tuân theo qui trình. Khi một dự án kết thúc, tài liệu thiết kế không tương ứng với sản phẩm phần mềm, và không có thời gian nào để làm tài liệu hay sửa vấn đề nào được tìm thấy. Khi dự án mới bắt đầu, tổ mới dùng tài liệu cũ như tham chiếu thiết kế, và do đó, đã lặp lại nhiều sai lầm từ dự án trước. Không có qui trình chính thức để trắc nghiệm và kiểm nghiệm thiết kế, để làm quản lí cấu hình, hay để quản lí yêu cầu, cùng sai lầm tiếp tục bị phạm phải trên từng và mọi  dự án. Những lỗi này đã tạo ra nhiều vấn đề hơn và nhiều chi phí hơn việc đơn giản cải tiến bằng cách cập nhật tài liệu thiết kế.

Liên quan tới tính sáng tạo cá nhân, tôi tin việc phát triển phần mềm tương tự với qui trình xây dựng nhà. Tính sáng tạo của kiến trúc sư có bị giới hạn bởi các qui tắc và qui chế luật lệ xây dựng không? Có thể có chút ít vì kiến trúc sư phải tuân thủ theo những qui tắc nào đó như an toàn, các đặc trưng của vật tư được dùng, mối quan tâm tới thẩm mĩ, vân vân. Tính sáng tạo, tri thức và kĩ năng là thuộc tính cá nhân nhưng mọi người có đánh mất chúng bởi vì họ tuân theo qui trình không? Qui trình có chế áp cách người ta nghĩ hay sáng tạo không? Tôi không nghĩ vậy.

Hỏi: Cuộc họp của chúng tôi về cải tiến qui trình không hiệu quả. Phần lớn mọi người dành thời gian tranh cãi lẫn nhau. Làm sao tôi tạo ra được môi trường mà mọi người có thể chia sẻ mọi thứ một cách hiệu quả?

Đáp: Có kĩ thuật tên là: “chia sẻ 10 phút” chính là cơ hội để mọi người nói về cải tiến qui trình. Qui tắc là:

1)     Mọi chủ đề đều phải hội tụ chỉ vào cải tiến qui trình

2)     Từng người được tối đa mười phút nói.

3)     Sẽ có bộ đếm thời gian. Khi hết mười phút, diễn giả phải dừng. Nếu chuông rung vào giữa câu, chúng ta sẽ dừng ở đó. Các đối thoại sau cuộc họp để kết thúc chủ đề được khuyến khích.

4)     Ưu tiên cho việc nói:

a)     Mọi người phải ghi tên mình vào danh sách trước khi họp.

b)     Mọi người sẽ nói theo thứ tự đã đăng kí. Vì đây không phải là bài trình bày, không có máy chiếu, các tờ chiếu không được phép, chỉ đối thoại vô tư để chia sẻ điều bạn đã biết.

5)     Nếu không còn ai nói,  chúng ta có thể quay lại diễn giả trước đó hay để mở cho bất kì ai.

6)     Vui vẻ, chia sẻ nhiều, và làm việc cải tiến xảy ra.

Hỏi: Tổ chức của tôi được xác nhận ISO 9001 vài tháng trước đây và hiện thời chúng tôi đang làm việc về CMMI với hi vọng đạt tới ít nhất cũng là CMM mức 2. Đạt tới CMM mức 2 sau kiểm định ISO 9001 là dễ hơn hay có cách đi vòng nào khác?

Đáp: Nhiều người nghĩ rằng đạt tới mức 2 dễ hơn khi bạn được xác nhận ISO 9001 nhưng có một số vấn đề cần được trả lời:

– Ai chịu trách nhiệm về chất lượng?  (QA hay dự án)

– Có cách nào khác để phát triển phần mềm thay vì tuân theo bản kế hoạch chất lượng mà mọi người tuân thủ nghiêm ngặt một số thủ tục tài liệu nào đó.

– Ai nên chịu trách nhiệm cho thủ tục phần mềm? Ai sở hữu chính sách, kế hoạch, và qui trình (Đó là QA, dự án hay cấp quản lí?) và ai nên viết chúng ra?

– Cái gì “thực sự” là thủ tục, chính sách, kế hoạch chất lượng, và qui trình?

– Tổ chức phải dịch chuyển tư duy từ, “Chúng ta đã qua được kiểm định ISO 9001″ sang “Chúng ta phải cải tiến cách chúng ta quản lí dự án phần mềm của mình.”

Hỏi: Có tương quan nào giữa Quản lí hiệu năng và miền qui trình bù trong People CMM mức 2 và PA phân tích tri thức và kĩ năng ở mức 3?

Đáp: Từng người phải có mục đích cải tiến cá nhân được làm tài liệu trong kế hoạch hiệu năng của mình nhận diện ra điều họ muốn cải tiến. Họ nên bao hàm cả mục đích đào tạo cá nhân của mình, điều tương quan với mong muốn của họ để mở rộng phân công và hoạt động.

Trong kiểm điểm hiệu năng với người giám sát, nhân viên nên thảo luận về trách nhiệm, chức vụ và đảm nhiệm hiện thời của mình và cách nó tương quan với mục đích cải tiến cá nhân.

Một cách lí tưởng, kết quả của kiểm điểm hiệu năng nên được dùng như một trong nhiều tiêu chí cho bù đắp tương lai. Trọng tâm huấn luyện của tổ chức nên tổ hợp mục đích huấn luyện cá nhân vào trong kế hoạch huấn luyện cho tổ chức. Ham muốn cá nhân để mở rộng phân công và hoạt động nên được dùng trong việc chuẩn bị báo cáo mà người quản lí và người lãnh đạo dùng cho việc lựa cán bộ tương lai  cả cho các chức năng toàn thời và bán thời.

Hỏi: Tôi rất ngạc nhiên là tổ chức của tôi được thẩm định ở mức 2. Tôi đã không để ý thay đổi hay cải tiến nào. Làm sao điều đó lại xảy ra?

Đáp: Đôi khi đạt được mức CMMI dường như xuất hiện qua đêm. Nhưng thay đổi bao giờ cũng xảy ra, từng tí một, qua một thời kì. Mọi người thay đổi với tỉ lệ khác nhau, nhưng chung cuộc, toàn bộ tổ chức quả có thay đổi. Mức 2 chỉ mới là bắt đầu, bước đầu tiên của cuộc hành trình dài. Bạn có lẽ không thấy mấy khác biệt giữa hôm nay và hôm qua nhưng nếu tổ chức của bạn  tiếp tục theo tiến trình của nó, mọi người trong tổ chức sẽ có khả năng  thấy những thay đổi có ý nghĩa trong vài năm kể từ bây giờ.

Hỏi: CMMI yêu cầu phương pháp luận nào? Về công cụ hay vòng đời phát triển phần mềm (SDLC) thì sao?

Đáp: CMMI không yêu cầu phương pháp luận nào nhưng nó nhấn mạnh rằng tổ chức đi theo một phương pháp luận. CMMI không ra lệnh phải dùng bất kì công cụ nào nhưng tổ chức phải lựa công cụ  nào nó cần để phát triển và duy trì phần mềm. CMMI cũng không nhấn mạnh vào bất kì vòng đời phát triển phần mềm đặc thù nào  (SDLC) nhưng tổ chức phải quyết định dùng SDLC thích hợp.

Điều CMM thực sự ngụ ý là ở chỗ tổ chức lựa bất kì công cụ nào, bất kì vòng đời phát triển phần mềm (SDLC) nào, và phương pháp luận để dùng và tuân theo chúng, dùng chúng, đo chúng và cải tiến chúng. Thực tế, tổ chức có thể có nhiều phương pháp luận, công  cụ, hay SDLC cho từng kiểu dự án.

Hỏi: Tôi không hiểu tại sao chúng ta cần hội tụ quá nhiều vào việc tuân theo qui trình tài liệu và dùng nó qua tất cả năm mức. Xin thầy giải thích.

Đáp: Qui trình tài liệu là đống giấy tờ chừng nào mọi người còn chưa dùng nó để làm cái gì đó. Tài liệu là bước đầu tiên nhưng không phải là đích đến cuối cùng. Về căn bản, ở mức 2 các dự án có thể dùng các qui trình đã được làm tài liệu của mình. Tuy nhiên, ở mức 3 dự án nên dùng Qui trình chuẩn phần mềm của tổ chức Organization Software Standard Process (OSSP). Qui trình chuẩn không xuất hiện “từ trời xanh” như phát minh của một nhóm ở đâu đó. Nó nên tới từ những thực hành tốt nhất: Thực hành tốt nhất được thu thập từ nhiều dự án và được cất giữ trong thư viện tài sản qui trình (PAL) để các dự án khác dùng lại. Những tài sản dùng lại này thiết lập nên sự kiện là tổ chức có các qui trình chuẩn được mọi dự án sử dụng và do đó nó quản lí nhất quán tất cả các dự án của nó tương ứng. Nó cũng lập ra giai đoạn thu thập cách đo trên việc dùng các tài sản đó: Chúng tốt thế nào? Chúng chính xác thế nào? Điều này trở thành cơ sở cho việc cơ cấu tổ chức để thực sự đo hiệu năng qui trình và sản phẩm tại mức trưởng thành tiếp (mức 4). Cách đo được dựa trên việc dùng các tài sản cơ sở này ngang qua mọi dự án, nó cho phép so sánh kết quả của các dự án khác nhau qua thời gian, điều hình thành nên cơ sở cho kiểm soát qui trình thống kê. Tại mức 4 các dự án đều được quản lí theo những mục đích được mong đợi nào đó (tức là không có việc trượt lịch biểu hơn vài ngày, không có nhiều hơn X lỗi) và dữ liệu được thu thập sẽ được dùng để xem tài sản nào là nguyên nhân của biến thiên. Những tài sản gây ra biến thiên là ứng cử viên cho việc cải tiến ở mức 5 trong Canh tân công nghệ và Quản lí thay đổi và Quản lí thay đổi qui trình nơi mà công cụ, phương pháp và qui trình được cập nhật để làm giảm biến thiên.

Hỏi: Khách hàng của tôi muốn có tốc độ tối đa nhưng chúng tôi muốn thực hiện với chất lượng và hiệu quả. Làm sao thầy cân bằng được điều này?

Đáp: Đúng là cả hai phía đều có những cái nhìn khác nhau. Chìa khoá cho bạn và khách hàng của bạn là nhận ra điều này và phát triển hiểu biết về điều này dẫn lái tới điều kia. Bạn không phải đồng ý với mọi thứ, nhưng có giá trị trong sự nhạy cảm được tăng cường. Làm điều này có thể nảy sinh sự bù trừ nào đó mà nếu không thế thì có thể không có được (chẳng hạn, đổi chi phí lấy tốc độ). Bạn không thể lúc nào cũng theo cách của mình mà bạn có thể giáo dục khách hàng về tại sao mọi sự là theo cách của chúng.

Hỏi: Trong vài tháng qua, nhiều người đã viết thư cho tôi và bày tỏ thất vọng về một số quyết định đẩy họ và tình huống xấu. Họ đã được trao mệnh lệnh cải tiến qui trình để đạt tới một mức trước ngày nào đó, vậy mà mọi thứ khác lại có ưu tiên cao hơn cải tiến qui trình.

Đáp: Chúng ta hãy nhìn vào tình huống này và vai trò của tác nhân thay đổi (thành viên của SEPG):

Tác nhân thay đổi hỗ trợ để cung cấp nhiệt tình, kĩ năng và chiều hướng cần có để vượt qua sự chống cự và làm thay đổi xảy ra.

Đầu tiên, chúng ta hãy thảo luận về vấn đề nhiệt tình: Nếu bạn không nhiệt tình với điều bạn làm thì tác nhân thay đổi không phải là việc dành cho bạn. Tôi giả sử rằng khi chấp nhận việc của SEPG, bạn có thái độ này trừ phi bạn bị “phân công” cho việc mà bạn không hề muốn. Trong trường hợp đó, bạn cần có thảo luận lâu với người quản lí của bạn.

Thứ hai, ta hãy nhìn vào vấn đề kĩ năng. Tôi mạnh mẽ tin tưởng rằng thành viên SEPG nên được tuyển mộ — không được phân công. Điều này nghĩa là cấp quản lí không nên phân công người cho vai trò này chỉ bởi vì họ có đó và sẵn có mà phải chọn lựa cẩn thận người có phẩm chất, người có thể tạo ra khác biệt. Để thành công, thành viên SEPG cần diện rộng kinh nghiệm phần mềm. Ít nhất cũng nhiều năm phát triển và bảo trì phần mềm. Kinh nghiệm này cho phép thành viên SEPG hiểu những thay đổi được cần tới cho các dự án cũng như trong toàn tổ chức và, hiểu tác động của những thay đổi nào đó với các dự án và trên tổ chức. Trong nhiều năm quá khứ, tôi đã huấn luyện nhiều thành viên SEPG và việc huấn luyện của tôi yêu cầu hai năm tham gia các lớp tập huấn và thực hành, đó là rất nhiều việc huấn luyện và tôi hi vọng nhiều người trong các bạn sẽ có khả năng áp dụng điều bạn đã học cho tổ chức của bạn.

Tất nhiên, cải tiến qui trình không bao giờ là nhiệm vụ dễ dàng! Bạn cần động viên cán bộ, tạo ra nhiệt tình, và tiếp sinh lực cho toàn tổ chức. Bạn cần làm cho tổ chức hiểu cả tầm nhìn và hiện thực hiện thời liên quan tới tầm nhìn đó. Một số trong những hiểu biết này tới khi bạn chuyển các kết quả thẩm định (điểm yếu và điểm mạnh) vào kế hoạch hành động. Bạn cần rất sáng tạo trong việc tìm ra giải pháp cho những điểm yếu của dự án và tổ chức. Bạn cũng phải dẫn nhịp để thay đổi xuất hiện trong tổ chức bởi vì nếu nhịp thay đổi quá chậm, tiến bộ sẽ bị giới hạn; trong khi nhịp quá nhanh sẽ bị ngắt quãng và tự thất bại. Một người SEPG có kĩ năng phải có khả năng lập kế hoạch và quản lí cải tiến qui trình coi như nó là dự án phần mềm.

Watts Humphrey, tác giả của CMM đã nói: thành viên SEPG “phải là người quản lí thông thái với năng lực được chứng minh để làm cho mọi sự xảy ra, người tôn trọng các nhà chuyên môn dự án, và hỗ trợ cho quản lí cấp cao.”

Cho nên thay vì chỉ tay vào ai đó khác, chúng ta hãy tự hỏi mình vài câu hỏi hắc búa. Bạn, xem như một thành viên của SEPG, bằng việc chọn lựa, liệu có phẩm chất và nền tảng cần thiết để hướng chương  trình cải tiến qui trình đi tới kết luận thành công trong tổ chức của bạn không? Bạn có phải là người có thể làm cho mọi sự xảy ra không? Bạn có tôn trọng người lãnh đạo dự án và người quản lí tổ chức để cho bạn có thể thực hiện các nhiệm vụ được yêu cầu ở bạn như tác nhân thay đổi không? Bạn có nhiệt tình cần thiết để làm cho tổ chức thay đổi không?  Dễ trách ai đó hay cái gì đó khi mọi sự không làm việc theo cách bạn muốn nhưng có những lúc bạn cần nhìn sâu vào trong bản thân mình và hỏi những câu hỏi hắc búa, không chỉ một lần hay hai lần mà mọi ngày.

—-English version —-

Question: I am not a “Change agent” or SEPG member. How could I help process improvement?

Answer: Change agent is not a title or position and SEPG is not an exclusive club. Anyone can be a change agent. When you notice something that can be improved in your organization, you have an opportunity to be a change agent. Management always appreciates people who are willing to help in improving the process.

However, when you identify a need for change, please take steps to learn more about the process.  Having adequate information is very important to make good decision because sometimes a recommendation for a change can fail when people makes suggestions without investing enough time in understanding why things are done that way. You need to investigate on who would be affected by the change you are suggesting and what the cost of making the change would be. You need to listen to all points of view, and consider asking everybody before making your recommendations. Learn from the experience of others and always be polite, respectful, and most of all, persistent.

Question: What is the role of software developers during the level 3 improvement activities?

Answer: Software developers are key contributors in process improvement at any levels. Without them improvement will never happen.

Developers need to follow software procedures and standard in the organization to ensure consistency. They need to demonstrate an in-depth understanding of methods and tools used in the organization as well as the CMMI framework.

At level 3, the Organization Standard Software Process (OSSP) exists to provide guidance and ensure consistency. Developers need to follow the project defined software process that is a tailored version of the OSSP defined process. They need to ensure that the software product that they create is of highest possible quality by removing defects (Conduct more reviews, inspections).They need to follow certain technique to ensure accurate and timely submittal of size, effort, schedule, and defect data to the Project Manager. Since improvement is continuous, developers also need to participate in the improvement of the OSSP by submitting change requests and propose improvement ideas to the organization improvement process to make it a better place to work.

Question: My organization just starts to use the CMMI and I am forming a SEPG. What approach should I use?

Answer: There are many approaches to start process improvement using CMMI but following is my recommendation:

As a SEPG member, you need to ensure that all improvement activities are aligned with organization business goals, objectives. Then you may want to coordinate, facilitate improvement activities between groups or projects and tracking these activities within your SEPG.

If your organization is large (Over 1,000 people) you may want to divide it into smaller groups based on specific domain or business and improve one group at a time. It is difficult and risky to do everything all at once, since changes require significant efforts and commitment.

Before you start, you need to have a meeting with senior management to discuss the improvement process, resources and effort estimates, goals and expectations, investment and return on investment etc. Only when you have long term commitment (several years) from senior management, you may start improvement activities.

The next step would be training all managers regarding the improvement activities to obtain their support. They must understand, commit and support what you are planning to do and only when all managers agreed with you then you may begin the additional training to people in the organization. You need to explain the improvement process starting with obtain their commitment, conduct appraisal to know where the organization is as well as the strengths and weaknesses and the action plan with measurements. After people really understand what the improvement is all about and agree to support you then you may start the appraisal activities, develop action plans and deploy improvement activities. You also need to establish a baseline measurement against the business goals and begin tracking all improvement activities. After all, you need data to prove that improvement activities indeed do make the difference.

Question: When do we need to collect best practices for the Process Assets Library (PAL)?

Answer: Anytime you find “Best practices” or something that works in your organization. Typically, Process Assets Library (PAL) emerges when organization going from Level 1 to Level 2. As long as there are “Best practices”, one must collect and deposit them in a place where people can share and use.

Question: Why bother with an old collection of process that limits personal creativity such as the CMMI when software is highly innovation process?

Answer: On the contrary, I believe CMMI is a powerful framework that enables an organization to produce better products while providing its employees with an improved working environment.

The CMMI is not a required process. There aren’t steps, or activities, that must be strictly followed. Process improvement is really an adaptation and corrective actions using past project information. By following a well-defined process, organization can reduce the uncertainties and risks. That is why the organization must document and verify what is done. If something goes wrong for a project, the information will be used on the next one to avoid making the same mistakes.

Few years ago, I have worked in an organization that didn’t follow a process. When a project ended, the design documentation didn’t correspond to the software product, and there wasn’t any time to document or correct any of the found problems. When a new project began, the new team used the old documentation as a design reference and, therefore, repeated many mistakes from the previous project. Without a formal process to verify and validate the design, to do configuration management, or to manage requirements, the same mistakes continued to be made on each and every project. These errors ultimately created more problems and cost more than it would have cost to simply improve by updating the design documentation.

Regarding personal creativity, I believe develop software is similar to the process of a building construction. Is the architect’s creativity limited by rules and building code regulations? Maybe a little since the architect has to comply with certain rules such as safety, the characteristics of the materials used, be concerned with aesthetics, and so on. Creativity, knowledge and skills are personal attributes but do people lose them because they are following a process? Does a process dictate how a person thinks or creates? I do not think so.

Question: Our meeting on process improvement is not effective. Most people spend time arguing with each other. How do I create an environment where people can share things effectively?

Answer: There is a technique called: “10 minutes sharing” which is an opportunity for people to talk on process improvement. The rules are:

1)     All subjects must be focused on process improvement activities only

2)     Each people get a maximum of ten minutes to talk.

3)     There will be a timer. When the ten minutes are up, speaker must stop.  If the bell rings in mid-sentence, we will stop there. Conversations after meeting to finish a subject are encouraged.

4)     Priority for speaking:

a)     People must put their name on the list before the meeting.

b)     People will speak in the order that they sign up.  Since this is not a presentation, no projector, slides is allowed, only candid conversation to share what you learned.

5) If no one is left to speak, we may go back to an earlier speaker or open to anyone.

6) Have fun, share a lot, and make improvement happen.

Question: My organization was ISO 9001 certified few months ago and currently we are working on the CMMI hoping to achieve at least CMM level 2. Is it easier to achieve CMM level 2 after ISO 9001 audit or the other way around?

Answer: Many people may think that it is easier to achieve Level 2 when you are ISO 9001 certified but there are certain issues that need to be answered:

– Who is in charge for quality?  (QA or the project)

– Is there other way to develop software rather than follow a quality plan require that people to strictly follow certain number of documented procedures.

– Who should be responsible for software procedure? Who own policy, plan, and process (Is it QA, project, or management?) and who should write them?

– What are “really” a procedure, policy, quality plan, and process?

– The organization must shift the thinking from, “We’ve got to pass the ISO 9001 audit” to “We have to improve the way we manage our software projects.”

Question: What correlation between Performance Management and Compensation PAs in People CMM level 2 and Skills and knowledge analysis PA at Level 3?

Answer: Each person should have the individual improvement goals documented in their performance plan identify what they want to improve. They should include their individual training goals that correlate with their desire to broadening assignment and activities.

During performance review with their supervisor, the employee should discuss his or her current responsibilities, position and accountabilities and how it correlates with the individual improvement goals.

Ideally, the result of the performance review should be used as one of many criteria for future compensation. The organization training focal should incorporate all individual training goals into a training plan for the organization. The individual desire to broadening assignments and activities should be used in preparing a report that managers and leaders use for future staffing both part-time and full-time functions.

Question: I was very surprised that my organization was assessed at level 2. I did not notice any changes or improvements. How does it happen?

Answer: Sometime achieving a CMMI level seems to occur overnight. But change is always happening, little by little, over a period of time. People changes at different rates, but eventually, the entire organization does change. Level 2 is only the beginning, the first step of a long journey. You probably do not see much different between today and yesterday but if your organization continues to follow its course, people from the organization will be able to see significant changes few years from now.

Question: Which methodology does the CMMI required? What about tools or software development life cycle (SDLC)?

Answer: The CMMI does not require any methodology but insists that the organization following one. CMMI does not dictate any tool to use but the organization must select whichever tool it need to develop and maintain software. The CMMI also does not insist on any particular software development life cycle (SDLC) but the organization must decide which appropriate SDLC to use.

What the CMM really implies is that the organization selects whatever tools, software development life cycle (SDLC), and methodology to use and follow them, use them, measure them and improve on them. In fact, the organization may have more than one methodology, tool, or SDLC for each type of project.

Question: I do not understand why we need to focus too much on following a document process and the usage of it throughout the five levels. Please explain.

Answer: A document process is a heap of paper unless people use it to do something. Document is the first step but not the final destination. Basically, at level 2 projects can use their own documented process. However, at level 3 projects should use the Organization Software Standard Process (OSSP). The standard process should not appear “out of the blue sky” as the invention of a group somewhere. It should come from best practices: The best process collected from several projects and stored in the process asset library (PAL) for re-use by other projects. These re-usable assets establish the fact that the organizational has standard processes to be used by all projects and therefore it is consistently managing all of its projects accordingly. It also sets the stage for the collection of measurements on the use of those assets: How good are they? How accurate are they? This becomes the basis for setting up the organization to truly measure process and product performance at the next maturity level. (Level 4) The measurements being based on the use of these basic assets across all projects, it allows a comparison of the results of different projects over time which forms the basis for statistical process control. At level 4 projects are managed to certain expected goals (i.e. No schedule slippage more than a few days, no more than X defects) and data collected will be used to see which assets are the cause of variations. Assets causing variation are candidates for improvement at level 5 in Technology innovation and Change Management and Process Change Management where tools, methods and processes are upgraded to reduce the variation.

Question: My customer wants maximum speed but we want to perform with quality and efficiency. How do you balance this?

Answer: It is true that both sides have different views. The key for you and your customer is to recognize this and to develop an understanding of what is driving the other. You don’t have to agree to everything, but there is value in the heightened sensitivity. Doing this may result in certain trade- offs that might not otherwise have come up (for example, trading cost for speed). You can’t always have your way but you can educate your customer on why things are the way they are.

Question: In the past few months, several people have written to me and expressed frustration over some decisions for placing them in a bad situation. They have been given an order to improve the process to achieve a level by a certain date, yet everything else has more priority than the process improvement.

Answer: Let’s look at the situation and the roles of the change agent (SEPG members):

A change agent supposed to provide the enthusiasm, skills, and direction needed to overcome resistance and make change happen.

First, let’s discuss the enthusiasm issue: If you are not enthusiasm about what you do then change agent is not a job for you. I assume that when accepting a SEPG job, you do possess this attribute unless you were “assigned” the job you never wanted. In that case, you need to have a long discussion with your manager.

Second, let’s look at the skills issue. I strongly believe that SEPG member should be recruited — not assigned. This means that management should not assign people to this role just because they are there and available but carefully select qualified people who can make the difference. To be successful, a SEPG member needs a wide breadth of software experience. At least, several years in develop and maintain software. This experience allows the SEPG member to understand the changes that are needed on projects as well as across the organization and, to understand the impact of certain changes on projects and on the organization. In the past several years, I have trained many SEPG members and my training required two-year of workshops and practicum, that is lots of training and I hope many of you will be able to apply what you learned to your organization.

Of course, process improvement is never an easy task! You need to motivate personnel, create enthusiasm, and energize the entire organization. You need to make the organization understand both the vision and the current reality relative to that vision. Some of this understanding comes when you translate assessment results (weaknesses and strengths) into action plans. You need to be very creative in finding solutions to project and organizational weaknesses. You also have to guide the pace at which change occurs in the organization because if the pace of change is too slow, progress will be limited; while too rapid a pace will be disruptive and self-defeating. A skilled SEPG should be able to plan and manage process improvement as though it was a software project.

Watts Humphrey, the author of CMM said: SEPG member “must be a knowledgeable manager with a demonstrated ability to make things happen, the respect of the project professionals, and the support of the top management”.

So instead of pointing the finger to somebody else, let’s ask ourselves some hard questions. Do you, as a SEPG member, by choice, have the qualities and background necessary to guide a process improvement program to successful conclusions in your organization? Are you the people who can make things happen? Do you have the respect of project leaders and organizational managers such that you can perform the tasks required of you as the change agent? Do you have the enthusiasm needed to make the organization change?  It is easy to blame somebody or something when things do not work the way you wanted but there are times you need to look deeply into yourself and ask hard questions, not only once, or twice but everyday.