Hỏi: Tổ chức của tôi muốn bắt đầu chương trình cải tiến qui trình bằng cách dùng CMMI làm khuôn khổ. Bước đầu tiên nên là gì? Tiến hành cuộc đánh giá chăng? Huấn luyện người lãnh đạo đánh giá? Thành lập Nhóm qui trình kĩ nghệ phần mềm – Software Engineering Process Group (SEPG)?

Đáp: Quyết định bắt đầu chương trình cải tiến qui trình trong một tổ chức là một quyết định nghiệp vụ và nó phải được thực hiện nghiêm chỉnh. Do đó, bạn phải đề cập tới nhiều điều trước khi bắt đầu nỗ lực cải tiến.

Có được cam kết từ quản lí cấp cao của tổ chức của bạn cho việc cải tiến qui trình. Cam kết nghĩa là họ nhận biết đầy đủ, hiểu và sẵn lòng hỗ trợ là điều có giá trị hơn nhiều so với việc cho phép bắt đầu cải tiến.

Trao đổi về các lí do nghiệp vụ cho việc cải tiến qui trình – Mọi người trong tổ chức của bạn cần biết tại sao bạn muốn bắt đầu chương trình cải tiến. Mục đích và mục tiêu là gì? Mong đợi là gì?

Thiết lập một nhóm chuyên trách cho cải tiến qui trình như Nhóm qui trình kĩ nghệ phần mềm Software Engineering Process Group (SEPG). Nhân tố then chốt trong chương trình cải tiến thành công nhất là thiết lập nhóm hỗ trợ này. Nếu nhóm này không có vai trò được xác định rõ ràng, trách nhiệm và thẩm quyền thực thi, thì cải tiến thực có thể không xảy ra được.

Tôi đã thấy nhiều tổ chức bắt đầu cải tiến qui trình bằng một đánh giá nhưng lại không chú ý tới việc thiết lập nhóm để phối hợp và tạo điều kiện thuận tiện cho các hoạt động cải tiến. Nếu tổ chức chỉ hội tụ vào việc có được đánh giá chứ khong để giải quyết các vấn đề mấu chốt hay xây dựng một nhóm cải tiến thì ai sẽ phối hợp và thực hiện các hoạt động cải tiến sau đánh giá?

Hỏi: Nhóm qui trình kĩ nghệ phần mềm- Software Engineering Process Group (SEPG) là gì?  Họ được dự định làm cái gì?

Đáp: Nhóm qui trình kĩ nghệ phần mềm – Software Engineering Process Group (SEPG) là nhóm “các tác nhân thay đổi” nội bộ được lập ra để giúp cho tổ chức cải tiến qui trình của nó. Vì nhóm SEPG phải:

  • Có hiến chương mô tả cách nó sẽ hỗ trợ cho tổ chức trong các hoạt động cải tiến qui trình.
  • Có các thành viên tổ chuyên môn trong một số khía cạnh nào đó của các bộ môn kĩ nghệ phần mềm như Yêu cầu, Thiết kế, Viết mã, Kiểm thử, Đưa ra, Ước lượng và Đo v.v.
  • Có khả năng “thử nghiệm” những thực hành mới để giải quyết các vấn đề gay cấn trước khi đưa ra dùng rộng rãi trong tổ chức (Thể lệ hoá)
  • Dành một số thời gian trong việc xây dựng các thực hành mới nhưng nhiều thời gian hơn để làm cho chúng được những người hành nghề phần mềm dùng.
  • Không phí thời gian vào việc làm tài liệu ít hữu dụng cho tổ chức. Giữ việc làm tài liệu qui trình chỉ trong vài trang hữu dụng.
  • Đo thành công của nó dựa trên tính hữu dụng cảm nhận được của những dịch vụ được xác định bởi kĩ sư phần mềm và người quản lí trong tổ chức.
  • Giữ quan hệ với SEPG khác để trao đổi và chia sẻ những thực hành tốt nhất và bài học rút ra.

Tóm lại, một SEPG tốt là nhóm có thể giúp cho tổ chức cải tiến hiệu năng của nó và giải quyết các vấn đề then chốt của nó.

Hỏi: Liệu có khả năng một tổ chức đã đạt tới mức trưởng thành cao rơi xuống mức trưởng thành thấp không?

Đáp: Có chứ, một tổ chức có thể rơi trở lại mức trưởng thành thấp. Điển hình, ở mức 2, nhiều thực hành chưa được thể lệ hoá đầy đủ. Nếu tổ chức bắt đầu chùng lỏng, thái độ “làm việc như thường” sẽ trở lại. Việc đánh giá chỉ là ảnh chụp nhanh về năng lực của tổ chức theo thời gian. Năng lực của tổ chức có thể thay đổi bất kì khi nào tổ chức thay đổi, con người, hay kết cấu nền thay đổi. Việc tái tổ chức và luân chuyển nhân sự then chốt là những nguyên nhân chung làm cho sự trưởng thành rơi xuống. Lời khuyên của tôi là bao giờ cũng giữ cho đà đi lên, bất kể mức độ trưởng thành. Tổ chức phải nhắm tới mức tiếp ngay cả khi họ đã đạt tới mức 5. Cách duy nhất để giữ không bị rơi xuống là giữ việc cải tiến. Nhớ cải tiến là liên tục. Xin đừng dừng lại và chùng lỏng, cải tiến nghĩa là đi lên mọi lúc.

Hỏi: Liệu có khả năng tiến hành chỉ một đánh giá cho một tổ chức lớn 10,000 người hay hơn không? Họ có thể đạt tới CMMI mức 3 không?

Đáp: Dựa vào kinh nghiệm riêng của tôi thì công việc đánh giá có tác dụng tốt nhất cho một nhóm xấp xỉ 100 tới 1000 người. Bên ngoài điều đó, nhiều người hay dự án có thể bị bỏ  không được đại diện.

Tại sao bạn muốn tiến hành chỉ một đánh giá cho một tổ chức rất lớn? Tổ chức này có thực sự có 10,000 người làm việc trong một lĩnh vực hay một ứng dụng? Tất cả họ có ở cùng một chỗ không? Họ đang phát triển một hệ thống hay nhiều hệ thống?

Nếu một tổ chức lớn chứa nhiều ứng dụng hay lĩnh vực miền thì phạm vi của đánh giá nên hội tụ vào mức miền. Bạn có thể cần tiến hành vài đánh giá cho từng lĩnh vực miền. Kết quả có thể được làm cuốn chiếu; tức là, nếu tất cả các lĩnh vực miền được thẩm định ở CMMI mức 3 thì toàn bộ tổ chức sẽ ở mức 3.

Mục đích của đánh giá là để nhận diện các vấn đề mấu chốt cần giải quyết và từng miền có thể có những vấn đề khác nhau đòi hỏi các giải pháp khác nhau để giải quyết. Gắn tất cả chúng lại thành một đánh giá có thể không phải là một ý tưởng hay.

Hỏi: Tôi muốn là một “tác nhân thay đổi “. Tôi bắt đầu thế nào? Tôi hứng khởi trong việc cải tiến tổ chức của tôi cho tốt hơn.

Đáp: Nếu bạn thực sự muốn là một tác nhân thay đổi, tốt nhất nên bắt đầu bằng việc đưa thay đổi vào trong cách bạn làm mọi thứ. Bạn có thể tự hỏi mình những câu hỏi như:

1)     Tôi có thể lấy những bước nào để cải tiến kĩ năng của mình?

2)     Tôi đã làm tài liệu cho các qui trình của tôi ở đâu?

3)     Tôi dùng cách đo nào để đo tính hiệu quả của mình?

4)     Tôi đã làm gì để thúc đẩy canh tân trong bản thân mình?

Tác giả Mark Twain đã nói: “Chẳng cái gì cần cải tiến nhiều bằng tiến bộ của người khác”. Những lời trí huệ làm sao! Cho nên trước khi bạn định thay đổi tổ chức của mình cho tốt hơn, hãy làm những thay đổi bạn có thể làm được bên trong bản thân mình, và rồi cố gắng thay đổi cái gì đó rõ ràng trong kiểm soát của bạn. Bạn sẽ có thể thành công nhiều hơn và bạn sẽ có đòn bẩy đưa thay đổi cho người khác.

Hỏi: Người quản lí của tôi muốn biết phải mất bao lâu để chuyển từ mức này sang mức khác của  CMMI? Liệu có thể đạt tới mức 3 trong vòng một năm không? Chúng tôi còn chưa có việc đánh giá.

Đáp: Dựa trên dữ liệu của Viện Kĩ nghệ phần mềm tại Đại học Carnegie Mellon, thời gian cần để đi lên trong mô hình trưởng thành là xấp xỉ 25 tháng từ mức 1 lên mức 2, và 24 tháng từ mức 2 lên 3. Tuy nhiên, dựa trên kinh nghiệm của riêng tôi thì sẽ mất xấp xỉ 36 tháng để chuyển từ mức 1 lên mức 2 và 24 tháng từ mức 2 lên mức 3.

Lập mục đích lên mức 3 mà không có đánh giá cũng giống như du hành trong rừng rậm mà không biết bạn đang ở đâu. Bạn phải tự hỏi mình mức 3 nghĩa là gì với bạn và tổ chức của bạn. Nó là con số ảo thuật hay cái gì đó khác? Mục đích doanh nghiệp của việc cải tiến qui trình là gì? Nó là cải tiến về chất lượng, chu kì thời gian, năng suất, và chi phí hay chỉ là là con số mức độ trưởng thành vô nghĩa?

Hỏi: Làm sao chúng tôi có thể duy trì cải tiến qui trình bền vững được? Chúng tôi có đánh giá hai năm trước và đã làm một số cải tiến nhưng đà gần đây đã bị chậm lại.

Đáp: Để duy trì bền vững việc cải tiến qui trình bạn cần ba nhân tố then chốt: Sự đảm nhiệm, sự tham gia và cách đo.

1)             Đảm nhiệm: Cải tiến qui trình nên được tổ chức để cho mọi người không thể nỏ qua được nó. Cấp quản lí của bạn nên đối xử với các hoạt động cải tiến như dự án và điều phối mọi nhiệm vụ cải tiến trên cơ sở hàng tháng và nhấn mạnh vào hiệu năng.

2)             Tham gia: Cải tiến qui trình tự nó không thể thành công được. Mọi người trong tổ chức phải được thông báo và được tham gia vào việc giải quyết vấn đề mà tổ chức đang đương đầu. Thành công của nhiệm vụ cải tiến nên được đối xử quan trọng ngang như việc chuyển gia sản phẩm phần mềm.

3)             Cách đo: Cải tiến qui trình phải được thiết kế với các mục đích đo được có liên quan tới nghiệp vụ của tổ chức. Những mục đích nàu phải được theo dõi và phân tích cẩn thận trên cơ sở hàng tháng. Dữ liệu cải tiến nên được trao đổi trong toàn tổ chức bởi vì nếu không có dữ liệu cải tiến, cấp quản lí sẽ ngần ngại đầu tư vào các hoạt động tương lai và không có ngân quĩ đầu tư, những nỗ lực cả tiến tương lai sẽ không xảy ra.

Hỏi: Tôi để ý rằng Citibank đang đạt tới CMMI mức trưởng thành 5 trong tạp chí Phố Wall. Tôi rất ấn tượng rằng một ngân hàng, không phải tổ chức phần mềm mà có thể cải tiến được tới chừng đó. Có đúng là bất kì công ti nào cũng có thể đạt tới mức độ trưởng thành cao hơn không?

Đáp: Vì Suzanne Kelly, Phó chủ tịch ở Citibank là người bạn nên tôi gọi điện cho cô ấy và cô ấy xác nhận rằng đấy là Citibank Ấn Độ đã đạt tới mức trưởng thành 5. Suzanne cũng chia sẻ với tôi các hoạt động cải tiến tại công ti của cô ấy như sau:” Việc cải tiến qui trình của Citibank đã bắt đầu năm năm trước đây và bất kì nhóm nào có hơn 400 nhân viên có tham gia vào việc phát triển phần mềm đều phải trải qua việc đánh giá. Tới hôm nay, Citibank có 42 đánh giá với 75% ở mức 1, 15% ở mức 2, 10% ở mức 3 và một ngoại lệ Citibank, Ấn Độ ở mức 5.”

Suzanne cũng chia sẻ với tôi rằng Citibank đã thay đổi đáng kể trong năm năm qua bằng việc lấy một số hành động then chốt:

1)     Quản lí theo qui trình chứ không theo sản phẩm

2)     Dùng qui trình và bảng chuẩn để nhận diện cơ hội cải tiến.

3)     Nhấn mạnh vào cải tiến liên tục và thay đổi tăng dần

4)     Dựa vào sự thoả mãn của khách hàng như nhân tố chính về hiệu năng

5)     Đối xử với mọi nhà cung cấp như đối tác

Suzanne cho sự thành công của Citibank là do tuân theo các nguyên tắc: “Thành công qui trình phụ thuộc vào cả nhiệm vụ và con người”. Cô ấy vẽ một chiếc bánh xe đạp như bánh xe nhiệm vụ, và phần khác là bánh xe con người. Cô ấy nói phải có cân bằng giữa hai điều này. Thông tin nhiệm vụ bao gồm cả “cái gì” và “thế nào”, trong khi con người phải vừa sẵn lòng vừa có khả năng tiến hành các nhiệm vụ được phân công cho họ.

Cô ấy nhấn mạnh:  Nếu một người không có khả năng tiến hành một nhiệm vụ, thì dù họ có sẵn lòng cũng chẳng được việc gì. – Nếu một người không sẵn lòng tiến hành một nhiệm vụ, dù họ có khả năng cũng chẳng được việc gì. Nếu một người tiến hành một việc sai, dù họ có biết làm nó cũng chẳng được việc gì. Nếu một người không biết cách tiến hành nhiệm vụ, dù họ có được hướng dẫn làm điều đúng cũng chẳng được việc gì.

Cô ấy còn đùa thêm về các nguyên tắc của mình là “Cải tiến qui trình cũng như nghệ thuật đi xe máy: Xe máy phải đi nhanh, cân bằng, được điều chỉnh kĩ, và được chuyên biệt theo người chủ. Cả người lái xe và người phát triển phần mềm đều phải có tầm nhìn rõ ràng, có kĩ năng, là một phần của tổ, và bao giờ cũng học tập.”

Cô ấy cũng chỉ ra rằng động cơ cho Citibank chấp nhận CMMI là do thay đổi nhanh chóng trong nghiệp vụ và công nghệ. Cô ấy nói: “Nhiều người chưa bao giờ nghĩ một thể chế tài chính lại dùng CMMI làm khuôn khổ cho việc cải tiến nhưng sau khi dùng nó chúng tôi thấy nó quả thực tốt. Chúng tôi phát triển nhiều phần mềm tại chỗ, chúng tôi cũng mua nhiều phần mềm, và việc tích hợp phải có tác dụng. Có nhu cầu cho người quản lí nghiệp vụ hiểu rõ hơn về công nghệ và cũng có nhu cầu cho các nhà công nghệ hiểu nghiệp vụ. CMMI đã có ích trong việc giải thích tình huống cho cả nhà công nghệ và người quản lí nghiệp vụ. Hiện thời có khoảng 10,000 nhà công nghệ ở Citibank, trong đó 5,000 người là người phát triển phần mềm.

Cô ấy cũng chia sẻ qui trình tại tổ chức mức 5 của mình như sau: “Tổ chức được thiết kế ở mức 5. Chúng tôi thuê người quản lí có kĩ năng và kinh nghiệm đúng. Tổ chức bắt đầu với qui trình chuẩn được chấp nhận từ một trong các tổ chức mức 4 của chúng tôi và chúng tôi huấn luyện mọi người tuân theo qui trình chuẩn đó khi chúng tôi thuê họ. Không có thay đổi văn hoá, không có lịch sử quá khứ vì nó là tổ chức chi nhánh mới. Chúng tôi lập kế hoạch tuân theo qui trình này cho tất cả các tổ chức mới của mình được mở trên toàn thế giới. Chúng tôi được lợi nhiều lắm bởi vì tổ chức mức 5 của chúng tôi  có năng suất rất cao, đáp ứng tốt hơn cho khách hàng, công việc làm phần mềm tại chỗ làm việc tốt với phần mềm thương mại bán ngoài thị trường (COTS),  và, hầu hết trong chúng, chi phí là rất hợp lí.  Nhưng tất nhiên, Citibank vẫn có nhiều tổ chức mức 1 và bạn có thể dễ dàng nhận ra họ: Không ai đến họp đúng giờ và nhiều người đi muộn. Mọi người đều bận dự họp hầu hết thời gian và chẳng ra quyết định nào. Không có chương trình nghị sự cho cuộc họp mà chỉ gặp gỡ và nói. Không ai ghi lại biên bản cuộc họp cho nên không ai biết cái gì đã xảy ra. Người quản lí nghiệp vụ vẫn ra lệnh cho mọi người làm dự án ba năm trong mười sáu tháng, và cuối cùng được thăng cấp lên vị trí mới nhanh chóng về sau cho nên chẳng ai đảm nhiệm cho dự án cả. Nhóm dự án cố gắng làm  bất kì cái gì họ có thể làm. Để có sản phẩm đưa ra, họ dành khối lượng thời gian khổng lồ, kể cả làm ngoài giờ, một số người có bị ảnh hưởng sức khoẻ (3 người bị đau tim) và thế rồi cuối cùng cái họ chuyển giao lại hoá ra không phải là cái khách hàng muốn. Điều này là phí thời gian, tiền bạc và công cức nhưng chúng tôi đang cải tiến và CMMI là khuôn khổ quả có ích.

Trong cuộc phỏng vấn của tôi, chủ tịch Citibank John Reid bước vào văn phòng của Suzanne và sau phần giới thiệu chính thức ông ấy tham gia vào cuộc đối thoại. Ông Reid nói về công ti của mình là “công ti đẳng cấp thế giới”. Ông ấy nói: “Chuyển lên một mức sẽ giúp giải quyết điều khó xử gay cấn: Việc thiếu năng lực để đáp ứng cho nhu cầu. Bất kì khi nào năng lực không thích hợp để giải quyết nhu cầu, chúng tôi đều cần làm việc bù trừ nào đó. Bù trừ được thực hiện ở mức độ trưởng thành khác nhau: ở mức 1, ông không có bù trừ bởi vì mọi thứ đều không rõ ràng, ông phản ứng lại mọi thứ. Ở mức 2, ông đáp ứng tương ứng theo kế hoạch và bù trừ là quản lí thấy được. Ở mức 3, ông có qui tắc – dựa trên việc thực hiện khách ông thực hiện việc bù trừ của mình. Ở mức 4, ông có đủ dữ liệu để đoán trước sự việc, chỉ ở mức này ông mới có thể thực sự quản lí theo sự kiện và dữ liệu. Ở mức 5, ông tối ưu bù trừ của mình và đoán trước mọi sự theo cách nhất quán và thực sự mở rộng nghiệp vụ của ông bằng việc nắm bắt thị trường”.

Hỏi: Tôi tin CMMI là tốt cho việc phê bình hay chỉ cho phát triển mới phần mềm. Chúng tôi bảo trì phần mềm cho các hệ thống cũ và như thế chúng tôi không có các yêu cầu tuyến cơ sở như phần mềm sản xuất nguyên gốc.  Do đó, tôi nghĩ CMMI không dành cho chúng tôi.

Đáp: CMMI không phải là thiết kế phần mềm mấu chốt hay chỉ phát triển phần mềm mới. Nhiều tổ chức đã đạt tới mức độ cao hơn, đã giảm chi phí, chu kì thời gian, và chất lượng được cải tiến, quả thực đang trong miền Bảo trì.

Chẳng hạn, trong môi trường bảo trì bạn có thể làm nhiều cập nhật (Đưa ra) dựa trên các tuyến cơ sở khác nhau. Với mỗi cập nhật bạn sẽ lập kế hoạch, ước lượng (kích cỡ, tài nguyên, lịch biểu), và theo dõi tiến độ. Bạn có lẽ sẽ có ban thay đổi để chấp thuận yêu cầu thay đổi và báo cáo lỗi. Bạn sẽ có kế hoạch đưa ra và theo dõi tiến độ theo kế hoạch đó. Bạn sẽ tiến hành các cuộc kiểm điểm ngang quyền, thảo luận trình bày mã và làm những hành động sửa chữa thích hợp. Rồi bạn sẽ kiểm thử phần mềm của mình để bảo đảm nó làm việc. Nếu bạn làm những điều này, thì CMMI có thể được áp dụng vào môi trường của bạn.  Về căn bản, CMMI có thể được dùng trong bất kì môi trường phần mềm nào, bất kể vòng đời, công nghệ, phương pháp luận, hay cấu trúc tổ chức. Nó là khuôn khổ để đo sự trưởng thành năng lực của tổ chức.

—-English version—-

CMMI-1

Question: My organization wants to start a process improvement program using the CMMI as the framework. What would be the first step? Conduct an appraisal? Train Lead appraisers? Form a Software Engineering Process Group (SEPG)?

Answer: The decision to start a process improvement program in an organization is a business decisions and it must be taken seriously. Therefore, you must address several things before starting the improvement efforts.

  1. Obtain commitment from your organization’s senior management for the process improvement. Commitment means they are fully aware, understand and willing to support which is much more than a permission to start the improvement.

1.

  1. Communicate the business reason for process improvement – People in your organization need to know why you want to start an improvement program. What are the goals and objectives? What are the expectations?
  2. Establish a group specializes in process improvement such as the Software Engineering Process Group (SEPG). The key factor in most successful improvement programs is the establishment of this supporting group. If this group does not have a clearly defined roles, responsibilities, and authority to implement, real improvement may not happen.

I have seen many organizations start process improvement with an appraisal but did not pay attention to the establishment of a group to coordinate and facilitate improvement activities. If the organization only focuses on having appraisal rather than solve critical issues or develop an improvement group then who will coordinate and implement improvement activities after an appraisal?

Question: What is a Software Engineering Process Group (SEPG)?  What are they supposed to do?

Answer: The Software Engineering Process Group (SEPG) is a group of internal “Change agents” established to help an organization to improve its processes. As a group SEPG must:

  • Have a charter describing how it will support the organization in its process improvement activities.
  • Have team member specialize in some aspect of software engineering disciplines such as Requirements, Design, Code, Test, Release, Estimates, and Metrics etc.
  • Be able to “pilot” new practices to solve critical issues before advocating widespread use in the organization (Institutionalization)
  • Spend some time in developing new practices but more time in getting them used by software practitioners.
  • Not wasting time developing document that is of little use to the organization. Keep process documentation to a few useful pages only.
  • Measure its successes based upon the perceived usefulness of the services determined by software engineers and managers in the organization.
  • Keep in touch with other SEPG for exchanging and sharing of best practices and lessons learned.

In summary, a good SEPG is the group that could help the organization improves its performance and solves its key issues.

Question: Is it possible for an organization that has already achieved a high maturity level to fall back to a lower maturity level?

Answer: Yes, it is possible for an organization to fall back to a lower level of maturity. Typically, at level 2, many practices are not fully institutionalized yet. If organizations start to relax, a “business as usual” attitude will return. An appraisal is only a snapshot of the organization’s capability in time. Organization capability could change whenever an organization changes, people change, or the infrastructure changes. Reorganization and key personnel turnover are the common causes of the maturity fall back. My advice is always keeping the momentum going, regardless of maturity levels. The organization must aim for the next level even when they achieved level 5. The only way to keep from falling back is to keep on improving. Remember improvement is continuous. Please do not stop and relax, improvement means on going all the time.

Question: Is it possible to conduct a single appraisal for a large software organization of 10,000 people or more? Is it possible for them to achieve CMMI level 3?

Answer: Based on my own experience, an appraisal works best for a group of approximately 100 to 1000 people. Beyond that, many people or projects could be left under-represented.

Why do you want to conduct a single appraisal for a very large organization? Does the organization really have 10,000 people working on a single domain or application? Are they all located at the same place? Are they developing one system or many systems?

If a large organization consists of many applications or domain areas then the scope of the appraisal should focus on the domain level. You may need to conduct several appraisals for each domain area. The results could be rolled up; that is, if all domain areas are assessed at CMMI level 3 then the entire organization will be at level 3.

The purpose of the appraisal is to identify critical issues to solve and each domain may have different issues that require different solutions to solve. Putting all of them into a single appraisal may not be a good idea.

Question:  I want to be a “Change Agent”, How do I start? I am inspired to improve my organization for the better.

Answer: If you really want to be a Change Agent, it is best to begin by introducing a change into your own way of doing things. You may want to ask yourself these questions:

1)     What steps can I take to improve my skills?

2)     Where have I documented my processes?

3)     What metric do I use to measure my effectiveness?

4)     What have I done to foster innovation in myself?

The author Mark Twain said: “Nothing needs improvement so much as other people’s processes”. What words of wisdom! So before you attempt to change your organization for the better, make the changes you can within yourself, and then try to change something clearly within your control. You’ll be more likely to succeed and you will have the leverage introduce change to others.

Question: My manager wants to know how long does it take to move from one level to another level of the CMMI? Is it possible to achieve level 3 within a year? We have not had an appraisal yet.

Answer: Based on data from the Software Engineering Institute at CarnegieMellonUniversity, the time required to move up the maturity model was approximately 25 months from level 1 to 2, and 24 months from 2 to 3. However, based on my own experience, it would take approximately 36 months to move from level 1 to level 2 and 24 months from level 2 to level 3.

Setting a goal to be level 3 without an appraisal is like traveling in the jungle without knowing where you are. You should ask yourself what does level 3 means to you and your organization. Is it a magic number or something else? What are the business goals of process improvement? Is it an improvement in quality, cycle time, productivity, and cost or only a meaningless maturity level number?

Question: How can we sustain process improvement? We had an appraisal two years ago and made some improvements but the momentum has slowed down recently.

Answer: To sustain a process improvement you need three key factors: Accountability, Involvement, and Metrics.

1)         Accountability: Process improvement should be organized so that people cannot ignore it. Your management should treat improvement activities like projects and monitor every improvement tasks on a monthly basis and insist on performance.

2)         Involvement: Process improvement cannot succeed by itself. Everybody in the organization must be informed and involved in solving problem that the organization encountered. The success of improvement tasks should be treated as equally important as is delivering the software product.

3)         Metrics: Process improvement must be designed with measurable goals that relate to the business of the organization. These should be tracked and analyzed carefully on a monthly basis. Improvement data should be communicated across the organization because without improvement data, management will be reluctant to invest in future activities and without investment funding, future improvement efforts will not happen.

Question: I noticed that Citibank is achieving CMMI maturity level 5 in an Wall Street Journal. I am very impressed that a bank, not a software organization can improve that much. Is it true that any company could achieve higher maturity levels?

Answer: Since Suzanne Kelly, the Vice President in Citibank is a friend so I called her and she confirmed that it was Citibank, India that achieved the maturity level 5. Suzanne also shared with me the improvement activities at her company as followed:” Citibank process improvement started five years ago and any group with more than 400 employees engaged in a software development must undergo an appraisal. To date, Citibank had 42 appraisals with 75% at level 1, 15% at level 2, 10% at level 3 and one exception Citibank, India at level 5.”

Suzanne also shared with me that Citibank has changed significantly in the last five years by taking a number of key actions:

1)     Managing by process rather than product

2)     Using process and benchmarking to identify opportunities for improvement.

3)     Emphasizing continuous improvement and incremental change

4)     Relying on customer satisfaction as the main factor of performance

5)     Treating all suppliers as partners

Suzanne attributed the success of Citibank to the following principles: “Process success depends on both tasks and people. She pictures one wheel of a bicycle as the task wheel, and other as the people wheel. She said there must be a balance between the two. Task information involves both “What” and “How”, while people must be both willing and able to carry out the tasks assigned to them.

She emphasized:  If a person is not able to carry out a task, it does not matter that they are willing. – If a person is not willing to carry a task, it does not matter that they are able to. If a person is carrying the wrong task, it does not matter that they know how to do it. If a person does not know how to carry out a task, it does not matter that they have been directed to do the right task.

She jokingly attributes her principles as “Process improvement as the art of riding motorcycle: “The motorcycle must be fast, balanced, fine tuned, and customized to the owners. Both motorcyclist and software developers must have clear vision, skills, be part of a team, and always be learning.

She also indicated that the motivation for Citibank to adopt the CMMI is due to the rapid change in the business and technology. She said: “Many people never think a financial institution would use the CMMI as a framework for improvement but after using it we think it is great. We develop a lot of software in-house, we also buy a lot of software, and the integration must work. There is a need for business managers to better understand technology and there is also need for the technologist to understand the business. The CMMI has been useful in explaining the situation to both technologist and business managers. Currently there are 10,000 technologists at Citibank, of which 5,000 are software developers.

She also shared the process at her level-5 organization as follows: “The organization was designed to be level 5. We hire managers who have the right skills and experience. The organization started with a standard process adopted from one of our level 4 organization and we trained people to follow that standard process when they were hired. There is no cultural change, no past history since it is a brand new organization. We are planning to follow this process to all of our new organizations to be opened worldwide. We have seen significant benefits because our level 5 organization has very high productivity, better response to customer, in-house software works well with commercial-off-the-shelf (COTS),  and, most of all, the cost is very reasonable.  But off course, Citibank still have many level 1 organizations and you can spot them easily: No one is at the meeting on time and many are late. Everybody is busy attending meeting most of the time and not making any decision. There is no agenda for meeting but just meet and talk. No one is recording meeting minutes so no one knows what happened. Business manager still orders people to do a three year project in sixteen months, and eventually move to a new position soon after so no one accountable for the project. The project group tries to do whatever they can. To get the product released, they spend a huge amount on overtime, some experienced health problems (3 Heart Attacks) and then finally what they delivered turned out to be not what the customer wanted. This is a waste of time, money and efforts but we are improving and the CMMI as a framework does help.

During my phone interview, Citibank chairman John Reid walked into Suzanne office and after a formal introduction he joined the conversation. Mr. Reid talks about his company being a “world class company”. He said: “Moving up a level will help in dealing with a major critical dilemma: The lack of capacity to deal with demand. Whenever capacity is not adequate to handle demand, we need to make some kind of trade-off. Trade-off is made at different maturity levels: At Level 1, you have no trade-off because everything is unclear, you react to things. At level 2, you respond according to a plan and the trade off is visible to management. At level 3, you have a rule-based to objectively perform your trade-off. At level 4, you have enough data to anticipate thing, only at this level you can really managing by facts and data. At level 5, you optimizing your trade-off and anticipating things in a consistent manner and really expanding your business by capturing the market”.

Question: I believe -CMMI is good for critical or new development software only. We maintain software for old systems and as such we do not have the baseline requirements as the original production software.  Therefore, I do not think the CMMI is for us.

Answer: The CMMI isn’t design for critical software or new development only. Many organizations that have achieved higher levels, have reduced costs, cycle time, and improved quality, were indeed in MAINTENANCE areas.

For example, in a maintenance environment you might do multiple updates (Releases) based on different baselines. For each update you would plan, estimate (size, resources, schedule), and track progress. You would probably have a change board to approve change requests and bug reports. You would have a release plan and track progress according to that plan. You would conduct peer reviews, code walkthrough and take appropriate corrective actions. Then you would test your software to make sure it works. If you do these things, then the CMMI can be applied to your environment.  Basically, the CMMI can be used in any software environment, regardless of life cycle, technology, methodology, or organization structure. It is a framework for measuring organization capability maturity.