Theo một khảo cứu của một đại học Nhật Bản về thất bại của dự án phần mềm ở châu Á, tổ nghiên cứu thấy rằng 87% các dự án phần mềm thường thất bại do các lí do sau:

1)    Ngược với những người quản lí dự án phần mềm ở Mĩ và châu Âu, đa số những người quản lí dự án phần mềm ở châu Á không phải là người làm phần mềm. Nhiều người không biết cách quản lí dự án phần mềm cho dù một số người đã học các lớp hay nhận chứng chỉ về quản lí dự án. Vài người quản lí biết về vòng đời dự án phần mềm hay qui trình phát triển phần mềm. Phần lớn nhận được tài trợ cho dự án từ người quản lí cấp cao và họ muốn chi số tiền nhanh nhất có thể được bằng việc mua nhiều trang thiết bị, phần cứng, hệ thống mạng rồi đặt hàng cho tổ dự án bắt đầu viết mã để chứng minh rằng dự án đang có tiến bộ.

2)    Không có kĩ năng quản lí dự án thích hợp, nhiều người cố gắng tỏ ra bận rộn bằng việc dành nhiều thời gian vào các cuộc họp của công ti thay vì quản lí dự án. Phần lớn không biết gì về làm ước lượng dự án, dự án phải mất bao lâu, hay bao nhiêu người phải có cho nó. Họ học cách tạo ra “bản kế hoạch dự án” bằng việc dùng khuôn mẫu với các lịch biểu chi tiết về bao nhiêu tiền đã chi mặc dầu nó chẳng liên quan gì tới tiến độ dự án thực tại. Không có nhận diện rủi ro hay kế hoạch giảm nhẹ rủi ro vì họ coi rủi ro là vấn đề may hay không may.

3)    Để trình diễn kĩ năng quản lí của mình, họ thường triệu tập các cuộc họp dự án ở đó họ yêu cầu các thành viên tổ phân tích mọi thứ tới mức chi tiết nhưng chẳng hoàn thành cái gì và hầu như không đóng góp gì để làm cho công việc được thực hiện. Nhiều người quản lí dựa trên người lãnh đạo phát triển của họ để làm cho mọi việc được thực hiện và thường đặt người lãnh đạo của họ vào chịu trách nhiệm để cho họ có thể hướng dẫn người khác. Những người quản lí này không biết cách giám sát tiến độ mà thường dựa vào báo cáo từ người lãnh đạo phát triển.

4)    Khi yêu cầu thay đổi, họ muốn giữ hình ảnh tích cực với khách hàng bằng việc chấp nhận mọi yêu cầu thay đổi mà không đặt câu hỏi với khách hàng. Phần lớn không biết cách thương lượng về chi phí hay lịch biểu nhưng thường lại chứng minh rằng họ có đáp ứng với khách hàng bằng việc buộc tổ làm việc vất vả hơn. Họ có xu hướng giữ tin xấu khỏi lan tới khách hàng hay quản lí cấp cao hơn vì họ tin rằng phần lớn mọi sự có thể được giải quyết mà không gây ra chấn động.

5)    Khi dự án có rắc rối, họ sẵn lòng thêm nhiều người, chi thêm nhiều tiền để giữ cho mọi sự trở lại bình thường. Họ tin rằng bằng việc có thêm người, sự việc sẽ tốt hơn. Họ cũng tin rằng nhiều người phụ thêm sẽ đem tới cảnh quan tươi sáng cho dự án. Bằng việc yêu cầu nhiều hỗ trợ và nhiều người, họ tin khách hàng sẽ thấy rằng họ thực sự nhận tình huống một cách nghiêm chỉnh.

—-English version—-

Software project failures

According to a Japanese university’s study on software project failures in Asia, the research team found that 87% of software projects often fail due to the following reasons:

1)    In contrast to software project managers in the U.S. and Europe, a majority of software project managers in Asia are not software people. Many do not know how to manage software projects even some may have taken classes or receive project management certificates. Few managers know about software project life cycle or software development process. Most receive funding for the project from senior managers and they like to spend money as fast as possible by buying more equipments, hardware, network systems then order the project teams to begin coding to prove that projects are making progress.

2)    Without appropriate project management skills, many try to look busy by spending more time in company’s meetings rather than managing projects. Most know nothing about project estimating, how long the project should take, or how many people should be on it. They learn to create a “project plan” using template with detailed schedule on how much money would be spend although it has nothing to do with the actual project’s progress. There is no risk identification or risk mitigation plan as they consider risk is the issue of luck or unlucky.

3)    To demonstrate their management skills, they frequent call project meetings where they request team members to analyze everything into level of details but accomplish nothing and contribute little to getting the work done. Many managers rely on their lead developer to get things done and often put them in charge so that they can guide others. These managers do not know how to monitor progress but often rely on report from the lead developer.

4)    When requirements change, they want to keep a positive image with customers by accept all request for changes without question them. Most do not know how to negotiate on costs or schedule but often prove that they are responsive to customers by forcing the team to work harder. They tend to keep bad news from reaching customers or higher level of management as they believe that most things can be resolved without causing a commotion.

5)    When project is in trouble, they are willing to add more people, spend more money to keep things back to normal. They believe that by having more people, thing would get better. They also believe that more additional people will bring a fresh perspective to the project. By asking for more support and people, they believe customer will see that they are really taking the situation seriously.