How to apply systems thinking in managing project

Bảng phân cơng cơng việc trong nhóm:
Thành viên
Cao Việt Cường
(nhóm trưởng)

Trần Vân Anh

Trần Hồng Anh Khoa

Hà Nhật Tảo

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.
2. Dịch và thuyết trình phần “fixes that fail”.
3. Thiết kế power point trắng 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.
2. Đưa ra ý tưởng, thiết kế và chỉnh sửa hiệu ứng
cho power point của toàn bộ bài thuyết trình.
3. Tổng hợp file word thành bài báo cáo hoàn
chỉnh.
1. Đọc và nắm ý toàn bộ bài thuyết trình của nhóm.
2. Dịch và thuyết trình 2 phần “levels of
understanding” và “the tragedy of commons”.
3. Thiết kế power point trắng 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.
2. Dịch và thuyết trình 2 phần “limits to growth” và
“shifting the burden”.
3. Thiết kế power point trắng cho phần thuyết trình

cá nhân.

Mức độ hồn
thành cơng việc
100%


HOW TO APPLY SYSTEMS THINKING IN MANAGING PROJECT
( Làm thế nào để áp dụng tư tưởng hệ thống vào 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.
1. FIXES THAT FAIL
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 đó tụt 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ờ một 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 sếp 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 hắn gần như cả ngày thứ hai. Sau đó, tối thấy anh ấy 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 hắn, để sửa lỗi cho
hắn. 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 nhân viên đó. Do vậy mà anh ấy 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 lại phải làm cực hơn, làm cho anh ấy
mệt mỏi hơn và rồi lại gây ra nhiều lỗi hơn. Cứ như vậy nó sẽ tạo thành một vịng lẩn quẩn
khơng giải quyết được vấn đề. Và rồi nếu có 1 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 đến, 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 mệt nhọc 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 1 trong những linh kiện đó. Và nếu như cơng
ty có khả năng giải quyết vấn đề đó, 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.
Không may 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ả vẫn giống như trường hợp trên, chất lượng công việc của họ 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à rồi 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ó 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) cho tương lai.