Peopleware – Chương 30: Khiêu vũ với rủi ro

Tiền đề về Peopleware — các vấn đề chính của chúng ta có nhiều khả năng mang tính xã hội học hơn là về bản chất công nghệ — không áp dụng mạnh mẽ hơn trong lĩnh vực rủi ro. Cơ chế của quản lý rủi ro được hiểu rộng rãi; khi nó không được thực hiện, lý do có thể là do chính trị và văn hóa của tổ chức.

Không chạy trốn khỏi rủi ro

Trước hết, cần phải nói rằng rủi ro dự án là một điều tốt, nó có thể là một chỉ số có giá trị. Các dự án có giá trị thực nhưng ít hoặc không có rủi ro liệu có tồn tại hay không. Những thứ quan trọng ngày nay chứa đầy rủi ro.

Một rủi ro mà chúng ta hầu như không bao giờ quản lý

Rủi ro mà chúng ta có xu hướng không quản lý là nguy cơ thất bại của chính chúng ta. Nếu bạn và nhóm đáng tin cậy của bạn phải tương tác với một nhà thầu ở cách xa hàng ngàn dặm và mười múi giờ trong một thành phố mà bạn chưa bao giờ nghe nói đến, tất nhiên bạn đặt sự không hoạt động có thể có của họ vào đầu danh sách rủi ro của mình. Đó là hiển nhiên. Nhưng rủi ro bạn và nhóm của bạn không đạt được mục tiêu được giao thì sao? Tất nhiên, bạn lo lắng về điều đó; bạn có thể thức dậy vào ban đêm trong tình trạng đổ mồ hôi. Lý do nó có thể không nằm trong danh sách rủi ro của bạn là vì nó giống như sự phòng thủ khi mang theo rủi ro về sự không hoạt động của chính bạn. Sau tất cả, bạn đã được giao phó để đảm bảo hiệu suất; đó là trách nhiệm được giao của bạn.

Để hiểu lý do tại sao không quản lý ngay cả một rủi ro này là nguy hiểm, bạn cần xem xét lý do thực sự của việc quản lý rủi ro: Không phải để làm cho rủi ro biến mất, mà là để giảm thiểu rủi ro một cách hợp lý nếu chúng xảy ra. Và việc giảm thiểu cũng có thể phải được lên kế hoạch và dự phòng trước thời hạn.

Hệ thống xử lý hành lý tại Sân bay Quốc tế Denver khét tiếng là một trường hợp điển hình. Quyền hạn đã được quyết định rằng việc cung cấp hệ thống đúng hạn là rất quan trọng nên việc không đạt hiệu quả (trễ hạn) không thể được coi là một rủi ro. Nó không phải là một rủi ro bởi vì nó đơn giản là sẽ không được phép xảy ra.

Nếu họ đã quản lý được rủi ro, họ sẽ có nghĩa vụ lập kế hoạch dự phòng thủ công hoặc bán tự động để di chuyển các túi hành lý trong trường hợp hệ thống mới chưa sẵn sàng. Họ đã không. Vì vậy, khi hệ thống đến muộn, họ phải hoãn việc mở cửa sân bay. Chi phí vốn để thực hiện một sân bay phi chức năng thứ hai trong hơn một năm cuối cùng đã lên đến hàng tỷ đô la.

Vào thời điểm rủi ro hình thành và hệ thống không khả dụng vào ngày khai trương, thì đã quá muộn để bắt đầu lập kế hoạch giảm thiểu. Mặt khác, nếu công tác giảm thiểu đã sẵn sàng, sân bay sẽ mở cửa với những chiếc xe tải tạm, cũ kỹ và những chiếc xe tải nhỏ đang di chuyển hành lý, và sự chậm trễ của hệ thống phần mềm sẽ cũng chỉ là 1 sự thất vọng nhỏ. Bạn sẽ chưa bao giờ nghe nói về Hệ thống Xử lý Hành lý của DIA; không ai ngoại trừ những người trong dự án đó.

Hoàn toàn hợp lý khi không quản lý một rủi ro mà xác suất xảy ra là cực kỳ thấp. Không hợp lý khi để lại rủi ro không được quản lý mà hậu quả gây ra là “quá khủng khiếp để nghĩ đến”.

Tại sao các rủi ro không hoạt động thường không được quản lý

Tư duy có thể làm thường thay thế quản lý rủi ro khi kết quả đã được xác định là một thách thức. Mọi người vươn tới một thử thách; họ hoan nghênh nó. Họ được tạo ra để chứng tỏ mình chống lại nghịch cảnh. Điều cuối cùng họ cần là dành bất kỳ thời gian nào để lập kế hoạch và dự phòng cho thất bại của chính họ. Thời gian là điều cốt yếu, đặc biệt khi thách thức là hoàn thành một việc gì đó theo một lịch trình chặt chẽ. Lịch trình càng quan trọng, càng ít thời gian cho việc lập kế hoạch giảm thiểu và càng ít người có xu hướng thực hiện nó.

Điều này không phải là tất cả xấu. Nếu người quản lý và nhóm của họ không thực hiện quản lý rủi ro, thì người khác phải làm. Người quản lý dự án tốt nhất trong tình huống này là người có thể nói, “Hãy nhìn xem, chúng tôi sẵn sàng chấp nhận thử thách này, ngày giao hàng đáng sợ này và chúng tôi sẽ cố gắng hết sức để đáp ứng nó. Sẽ không có thời gian để quản lý rủi ro mà chúng tôi sẽ không thực hiện được mặc dù đã cố gắng hết sức, nhưng ai đó quản lý rủi ro đó tốt hơn. Trừ khi thấy rằng các kế hoạch cụ thể đang được lập cho trường hợp giao hàng muộn, chúng tôi sẽ không thể coi đây là một thách thức; nó giống như một trò lừa bịp ngu ngốc, tuyệt vọng hơn.“

Các nhà quản lý và giám đốc điều hành cấp trung thường có kỹ năng xác định một kết quả mong muốn như một thách thức. Họ đặt ra thách thức như một thứ gì đó sẽ là bằng chứng của sự xuất sắc. Nhưng trong nhiều trường hợp, những gì họ đang cố gắng hoàn thành không phải là đưa nhóm trở nên xuất sắc, mà là để các thành viên trong nhóm hoàn thành dự án với giá rẻ. Ngược lại, lợi ích mà dự án mang lại càng cận biên thì điều quan trọng là phải phân phối nó với giá rẻ. Không có gì ngạc nhiên khi việc giao hàng giá rẻ để che giấu lợi ích tệ hại không phải là một động lực tuyệt vời, vì vậy các giám đốc điều hành ở vị trí này có thể tự nói rằng: “Công việc này quan trọng đến mức chúng ta phải hoàn thành nó trước tháng 1”. Ý của họ thực sự là, “Công việc này không quan trọng đến mức tôi không muốn tài trợ cho nó quá tháng Giêng.”

Đây là một thử thách sai lầm, nhưng nhóm và trưởng nhóm có thể không hiểu nó như vậy. Họ có thể chấp nhận ngày giao hàng và cố gắng hết sức để đáp ứng ngày đó, che giấu mọi hành động giả vờ quản lý rủi ro trên đường đi.

Các dự án thách thức sai luôn có cùng đặc điểm: lợi ích cận biên (vì chúng không chịu rủi ro công nghệ thực sự vì tổ chức không thích rủi ro), nhưng rủi ro lịch trình lớn thường không được quản lý. Chào mừng bạn đến với điều tồi tệ nhất của cả hai thế giới.

— Nguồn: Tom DeMarco, Timothy Lister (2014) Nhân liệu (Peopleware): Các dự án và đội ngũ hiệu quả, xuất bản lần 3.