Quản lý dự Án cho kỹ sư cách Áp dụng tư duy hệ thống trong quản lý dự Án how to apply systems thinking in managing projects

Quản lý dự Án cho kỹ sư cách Áp dụng tư duy hệ thống trong quản lý dự Án how to apply systems thinking in managing projects

CÁCH ÁP DỤNG TƯ DUY HỆ THỐNG

TRONG QUẢN LÝ DỰ ÁN

How to apply systems thinking in managing projects

Fixes that fail – Sửa lỗi sai 1

Levels of understanding –Các cấp độ nhìn nhận 3

The tragedy of the commons– Khuyết điểm của những vấn đề chung 5

Limits to growth– Giới hạn của sự phát triển 6

Shifting the burden – Xoay sở với những gánh nặng 7

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ốiquan 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ụngnhữ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êucầu nhân viên phải tăng ca thêm vài giờ làm mỗi ngày để chokị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ệchoàn thành chắc chắn sẽ tốt hơn trước Tuy nhiên, sau một

chắn là cần được sửa lại) Hơn nữa, bạn sẽ thấy rằng năngsuấ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ếubạn để ý sẽ thấy lượng công việc mà nhân viên đó dù có dốchế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ấtcô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 dohai người không khác gì so với một người Đáng quan tâmhơ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à anhmớ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úpsử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àylại phải làm nhiều hơn, làm cho anh ta mệt mỏi hơn và gây ranhiề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ườimớ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ạitiế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ừnglại Họ lập kế hoạch để giải quyết vấn đề cho khách hàng rồimớ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ế linhkiện không thay đổi và họ bị trễ tiến độ Giải pháp duy nhấthiệ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ấtlượng công việc bị giảm sút, không đạt yêu cầu Linh kiệnmới được tung ra thị trường, lại có vấn đề với những linhkiệ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ảnphẩm không tốt, cứ như vậy vòng tròn ấy sẽ lặp lại tuầnhoàn

Từ thường được dùng để mô tả trường hợp này là fighting” (chữa cháy) Theo từ điển, “fire-fighting” được giải

“fire-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ằngnhiều cấp độ khác nhau Những người cótư duy hệ thốngthườ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 hayviết bản ghi nhớ Trong trường hợp của kĩ sư, họ sửa chữa lỗilinh 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ấyvấ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 nhanhchó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òngngừ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ảiquyết vấn đề, tách biệt với các kỹ sư thiết kế Điều này giảiphóng kỹ sư khỏi việc đối mặt vấn đề, do đó họ có thể tậptrung 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

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úcngày càng tăng nhanh Chẳng mấy chốc số lượng gia súctă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 sinhtrưởng được nữa, cuối cùng chúng không còn gì ăn Nhữngcon bò ngày càng đói và toàn bộ dân làng phải đối mặt vớithả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 chochính bản thân họ Điều đó mang lại nhiều cỏ hơn, đồngnghĩ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ườiláng giềng của anh ta ngày càng giàu có Điều đáng nói trongtrườ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ọingườ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ĩanế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 đượcnhư vậy, dân làng sẽ có được lợi về lâu dài Tất nhiên, conngườ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ênkhan hiếm để hoàn thành công việc Nếu chúng ta nhận rarằng lợi ích thực sự của chúng ta nằm ở hợp tác hơn là cạnhtrạnh, các đội dự án của chúng ta sẽ hoạt động tốt hơn Thayvào đó, chúng ta đôi khi sa lầy vào việc thắng - thua trongtranh 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àmtổ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ướngvà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 quaylại điểm cân bằng nếu bị xáo trộn, do đó, nếu bạn cố gắnglàm giảm xung đột, nó trở lại điểm cân bằng sớm hơn mộtchút Trừ khi bạn làm gián đoạn các mô hình bằng cách làmnhiễ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ớithiệu một số hệ thống mô hình kiểu mẫu xuất hiện nhiềutrong 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 đượcnhữ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ể đếnmộ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ấtlượ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 – 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 những vấn để “nổi”, còn vấn đề “ngầm” thì vẫn

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àmtrước Khi người đó muốn ôm đồm nhiều việc để hoàn thànhnhanh hơnvà cố gắng giải tỏa stress bằng rượu hay bỏ quamọ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ềurượu hơn nữa

Vấn đề này còn có thể xảy ra trong quá trình làm việcnhó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ếuanh ta vẫn tiếp tục giữ nguyên thái độ cư xử, tốt nhất nên loạianh 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 FifthDiscipline Fieldbook (Senge và cộng sự, 1994), hay The Systems Thinker Newsletter.