Tự do - Osho: Cùng khám phá điều kỳ diệu của tự do
Trong suốt chiều dài lịch sử, con người luôn kêu đòi tự do, luôn đấu tranh vì tự do. Nhưng tự do thật sự là gì? Chúng ta có thực sự tự do như mình vẫn nghĩ?
SM: Anh có biết cách giữ việc làm của mình trong cuộc khủng hoảng tài chính này khi nhiều công ti đang giảm người không?
PM: Ông chủ của tôi sẽ giữ tôi nếu dự án của tôi có tác dụng tốt. Tuy nhiên tôi không biết tại sao một số dự án thành công và số khác thất bại. Tôi đoán đó là vấn đề may mắn. Nếu tôi may, tôi có thể giữ được việc của mình.
SM: Các dự án hầu hết thất bại là do thiếu lập kế hoạch và quản lí chứ không phải là do may mắn. Phần lớn mọi người bỏ qua việc lập kế hoạch và nhảy vào viết mã cứ nghĩ rằng họ sẽ làm tốt bởi vì họ tin “phần mềm là mã”. Nhiều người thậm chí không để thời gian xác định họ phải giải quyết vấn đề gì. Anh không thể dựa vào may mắn để giữ việc của mình được.
PM: Vậy tôi phải làm gì để đảm bảo dự án thành công?
SM: Có qui trình phần mềm mà mọi người quản lí phần mềm phải tuân theo. Viết mã là điều dễ làm nhất vì hầu hết mọi người đều được đào tạo viết mã nhưng không được đào tạo về qui trình phần mềm. Công việc phần mềm còn nhiều hơn viết mã; thực tế pha viết mã chỉ chiếm khoảng 20% của tổng công sức. Đừng phạm phải sai lầm như người khác bằng việc để quá nhiều công sức vào viết mã; điều đó sẽ làm phí thời gian của bạn, để lại cho bạn nhiều vấn đề.
PM: Qui trình phần mềm là gì?
SM: Qui trình phần mềm là tập các bước bạn phải tuân theo. Là người quản lí dự bán bạn cần:
PM: Anh ngụ ý gì bởi “đánh giá nhu cầu nghiệp vụ của khách hàng”?
SM: Để bắt đầu, bạn cần nhìn vào nhu cầu nghiệp vụ của khách hàng. Dự án chỉ thành công khi nhu cầu của khách hàng và người dùng được đáp ứng. Đây là điều quan trọng nhất cho các dự án của bạn bởi vì nhu cầu của họ chỉ đạo quá trình phát triển của bạn sẽ là cái gì. Bạn phải hiểu vấn đề của họ trước khi bạn có thể đi tới giải pháp. Bên cạnh đó, bạn cần biết khách hàng của mình (người trả tiền cho sản phẩm) và người dùng (người dùng sản phẩm) và thảo luận mọi điều với họ, xây dựng mối quan hệ với họ và để họ biết rằng bạn ở đó để hỗ trợ cho họ. Bạn phải nhớ rằng họ là người chung cuộc sẽ trả tiền cho công sức của bạn và hỗ trợ bạn nếu mọi sự không trôi chảy.
PM: Vâng. Giả sử tôi có quan hệ tốt với họ và hiểu nhu cầu của họ, tiếp đó là gì?
SM: Xác định yêu cầu cho dự án. Cái vào cho qui trình này nên tới từ khách hàng, người dùng, người phân tích hệ thống và người quản lí. Bắt đầu bằng việc hiểu đầy đủ mọi điều bạn phải làm kể cả những điều bạn phải chuyển giao cho họ. Nhiều người nghĩ chuyển giao duy nhất là sản phẩm phần mềm hay mã. Điều đó là không đúng, có nhiều điều hơn như tài liệu yêu cầu, tài liệu kiến trúc, tài liệu giao diện người dùng, tài liệu thiết kế, trường hợp kiểm thử v.v. Tất cả những điều này yêu cầu nhiều công việc cho nên điều tốt nhất cần làm là hỏi khách hàng của bạn những thứ gì họ cần và họ mong đợi chúng khi nào? Trao đổi là mấu chốt trong pha sớm của dự án. Đây là chỗ bạn phải dành ít nhất 20% nỗ lực để có được yêu cầu đúng.
PM: Anh có cho rằng 20% là quá nhiều không. Nó gần như bằng công sức viết mã.
SM: Tôi muốn dành nhiều thời gian cho pha yêu cầu hơn bất kì pha nào khác. Yêu cầu chỉ đạo mọi thứ, yêu cầu sai nghĩa là thất bại dự án. Đây là lúc bạn phải đầu tư nhiều công sức để hiểu điều khách hàng muốn và điều họ mong đợi. Không nắm được yêu cầu là nhân tố thông thường nhất trong thất bại dự án. Phần lớn mọi người dành ít hơn 5% công sức trong yêu cầu nhưng lại nhiều hơn 50% công sức cho viết mã và đó là lí do tại sao nhiều dự án thế đã thất bại. Nếu họ không hiểu yêu cầu, họ sẽ xây dựng sản phẩm sai và rồi phải sửa nó với chi phí tốn hơn và làm cho khách hàng rất bực bởi vì họ không có được cái họ muốn theo cách đúng hạn.
PM: Vâng, tôi nghĩ tôi hiểu quan điểm của anh vậy thì cái gì tiếp?
SM: Bước tiếp là xây dựng tổ dự án tốt. Tôi thích việc “Xây dựng” và bởi vì phải mất thời gian xây dựng tổ tốt. Bạn phải hiểu tri thức và kĩ năng của tổ mình để cho bạn có phân công công việc tương ứng cho họ. Bạn cần xây dựng tổ tốt với các vai trò và trách nhiệm được xác định rõ ràng để cho mọi người đều đảm nhiệm. Luôn lưu tâm, mọi dự án mới đều là cơ hội mới để cải tiến mọi thứ và bao giờ cũng có cơ hội thành công tốt hơn khi mọi người hiểu điều họ được giả định sẽ làm.
PM: Điều đó toàn là tốt thôi, nhưng làm sao anh tìm ra thời gian để hoàn thành tất cả những điều này? Tôi chỉ là một người và với đủ mọi thứ hiện tại đã làm tôi bận bịu hết thời gian rồi.
SM: Xây dựng tổ dự án tốt là nhân tố then chốt cho thành công dự án. Lựa đúng người thông thạo và có tâm trí đủ cởi mở để làm việc cùng nhau bao giờ cũng là thách thức nhưng đó là việc của người quản lí dự án và bạn phải lựa chọn cẩn thận. Mọi người trong tổ phải có năng lực kĩ thuật, kiên nhẫn, có kĩ năng làm việc tổ tốt, và có đủ kinh nghiệm để vận hành thành công. Bên cạnh những trách nhiệm trên, tổ này sẽ thực hiện các nghĩa vụ sau:
Bên cạnh tri thức chuyên gia của họ, bạn cần hỗ trợ và cam kết của họ để giúp bạn trong kiểm nghiệm yêu cầu. Tôi sẽ dành nhiều công sức vào việc xây dựng tổ bởi vì tổ tốt nghĩa là bạn có cơ hội thành công tốt hơn.
PM: Anh nhắc tới “Nhận diện qui trình chuẩn và độ đo.” Chúng ta làm điều đó thế nào?
SM: Bạn phải nhận diện qui trình chuẩn mà tổ của bạn phải tuân theo và tập các độ đo phần mềm. Qui trình chuẩn phụ thuộc vào yêu cầu của khách hàng dù chúng được xác định tốt và được làm tài liệu hay chúng vẫn còn thay đổi, cho nên bạn có thể lựa các phương pháp và qui trình thích hợp tương ứng. Bạn có thể lựa vòng đời thác đổ, vòng đời gia tăng đưa ra, hay bạn có thể muốn lựa phương pháp mau lẹ. Từng vòng đời đều yêu cầu qui trình khác nhau. Là người quản lí dự án, bạn phải biết bạn đang ở đâu và bạn đang làm tốt đến đâu trong toàn bộ qui trình. Bạn phải chứng tỏ được quyền lãnh đạo và kĩ năng quản lí của mình cho ông chủ của mình để họ biết họ sẽ thu được gì với tiền họ bỏ ra. Để có an ninh nghề nghiệp của bạn, bạn cần độ đo để chứng minh cho cấp quản lí rằng bạn đang quản lí dự án và có dữ liệu để chứng minh về nó.
Độ đo giúp bạn tìm cái gì sai và cách sửa nó. Để tôi cho bạn một ví dụ, thử nghĩ về dự án phần mềm như bệnh nhân ở bệnh viện. Không bác sĩ nào sẽ chữa cho bệnh nhân mà không biết mọi triệu chứng. Tương tự vậy, làm sao bạn quản lí được dự án mà không biết các vấn đề của dự án? Độ đo thu thập dữ liệu cho bạn vì bạn cần biết tình trạng của dự án để có hành động sửa chữa. Tuy nhiên, độ đo phải không có tính đe doạ cho tổ. Đừng dùng chúng để đánh giá, phán xét cá nhân; chỉ dùng độ đo cho cải tiến qui trình và giám sát liên tục dự án của bạn. Bằng không, tổ chỉ báo cáo điều họ nghĩ bạn muốn thấy và điều đó là vô dụng. Bạn phải yêu cầu dữ liệu trung thực, chính xác, và nhất quán từ tổ.
PM: Tổ chức của tôi có nhiều vấn đề phần mềm mà có lẽ có thể có lợi từ độ đo. Nhưng làm sao tôi yêu cầu họ ước lượng và thu thập dữ liệu khi họ rất bận rộn làm việc cho dự án? Ông chủ của tôi nhấn mạnh vào việc dự án phải làm đúng thời gian và trong phạm vi ngân sách nào đó.
SM: Làm sao bạn biết lịch biểu đã cho là đúng nếu bạn không ước lượng công việc của bạn? Là người quản lí dự án, bạn phải chia nhỏ các yêu cầu thành nhiều nhiệm vụ và phân công chúng cho thành viên tổ. Từng thành viên đều phải ước lượng sẽ mất bao lâu thời gian để hoàn thành nhiệm vụ được phân công và báo cáo cho bạn. Bạn có thể tổ hợp tất cả những ước lượng này vào trong ước lượng lịch biểu dự án và so sánh với lịch biểu đã cho. Nếu ước lượng của bạn sánh đúng với lịch biểu đã cho, thế thì nó là hoàn hảo nhưng phần lớn thời gian chúng lại không sánh đúng cho nên bạn phải thương lượng với người quản lí và khách hàng của mình về ngày giao hàng.
PM: Anh nói về loại thương lượng nào vậy?
SM: Bằng việc biết dự án phải chuyển giao cái gì cho khách hàng và nhu cầu nào cần được thực hiện, kể cả về khoảng thời gian cần để hoàn thành mọi nhiệm vụ, bạn có thể xác định được liệu bạn có thể đáp ứng ngày chuyển giao của khách hàng hay không. Nếu có khác biệt lớn thì bạn phải thương lượng về ngày chuyển giao với khách hàng bằng hoặc là yêu cầu thêm thời gian, thêm tài nguyên hay thay đổi khối lượng công việc của dự án. Thương lượng là kĩ năng quan trọng cho mọi người quản lí dự án, điều không được dạy trong hầu hết các môn học kĩ thuật nhưng lại là kĩ năng bản chất của mọi người quản lí dự án. Bạn phải hiểu rằng phần lớn khách hàng chỉ đoán chừng ngày giao hàng vì họ không biết đích xác sẽ mất bao lâu cho nên họ lựa ngày xấp xỉ cho tiện.
Đây là cơ hội cho bạn giải thích cho họ cách bạn đi tới thời gian được yêu cầu dựa trên ước lượng của bạn và đạt tới thoả thuận lẫn nhau về ngày chuyển giao cuối cùng. Tuy nhiên, với một số khách hàng, ngày chuyển giao là quan trọng nhất vì nó có liên quan tới các doanh nghiệp khác cho nên điều mấu chốt là khách hàng và người quản lí dự án đồng ý về ngày tháng hợp lí cho cả hai bên. Bởi vì hầu hết khách hàng không hiểu về phần mềm và hoạt động dự án, họ có mong đợi cao cho nên điều quan trọng là có nhiều cuộc họp để thảo luận về điều có thể được làm và điều không thể được làm. Là người quản lí dự án, bạn không muốn lâm vào những tình huống mà nhu cầu và mong đợi không sánh đúng. Chẳng hạn, khách hàng nghĩ tổ có thể làm dự án trong 6 tháng khi dự án có thể mất cả năm cho nên kĩ năng trao đổi và thương lượng là cực kì quan trọng.
SM: Thương lượng là kĩ năng quan trọng nhất của người quản lí phần mềm. Nhưng không may, rất ít chương trình đào tạo cung cấp loại đào tạo này. Trong thương lượng, có ba nhân tố người quản lí dự án nên thảo luận: Khối lượng công việc (Chức năng hay phạm vi), tài nguyên (người) và lịch biểu (Ngày tháng). Nếu ước lượng lịch biểu của bạn và ngày chuyển giao của khách hàng không sánh đúng, bạn có thể yêu cầu khách hàng cho bạn thêm thời gian bằng việc thay đổi ngày chuyển giao. Bạn có thể thương lượng lấy thêm người cho dự án và bạn phải làm điều này từ lúc bắt đầu dự án. Nhiều người có kĩ năng đúng có thể tăng tốc cho dự án, nhiều người có thể làm giảm tải việc của thành viên tổ. Tuy nhiên, thêm nhiều người vào giữa chừng dự án khi mọi sự không làm việc tốt có thể là thảm hoạ.
Nhiều người sẽ làm vỡ công việc dự án, điều đã bị căng thẳng rồi. Nhiều người hơn nghĩa là nhiều trao đổi hơn và làm tăng độ phức tạp của tính động của tổ. Người mới không quen thuộc với công việc dự án cần thời gian để học, điều đó có nghĩa là những người đang làm việc phải dành thời gian đào tạo người mới và mất thời gian quí giá của họ dành cho công việc của họ. Vì các nhiệm vụ trong dự án phần mềm thường sẽ phụ thuộc vào nhiệm vụ của người khác, thất bại của một người có thể làm thiệt hại lớn cho tiến triển dự án. Qui tắc của tôi là không bao giờ thêm người giữa chừng dự án đặc biệt khi dự án đang bị trục trặc.
PM: Điều đó là thú vị đấy. Phần lớn những người quản lí sẽ thêm người cho dự án khi mọi sự không trôi chảy. Anh nói điều đối lập.
SM: Đó là lí do tại sao nhiều dự án phần mềm thất bại. Dường như là những người quản lí này không có kinh nghiệm trong quản lí dự án phần mềm. Dự án phần mềm KHÔNG phải là dự án xây dựng. Trong dự án xây dựng như xây nhà, thêm nhiều người sẽ giúp tăng tốc nó nhưng trong dự án phần mềm điều đó sẽ KHÔNG giúp gì mà tạo ra thêm vấn đề. Từ kinh nghiệm của tôi, điều quan trọng là thương lượng về người phụ ngay từ đầu dự án khi bạn cần đáp ứng lịch biểu của khách hàng.
PM: Vâng, vậy người quản lí dự án có thể thương lượng cái gì khác nữa?
SM: Người quản lí dự án cũng có thể yêu cầu giảm khối lượng công việc (chức năng) bởi vì ít việc hơn nghĩa là bạn có thể hoàn thành các yêu cầu trong thời gian cho phép để dự án có thể được hoàn thành thành công như mong đợi. Tuy nhiên, nếu sản phẩm phần mềm không có tất cả chức năng như được yêu cầu, người dùng có thể không hài lòng. Cách tốt nhất là hỏi người dùng mức ưu tiên để xác định chức năng nào bạn có thể làm trước và cái nào có thể để trễ vào thời gian muộn hơn bằng việc dùng cách tiếp cận đưa ra dần dần.
Ngày nay, phần lớn phần mềm đều lớn và phức tạp nên rất khó làm mọi thứ ngay một lúc cho nên điều quan trọng là xây dựng phần mềm theo các bước tăng nhỏ. Bạn cần làm việc chặt chẽ với khách hàng để có được ưu tiên của họ và chốt cứng yêu cầu cho từng bước trước khi bắt đầu thiết kế. Đây là chỗ phương pháp mau lẹ rất phù hợp cho việc quản lí dự án tốt hơn. Bạn chia dự án lớn thành nhiều mảnh nhỏ và thực hiện từng mảnh như một dự án nhỏ. Khi cả hai bên có thoả thuận vững chắc về lịch chuyển giao thì người quản lí dự án có thể bắt đầu phân công cho các thành viên tổ theo vai trò và trách nhiệm của họ.
Trong dự án phần mềm, không ai làm việc một mình mà bao giờ cũng trong tổ. Công việc tổ KHÔNG phải là nhóm người làm việc trong cô lập, mỗi người làm việc riêng của mình mà là nỗ lực hợp tác của tất cả thành viên của tổ để đạt tới mục đích chung. Đây là chỗ việc xây dựng tổ là bản chất; người quản lí dự án phải trao đổi và cung cấp sự lãnh đạo trong việc xây dựng tổ.
PM: Đó là đòi hỏi quá nhiều với người quản lí dự án.
SM: Bạn nghĩ người quản lí dự án phần mềm thành công phải làm gì? Họ phải dựa vào may mắn hay kĩ năng của mình? Bạn có muốn tăng cơ hội thành công và giữ việc của mình hay để mọi sự xảy ra cho bạn? Quản lí dự án là kĩ năng cần được đào tạo để có tri thức cơ bản rồi áp dụng nó vào dự án thực để cải tiến kĩ năng của bạn. Không may, ngày nay nhiều công ti bổ nhiệm người kĩ thuật giỏi vào làm người quản lí dự án mà không có đào tạo nào. Đây là sai lầm lớn vì nhiều người sẽ thất bại và họ mất người kĩ thuật giỏi và thu được người quản lí tồi.
Nếu bạn muốn thành công, bạn phải đào tạo người quản lí dự án phần mềm. Có đào tạo về quản lí dự án nhưng nhiều người KHÔNG được đào tạo về quản lí dự án phần mềm cho nên bạn phải phân biệt họ. Phần mềm là duy nhất và yêu cầu giảng viên có nhiều kinh nghiệm, không có kinh nghiệm tất cả mọi điều bạn thu được là mớ lí thuyết mà có thể chẳng ích gì cho nghề nghiệp của bạn. Xây dựng tổ và thương lượng là hai kĩ năng nhưng có nhiều kĩ năng nữa như trao đổi. Để đảm bảo tổ hiểu yêu cầu và mục đích, người quản lí dự án phải thường xuyên trao đổi với tổ. Trao đổi là theo cả hai chiều cho nên tổ cũng phải để người quản lí dự án biết mọi điều về nhiệm vụ của họ và ý kiến của họ. Điều quan trọng là có báo cáo tiến độ hàng tuần mô tả cách dự án đang thực hiện, và nhiệm vụ nào đã được đạt tới.
PM: Đó là nhiều thứ và nhiều dữ liệu tôi phải thu thập.
SM: Có các công cụ giúp bạn thu thập dữ liệu phân tích về dự án của bạn. Các công cụ này sẽ giúp bạn phân tích độ phức tạp của phần mềm, kiểm trạng thái dự án, đánh giá tác động của thay đổi đã cho, và nhận diện vi phạm chuẩn. Dữ liệu này sẽ giúp bạn trong pha kiểm nghiệm và cung cấp dữ liệu khách quan cho quản lí dự án phần mềm. Người quản lí phần mềm tốt phải biết các công cụ này và nếu cần thì học một một học ngắn về cách dùng các công cụ này.
PM: Nhưng điều gì xảy ra nếu tôi có thể tìm ra một công cụ đích xác khớp với mọi yêu cầu của tôi?
SM: Có thể không có công cụ thoả mãn cho mọi thứ. Bạn phải xác định qui trình chuẩn cho phần mềm và lập kế hoạch về cách các công cụ này có thể khớp với từng qui trình cũng như điều gì cần được thực hiện trong từng pha như kiến trúc, thiết kế, kiểm nghiệm, tích hợp, đào tạo v.v. Có các công cụ cho từng pha như công cụ kiến trúc, công cụ thiết kế, và công cụ để thu thập độ đo, công cụ để kiểm thử cho nên bạn phải quyết định bạn muốn mua cái nào. Chính tại điểm này bạn phải ra quyết định cơ bản liên quan tới dự án của mình và bạn cần bao nhiêu công cụ bởi vì bạn sẽ cần làm ngân sách cho chúng. Đó là lí do tại sao người quản lí phần mềm cũng cần hiểu về tài chính và làm ngân sách và những điều này cũng phải được dạy trong môn học quản lí dự án phần mềm.
PM: Tại sao người kĩ thuật cần biết qui trình doanh nghiệp như tài chính và làm ngân sách?
SM: Bạn là người quản lí dự án và đó là việc của người quản lí. Ai khác sẽ làm điều đó cho bạn? Giả sử ông chủ của bạn cho bạn một ngân sách và số đó chỉ được một nửa điều bạn cần, bạn có thể hoàn thành dự án này một cách thành công được không? Nhiều người quản lí dự án phần mềm thụ động và không biết cách thương lượng, không biết hỏi cái gì, không biết ước lượng kích cỡ, phạm vi, tài nguyên, ngân sách và công cụ. Họ cần đào tạo bằng không họ sẽ không bao giờ thành công trong nghề của mình. Một công ti không đầu tư vào đào tạo sẽ không tồn tại lâu trong môi trường cạnh tranh này.
PM: Anh nhấn mạnh quá nhiều vào đào tạo. Anh nghĩ đào tạo là quan trọng thế sao?
SM: Vâng, nó là điều quan trọng nhất và là đầu tư tốt nhất mà công ti có thể làm. Tôi nghĩ điểm yếu chính của nhiều công ti là họ không hiểu bản chất của phần mềm. Họ không có vấn đề trong chi tiêu tiền về phần cứng nhưng rất keo kiệt trong đào tạo cho người của họ. Đào tạo cung cấp tri thức và kĩ năng và phải được coi là quá trình tiếp diễn. Đào tạo không bao giờ nên dừng lại vì công nghệ thanh đổi nhanh chóng. Hơn bao giờ hết, trong thời khủng hoảng kinh tế khi mọi sự đều chậm, đây là lúc cho bạn nhận đào tạo và thời gian cho đào tạo người của bạn về những kĩ năng mà họ sẽ cần khi mọi sự trở lại bình thường.
PM: Tôi đoán rằng đó là mọi thứ chúng tôi có được hôm nay. Nhưng tôi đánh giá cao lời khuyên của anh và tôi xin phép đi với cam kết cải tiến kĩ năng của tôi. Tôi hiểu rằng tôi không thể phụ thuộc vào may mắn mà vào kĩ năng của tôi trong thời không chắc chắn này. Quản lí dự án yêu cầu hiểu biết sâu sắc về cách phần mềm phải được lập kế hoạch và ước lượng. Người quản lí dự án tốt phải biết cách thương lượng với khách hàng và biết cách xây dựng tổ. Không có cách nào là tốt nhất cho người quản lí phần mềm mà không có đào tạo thêm.
Following is a conversation between a Senior Manager (SM) who advise a Software Project Manager (PM)
SM: Do you know how to keep your job in this financial crisis when many companies are reducing people?
PM: My boss will keep me if my project does well. However I do not know why some projects succeed and others fail. I guess it is a matter of luck. If I am lucky, I can keep my job.
SM: Projects mostly fail due to a lack of planning and managing, not luck. Most people skip planning and just jump into coding thinking that they will do well because they believe “software is code”. Many have not even taken the time to define what problems they must solve. You can not count on luck to keep your job.
PM: So what should I do to ensure a successful project?
SM: There is a software process that every project manager must follow. Coding is the easiest thing to do because most people are trained to code but not train about software process. Software work is more than coding; actually coding phase is only about 20% of the total efforts. Don’t make the same mistake as others by putting too much effort into coding; it will waste your time, leaving you with a lot of problems.
PM: What is this software process?
SM: The Software process is a set of steps that you must do. As project manager you need to:
Evaluate your customer’s business needs.
Define the requirements and verify with customers and users.
Build a good project team.
Identify a standard process and software metrics.
Create a project plan with estimates.
Negotiate with customers
Train your project team and managing them accordingly.
PM: What do you mean by “evaluating customer’s business needs”?
SM: To begin, you need to look at your customer’s business needs. A project is only successful when the needs of customers and users are met .This is the most important to your projects because their needs dictate what your development process will be. You must understand their problems before you can come up with a solution. Beside that, you need to know your customers (People who pay for the product) and users (People who use the product) and discussing things with them, build relationship with them and let them know that you are there to support them. You must remember that they are the ones that will ultimately pay for your efforts and support you if things do not go well.
PM: OK. Suppose I have good relationship with them and understand their needs, what’s next?
SM: Define requirements for the project. Input to this process should come from your customer, users, business analysts, and managers. Start by fully understanding all the things that you must do including things that you must deliver to them. Many people think the only delivery is the software product or code. That is not correct, there are much more such as requirements document, architect document, user interface document, design document, test cases etc. All of these require a lot of works so the best thing to do is asking your customers what kind of things that they need and when do they expect them? Communication is critical during the early phase of the project. This is where you should spend at least 20% of the effort to get the requirements correct.
PM: Do you think that 20% is too much. It is almost the same effort as coding.
SM: I would spend more time in requirements phase than anything other phases. Requirements dictate everything, wrong requirements means project failure. This is the time that you must invest a lot of efforts to understand what customers want and what do they expect. Failure to capture requirements is the most common factor in project failure. Most people spend less than 5% of effort during requirements but more than 50% effort in coding and that is why so many software projects failed. If they do not understand requirements, they will build the wrong thing and then have to fix it which costs more and make customers very angry because they do not get what they want in a timely manner.
PM: OK, I think I understand your point so what is next?
SM: The next step is to build a good project team. I like the work “Building” and because it takes time to build a good team. You must understand your teams’ knowledge and skills so you can assign works to them accordingly. You need to build a good team with clearly defined roles and responsibilities so everybody is accountable. Keep in mind, every new project is a new opportunity to improve things and it always has a better chance of success when everybody understands what they are supposed to do.
PM: That is all good, but how do you find the time to accomplish all this? I’m only one person with enough things already to keep me busy full time.
SM: Building a good project team is the key factor for project success. Selecting the right people that are knowledgeable and open-minded enough to work together is always at challenge but it is the job of project manager and you must choose carefully. People in the team must be technically competent, patient, possess good teamwork skills, and experience enough to function successfully. Besides the above responsibilities, this team will need to perform the following duties:
Understand the customer’s needs.
Establish goals, strategies, and action plans.
Provide cost estimates for their task.
Train and support others.
Improve their processes using customer satisfaction surveys.
Besides their expertise, you need their supports and commitments to help you in the validation of the requirements. I would spend a lot of efforts in building the team because a good team means you have better chance to succeed.
PM: You mentioned “Identify standard process and metrics”. How do we do this?
SM: You must identify a standard process that your team should follow and a set of software metrics. The standard process is depending on the customer’s requirements whether they are well-defined and documented or they are still changing so you can select appropriate process and methods accordingly. You could select a waterfall lifecycles, an incremental release lifecycle, or you may want to select agile method. Each lifecycle requires different process. As project manager, you must know where you are and how well you are doing throughout the process. You must demonstrate your leadership and management skills to your boss by having weekly status report so they know what they got for their money. For your career’s security, you need metrics to prove to management that you are managing the project and have data to prove it. Metrics helps you find out what is wrong and how to fix it. Let me give you an example, think of software project as a patient in a hospital. No doctor would treat a patient without knowing all the symptoms. Similarly, how do you manage the project without knowing the problems of the project? Metrics gather data for you as you need to know the status of the project in order to take corrective actions. However, metrics must be non-threatening to the team. Don’t use them for personnel appraisals, judgments; just use metrics for process improvement and continued monitor your project. Otherwise, the team only report what they think you want to see than it is useless. You must require honest, accurate, and consistent data from the team.
PM: My organization has a lot of software problems that could probably benefit from metrics. But how do I ask them to estimate and collect data when they are very busy working on project? My boss insists on getting the project done on time and within certain budget.
SM: How do you know the given schedule is correct if you do not estimate your works? As Project manager, you must breakdown requirements into many tasks and assign them to team members. Each member must estimate how long it will take to complete their assignment and report to you. You can combine all these time estimates into a project schedule estimates and compare with the given schedule. If your estimates match the given schedule, then it is perfect but most of the time, they do not match so you must negotiate with your manager and customers on the delivery date.
PM: What kind of negotiation are you talking about?
SM: By knowing what the project must deliver to customers and what need to be done, including the amount of time required to complete all tasks you can determine whether you can meet the customer’s delivery date or not. If there is a big difference then you must negotiate the delivery date with customer by either request more time, additional resources or change the amount of works of the project. Negotiation is an important skill for every project manager that is not taught in most technical courses but it is an essential skill of every project manager. You must understand that most customers only guess the delivery date as they do not know exactly how long it will take so they select an approximately date for convenience. This is your chance to explain to them how do you come up with the required time based on your estimates and achieve a mutual agreement on the final delivery date. However, to some customers, delivery date is the most important as it relates with other businesses so it is critical that customer and project manager agree on a date that is reasonable for both sides. Because most customers do not understand software and project activities, they have high expectation so it is important to have several meetings to discuss on what can be done and what can not. As project manager, you do not want to get into situations where the needs and expectations do not match. For example, customer thinks the team can do it in 6 months when it may take a whole year so communication and negotiation skill are extremely important.
SM: Negotiation is the most important skill of software project manager. Unfortunately, very few training programs provide this kind of training. During negotiation, there are three factors that project manager should discuss: The amount of works (Functionality or scope), resources (people) and schedule (Date). If your schedule estimate and customer’s delivery date does not match, you could ask the customer to give you more time by changing the delivery date. You can negotiate on having additional people for the project and you must do this at the beginning of the project. More people with the right skills can speed up the project, more people can reduce the work load of team members. However, adding more people in the middle of a project when things do not work well could be a disaster. More people will disrupt project works that is already in stress. More people mean more communications and increase complexity of team dynamics. New people are not familiar with project works need time to learn, that mean people who do works have to spend time training new people and take away precious time for their works. Since tasks in software project would usually depend on others’ tasks, one person’s failure could drastically damage project progress. My rule is never added more people in the middle of the project especially when project is in trouble.
PM: That is interesting. Most managers would add more people to project when things do not work well. You are saying the opposite.
SM: That is why so many software projects failed. It seems that these managers do not have experiences in managing software projects. Software project is NOT a construction project. In construction project such as building a house, adding more people will help accelerate it but in software project it will NOT help but create more problems. From my experience, it is important to negotiate for additional people at the beginning of the project when you need to meet customer’s schedule.
PM: OK, so what else could project manager negotiate?
SM: Project manager could also ask for reducing amount of works (functionality) because less works mean you could complete the requirements within the time permitted so project could be successfully completed as expected. However, if the software product does not have all functional required, users may not be happy. The best way is to ask users for priority to determine which functions you can do first and which could be delay to later time using an incremental release approach. Today, most software is large and complex it is very difficult to do everything in one time so it is important to build the software in small incremental steps. You need to work closely with customers to get their priority and freeze the requirements for each step before starting the design. This is where agile method is well suite for better project management. You break a large project into many small pieces and implement each piece as a small project. When both sides have a firm agreement on the delivery schedule then project manager could start to assign team members by their roles and responsibilities. In software project, no one work alone but always in a team. Teamwork is NOT a group of people working in isolation, each do its own things but a cooperative effort by all members of a team to achieve a common goal. This is where team building is essential; project manager must communicate and provide leadership in team building.
PM: That is asking too much of a project manager.
SM: What do you think a successful software project manager should do? Should they rely on their lucks or their skills? Do you want to increase the chance of success and keep your job or let things happen to you? Project management is a skill that requires training to have the basic knowledge then apply it in real project to improve your skill. Unfortunately, today many companies promote good technical people into project manager without any training. This is a big mistake as many will fail and they lose a good technical people and gain a bad project manager. If you want to succeed, you must take training in software project manager. There are project management trainings but many are NOT software project management training so you must distinguish them. Software is so unique and requires instructors to have a lot of experiences, without it all you may receive is a lot of theories that may not be helpful to you career. Team building and negotiation are two skills but there are more such as communication. To ensure the team understands the requirements and goals, project manager must communicate often to the team. Communication is both ways so the team also must let project manager know everything about their tasks and their opinions. It is important to have a weekly progress report describing how the project is performing, and what task has been achieved.
PM: That’s a lot of things and data that I have to collect.
SM: There are tools to help you gather analysis data on your project. These tools will help you analyze the complexity of your software, check the project status, evaluate the impact of a given modification, and identify standards violations. This data will help you during the validation phase and provides objective data to the management of software project. A good software manager should know these tools and if needed take a short course on how to use these tools.
PM: But what if I can’t find a tool that exactly fits all my requirements?
SM: There may not be a tool that satisfies everything. You must define your software standard process and plan how these tools can fit into each process as well as what needs to be done in each phases such as architect, design, validation, integration, training, etc. There are tools for each phase such as architecture tools, tools for design, and tools for collect metrics, tools for testing so you must decide which one you want to buy. It is at this point that you must make a basic decision regarding your project and how many tool that you need because you will need budget for them. That is why software project manager also need to understand financial and budgeting and these must also be taught in software project management course.
PM: Why technical people need to know business process such as finance and budgeting?
SM: You are a project manger and that is the job of a manager. Who else would do that for you? Assume your boss give you a budget that is half of what you need, could you complete the project successfully? Many software project managers are passive and do not know how to negotiate, do not know what to ask, do not know estimate size, scope, resources, budget and tools. They need training or else they will never be successful in their career. A company that does not invest in training will not survive long in this competitive environment.
PM: You are emphasizing too much on training. Do you think training is that important?
SM: Yes, it is the most important and the best investment a company can make. I think this is the major weakness of many companies that do not understand the nature of software. They have no problem in spending money on hardwares but very stingy in training for their people. Training provides knowledge and skills and should be considering an ongoing process. Training should never stop as technology is changing fast. More than ever, during the financial crisis when everything is slow, this is the time for you to take training and the time to train your people on the skill that they will need when things returning to normal.
PM: I guess that’s all the time we have today. But I appreciate your advices and let me leave you with my commitment to improve my skills. I understand that I can not depend on luck but my skills in this time of uncertainty. Project management requires a deep understanding of how software should be planned and estimated. Good project manager should know how to negotiate with customer and know how to build the team. There is no ways to be the best software manager without additional training.
