Rà soát giai đoạn lập kế hoạch và đánh giá tính hợp lý của thay đổi phạm vi công việc trong dự án phần mềm công
1. Tổng quan
A. Định nghĩa và bối cảnh
Rà soát tính hợp lý ở giai đoạn lập kế hoạch là thủ tục kiểm chứng trước khi đặt hàng một dự án phần mềm công xem yêu cầu, phạm vi, quy mô, thời gian và mức giá có thực tế hay không; còn đánh giá tính hợp lý của thay đổi phạm vi công việc là cơ chế kiểm soát dùng thủ tục chính thức để xác định việc bổ sung, thay đổi, loại bỏ hạng mục công việc phát sinh trong quá trình thực hiện dự án có chính đáng và hợp lý hay không. Mục đích chung của hai chế độ này là phòng ngừa thất bại dự án (chậm trễ, suy giảm chất lượng, tranh chấp) do kế hoạch sơ sài và thay đổi công việc tùy tiện.
Lý do căn bản cần đến các đánh giá này là 'nếu khởi đầu sai hoặc bị chao đảo giữa chừng thì dự án sẽ thất bại'. Dự án phần mềm công thường được đặt hàng khi yêu cầu còn chưa rõ ràng, với tiến độ gấp gáp và mức giá thấp, và trong quá trình phát triển, công việc liên tục bị bổ sung, thay đổi đến mức mất kiểm soát. Đặc biệt, cơ quan đặt hàng phải xác lập quy mô dự án tại thời điểm lập ngân sách, nhưng khi đó yêu cầu chưa được chi tiết hóa đầy đủ mà chỉ tính được mức giá sơ bộ — đây là giới hạn mang tính cấu trúc. Kết quả là sau khi khởi động, các yêu cầu bổ sung kiểu "chẳng phải cái này đương nhiên được bao gồm sao" (còn gọi là sự trôi dạt phạm vi yêu cầu, scope creep) tích tụ dần, và bên thực hiện phải hấp thụ chúng trong giới hạn giá hợp đồng, rốt cuộc hy sinh chất lượng.
Đánh giá tính hợp lý ở giai đoạn lập kế hoạch kiểm chứng trước 'ngay từ đầu dự án này có khả thi với thời gian và phạm vi này không' để ngăn các đơn đặt hàng thiếu thực tế, còn đánh giá tính hợp lý của thay đổi phạm vi công việc xác định 'thay đổi này có chính đáng và hợp lý không, việc điều chỉnh thời gian và mức giá tương ứng đã được thực hiện chưa' để kiểm soát việc mở rộng phạm vi tùy tiện và đẩy chi phí bất hợp lý. Tức là có thể xem đây là cơ chế an toàn kép quản lý rủi ro tại hai cửa: lối vào (kế hoạch) và trong quá trình thực hiện (thay đổi) của dự án.
Về mặt thể chế tại Hàn Quốc, 「Luật Chấn hưng Phần mềm」 (sửa đổi toàn diện 「Luật Chấn hưng Công nghiệp Phần mềm」 năm 2020) cùng các thông tư hướng dẫn, và 「Sổ tay Đặt hàng·Quản lý Dự án Phần mềm Công」 mà cơ quan đặt hàng áp dụng, là căn cứ cho việc rà soát kế hoạch và thẩm định công việc. Tuy nhiên, tên thông tư và điều khoản chi tiết thường xuyên được sửa đổi, nên khi áp dụng thực tế nên kiểm tra nguyên văn luật và thông tư mới nhất.
B. Sự cần thiết
Để ngăn chặn những thất bại lặp đi lặp lại của dự án phần mềm công, tính khả thi của kế hoạch dự án và tính chính đáng của thay đổi công việc phải được xác định bằng tiêu chí khách quan và thủ tục chính thức, chứ không theo ý chí chủ quan của riêng cơ quan đặt hàng hay bên thực hiện. Sự cần thiết có thể chia thành ba tầng. Thứ nhất là hiệu quả ngân sách. Đặt hàng giá thấp, thời gian ngắn một cách thiếu thực tế ngược lại làm tăng chi phí làm lại và bảo hành sửa lỗi, đẩy tổng chi phí sở hữu (TCO) lên cao. Thứ hai là chất lượng và sự ổn định của dịch vụ công. Sự yếu kém của các hệ thống gắn trực tiếp với đời sống người dân như hành chính, phúc lợi, thuế sẽ bị chuyển thành chi phí xã hội. Thứ ba là quan hệ hợp đồng công bằng. Phải bảo đảm việc điều chỉnh giá và thời gian tương ứng với thay đổi công việc thì mới giảm được tranh chấp giữa cơ quan đặt hàng và bên thực hiện, và giữ được sự lành mạnh của hệ sinh thái ngành phần mềm.
2. Cấu trúc tổng thể — Luồng rà soát kế hoạch và kiểm soát thay đổi công việc
Rà soát kế hoạch và đánh giá thay đổi công việc không phải là các sự kiện riêng biệt mà là một hệ thống quản lý rủi ro liên kết xuyên suốt vòng đời dự án (chuẩn bị đặt hàng → hợp đồng → thực hiện → nghiệm thu). Sơ đồ cấu trúc dưới đây cho thấy hai cửa kiểm soát nằm ở đâu và ăn khớp với những sản phẩm đầu ra, cơ quan nào.
flowchart TB
subgraph PlanStage["Giai đoạn lập kế hoạch (trước khi đặt hàng)"]
A1["Tính rõ ràng của yêu cầu·phạm vi"] --> G1{"Đánh giá xác lập dự án·tính hợp lý thời gian"}
A2["Ước tính quy mô·mức giá (FP...)"] --> G1
A3["Căn cứ ước tính thời gian"] --> G1
A4["Yếu tố rủi ro·ràng buộc"] --> G1
end
G1 -->|Hợp lý| B["Xác lập hồ sơ mời thầu (RFP)·hợp đồng"]
G1 -->|Không hợp lý| A0["Chi tiết hóa yêu cầu (ISMP)·rà soát lại"]
A0 --> G1
B --> C["Thực hiện dự án (thiết kế·phát triển)"]
C --> D{"Phát sinh thay đổi công việc"}
D -->|Yêu cầu thay đổi| G2{"Hội đồng thẩm định công việc xem xét"}
G2 -->|Chính đáng·điều chỉnh hợp lý| E["Phản ánh thay đổi công việc + điều chỉnh thời gian·mức giá"]
G2 -->|Không chính đáng·quá mức| F["Bác bỏ thay đổi hoặc điều chỉnh phạm vi"]
E --> C
style G1 fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style G2 fill:#fde8e8,stroke:#d64545,stroke-width:2px
Điểm đáng chú ý trong cấu trúc trên là sự khác biệt về tính chất của hai cửa kiểm soát. Đánh giá ở giai đoạn lập kế hoạch (G1) là kiểm soát mang tính phòng ngừa (preventive), một cánh cổng sàng lọc để các dự án thiếu thực tế không được bắt đầu ngay từ đầu. Ngược lại, thẩm định công việc (G2) là kiểm soát mang tính khắc phục (corrective) trong quá trình thực hiện, một chiếc van giữ cho dự án đã bắt đầu không đi chệch quỹ đạo. Nếu yêu cầu được chi tiết hóa đầy đủ ở giai đoạn lập kế hoạch (ISMP...), bản thân các thay đổi trong quá trình thực hiện sẽ giảm, nên hai cửa kiểm soát có quan hệ bổ trợ lẫn nhau.
3. Các hạng mục rà soát ở giai đoạn lập kế hoạch (xác lập dự án·tính hợp lý thời gian)
Mục tiêu của rà soát ở giai đoạn lập kế hoạch là xác định "xét theo phạm vi yêu cầu và quy mô, thời gian và mức giá của dự án có thực tế không". Sơ đồ luồng chi tiết dưới đây thể hiện rà soát được tiến hành theo trình tự nào.
flowchart LR
R["Thu thập yêu cầu"] --> S1["Rà soát tính rõ ràng của yêu cầu·phạm vi"]
S1 --> S2["Ước tính quy mô (điểm chức năng FP)"]
S2 --> S3["Tính mức giá hợp lý"]
S3 --> S4["Rà soát tính hợp lý về thời gian"]
S4 --> S5["Phản ánh rủi ro·ràng buộc"]
S5 --> J{"Đánh giá tổng hợp tính hợp lý"}
J -->|Chưa đạt| S1
J -->|Hợp lý| OUT["Xác lập đặt hàng"]
A. Tính rõ ràng của yêu cầu·phạm vi
Nguyên nhân đầu tiên của kế hoạch sơ sài là dự án được đặt hàng khi yêu cầu còn mơ hồ. Nếu yêu cầu chỉ được mô tả trừu tượng như "toàn bộ chức năng quản lý thành viên", bên thực hiện và cơ quan đặt hàng sẽ mỗi bên hình dung một phạm vi khác nhau, và khoảng cách này về sau bùng nổ thành tranh chấp thay đổi công việc. Vì vậy, ở giai đoạn lập kế hoạch cần xem xét yêu cầu chức năng và phi chức năng đã được tổng hợp ở mức có thể đo lường và mang tính xác định hay chưa. Ví dụ, không phải "phản hồi nhanh" mà phải ở dạng có thể kiểm chứng như "với 1.000 truy cập đồng thời, phản hồi trung bình trong vòng 2 giây".
Với các dự án quy mô lớn, phức tạp mà yêu cầu chưa được chi tiết hóa đầy đủ, khuyến nghị thực hiện trước một dự án riêng về Kế hoạch chiến lược thông tin hóa (ISP) hoặc Kế hoạch tổng thể hệ thống thông tin (ISMP) trước khi đặt hàng để cụ thể hóa yêu cầu. ISMP hướng tới việc chi tiết hóa yêu cầu đến mức có thể ước tính điểm chức năng, nên nâng cao đáng kể độ tin cậy của việc ước tính quy mô, mức giá và thời gian về sau.
B. Tính hợp lý của quy mô·mức giá
Khi yêu cầu đã được tổng hợp, quy mô được định lượng. Thước đo quy mô tiêu chuẩn của dự án phần mềm công là điểm chức năng (Function Point, FP), có ưu điểm đo kích thước chức năng từ góc nhìn người dùng, không phụ thuộc vào ngôn ngữ và công nghệ phát triển, nên được dùng rộng rãi làm căn cứ ước tính quy mô đặt hàng và tính mức giá. Áp dụng đơn giá và hệ số hiệu chỉnh theo tiêu chuẩn giá dự án phần mềm vào số FP đã ước tính để tính chi phí phát triển, rồi cộng thêm chi phí trực tiếp, lợi nhuận... để ra mức giá hợp lý.
Cốt lõi ở đây là sàng lọc rủi ro của đặt hàng giá thấp. Nếu mức giá quá thấp so với quy mô, bên thực hiện sẽ giảm nhân lực hoặc bù bằng nhân lực tay nghề thấp, khiến chất lượng suy giảm mang tính cấu trúc. Thực tế, trong các dự án phần mềm công tại Hàn Quốc, cạnh tranh giá quá mức (trúng thầu giá thấp) đã bị chỉ ra là nguyên nhân của suy giảm chất lượng và vấn đề thầu phụ, và vì vậy các chính sách như mua trực tiếp phần mềm thương mại (đặt hàng tách riêng), mở rộng phát triển từ xa, chi trả mức giá hợp lý đã liên tục được nhấn mạnh.
C. Tính hợp lý về thời gian
Dù quy mô như nhau, nếu thời gian ngắn một cách thiếu thực tế thì dự án sẽ thất bại. Việc không thể nén người-tháng (man-month) vô hạn đã được định luật Brooks ("thêm người vào một dự án đang trễ sẽ làm nó trễ hơn") chỉ ra từ lâu. Ở giai đoạn lập kế hoạch, dựa trên quy mô đã ước tính (FP) và chỉ số năng suất để tính ngược thời gian cần thiết, rồi kiểm tra khoảng chênh với thời gian mong muốn mà cơ quan đặt hàng đặt ra vì ngân sách hay lịch hành chính. Nếu khoảng chênh lớn, phải chia phạm vi thành các giai đoạn (xây dựng theo giai đoạn) hoặc hiện thực hóa lại thời gian.
Ví dụ, nếu một hệ thống thế hệ mới được ước tính quy mô 3.000 FP mà thời gian đặt hàng mong muốn là 8 tháng, xét theo chỉ số năng suất thông thường thì nhiều khả năng đây là sự nén thời gian thiếu thực tế. Trong trường hợp này, kết luận thực tiễn của rà soát kế hoạch là đưa ra lộ trình chia thành 2 giai đoạn sau khi ưu tiên xây dựng các chức năng cốt lõi.
D. Yếu tố rủi ro·ràng buộc
Cuối cùng, xem xét kế hoạch đã phản ánh các ràng buộc về công nghệ, nhân lực, tổ chức, pháp chế hay chưa. Sự bất định do áp dụng công nghệ mới, điều phối lợi ích do liên kết nhiều cơ quan, tuân thủ quy định về thông tin cá nhân và bảo mật, độ khó chuyển đổi dữ liệu từ hệ thống hiện có đều là các biến số quyết định tiến độ và chi phí. Việc những rủi ro này đã được nhận diện, định lượng trong bản kế hoạch và đã có phương án đối phó (quỹ dự phòng, tiến độ đệm) hay chưa là yếu tố đánh giá quan trọng của tính hợp lý.
| Hạng mục rà soát | Câu hỏi cốt lõi | Hậu quả khi sơ sài |
|---|---|---|
| Tính rõ ràng của yêu cầu·phạm vi | Yêu cầu có đo lường được·mang tính xác định không | Tranh chấp phạm vi sau khởi động, scope creep |
| Tính hợp lý của quy mô·mức giá | Ước tính quy mô bằng FP..., có phải mức giá hợp lý không | Đặt hàng giá thấp → suy giảm chất lượng |
| Tính hợp lý về thời gian | Thời gian có thực tế so với quy mô không | Nén thời gian thiếu thực tế → chậm trễ·yếu kém |
| Rủi ro·ràng buộc | Đã phản ánh ràng buộc công nghệ·nhân lực·quy định chưa | Dự án mắc cạn vì biến số không lường trước |
4. Tiêu chí đánh giá tính hợp lý của thay đổi phạm vi công việc
A. Vì sao thay đổi công việc trở thành vấn đề
Bản thân thay đổi công việc phát sinh sau khi dự án bắt đầu là không thể tránh khỏi. Bởi yêu cầu luôn tiến hóa, luật và chính sách thay đổi, và có những yêu cầu chỉ lộ ra sau khi khởi động. Vấn đề là khi thay đổi được thực hiện không có căn cứ chính đáng, thủ tục chính thức và điều chỉnh tương ứng. Nếu cơ quan đặt hàng bổ sung chức năng mà không điều chỉnh giá và thời gian với lý do "vốn dĩ phải làm được đến mức đó", bên thực hiện sẽ bù lỗ bằng chất lượng; ngược lại, nếu bên thực hiện tự ý thu hẹp phạm vi thì cơ quan đặt hàng chịu thiệt. Vì vậy cần có thủ tục thẩm định khách quan tính chính đáng của thay đổi và tác động của nó.
B. Bốn tiêu chí đánh giá
Tính hợp lý của thay đổi công việc được đánh giá theo bốn trục sau. Các trục không độc lập mà đan xen nhau, chỉ cần một trục lệch là thay đổi có thể bị đánh giá không hợp lý.
Thứ nhất là tính chính đáng của lý do thay đổi. Phân định xem thay đổi là không thể tránh khỏi như thay đổi luật, chính sách, thay đổi kế hoạch cấp trên, yêu cầu thiết yếu được xác nhận sau khởi động, hay chỉ là mở rộng tùy tiện theo sở thích, sự tiện lợi. Thứ hai là tác động tới phạm vi·quy mô. Định lượng mức tăng giảm điểm chức năng so với hợp đồng gốc để nắm được tỷ trọng của thay đổi trong toàn bộ dự án. Thứ ba là tác động tới tiến độ·chi phí. Nếu quy mô tăng thì phải điều chỉnh thời gian và mức giá tương ứng, và thay đổi chỉ đòi hỏi hấp thụ mà không điều chỉnh là không hợp lý. Thứ tư là tuân thủ thủ tục. Xác nhận thay đổi đã qua thẩm định của cơ quan chính thức như Hội đồng thẩm định công việc hay chưa, và thủ tục thay đổi hợp đồng (thay đổi thiết kế, điều chỉnh giá trị hợp đồng) đã được thực hiện đúng hay chưa.
Hội đồng thẩm định công việc là cơ quan có sự tham gia của cơ quan đặt hàng, bên thực hiện, chuyên gia bên ngoài... để thẩm định tính chính đáng và tác động của thay đổi, đóng vai trò cơ chế kiềm chế sự mất cân bằng quyền lực (cơ quan đặt hàng chiếm ưu thế) xung quanh thay đổi. Nếu kết quả thẩm định xác định là thay đổi chính đáng, thời gian và mức giá được điều chỉnh tương ứng, còn các yêu cầu quá mức, không chính đáng thì bị bác bỏ hoặc điều chỉnh lại phạm vi.
C. Hợp lý/không hợp lý qua ví dụ cụ thể
Ví dụ, nếu sau khi khởi động, Luật Bảo vệ Thông tin Cá nhân (của Hàn Quốc) được sửa đổi làm tăng yêu cầu mã hóa và kiểm soát truy cập khiến phải bổ sung chức năng liên quan, thì đây là thay đổi chính đáng không thể tránh khỏi, nên việc điều chỉnh thời gian và mức giá tương ứng với phần quy mô tăng thêm là hợp lý. Ngược lại, nếu cán bộ của cơ quan đặt hàng vì sở thích cá nhân yêu cầu cải tổ toàn diện thiết kế màn hình nhiều lần trong khi vẫn giữ nguyên giá và thời gian, thì đây là thay đổi không hợp lý thiếu cả tính chính đáng của lý do lẫn điều chỉnh tương ứng, và phải được kiểm soát thông qua thẩm định công việc.
| Tiêu chí đánh giá | Nội dung | Điều kiện để được đánh giá hợp lý |
|---|---|---|
| Tính chính đáng của lý do thay đổi | Có phải thay đổi thiết yếu·không thể tránh không | Căn cứ khách quan như thay đổi luật·chính sách·kế hoạch cấp trên |
| Tác động tới phạm vi·quy mô | Thay đổi quy mô so với hợp đồng gốc | Định lượng tăng giảm bằng FP... |
| Tác động tới tiến độ·chi phí | Sự cần thiết điều chỉnh thời gian·mức giá | Điều chỉnh tương ứng với thay đổi quy mô |
| Tuân thủ thủ tục | Đã qua thủ tục chính thức chưa | Thẩm định của hội đồng·thực hiện thay đổi hợp đồng |
5. Chuyên sâu — Liên kết với các chế độ liên quan và hướng ra đề dự kiến
Rà soát kế hoạch và đánh giá thay đổi công việc không phải là chế độ đơn lẻ mà vận hành ăn khớp với toàn bộ hệ thống quản lý dự án phần mềm công. Trước khi đặt hàng, yêu cầu được chi tiết hóa bằng ISP/ISMP, và đặt hàng tách riêng phần mềm thương mại giúp giảm bớt các đơn đặt hàng tích hợp thiếu thực tế. Trong quá trình thực hiện, giám sát hệ thống thông tin (giám sát theo giai đoạn, giám sát thường trú) liên tục kiểm tra tiến độ, chất lượng và thay đổi công việc, còn PMO (tổ chức quản lý dự án thay mặt cơ quan đặt hàng) rà soát trước các yêu cầu thay đổi công việc để giảm gánh nặng cho thẩm định công việc. Khi nghiệm thu, kiểm chứng việc thực hiện so với yêu cầu. Như vậy, rà soát kế hoạch (lối vào)–giám sát·PMO (thực hiện)–thẩm định công việc (thay đổi)–nghiệm thu (lối ra) tạo thành một chuỗi kiểm soát thống nhất.
Về xu hướng chính sách tại Hàn Quốc, các biện pháp nhằm giảm xung đột do trúng thầu giá thấp và thay đổi công việc như chi trả mức giá hợp lý, mở rộng phát triển từ xa, cải thiện cấu trúc thầu phụ, đánh giá tác động phần mềm... đã liên tục được nhấn mạnh. Tuy nhiên, tên chế độ chi tiết và phạm vi áp dụng thường xuyên được sửa đổi, nên khi viết bài an toàn hơn là kiểm tra luật và thông tư mới nhất và dùng cách diễn đạt khái quát.
Từ góc độ kỳ thi Kỹ sư chuyên nghiệp, chủ đề này dễ được ra đề kết hợp với "nguyên nhân thất bại và đối sách của dự án phần mềm công", "quản lý thay đổi công việc (Hội đồng thẩm định công việc)", "tính giá dự án phần mềm (điểm chức năng)", "giám sát hệ thống thông tin·PMO". Chiến lược xây dựng bài làm hiệu quả là ① trước tiên trình bày cấu trúc kiểm soát kép giữa giai đoạn lập kế hoạch (lối vào) và thay đổi công việc (thực hiện), ② triển khai tiêu chí đánh giá chi tiết của từng cửa kiểm soát bằng bảng + văn xuôi, rồi ③ kết thúc bằng các chế độ liên kết như ISMP, giám sát, PMO và xu hướng chính sách.
6. Lưu ý và hàm ý
- Bảo đảm mức giá và thời gian hợp lý là tiền đề của chất lượng. Đặt hàng giá thấp, thời gian ngắn thiếu thực tế ngược lại làm tăng tổng chi phí do làm lại và bảo hành sửa lỗi. Bảo đảm từ giai đoạn lập kế hoạch mức giá dựa trên quy mô (FP) và thời gian thực tế là điểm xuất phát của thành công dự án, và đây không phải là đánh đổi mà về lâu dài cũng có lợi cho cơ quan đặt hàng.
- Kiểm soát thay đổi công việc và điều chỉnh chính đáng phải luôn song hành. Ngăn chặn mở rộng phạm vi tùy tiện, nhưng với thay đổi chính đáng thì điều chỉnh thời gian và mức giá tương ứng mới là công bằng. Nếu chỉ nhấn mạnh kiểm soát, ngay cả những thay đổi cần thiết cũng bị thu hẹp; nếu chỉ nhấn mạnh điều chỉnh, sẽ khuyến khích scope creep, nên cân bằng là then chốt.
- Đầu tư vào kiểm soát phòng ngừa (kế hoạch) hiệu quả hơn kiểm soát khắc phục (thay đổi). Nếu chi tiết hóa yêu cầu bằng ISMP trước khi khởi động, bản thân các thay đổi trong quá trình thực hiện sẽ giảm. Xác lập yêu cầu từ phía trước sẽ giảm tận gốc chi phí và tranh chấp hơn là để thẩm định công việc gánh chịu sự không rõ ràng của yêu cầu về sau.
- Phải nâng cao hiệu lực kiểm soát thông qua liên kết với giám sát·PMO. Rà soát kế hoạch và thẩm định công việc dễ chỉ dừng ở thủ tục trên giấy tờ, nên giám sát thường trú và PMO phải thường xuyên theo dõi tiến độ và thay đổi thực tế để hỗ trợ, tránh việc thẩm định trở thành hình thức.
- Mục đích của chế độ không phải là quản lý mà là thành công dự án và sự lành mạnh của hệ sinh thái ngành. Nếu chỉ coi thủ tục kiểm soát là gánh nặng, nó sẽ bị hình thức hóa. Chỉ khi cơ quan đặt hàng và bên thực hiện sử dụng chế độ như một cơ chế hợp tác cùng quản lý rủi ro thì hiệu quả vốn có là giảm tranh chấp và nâng cao chất lượng mới xuất hiện.
Tài liệu tham khảo
- Trung tâm Thông tin Pháp luật Quốc gia (Hàn Quốc), 「Luật Chấn hưng Phần mềm」: https://www.law.go.kr/
- Bộ Khoa học và CNTT·Cơ quan Xúc tiến Công nghiệp CNTT Quốc gia (NIPA), Hướng dẫn tính giá dự án phần mềm: https://www.nipa.kr/
- Tài liệu quản lý dự án thông tin hóa công của Cơ quan Xã hội Thông tin Thông minh Quốc gia Hàn Quốc (NIA): https://www.nia.or.kr/
Tóm tắt một câu: Dự án phần mềm công kiểm chứng trước ở giai đoạn lập kế hoạch tính hợp lý của độ rõ ràng yêu cầu, quy mô (FP), thời gian và mức giá để ngăn đơn đặt hàng thiếu thực tế, và trong quá trình thực hiện thì thẩm định tính chính đáng, tác động phạm vi, tiến độ·chi phí và thủ tục của thay đổi công việc thông qua Hội đồng thẩm định công việc cũng như bảo đảm điều chỉnh tương ứng, qua đó kiểm soát hai nguyên nhân thất bại là kế hoạch sơ sài và mở rộng phạm vi tùy tiện tại hai cửa: lối vào và quá trình thực hiện.