Hỏi: Tại sao các thành viên SEPG cần huấn luyện về cải tiến qui trình? Họ có là chuyên gia trong cải tiến không?

Đáp: Để tôi chia sẻ với bạn về một tình huống thực.

Một công ti bắt đầu cải tiến qui trình vài năm trước đây. Người quản lí cao nhất là người ủng hộ nhiệt thành, người dành ra nhiều tiền cho cải tiến. Không may là họ không có người nào có kinh nghiệm trong cải tiến qui trình cho nên họ đã lựa người kĩ thuậtgiỏi nhất mà họ có thể tìm được. Tổ kĩ thuật không nhận được huấn luyện gì mà chỉ dựa trên kĩ năng phân tích của mình và đọc sách CMMI. Họ trả tiền cho một nhà tư vấn để tiến hành việc đánh giá và bắt đầu lập kế hoạch hành động. Họ đã lập kế hoạch và sửa đổi bản kế hoạch này trong nhiều tháng trong khi tổ chức tiếp tục chờ đợi những điều cần làm. Sau mười tháng, đà bị giảm đi, kinh doanh không cải thiện, mong đợi bị nao núng và bỗng nhiên, có giận dữ và thất vọng trong các thành viên tổ. Nhiều người ra đi và được thay thế bởi nhóm người kĩ thuật khác. Người mới không thích bản kế hoạch này cho nên họ sửa lại và lập kế hoạch lại cho nó. Một năm nữa trôi qua mà chẳng có hành động nào mãi cho tới khi người quản lí cấp cao nhất mất kiên nhẫn và bảo họ dừng toàn thể việc lại. Đó là chấm dứt của cải tiến qui trình.

Nếu như họ đã huấn luyện, họ có thể đã tránh được việc phạm sai lầm bằng việc lập kế hoạch quá đáng và chắc đã đi xa trên con đường cải tiến qui trình. Bởi vì thất bại của việc cải tiến, tổ chức đã không được lợi từ việc cải tiến qui trình mà cũng không đạt tới được mục đích và mục tiêu doanh nghiệp. Tuy nhiên, có những hậu quả khác. Cải tiến tương lai bị lâm nguy vì sự chống đối thay đổi đã tăng lên một cách đáng kể, lòng tin vào các thành viên SEPG bị tan tành và sự tin cậy vào quyền lãnh đạo của cấp quản lí xuống mức thấp nhất. Thay đổi là làm mọi thứ theo cách mới và làm cho thay đổi xảy ra không phải là điều trực cảm mà là kĩ năng thu được qua học tập và trải nghiệm. Các blog của tôi được tạo ra  từ nhiều bài học rút ra từ nhiều công ti và học từ sai lầm của người khác là tốt hơn tự mình phạm sai lầm.

 

Hỏi: Khi nào là lúc tốt nhất cho kiểm thử phần mềm? Chúng ta có nên đợi cho tới khi việc viết mã được hoàn  thành rồi mới thực hiện một loạt các kiểm thử không?

Đáp: Tôi tin kiểm thử nên bắt đầu vào lúc bắt đầu của dự án. Việc lập kế hoạch và thiết kế kiểm thử nên bắt đầu vào lúc bắt đầu của vòng đời phần mềm – pha yêu cầu. Kiểm thử chấp nhận nên được người dùng xác định vào cùng lúc yêu cầu của người dùng được xác định. Kiểm thử hệ thống nên được xác định trong khi phân tích yêu cầu. Kiểm thử tích hợp nên được xác định trong thiết kế kiến trúc; và kiểm thử đơn vị nên được xác định trong thiết kế chi tiết. Thậm chí có thể xác định kiểm thử trước khi phát triển các vật chuyển giao trong vòng đời. Đừng đợi cho tới “phút cuối cùng trước hạn chót” vì bạn không có thời gian để kiểm thử đúng sản phẩm.

Hỏi: Để  giảm chi phí, chúng tôi quyết định đưa vào trong tổ chức của mình phương pháp phần mềm mới. Chúng tôi muốn mọi dự án đều tuân theo phương pháp chuẩn này để cho chúng tôi có thể đạt tới CMMI mức 3. Thầy nghĩ sao?

Đáp: Trước khi đưa bất kì phương pháp nào mới vào tổ chức, cần phải rõ ràng rằng bạn có hoàn cảnh nghiệp vụ – tiết kiệm và ích lợi sẽ cân xứng với chi phí phải trả kể cả chi phí vận hành, và chi phí bắt đầu. Chừng nào tổ chức của bạn còn chưa có phương pháp, việc đưa vào một phương pháp mới là rất mạo hiểm và yêu cầu nhiều nỗ lực và chi phí cao hơn bạn giả định. Xem như một cách khác việc đưa vào phương pháp mới, bạn có thể phải điều tra tại sao phương pháp hiện thời của bạn không có tác dụng và tại sao chi phí phần mềm của bạn lại quá cao và rồi cải tiến phương pháp hiện tại của bạn thay vì đưa vào phương pháp mới.

Nhân tiện, việc đạt tới CMMI mức 3 yêu cầu nhiều thứ hơn là việc có phương pháp chuẩn tại chỗ.

 

Hỏi: Tại sao người phát triển phần mềm cần nhiều huấn luyện trong cả đời mình?

Đáp: Bởi vì công nghệ liên tục thay đổi nhưng hầu hết người làm phần mềm không làm nỗ lực nào để vẫn còn cập nhật về mặt kĩ thuật. Nhiều người không đọc sách kĩ thuật, không dự các hội nghị, hay học các môn kĩ thuật phụ. Đây là kết quả của một nghiên cứu tôi đã tiến hành trong nhiều năm qua:

1.      Nhiều người phát triển phần mềm đọc báo, tạp chí, nhưng ít hơn 1% đọc sách kĩ thuật trên cơ sở đều đặn.

2.      Một số người phát triển phần mềm có dự các lớp tập huấn địa phương, các hội thảo nhưng chỉ 8% tham dự các hội nghị phần mềm quốc tế để mở rộng hơn kĩ năng của họ.

3.      Người phát triển phần mềm dành ít hơn 5 giờ một tháng để được thông báo về các biến cố kĩ thuật mới nhất trong lĩnh vực của họ.

Trên năm nghìn người phát triển phần mềm đã tham gia vào nghiên cứu này. Họ tất cả đều có bằng đại học và trung bình có hơn 5 năm kinh nghiệm. Dựa trên kết quả này, tôi mạnh mẽ tin tưởng người phát triển phần mềm cần huấn luyện kĩ thuật để vẫn còn được cập nhật với thay đổi công nghệ.

Hỏi: Khi triển khai các hoạt động cải tiến qui trình, chúng tôi lâm vào nhiều xung đột giữa các nhóm. Làm sao chúng tôi giải quyết xung độ liên nhóm này?

Đáp: Điều này rất thông thường trong các nhóm phần mềm nơi mọi người có xu hướng coi nhóm mình là duy nhất. Sau đây là một số gợi ý có thể có tác dụng.

1.      Người quản lí của các nhóm đang xung đột trước hết bản thân họ phải định giải quyết vấn đề.

2.      Nếu người quản lí đi tới ngõ cụt, vấn đề nên được thăm dò một cách không chính thức với từng người quản lí một cách tách biệt, và rồi cả hai người đó nên gặp gỡ nhau, không để giải quyết vấn đề mà để đồng ý về cách giải quyết nó.

3.      Nếu người quản lí được thông báo rõ ràng và có cam kết với các vị trí riêng của họ, điều thường có ích là hình thành một tổ với các thành viên được lấy ra từ từng nhóm. Tuy nhiên người lãnh đạo tổ nên là người trung lập – thành viên SEPG chẳng hạn – bằng không, tổ này sẽ trở nên bị phân cực tại chỗ bắt đầu và rất có thể sẽ hầu như không tiến bộ được.

4.      Để giảm rủi ro, tổ này nên đề cập tới một phần của vấn đề, bắt đầu bằng việc hội tụ vào các vấn đề kĩ thuật và bỏ qua các mối quan tâm về tổ chức hay cán bộ.

5.      Trong hầu hết các trường hợp, một khi có giải pháp kĩ thuật được thoả thuận, người quản lí có thể tự mình nhanh chóng giải quyết các vấn đề còn lại.

 

Hỏi: Tại sao chúng ta cần cải tiến qui trình ở mức tổ chức chứ không ở mức cá nhân?

Đáp: Lí do để thiết lập một cấu trúc tổ chức là để phân công công việc. Nếu một người có thể làm được tất cả công việc một mình, sẽ chẳng cần cấu trúc nào cả. Nếu mọi sự không làm việc, một người có thể dễ dàng quyết định phải làm gì và cải tiến gì. Khi bạn có nhiều người, mọi sự trở nên phức tạp vì không ai muốn sửa sai lầm của ai đó khác. Vì một người không thể xây dựng được hệ thống phần mềm lớn, cấu trúc tổ chức của nhiều người được thiết lập ra. Để tổ chức đạt tới các mục đích và mục tiêu nghiệp vụ của nó, một số qui trình phải được đưa vào thực tế tại chỗ. Để làm tối ưu hoá các mục đích và mục tiêu doanh nghiệp, một số qui trình có thể cần cải tiến.

 

Hỏi: Chúng tôi có việc đánh giá CMMI 6 tháng trước đây nhưng tôi chưa thấy gì xảy ra cả. Tôi muốn thấy SEPG của chúng tôi đi tới một bản kế hoạch để cho tôi có thực hiện cái gì đó. Tôi sẽ tiếp tục đợi chứ? Kiên nhẫn của tôi đang tan dần.

Đáp: Không, đừng đợi. Sáu tháng đã là quá lâu rồi. Nếu tôi mà là bạn tôi đã trực tiếp yêu cầu các thành viên SEPG về bản kế hoạch và người tình nguyện làm việc về một số nhiệm vụ. Có thể họ đã có bản kế hoạch rồi và đang tìm ai đó như bạn để làm việc về một nhiệm vụ. Dường như tổ chức của bạn có thể bị gián đoạn trao đổi rồi. Trong thời đại của email, fax, điện thoại, đôi khi chúng ta có xu hướng chờ đợi và quên mất hỏi các câu hỏi. Xin hãy nói với nhau, xin hãy trao đổi và trao đổi.

 

Hỏi: Là người quản lí, tôi thích ý tưởng về thừa nhận và thưởng cho mọi người. Tôi có thể tìm tài liệu về qui trình thừa nhận và thưởng ở đâu để tôi có thể áp dụng rộng trong tổ chức của tôi, mà đã có hơn 1200 người?

Đáp: Gợi ý của tôi là có lẽ bạn không muốn thừa nhận mọi người cùng một lúc, và có lẽ bạn không cần một “anh hùng” mỗi tuần. Thừa nhận là đánh giá cao nỗ lực của một người làm điều gì đó ngoại lệ, không phải là qui trình bạn phải tuân theo hay phải tuân thủ mọi tuần. Nó là hành động đơn giản chỉ ra rằng bạn quan tâm và bạn có đánh giá cao mọi người trong tổ chức của bạn. Lời khuyên của tôi là cứ tự nhiên, dừng lại ở bàn của họ, nói chuyện với họ, hỏi về cách họ làm, nói cho họ rằng bạn có chú ý tới nỗ lực của họ. Bất kì cái gì từ trái tim bạn đều sẽ truyền đạt sự đánh giá cao còn hơn nhiều qui trình được làm tài liệu cứng nhắc.

 

Hỏi: Tại sao dự án phần mềm bao giờ cũng chịu dưới sức ép lịch biểu?

Đáp: Vấn đề nền tảng có thể là ước lượng lịch biểu không hợp lí. Vài kĩ sư phần mềm biết cách ước lượng, lập kế hoạch, và theo dõi công việc của họ. Không có những bộ môn này, họ không có khả năng lập kế hoạch công việc hay dự án tương ứng, và không có lập kế hoạch thích hợp họ bao giờ cũng bị dưới sức ép.

Hỏi: Tại sao quản lí phần mềm lại quan trọng thế và bao giờ cũng yêu cầu cao?

Đáp: Kĩ nghệ phần mềm là qui trình chủ yếu với con người và các phương pháp để quản lí con người, tài nguyên, và rủi ro bao giờ cũng có tác động sâu sắc lên dự án phần mềm. Quản lí phần mềm là phụ thuộc vào tình huống, và những bù trừ. Khó đưa ra được mô tả xác đáng về nhiều khái niệm và duy trì sự chính xác của trình bày qua miền rộng các lĩnh vực. Việc hiểu sự khác biệt giữa chính xác và xác đáng là kĩ năng nền tảng của người quản lí phần mềm giỏi, người phải dự báo xác đáng các ước lượng, rủi ro, và tác động của thay đổi. Không có “công thức ảo thuật” cho quản lí phần mềm nhưng có vấn đề đánh giá, theo nghĩa thường, và ra quyết định tuỳ theo tình huống. Đó là lí do tại sao người quản lí phần mềm bao giờ cũng được trả nhiều tiền.

 

Hỏi: Sau đánh giá CMMI, chúng tôi đã tổ chức ra Tổ hành động qui trình Process Action Team (PAT) để xác định qui trình chuẩn. Chúng tôi dành chín tháng qua để làm tài liệu qui trình mới mà chúng tôi nghĩ có thể cải tiến tổ chức chúng tôi nhưng nhiều người phát triển đã phàn nàn rằng chúng tôi đã không làm tiến bộ nào. Chúng tôi đã làm cái gì sai?

Đáp: Sau việc đánh giá, nhiều công ti đã thành lập “Nhóm công tác” hay “Tổ hành động qui trình – Process Action Team” (PAT) quanh các miền qui trình Process Areas (PA) như quản lí dự án, quản lí yêu cầu, đảm bảo chất lượng. Họ cố gắng xác định qui trình chi tiết cho toàn bộ miền qui trình và điều này là rất rủi ro do kích cỡ và độ phức tạp của thay đổi. Tôi đã thấy nhiều tổ thất bại theo cách tiếp cận này. Ngay cả khi họ thành công trong việc xác định qui trình, việc thực hiện qui trình được xác định rõ này thường lao vào các vấn đề vì nó yêu cầu mọi người thay đổi hoàn toàn cách họ làm mọi thứ. Tôi đã nghe nói nhiều thành viên SEPG phàn nàn rằng, “Mọi người không muốn thay đổi” hay “Cấp quản lí thực sự không hỗ trợ điều này.”  Điều bạn cần  hiểu là ở chỗ cách tiếp cận PA hay việc xác định các qui trình PA chi tiết về bản chất là quá lớn, yêu cầu nỗ lực lâu dài và quá khó cho tổ chức tuân theo. Điều này cũng giống như ăn cả con voi bằng một miếng cắn. Gợi ý của tôi là chia nhỏ PA thành những nhiệm vụ nhỏ hơn. Bạn cần triển khai từng nhiệm vụ như một dự án nhỏ và tuân theo pha triển khai Xác định, Thử nghiệm, Làm mịn, và thể lệ hoá. Cách tiếp cận này ít rủi ro hơn và có thể làm cho thay đổi xảy ra sớm hơn.

 

Hỏi: SEPG của chúng tôi đã thiết kế việc thẩm định chỉ mất 3 ngày thay vì 2 tuần.  Chúng tôi cũng thiết kế một thẩm định mini 1 ngày và lập kế hoạch thiết kế thẩm định nhanh khác có thể làm điều đó trong vài giờ. Chúng tôi muốn chia sẻ những kĩ thuật này với các SEPG khác. Thầy nghĩ sao?

Đáp: Tôi tự hỏi liệu SEPG của bạn là trong “doanh nghiệp thẩm định” hay “doanh nghiệp cải tiến qui trình”? Tại sao bạn cần nhiều thẩm định thế? Thẩm định không có nghĩa gì nếu công ti của bạn không cải tiến. Tôi tin điều công ti bạn cần là giảm chi phí, và cải tiến chất lượng không nhiều hơn kĩ thuật thẩm định.

 

Hỏi: Với tôi dường như là công nghệ đã thay đổi có ý nghĩa nhưng quản lí thì lại không thay đổi. Điều khôn ngoan là cải  tiến khía cạnh quản lí chứ không phải là khía cạnh công nghệ?

Đáp: Để cải tiến qui trình, người ta phải xem xét cả ba nhân tố qui trình: Con người, Chuẩn và Công nghệ. Bạn không thể cải tiến cái này mà không có cái khác.

 

Hỏi: Làm sao chúng tôi bắt đầu chương trình đo cho tổ chức CMMI mức 1? Loại đo nào được cần tới?

Đáp: Để bắt đầu chương trình đo cho tổ chức CMMI mức 1, tôi đề nghị một tập các cách đo cơ sở như sau:

1)  Chất lượng (lỗi trước và sau khi đưa ra)

2)  Thời gian chu kì (Thời gian để hoàn thành một nhiệm vụ)

3)  Nỗ lực

4)  Biến thiên (Theo kế hoạch so với thực tế về thời gian, kích cỡ, chi phí)

Tập trên chỉ  là hướng dẫn, không phải là yêu  cầu nhưng nó sẽ giúp cho tổ chức bắt đầu tập trung vào việc đo sớm hơn.

Để đạt tới mức độ trưởng thành 2, tổ chức phải có qui trình thu thập dữ liệu tại chỗ và bằng chứng rằng người quản lí dự án thực hiện hành động sửa chữa dựa trên những dữ liệu đó.

Định nghĩa về dữ liệu và bao nhiêu cách đo được cần tới có thể thay đổi từ dự án nọ sang dự án kia (với CMMI mức 2) nhưng phải nhất quán trong toàn tổ chức (với CMMI mức 3). Do đó, thay vì bắt đầu bằng cách tiếp cận “kệ làm” với việc đo, nơi từng dự án có thể thể quyết định bất kì cái gi họ muốn, tôi gợi ý tổ chức xác định một danh sách các cách đo và cho phép từng dự án lựa lấy vài cách đo từ danh sách này.

 

Hỏi: Việc cải tiến qui trình của chúng tôi đã dừng lại. Làm sao tôi làm cho nó chạy được?

Đáp: Tôi thực sự muốn biết tại sao nó đã dừng. Có phải vì thiếu cam kết của cấp quản lí? Hay thiếu hiểu biết về điều cần làm tiếp? Bạn có đủ tài nguyên không? Bạn có người đúng với kĩ năng đúng trong SEPG của bạn không? Nó là vấn đề động cơ hay vấn đề kinh tế? Về quản lí cấp cao của bạn thì sao? Bạn có tuân theo bản lộ trình cải tiến không?

Trước khi chúng ta bắt đầu lại một qui trình, bạn cần hiểu căn nguyên gốc rễ và làm hành động sửa chữa. Không hiểu nguyên nhân, bạn sẽ phí thời gian của mình vì lịch sử bao giờ cũng lặp lại bản thân nó.

—-English version—–

 

CMMI-19

Question: Why do SEPG members need training for process improvement? Are they the expert in improvement already?

Answer: Let me share with you a real situation.

A company started process improvement few years ago. The top manager was a good supporter who set aside a lot of money for improvement. Unfortunately, they had no one who was experienced in process improvement so they selected the best technical people they could find. The technical team received no training but relied on their analytical skills and the CMMI book. They paid a consultant to conduct an appraisal and started their action planning. They planned and revised the plan for many months while the organization continued to wait for things to do. After ten months, the momentum faded, the business did not improve, the expectations faltered and suddenly, there was anger and frustration among team members. Many quit and were replaced by another group of technical people. New people did not like the plan so they revised and re-planned it. Another year passed with no action until the top manager lost patience and told them to stop the whole thing. That was the end of process improvement.

If they had training, they could have avoided making mistakes by excessive planning and would have been well on their way to improving their processes. Because of the failure to implement, the organization did not benefit from its process improvement nor did it achieve the business goals and objectives. However, there were other consequences. Future improvement is at risk since resistance to change has significantly increased, the credibility of SEPG members was shattered and the confidence in management leadership is at the lowest level. To change is to do things in a new way and to make change happen is not intuitive but a skill acquired via learning and experiencing. My blog is created from so many lessons learned from many companies and it is better to learn from someone else’s mistake than to make one.

 

Question: When is the best time to test software? Should we wait until the coding is completed then execute a series of tests?

Answer: I believe testing should start at the beginning of a project. The planning and design of testing should start at the beginning of the software life cycle—requirements phase. Acceptance tests should be defined by users at the same time that user requirements are defined. System tests should be defined during requirements analysis. Integration tests should be defined during architectural design; and unit tests should be defined during detailed design. It is possible even to define tests before developing the life cycle deliverables. Do not wait until “the last minute before deadline” since you do not have time to properly test the product.

 

Question: To reduce cost, we decided to introduce a new software method to our organization. We like to have all projects follow this standard method so we can achieve CMMI level 3. What do you think?

Answer: Before introducing any new method into an organization, it must be clear that you have a business case—the savings and benefits will outweigh the costs incurred including the ongoing running costs, and the start up costs. Unless your organization has no method, introducing a new one is very risky and requires more effort and higher cost than you assume. As an alternative to a new method, you may want to investigate why your current method doesn’t work and why your software cost is too high and then improving your existing method rather than introducing a new one.

By the way, to achieve a CMMI level 3 requires much more than having a standard method in place.

 

Question: Why do software developers need more training throughout their life?

Answer: Because technology continues to change but most software developers do not make effort to stay technically up to date. Many do not read technical books, attend conferences, or take additional technical courses. Here are the results of a research that I have conducted several years ago:

1.      Many software developers read newspapers, magazines, but less than 1% read technical books on a regular basis.

2.      Some software developers do attend local workshops, seminars but only 8% attend international software conferences to broaden their skills.

3.      Software developers spent less than 5 hours per month in keeping informed of the latest technical events in their field.

Over five thousand software developers participated in this research. They all had college degrees and an average of more than 5 years of experiences. Based on this result, I strongly believe software developers need technical training to stay up to date with technology changes.

 

Question: When deploying process improvement activities, we ran into a lot of conflicts among groups. How do we solve this intergroup conflict?

Answer: This is very common among software groups where people tend to think their group is unique. Following are some suggestions that may work.

1.      The managers of the conflicting groups should first attempt to resolve the issues themselves.

2.      If the managers reach an impasse, the issues should be informally explored with each manager separately, and then both of them should be brought together, not to settle the issue but agree on a way to settle it.

3.      If the managers are well informed and committed to their own positions, it is often helpful to form a team with members taken from each group. The team leader, however, should be neutral—a SEPG member for example—otherwise, this team will become polarized at the outset and will likely make little progress.

4.      To reduce the risks, this team should address a portion of the issue, starting with focusing on technical issues and ignoring organizational or staffing concerns.

5.      In most cases, once there is an agreed technical solution, the managers can quickly resolve the remaining questions themselves.

 

Question: Why do we need to improve the process at the organizational level and not at the personal level?

Answer: The reason for establishing an organizational structure is to allocate work. If one person can do all the work alone, no structure would be needed. If things do not work, one person can easily decide what to do and what to improve. When you have more than one person, things get complicated since no one likes to fix someone else’s mistakes. Since one person can not build a large software system, an organizational structure of many people is established. For an organization to achieve its business goals and objectives, certain processes have to be in place. To maximize the business goals and objectives, some process may need to improve.

 

Question: We had CMMI appraisal 6 months ago but I have not seen anything happening yet. I want to see our SEPG come up with a plan so I can implement something. Shall I continue to wait? My patience is running out.

Answer: No, do not wait. Six months is too long already. If I were you I would ask the SEPG members directly about the plan and volunteer to work on some tasks. Maybe they already have a plan and are looking for someone like you to work on a task. It seems like your organization may have a communication break down. In the era of e-mail, fax, phone, sometime we tend to wait and forget to ask questions. Please talk to each others, please communicate and communicate

 

Question: As a manager, I like the idea of recognize and reward people. Where can I find a document process for the recognition and reward so I can apply broadly across my organization that has over 1200 people?

Answer: My guess is you probably do not want to recognize everybody at the same time, and you probably do not need a “Hero” every week. To recognize is to appreciate one’s effort of doing something exceptional, not a process that you have to follow or adhere to every week. It’s the simple act of showing that you care and you do appreciate the people in your organization. My advice is just be natural, stopping at their desk, talking to them, inquiring on how they are doing, telling them that you do notice their efforts. Anything from your heart will convey the appreciation much better than any rigid documented process.

 

Question: Why software project is always under schedule pressure?

Answer: The fundamental problems could be unreasonable schedule estimates. Few software engineers know how to estimate, plan, and track their work. Without these basic disciplines, they are not able to plan their work or project accordingly, and without adequate planning they are always under pressure.

 

Question: Why software management is so important and always in high demand?

Answer: Software engineering is a people-intensive process and methods for managing people, resources, and risks always have profound impact on the software project. Software management is a situation dependencies, and trade-offs. It is difficult to provide an accurate depiction of many concepts and to retain precision of the presentation across a broad range of domains. Understanding the difference between precision and accuracy is a fundamental skill of good software managers, who must accurately forecast estimates, risks, and the effects of change. There is no “magic formula” for software management but a matter of judgment, common sense, and situation-dependent decision making. That’s why software managers are always get paid a lot of money.

 

Question: After a CMMI appraisal, we organized a Process Action Team (PAT) to define standard process. We spent the past nine months documented a new process which we think could improve our organization but many developers complained that we have not making progress. What did we do wrong?

Answer: After an appraisal, many companies formed “Working Groups” or “Process Action Team” (PAT) around Process Areas (PA) such as project management, requirement management, quality assurance. They try to define a detailed process for the entire process area and this is very risky due to size and complexity of the change. I have seen many teams failed in this approach. Even when they succeed in define the process, the implementation of this well -defined process usually ran into problems since it required people to completely changing the way they do things. I have heard many SEPG members complained that, “People do not want to change” or “Management really does not support this.”  What you need to understand is that the PA approaches or define a detailed PA processes are inherently too big, require a long effort and too difficult for an organization to follows. This is like eating the whole elephant in one bite. My suggestion is to breakdown the PA into smaller tasks. You need to deploy each task as a small project and follow the deployment phases of Define, Pilot, Refine, and institutionalize. This approach is less risky and could make change happen sooner.

 

Question: Our SEPG have designed an assessment that only takes 3 days instead of 2 weeks.  We also designed a 1 day mini assessment and plan to design another quick assessment that people can do it in a few hours. We like to share these techniques with others SEPG. What do you think?

Answer: I wonder if your SEPG is in “assessment business” or “process improvement business”?. Why do you need so many assessments? An assessment do not mean anything if your company does not improve. I believe what your company need is to reduce cost, and improve quality not more assessment techniques.

 

Question: It seems to me that technologies have changed significantly but management has not. Is it wise to improve the management aspect rather than technology?

Answer: In order to improve the process, one must consider all three factors of process: People, Standards, and Technology. You can not improve one without the others.

 

Question: How do we start a measurement program for a CMMI level 1 organization? What kind of measurements is needed?

Answer: To start a measurement program for a CMMI level 1 organization, I would propose a set of basic measurements as follow:

1)  Quality (Pre and Post released defect)

2)  Cycle time (Time to complete a task)

3)  Effort

4)  Variances (Planned vs. Actuals of time, size. Cost)

The above set is only a guide, not a requirement but it will help the organization to start focus on measurement earlier.

To achieve a maturity level 2, the organization must have a data collection process in place and evidence that project managers take corrective actions based on those data.

The definition of data and how many measurements are needed may vary from project to project (For CMMI level 2) but must be consistent across the organization (For CMMI level 3). Therefore, instead of starting with a “Laissez faire” approach to measurements, where each project can come up with anything they want, I would suggest the organization defines a list of measurements and allow each project to select few from this list.

 

Question: Our process improvement has stopped. How can I get it going?

Answer: I really want to know why it has stopped. Is it because lack of management commitment? Or lack of understanding of what to do next? Do you have enough resources? Do you have the right people with the right skills in your SEPG? Is it a motivational issue or economical issue? What about your senior management? Did you follow the improvement roadmap?

Before we restart a process, you need to understand the root cause and take corrective action. Without understand the cause, you will be wasting your time since history always repeat itself.