Xây dựng kế hoạch công việc IT theo tháng, quý và năm: Từ mục tiêu đến kết quả đo lường.

Vì sao IT Manager cần ba tầng kế hoạch thay vì một danh sách việc duy nhất?

Kế hoạch năm có tầm nhìn dài nhưng không đủ chi tiết để điều hành hằng ngày. Kế hoạch tháng đủ cụ thể nhưng dễ bị cuốn theo sự vụ. Kế hoạch quý nằm giữa hai tầng, giúp chuyển chiến lược thành cam kết thực thi và cho phép điều chỉnh trước khi hết năm. Ba tầng tạo thành một hệ thống thay vì ba tài liệu tách rời.

Nếu thiếu tầng năm, IT bị dẫn dắt bởi yêu cầu mới và khó phát triển năng lực nền tảng. Nếu thiếu tầng quý, các mục tiêu năm quá xa và không tạo áp lực ưu tiên. Nếu thiếu tầng tháng, dự án và vận hành tranh chấp nguồn lực mà không ai thấy. IT Manager cần một nhịp planning–review liên tục để giữ cân bằng.

Bài Xây dựng mục tiêu và kế hoạch hoạt động bộ phận IT tập trung vào logic từ mục tiêu doanh nghiệp đến outcome. Ở đây trọng tâm là biến logic đó thành nhịp kế hoạch thực thi.

Kế hoạch năm: xác định hướng, outcome, ngân sách và năng lực cần xây

Kế hoạch năm nên trả lời: doanh nghiệp đang theo đuổi mục tiêu nào; IT cần bảo vệ hoặc tạo năng lực gì; dịch vụ nào là trọng yếu; sáng kiến lớn nào cần thực hiện; năng lực con người/công nghệ nào còn thiếu; và budget envelope dự kiến. Không cần chi tiết đến task.

Một cấu trúc gọn có thể gồm 5–8 outcome cấp bộ phận, các chỉ số chính, danh mục sáng kiến lớn và giả định về capacity. Mỗi outcome nên có baseline và target đủ rõ để review quý. Nếu kế hoạch năm có 40 “mục tiêu ưu tiên”, thực tế nó không còn là kế hoạch ưu tiên.

Ngân sách nên đi cùng outcome và danh mục. Nội dung Lập Kế Hoạch & Quản Lý Ngân Sách IT hữu ích để quản lý forecast, actual và quyết định phân bổ nguồn lực theo mục tiêu thay vì chỉ theo tài khoản chi phí.

Kế hoạch quý: biến chiến lược thành cam kết ưu tiên và giới hạn WIP

Quý là khoảng thời gian đủ dài để tạo kết quả nhưng đủ ngắn để điều chỉnh. IT Manager nên chọn số lượng cam kết hữu hạn. Mỗi cam kết cần outcome, owner, milestone, phụ thuộc, capacity và rủi ro. Những việc quan trọng nhưng chưa đủ capacity phải được nhìn thấy như backlog, không nên “nhét” vào kế hoạch rồi hy vọng làm được.

Một review đầu quý nên xác nhận các thay đổi về nhu cầu doanh nghiệp, budget, vendor và rủi ro. Giữa quý, review tập trung vào ngoại lệ và trade-off. Cuối quý, đánh giá outcome chứ không chỉ milestone. Nếu dự án hoàn tất nhưng người dùng chưa áp dụng, outcome vẫn chưa đạt.

Kế hoạch tháng: điều phối dự án, vận hành, thay đổi và năng lực con người

Ở tầng tháng, IT Manager cần thấy tổng workload. Một lỗi phổ biến là dự án có kế hoạch riêng, BAU có kế hoạch riêng, maintenance có lịch riêng và đào tạo lại tách riêng. Khi cộng lại, team thường được “lập kế hoạch” vượt quá năng lực thực tế.

Kế hoạch tháng nên hợp nhất tối thiểu bốn loại nhu cầu: vận hành bắt buộc, project/change, cải tiến và phát triển năng lực. Với từng team, xác định capacity khả dụng sau khi trừ trực, support, nghỉ phép và công việc định kỳ. Nội dung Quản Lý Năng Lực & Hiệu Suất IT giúp chuyển capacity từ cảm tính sang dữ liệu.

Tầng tuần không cần biến thành micro-management. Mục đích là xác nhận commitment gần nhất và phát hiện blocker sớm. Chi tiết task có thể nằm ở công cụ team; IT Manager chỉ cần nhìn các ngoại lệ có khả năng ảnh hưởng outcome hoặc cam kết tháng.

Đo lường và review: kế hoạch chỉ có giá trị khi có vòng phản hồi

Mỗi tầng kế hoạch cần dữ liệu review phù hợp. Năm: outcome và xu hướng capability. Quý: mức đạt mục tiêu, dự báo, rủi ro và lợi ích. Tháng: tiến độ cam kết, workload, service performance và dependency. Tuần: blocker, incident và quyết định cần hỗ trợ.

Không nên chỉ dùng RAG status đỏ-vàng-xanh. Một status cần kèm xu hướng và lý do. Ví dụ “Vàng – milestone integration trễ 2 tuần vì vendor; không ảnh hưởng go-live nếu quyết định phương án B trước ngày X” hữu ích hơn “Vàng – đang theo dõi”.

Nhịp review nên gắn với continual improvement: kế hoạch không chỉ hỏi “đã làm đúng chưa?” mà còn “cách lập kế hoạch có chính xác không?”. Nếu mỗi quý đều overcommit 30%, vấn đề nằm ở capacity model hoặc cách ưu tiên, không phải ở việc team chưa cố gắng đủ.

Tình huống minh họa: mọi dự án đều ưu tiên và tháng nào cũng phải làm thêm giờ

Tình huống giả định: bộ phận IT có bốn dự án, vận hành 24/7 và nhiều yêu cầu từ các phòng ban. Kế hoạch năm ghi cả bốn dự án đều “High”. Mỗi tháng, team nhận thêm thay đổi khẩn nên thường làm thêm giờ và các mốc dự án trễ.

IT Manager thiết lập planning theo quý. Team ước tính capacity thật sau BAU; chỉ hai dự án được cam kết trong quý, một dự án giảm phạm vi và một dự án chuyển sang quý sau. Kế hoạch tháng thêm buffer cho incident và maintenance. Các yêu cầu mới phải đánh đổi với một ưu tiên hiện hữu, thay vì tự động cộng thêm.

Kết quả kỳ vọng là giảm overcommit và tăng độ tin cậy của cam kết. Quan trọng hơn, cuộc đối thoại với business trở nên minh bạch: “nếu thêm ưu tiên này, việc nào sẽ lùi?” thay vì “IT sẽ cố gắng”.

Quản lý “công việc vô hình” để kế hoạch không liên tục bị phá vỡ

Nhiều kế hoạch IT thất bại vì chỉ lập lịch cho project và ticket được ghi nhận, trong khi công việc vô hình như hỗ trợ đồng nghiệp, xử lý truy vấn nhanh, họp nhà cung cấp, audit evidence và các yêu cầu nhỏ tiêu tốn đáng kể capacity. IT Manager nên lấy dữ liệu vài tuần để ước tính tỷ lệ công việc không kế hoạch và phản ánh vào capacity model.

Mục tiêu không phải biến mọi phút thành task, mà là nhìn thấy pattern. Nếu một team luôn mất 25% thời gian cho request ad-hoc, đây là dữ liệu để thiết kế buffer, cải thiện self-service hoặc thay đổi quy trình intake. Khi công việc vô hình được quản lý ở mức hệ thống, kế hoạch trở nên đáng tin cậy hơn mà không cần micro-manage từng người.

Checklist triển khai hệ thống kế hoạch tháng–quý–năm

• Kế hoạch năm có số outcome hữu hạn và liên kết mục tiêu doanh nghiệp.
• Kế hoạch quý có owner, milestone, capacity, dependency và risk cho mỗi cam kết.
• Kế hoạch tháng hợp nhất BAU, project, change, maintenance và phát triển năng lực.
• Capacity được tính trên nguồn lực thực tế, không trên 100% giờ làm việc lý thuyết.
• Có buffer phù hợp cho incident và công việc không dự báo.
• Yêu cầu mới bắt buộc đi kèm quyết định trade-off nếu vượt capacity.
• Review tập trung vào outcome, forecast và quyết định, không chỉ cập nhật status.
• Cuối mỗi quý có retrospective về độ chính xác của kế hoạch và nguyên nhân lệch.

Khi hệ thống mới triển khai, hãy giữ cấu trúc đơn giản. Một spreadsheet hoặc board tốt với dữ liệu đáng tin cậy hữu ích hơn một công cụ portfolio phức tạp nhưng không được cập nhật. Sau khi nhịp quản trị ổn định, mới cân nhắc tự động hóa dashboard và tích hợp dữ liệu.

Nếu bộ phận quản lý nhiều dự án đồng thời, kỹ thuật trong Quản Lý Dự Án IT có thể hỗ trợ chuẩn hóa milestone, dependency và risk để dữ liệu dự án đi vào planning cadence nhất quán.

Kết luận: kế hoạch là một vòng lặp ưu tiên – thực thi – học hỏi

Mục tiêu của planning không phải dự đoán chính xác cả năm. Mục tiêu là tạo một cơ chế giúp IT Manager duy trì hướng đi, nhìn thấy trade-off và điều chỉnh dựa trên bằng chứng. Năm tạo hướng; quý tạo cam kết; tháng tạo khả năng điều phối; tuần tạo phản hồi nhanh.

Hành động nên bắt đầu là tạo một bảng liên kết 3 tầng cho ba outcome quan trọng nhất. Sau một chu kỳ quý, đo độ chính xác của cam kết, nguyên nhân thay đổi và mức đạt outcome. Chính dữ liệu này sẽ làm kế hoạch ngày càng thực tế hơn.

Bài viết liên quan

• Mục tiêu và kế hoạch hoạt động của bộ phận IT
• Quản lý kết quả thay vì chỉ quản lý công việc
• Thiết kế cơ cấu tổ chức IT
• Áp dụng RACI để làm rõ trách nhiệm

Nguồn tham khảo

1. ISO/IEC 38500:2024 – Governance of IT for the organization
2. ISACA – COBIT resources
3. PeopleCert – ITIL Foundation (Version 5): value, governance, organizations and people
4. PeopleCert – ITIL Service (Version 5): service performance and measurable outcomes

Các nguồn trên được dùng để tham khảo nguyên tắc quản trị, quản lý dịch vụ, trách nhiệm và tổ chức công việc. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.