Mở đầu — vì sao bài này quan trọng
Nếu bạn từng dự một buổi phỏng vấn PMP hoặc đọc các đề thi mẫu, bạn sẽ nhận ra một điều: PMI không còn muốn bạn thuộc lòng "quy trình chuẩn phải làm 49 bước". Thay vào đó, họ muốn biết bạn có đủ tỉnh táo để chọn đúng mức độ quy trình cho đúng dự án hay không. Đó chính là Tailoring — nguyên tắc thứ 7 trong 12 nguyên tắc của PMBOK 7th Edition, và cũng là một trong những chủ đề bị hiểu sai nhiều nhất.
Tại sao Tailoring lại quan trọng đến vậy với một PM Việt Nam? Bởi vì phần lớn dự án chúng ta làm không giống sách giáo khoa. Một dự án triển khai phần mềm ERP cho nhà máy dệt ở Bình Dương khác hẳn một dự án marketing ra mắt sản phẩm mới trong 6 tuần. Một dự án xây dựng có hợp đồng FIDIC hàng chục tỷ đồng khác hẳn một dự án nội bộ cải tiến quy trình kho. Nếu bạn áp cùng một bộ quy trình nặng nề cho cả ba, bạn sẽ hoặc làm chậm dự án nhỏ đến mức bóp nghẹt nó, hoặc để dự án lớn thiếu kiểm soát đến mức mất tiền.
Tailoring dạy bạn cách "may đo" (tailor nghĩa gốc là thợ may) bộ áo quản lý dự án vừa vặn với từng cơ thể. Đây không phải kỹ năng nâng cao dành cho PM lâu năm — nó là tư duy nền tảng mà đề thi PMP kiểm tra ở gần như mọi tình huống. Hiểu Tailoring, bạn sẽ trả lời đúng rất nhiều câu hỏi "PM nên làm gì tiếp theo" mà không cần thuộc lòng.
Khái niệm cốt lõi
Tailoring là gì
Tailoring là quá trình điều chỉnh có chủ đích cách tiếp cận (approach), cơ chế quản trị (governance) và các quy trình (processes) sao cho phù hợp với dự án cụ thể và môi trường của nó. Điểm mấu chốt nằm ở cụm từ "có chủ đích": bạn không cắt bỏ quy trình vì lười, cũng không thêm quy trình vì sợ; bạn điều chỉnh dựa trên phân tích bối cảnh.
Triết lý nền của Tailoring là: không có "one-size-fits-all" (không có một khuôn duy nhất vừa cho tất cả). PMBOK 7 không đưa cho bạn một danh sách bắt buộc phải làm. Nó đưa cho bạn nguyên tắc và miền hiệu suất (performance domains), rồi giao cho bạn trách nhiệm quyết định cần bao nhiêu, kiểu gì, và ở mức độ nào.
Ba cấp độ có thể tailor
Khi thi PMP và khi làm thực tế, hãy nhớ bạn có thể may đo ở ba lớp:
1. Life cycle và development approach — Chọn predictive (waterfall), adaptive (agile), hay hybrid. Ví dụ: phần backend ổn định có thể làm predictive, phần giao diện người dùng hay thay đổi làm agile trong cùng một dự án.
2. Processes — Với mỗi hoạt động, bạn có thể thêm, bớt, gộp, tách, hoặc điều chỉnh tần suất. Ví dụ: dự án nhỏ có thể gộp "quản lý rủi ro" thành một buổi review 30 phút mỗi tuần thay vì lập risk register đầy đủ với Monte Carlo.
3. Engagement, tools, methods, artifacts — Chọn công cụ (Jira hay bảng Kanban giấy dán tường), chọn mức độ chi tiết tài liệu (charter 2 trang hay 40 trang), chọn nhịp họp.
Những yếu tố quyết định "nên may đo thế nào"
Tailoring không phải cảm tính. Bạn dựa trên các yếu tố bối cảnh:
- Quy mô và độ phức tạp dự án: dự án lớn, nhiều bên liên quan, nhiều phụ thuộc thì cần governance nặng hơn.
- Mức độ bất định và tốc độ thay đổi: yêu cầu càng mơ hồ, thay đổi càng nhanh thì càng nghiêng về adaptive.
- Văn hóa và mức độ trưởng thành của tổ chức: một công ty quen waterfall không thể chuyển sang scrum thuần trong một đêm.
- Ràng buộc pháp lý, ngành nghề, hợp đồng: dự án ngân hàng, dược phẩm, hàng không có yêu cầu tuân thủ nghiêm ngặt, không được cắt bớt tài liệu tùy tiện.
- Rủi ro và giá trị dự án mang lại: rủi ro cao thì kiểm soát chặt hơn.
Tailoring không phải "cắt cho nhẹ"
Đây là hiểu lầm chết người. Nhiều bạn nghĩ Tailoring = bỏ bớt việc. Sai. Tailoring có thể là thêm quy trình cho phù hợp. Một dự án fintech có yêu cầu bảo mật khắt khe có thể cần thêm hẳn một quy trình security review mà PMBOK không hề nhắc tới. Tailoring là "đúng lượng, đúng chỗ" — có thể nhiều hơn, có thể ít hơn mức mặc định.
Mối liên hệ với các nguyên tắc khác
Tailoring gắn chặt với nguyên tắc Stewardship (quản lý có trách nhiệm) và Systems Thinking (tư duy hệ thống). Bạn tailor không phải để tiện cho mình, mà để tối ưu giá trị cho tổ chức trong khi vẫn giữ đạo đức và cái nhìn tổng thể. Nó cũng là "van điều tiết" giúp bạn áp dụng linh hoạt 8 miền hiệu suất tùy dự án.
Tình huống thực tế
Ví dụ 1 — Startup fintech tại TP.HCM: may đo cho tốc độ nhưng không hy sinh tuân thủ
Công ty giả định "PayViet" là một startup ví điện tử ở Quận 1, đội ngũ 25 người, cần ra mắt tính năng chuyển tiền QR trong 3 tháng để kịp mùa Tết. PM mới về từ một tập đoàn lớn, quen làm charter 30 trang, risk register 80 dòng, và bốn cấp phê duyệt thay đổi.
Nếu áp nguyên bộ đó, dự án sẽ chết vì giấy tờ trước khi kịp ra mắt. PM quyết định tailor: chọn cách tiếp cận agile với sprint 2 tuần, thay charter dày bằng một "project brief" 3 trang được ký duyệt trong một buổi họp, và gộp change control thành quy tắc "PO quyết trong ngày cho thay đổi dưới 5 người-ngày".
Nhưng — và đây là điểm quan trọng — PM không cắt phần liên quan tuân thủ Ngân hàng Nhà nước. Vì là dịch vụ trung gian thanh toán, mọi thay đổi ảnh hưởng luồng tiền phải qua bước compliance review bắt buộc, có ký tên, có lưu vết. PM thậm chí thêm một checklist bảo mật mà PMBOK không nhắc.
Bài học: Tailoring là hai chiều. Cắt phần rườm rà (tài liệu, phê duyệt nội bộ) nhưng thêm/giữ nguyên phần bất khả xâm phạm (tuân thủ pháp lý). Bối cảnh quyết định chỗ nào nới, chỗ nào siết.
Ví dụ 2 — Nhà thầu xây dựng ở Đà Nẵng: khi "nặng" mới là đúng
Công ty "Trường Sơn Construction" nhận dự án xây khu nghỉ dưỡng 400 tỷ đồng, hợp đồng theo mẫu FIDIC, thời gian 30 tháng. PM trẻ vừa đi học agile về, hào hứng muốn "làm nhẹ cho linh hoạt", đề xuất bỏ bớt tài liệu và họp daily standup thay cho báo cáo tuần.
Đây là ví dụ Tailoring sai hướng. Với dự án xây dựng lớn, ràng buộc hợp đồng và pháp lý đòi hỏi tài liệu đầy đủ: WBS chi tiết đến từng hạng mục, baseline chi phí và tiến độ được phê duyệt chính thức, quy trình change order có chữ ký ba bên (chủ đầu tư, tư vấn giám sát, nhà thầu). Bê tông đã đổ thì không "sprint lại" được. Ở đây, tailor đúng là giữ governance nặng, thậm chí thêm các điểm kiểm tra chất lượng theo TCVN.
PM khôn ngoan sau đó điều chỉnh lại: giữ predictive life cycle và tài liệu đầy đủ cho phần thi công, nhưng vẫn áp dụng vài kỹ thuật agile cho phần thiết kế nội thất và trải nghiệm khách — nơi yêu cầu còn thay đổi theo ý chủ đầu tư. Đó là hybrid được may đo đúng chỗ.
Bài học: "Nhẹ" không phải lúc nào cũng tốt. Ràng buộc hợp đồng, an toàn, và tính không thể đảo ngược của công việc buộc bạn tailor theo hướng chặt chẽ hơn. Đừng để trào lưu agile che mắt việc đọc bối cảnh.
Ví dụ 3 — Công ty gia công phần mềm ở Hà Nội: may đo theo khách hàng
Công ty outsourcing "FTECH Solutions" cùng lúc chạy hai dự án cho hai khách hàng. Khách A là một ngân hàng Nhật Bản, yêu cầu tài liệu tiếng Anh chi tiết, review gate cứng, mọi thay đổi qua CCB (Change Control Board) họp thứ Sáu hằng tuần. Khách B là một startup Singapore, chỉ muốn thấy demo mỗi hai tuần và trao đổi qua Slack.
Cùng một công ty, cùng một PM, nhưng hai bộ quy trình hoàn toàn khác nhau. Với khách A, PM dùng predictive với đầy đủ artifacts. Với khách B, PM dùng scrum, backlog trên Jira, không viết đặc tả dài. Nếu PM cứng nhắc dùng chung một quy trình cho cả hai, một khách sẽ phàn nàn "chậm và quan liêu", khách kia sẽ lo lắng "thiếu kiểm soát".
Bài học: Tailoring không chỉ phụ thuộc bản chất dự án mà còn phụ thuộc kỳ vọng của bên liên quan và văn hóa tổ chức khách hàng. PM giỏi đọc được cả hai và chỉnh cho vừa.
Hướng dẫn từng bước
Dưới đây là quy trình bốn bước bạn có thể áp dụng khi bắt đầu một dự án mới — và cũng là logic mà đề thi PMP thường ngầm kiểm tra.
Bước 1 — Chọn cách tiếp cận phát triển ban đầu (initial approach). Đánh giá mức độ bất định của yêu cầu và tần suất thay đổi. Yêu cầu rõ, ít đổi thì nghiêng predictive; yêu cầu mơ hồ, đổi nhiều thì nghiêng adaptive; pha trộn thì hybrid. Đây là quyết định "khung áo".
Bước 2 — Tailor cho tổ chức. Xem xét văn hóa, mức trưởng thành, năng lực đội ngũ, và các chuẩn/quy định nội bộ (organizational process assets). Đừng chọn một mô hình mà tổ chức chưa sẵn sàng vận hành. Ở bước này bạn cũng kiểm tra các ràng buộc pháp lý và ngành nghề — đây là "vùng không được cắt".
Bước 3 — Tailor cho dự án cụ thể. Với từng nhóm quy trình, tự hỏi: hoạt động này có tạo giá trị cho dự án này không? Nếu có, giữ và chỉnh mức chi tiết. Nếu không, cân nhắc gộp hoặc bỏ. Chọn công cụ, artifacts, nhịp họp, mức tài liệu tương ứng với quy mô và rủi ro.
Bước 4 — Triển khai, đo lường và tailor liên tục. Tailoring không phải làm một lần rồi thôi. Bạn thử, quan sát qua các retrospective hoặc review, rồi tiếp tục điều chỉnh (continuous improvement). Một quy trình phù hợp ở giai đoạn đầu có thể trở nên thừa hoặc thiếu khi dự án lớn dần.
Một mẹo thực hành: hãy ghi lại lý do của mỗi quyết định tailor vào một trang gọi là "tailoring rationale". Khi kiểm toán viên, sếp, hoặc chính bạn sau này hỏi "sao dự án này không có bước X?", bạn có câu trả lời dựa trên bối cảnh, không phải "quên làm".
Lỗi thường gặp & mẹo
Lỗi 1 — Đánh đồng Tailoring với cắt giảm. Như đã nói, tailor có thể là thêm. Đừng biến "may đo" thành cái cớ để lười lập kế hoạch. Mẹo: mỗi lần bỏ một quy trình, tự hỏi "rủi ro nào phát sinh khi bỏ nó?".
Lỗi 2 — Cắt phần tuân thủ và an toàn. Đây là lỗi nguy hiểm nhất. Ràng buộc pháp lý, an toàn lao động, bảo mật dữ liệu, chuẩn ngành là "vùng đỏ" — thường không được tailor theo hướng nới lỏng. Trong đề thi, đáp án cắt bỏ compliance để "nhanh hơn" gần như luôn sai.
Lỗi 3 — Tailor một mình, không tham vấn. Quyết định cách tiếp cận nên có sự tham gia của đội và bên liên quan chính. PM tự ý áp đặt sẽ vấp phải phản kháng. Mẹo: đưa quyết định approach ra bàn trong buổi kick-off.
Lỗi 4 — Chạy theo trào lưu. "Agile đang hot nên dự án nào cũng agile" là tư duy sai. Chọn cách tiếp cận dựa trên bối cảnh, không dựa trên thời thượng. Ví dụ 2 ở trên minh họa rõ điều này.
Lỗi 5 — Tailor một lần rồi đóng băng. Bối cảnh thay đổi thì quy trình cũng nên thay đổi. Dùng retrospective để tinh chỉnh.
Mẹo thi cử: Khi gặp câu hỏi "PM nên làm gì", nếu một đáp án nói về việc đánh giá bối cảnh dự án rồi điều chỉnh cách tiếp cận, đó thường là hướng đúng — miễn là không vi phạm compliance. PMI đề cao PM biết suy nghĩ theo bối cảnh hơn PM máy móc làm đủ 49 quy trình.
Bài tập thực hành
Bài tập 1 — Đọc bối cảnh. Chọn một dự án bạn đang hoặc từng tham gia. Viết ra 5 yếu tố bối cảnh: quy mô, độ bất định, ràng buộc pháp lý, văn hóa tổ chức, kỳ vọng bên liên quan. Với mỗi yếu tố, ghi nó đẩy bạn về phía "nặng hơn" hay "nhẹ hơn".
Bài tập 2 — Bảng quyết định approach. Cho ba tình huống: (a) app di động cho một quán cà phê chuỗi, yêu cầu còn thay đổi; (b) hệ thống thanh toán lương cho cơ quan nhà nước, yêu cầu tuân thủ luật; (c) nâng cấp hạ tầng mạng cho nhà máy. Với mỗi tình huống, chọn predictive / adaptive / hybrid và giải thích trong 2–3 câu dựa trên yếu tố bối cảnh.
Bài tập 3 — Tìm "vùng đỏ". Với một dự án trong ngành bạn quan tâm (ngân hàng, y tế, xây dựng, giáo dục...), liệt kê 3 quy trình/tài liệu không được tailor theo hướng cắt giảm và giải thích lý do.
Bài tập 4 — Viết tailoring rationale. Chọn một quy trình bạn muốn gộp hoặc bỏ trong dự án của mình. Viết một đoạn 3–4 câu nêu rõ lý do, rủi ro phát sinh, và biện pháp bù đắp. Đây chính là kỹ năng bạn cần khi giải trình với sếp hoặc kiểm toán.
Tóm tắt
Tailoring — nguyên tắc thứ 7 của PMBOK 7 — là quá trình điều chỉnh có chủ đích cách tiếp cận, quản trị và quy trình cho vừa vặn với dự án và môi trường của nó. Cốt lõi cần nhớ:
- Không có "one-size-fits-all": mỗi dự án cần một bộ quy trình được may đo riêng.
- Tailor được ở ba lớp: life cycle/approach, processes, và engagement/tools/artifacts.
- Quyết định dựa trên bối cảnh: quy mô, độ bất định, văn hóa tổ chức, ràng buộc pháp lý, rủi ro và giá trị.
- Tailoring hai chiều: có thể bớt (phần rườm rà) nhưng cũng có thể thêm (phần bảo mật, tuân thủ). Tuyệt đối không cắt vùng đỏ pháp lý/an toàn.
- Tailor là hoạt động liên tục, tinh chỉnh qua từng giai đoạn, và nên có sự tham gia của đội cùng bên liên quan.