Ước lượng dự án là một trong những nhân tố chính xác định thành công hay thất bại của dự án nhưng rất ít người biết cách làm nó đúng đắn hay đưa nỗ lực nào đó vào điều đó.

Nhiều người quản lí phần mềm nói với tôi rằng họ KHÔNG ước lượng dự án của mình bởi vì nhiều thứ đằng nào cũng thay đổi. Những người khác bảo tôi rằng cho dù họ có ước lượng, khách hành của họ có thể không đồng ý với ước lượng của họ hay đổi ý cho nên tại sao phải phí thời gian. Đây là sai lầm chính bởi vì trong trường hợp đó, người quản lí dự án cho phép khách hàng áp chế lịch biểu và ngân sách của dự án đối với họ. Làm sao bạn thích làm việc trong dự án khi bạn biết rằng lịch biểu là không hợp lí và bạn không có đủ người để làm việc đó? Làm sao bạn thích làm việc trong dự án mà bạn biết rằng nó sẽ không đáp ứng được lịch biểu và chức năng? Làm sao bạn thích làm việc trong dự án mà bạn biết rằng nó sẽ bị chậm cho dù bạn phải làm việc rất vất vả để đáp ứng lịch biểu? Tôi đã thấy rằng khi dự án bị chậm với chi phí cao nhất và ít chức năng, nhiều người quản lí dự án sẽ quở trách về yêu cầu kém, hay trách móc khách hàng đổi ý thường xuyên. Rất ít người quản lí dự án chịu thừa nhận rằng họ không biết cách ước lượng và phải mất bao nhiêu thời gian để hoàn thành dự án (Lịch biểu), dự án sẽ cần bao nhiêu người để làm việc (Tài nguyên), và nó tốn bao nhiêu (Ngân sách).

Quan điểm của tôi là ước lượng sẽ cho phép người quản lí dự án nhận diện rủi ro mà có thể ngăn cản dự án đạt được mục đích của nó. Ước lượng sẽ KHÔNG tạo ra yêu cầu tốt hơn. Nó sẽ KHÔNG làm cho khách hàng thôi đổi ý. Nó có thể KHÔNG đổi lịch biểu. Nó có thể KHÔNG cho bạn nhiều người hơn hay nhiều ngân sách hơn nhưng nó SẼ tạo ra đánh giá chính xác về rủi ro có trong dự án. Ước lượng SẼ cho bạn khả năng biết dự án sẽ thành công hay không. Bằng việc có những ước lượng này (Lịch biểu, tài nguyên, ngân sách), người quản lí dự án có thể thiết lập mong đợi ĐÚNG ĐẮN với khách hàng cho nên một thoả thuận HỢP LÍ có thể được đạt tới. Người quản lí dự án giỏi nên biết cách thương lượng với khách hàng về các rủi ro mấu chốt trong những tình huống nào đó.

Để tôi cho bạn một ví dụ: Khách hàng yêu cầu một dự án có 10 chức năng cần được hoàn thành trong 4 tháng với ngân sách dành cho 5 người phát triển phần mềm. Ước lượng của bạn lên tới 6 tháng mới hoàn thành dự án này với chức năng và tài nguyên đã cho. Bạn có thể hỏi khách hàng liệu có thể kéo dài lịch biểu từ 4 tới 6 tháng không. Nếu câu trả lời là KHÔNG thì bạn có thể cho khách hàng biết là với ngân sách hiện thời cho 5 người, bạn có thể KHÔNG có khả năng thực hiện điều đó trong vòng 4 tháng được yêu cầu nhưng nếu khách hàng có thể tăng ngân sách từ 5 tới 7 người phần mềm, thì bạn có thể đáp ứng ngày tháng đã yêu cầu. Nếu câu trả lời là KHÔNG thì yêu cầu cuối cùng của bạn sẽ là bạn sẽ hoàn thành dự án với 5 người trong 4 tháng nhưng chỉ thực hiện 6 chức năng thay vì 10 chức năng. Về căn bản, có ba nhân tố (lịch biểu, tài nguyên và chức năng) hay tổ hợp của ba nhân tố này mà bạn có thể đưa ra thương lượng. Rất có thể là bạn sẽ kết thúc với 6 người, 5 tháng và 8 chức năng sau khi thương lượng dồn dập. Ít nhất điều đó cũng là tốt hơn điều bạn được trao ngay chỗ bắt đầu.

Thương lượng là kĩ năng mấu chốt của người quản lí dự án giỏi nhưng nó KHÔNG được dạy trong trường. Tất nhiên, trước khi bạn học cách thương lượng, bạn phải biết cách ước lượng bởi vì không có ước lượng, bạn không thể đi tới chiến lược thương lượng được. Ước lượng nên được coi như phần mấu chốt để làm giảm nhẹ nhiều rủi ro có thể tác động vào dự án. Khi ước lượng được thừa nhận về giá trị của nó, khách hàng và người quản lí cấp cao rất có thể sẽ chấp nhận điều đó bằng việc yêu cầu người quản lí dự án có kĩ năng này.

Mô hình trưởng thành năng lực của SEI (CMMI) gợi ý rằng trưởng thành của một tổ chức dựa trên qui trình được thiết lập rõ và được thực hiện có hiệu quả. Một phát biểu rõ ràng về chính sách ước lượng được hỗ trợ bởi một qui trình ước lượng được xác định rõ là nhân tố chính trong việc đạt tới xếp hạng CMMI mức 3. (Nếu tổ chức của bạn được đánh giá xếp hạng ở mức trưởng thành cao hơn nhưng qui trình ước lượng của bạn KHÔNG tốt tại chỗ thì bạn có thể phải yêu cầu người đánh giá CMMI xem liệu người đó có nghiêm chỉnh trong nghề của mình hay chỉ “lừa” đánh giá để lấy tiền). Ước lượng chính xác yêu cầu nhiều dữ liệu lịch sử và những dữ liệu này chỉ có thể được thu thập nếu được cấp quản lí thừa nhận rằng đó là nhân tố quan trọng trong việc xác định qui trình dự án.

—-English version—-

Project estimates

Project estimation is one of the key factors that determine project success or failure but very few people know how to do it correctly or put some efforts into it. Many software managers told me that they do NOT estimate their projects because things will change anyway. Other told me that even if they do estimate, their customers may not agree with their estimation or change their minds so why waste time. This is a major mistake because in that case, project managers allow customers to dictate the schedule and budget of the project to them. How do you like to work in a project when you know that the schedule is unreasonable and you do not have enough people to do the job? How do you like to work in a project that you know that it will fail to meet schedule and functionality? How do you like to work in a project that you know that it will be late even you have to work very hard to meet the schedule? I have seen that when a project is late with higher costs and less functionality, many project managers would blame on bad requirements, or blaming customers changing their minds often. Very few managers would admit that they do not know how to estimate on how long will it take to complete the project (Schedule), how many people will the project need to do the job (Resources), and how much does it cost (Budget).

My view is estimates will allow project manager to identify risks that may prevent the project from achieve its goal. Estimates will NOT produce better requirements. It will NOT stop customers from changing their minds. It may NOT change the schedule. It may NOT give you more people or budget but it WILL produce an accurate evaluation of the risks involved of the project. Estimate WILL give you the possibility on whether the project would be succeeded or not. By having these estimates (Schedule, resource, budget), project managers can set expectations CORRECTLY with customers so a RESONABLE agreement can be achieved. A good project manager should know how to negotiate with customer on the critical risks of certain situations.

Let me give you an example: A customer requires a project to have 10 functions to be completed in 4 months with a budget for 5 software developers. Your estimate comes up with 6 months to complete the project with the given functionality and resources. You can ask the customer whether it is possible to extend the schedule from 4 months to 6 months. If the answer is NO then you can let the customer know that with the current budget for 5 people, you may NOT be able to do that within the 4 months required but if customer can increase budget from 5 to 7 software people, then you can meet the required date. If the answer is NO then your last request would be you will complete the project with 5 people in 4 months but only implement 6 functions instead of 10 functions. Basically, there are three factors (Schedule, resource and function) or a combination of those three factors that you can negotiate. It is very likely that you will end up with 6 people, 5 months and 8 functions after intensive negotiation. At least it is better than what you are given in the first place.

Negotiation is a critical skill of good project manager but it is NOT taught in school. Of course, before you learn how to negotiate, you must know how to estimate because without estimation, you can not come up with a negotiation strategy. Estimation should be viewed as a critical part to mitigate many risks that might impact a project. When estimating is recognized for its value, customer and senior management will be more likely to accept that by require project managers to have this skill.

The SEI Capability Maturity Model (CMMI) suggests that an organization’s maturity is based upon a well defined and effectively executed process. A clear statement of estimating policy backed by a well defined estimating process is a major factor in achieving a CMMI Level 3 rating. (If your organization is appraised at higher maturity rating but your estimating process is NOT well in place then you may want to ask the CMMI appraisal person whether he is serious about his business or just “Cheat” an appraisal for the money). Accurate estimating requires a lot of historical data and these data can only be collected if there is an acknowledgement by management that it is important factor in determining project success.