Báo cáo Quản lí dự án cho kĩ sư - Cách áp dụng tư duy hệ thống trong quản lý dự án
BẢNG PHÂN CÔNG CÔNG VIỆC TRONG NHÓM
Hoàn thành
công việc
Thành viên
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.
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.
100%
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 toàn
bộ bài thuyết trình.
3. Biên tập file word thành bài báo cáo hoàn
Trần Vân Anh
100%
chỉnh.
4. Thuyết trình 2 phần “limits to growth” và
“shifting the burden”
1. Đọc và nắm ý toàn bộ bài thuyết trình của
nhóm.
Trần Hoàng
Anh Khoa
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 cho phần thuyết trình cá
nhân.
1. Đọc và nắm 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%
100%
Hà Nhật Tảo
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 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). 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 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
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 trong 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), bở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 đề.
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à
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
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ề 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ể 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ự thoá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 thoá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 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ơ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 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.
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.
8 trang
28/04/2022
6980
Bạn đang xem tài liệu "Báo cáo Quản lí dự án cho kĩ sư - Cách áp dụng tư duy hệ thống trong quản lý dự án", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bao_cao_quan_li_du_an_cho_ki_su_cach_ap_dung_tu_duy_he_thong.docx
