Giống như chứng khoán thực hiện kém trên thị trường chứng khoán, dự án phần mềm có nhiều vấn đề nên được cắt bỏ sớm thay vì cho phép nó tiếp tục. Không may, sự kiện là có nhiều dự án kém đã bị cắt bỏ chỉ sau khi người ta chi hàng triệu đô la để giữ cho chúng tiếp tục kéo dài thêm một thời gian.

Tất nhiên, khó cắt bỏ dự án kém đặc biệt sau khi bạn đã đổ nhiều tiền và nỗ lực thế vào nó. Sau rốt, không ai muốn nhìn vào cái dở. Người quản lí cấp cao không muốn bị khiển trách về tiêu tiền vào cái gì đó thất bại. Người quản lí dự án không muốn bị mọi người biết mình là người quản lí dự án thất bại cho nên họ thường bỏ qua nó và hi vọng vấn đề trôi đi cho tới khi nó tệ đến thế và phải bị cắt bỏ. Khi dự án kém xảy ra, người quản lí cấp cao đổ lỗi cho người quản lí dự án và người quản lí dự án đổ lỗi cho người phát triển phần mềm và thường người ở mức thấp nhất sẽ là nạn nhân.

Tại sao ai đó cho phép điều như vậy xảy ra? Tại sao người quản lí không cắt bỏ dự án kém? Đó thực sự là thiếu quyết định và tính đảm nhiệm. Về căn bản, một dự án phải qua nhiều điểm kiểm trong vòng đời của nó và tại từng điểm kiểm, người quản lí phải ra quyết định. Khi một dự án đạt tới điểm kiểm mà không đáp ứng điều kiện nào đó, người quản lí phải hoặc sửa vấn đề cho tới khi nó đáp ứng điều kiện qua được hoặc cắt bỏ dự án nếu rủi ro quá cao. Đó là điều điểm kiểm được thiết kế để phục vụ. Không có tri thức đúng về quản lí dự án, thỉnh thoảng người quản lí cho phép dự án tiếp tục do đó làm tăng rủi ro dự án, cả về mặt kĩ thuật và tài chính. Việc thiếu ra quyết định này và đánh giá quản lí nghèo nàn thường tạo ra nhiều vấn đề hơn cho dự án trong pha tiếp. Nếu nó được phép tiếp tục, vấn đề sẽ tích luỹ và dự án chung cuộc thất bại sau khi tiêu tốn nhiều tiền và nỗ lực.

Dự án phải có nhiều điểm kiểm hay cổng được lập kế hoạch. Kiểm điểm cổng cho phép người quản lí dự án biết trạng thái dự án, các vấn đề chính và rủi ro để cho người đó có thể ra quyết định đúng. Người quản lí dự án giỏi phải quyết định liệu dự án nên được dừng lại để làm cải tiến trước khi cho phép tiếp tục hay cắt bỏ do những rủi ro nào đó hay vấn đề công nghệ. Kiểm điểm cổng truyền thống thường được đặt vào cuối từng pha. Chẳng hạn, trong vòng đời thác đổ, kiểm điểm cổng xảy ra và cuối của pha yêu cầu, pha kiến trúc, pha thiết kế, pha viết mã và pha kiểm thử.

Điểm kiểm thứ nhất tới tại cuộc kiểm điểm về yêu cầu. Kiểm điểm này sẽ cho phép người quản lí dự án xác định liệu các yêu cầu có là đủ tốt để bắt đầu dự án không. Nếu không thì dự án sẽ không bắt đầu và tổ có thể cần nhiều thời gian hơn để phân tích và hiểu các yêu cầu về chi tiết. Bằng việc rõ hiểu yêu cầu, người quản lí dự án có thể ước lượng chi phí phát triển và lịch biểu tốt hơn và quyết định liệu ngân sách là đúng hay cần cập nhật tương ứng. Trong suốt dự án, có nhiều điểm kiểm mà người quản lí dự án phải kiểm điểm liệu có cho phép dự án tiếp tục hay không.

Một điểm kiểm quan trọng khác tới vào cuộc kiểm điểm sản phẩm cuối cùng sau pha kiểm thử. Kiểm điểm này sẽ cho phép người quản lí dự án quyết định liệu sản phẩm có sẵn sàng cho việc gửi cho khách hàng hay không. Đây là quyết định chính nên được lập kế hoạch cẩn thận theo chi tiết đặc biệt và đo được. Đây cũng là kiểm thử để xác định người quản lí dự án giỏi và người quản lí dự án kém vì bao giờ cũng có sức ép từ quản lí cấp cao để gửi sản phẩm đi. Tuy nhiên, nếu bạn gửi một sản phẩm đầy lỗi, bạn sẽ nhận được nhiều vấn đề về sau vì khách hàng sẽ phàn nàn và bạn sẽ phải sửa chúng với chi phí cao hơn nhiều.

Để ra quyết định tốt hơn, người quản lí dự án phải lập kế hoạch cho mọi điểm kiểm trên dự án với những điều kiện qua được nào đó. Thỉnh thoảng, điều tốt nhất là đưa người khác vào trong quá trình ra quyết định và phải chắc rằng mọi người đều làm việc cùng nhau để đạt tới mục đích chuyển giao dự án chất lượng cao, đúng thời gian và trong ngân sách.

—-English version—-

Project checkpoints

Like a stock that performs poorly on the stock market, software project that having lots of problems should have been canceled earlier rather than allows it to continue. Unfortunately, the fact is there are many bad projects that were cancelled only after people spent millions of dollars to keep them continue for awhile.

Of course, it is difficult to cancel a bad project especially after you put so much money and efforts to it. After all, no one wants to look bad. Senior manager does not want to be blame of spending money on something that fails. Project manager does not want to be known as the manager of a fail project so they often ignore it and hope the problems go away until it gets so bad and must be cancelled. When bad thing happens, senior manager blames project manager and project manager blames software developers and usually the lowest level people would be victims.

Why would someone allow such thing to happen? Why would manager not cancel a bad project? It is really the lack of decision making and accountability. Basically, a project must pass through many checkpoints in its lifecycle and at each checkpoint, manager must make decision. When a project reach a checkpoint without meeting certain conditions, the manager must either fix the problems until it meets the passing condition or cancel the project if the risk is too high. That is what checkpoint is designed for. Without proper knowledge about project management, sometime manager allows the project to continue therefore increase the project risks, both technically and financially. This lack of decision making and poor management judgment often create more problems to the project in the next phase. If it is allowed to continue, the problems will accumulate and project will eventually fail after consumes a lot of money and efforts.

Project must have several planned checkpoints or gates. Gate reviews allow project manager to know the project status, major issues and risks so he can make the right decision. A good project manager must decide whether the project should be stopped to make improvement before allows to continue or cancel due to certain risks or technology issues. Traditional gate reviews are often set at the end of each phase. For example, in the Waterfall lifecycle, gate reviews happen at the end of the requirement phase, architecture phase, design phase, coding phase and testing phase.

The first checkpoint comes at the review of the requirements. The review will allow project manager to determine whether the requirements are good enough to start the project. If not then the project should not start as the team may need more time to analyze and understand requirements in details. By understand requirements well, project manager can estimate the development cost and schedule better and decide whether the budget is correct or need to update accordingly. Throughout the project, there are many checkpoints that project manager must review and decides whether to allow the project to continue or not.

Another important checkpoint comes at the review of the final product after testing phase. The review will allow project manager to decide whether the product is ready to ship to customers or not. This is a major decision that should be planned carefully in specific and measurable details. This is also a test to determine a good project manager and a bad project manager because there is always pressure from senior management to ship the product. However, if you ship a product full of defects, you will get a lot of problems later as customers will complain and you will have to fix them at much higher costs.

To make better decisions, project manager must plan all checkpoints on the project with certain passing conditions. Sometime, it would be best to involve others into the decision making process and make sure that everybody is working together to achieve the goals of deliver high quality project, on time and within costs.