Đáp: Thân tri thức quản lí dự án có các định nghĩa sau:

Dự án phần mềm là tập các hoạt động tạm thời được tiến hành để tạo ra sản phẩm và dịch vụ duy nhất. Tạm thời nghĩa là mọi dự án đều có chỗ bắt đầu được định rõ và chỗ kết thúc được định rõ tương phản với hoạt động hỗ trợ diễn ra đều đều không có kết thúc. Duy nhất nghĩa là sản phẩm hay dịch vụ là khác với tất cả sản phẩm và dịch vụ tương tự. Mục đích của dự án là chuyển giao sản phẩm hay dịch vụ để đáp ứng mục đích của tổ chức, điều bao gồm các yêu cầu dự án và các điều kiện riêng như thời gian, ngân sách và tài nguyên.

Quản lí dự án là việc áp dụng tri thức, kĩ năng, công cụ và kĩ thuât tạo khả năng khởi đầu, lập kế hoạch, thực hiện, kiểm soát, và đóng dự án trong khuôn khổ thời gian và ngân sách đã cho, và với mức độ mong đợi về chất lượng để thoả mãn các yêu cầu và mục tiêu doanh nghiệp.

Vai trò của người quản lí dự án là dùng tài nguyên của công ti để hoàn thành mục đích xác định qua việc áp dụng các qui trình và kĩ thuật quản lí dự án, nhưng cũng bằng việc áp dụng kĩ năng có liên quan tới lãnh đạo, trao đổi và xây dựng quan hệ. Người quản lí dự án có trách nhiệm trực tiếp về quản lí việc chuyển giao của dự án đúng thời gian, trong ngân sách, và với chất lượng được yêu cầu. Bằng việc có quản lí dự án tốt, tổ chức có thể:

a)      Giảm mức độ không chắc chắn và rủi ro bằng việc phát biểu các mục tiêu dự án rõ ràng;

b)      Cung cấp kế hoạch dự án tổng thể để quản lí và kiểm soát công việc;

c)      Đo việc hoàn thành theo kế hoạch và mục tiêu đã phát biểu;

d)      Tạo ra kênh hiệu quả cho trao đổi;

e)      Nhận ra các rủi ro và lấy hành động sớm;

f)       Nhận diện và giảm bớt rủi ro để giảm lịch biểu và lạm chi;

g)      Xây dựng tổ và thiết lập chương trình hành động tổ mạnh;

h)      Tối ưu hoá tài nguyên.

Người lãnh đạo tổ thường là người có kinh nghiệm nhất và có kĩ thuật cao trong tổ dự án. Người lãnh đạo tổ chịu trách nhiệm xác định giải pháp kĩ thuật cho nhu cầu nghiệp vụ (yêu cầu dự án) và quản lí thay đổi của dự án. Trong cộng tác với người quản lí dự án, người lãnh đạo tổ tham gia vào lập kế hoạch và kiểm điểm các hoạt động của dự án, phần lớn về khía cạnh kĩ thuật như kiến trúc, thiết kế và thực hiện. Người đó cũng kiểm nghiệm và chấp thuận các vật chuyển giao cuối cùng do tổ dự án làm ra.

Tổ dự án bao gồm người quản lí dự án, người lãnh đạo tổ, và tất cả thành viên được phân cho dự án. Tổ dự án chịu trách nhiệm về kết quả của dự án (tức là sản phẩm hay dịch vụ) được chuyển giao.

Thành viên tổ là người tham gia vào dự án và là một phần của tổ bên trong cấu trúc tổ chức của dự án. Thành viên tổ có nhiệm vụ và vai trò được phân công cho người đó và đảm nhiệm hoàn thành phân công này.

Mục đích hiệu năng là mục đích xác định, đo được, mang tính thách thức được trao cho tổ. Nó là mô tả về mục đích trả lời cho câu hỏi “Tại sao chúng ta làm dự án này?” và “Chúng ta phải làm gì?” nhưng không về “Chúng ta làm nó thế nào?” Mục đích không phải là mô tả về hoạt động mà là phát biểu về kết quả mong muốn. Tổ dự án sẽ phải trả lời “thế nào?” và thực hiện nó. Khái niệm này là bản chất để lập ra biên giới ban đầu của tổ tự tổ chức. Bằng việc xác định “cái gì” và “tại sao”, tổ hiểu lí do và cái gì họ phải làm nhưng cho phép họ đi tới giải pháp riêng của mình. Mục đích hiệu năng cũng là bản chất để xây dựng tính đảm nhiệm của của (như đối lập với tính đảm nhiệm của cá nhân).

Hỏi: Liệu có thể được đánh giá ở các mức CMMI cao hơn mà không có cải tiến nào không?

Đáp: Câu trả lời là “Có”, nhưng câu hỏi là “Tại sao.” Tại sao bạn muốn được đánh giá ở mức CMM cao hơn mà không thấy cải tiến thực gì cả? Mức cao hơn có nghĩa gì với bạn? Trong nhiều năm qua, tôi đã thấy nhiều tổ chức triển khai các hoạt động cải tiến bằng việc thiết lập SEPG và các tổ cải tiến. Họ đã tạo ra tài liệu cải tiến được đặt lên các website cải tiến, có vẻ rất bận rộn với các cuộc họp cải tiến hàng tuần mà chẳng làm cải tiến nào cả.

Một số tổ chức thậm chí đã qua được các cuộc kiểm điểm ISO 9000 hay được đánh giá ở các mức CMM cao nhưng người của họ không làm việc khác đi và sản phẩm của họ chẳng khác sản phẩm của các tổ chức mức thấp hơn. Các tổ chức này đã tạo ra bầu không khí“có vẻ và cảm giác cải tiến,” nơi nhiều tổ bận rộn tạo ra tài liệu nhân tạo mà chẳng liên quan gì tới cách tổ chức làm kinh doanh hay xây dựng phần mềm. Họ thường xuyên rót đầy các website của họ với nhiều thủ tục, khuôn mẫu mà chẳng ai dùng và tất nhiên đến cuối chẳng cải tiến thực nào xảy ra cả.

Việc làm nhiều tài liệu và thủ tục, không thay đổi hành vi con người, sẽ không cải tiến hiệu quả kinh doanh. Để làm cho công việc cải tiến, tổ chức phải thay đổi cách mọi người làm việc, nghĩa là tài liệu và thủ tục phải dựa trên qui trình thực mà mọi người dùng và không là qui trình nhân tạo bởi vì một số sách đã gợi ý hay một số chuyên gia ở đâu đó đã nói vậy. Người chịu trách nhiệm cho cải tiến là các công nhân và người quản lí của họ. Nếu người quản lí không chăm nom về cải tiến thì công nhân sẽ tiếp tục làm những điều như họ đã làm trước đây, và không cái gì sẽ thay đổi cả. Để làm cho thay đổi xảy ra, người quản lí phải chịu trách nhiệm về cải tiến qui trình, họ phải thu thập và phân tích dữ liệu chất lượng, chi phí và thời gian để thấy cơ hội cải tiến; và dùng SEPG để hỗ trợ cho tổ chức và điều phối tiến bộ.

Bi kịch trong cải tiến qui trình là cuộc đua đạt tới các mức cao hơn, nơi tổ chức đặt mức độ trưởng thành là mục đích tối thượng, thay vì hội tụ vào việc đạt tới ích lợi doanh nghiệp. Bằng chứng cho điều này là tổ chức trở nên bị ám ảnh với đánh giá, và mọi hoạt động đều vận hành hướng tới việc đánh giá, và mọi hành động đều cuốn theo việc qua được “đánh giá.” Tôi đã thấy nhiều người khoe khoang rằng tổ chức của họ ở mức rất cao, nhưng chẳng có bằng chứng nào rằng cải tiến đã xảy ra.

Lấy ví dụ: một tổ chức “mức 5” có thể vẫn có vấn đề với quản lí dự án, lịch biểu, chi phí, chất lượng và lỗi phần mềm tầm thường; một tổ chức “mức 4” bắt đầu thu thập cách đo và tuyên bố ý nghĩa thống kê với rất ít điểm dữ liệu. Tôi thực sự tin những người hành nghề phần mềm phải dừng “cơn rồ mức cao hơn” vô nghĩa này, và hội tụ vào việc tạo ra công việc cải tiến qui trình thực sự. Nghĩa vụ, trách nhiệm và tính chính trực của chúng ta bị lâm nguy ở đây.

Hỏi: Chúng tôi có thể dùng CMMI trong tổ chức nhỏ (ít hơn 100 người) với nhiều dự án nhỏ không? Chúng tôi bắt đầu thế nào?

Đáp: CMMI là khuôn khổ cải tiến có thể được áp dụng cho các nhóm nhỏ hay lớn, với mức độ thay đổi nào đó. Cụm từ then chốt là “dùng theo nghĩa thường.” Chẳng hạn, các nhóm nhỏ hơn có thể không cần nhiều việc làm tài liệu và điều phối, chủ yếu bởi vì trao đổi trong các nhóm nhỏ là tốt hơn nhiều so với nhóm lớn hơn. Chìa khoá là đặt các mục đích hiện thực cho từng dự án, và tuân theo khuôn khổ CMMI để đạt tới các mục đích này. Để bắt đầu nỗ lực cải tiến qui trình bạn cần quản lí cấp cao chấp thuận và cam kết về thời gian, tiền bạc, chỉ đạo trên xuống, và lập mục đích. Bạn cũng cần huấn luyện và trao đổi cho mọi người trong tổ chức.

Hỏi: Định nghĩa về “thời gian chu kì” là gì và làm sao cắt giảm nó đi 50% để đáp ứng mục đích và mục tiêu của khách hàng?

Đáp: Thời gian chu kì hiếm khi được định nghĩa chính xác, cho dù nhiều tổ chức coi nó là mục đích quan trọng nhất của họ. Về căn bản, thời gian chu kì nói tới thời gian từ khởi động dự án cho tới lần đưa ra đầu tiên của sản phẩm phần mềm cho khách hàng. Nó cũng có thể được định nghĩa như thời kì trong từng pha trong vòng đời phần mềm, như yêu cầu, thiết kế, mã, kiểm thử v.v, hay giữa từng việc đưa ra phần mềm. Khái niệm này là: nếu bạn không đo thời gian chu kì, bạn không thể quản lí được nó; và nếu bạn không quản lí được nó, bạn không thể kiểm soát được nó; và nếu bạn không kiểm soát được nó, bạn không thể cải tiến được nó.  Tôi có vài câu hỏi cho bạn:

1)     Khách hàng của bạn đặt mục đích giảm 50% thời gian chu kì như thế nào? Sao không 20% hay 80%?

2)     Đáp ứng của cấp quản lí của bạn cho yêu cầu này là gì?

3)     Có người nào làm gì về nó không?

4)     Tổ chức của bạn có kế hoạch đạt tới mục đích này không?

Nhiều lần thế tôi đã thấy mọi người đặt các mục đích rất năng nổ mà chẳng có ý tưởng nào về cách đạt tới nó. Điều này có thể tạo ra lẫn lộn hay giận dữ và cuối cùng mọi người sẽ bỏ qua nó và rồi chẳng cái gì được làm. Mục đích là hữu dụng duy nhất nếu nó dẫn tới hành động. Để hành động được thấy mọi người phải thay đổi hành vi của họ; nhưng nếu hành vi hay văn hoá không thay đổi, nó sẽ là “chẳng cái gì thay đổi như thường.”

Hỏi: Tôi hiểu rằng có nhiều mô hình CMMI sẵn có trên thị trường. Chúng tôi nên chọn mô hình nào?

Đáp: Vâng, quả thực nó là bãi lầy với nhiều CMMI chính thức và không chính thức sẵn có khắp mọi chỗ nhưng trước khi lựa ra một CMMI chúng ta phải tự hỏi mình: “Mục đích của cải tiến của chúng ta là gì?” Chúng ta có đang trong việc tìm “CMMI hoàn hảo không”? Bằng việc liên tục đi chợ kiếm CMMI mới nhất, chúng ta có thể mất  khá nhiều thời gian và tài nguyên, điều có thể được dùng để làm việc cải tiến qui trình. CMMI chỉ là mô hình nhưng cải tiến còn nhiều hơn là có một mô hình được lựa mà là thu được cam kết, kĩ năng, tri thức, tài nguyên và làm cho công việc được cải tiến. Người ta không nên bám dính một cách mù quáng vào chỉ một mô hình mà chúng ta cũng không nên nhảy vào mô hình mới mọi lúc nó được đưa vào. Chúng ta phải đánh giá các mô hình một cách cẩn thận khi công nghệ tiến hoá, và giữ sự hội tụ của chúng ta vào cải tiến qui trình, chi phí và chất lượng.

Hỏi: Liệu có thể để một tổ chức làm cải tiến và trưởng thành độc lập được không, hay chúng ta phải tuân thủ qui trình toàn công ti áp đặt lên chúng ta?

Đáp: Phạm vi của cải tiến qui trình là tổ chức, cái có thể là một chương trình chính, ban giám đốc, miền, hay đơn vị nghiệp vụ nhỏ. Kích cỡ lí tưởng cho một tổ chức là xấp xỉ 300 tới 1000 người. Từng tổ chức đều phải cải tiến mức trưởng thành của riêng mình một cách độc lập dựa trên cái gì là tốt nhất cho kinh doanh của nó và khách hàng của nó. Tôi mạnh mẽ tin tưởng rằng cải tiến phải dựa trên mục đích, mục tiêu của tổ chức và chiều hướng quản lí. Tôi không tin vào việc tạo ra một qui trình toàn công ti và áp đặt nó lên tổ chức, bởi vì có nhiều tổ chức với các miền khác nhau, các ứng dụng, khách hàng, sản phẩm, qui trình, mục đích nghiệp vụ và mức độ trưởng thành. Một qui trình toàn công ti không thể mô tả được tất cả chi tiết được cần tới hay hữu dụng nếu nó là qui trình tổng quát mức cao. Cách tiếp cận “một cỡ khớp cho tất cả” không phải là hoạt động gia tăng giá trị và đằng nào thì cũng có thể sẽ bị bỏ qua bởi hầu hết các tổ chức.

Hỏi: Liệu có thể cải tiến các qui trình QA chế tạo bằng việc dùng CMMI cho dù chúng ta không phát triển phần mềm?

Đáp: Có chứ, có thể dùng nguyên tắc của CMMI để cải tiến bất kì qui trình nào nhưng bạn phải thay đổi nó để gióng thẳng với qui trình nghiệp vụ của chế tạo. Chẳng hạn:

Ở mức 2, sự hội tụ là vào việc tiến hành giám định Đảm bảo chất lượng Quality Assurance (QA) ở mức dự án. Nhiệm vụ QA là kiểm điểm, làm tài liệu và thu thập dữ liệu lỗi tại mức dự án.

Ở mức 3, hội tụ là thiết lập qui trình chuẩn QA qua tất cả các qui trình chế tạo. Chuẩn QA này bao gồm chính sách, chỉ đạo, kiểm điểm, và qui trình kiểm định. QA cần tiến hành các cuộc kiểm điểm và kiểm định, cả chính thức và không chính thức. QA thu thập dữ liệu lỗi ở mức dự án rồi soạn thảo ra dữ liệu ở qui trình hay pha chế tạo, (xác định, xây dựng, kiểm thử, đưa ra, v.v.). Từ những dữ liệu này, cấp quản lí có thể ra quyết định. QA cũng phân tích những dữ liệu này (Phân tích căn nguyên) để loại bỏ lỗi một lần cho tất cả.

Ở mức 4, ý định là dùng tất cả các dữ liệu đã được thu thập để lập kiểm soát các giới hạn và dùng các kĩ thuật Kiểm soát qui trình thống kê để loại bỏ tất cả các lỗi khỏi sản phẩm và qui trình. Đây là chỗ bắt đầu của “chất lượng có sẵn” thay vì “giám định vào,” hay kiểm thử, vì chất lượng. Người quản lí sẽ quản lí tất cả các qui trình bằng sự kiện và dữ liệu. Thông thường ở mức 4, phần lớn lỗi đã được loại bỏ và chất lượng không còn là vấn đề với lỗi.  Tuy nhiên, có các vấn đề với các thuộc tính khác như độ tin cậy, hiệu năng, và tính đổi qui mô được.

Ở mức 5, hội tụ là vào tối ưu hoá mọi qui trình để đảm bảo toàn bộ tuyến sản phẩn có thể đạt tới mục đích tối thượng của  việc không có lỗi hay phẩm chất six-sigma.

Hỏi: Tại sao chúng ta cần đo phần mềm tuân thủ theo CMMI? Cái gì là điều hợp lí gì trong việc thu thập các cách đo trong CMMI?

Đáp: Chính nguyên tắc nền tảng là tổ chức tồn tại bởi việc cung cấp giá trị đã được chứng minh cho kinh doanh. Từ khoá ở đây là “giá trị được chứng minh.” Không có cách đo làm sao bạn chứng minh được giá trị của mình để biện minh cho quyền duy trì trong kinh doanh? Nguyên tắc này cũng áp dụng cho cải tiến qui trình phần mềm. Nếu chúng ta không thể chứng minh được rằng cải tiến qui trình có tác dụng bằng sự kiện và dữ liệu, chúng ta có nên tiếp tục duy trì kinh doanh nữa không? Chúng ta có nên đầu tư vào cải tiến qui trình chút nào không? Việc đo là quan niệm then chốt trong cải tiến qui trình được CMMI yêu cầu, tức là đo dự án ở mức 2; đo tổ chức ở mức 3; đo tuyến sản phẩm ở mức 4; đo tối ưu qui trình ở mức 5.

Đo nên là một phần của vòng đời phần mềm và không nên bị đối xử như hoạt động tách rời.

Hỏi: Tại sao chúng ta phải tuân theo qui trình được làm tài liệu? Tại sao làm tài liệu khi công nghệ thay đổi nhanh thế và mọi sự trở thành lỗi thời trong vài năm?

Đáp: Pha phát triển phần mềm là ngắn khi so sánh với pha bảo trì. Bảo trì có thể kéo dài trong hàng chục năm và nó phức tạp bởi nhu cầu gỡ lỗi và nâng cao, dựa trên nhu cầu của khách hàng. Vấn đề chính của bảo trì là ở chỗ nó thường được thực hiện bởi ai đó chứ không phải là người phát triển ban đầu. Qua thời gian, khi mọi người đi chuyển từ dự án nọ sang dự án kia, các yêu cầu ban đầu, các qui tắc nghiệp vụ, kiến trúc và những bù trừ thiết kế bị mất đi. Không có qui trình được làm tài liệu tại chỗ, không thể nào bảo trì được các hệ thống như thế.

Hỏi: Tổ chức của tôi đang nỗ lực xây dựng Qui trình chuẩn phần mềm của tổ chức Organization Software Standard Process (OSSP). Đã có nhiều tranh luận về chấp thuận chuẩn bên ngoài hay vay mượn từ các tổ chức mức cao hơn, nhưng dầu vậy vẫn chẳng đi tới kết luận nào. Xin thầy giúp cho.

Đáp: CMMI yêu cầu tổ chức phải có Qui trình chuẩn phần mềm của tổ chức “Organization Software Standard Process” (OSSP) được làm tài liệu, và được dùng bởi các dự án bên trong tổ chức đó (đây là miền qui trình mức 3 PA). Câu hỏi chung là: qui trình chuẩn này tới từ đâu?

Chúng ta hãy giả sử rằng tổ chức đã thiết lập một nhóm chuyên gia để xác định chuẩn này. Những người này đều thông minh và có thể tạo ra qui trình rất tốt cho tổ chức. Ngay cả với người giỏi nhất, vẫn phải mất thời gian để phát triển qui trình này, để huấn luyện mọi người tuân theo nó, để thu thập dữ liệu và để phân tích nó xem nó có thực làm việc không. Đồng thời, mọi người sẽ tiếp tục làm bất kì cái gì họ làm như chẳng cái gì xảy ra trong tổ chức.  Qui trình chuẩn càng được phát triển lâu, càng ít có cơ hội cho thành công bởi vì mọi đà và nhiệt tình cải tiến phai nhạt dần qua thời gian và cấp quản lí có thể mất kiên nhẫn và kết thúc nỗ lực cải tiến.

Cho dù tổ có thành công tạo ra một qui trình chuẩn có nhãn hiệu từ tay trắng và bắt đầu triển khai nó, phần lớn mọi người sẽ tin rằng ai đó đang ép buộc họ thay đổi cách họ làm nghiệp vụ (đây là hành vi rất thông thường) và bắt đầu chống lại chuẩn mới và mối quan hệ SEPG và những người hành nghề có thể trở thành kình địch thay vì cộng tác và điều xấu có thể xảy ra yêu cầu cấp quản lí lấy hành động và nhiều hoạt động cải tiến có thể lâm vào vấn đề nghiêm trọng.

Cho dù SEPG có thể chấp nhận một chuẩn từ đâu đó và đem nó vào trong tổ chức nhưng dựa trên nhiều bài học rút ra tôi thấy rằng áp đặt một “qui trình chuẩn” bên ngoài vào tổ chức thường không làm việc tốt, và đằng nào thì mọi người cũng có xu hướng bỏ qua chúng. Vay mượn từ các tổ chức mức cao hơn không ích gì bởi vì nó vẫn là qui trình “bên ngoài hay ngoại lai.”

Cách tiếp cận theo nghĩa thông thường tốt nhất là tạo ra OSSP từ dưới lên, dựa trên “thực hành tốt nhất” bên trong tổ chức. Bạn nên bắt đầu với tuyển tập các thực hành tốt nhất, cái đã tồn tại trong tổ chức, đơn giản hoá nó như “chuẩn lâm thời” cho mọi người theo. Hoạt động này không yêu cầu nhiều thời gian để xác định và để huấn luyện vì phần lớn các qui trình đều tới từ tổ chức và mọi người đã quen thuộc với chúng do đó họ không chống lại. Hoạt động then chốt tiếp theo là đo việc sử dụng và tính hiệu quả của “chuẩn lâm thời” này.  Khi có việc đo, SEPG có thể nhận diện qui trình tốt nhất bên trong qui trình lân thời và làm mịn nó thành “chuẩn của tổ chức.”

Cách tiếp cận này không mới bởi vì nó dựa trên chiến lược triển khai: Xác định chuẩn dựa trên thực hành hiện có, thử nghiệm nó trong vài dự án để thu thập dữ liệu, làm mịn nó dựa trên cách đo và chuẩn hoá nó cho sử dụng rộng rãi trong toàn tổ chức. Qui trình chuẩn không phải là cứng nhắc mà là linh hoạt và cuối cùng trở thành mô tả vững chắc mà mọi người sẽ theo. Theo kinh nghiệm của tôi, bất kì việc xác định chuẩn nào cũng nên bắt đầu bằng thực hành, điều đã tồn tại bên trong tổ chức nhưng với một số sửa đổi hay “vi chỉnh” cho dễ dùng.

Hỏi: Làm sao chúng tôi biết cách đo của mình là hiệu quả?

Đáp: Để dùng độ đo hiệu quả, bạn nên: a) Chỉ đo điều bạn có thể làm cái gì đó về nó; b) Đo thực tế so với kế hoạch; c) Giữ tập dữ liệu đơn giản, và 4) Giữ mọi thứ thấy được. Cách đo có thể giúp bất kì tổ chức nào cải tiến chừng nào bạn không làm quá mức nó bằng việc bắt đầu nỗ lực cải tiến với quá nhiều cách đo. Giữ cho được hội tụ vào kết quả cuối cùng và dùng độ đo để giúp cho dự án.

Hỏi: Chúng tôi có thể làm gì để cải tiến tính cạnh tranh của công ti chúng tôi?

Đáp: Tôi tin một điểm quan trọng nhất mà công ti có thể làm để cải tiến tính cạnh tranh của mình là bằng việc cải tiến triệt để năng suất, chất lượng và tinh thần của nó.  Ba mục đích này có thể dường như loại trừ lẫn nhau, nhưng trong thực tế chúng được nối rất mạnh.  Công ti có năng suất lớn nhất thu được bằng cải tiến chất lượng các sản phẩm của nó và các qui trình tạo ra chúng. Bằng việc cải tiến, công ti, đồng thời, có được cải tiến lớn nhất về tinh thần với việc loại bỏ các vấn đề gây ra chuyện tinh thần.

Tôi đã thấy nhiều công ti theo cách tiếp cận này từ vài năm trước, và đã thấy dữ liệu có ý nghĩa về cải tiến như giảm chi phí và cải tiến chất lượng, và đồng thời tăng chỉ số hài lòng của nhân viên của họ. Xây dựng niềm tin vào cách tiếp cận này, các công ti đó bây giờ cam kết tăng hơn 50% về năng suất thu được qua năm năm tới.  Đi cùng điều này, họ cũng cam kết cải tiến tăng 30% khác trong phát hiện và khử bỏ lỗi.

English version

Question: I am confused about some software terms such as project, project management, team leaders, project team, and project performance. Every people I asked, give different answers.

Answer: The Project Management Body of Knowledge has the following definitions:

A software project is a temporary set of activities undertaken to create a unique product or service. Temporary means that every project has a definite beginning and a definite end as contrast with on going support activity which has no end. Unique means that the product or service is different from all similar products or services. The objective of a project is to deliver the product or service to meet the organizational goals, which consists of the project requirements and specific conditions such as time, budget, and resources.

Project management is the application of knowledge, skills, tools, and techniques that enables the initiation, planning, execution, control, and closure of a given project within a given time frame and budget, and with the expected level of quality to satisfy requirements and business objectives.

The project manager’s role is to use the company’s resources to fulfill a specific objective through the application of project management processes and techniques, but also by applying skills related to leadership, communication and relationship building. The project manager has a direct responsibility for managing the delivery of the project on time, within budget, and with the quality required. By having good project management, the organization could:

a)      Reducing the level of uncertainty and risk by means of a clear project objectives;

b)      Providing an overall project plan to manage and control of the work;

c)      Measuring accomplishments against the plan and stated objectives;

d)      Creating effective channels of communications;

e)      Recognizing risks and take actions early;

f)        Identifying and mitigating risks to reduce schedule and cost overruns;

g)      Team building and establishing a strong teamwork agenda;

h)      Optimizing resources.

The team leader is usually the most experienced and highly technical person on the project team. The team leader is responsible for defining the technical solutions for the business needs (project requirements) and manages changes to the project. In collaboration with the project manager, the team leader participates in the planning and reviewing activities of the project, mostly on the technical aspect such as the architecture, design and implementation. He also validating and approving the final deliverables produced by the project team.

The project team is composed of the project manager, the team leader, and all the members assigned to the project. The project team is responsible for the outcome of the project (i.e. the product or service) to be delivered.

Team member is people involved in the project and is part of a team within the project’s organizational structure. A team member has a task or a role assigned to him and is accountable for the completion of his assignment.

The Performance Goal is a specific, measurable, challenging goal that is given to the team. It is a description of a goal that answers the questions “why do we do this project?” and “what must we do?”, but not “how do we do it?”. The goal is not a description of activities but a statement of desired results. The project team will have to answer “how?” and implement it. This concept is essential for setting the initial boundaries of a self-organization team. By defining “what” and “why”, the team understands the reason and what they must do but allow them to come up with their own solutions. The Performance Goal is also essential to building team accountability (as opposed to individual accountability).

Question: Is it possible to be assessed at higher CMMI levels without any improvement?

Answer: The answer is “Yes”, but the question is “Why”. Why would you want to be assessed at higher CMM level without seeing any real improvement? What does a higher level mean to you? In the past several years, I have seen many organizations deployed improvement activities by established an SEPG and improvement teams. They created improvement documents to be placed on improvement websites, appeared very busy with weekly improvement meetings without improving anything. Some organizations have even passed ISO 9000 reviews or assessed at higher CMM levels but their people were not working any differently and their products were no different from products of lower level organizations. These organizations have created an “improvement look and feel” atmosphere, where many teams are busy creating artificial documents that have nothing to do with the way the organization do business or build software. They constantly filled their websites with many procedures, templates that nobody used and of course in the end no real improvement happened.

Developing a lot of documents and procedures, without changing people behavior, does not improve business performance. To make improvement work, organization must change the way people work that mean the documents and procedures must be based on actual process that people use and not an artificial process because some books have suggested or some experts somewhere have said so. The people responsible for improvement are workers and their managers. If managers do not care about improvement then the workers will continue to do things as they have done before, and nothing will change. To make change happen, the managers must be held responsible for process improvement, they must collect and analyze quality, cost, and time data for improvement opportunities; and use the SEPG to support the organization and monitor progress.

A tragedy in process improvement is the race to achieve higher levels, where an organization sets a maturity level as the ultimate goal, rather than focusing on achieving the business benefits. Evidence of this is the organization becomes obsessed with the assessment, and all activities are geared toward passing an “assessment”. I have seen many people boasting that their organization is at a very high level, but there is no evidence that improvement has taken place. As an example: A “Level 5” organization may still be having problems with project management, schedule, costs, quality and trivial software defects; A “level 4” organization begin collecting measurements and claim statistical significant with very few data points. I really believe software practitioners must stop the nonsense “higher-level craze,” and focus on making real process improvement work. Our duties, responsibilities, and personal integrity are at stake here.

Question: Can we use the CMMI in a small organization (less than 100 people) with many small projects? How do we get started?

Answer: The CMMI is an improvement framework that can be applied to small or large groups, with some degree of modification. The key phrase is “using common sense”. For example, smaller groups may not need a lot of documentation and coordination, primarily because communication is much better in a small group than larger one. The key is setting realistic goals for each project, and following the CMMI framework to achieve these goals. To start a process improvement effort you need senior management approval and commitment for time, money, top-down direction, and goal setting. You also need necessary training and communication for the people in your organization.

Question: What is the definition of “cycle time” and how to cut it by 50% to meet customer’s goal and objectives?

Answer: Cycle time is rarely defined exactly, even though many organizations consider it their most important goal. Typically, cycle time refers to the time from project kick-off to the first release of the software product to the customer. It can also be defined as the period within each phase in the software life cycle, e.g. requirements, design, code, test etc, or between each software release. The concept is: if you do not measure cycle time, you cannot manage it; and if you do not manage it, you cannot control it; and if you do not control it, you cannot improve it.  I do have several questions for you:

1)     How does your customer set the goal of 50% to reduce cycle time? Why not 20% or 80%?

2)     What is your management response to this demand?

3)     Is anybody doing anything about it?

4)     Does your organization have a plan to achieve this goal?

So many times I have seen people setting aggressive goals without any idea on how to achieve it. This can create confusion or anger and eventually people will ignore it and then nothing will get done. The goal is only useful if it leads to action. For action to be seen people must change their behavior; but if the behavior or culture is not changing, it will be “nothing change as usual”.

Question: I understand that there are several CMMI models available in the market.  Which one must we select?

Answer: Yes, indeed it is a quagmire with so many official and unofficial CMMI available all over the place but before select a CMMI we must ask ourselves: “What is the purpose of our improvement?” Are we in business to look for the “Perfect CMMI”? By continuing to shop around for the latest CMMI, we may lose a considerable amount of time and resources, which could be utilized for making process improvement work. A CMMI is only a model but improvement is much more than having selected a model but obtaining commitment, skills, knowledge, resources and making improvement works. One should not blindly stick to only one model but we should not jump into new one every time it is introduce either. We must evaluate new models carefully as technology evolves, and keep our focus on improving time, cost and quality.

Question: Is it possible for an organization to improve and mature independently, or do we have to comply with a company-wide process forced on us?

Answer: The scope of process improvement is an organization, which it could be a major program, directorate, domain, or small business unit. An ideal size for an organization is approximately 300 to 1000 people. Each organization should improve its own maturity level independently based on what is best for its business and its customers. I strongly believe that improvement must be based on organizational business goals, objectives and management directions. I do not believe in creating a companywide process and forcing it on organizations, because there are so many organizations with different domains, applications, customers, products, processes, business goals and maturity levels. A single companywide process cannot describe all needed details or be useful if it is a high level generic process. The “one size fits all” approach is not a value-added activity and likely will be ignored by most organizations anyway.

Question: Is it possible to improve a Manufacturing QA processes using the CMMI even though we do not develop software?

Answer: Yes, it is possible to use the principle of CMMI to improve any processes but you have to modify it to align with the business process of manufacturing. For example:

At level 2, the focus is on conducting Quality Assurance (QA) inspection at the project level. The QA task is to review, document and collect defect data at the project level.

At level 3, the focus is to establish a QA standard process across all manufacturing processes. This QA standard consists of a policy, direction, review, and audit process. QA needs to conduct reviews and audits, both formal and informal. QA collects defect data at the project level then compiles the data at manufacturing process or phases, (define, build, test, release, etc). From these data, management can then make decisions. QA also analyzes these data (Root cause analysis) to remove defects once and for all.

At level 4, the intent is to use all data collected to set control limits and use Statistical Process Control techniques to remove all defects from products and processes. This is the beginning of “built-in quality” rather than “inspecting-in”, or testing, for quality. Managers will manage all processes by facts and data. Usually at level 4, most defects have been removed and quality is no longer an issue for defects.  However, there are issues with other attributes such as reliability, performance, and scalability.

At level 5, the focus is on optimizing all processes to ensure the entire product-line can reach the ultimate goal of zero defect or six-sigma quality.

Question: Why do we need to measure our software in compliance with CMMI? What is the rational for gathering measurements in CMMI?

Answer: It is a fundamental principle that organizations exist by providing demonstrated value to the business. The key word here is “demonstrated value”. Without measurements how do you demonstrate your worth to justify the right to stay in business? This principle also applies to software process improvement. If we cannot demonstrate that process improvement works by fact and data, should we continue to stay in business? Should we invest in process improvement at all? Measurement is a key concept in process improvement required by the CMMI, i.e. project measurements at level 2; organization measurements at level 3; product-line measurement at level 4; optimizing process measurement at level 5.

Measurement should be part of the software life cycle and should not be treated as a separate activity.

Question: Why do we have to follow a documented process? Why document when technology changes so fast and things become obsolete in a few years?

Answer: The software development phase is short as compared to the maintenance phase. Maintenance can last for decades and is complicated by the need for bug fixes and enhancements, based on customer’s demand. The major problem of maintenance is that it is usually done by someone else rather the initial developers. Overtime, as people move from project to project, the initial requirements, business rules, architecture, and design trade-offs are lost. Without a documented process in place, it is impossible to maintain such systems.

Question: My organization is still struggling to build an Organization Software Standard Process (OSSP). There have been several debates about adopting an external standard or borrow from higher-level organizations, but still come up with no solutions. Please help.

Answer: The CMMI requires an organization to have an “Organization Software Standard Process” (OSSP) documented, and used by projects within that organization (this is Level 3 PA). The common question is: where does this standard process come from?

Let’s assume that the organization establish a group of expert to define this standard. These people are smart and could create a very good process for the organization. Even with the best people, it will take time to develop this process, to train people to follow it, to collect data and to analyze it to see if it really works. In the mean time, people will continue to do whatever they do as nothing happen in the organization.  The longer the standard process being developed, the less chance of success it will be because all the momentum and energy to improve has faded overtime and management could loose patient and terminate the improvement efforts.

Even if the team successful create a brand new standard process from scratch and begin to deploy it, most people will believe that someone is forcing them to change the way they do business (This is very common behavior) and begin to resist the new standard and the SEPG and Practitioner relationship could become adversarial rather collaborative and bad things could happen require management to take action and many improvement activities could get into serious problem.

Even if the SEPG could adopt a standard from somewhere and bring it into the organization but based on several lessons learned I found that forcing an external “standard process” on an organization usually does not work well, and people have a tendency to ignore them anyway. Borrowing from higher-level organizations does not help either because it is still an “external or foreign” process.

The best common sense approach is to create the OSSP from the bottom up, based on “best practices” within the organization. You should start with a collection of best practices, which already exist in the organization, simplify it as the “interim standard” for people to follow. This activity does not require a lot of time to define and to train because most processes come from the organization and people are already familiar with them therefore they do not resist. The key activity follow is measure the usage and effectiveness of this “interim standard”.  Having measurements, the SEPG could identify the best process within the interim standard and refined it into the “organization standard”.

This approach is not new because it is based on the deployment strategy: Define the standard based on existing practices, pilot it in several projects to collect data, refined it based on measurements and standardize it for wide usage across the organization. Standard process is not a rigid but a flexible and eventually become a robust description that people will follow. Based on my experience, any standard definition should start with actual practices, which already exist within an organization but with some modification or “fine tuning” for ease of use.

Question: How do we know our measurements are effective?

Answer: To use metrics effectively, you should: a) Measure only what you can do something about it. B) Measure actual against plan; c) Keep data collection simple, and 4) Keep everything visible. Measurements can help any organization to improve as long as you don’t overdo it by starting the improvement efforts with too many measurements. Keep focused on the end result and use metrics to help guide the project.

Question: What can we do to improve the competitiveness of our company?

Answer: I believe the single most important thing a company can do is to improve its competitiveness by dramatically improve its productivity, quality and morale.  These three goals may seem mutually exclusive, but in reality they are strongly connected.  A company gets the biggest productivity gains by improving the quality of its products and the processes that create them. By improving, the company, in the same time, gets the biggest improvements in morale by getting rid of the issues that cause morale problems.

I have seen several companies following this approach few years ago, and have already seen significant data on improvements such as reducing costs and improving quality, and at the same time increased their employee satisfaction index. Having built confidence in the approach, those companies are now committing to more than 50% increase in productivity gains over the next five years.  Right along with this, they also committed to another 30% improvement in defect detection and elimination.