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 Hoàn thành công việc Cao Việt Cường (Nhóm trưởng) 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 và[.]

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

Cao Việt Cường

(Nhóm trưởng)

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 và thuyết trình phần “Fixes that fail”.

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

100%

Trần Vân Anh

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 chỉnh

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

“shifting the burden”

100%

Trần Hoàng

Anh Khoa

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 Chuẩn bị nội dung cho phần thuyết trình cá nhân

100%

Hà Nhật Tảo 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

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.