Hỏi: Trong tình huống khủng hoảng kinh tế này, nơi các công ti sẽ mất kinh doanh, chúng ta có vẫn cần cải tiến qui trình không?

Đáp: Tình huống căng thẳng ngày nay có thể làm cho người giỏi nhất trong chúng ta mất tập trung. Căng thẳng của khủng hoảng kinh tế, công nhân bị thải việc của công ti, và việc đóng cửa doanh nghiệp đã thậm chí làm cho người quản lí giỏi nhất quên mất điều là thực sự quan trọng cho họ. Mục đích của cải tiến qui trình là giảm chi phí phần mềm và cải tiến chất lượng phần mềm. Nó là cách thức bản chất để cải tiến kinh doanh và duy trì trong kinh doanh. Tôi tin bây giờ hơn bao giờ hết, bạn cần cải tiến qui trình phần mềm của mình để hỗ trợ cho doanh nghiệp của bạn vẫn duy trì tính cạnh tranh. Bạn cần biết rằng người cạnh tranh với bạn không nghỉ và nếu bạn không cải tiến, họ vẫn cải tiến.

Hỏi: Cần đặt ra bao nhiêu ngân sách dành cho cải tiến qui trình? Làm sao thầy phân nhỏ nó ra và biện minh cho nó?

Đáp: Theo kinh nghiệm của riêng tôi, ngân sách cải tiến qui trình điển hình là quãng 3%-5% ngân sách hàng năm của tổ chức. Nó có thể có vẻ nhiều nhưng nó là đầu tư mà nếu thực hiện thành công có thể đem lại lãi lớn. Đây là việc phân nhỏ của ngân sách này:

Bước đầu tiên là nhận biết về các hoạt động cải tiến. Mọi người bao giờ cũng muốn biết lí do (tại sao), qui trình (thế nào), mục tiêu (cái gì) và bản lộ trình nào (khi nào, ở đâu) mà họ phải theo. Cách tốt nhất để cho tất cả mọi người trong tổ chức nhận biết về các hoạt động là giáo dục họ về khuôn khổ CMMI và kỉ luật kĩ nghệ phần mềm. Lớp “Nhập môn CMMI” được thiết kế cho hoạt động này. Xét kích cỡ của một tổ chức điển hình có xấp xỉ 300 – 600 người, và từng lớp sẽ có xấp xỉ 60 người. Bạn cần lập lịch biểu ít nhất cho 5 tới 10 lớp cho toàn tổ chức và một lớp đặc biệt  cho người quản lí (họ cần biết về CMMI nữa). Có chi phí liên kết với việc để tất cả mọi người dự lớp cả ngày nhưng dựa trên dữ liệu của chúng tôi từ nhiều năm quá khứ, phần lớn mọi người  đều đồng ý rằng đây thực sự là đầu tư tốt.

Bước thứ hai là thiết lập một nhóm toàn thời chuyên dành để hỗ trợ cho hoạt động cải tiến qui trình. Cái tên thông dụng nhất cho nhóm này là Nhóm Qui trình Kĩ nghệ Phần mềm – Software Engineering Process Group or SEPG. Các thành viên của SEPG cũng cần huấn luyện thêm để làm việc của họ. Tôi mạnh mẽ tin tưởng đây là nhân tố then chốt phân biệt thành công và thất bại của cải tiến qui trình bởi vì tri thức và kĩ năng của các thành viên của SEPG là bản chất cho mọi triển khai của các hoạt động cải tiến. Kết cấu nền này cũng buộc tổ chức phải tính chi phí phụ nhưng dữ liệu của chúng tôi cũng kiểm chứng rằng đây thực sự là đầu tư tốt.

Bước thứ ba là trao đổi về mọi hoạt động cải tiến, các thành tựu, cách đo, mục đích và mục tiêu trên cơ sở đều kì cho cấp quản lí và mọi người trong tổ chức. Quản lí cải tiến yêu cầu trao đổi tốt về thay đổi, thừa nhận tiến bộ đã làm, và đo tổ chức đã cải tiến được bao xa hướng tới mục đích. Hoạt động này cũng yêu cầu thời gian và nỗ lực (chi phí) nhưng nó là một phần của hoạt động cải tiến.

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

Như bạn có lẽ thấy từ phân tích này, phần lớn chi phí là đổ vào đầu tư cho con người trong tổ chức của bạn, huấn luyện họ, trao đổi với họ, đo thực hiện của họ, kiểm điểm công việc của họ, và vượt qua sự chống lại thay đổi để đạt tới các mục đích và mục tiêu doanh nghiệp. Cải tiến qui trình là đầu tư chính nhưng nó quả có trả lại trong tương lai, nếu bạn làm nó một cách đúng đắn và giống như bất kì đầu tư nào cấp quản lí đều phải theo dõi tiến bộ và có hành động sửa chữa khi nó dường như tạo ra kết quả không mong muốn.

Hỏi: People-CMM là gì? Điều gì xảy ra cho CMMI?

Đáp: Trong nhiều năm, tổ chức phần mềm đã chuyên môn hoá nỗ lực của nó để cải tiến công nghệ và qui trình nhưng không mấy về con người. Con người xây dựng phần mềm và làm công việc được thực hiện. Nếu họ được đối xử tốt (tức là huấn luyện, thừa nhận, đền bù) họ có thể được động viên để việc được thực hiện nhanh, tốt hơn, rẻ hơn và dùng công nghệ một cách hiệu quả hơn. Điều rất quan trọng là thừa nhận đóng góp của mọi người trong công ti và điều rất quan trọng là quản lí họ tương ứng. Mô hình trưởng thành năng lực con người – People Capability Maturity Model (P-CMM) là khuôn khổ để hấp dẫn, nuôi dưỡng, và duy trì những tài năng giỏi nhất trong công nghiệp. Nó là phần bổ sung cho CMMI chứ không thay thế. Bạn cần chấp nhận cả hai mô hình cho việc cải tiến của mình.

Hỏi: Chúng ta sống trong thời thay đổi nhanh chóng nơi mọi sự xảy ra nhanh và tác động vào cuộc sống chúng ta. Chúng ta nên làm gì để đối phó với những thay đổi này?

Đáp: Là nhà chuyên nghiệp phần mềm, có sản phẩm và dịch vụ giữ vai trò sống còn trong doanh nghiệp, chúng ta bao giờ cũng cần đánh giá những thay đổi này đang gây ra loại tác động nào lên chúng ta. Chẳng hạn: an ninh tính toán tăng lên là quan trọng cho mọi công ti, nhưng chúng ta không thể để hệ thống máy tính của mình bị khoá kín trong toà nhà được bảo vệ an ninh giống như điều chúng ta đã làm trong quá khứ. Chúng ta cần kiểm lại quan niệm về “hệ thống mở” và tác động của Internet liên quan tới những hắc khách tinh quái và chuẩn bị đối phó với “vi rút” của họ nhắm tấn công vào mục tiêu công ti.

Chúng ta cần giúp khách hàng của mình đánh giá lại hệ thống của họ, và sự phụ thuộc của họ vào Công nghệ Thông tin. Một số trong những điều này có thể bao gồm việc lập kế hoạch dự phòng nhưng chúng ta cần giúp họ xem xét lại những giả định nền tảng của họ và phát biểu về công việc và – ở chỗ thích hợp, đưa họ tham gia vào “tư duy về điều không thể tư duy được.”

Chúng ta cũng cần xem xét lại nghề nghiệp của mình trong thời kì thay đổi này. Nhiều người trong chúng ta bắt đầu hiểu thực tại là “vận may phần mềm” không còn sẵn có nữa trong thời khủng hoảng tài chính và toàn cầu hoá không còn là khái niệm mà là xu hướng. Phần lớn trong chúng ta đã từng tự hào về công việc mình làm trong nghề của mình mãi cho tới điểm này; và bây giờ chúng ta phải áp dụng kĩ năng và tri thức của mình theo cách chúng ta có thể thậm chí còn tự hào hơn về nghề của mình trong những năm tới bằng việc liên tục học những điều mới và hỗ trợ cho doanh nghiệp của mình phát đạt trong thời thay đổi này.

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

Đáp: Đây là “kịch bản lặp lại được” mà tôi đã thấy lặp đi lặp lại trong các blog trước đây: Tổ chức mức 1 vay mượn các qui trình từ các tổ chức mức 3, hay mức 4 và thậm chí mức 5, làm tài liệu chúng trong qui trình chuẩn tổ chức riêng của mình, yêu cầu tất cả các dự án phải tuân theo nó và tuyên bố thành công.  Bạn có thực sự nghĩ mình có thể giảm trọng lượng bằng việc lấy bài luyện tập và chế độ ăn uống của ai đó làm của mình không? Tôi biết nhiều nhà tư vấn đã gợi ý cho công ti đó cách dễ dàng để đạt tới mức cao hơn mà không mất nhiều nỗ lực cho nên tôi thực sự muốn hỏi:

a)     Làm sao bạn biết rằng các qui trình được chấp nhận sẽ có tác dụng cho tổ chức của bạn?

b)     Qui trình được chấp nhận có ích và chấp nhận được cho mọi người trong tổ chức của bạn không?

c)     Có bằng chứng rằng bằng việc tuân theo qui trình được chấp nhận, chất lượng, thời gian và chi phí của dự án của bạn đã được cải tiến không?

d)     Tổ chức của bạn có dữ liệu chỉ ra rằng chất lượng sản phẩm của bạn, mối quan hệ khách hàng, sự hài lòng của nhân viên và mục đích doanh nghiệp được thực hiện không?

e)     Bạn có tin bằng việc có chuẩn đã được làm tài liệu tổ chức của bạn tự động cải tiến không?

f)      Bạn có huấn luyện mọi người dùng qui trình được chấp nhận không? Hay bạn huấn luyện họ để họ có thể qua được những câu hỏi nào đó trong kì đánh giá?

Chừng nào mọi người còn chưa hiểu qui trình mới được chấp thuận, chấp nhận nó, nhận huấn luyện về nó, dùng nó, sửa đổi nó cho khớp với nhu cầu dự án của họ, đo nó như cách họ xây dựng và bảo trì phần mềm: Chẳng cái gì đã thay đổi cả.

Tôi tin sẽ là sai lầm đi ép buộc các thay đổi lên dự án bằng việc đem qui trình chuẩn bên ngoài vào thay vì thu thập “thực hành tốt nhất” từ bên trong và thiết lập qui trình chuẩn dựa trên chúng.

Tôi tin SEPG đã vi phạm khái niệm then chốt của CMMI: “Bạn không được nhảy qua các mức.” Tổ chức mức 1 nên hội tụ vào việc thiết lập môi trường quản lí dự án có kỉ luật trước khi thiết lập qui trình chuẩn trong toàn tổ chức. Qui trình được xác định tốt từ tổ chức mức cao hơn chắc chắn là chỗ tốt để thiết lập qui trình chuẩn nhưng nó thường không có tác dụng tốt cho tổ chức mức 1. Làm cho tổ chức chấp nhận một qui trình chuẩn mới bằng việc cung cấp huấn luyện là tốt nhưng không đủ và không hiệu quả trong môi trường hỗn độn. Cải tiến qui trình bao gồm việc thay đổi cách mọi người hành xử, cách mọi người làm mọi việc và điều rất mấu chốt là làm mọi người tham gia vào việc tạo ra qui trình chuẩn dựa trên thực hành tốt nhất hiện có, không vay mượn từ ai đó.

Hỏi: Cách nhanh nhất để đáp ứng mục đích giảm chi phí trong tổ chức phần mềm là gì?

Đáp: Với giải pháp dài hạn, bạn cần nghiên cứu toàn bộ qui trình tổ chức để nhận diện các cơ hội giảm chi phí. Bạn cũng cần có dữ liệu dự án để biết chi phí chính phải gánh là ở đâu và lấy hành động sửa chữa thích hợp. Không có cách đo nào đó tại chỗ, bạn có thể thực sự không biết phải làm gì và cải tiến ở đâu.

Với giải pháp ngắn hạn, tổ chức có thể giảm cho phí bằng việc ưu tiên các dự án của mình. Cấp quản lí cần kiểm điểm các yêu cầu phần mềm, thảo luận với khách hàng để giảm phạm vi dự án, trì hoãn các dự án khác, hay thậm chí cắt bỏ những dự án không quan trọng.

Hỏi: Khác biệt giữa qui trình nghiệp vụ và tái kĩ nghệ qui trình nghiệp vụ là gì?

Đáp: Qui trình nghiệp vụ được định nghĩa là tập các hoạt động tạo ra giá trị cho công ti và khách hàng của nó. Khi công ti quyết định cách làm nghiệp vụ, họ thiết kế ra qui trình nghiệp vụ để đảm bảo rằng họ có thể quản lí mọi khía cạnh của nghiệp vụ theo cách hiệu quả và hiệu lực nhất có thể được. Tuy nhiên, qua thời gian một số qui trình có thể không còn tạo ra giá trị mong đợi nữa và phải được thay thế hay tái kĩ nghệ lại.

Tái kĩ nghệ qui trình nghiệp vụ là tập các hoạt động tạo khả năng cho công ti xoá bỏ hay giảm bớt triệt để, tất cả những hoạt động bên trong qui trình nghiệp vụ mà gia tăng ít hay không gia tăng giá trị nào cho công ti và khách hàng của nó.

Hỏi: Tôi quan tâm tới chi phí không cần thiết của việc thêm chức năng đảm bảo chất lượng phần mềm – Software Quality Assurance (SQA) vào trong tổ chức của tôi để tuân thủ với CMMI. Tôi không thấy ích lợi chút nào của việc để SQA làm cảnh sát về sản phẩm phần mềm của chúng tôi.

Đáp: Cảnh sát SQA tới vào lúc kết thúc của dự án và hội tụ vào giám định chất lượng đã hết thời rồi. Ngày nay SQA tham gia vào mọi khía cạnh của qui trình phát triển phần mềm và được thừa nhận là thành viên gia tăng giá trị của dự án nơi chất lượng là “được cấy sẵn bên trong.”

Với tổ chức mức 1, SQA hỗ trợ cho người quản lí và người phát triển trong lập kế hoạch chất lượng, cách thiết kế chất lượng trong qui trình, và loại chuẩn và công cụ nào là thích hợp nhất cho dự án. Trong vòng đời dự án, SQA tham gia vào kiểm điểm pha, đảm bảo rằng qui trình được tuân theo, và hỗ trợ việc nhận diện và loại bỏ các lỗi.

Vì bạn quan tâm tới chi phí của việc thêm chức năng SQA, ta hãy nhìn vào ví dụ đơn giản này: Dựa trên nhiều nghiên cứu, chi phí lỗi điển hình $100 cần sửa trong pha yêu cầu sẽ tốn $ 20,000 để chữa sau khi đưa ra cho khách hàng. Nếu SQA có thể ngăn ngừa chỉ mười trong những lỗi này từ lúc xảy ra, thì điều đó xứng đáng hơn lương cả năm cho người SQA (ít hơn $ 200,000). Nhớ, SQA còn nhiều hơn chỉ là ngăn ngừa lỗi xuất hiện, SQA cũng hỗ trợ cho lập kế hoạch dự án, huấn luyện chất lượng, và đánh giá công cụ, danh sách kiểm v.v.

Với tổ chức mức 2, SQA hỗ trợ cho SEPG để nhận diện “thực hành tốt nhất,” thu thập dữ liệu dự án (chất lượng, thời gian, chi phí), thiết lập thư viện tài sản qui trình, giáo dục và huấn luyện mọi người về qui trình chất lượng như phân tích căn nguyên v.v.

Với tổ chức mức 3, SQA kiểm điểm sự tuân thủ của dự án với qui trình chuẩn phần mềm của tổ chức – organizational software standard process (OSSP). SQA cũng phân tích dữ liệu chất lượng như chức năng, hiệu năng, độ tin cậy, an toàn, tính dùng được v.v. để thiết lập kiểm soát qui trình thống kế cho sản phẩm phần mềm.

Vai trò của SQA tiếp tục tiến hoá khi tổ chức trưởng thành và ở mức 4, các chức năng SEPG và SQA được tích hợp rất nhiều để hội tụ vào cả chất lượng sản phẩm và qui trình. Bằng việc hội tụ vào ngăn ngừa hơn là phát hiện, cả SQA và SEPG liên tục hỗ trợ cho cuộc hành trình cải tiến của tổ chức để cải tiến chất lượng, giảm chi phí, thời gian của hoạt động phần mềm.

Hỏi: Người hỗ trợ cho cải tiến qui trình cần làm gì để duy chỉ chỉ đạo?

Đáp: Người hỗ trợ cải tiến qui trình cần hỗ trợ sáng kiến này bằng việc bổ nhiệm cán bộ cho nó với người đúng và theo dõi tiến độ cải tiến trên cơ sở hàng tháng. Thiếu sự tham gia của nhân sự là sai lầm then chốt trong hầu hết việc cải tiến qui trình. Quyền lãnh đạo điều hành là rất mấu chốt vì cải tiến được xây dựng trên tầm nhìn và mong đợi của họ. Nếu họ không tham gia một cách cá nhân và theo dõi tiến bộ trên cơ sở đều đặn, điều đó gửi thông điệp sai cho mọi cấp quản lí rằng họ không quan tâm thêm nữa. Điều này có thể gây tác động lên hoạt động cải tiến rất nhanh chóng và phá hoại toàn bộ tổ chức. Mọi người sẽ không coi sáng kiến của cấp điều hành là nghiêm chỉnh và nếu sáng kiến thất bại đâu sẽ là cơ hội cho sáng kiến tiếp? Và nếu phần lớn các sáng kiến không được coi là nghiêm chỉnh cái gì sẽ là cơ hội để làm điều gì? Chúng tất cả đều trở thành sự phí hoài nỗ lực, tiền bạc và thời gian của công ti. Để đảm bảo điều này xảy ra, người điều hành phải để những người quản lí có trách nhiệm làm cho cải tiến xảy ra và thưởng cho thành công tương ứng.

Hỏi: Tổ chức chúng tôi đã từng làm việc về cải tiến trong nhiều năm. Chúng tôi có nhiều lần tái tổ chức và cấp quản lí thay đổi và các hoạt động cải tiến cũng đã phản ánh những thay đổi này bằng sự thăng giáng giữa các ưu tiên hàng đầu và ưu tiên thấp nhất. Chúng tôi rất thất vọng. Làm sao chúng tôi thay đổi đây? Chúng tôi phải làm gì?

Đáp: Tôi tin bạn bị thất vọng bởi vì chẳng cái gì đã được thực hiện. Bạn muốn làm mọi thứ tốt hơn nhưng không có chỉ đạo rõ ràng từ cấp quản lí nó sẽ không xảy ra. Vì tổ chức của bạn đã có nhiều lần tái tổ chức và cấp quản lí thay đổi, tôi sẽ giả định rằng đã có nhiều vấn đề găng cần được thực hiện và cấp quản lí rất bận rộn giải quyết các vấn đề trước mắt và không có thời gian cho cái gì đó khác. Chừng nào họ còn quá bận rộn tái cấu trúc tổ chức, không cải tiến nào sẽ được thực hiện đâu. Điều bạn cần là giáo dục họ về ích lợi của cải tiến và yêu cầu họ hướng dẫn và lãnh đạo. Nếu họ không được thuyết phục, chẳng cái gì sẽ làm việc.

Hỏi: Người phát triển phải viết bao nhiêu hoàn cảnh kiểm thử trong vòng đời phần mềm?

Đáp: Người phát triển phần mềm nên viết ít nhất hai kiểu hoàn cảnh kiểm thử. Hoàn cảnh kiểm thử thứ nhất ở sớm trong vòng đời phần mềm, trong việc khêu gợi yêu cầu (liệt kê cái gì cần được kiểm thử, cách nó sẽ được kiểm thử, và kết quả được mong đợi là gì) để giúp họ hiểu các yêu cầu và hoàn cảnh kiểm thử kia là ở sau khi mã được hoàn thành để giúp họ kiểm thử việc thực hiện (mã thực tại).

Hỏi: Vì lĩnh vực phần mềm vẫn thay đổi nhanh chóng, tại sao chúng ta cần cải tiến nó, dù biết rằng đằng nào nó cũng sẽ thay đổi?

Đáp: Trong khi lĩnh vực kĩ nghệ phần mềm đã thay đổi đáng kể trong vài năm qua, có những điều đã không thay đổi như kỉ luật của kĩ nghệ phần mềm. Xã hội đang trở nên phụ thuộc hơn bao giờ hết vào tính toán và nó cần phần mềm tốt hơn mà có thể được chuyển giao đúng thời gian và với giá thoả thuận được.  Thái độ “bạn sẽ có nó ngay khi chúng tôi hoàn thành nó” của nhiều người phát triển phần mềm là không nhất quán với kinh doanh hàng nhiều tỉ đô la một năm, điều ảnh hưởng tới gần như mọi khía cạnh của cuộc sống chúng ta.

Trích dẫn:

Các điểm then chốt của Deming về chất lượng:

1)     Tạo ra sự kiên trì cải tiến sản phẩm và dịch vụ

2)     Chấp nhận triết lí mới

3)     Dừng phụ thuộc vào giám định để đạt tới mỗi một mình chất lượng

4)     Chấm dứt thực hành thưởng kinh doanh trên cơ sở một mình nhãn giá

5)     Cải tiến thường xuyên và mãi mãi mọi qui trình về lập kế hoạch, sản xuất và dịch vụ

6)     Mở lớp huấn luyện trong công việc

7)     Chấp nhận và bổ nhiệm quyền lãnh đạo

8)     Gạt bỏ sợ hãi

9)     Phá vỡ rào cản giữa các miền cán bộ

10)   Xoá bỏ các khẩu hiệu, hô hào, và mục tiêu cho lực lượng lao động.

11)   Xoá bỏ các trích dẫn số về lực lượng lao động và mục đích số về quản lí

12)   Loại bỏ rào cản cướp đi niềm tự hào tay nghề của mọi người

13)   Xoá bỏ việc xếp hạng hàng năm của hệ thống khen thưởng

14)   Khai trương chương trình giáo dục sinh động và tự cải tiến cho mọi người

15)   Để mọi người trong công ti làm việc hoàn thành biến đổi

—-English version—-

Question: In this economic crisis situation, where companies are going out of business, do we still need process improvement?

Answer: Today stressful situation can cause even the best of us to lose focus. Stresses of economic crisis, company laid-off workers, and business closing have caused even the best managers to forget the thing that really important to them. The purpose of process improvement is to reduce software cost and improve software quality. It is an essential way to improve the business and stay in business. I believe now more than ever, you need to improve your software process to support your business to stay competitive. You need to know that your competitors do not rest and if you do not improve, they will.

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

Answer: Based on my own experiences, a typical process improvement budget is about 3%-5% of the organizational annual budget. It may sound like a lot but it is an investment that if successfully implement can bring significant return. Here is a breakdown of the budget:

The first step is the awareness of the improvement activities. People always want to know the reason (Why), the process (How), the objectives (What) and what roadmap (When, Where) that they must follow. The best way to have all people in the organization aware of the activities is educating them on the CMMI framework and the software engineering discipline. The class “Introduction to CMMI” is designed for this activity. Consider the size of a typical organization which is approx. 300 – 600 people, and each class will hold approx. 60 people. You need to schedule at least 5 to 10 classes for the entire organization and a special class for manager (they need to know about the CMMI too). There is cost associated with having all people to take a full day class but based on our data from past several years, most people agreed that this was really a good investment.

The second step is to establish a full time group dedicated to support process improvement activities. The most common name for this group is Software Engineering Process Group or SEPG. The SEPG members also need additional training to do their job. I strongly believe this is the key factor that discriminate success and failure of process improvement because the knowledge and skills of SEPG members are essential for all deployment of improvement activities. This infrastructure also incurs additional costs to organization but our data also verified that this was a really good investment.

The third step is to communicate all improvement activities, achievement, measurements, goals and objectives on a periodic basis to management and people in the organization. Managing improvement requires good communication of the change, acknowledge the progress made, and measure how far the organization has improved toward the goal. This activity also requires time and effort (cost) but it is a part of improvement activities.

There are costs associated with having an assessment, establish an action plan and the deployment of improvement activities. Most people focuses on the cost of conducting an assessment but I believe the organization must focuses on the deployment of an action plan where many software practitioners in organization will participate in improvement activities besides their daily work and it also incurs efforts (costs). There are costs associated with managing, tracking, collecting data, and measuring all improvement activities that also need to be identified as early as possible to be incorporate in the total cost of process improvement.

As you probably see from this analysis, most of the cost is on investing in your own people, train them, communicate with them, measure their implementation, review their works, and overcome the resistance to changes to achieve the business goals and objectives. Process improvement is a major investment but it does pay-off in the future, if you do it correctly and like any investment management must track progress and take corrective action when it does not seems to produce desirable results.

Question: What is the People-CMM? What happen to CMMI?

Answer: For years, software organization has dedicated its efforts to improve technology and process but not much in people. People build software and get the job done. If they are well treated (i.e. train, recognize, compensate) they can be motivated to get the job done faster, better, cheaper and use technology more effectively. It is very important to recognize the contribution of people to the business of a company and it is very important to manage them accordingly. The People Capability Maturity Model (P-CMM) is a framework to attract, nurture, and retain the best talents in the industry. It is a complementary to the CMMI not a substitute. You need to adopt both models for your improvement.

Question: We live in a fast changing time where things happen quickly and impact our life. What do we supposed to do to cope with these changes?

Answer: As software professionals, whose products and services play a vital role in the business, we always need to assess what kind of impact these changes are going to have on us. For example: increased computing security is important to all companies, but we can not keep our computer systems locked in a secured building like what we did in the past. We need to review the concept of “open systems” and the impact of the Internet regarding malevolent hackers and prepare to deal with their “Viruses” aim to attack corporate targets.

We need to help our customers re-evaluate their systems, and their dependence on Information Technology. Some of this may involve the contingency planning but we need to help them examine their fundamental assumptions and statement of works and – where appropriate, engage them in “thinking the unthinkable.”

We also need to re-examine our career in this changing time. Many of us begin to understand the reality that “software fortunes” were no longer available in the financial crisis time and globalization is no longer a concept but a trend; Most of us have been proud of the work we’ve done in our careers up to this point; and now we should apply our skills and knowledge in such a way that we can be even more proud of our careers in the coming years by continue to learn new things and support our business to thrive in this changing time.

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

Answer: This is a “Repeatable scenario” that I have seen over and over and mentioned in previous blogs: A level 1 organization borrows processes from level 3, or level 4 and even level 5 organizations, document them into their own organization standard process, requires all projects to follow it and declares success.  Do you really think you can lose weight by having somebody exercise and diet for you? I know many consultants suggested to company that is the easy way to achieve higher levels without much effort so I really like to ask:

a)      How do you know that the adopted processes will work for your organization?

b)     Is the adopted process useful and acceptable to the people in your organization?

c)     Is there evidence that by following the adopted process, your project’s quality, time, and cost has improved?

d)     Does your organization have data indicate that your product quality, customer relationship, employee satisfaction and business goals are realized?

e)     Do you believe by just having a documented standard your organization is automatically improving?

f)      Are you training people to use the adopted process? Or are you training them so they can pass certain questions during the appraisal?

Unless people understand the new adopted process, accept it, receive training to follow it, use it, modify it to fit their project needs, measure it, improve it as the way they build and maintenance software: Nothing will ever change.

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

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

Question: What is the fastest way to meet cost reducing goal in software organization?

Answer: For long-termed solution, you need to investigate the entire organization process to identify cost-reduction opportunities. You also need to have project data to know where the major cost incurring is and take appropriate corrective actions. Without certain measurements in place, you may not really know what to do and where to improve.

In the short-termed, organization can reduce costs by prioritize its projects. Management needs to review software requirements, discuss with customers to reduce the scope of projects, postpone others, or even shutdown a few not important ones.

Question: What are the differences between business process and business process reengineering?

Answer: A business process is defined as those sets of activities that create value for a company and its customer. As company decides how to do business, they design business processes to ensure that they can manage all aspects of the business in the most effective and efficient ways as possible. However, over a period of time some processes may no longer produce the expected value or yields and have to be replaced or re-engineered.

Business process reengineering is a sets of activities that enable the company to eliminate or reduce drastically, all those activities within a business process that add little or no value to the company and its customer.

Question: I am concern with the unnecessary cost of adding Software Quality Assurance (SQA) function in our organization to comply with the CMMI. I do not see any benefit of having SQA policing our software products at all.

Answer: The SQA Police that comes at the end of the project and focus on quality inspection is gone. Today SQA participates in all aspects of the software development process and being recognized as a value-added member of the project where quality is “Built-in”.

For a level 1 organization, SQA supports managers and developers in quality planning, how to design quality into the process, and what kind of standards and tools would be best suited for the project. During the life cycle of the project, SQA participates in phase-reviews, ensure that the process is being followed, and support the identification and removal of defects.

Since you are concern with the cost of adding a SQA function, let look at this simple example: Based on several studies, a typical defect costs $100 to fix during requirement phase will costs $ 20,000 to fix after release to customers. If SQA can prevent just ten of those defects from happening, then it already worth more than a year salary for a SQA person (Less than $ 200,000). Remember, SQA is far more than just preventing defects from occurs, SQA also supports project planning, quality training, and evaluate quality tools, checklists etc.

For a level 2 organization, SQA supports SEPG to identify “Best practices”, collect project data (Quality, time, cost), establish the process assets library, educate and train people on quality process such as root cause analysis etc.

For a level 3 organization, SQA reviews project compliance with the organizational software standard process (OSSP). SQA also analyzes quality data such as functionality, performance, reliability, safety, usability etc. to establish statistical process control for software products.

The role of SQA continues to evolve as the organization maturing and at level 4, SEPG and SQA functions are very much integrated to focus on both product and process quality. By focus in prevention rather than detection, both SQA and SEPG continue to support organization’s improvement journey to improve quality, reduce the costs, time of software activities.

Question: What does a sponsor of process improvement need to do to maintain the direction?

Answer: Process improvement sponsor needs to support the initiative by staffing it with the right people and tracking improvement progress on a monthly basis. Lack of personal involvement is the key failure in most process improvement. Executive leadership is very critical since improvement is built on their vision and expectation. If they do not get involve personally and tracking progress on a periodic basis, it sends the wrong message to all management levels that they do not care anymore. This could impact improvement activities very quickly and devastate the entire organization. People will not taken executive’s initiative seriously anymore and if an initiative fail what is the chance for the next initiative? And if most initiatives are not taken seriously what would be the chance to do anything? They all become a totally waste of company’s efforts, money, and time. To ensure this from happening, executives must hold managers responsible for making improvement happen and reward success accordingly.

Question: Our organization has been working in improvement for many years. We had several reorganizations and management changes and our improvement activities also reflected these changes by fluctuate between top priority and lowest priority. We are very frustrated. How do we change? What do we do?

Answer: I believe you are frustrated because nothing is getting done. You want to make things get better but without clear direction from management it will not happen. Since your organization already had several reorganizations and management changes, I would assume that there were many critical issues that need to get done and management is very busy solving immediate problems and do not have time on something else. As long as they are too busy restructure the organization, no improvement activities will get done. What you need is to educate them on the benefit of improvement and asking them for guidance and leadership. If they are not convinced, nothing will work.

Question: How many test cases should developer write during the software life cycle?

Answer: Software developer should write at least two types of test case. The first test cases early in the software life cycle, during requirements elicitation (listing what is to be tested, how it will be tested, and what results are expected) to help them understand the requirements and another test cases after the code is completed to help them test the implementation (Actual code).

Question: Since software field keep on changing rapidly, why do we need to improve it, knowing that it will change anyway?

Answer: While software engineering field has changed significantly in the past few years, there are things that have not changed such as the discipline of software engineering. Society is becoming ever more dependent on computing and it need better software that can be delivered on time and at the agreed-upon price.  The “you’ll get it as soon as we finish it” attitude of many software developers is inconsistent with a multi-billion dollar a year business that influences nearly every aspect of our lives.

Quote:

Deming’s key points on quality:

1)     Create constancy of purpose for improvement of product and service

2)     Adopt the new philosophy

3)     Cease dependence on inspection to achieve quality alone

4)     End the practice of awarding business on the basis of price tag alone

5)     Improve constantly and forever every process for planning, production, and service

6)     Institute training on the job

7)     Adopt and institute leadership

8)     Drive out fear

9)     Breakdown barriers between staff areas

10) Eliminate slogans, exhortations, and targets for the workforce.

11) Eliminate numerical quotas for the workforce and numerical goals for management

12) Remove barriers that rob people of pride of workmanship

13) Eliminate the annual rating of merit system

14) Institute a vigorous program of education and self improvement for everyone

15) Put everybody in the company to work to accomplish the transformation