Báo cáo Quản lý dự án cho kỹ sư - Đề tài: How to apply systems thinking in managing projects

BẢNG PHÂN CÔNG CÔNG VIỆC TRONG NHÓM

Hoàn thành

Thành viên

Công việc

công việc

1. Đọc toà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 phần “Fixes that fail”.

Cao Việt Cường

(Nhóm trưởng)

3. Chuẩn bị nội dung thuyết trình “Fixes that fail”.

4. Chỉnh sửa nội dung cho bản word.

100%

5. Yêu cầu nhóm phải nắm vững phần “Fixes that

fail” để có thể thuyết trình đầu tiên.

1. Tìm hiểu 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 toà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.

100%

4. Thuyết trình 2 phần“Limits to growth” và

“Shifting the burden”.

1. Tìm hiểu toàn bộ bài thuyết trình của nhóm.

Trần Hoàng

2. Dịch và thuyết trình 2 phần “Levels of

understanding” và “The tragedy of commons”.

3. Chuẩn bị nội dung phần thuyết trình cá nhân.

1. Tìm hiểu toàn bộ bài thuyết trình của nhóm.

2. Dịch 2 phần “Limits to growth” và “Shifting the

burden”.

100%

Anh Khoa

Hà Nhật Tảo

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

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ư duy 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ư

duy 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 hoà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). Tuy nhiên bạn đã vô tình làm mất đi năng suất công

Trang 1

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

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 hoà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 để hoà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 hoà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 để hoàn

Trang 2

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

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

hoà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 ở Hình 14-1. Ở 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, hoà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), vì chúng ta luôn 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 đề.

Trang 3

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

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?”

Trang 4

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

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 mạnh. 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à

toà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í luôn luôn

cạnh tranh các nguồn tài nguyên khan hiếm để hoà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

Trang 5

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

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ủ địnhthì 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ề quá

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ể

đế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ờ.

Trang 6

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

Hình 14-2. Cấu trúc hệ thống Limits-to-growth

Shifting the burden – Xoay sở với những 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 sinhnhữ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 xoay sở với những gánh nặng bằng nhiều cách khác nhau. Nó là

sự “giải quyết” có vẻ hiệu quả. Tuy nhiên, việc xoay sở 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 hoã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 để hoàn thành nhanh hơnvà cố gắng giải tỏa stress bằng rượu

hay bỏ qua mọi thứ, 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 quá 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.

Trang 7

Quản lý Dự án cho Kỹ sư

How to apply systems thinking in managing projects

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 FifthDiscipline Fieldbook

(Senge và cộng sự, 1994), hay The Systems Thinker Newsletter.

Trang 8

Báo cáo Quản lý dự án cho kỹ sư - Đề tài: How to apply systems thinking in managing projects - Cao Việt Cường