Thuyết trình

BẢNG PHÂN CƠNG CƠNG VIỆC TRONG NHĨM
Thành viên

Cơng việc

1. Đọc tồn bộ bài viết, nắm ý của từng phần,
phân cơng công việc cho các thành viên.
Cao Việt Cường 2. Dịch và thuyết trình phần “Fixes that fail”.
(Nhóm trưởng) 3. Chuẩn bị nội dung cho phần thuyết trình cá
nhân.
4. Chỉnh sửa nội dung cho bản word.
1. Đọc và nắm ý toàn bộ bài thuyết trình của
nhóm.
2. Đưa ra ý tưởng, thiết kế power point của tồn
bộ bài thuyết trình.
Trần Vân Anh
3. Biên tập file word thành bài báo cáo hoàn
chỉnh.
4. Thuyết trình 2 phần “limits to growth” và
“shifting the burden”
1. Đọc và nắm ý tồn bộ bài thuyết trình của
nhóm.
Trần Hồng
2. Dịch và thuyết trình 2 phần “Levels of
Anh Khoa
understanding” và “The tragedy of commons”.
3. Chuẩn bị nội dung cho phần thuyết trình cá
nhân.
1. Đọc và nắm tồn bộ bài thuyết trình của nhóm.
Hà Nhật Tảo
2. Dịch 2 phần “Limits to growth” và “Shifting the

burden”.

Hồn thành
cơng việc

100%

100%

100%

100%


MỤC LỤC


CÁCH ÁP DỤNG TƯ DUY HỆ THỐNG
TRONG QUẢN LÝ DỰ ÁN
Trong những phần trước đã đề cập đến vấn đề tư tưởng hệ thống có thể giúp ta hiểu được
những động lực trong các mối quan hệ giữa người với người. Nói chung, các cơng việc
dự án được con người đảm nhiệm nên ta cần phải áp dụng những khái niệm về tư tưởng
hệ thống để có thể hiểu và quản lý được các dự án.

Fixes that fail – Sửa lỗi sai
Hãy bắt đầu bằng một vấn đề thường gặp nhất trong dự án: công việc bị chậm tiến độ so
với kế hoạch. Dẫn đến việc yêu cầu nhân viên phải tăng ca thêm vài giờ làm mỗi ngày để
cho kịp tiến độ. Nếu chỉ trong 1 tuần, có thể nhân viên sẽ đồng ý làm 12 giờ mỗi ngày để
xúc tiến cơng việc. Lượng cơng việc hồn thành chắc chắn sẽ tốt hơn trước. Tuy nhiên,
sau một vài tuần, người nhân viên đó sẽ phạm rất nhiều sai lầm (chắc chắn là cần được

sửa lại). Hơn nữa, bạn sẽ thấy rằng năng suất cũng như chất lượng của nhân viên đó
xuống dốc nhiều so với những gì bạn thấy trong tuần đầu tiên. Thực chất, nếu bạn để ý sẽ
thấy lượng cơng việc mà nhân viên đó dù có dốc hết sức làm cũng chỉ bằng lúc anh ta
làm việc bình thường (40 giờ/tuần). Nhưng bạn đã vơ tình làm mất đi năng suất công việc
bởi bây giờ phải tốn thêm thời gian sửa lỗi mà anh ta gây ra và điều này đã giảm đi năng
suất của nhân viên khá nhiều.
Cần phải làm một điều gì đó để giải quyết tình trạng này.
Bạn sẽ quyết định rằng nếu tăng ca không phải là đáp án, vậy thử tăng nguồn lực thì vấn
đề có được giải quyết khơng? Bạn thuyết phục cấp trên huy động thêm một người mới
đến hỗ trợ. Thật ngạc nhiên rằng lượng cơng việc hồn thành do hai người khơng khác gì


so với một người. Đáng quan tâm hơn cả là nhiều lỗi có thể xảy ra hơn nữa. Chuyện gì đã
xảy ra ở đây?
Bạn họp lại với các thành viên ban đầu của nhóm dự án, có ý kiến cho rằng: “Chuyện đó
rất đơn giản. Người mà anh mới đưa đến hỗ trợ tơi khơng biết gì về việc tơi đang làm.
Tôi phải hướng dẫn anh ta gần như cả ngày thứ hai. Sau đó, tối thấy anh ta làm sai rất
nhiều lỗi và tôi phải là người giúp sửa hết những lỗi đó và tơi vẫn phải làm tăng ca để đào
tạo và để sửa lỗi cho người đó. Tôi không cần bất kỳ sự giúp đỡ nào khác, điều đó sẽ tốt
hơn!”
Đây là một ví dụ của “Fixes that fail”. Bắt một nhân viên phải làm việc tăng ca sẽ gây ra
sự mệt mỏi kéo dài cho người đó. Do vậy mà anh ta sẽ mắc nhiều lỗi hơn trong cơng
việc. Những lỗi đó cần phải được sửa chữa, như vậy nhân viên này lại phải làm nhiều
hơn, làm cho anh ta mệt mỏi hơn và gây ra nhiều lỗi hơn. Cứ như vậy một vòng lẩn quẩn
sẽ tạo thành mà không giải quyết được vấn đề. Và rồi nếu có một người mới được điều
đến để hỗ trợ dự án. Nhân viên cũ lại phải chỉ dẫn cho người mới, không chỉ làm giảm
năng suất làm việc mà còn buộc nhân viên cũ phải làm việc nhiều hơn, lỗi lại tiếp tục xảy
ra và vòng tròn trên được lặp lại.
Một ví dụ khác, có một cơng ty tên là Acme Electronics sản xuất ra các linh kiện rồi sau
đó chuyển các linh kiện đó cho một cơng ty khác lắp ráp lại với nhau thành sản phẩm.

Thỉnh thoảng, khách hàng báo về có một số vấn đề liên quan đến một trong những linh
kiện đó. Và nếu như cơng ty có khả năng giải quyết vấn đề này, họ sẽ gửi kỹ sư thiết kế
đến. Do công việc chủ yếu của những kỹ sư này là thiết kế ra những linh kiện mới nên
công việc thiết kế của họ bị dừng lại. Họ lập kế hoạch để giải quyết vấn đề cho khách
hàng rồi mới trở lại cơng việc.
Đáng tiếc là thời hạn để hồn thành cơng việc thiết kế linh kiện không thay đổi và họ bị
trễ tiến độ. Giải pháp duy nhất hiện có là làm việc cật lực để cố gắng hồn thành cơng
việc được giao. Kết quả cũng giống như trường hợp trên, chất lượng công việc bị giảm
sút, không đạt yêu cầu. Linh kiện mới được tung ra thị trường, lại có vấn đề với những
linh kiện này ở khách hàng. Công việc thiết kế lại bị trì trệ. Họ làm nhiều hơn để hồn
thành cơng việc và lại tạo ra sản phẩm khơng tốt, cứ như vậy vịng trịn ấy sẽ lặp lại tuần
hồn.
Từ thường được dùng để mơ tả trường hợp này là “fire-fighting” (chữa cháy). Theo từ
điển, “fire-fighting” được giải nghĩa là “the practice of dealing with problems as they
arise rather than planning strategically to avoid them, in business”. Các kỹ sư thường
làm việc theo kiểu chữa cháy như vậy mà khơng có một kế hoạch gì để ngăn chặn những
hậu quả (fires) trong tương lai.
Levels of understanding –Các cấp độ nhìn nhận
Chúng ta có thể nhìn nhận các vấn đề xung quanh bằng nhiều cấp độ khác nhau. Những người
cótư duy hệ thống thường quan tâm đến bốn trong số những cấp độ được thể hiện trong Hình 141. Ở cấp độ “event” (sự kiện), tức là giải quyết những việc căn bản diễn ra hằng ngày. Khi rủi ro
xảy ra, chúng ta vẫn làm việc, giải lao, hồn thành cơng việc hay viết bản ghi nhớ. Trong trường
hợp của kĩ sư, họ sửa chữa lỗi linh kiện, họ lập tức giải quyết vấn đề. Cấp độ này gọi là
“reactive” (phản ứng lại), bởi vì chúng ta ln phản ứng liền với các vấn đề hơn là cố kiểm soát
chúng xảy ra.


Cấp độ tiếp theo là “pattern of event” (mơ hình sự kiện). Trong trường hợp của các kỹ sư,
chúng ta bắt đầu nhận thấy vấn đề xảy ra theo một mơ hình nào đó. Cần chú ý rằng mơ
hình chỉ có thể được áp dụng trong một thời gian. Khi mơ hình phát triển, chúng ta có lẽ
phải thích ứng trong tiếp nhận. Chúng ta sẽ đào tạo các kỹ sư trong việc đối mặt với vấn

đề, do đó họ có thể phân biệt và giải quyết vấn đề xảy ra nhanh chóng. Điều này vẫn
khơng ngăn được vấn đề.

Hình 14-1. Các cấp độ nhìn nhận
Với cấp độ “systemic structure” (cấu trúc hệ thống), chúng ta bắt đầu hỏi nguyên nhân
xảy ra các mơ hình của vấn đề. Cách này gọi là “creative” (sáng tạo), bởi vì chúng ta có
thể ngăn chặn vấn đề nếu chúng ta có thể hiểu các mơ hình. Cách này định hướng cho
tương lai. Bằng việc phòng ngừa vấn đề, chúng ta tạo ra kết quả khác biệt hơn thông
thường. Với cách này, chúng ta quyết định lập nhóm giải quyết vấn đề, tách biệt với các
kỹ sư thiết kế. Điều này giải phóng kỹ sư khỏi việc đối mặt vấn đề, do đó họ có thể tập
trung cho việc thiết kế được tốt, về lâu dài sẽ làm giảm số lượng các vấn đề phát sinh.
Bậc kế tiếp là “shared vision”(tầm nhìn chung). Cách này tạo ra các cấu trúc hình thành
mơ hình. Mơ hình này gọi là “generative” (kiến tạo) và nó cũng định hướng cho tương
lai. Với cách này, chúng ta sẽ hỏi các câu hỏi, như “Vai trò thực sự của các kỹ sư thiết kế
là gì? Vấn đề cần được xử lý như thế nào? Sự cân bằng giữa nguồn lực dành cho việc
thiết kế và giải quyết vấn đề như thế nào?”
The tragedy of the commons– Khuyết điểm của những vấn đề chung


Hệ thống phức hợp có rất nhiều điểm manh. Tuy nhiên hệ thống phức hợp cũng có những
vấn đề của riêng nó.
Một trong những vấn đề đó là những nhược điểm của những vấn đề chung. Trong thời
trung cổ Anh, có những nơi cơng cộng hay khu vực đồng cỏ chung. Ý tưởng này được
đưa tới Mỹ bởi các nhà thám hiểm. Tất cả các thành viên trong một cộng đồng được chăn
thả gia súc trong khu vực chung.
Một chủ sở hữu vật nuôi sớm suy nghĩ rằng, “Càng nhiều bị càng tốt, khi được chăn thả
miễn phí, tơi sẽ gia tăng đàn bị nhanh nhất có thể”. Điều này tạo ra một vòng phản hồi
gia tăng.
Điều này tạo ra tình huống là mỗi cá nhân quá mềm yếu để có thể tránh được vấn đề đó.
Mọi người đều cùng suy nghĩ như vậy và có cách thực hiện giống nhau, vì vậy đàn gia

súc ngày càng tăng nhanh. Chẳng mấy chốc số lượng gia súc tăng nhanh hơn lượng cỏ
mọc lên. Gia súc thiếu thức ăn và phải gặm sâu tận rễ, khiến cho cỏ không thể tiếp tục
sinh trưởng được nữa, cuối cùng chúng khơng cịn gì ăn. Những con bị ngày càng đói và
tồn bộ dân làng phải đối mặt với thảm họa.
Chúng ta nhận thấy rằng việc đơn lẻ một người dân tự nguyện giảm quy mơ đàn gia súc
của mình là bất lợi cho chính bản thân họ. Điều đó mang lại nhiều cỏ hơn, đồng nghĩa với
việc những người khác sẽ có động lực nhiều hơn để phát triển đàn gia súc của họ . Như
vậy, hành động vì người khác này sẽ khơng ngăn chặn được các thảm họa và người có
nghĩa cử cao đẹp ấy lại nghèo đi trong khi người láng giềng của anh ta ngày càng giàu có.
Điều đáng nói trong trường hợp này là nếu mỗi người tự đưa ra quyết định mà cho đó là
tốt nhất theo quan điểm của riêng mình thì mọi người vẫn sẽ gặp kết cục không tốt.
Peter Block đã chỉ ra rằng lợi ích cá nhân thật sự có nghĩa nếu mỗi người dân sẽ làm
những điều tốt nhất cho cả làng – chứ không phải là cho cá nhân (Block, 1987). Khi làm
được như vậy, dân làng sẽ có được lợi về lâu dài. Tất nhiên, con người rất khó làm được
việc này. Con người có xu hướng ích kỷ, khơng bao giờ nhận ra rằng hành động của họ
cuối cùng có thể phá hủy mọi thứ. Chúng ta thấy điều khá đúng với vấn đề mơi trường
ngày nay.
Nhưng điều này có liên quan gì đến quản lí dự án?
Một trong những khía cạnh quan trọng của quản lí dự án là người quản lí ln ln cạnh
tranh các nguồn tài ngun khan hiếm để hồn thành cơng việc. Nếu chúng ta nhận ra
rằng lợi ích thực sự của chúng ta nằm ở hợp tác hơn là cạnh trạnh, các đội dự án của
chúng ta sẽ hoạt động tốt hơn. Thay vào đó, chúng ta đơi khi sa lầy vào việc thắng - thua
trong tranh chấp nguồn tài nguyên. Mỗi nhà quản lí dự án muốn tối ưu hóa “nhóm” của
họ mà khơng gây ảnh hưởng tới các nhóm khác. Từ quan điểm hệ thống, bất cứ chuyện gì
mà chúng ta làm để giúp tổ chức trong một phạm vi có xu hướng sẽ giúp đỡ cho toàn bộ
hệ thống và ngược lại, chúng ta làm tổn hại bất cứ thứ gì thì cũng tổn hại đến tất cả mọi
người.
Như đã đề cập trong chương 12, đôi khi chúng ta bị vướng vào trị chơi khơng có điểm
dừng bởi vì chúng ta tạo ra một sự tương tác lặp đi lặp lại. Lúc này xuất hiện vòng phản
hồi phủ định, hệ thống có xu hướng tự cân bằng và chống lại sự thay đổi. Ở đoạn cuối

chương 13, hệ thống có xu hướng quay lại điểm cân bằng nếu bị xáo trộn, do đó, nếu bạn
cố gắng làm giảm xung đột, nó trở lại điểm cân bằng sớm hơn một chút. Trừ khi bạn làm


gián đoạn các mơ hình bằng cách làm nhiễu các vịng phản hồi phủ định thì sự tương tác
sẽ tiếp tục, không suy giảm, mãi mãi (hoặc đến khi cả hai bên đều trở nên mệt mỏi về
nó).
Limits to growth– Giới hạn của sự phát triển
Trong cuốn The Fifth Discipline (1990), Peter Block giới thiệu một số hệ thống mô hình
kiểu mẫu xuất hiện nhiều trong tổ chức, nhóm và cả trong cá nhân. Một trong số đó là
limits-to-growth. Mơ hình kiểu mẫu này gần như lúc nào cũng được tìm thấy trong
trường hợp “phát triển vượt mức giới hạn” (Senge, 1990, trang 96). Các tổ chức phát
triển trong một khoảng thời gian nhất định, sau đó sẽ dừng lại. Điều này cũng tương tự
với các nhóm và cá nhân. Các cố gắng phát triển tổ chức thông qua cải tổ có thể đạt được
những thành cơng nhất định, sau đó sẽ tới ngưỡng giới hạn.
Điều này có thể áp dụng cho nhóm dự án. Trong chương 27 sẽ đề cập thêm về q trình
phát triển trong các nhóm dự án. Tuy nhiên, có thể thấy rằng sự phát triển chỉ có thể phát
triển đến một mức độ giới hạn nào đó. Chúng ta cố gắng giải quyết vấn đề deadline(hạn
chót) bằng cách làm việc nhiều giờ hơn, nhưng như tôi đã cho thấy ở đầu chương này,
stress và mệt mỏi bắt đầu làm chậm tiến độ công việc và giảm chất lượng, do đó làm
giảm lợi ích của làm thêm giờ.

Hình 14-2. Cấu trúc hệ thống Limits-to-growth
Shifting the burden – Sự thối thác gánh nặng
Mơ hình kiểu mẫu này phổ biến trong chính phủ và các tổ chức hợp tác. Có một vấn đề
làm phát sinh những vấn đề khác cần phải chú ý, nhưng những vấn đề cơ bản này lại quá
khó để tập trung vào giải quyết do chúng không thực sự rõ ràng hoặc là quá tốn kém để
xử lý. Nên mọi người thoái thác gánh nặng theo cách này hay cách khác. Nó là sự “giải
quyết” có vẻ hiệu quả. Tuy nhiên, việc thối thác này chỉ giải quyết những vấn để “ nổi”,
còn vấn đề “ngầm” thì vẫn tồn tại.

Có thể lấy ví dụ như sau,với một cá nhân, khi người đó làm quá sức, có thể vì phịng ban
thiếu nhân lực. Người đó cố gắng đảm đương cơng việc, gia đình, học vấn, và lúc nào


cũng phải chạy đua với công việc. Khi khối lượng công việc vượt quá năng lực cá nhân,
hướng giải quyết duy nhất chính là tạo ra “ngưỡng” cơng việc cho mình bằng cách hoặc
hịa hỗn cơng việc hoặc chọn lựa công việc nào cần ưu tiên làm trước. Khi người đó
muốn ơm đồm nhiều việc để hồn thành nhanh hơn và cố gắng để giải tỏa stress bằng
rượu để quên đi lo âu, nhưng cả hai đều không phải là giải pháp thiết thực. Vấn đề cứ tiếp
diễn, người đó càng ngày càng uống nhiều rượu hơn nữa.
Vấn đề này cịn có thể xảy ra trong q trình làm việc nhóm. Thay vì giải quyết trực tiếp
từng người, người quản lý cố gắng phát triển kĩ năng giao tiếp của nhân viên. Có lẽ bộ
phận Nhân sự cần can thiệp. Họ nói chuyện, hướng dẫn, khuyên giải và có thể khuyến
khích người đó. Tuy nhiên, nếu anh ta vẫn tiếp tục giữ nguyên thái độ cư xử, tốt nhất nên
loại anh ta khỏi nhóm (hay sa thải khỏi cơng ty), nhưng khơng ai muốn nhận lấy “hình
phạt nặng” như vậy.

Hình 14-3. Cấu trúc hệ thống Shifting the burden
Những ví dụ nêu trên cho thấy tư duy hệ thống đem lại sự hữu ích trong cơng tác quản lý
dự án. Để hiểu chi tiết hơn về những giải pháp trong hệ thống tổ chức bạn có thể tìm hiểu
thêm trong một số tài liệu tham khảo khác như The Fifth Discipline Fieldbook (Senge và
cộng sự, 1994), hay The Systems Thinker Newsletter.