Một người quản lí dự án hỏi tôi: “Dự án phần mềm của tôi không chạy tốt, tổ của tôi mệt mỏi và nản chí. Tôi phải làm gì?”

Đáp: Không dự án phần mềm nào là hoàn hảo. Mọi dự án đều có vấn đề. Là người quản lí dự án, bạn phải động viên tổ của mình ngay cả khi dự án KHÔNG tiến triển tốt. Thứ nhất, bạn phải báo cho tổ của bạn biết rằng hiện trạng là KHÔNG tốt. Không có gì tồi hơn khi dự án không thực hiện tốt nhưng người quản lí vẫn khăng khăng rằng nó là tốt. Bạn phải nói SỰ THỰC nhưng có thể thêm chút khôi hài cho nó để cho tổ có thể cười chút ít. Chẳng hạn: “Tôi biết rằng dự án là tệ cho nên câu hỏi là ai muốn mua một sản phẩm kém? Chúng ta có thể bán nó bằng nửa giá được không?” Thứ hai, bạn có thể yêu cầu tổ của bạn hình dung về kết cục của dự án bằng việc cho phép họ nghĩ tích cực về kết quả tốt hơn. Bạn có thể yêu cầu từng người nghĩ về một kịch bản “Cái gì xảy ra nếu yêu cầu không thay đổi thì …” “Cái gì xảy ra nếu chúng ta có đủ thời gian để làm thiết kế tốt hơn …” rồi với tổ của bạn cùng nhau hình dung kết cục của dự án. Cái gì sẽ có vẻ giống vậy? Làm sao cảm thấy thành công? Bạn đã hoàn thành cái gì? Làm sao bạn đã đi tới đó? Làm sao bạn biết bạn ở đó? Khi nào tổ của bạn cảm thấy mệt mỏi hay nản chí, thường khó thấy kết thúc hạnh phúc. Là người quản lí, bạn có thể giúp họ bằng việc cho hi vọng rằng kết quả sẽ tốt hơn.

Nhiều vấn đề thường tới từ mệt mỏi vì người làm phần mềm thường làm việc thời gian dài. Trong trường hợp đó, bạn có thể cho tổ của mình nghỉ giải lao bằng việc có một ngày hội thảo xây dựng tổ thay vì làm việc dự án. Thỉnh thoảng chuyến đi dã ngoại một ngày ngoài thành phố có thể cho tổ của bạn “tư duy tươi tắn” nhìn vào dự án cũ. Tốt hơn cả nếu bạn có thể mời một diễn giả bên ngoài tới và nói với tổ về chủ đề khác và để cho tổ nghỉ ngơi bộ óc của họ một chút. Với dự án lớn bao giờ cũng có thay đổi. Thỉnh thoảng mọi người chuyển sang dự án khác và thỉnh thoảng yêu cầu thay đổi. Là người quản lí dự án, bạn phải kiểm điểm tài liệu kế hoạch dự án, làm các điều chỉnh bằng việc xem lại những mong đợi, điều chỉnh mục đích và phân công lại người cho các vai trò và trách nhiệm mới. Đôi khi chút ít thay đổi có thể nạp lại năng lượng cho tổ, loại bỏ một số vấn đề và thất vọng.

Ngay cả khi dự án thất bại hay bị huỷ bỏ bạn KHÔNG nên cay đắng. Dễ dàng cho người quản lí dự án đổ lỗi tại cái gì đó hay ai đó nhưng làm điều đó bạn đang tạo ra “môi trường xấu” và có thể đánh mất sự kính trọng của tổ. Ai muốn làm việc với người quản lí đổ lỗi cho người của họ? Bạn phải chấp nhận trách nhiệm và rồi kết nối lại với tổ bằng việc chỉ ra cho họ rằng bạn chăm nom. Bạn phải dùng mọi thất bại như “bài học rút ra”. Dễ dàng làm cho họ tham gia lại nếu bạn chỉ cho họ rằng có cơ hội khác, dự án khác và bạn muốn họ làm việc nữa cho bạn. Bạn có thể nói rằng “Là một tổ, tất cả chúng ta đều học được từ bài học này” và chúng ta sẽ KHÔNG phạm sai lầm này lần nữa. Khi tổ của bạn bị nản chí, ĐỪNG né tránh họ. Thay vì thế, cố gắng chủ động và xem cái gì có thể làm lại và KHÔNG sợ hỏi các ý tưởng mới từ tổ của bạn về cách làm nó tốt hơn lần sau. Bạn sẽ ngạc nhiên bao nhiêu ý tưởng họ có thể đem tới để làm khác biệt lớn cho lần sau.

—-English version—-

How to help a failing project.

A project manager asked me: “My software project is not going well, my team is tired and discouraged. What should I do?”

Answer: No software project is perfect. Every project has problems. As project manager, you must motivate your team even when the project is NOT progressing well. First, you must acknowledge to your team that the current situation is NOT good. There is nothing worse than when the project is not doing well but manager still insists that it is fine. You must speak the TRUTH but may add humor to it so the team can laugh a little. For example: “I know that the project is bad so the question is who want to buy a bad product? Can we sell it at half price?”. Second, you may ask your team to visualize about the end of the project by allow them to think positive on a better outcomes. You can ask each member to think of a scenario “What if the requirement does not change then …” “What if we have enough time to do better design …” then with your team together visualizing the end of the project. What will that look like? How does the success feel? What did you accomplish? How did you get there? How do you know you are there? When your team feels tired or discouraged, it often difficult to see the happy ending. As the manager, you can help them by give hope that the result will be better.

Many problems often come from fatigue as software people usually work long hours. In that case, you may give your team a break by having one day teambuilding workshop instead of project work. Sometime a one day field trip outside of town can give your team some “fresh thinking” into the old project. It is better if you can invite an outside speaker to come in and talk with the team on another subject and let the team rests their brain a little. For large project there are always changes. Sometime people move to another project and sometime requirements change. As project manager, you must review the project plan document, make adjustments by revisiting the expectations, adjusting goals and re-assign people to new roles and responsibilities. Sometime a little change may recharge the team, remove some issues and frustrations.

Even when the project failed or being cancelled you should NOT be bitter. It is easy for the project manager to blame something or somebody but by doing that you are creating a “bad environment” and may lose the respect of the team. Who want to work for a manager that blame their people? You must accept the responsibility and then connect back with the team by show them that you care. You must use any failures as a “lesson learned”. It is easy to get them engaged again if you show them that there is another chance, another project and you want them to work for you again. You may say that “As a team, we all learn from this lesson” and we will NOT make that mistake again. When your team is discouraged, do NOT avoid them. Instead, try to be positive and see what can be reworked and do NOT be afraid to ask for new ideas from your team on how to do it better next time. You will be surprised at how many ideas that they could come up to make a big difference the next time.