Đáp: Đúng là chỉ có vài người lãnh đạo đánh giá hay nhà tư vấn có kinh nghiệm ở các tổ chức mức cao nhưng họ đã được huấn luyện về điều cần tìm kiếm trong đánh giá của họ. Tất nhiên, kinh nghiệm không tạo ra khác biệt. Sau đây là những quan sát dựa trên kinh nghiệm của tôi khi tiến hành đánh giá CMMI tại hơn 30 tổ chức mức 4 và:

Về căn bản khi tôi tiến hành đánh giá cho một tổ chức ở mức 4, tôi cũng tìm những thực hành mức 5. Phần lớn các tổ chức đạt tới mức 4 đều đã có nhiều thực hành mức 5 đang dùng. Điều đáng ngạc nhiên là nhiều tổ chức đã đạt tới mức 5 mà không biết về điều đó. Bên cạnh việc tìm các vật phẩm và thực hành then chốt được làm tài liệu trong sách CMMI, tổ chức trưởng thành đầy đủ mức 4/5 cũng có dữ liệu lớn và những thực hành không được làm tài liệu trong CMMI và đây là chỗ tôi chú ý tới nhiều.

1) Thu hồi đầu tư (ROI) và Dữ liệu xu hướng cải tiến

Nếu tổ chức đã dùng CMMI trong nhiều năm, họ phải có dữ liệu xu hướng cải tiến như họ đã đầu tư bao nhiêu vào cải tiến qui trình (tổng nỗ lực của tổ chức và giờ nỗ lực theo kĩ sư phần mềm) và loại ích lợi doanh nghiệp nào họ đã thu được dưới dạng chi phí, lịch biểu, chất lượng như giảm lỗi khi đưa ra tới X% trong X năm, tăng sự hài lòng của khách hàng lên X% trong X năm v.v. Một tổ chức được quản lí tốt sẽ có đồ hoạ chỉ ra xu hướng cải tiến qua thời gian cho từng mức độ trưởng thành so với mục đích và mục tiêu doanh nghiệp. Đây là những bằng chứng rằng tổ chức đã từng cải tiến trong nhiều năm.

2) Bài học rút ra và thực hành duy nhất

Tổ chức mức 4/ 5 cũng có những bài học rút ra được làm tài liệu ở đâu đó. Tôi muốn tìm ra những rào cản nào họ đã phải vượt qua để đạt tới mức 4/5? Những rào cản này có thể là qui trình, cách đo, văn hoá, môi trường kinh doanh, hay quan hệ khách hàng v.v. Ý định là nhận diện những điều đã phải được làm khác đi để chuyển sang mức 4/5. Có điều gì mà họ đã thử và bỏ bởi vì chúng không có tác dụng? Tôi tìm những thực hành duy nhất mà họ đang làm bây giờ bởi vì mức độ trưởng thành cao của họ nhưng không mong đợi tổ chức trưởng thành thấp phải làm; có thể đây là đóng góp quan trọng cho sự trưởng thành cao của họ chăng?

Một tổ chức mức 4 điển hình bao giờ cũng đưa khách hàng cùng tham gia và loại xây dựng tổ này xác định nên mức 4 vững chắc. Về căn bản, trong các cuộc phỏng vấn, bạn sẽ không nghe thấy mọi người phàn nàn gì mà có thái độ hướng tới tổ và hợp tác có tổ chức. Dữ liệu về các cuộc họp với khách hàng, kết quả của những cuộc họp đó là vật phẩm tốt để nhìn vào. Bạn không chờ cho tới mức 5 mới ngăn ngừa lỗi mà biết về chúng từ mức 4 (các cuộc họp kiểm điểm quan trọng trong pha vòng đời và mọi người biết họ đã khám phá ra bao nhiêu lỗi và đã sửa được bao nhiêu trước khi đưa ra). Xem như qui tắc, tỉ lệ phát hiện lỗi điển hình 85% hay 90% được trông đợi ở mức 4/5 này. Ít hơn 80% có thể là CMMI mức 3 nhưng chưa hoàn toàn ở mức 4.

Qui trình phần mềm chuẩn của tổ chức ở mức 4 được tổ chức hơn nhiều với việc dùng lại có ý nghĩa. Dữ liệu về biến thiên lịch biểu, lỗi, và thời gian bao giờ cũng dưới Kiểm soát qui trình thống kê – Statistical Process Control (SPC), cận trên và dưới được xác định bởi dữ liệu lịch sử chứ không phải là “Ba sai lệch chuẩn” điển hình như thực hành thông thường. Tôi bao giờ cũng hỏi làm sao họ đi tới với kiểm soát SPC của họ để xác định liệu họ có ở mức 4 vững chắc hay không?

3) Vấn đề con người và văn hoá

Phần lớn các tổ chức mức 4/5 cũng làm điều gì đó đúng về vấn đề con người. Về căn bản tôi thấy nhiều việc xây dựng tổ, quản lí hướng theo con người, và hoạt động xây dựng kĩ năng. Nhiều tổ chức đã thiết lập chương trình kèm cặp chính thức và có chương trình định hướng có nghĩa cho các nhân viên mới. Dữ liệu về thay đổi nhân viên cũng được giữ và được cấp quản lí biết. Một số tổ chức thậm chí còn có dữ liệu về tinh thần nhân viên được cải thiện xem như kết quả của hoạt động cải tiến qui trình.

Xem như qui tắc, tôi cũng hỏi họ sẽ làm gì tiếp? Tổ chức “mức 4/5 vững chắc” biết điều cần làm tiếp và tổ chức “mức 4/5 sơ sinh” không có tầm nhìn vượt quá việc đạt tới mức 5 (Câu trả lời điển hình là: đạt tới mức 5 trước 2005 và nó là vậy thôi). Một nhân tố xác định mức 5 vững chắc là câu trả lời về điều họ sẽ làm tiếp và mục tiêu cải tiến của họ. Loại thực hành nào họ đang tối ưu. Rào cản nào họ có thể đối diện và lập kế hoạch vượt qua. Họ biết cách duy trì việc cải tiến của mình và bàng trướng nó hướng tới mục đích doanh nghiệp.

Tôi bao giờ cũng hỏi mọi người ở các tổ chức mức ao, đạt các mức 4 hay 5 có nghĩa gì? Cái gì là khác biệt? Có thay đổi trong tinh thần nhân viên, động cơ và kết quả kinh doanh như năng suất và chất lượng không? Về tuyệt hảo hiệu năng thì sao, tuyệt hảo vận hành, và hài lòng của khách hàng thì sao? Vì mức 4 hội tụ vào quản lí định lượng, và Kiểm soát qui trình thống kê – Statistical Process Control, tôi muốn biết cách đo nào là có ích cho họ. Kĩ thuật phân tích nào cung cấp cái nhìn sâu sắc hơn? Ai đang dùng các kĩ thuật SPC, và họ thu được giá trị nào? Có loại hỗ trợ quản lí nào ở mức trưởng thành cao từ các mức thấp hơn không? Vấn đề hỗ trợ có thay đổi sau mức 3 không? Vấn đề là gì trong việc duy trì tuyệt hảo sau khi đạt tới mức 4 hay 5?

Bằng việc có câu trả lời thoả mãn cho những câu hỏi này, tôi có thể xác định liệu một tổ chức có thực sự đạt tới CMMI mức 4 hay 5 hay chỉ là khái niệm rằng chúng gần như có đó.

Hỏi: Người quản lí của tôi không thích tiến bộ của chúng tôi và muốn đạt tới mức 2 bằng việc ra lệnh cho chúng tôi làm tài liệu mọi qui trình để thoả mãn các yêu cầu mức 2. Thầy nghĩ sao?

Đáp: Đôi khi cấp quản lí mất kiên nhẫn với cách tiếp cận hiện thời và quyết định rằng thay đổi “Lớn” là cần để đưa mọi thứ trở lại khuôn dạng. Cách tiếp cận “Big-bang” này rất có thể đưa tới nhiều thất bại hơn là cách tiếp cận nó thay thế.

Thay đổi có nghĩa yêu cầu học tập đáng kể và nỗ lực phụ. Theo kinh nghiệm của tôi, lần đầu tiên tổ chức làm cải tiến qui trình, bạn có thể trông đợi việc tăng thêm thời gian bởi vì mọi người phải học thay đổi cách họ làm việc. Bất kì thay đổi nào cũng đều yêu cầu điều chỉnh trước khi cải tiến thực có thể được thực hiện. Tuy nhiên thực hiện cải tiến qui trình bằng làm hàng đống tài liệu không có tác dụng và sẽ không bao giờ có tác dụng cũng như “mì ăn liền” không bao giờ có thể thay thế được thức ăn nấu ở nhà cho người sành ăn.

Cấp quản lí của bạn cần biết tại sao cách tiếp cận hiện thời không đạt tới kết quả mong muốn. Có phải vì thiếu chỉ đạo của cấp quản lí? Có phải vì trao đổi giữa các thành viên? hay có thể bản thân qui trình cải tiến có khuyết điểm?

Tôi gợi ý rằng tổ chức của bạn nên hội tụ vào việc nhận diện miền bị ảnh hưởng nhiều nhất tới khả năng đạt tới mục đích và hội tụ vào mỗi miền đó thôi. Với phần lớn dự án, những chỗ then chốt để tìm là ở trong miền quản lí dự án như quản lí phạm vi, thời gian, và chất lượng. Nếu miền đúng được lựa, bạn có thể thấy thay đổi bắt đầu xảy ra và với những thay đổi này, việc không hài lòng của cấp quản lí sẽ được giảm đi và cơ hội thành công của bạn sẽ tăng lên.

Hỏi: Làm sao thầy thoả mãn được khách hàng người thường xuyên đòi hỏi rằng thầy đáp ứng lịch biểu không hợp lí?

Đáp: Mong đợi của khách hàng bao giờ cũng nảy sinh trong việc áp đặt hạn chót nào đó cho dự án phần mềm. Tuy nhiên, bản chất của dự án phần mềm yêu cầu rằng tổ phần mềm phải giải quyết tính động thường xuyên của thay đổi. Điều này tạo ra mức độ cực đoan về rủi ro dự án và duy trì khủng hoảng, điều nảy sinh số phần trăm lớn các dự án bị cắt bỏ, chậm chuyển giao, hay với chi phí quá mức và chất lượng kém. Tuy nhiên, việc biết bản chất của tính động này có thể cho phép người quản lí dự án ra quyết định theo chức năng được hứa hẹn thay vì thời gian, do đó kiểm soát được chính các nhân tố làm giảm cấp chất lượng và độ tin cậy phần mềm. Bạn bao giờ cũng có thể thương lượng về chức năng, tài nguyên, và thời gian. Nếu thời gian là quan trọng cho khách hàng của bạn thì bạn phải giảm chức năng để đáp ứng cam kết thời gian.

Hỏi: Chúng tôi tổ chức Thư viện tài sản qui trình – Process Asset Library (PAL) thế nào để cất giữ các tài liệu và thực hành tốt nhất?

Đáp: Có nhiều cách tổ chức Thư viện tài sản qui trình của bạn (PAL). Bạn có thể chọn thiết kế PAL từ cảnh quan SEPG (theo các miền qui trình PA), cảnh quan người hành nghề phần mềm (theo vòng đời phần mềm), hay bất kì cảnh quan nào thích hợp cho cấu trúc tổ chức của bạn.

Bạn cũng cần xem xét các nhân tố sau.

· Cảnh quan của PAL.

· Góc nhìn dẫn lái của PAL.

· Yêu cầu bảo trì của PAL (cập nhật hàng tháng hay hàng quí).

· Các câu hỏi chung về huấn luyện, điều chỉnh, và dùng PAL cho phát triển, bảo trì và thẩm định phần mềm.

Hỏi: Thầy có lời khuyên nào cho tổ chức đang nỗ lực cố đạt tới mức 2 không?

Đáp: Xin hãy đọc các câu hỏi và đáp khác mà tôi đã đưa lên. Có nhiều lời khuyên và tổ chức đang nỗ lực của bạn không phải một mình đâu.

Đầu tiên, tổ chức của bạn cần hiểu mức 2 nghĩa là gì. Có phải đạt tới một mức chỉ là một đánh dấu trên lịch biểu hay danh sách kiểm?

Thứ hai bạn phải tự hỏi mình, mục đích và mục tiêu của cải tiến qui trình của bạn là gì? Tại sao tổ chức của bạn cố gắng cải tiến qui trình? Bạn đã có đánh giá chưa? Bạn có kế hoạch hành động không? Nếu bạn có, thì lấy ra hai khuyến cáo hàng đầu từ kế hoạch hành động và bắt đầu thực hiện chúng.

Đây là bài học tôi rút ra.

1. Không nỗ lực quá lâu. Thử lấy giúp đỡ nào đó.

2. Hội tụ vào giải quyết vấn đề tổ chức và đáp ứng mục đích. Tránh cố gắng làm tài liệu qui trình bởi vì cách tiếp cận này rất mệt mỏi, tốn thời gian, và không phải rất thành công trong quá khứ. Nhiều người tin rằng họ có thể cải tiến bằng việc làm tài liệu qui trình theo CMMI nhưng bản thân tài liệu sẽ không đem tới cải tiến chừng nào mọi người còn chưa thực hành chúng trước hết.

3. Thiết lập cách đo động viên hành vi thích hợp như giảm lỗi và cải tiến ước lượng dự án. Giáo dục tổ chức về ý định và việc dùng đúng cách đo.

4. Theo dõi mọi hoạt động triển khai và đặt tương quan để xem liệu xu hướng cải tiến có nổi lên không.

Hỏi: Khi nào thầy xây dựng chính sách để tuân thủ các yêu cầu CMMI?

Đáp: Nhiều tổ chức xây dựng các phát biểu chính sách vào lúc đầu của hoạt động cải tiến qui trình của họ. Tuy nhiên, cách tốt nhất là để trễ vấn đề này cho tới khi ít nhất bạn cũng hoàn thành pha thử nghiệm của vòng đời triển khai: Xác định, Thử nghiệm, Duyệt xét lại, và Thể lệ hoá. Bạn cần thu được một số kinh nghiệm bằng việc dùng qui trình này và thu được mức độ chấp nhận nào đó trước khi ban hành chính sách chỉ đạo dùng qui trình này.

Hỏi: Chúng tôi đang làm việc về chính sách của mình và tôi thấy chính sách từ các tổ chức khác nói: “Dự án sẽ” và liệt kê mọi thực hành trong CMMI. Thầy nghĩ sao?

Đáp: Tôi bao giờ cũng hoài nghi chính sách trích dẫn mọi thực hành của CMMI là chính sách thực. Chính sách mà trích dẫn tất cả các thực hành có lẽ là cái gì đó đã được tạo ra để làm hài lòng người lãnh đạo đánh giá trong thời gian đánh giá. Tôi không chắc liệu tổ chức sẽ có khả năng thực hiện tất cả chúng hay cấp quản lí có thực sự muốn áp đặt mọi thực hành then chốt trong CMMI? Một chính sách thực bao giờ cũng dựa trên mục đích và mục tiêu doanh nghiệp vốn là đặc thù cho tổ chức đó. Nó cung cấp chiều hướng và mong đợi từ cấp quản lí và nó sẽ được thực hiện và được áp đặt.

Hỏi: Tại sao chúng tôi cần kiến trúc phần mềm? Làm sao tôi được huấn luyện trong lĩnh vực này?

Đáp: Kiến trúc phần mềm là chất liệu then chốt trong phát triển các hệ thống phần mềm phức tạp. Ích lợi của việc có kiến trúc được xác định tốt là hệ thống kết quả sẽ có hành vi dự đoán được. Điều không may là kiến trúc vẫn còn là lĩnh vực tiến hoá với rất ít trường phái dạy về nó. Có vài cách nhìn và phong cách kiến trúc, tuỳ thuộc vào kinh nghiệm của kiến trúc sư.

Phong cách kiến trúc là mô tả về các cấu phần, các ghép nối (quan hệ giữa các cấu phần), topology (cách thu xếp các cấu phần và ghép nối), và một số ràng buộc lên giao diện của chúng. Chúng phục vụ như nền tảng cho lập luận chính xác và hiệu quả về các mục đích chất lượng-thuộc tính riêng. Chúng làm điều này bằng việc liên kết tường minh một khuôn khổ suy luận với một phong cách thiết kế. Khuôn khổ suy luận này có thể có nền tảng định lượng như Phân tích đơn nguyên tỉ lệ – Rate Monotonic Analysis hay lí thuyết xếp hàng hay các cách đo hay nó nó có thể định tính như danh sách kiểm, bảng hỏi, hay phân tích theo kịch bản.

Hỏi: Công ti của tôi muốn bắt đầu kinh doanh điện tử. Chúng tôi lập kế hoạch để bắt đầu với nhóm phát triển web, làm việc qua các tổ chức kĩ nghệ phần mềm và rồi với nhóm hệ thông tin. Thầy thấy đấy có là cách tiếp cận tốt không?

Đáp: Tổ chức của bạn không nên bắt đầu kinh doanh điện tử bằng nhóm web, các tổ chức kĩ nghệ phần mềm hay hệ thông tin. Chỗ bắt đầu phải là nhóm kinh doanh của bạn. Tổ chức phải có chiến lược kinh doanh, được đi theo đó là các chính sách thực hiện chiến lược, rồi được tổ chức theo các nhóm chức năng để hỗ trợ cho chiến lược kinh doanh. Một khi tổ chức suy nghĩ qua kinh doanh của mình và hiểu cách kinh doanh điện tử nên làm việc thế nào, thì cấp quản lí có thể lập kế hoạch thực hiện. Chỉ thế thì hệ thông tin, tổ chức kĩ nghệ phần mềm và nhóm web mới có thể hỗ trợ cho bản kế hoạch này bằng việc thực hiện công nghệ cần thiết để đạt tới mục tiêu kinh doanh. Nhớ rằng kinh doanh điện tử là kinh doanh và KHÔNG PHẢI là website. ĐỪNG lẫn lộn kinh doanh với công nghệ.

Hỏi: Thầy có cần làm tài liệu cho tất cả sáu miền qui trình (PA) không hay chỉ một phần của chúng để đạt tới CMMI mức 2?

Đáp: Nếu bạn làm tài liệu cho tất cả hay một phần của sáu qui trình này thì điều bạn có là một chồng giấy thường bị người phát triển bỏ qua và bạn chẳng bao giờ đạt tới CMMI mức 2. Tôi thực sự KHÔNG hiểu tại sao nhiều công ti thế cứ nói tới cách tiếp cận “làm tài liệu” khi cải tiến qui trình của họ. Loại hoạt động này không đề cập tới mục đích thực của cải tiến như giảm chi phí phần mềm và thời gian chu kì và cải tiến chất lượng. Cải tiến qui trình là quyết định kinh doanh và nó phải được đặt tương quan với mục đích kinh doanh thực bằng việc thực tế thực hành cái gì đó. Tài liệu chỉ là phản ánh những thực hành nào đó đã có tại chỗ. Điều đó nghĩa là bạn phải thực hành trước rồi làm tài liệu sau – không có cách đi vòng khác.

Hỏi: Thầy bao giờ cũng biện hộ cho huấn luyện nhưng huấn luyện cấp quản lí thì sao? Người quản lí cũng cần huấn luyện chứ?

Đáp: Vâng, người quản lí tốt động viên mọi người làm hết sức của họ và có thể tạo ra kết quả lớn lao ngay cả khi dự án hay tổ chức phải nỗ lực dưới những điều kiện kém hơn lí tưởng. Tất cả các công nghệ lớn và cải tiến qui trình trên thế giới sẽ không bù lại được cho quản lí kém, điều có thể đưa dự án hay tổ chức vào thất bại.

Tôi mạnh mẽ tin mọi người quản lí đều cần huấn luyện, đặc biệt trong “quản lí thời gian” vì họ chỉ có thể tốt nếu họ có đủ thời gian làm hết sức. Mặc dầu tài năng tự nhiên là cấu phần quan trọng cho người quản lí tốt, bao giờ cũng có nhiều điều để học và liên tục học là điều người quản lí tốt nhắm tới.

Hỏi: Người quản lí dự án có phải tiến hành báo cáo trạng thái hàng tuần và hàng tháng không? Người quản lí dự án còn phải là gì khác nữa?

Đáp: Báo cáo trạng thái hàng tuần hay hàng tháng là cách tiếp cận tốt tới quản lí dự án nhưng chúng không đủ. Có nguy cơ thực sự là người quản lí dự án có thể vẫn bỏ lỡ những vẫn đề then chốt mà sẽ báo động cho họ về các vấn đề của dự án. Thỉnh thoảng, các báo cáo trạng thái tuần hay tháng trở thành nhiệm vụ được làm “một cách hời hợt” để cho người phát triển có thể trở lại công việc (về sau) của họ.

Một cách bổ sung để kiểm chứng thông tin được nêu trong các báo cáo trạng thái hàng tuần hay tháng là tiếp xúc cá nhân với các nhân viên trên cơ sở hàng ngày. Nó sẽ cho người quản lí dự án cái nhìn rõ ràng về điều thực sự diễn ra trong dự án (thường không tường minh qua điều điều không được nói). Hãy biết cán bộ của bạn, làm việc cùng họ, và nói với họ hàng ngày và bạn sẽ thu được hiểu sâu mà không báo cáo trạng thái dự án nào có thể cung cấp được. Bạn không chỉ có khả năng thấy được những dấu hiệu nguy hiểm sớm hơn, mà bạn sẽ có khả năng thấy và thưởng cho những nỗ lực mạnh đang giữ cho dự án đi đúng đường.

English version

Question: Since very few lead appraisers have worked at high level organizations. How do they appraise level 4 or 5 organization?

Answer: It is true that there are only few lead appraisers or consultants have experiences in higher level organizations but they were trained on what to look for in their appraisal. Of course, experience does make a difference. Following are observations based on my experiences in conducting CMMI appraisal at more than 30 level 4 and 5 organizations:

Typically when I conduct appraisal for organization at level 4, I also look for level 5 practices. Most organizations achieved level 4 already have a lot of level 5 practices in use. Surprisingly, many may have achieved level 5 without knowing it. Besides looking for artifacts and key practices documented in the CMMI books, a fully matured level 4/5 also have significant data and practices not documented in CMMI and this is where I pay a lot of attention.

1) Return on Investment (ROI) and Improvement Trend Data

If organization used CMMI for many years, they should have improvement trend data such as how much they have invested in process improvement (total organization efforts and effort hours per software engineer) and what kind of business benefit they have obtained in terms of cost, schedule, quality such as decrease released defects by X% within X years, increase customer satisfaction to X% within X years, etc. A well-run organization would have graphics that show improvement trends over time for each maturity levels against business goals and objectives. These are evidences that the organization has been improving for several years.

2) Lessons learned and unique practices

A level 4/ 5 also have lessons learned documented somewhere. I want to find out what barriers that they had to overcome to achieve level 4/5? These barriers may be process, measurement, cultural, business environment, or customer relation, etc. The intent is to identify the things that had to be done differently to transition to Level 4/5. Are there any things that they tried and abandoned because they weren’t working? I am looking for unique practices that they do now because of their high maturity but wouldn’t expect a low maturity organization to do; maybe this is an important contributor to their high maturity? A typically level 4 always involve customers and this kind of team building determines the solid level 4. Typically, during interviews, you will not hear people complain about customer anymore but an attitude toward teaming or working together. Data on customer meetings, results of those meetings are good artifacts to look into. You do not wait until level 5 for defect prevention but hear about them at level 4 (Significant reviews per life cycle phase and people know how much defects they discovered and fixed before release). As a rule, a typical 85% or 90% defect detection rate is expected at this level 4/5. Less than 80% may be a CMMI Level 3 but not quite a Level 4 yet. The Organization Standard Software Process at level 4 is much more organized with significant reuse. Data on schedule variance, defect, and time are always under Statistical Process Control (SPC), upper and lower bound are determined by historical data not just typical “Three Standard Deviation” as commonly practices. I always ask how do they come up with their SPC control to determine if they are solid 4 or not?

3) People and Cultural Issues

Most level 4/5 organizations also doing something right about people issues. Typically I found a lot of team building, people-oriented management, and skills building activities. Many established formal mentoring program and have significant orientation program for new employees. Data on employee turnover is also kept and known by management. Some even have data on employee morale improving as a result of process improvement activities. As a rule, I also ask on what are they working on next? A “Solid level 4/5” knows what to do next and a “Fluffy level 4/5” does not have vision pass achieve level 5 (Typical answer is: achieve level 5 by 2005 and that’s it). One factor determines solid level 5 is the answer on what they will do next and their improvement objectives. What kind of practices that they are optimizing. What barriers they may be facing and plan to overcome. They know how to sustain their improvement and expand it toward business goals.

I always ask people in the high level organization, what does it mean to be level 4 or 5? What is different? Are there change in employee morale, motivation, and business results such as productivity and quality? What’s about performance excellence, operational excellence, and customer satisfaction? Since level 4 focus on quantitative management, and Statistical Process Control, I want to know what measures are useful for them. What analytic techniques provide more insight? Who is using SPC techniques, and what value are they obtaining? What kind of management sponsorship at high maturity level differs from lower levels? Do sponsorship issues change after Level 3? What are the issues in maintaining excellence after achieving Level 4 or 5?

By having these questions answered satisfactorily, I can determine whether the organization is truly achieved CMMI Level 4 or 5 or just a notion that they are almost there.

Question:  My manager is not happy with our progress and wants to reach level 2 by ordering us to document all processes to satisfy the level 2 requirements. What do you think?

Answer: Sometimes management looses patience with the current approach and decides that a “Big” change is needed to put things back into shape. This “Big-bang” approach is likely to lead to more failures than the approach it replaced.

Significant changes require significant learning and additional efforts. Based on my experiences, the first time organization does process improvement, you can expect an increase in time because people must learn to change the way they work. Any change requires an adjustment before real improvements can be realized. However implementing process improvement by massive documentation does not work and will never work just like “Instant noodles” can never replace gourmet home cook foods.

Your management needs to know why the current approach is not achieving the desired results. Is it because lack of management direction? Is it communication among members? Or maybe the improvement process itself is flawed?

I suggest that your organization focus on identifying the area that is most affecting the ability to achieve the goals and focus on that one area only. For most projects, the key places to look for are in the project management areas such as management of scope, time, and quality. If the correct area is selected, you may see changes begin to happen and with these changes, management’s unhappiness will be reduced and your chances for success will increase.

Question: How do you satisfy a customer who constantly demands that you meet their unreasonable schedule?

Answer: Customer expectations always result in imposing certain deadlines for software projects. However, the nature of software projects demands that software teams deal with the constant dynamics of change. This creates extreme degrees of project risk and perpetuates the crisis, which results in a large percentage of projects being canceled, delivered late, or with cost overruns and poor quality. However, knowing the nature of these dynamics can allow project managers to make decisions on promised functionality instead of time, thereby controlling the very factors that degrade software quality and reliability. You can always negotiate on functionality, resource, and time. If time is important to your customer then you must reduce your functionality to meet the time commitment.

Question: How do we organize our Process Asset Library (PAL) to store our documents and best practices?

Answer: There are many ways to organize your Process Asset Libraries (PAL). You may choose to design a PAL from a SEPG perspective (By PAs), a software practitioner perspective (by software life cycle), or any perspective that is suitable for your organization’s structure.

You also need to consider the following factors.

· The perspective of the PAL.

· The navigational view of the PAL.

· The maintenance requirements of the PAL (Monthly or quarterly update).

· General questions on training, tailoring, and use of the PAL for software development, maintenance, and assessments.

Question: Do you have any advice for a struggling organization trying to get to level 2?

Answer: Please read other Questions and Answers that I posted. There are plenty of advices there and your struggling organization is not alone.

First, your organization needs to understand what a level 2 means. Is achieving a level just a mark on a schedule or checklist?

Second you must ask yourself, what are your process improvement goals and objectives? Why is your organization trying to improve the process? Have you had an appraisal yet? Do you have an action plan? If you do, then pick two top recommendations from the action plan and start implementing them.

Here are my lessons learned.

1. Don’t struggle for too long. Try to get some help.

2. Focus on solving organization problems and meeting goals. Avoid attempting to document processes because this approach is very tedious, time consuming, and hasn’t been very successful in the past. Many people believe that they can improve by documenting the process according to the CMMI but the document by itself will not bring improvement unless everyone practices them first.

3. Establish measures that encourage appropriate behavior such as reducing defects and improving project estimation. Educate the organization on the intent and correct use of metrics.

4. Track all deployment activities and correlate with the metrics to see if an improvement trend has emerged.

Question: When do you develop a policy to comply with the CMMI requirements?

Answer: Many organizations develop policy statements at the start of their process improvement activity. However, the best way is to delay the issue of a policy until you at least complete the pilot phase of the deployment Lifecycle: Define, Pilot, Revise, and Institutionalize. You need to gain some experience using the process and gain some degree of acceptance before issuing a policy directing the usage of the process.

Question: We are working on our policies and I saw policies from other organizations stated: “The project shall” and listed every practice in the CMMI. What do you think?

Answers: I always doubt policies that quote every practice of the CMMI to be a real policy. A policy that quotes all the practices is probably something that has been created to please the Lead appraiser during appraisal time. I am not sure if the organization will be able to implement them all or the management really wanting to enforce every key practice in CMMI? A real policy is always based on business goals and objectives that are particular to that organization. It provides the direction and expectation from management and it will be implemented and enforced.

Question: Why do we need software architecture? How do I get trained in this field?

Answers: Software architecture is a key ingredient in the development of complex software systems. The benefit of having a well-defined architecture is the resulting systems will behave predictably. Unfortunately, architecture is still an evolving field with very few schools teaching it. There are several views and styles of architecture, depend on the experiences of the architect. An architectural style is a description of components, connectors (relations among components), topology (arrangement of components and connectors), and some constraints on their interaction. They serve as a foundation for precise and efficient reasoning about specific quality-attribute goals. They do this by explicitly associating a reasoning framework with an architectural style. This reasoning framework may be quantitatively grounded such as the Rate Monotonic Analysis or queuing theory or metrics or it may be qualitative in nature such as checklists, questionnaires, or scenario-based analysis.

Question: My company would like to start an e-business. We are planning to begin with our web development group, work through software engineering organizations and then to the information systems groups. Do you think it is a good approach?

Answers: Your organization should not start e-business with the web group, software engineering organizations or information systems. The starting place should be your business group. The organization must have a business strategy, followed by policies to implement the strategy, then organized by functional groups to support the business strategy. Once an organization thinks through its business and understand how e-business should works, then management can plan the implementation. Only then, information systems, software engineering organizations and web groups can support the plan by implement the technology needed to achieve the business objectives. Remember that E-business is a business and NOT a website. Do NOT confuse the business with the technology.

Question: Do you need to document all six processes area (PA) or only part of them to achieve CMMI level 2?

Answer: If you document all or part of the six processes then what you have is a stack of paper that is often ignored by developers and you never achieve the CMMI level 2. I really do NOT understand why so many companies are taking the “Documentation” approach when improve their process. This kind of activity does not address the real goals of improvement such as reducing software cost and cycle time and improving quality. Process improvement is a business decision and it must be correlated with real business goals by actually practicing something. A document is only a reflection of certain practices already in place. That means you must practice first then document later—not the other way around.

Question: You always advocate technical training but what about management training? Does manager need training also?

Answer: Yes, a good manager motivates people to do their best and can produce great results even when a project or an organization struggles under conditions that are less than ideal. All the great technology and process improvement in the world will not compensate for poor management, which can drive a project or an organization into failure.

I strongly believe all managers need training, especially in “Time management” since they can only be good if they have enough time to do their best. Although natural talent is an important component for good managers, there is always more to learn and continuously learning is what a good manager should aiming for.

Question: Should project manager conduct monthly and weekly status report? What else should project managers do?

Answers: Weekly or monthly status reports are good approach to project management but they are not enough. There is a real danger that project managers may still missing key issues that will alert them of project problems. Sometime, weekly or monthly status reports become tasks that get done “superficially” so that developers can get back to their (late) work.

A complementary way to verify the information provided in weekly or monthly status reports is personal contact with staff on daily basis. It will give project manager a clear view of what is really going on in a project (often implicitly through what is not said). Get to know your staff, work with them, and talk with them daily and you’ll gain insights that no project status report can provide. Not only will you be more likely to see danger signs earlier, but you’ll also be able to see and reward the strong efforts that are keeping the project on track.