Chương 14: Áp dụng tư duy hệ thống trong QLDA:

Hãy bắt đầu xem xét một vấn đề khá phổ biến trong các dự án: Công việc đang trì trệ so với kế hoạch.
Việc duy nhất cần làm tăng giờ làm việc trong một ngày của người công nhân đó, tức là làm thêm vài giờ
để theo kịp tiến độ. Anh ta đồng ý. Tuần đầu tiên, anh ta làm việc 12 giờ/ngày và công việc đã theo kịp
tiến độ dù khối lượng công việc đã làm là lớn hơn trước đây. Tuy nhiên, sau một vài tuần, bạn thấy rằng
anh ta đang gây ra rất nhiều lỗi, và chúng cần phải được sửa chữa. Hơn nữa, sản lượng của anh làm ra bị
giảm sút so với tuần đầu tiên. Sự thật là, lượng công việc anh ta đang làm chỉ tương đương với lượng
công việc anh ta làm trước khi tăng ca. Vì giờ đây anh ta dành nhiều thời gian để sửa lỗi mà anh ta đã
gây ra, và việc đó làm giảm năng suất. Ta cần phải có một giải pháp khác! Nếu làm thêm giờ không phải
là giải pháp, thì ta cần phải tăng nguồn lực. Bạn thuyết phục sếp cho bạn thêm một người để làm việc.
Điều ngạc nhiên là công việc được thực hiện bởi cả hai người hầu như không giống với làm việc một
người, và nó gây ra lỗi nhiều hơn. Chuyện gì đang xảy ra? Bạn nói chuyện với thành viên trong nhóm ban
đầu của bạn, và anh ta nói, "Mọi chuyện rất đơn giản. Anh chàng mà bạn đưa cho tôi không biết những
gì tôi đang làm. Vì vậy tôi đã dành phần lớn ngày thứ Hai gặp anh ta trên con tàu. Sau đó, tôi phát hiện
ra rằng anh ta làm rất nhiều lỗi, vì vậy tôi phải giúp anh ta sửa chữa, tôi vẫn phải làm việc ngoài giờ để
đào tạo anh ta và sửa chữa tất cả các lỗi. Tôi sẽ được tốt hơn khi không có sự giúp đỡ nào cả!”. Đây là
một ví dụ của “khắc phục lỗi sai”. Người làm thêm giờ làm đến khi sự mệt mỏi tác động lâu dài đến họ.
Sau đó, người làm bắt đầu làm ra sai sót nhiều hơn, và phải được sửa chữa, điều này khiến anh ta rơi
vào "sửa chữa mà không thành", việc yêu cầu anh ta phải làm việc nhiều hơn, gây nên mệt mỏi, và nhiều
lỗi, và cứ thế cứ thế diễn ra. Sau đó, một người làm việc được bổ sung vào dự án. Nhân viên ban đầu
phải đào tạo người mới này, điều này làm giảm năng suất của anh ta, khiến anh ta làm việc khó khăn
hơn, làm anh ta mệt mỏi, và người làm mới gây lỗi, nhưng lỗi thì phải được sửa chữa, điều này khiến
anh ta thậm chí còn mệt mỏi hơn, và cứ như vậy diễn ra. Một ví dụ khác. Tôi có biết về một công ty, nó
là Acme Electronics, ở đó sản xuất ra những linh kiện để đưa vào các sản phẩm ở các công ty khác. Đôi
lúc, khách hàng của họ có vấn đề với một trong những linh kiện đó, và những kỹ sư thiết kế được cử đến
để xem xét nếu họ có thể khắc phục được vấn đề đó. Nhưng từ khi họ làm công việc thiết kế những linh
kiện mới, thì công việc của họ trở nên trì trệ. Vì họ quản lý cả về khắc phục lỗi cho khách hàng và cả công
việc thiết kế hiện tại. Thật không may cho họ, thời hạn hoàn thành cho việc thiết kế linh kiện vẫn không
thay đổi, và họ phải đối mặt với trễ hạn. Giải pháp duy nhất là làm việc chăm chỉ để cố bắt kịp tiến độ.
Kết quả vẫn giống như trước đó, nhưng trong trường hợp này - họ làm việc kém chất lượng mà không
được giám sát. Linh kiện mới được đưa ra. Khách hàng lại có vấn đề về nó. Những kỹ sư lại được cử đến
để khắc phục vấn đề. Công việc hiện tại của họ thì vẫn rơi vào sự trì trệ. Họ lại cố gắng làm việc cật lực
để bắt kịp tiến độ, và làm phần thiết kế xuất hiện thêm nhiều cái tệ hại khác nữa, và vòng xoay bắt đầu
xoay đi xoay lại. Các biểu hiện như mô tả trong tình trạng này là việc "chữa cháy". Những người kỹ sư
"chữa cháy" công việc như là một công việc hợp lý, và không làm gì để ngăn chặn đám cháy này trong
tương lai.

Có 4 cấp độ của sự nhận biết và giải quyết vấn đề theo tư duy hệ thống, tương ứng với tính
chất từng hành động trong mỗi cấp độ:
★ events (sự kiện) - reactive (phản ứng)
là những sự việc diễn ra hàng ngày - chúng ta chỉ tìm cách giải quyết vấn đề ngay sau khi
nó phát sinh, không kiểm soát sự xuất hiện của nó
 ★ patterns of event (mô hình sự kiện) - adaptive (thích ứng)
vấn đề xảy ra theo cùng 1 mô hình (trong 1 thời gian nhất định) - tìm cách thích ứng
trong việc tiếp nhận, phản hồi những vấn đề (nhận ra sự tương tự của các tác nhân
chính làm nảy sinh vấn đề)
★ systemic structure (cấu trúc hệ thống) - creative (sáng tạo)
liên hệ và tìm hiểu nguyên nhân xảy ra vấn đề qua các mô hình - ngăn chặn vấn đề, định
hướng tương lai, tạo ra kết quả khác với thông thường (khác với mô hình); lập nhóm
riêng để giải quyết vấn đề (các kỹ sư thiết kế không phải làm điều đó nữa)
★ shared vision (tầm nhìn chung) - generative (kiến tạo)
tìm hiểu những cấu trúc hình thành mô hình (nguyên nhân tạo ra mô hình) - định hướng
cho tương lai, đặt ra những câu hỏi sâu xa hơn, mang tính giải quyết vấn đề lâu dài, bền
vững
Chương 10: Quản lý rủi ro của dự án

It seems clear that when something goes wrong, we have the possibility of suffering harm or loss, which
is defined as risk. There are two places in which risk management needs to be done. The first is in
planning project strategy. The second is in implementation planning.

the first step in risk analysis is to identify what might go wrong

While threats and risks are technically different, for the purposes of managing projects, they can be
lumped together in the same analysis.

Định nghĩa rủi ro

Rõ ràng là khi có sự cố xảy ra, chúng ta có khả năng bị tổn hại hoặc mất mát, được định nghĩa là rủi ro.
Có hai nơi mà việc quản lý rủi ro cần được thực hiện. Đầu tiên là trong việc hoạch định chiến lược dự án.
Thứ hai là trong việc lập kế hoạch thực hiện.

Rủi ro (risk) là những thứ có thể xảy ra mà không phải do cố ý. Ví dụ có thể là tai nạn; thiên tai. Mối đe
dọa (threat) là điều gì đó được thực hiện bởi đối thủ cạnh tranh hoặc đối thủ để cản trở thành công của
bạn. Mặc dù các mối đe dọa và rủi ro khác nhau về mặt kỹ thuật, nhưng đối với mục đích quản lý dự án,
chúng có thể được gộp lại với nhau để phân tích.

Tốt nhất nên phòng tránh rủi ro

Bắt đầu phân tích rủi ro bằng cách xác định những gì có thể xảy ra sai sót mà có thể ảnh hưởng đến thời
gian, chi phí, hiệu suất trong dự án.

Phòng tránh rủi ro luôn tốt hơn là quản lý nó. Điều này được thực hiện thông qua việc lập kế hoạch tốt
hơn. Phòng ngừa luôn ít tốn kém hơn thất bại.

Nếu nó không thể tránh khỏi, bạn có thể cố gắng giảm tác động. Ví dụ, thời tiết có thể làm trì trệ các dự
án và không thể tránh. Giải pháp là kiểm tra lịch sử thời tiết cho khu vực và thời gian trong năm và thay
đổi kế hoạch một khoảng hợp lý.
Đo lường, đánh giá rủi ro và mối đe dọa

Cách tiếp cận đầu tiên được các kỹ sư nghĩ ra để xác định các thiết kế sản phẩm có thể bị lỗi được gọi là
FMEA (failure mode effects analysis).

Một khi đã suy nghĩ về một danh sách các rủi ro, chúng ta phải ước tính xác suất mà chúng có thể xảy ra
(Probability of Occurrence). Lưu ý rằng thang đo Probability là thang đo logarit, trong khi các thang còn
lại là tuyến tính.

Tiếp theo, chúng ta cần xem xét mức độ ảnh hưởng của sự kiện hoặc sự cố xảy ra trong dự án (Severity
of the Effect). Một sự kiện có xác suất xảy ra cao nhưng tác động thấp đến dự án thì ít được quan tâm,
trong khi một sự kiện có xác suất thấp nhưng tác động đáng kể là mối quan tâm lớn.

Điều tiếp theo chúng ta xem xét là độ khó của việc dự đoán sự kiện sắp xảy ra trước khi nó thực sự diễn
ra (detection capacity). Lưu ý rằng thang đo này bị đảo ngược, nghĩa là, bạn càng chắc chắn rằng bạn có
thể phát hiện ra mối nguy hiểm, thì rank càng thấp.

Đối với mỗi rủi ro mà bạn đã xác định, bây giờ bạn có ba thước đo: mức xác suất, mức độ nghiêm trọng
và khả năng phát hiện. Ba con số này được nhân lại để thu được số xác suất rủi ro (RPN).

Con số đó càng cao, rủi ro càng nghiêm trọng. Tùy vào trường hợp chúng ta có thể giảm xác suất rủi ro
hoặc độ nghiêm trọng, hoặc có thể tăng khả năng phát hiện bằng cách thận trọng hơn để giúp giảm số
RPN.

Phát triển kế hoạch phòng sự cố bất ngờ (DEVELOPING CONTINGENCY PLANS)

Sau khi xác định, định lượng rủi ro, ta hướng tới việc quản lý chúng:

Điều này có thể được thực hiện theo ba cách:

1.Risk avoidance.

Trong thiết kế kỹ thuật sử dụng các chiến lược thiết kế song song để tránh khả năng lỡ hạn vì một chiến
lược khó thực hiện. Trong bất kỳ dự án nào, tránh có thể là chiến lược thích hợp nhất để thực hiện.

2. Mitigation (giảm thiểu).

Có thể giảm độ khó mục tiêu để nhóm dự án có thể hoàn thành đúng tiến độ, sau đó quay lại và kết hợp
phần việc bị hoãn lại để hoàn thành công việc chưa xong.

3. Transfer (chuyển đổi rủi ro)

- Phòng ngừa tổn thất (như việc đăng ký bảo hiểm, sao lưu dữ liệu, hoặc có 1 nhân viên dự phòng
để thực hiện công việc khi người chủ chốt bị ốm, với điều kiện người thay thế phải có kỹ năng
tương đương với người được thay thế)

- Dự phòng chi phí (có khoản ngân sách dự phòng cho những thay đổi so với kế hoạch)

6 thước đo thành công của dự án:

Kỹ thuật 1: Phép đo chủ quan về thành công kỹ thuật liên quan đến yêu cầu ban đầu

Kỹ thuật 2: Các thước đo chủ quan của thành công kỹ thuật so với các dự án khác trong.
Chi phí: Đo lường chủ quan của ngân sách vượt quá / sử dụng dưới mức

Thời gian: Là thước đo chủ quan của việc vượt/ chậm tiến độ

Quy trình: Mức độ hài lòng với quy trình quản lý dự án; một dự án thành công yêu cầu quản lý xung đột
và khủng hoảng tối thiểu.

Tổng thể: Các thước đo chủ quan về thành công tổng thể của dự án.

Couillard kết luận rằng các mẫu giao tiếp (communication patterns) và hiểu biết về mục tiêu dự án
(project goal understanding) ảnh hưởng đáng kể đến cả sáu thước đo thành công của dự án (Bảng 15–
4).

Các nhà quản lý dự án trong nghiên cứu được yêu cầu đánh giá rủi ro dự án theo ba mục tiêu: hiệu suất
kỹ thuật, tiến độ và chi phí. Couillard đã sử dụng thang điểm ba trong đó rủi ro được đánh giá là thấp,
trung bình và cao.

- Rủi ro kỹ thuật : Khi rủi ro kỹ thuật cao, thành công của dự án bị ảnh hưởng bởi quyền hạn của người
quản lý dự án(project manager authority), giao tiếp(communication), làm việc nhóm(team support) và
xử lý vấn đề(problem handling).

- Rủi ro chi phí : Khi rủi ro chi phí cao, sự thành công của dự án bị ảnh hưởng bởi sự hiểu biết về các mục
tiêu dự án của nhóm (understanding of project goals by the team), quyền của người quản lý dự án, làm
việc nhóm và giao tiếp

- Rủi ro tiến độ: Nếu rủi ro về tiến độ cao, hai yếu tố quan trọng: kinh nghiệm của người quản lý dự
án(the project manager’s experience) và tần suất giám sát tiến độ(the frequency of monitoring
progress).

Các dự án rủi ro cao cần lập kế hoạch, giám sát và kiểm soát cẩn thận hơn. Cần thận trọng làm theo các
nguyên tắc sau:

1.Nhấn mạnh sự hỗ trợ giữa những người trong nhóm.

2. Trao cho người quản lý dự án quyền hạn thích hợp.

3. Cải thiện khả năng xử lý vấn đề và giao tiếp.

4. Tránh cấu trúc dự án thuần túy.

5. Tăng tần suất giám sát dự án.

6. Sử dụng WBS, PERT / CPM và C / SCSC.

7. Thiết lập các mục tiêu dự án rõ ràng cho nhóm.

8. Lựa chọn người quản lý dự án có kinh nghiệm

Bài: ĐỊNH NGHĨA THÀNH CÔNG & THẤT BẠI

“Thất bại đơn giản là cái gì đó đi sai hay không hoạt động theo ý muốn. Bằng cách mở rộng khái niệm
đơn giản này, chúng ta có thể định nghĩa rất nhiều loại lỗi sai khác nhau.”

Một Dự Án Thất Bại Khi Nó Không Đáp Ứng Được Mục Tiêu Về Chi Phí, Hiệu Suất, Thời Gian Hoặc Phạm
Vi Mục Tiêu (C, P, T, S) Của Nó. (cost, performance, time, scope).

4 lỗi thường mắc phải khi giải quyết vấn đề

Không hành động khi cần hành động

Hành động khi không nên hành động

Hành động sai dẫn đến giải quyết sai vấn đề

Xác định đúng vấn đề nhưng giải quyết không hiệu quả

4 loại thất bại

Không đạt được mục tiêu (VD: một phần mềm không hoạt động bình thường hoặc là một sản phẩm mới
mà doanh nghiệp không thể đưa ra thị trường).

Tác dụng phụ không mong muốn: các mục tiêu ban đầu được đáp ứng, nhưng lại phát sinh ra những kết
quả hay tác dụng không mong muốn (VD: vấn đề môi trường, thuốc chữa bệnh).

Lỗi nằm trong chủ ý thiết kế: không được coi là có hại (VD: cầu chì bị chảy khi dòng điện quá mức, phô
mai xanh có mốc)

Mục tiêu không phù hợp: giải quyết sai vấn đề (lắp băng chuyền để giảm hư hỏng hàng hóa nhưng chỉ
giúp di chuyển hàng hóa thuận lợi, không giải quyết đổ vỡ hàng hóa, thất bại của Apple 3 hay betamax)

Cần phải có một định nghĩa về thành công được phát triển và chấp thuận giữa các bên liên quan trước
khi dự án được bắt đầu.

Thành công của 1 dự án được Murphy, Baker và Fisher định nghĩa: “Nếu một dự án đáp ứng được
những yêu cầu kỹ thuật và thực hiện được nhiệm vụ đề ra, đồng thời đạt được sự hài lòng ở mức cao
giữa những người chủ chốt trong tổ chức mẹ, những người chủ chốt trong tổ chức khách hàng, những
người chủ chốt trong nhóm dự án và những khách hàng hoặc nhóm khách hàng chính mà nổ lực dự án
hướng đến thì dự án đó được coi là thành công về tổng thể.”

Chúng ta nên làm gì để dự án thành công:

Chỉ nhận những việc bạn có thể làm

Làm hết mình dựa trên kinh nghiệm

Đừng cứng nhắc theo “lịch trình”

Chấp nhận tính khả biến và mạo hiểm

Đừng trông đợi vào phép màu!!!