Quản lý dự án tin học – những điều cần biết

Joseph Phillips, PMP, Project+, là giám đốc đào tạo cho các chuyên đề về dự án (Project Seminars). Là tác giả của nhiều sách về quản lý dự án Ông cũng đã từng là tư vấn về quản lý dự án cho các tổ chức tạo ra các phòng dự án, các mô hình nổi tiếng, cũng như các ứng dụng “best practices”. Có thể liên lạc với ông qua địa chỉ jdp@projectseminars.com.
Sau đây là trích lược dịch từ bài phỏng vấn ông trên trang web www.cio.com

1. Các nguyên tắc cơ bản của quản lý dự án là gì

Dự án được hiểu như 1 nỗ lực ngắn hạn để tạo ra 1 sản phẩm, dịch vụ, hoặc một “môi trường” duy nhất : thí dụ như lọai bỏ những server cũ, hay phát triển e-comerce site , tạo 1 hình ảnh/ giao diện mới cho desktop, hay sát nhập/gộp các cơ sở dữ liệu.

Tất cả các dự án đều bị ràng buộc bởi các yếu tố: thời gian, chi phí, và phạm vi. Để 1 dự án thành công 3 ytố này (thừong gọi Triple contrainst of Project management) phải trạng thái cân bằng. Nếu bất cứ nào làm ảnh hưởng đến sự cân bằng, dự án đang hướng tới phá sản.

Tất cả các dự án bao gồm cả dự án IT, sẽ tiến hành qua 5 giai đọan trong cái gọi là “project managemtn life cycle” ( tạm dịch : vòng đời của quản lý dự án): bao gồm: khởi tạo, lập kế hoặc, thực thi, giám sát và kiểm sóat, và kết thúc. Ở mỗi giai đọan, các process sẽ biến dự án từ ý tưởng thành thực thi ( hay hiện thực)

2. Tại sao các dự án IT thường thất bại

Theo Standish Group, Nhóm kiểm chứng tỷ lệ thành công các dự án IT, chỉ có 29% dự án IT thực hiện trong năn 2004 là thành công hoàn toàn. Con số đó minh họa cho nhiều lý do và đa dạng của sự thất bại.

Dự án IT thất bại bởi vì chúng cần phải lên kỹ hoặc chi tiết hơn. Chúng bao gồm thử thách về quản trị dự án như: dead line (đến hạn), ràng buộc về ngân sách, quá ít nhận lực. Nhưng chúng cũng fải đối mặt những khó khăn về mặt công nghệ duy nhất, phần cứng, hệ điều hành, mạng hay cơ sở dữ liệu (csdl), rủi ro về an ninh, những tuơng tác phát sinh, những thay đổi của nhà sx đối với cầu hình phần cứng phần mềm
Dự án IT thất bại ngay từ đầu, không phải chỉ khi đến giai đoạn cuối, bởi vì thiếu kế họach.
Một tổ chức IT phải cân nhắc nguồn tài nguyên cần thiết để phát triển dự án. Kỹ năng cần thiết, các cá nhân có liên quan, cân nhắc 1 cách thực tế về thời gian, tạo, triển khai các chuyển giao cụ thể “deliverable” (chú thích của người dịch: 1 deliverable là 1 phần cụ thể hóa của objectives). Nếu không, dự án sẽ rối. Tổ chức IT sẽ không bao giờ hoàn thành đúng hạn, trong ngân sách hoặc đúng yêu cầu đặt ra. Đó cũng chính là sự cân bằng của 3 yếu tố (đã nói ở trên) cho sự thành công của dự án.
Điều thứ 3, dự án IT thất bại, vì phải làm trong tình trạng vội vàng. Bởi vì ngày càng có nhiều cty phụ thuộc vào IT để chiến thắng trong cạnh tranh, họ đã đẩy nhanh nỗ lực phát triển và triển khai hệ thống để trở thành người đầu tiên trên thị trường về những sản phẩm, dịch vụ, khả năng mới dựa trện công nghệ IT. Các tổ chứd thường cảm thấy rằng, để duy trì sự cạnh tranh, họ phải giảm chi phí, và duy trì hoạt động kinh doanh. Nhưng điều này làm thêm áp lực trên các dự án lớn và mắc tiền như triển khai ERP hoặc nâng cấp “platform” (chú thích người dịch: platform: thông thường được hiểu như 1 hệ điều hành dạng NT của Microsoft, Unix, hay Lilux, tuy nhiên trong một số trường hợp khác nó còn có nghĩa như 1 nền tảng cho 1 ứng dụng). Một dự án với kế hoạch không phù hợp, các đánh giá về rủi ro, và kiểm chứng không phù hợp thất bại sẽ sinh ra ngay tư đầu.
Cuối cùnng,dự án IT thất bại vì phạm vi dự án quá rộng. Một dự án với phạm vi quá rộng có thể chia nhỏ thành những thành phần nhỏ hơn để dễ quản lý và tiến hành. Thí dụ như dự án chuyển đổi tất cả các thông tin cũ, các biểu mẫu, các giao dịch từ các giấy tờ thành thông tin trực tuyến có thể là quá phức tạp và tốn nhiều thời gian. Một chuỗi các dự án nhỏ cho phép dễ quản lý các nỗ lực. thí dụ như trước tiên sẽ là chuyển đổi các thông tin cũ ra các thông tin số (số hóa các thông tin), sau đó sẽ có dự án sử dụng các cơ sở dữ liệu về thông tin số hóa trong phạm vi nôi bộ, và tiếp theo 1 dự án mang csdl lên web. Các dự án nhỏ có thể hòan thành theo 1 trình tự với tính uyển chuyển cao hơn là các da lớn phức tạp và nặng nề

3. Làm thế nào để xác định một da là thất bại khi nó đang vận hành

Trong suốt giai đọan khởi động, bạn phải thiết lập các điều kiện để xác định đó là thành công hay thất bại. Td: Dự án (DA) được coi là thành công nếu DA phải gắn liền với môt số tiêu chuẩn chất lượng (chẳng hạn như 6 Sigma hay 1 ISO program). Trong giới hạn ngân sách, đúng hạn, chuyển giao một số chức năng cụ thể.
Một cách tiếp cận khác như sử dụng các chỉ số như “15-15 Rule” (tạm dịch nguyên lý 15-15). Nguyên lý 15-15 phát biểu rằng, nếu 1 dự án vuợt quá 15% ngân sách hay 15% kế họach.Nó cũng giống như không bao giờ thu lại được về mặt thời gian hay chi phí cần thiết để được coi là thành công (chú thích thêm của ng dịch: DA được hiểu là thất bại)
Một vài kỹ thuật cũng có thể giúp bạn xác địng DA là thành công hay thất bại. Td như kỹ thuật xác định giá trị thu được cho phép 1 tổ chức đo lường sự hoàn thành của DA, những sai lệch của lịch biểu, tạo ra lịch biểu và chỉ số đánh giá hiệu quả chi phí và tiên đóan ngày mà dự án hòan thành và sự ảnh hưởng tài chính saukhi hoàn thành. Nếu sử dụng kỹ thuật đó, bạn thấy rằng DA đang tốn kém quá nhiều tiền rằng nó đang sản sinh ra sự mất mát hàng quí, thì bạn biết DA bạn thất bại
Nếu bạn muốn biết thêm các dấu hiệu của dự án thất bại hãy đọc “How to Kill an Enterprise Project.”

4. Khi nào dự án nên bị hủy

DA IT có thể bị hủy bỏ với rất nhiều lý do, mặc dù lý do lớn nhất vẫn là kế hoạch kém. Chí phí đang vượt quá 15%, trễ hẹn so với các cột mốc và chất lượng kém là các lý do để hủy bỏ DA.
Để xác định một da nên hủy bỏ khi chúng bắt đầu, xác định tình huống có thể làm cho da hủy bỏ. Bạn có thể phải cân nhắc thời gian và chi phí hoặc thay đổi điều kiện kinh doanh. Td: nếu công ty phải chịu đựng tổn thất về thu nhập vì bất cứ lý do gì, bạn có thể phải hủy bỏ DA để tiết kiệm tiền của bạn. Bạn cũng có thể quyết định hủy bỏ DA nếu phạm vi lớn vuợt quá hay thay đổi quá lớn làm cho DA không còn đáng đuợc ghi nhận hoặc … (has morphed into something else).
Nếu dự án gây ra sự chán nản, bạn có thể chia thành các dự án nhỏ chúng mang lại giá trị tương ứng với 1 ít chi phí bỏ ra. Cuối cùng, một dự án nhỏ hơn thì khả năng thành công cao hơn.

5. Làm thế nào để chắc chắn là DA thành công

Tổ chức nên tạo ra hay thích ứng với 1 cách tiếp cận chuẩn để quản lý DA. Các giám đốc có thể xác định 1 cách nhanh chóng cách thúc nào tiến hành thuận tiện và cách thức nào thì không whi tất cả da tiến hành theo cùng 1 quá trình và 1 cách tiếp cận, và sử dụng 1 đơn vị đo lường chung để đo lường hiểu quả da. 1 chuẩn mực tiếp cận để quản lý dự án sẽ thiết lập các qui tắc chặt chẽ và giá trị mong đợi cho đội dự án. Nó cũng cung cấp cho giám đốc dự án, các giám đốc các bộ phận, phòng ban và các nhân viên 1 ngôn ngữ chung trong việc quản lý dự án làm cho quá trình giao tiếp dễ dàng và làm cho mọi nguời cùng chung một “chiến tuyến”.

Sử dụng tập hợp những thứ không liên quan trong kỹ thuật quản lý dự án làm cho dự án không khả thi cho việc đo lườmg đánh giá mức độ thành công của DA. Và nếu tổ chức không thể đo lường da của họ, họ cũng không thể xác định tiến trình và phương pháp nào là tốt và cái nào cần phải cải tiến.

6. Phương thức quản lý da nào là thông dụng, và cái nào ứng dụng tốt nhất cho nhiều lọai dự án khác nhau

Có 3 cách tiếp cận tốt nhất trong quản lý DA IT. Cách thứ nhất dựa trên “quản lý DA truyền thống”. Nó thì tốt cho bất kỳ dự án IT nào không phân biệt đó là DA với công nghệ IT nào với thời gian bao lâu
Cách thứ 2 được gọi là “Extreme Programing”. Nó đôi khi được viết tắt XP.(không phải windows XP) . XP là 1 phương pháp quản lý dự án được thiết kế đặc biệt cho phát triển phần mềm. XP sử dụng 1 mô hình phát triển phần mềm nó bao gồm người sử dụng, khách hàng và người lập trình trong 4 giai đọan lặp đi lặp lại: lập kế hoạch, viết mã lệnh, thiết kế và kiểm chứng.

Scrum là phương pháp cuối (trong 3 phương pháp kể trên). Cách tiếp cận này, được đặt tên theo thuật ngữ của môn thể thao bóng bầu dục, cũng sử dụng sự lặp đi lặp lại của lập kế hoạch, viết mã lệnh, thiết kế và kiểm chứng . Scrum sử dụng ngôn ngữ riêng của chúng và có một vài nguyên tắc khắt khe về họp hành, cột mốc đạt được, thời gian của kế họach hành động

7. Ở một vài công ty có phòng quản lý da. Nhiệm vụ của phòng này là gì, có nên tạo ra phòng này hay không

Một vài cty có phòng qlda (PMO) để tập trung và phối hợp tất cả các họat đông QLDA bao gồm IT và các phòng chức năng của cả cty. PMO thiết lập các qui tắc vững bền và các giá trị mong đợi xung quanh việc tiến hành dự án cho trưởng phòng dự án, phòng dự án và các bên tham gia.
PMO tập trung các yêu cầu thay đổi của phạm vi dự án, cung cấp khóa đào tạo, kiểm chứng các phần mềm, các mẫu kế họach dự án (template plan) , các form tiến trình (process from) cho qlý dự án và đội dự án nhằm bảo đảm rằng da được tiến hành trôi chảy và kết thúc thành công. Trong 1 vài cty. PMO xác định thứ tự ưu tiên dự án nào làm trước và khi nào. PMO cũng xác định nguồn tài nguyên (con người, và các yếu tố khác) sẽ làm việc trong dự án nào để ngăn các bộ phận tranh giành resource

1 PMO vững chắc thì thường được lãnh đạo bởi nhà quản lý DA thành thạo và dầy dạn kinh nghiệm có nhân viên hỗ trợ , người này sẽ giúp nhà quản lý trong những việc hành chính (như ghi biên bản cuộc họp, phối hợp ghi nhận tiến trình dự án, truyền thông và họp với các stakeholder) nhằm tăng thời gian để tập trung ở các khâu khác (ghi chú: dịch thóat đi so với bản gốc)
PMO có thể tồn tại bên trong hoặc bên ngoài phòng IT. Một vài cty thường có duy nhất một PMO cho tất cả các lọai dự án ( bất kể là DA sáng kiến IT, phát triển doanh nghiệp hoặc sản phẩm mới) và nó độc lập với tât cả cả các phòng ban khác.
Các Qlý DA chỉ phải report bên trong phòng PMO. Các giám đốc dự án chuyên biệt thuờng cũng là nhân viên của PMO, nhưng nhân viên mà được gắn chức danh cho giai đọan khởi đông dự án thường không phải là nhân viên của PMO bởi vì họ có trách nhiệm trong các công việc thuờng nhật khác cộng thêm trách nhiệm của vào chức danh mới (quản lý da)
Một tin xấu về PMO là nó làm khó cho tính lãnh đạo và cách quản lý của các nhà qlda bởi mệnh lệnh phải sử dụng các phuơng thức qlda chỉ định cũng như buộc phải tuânn theo các thủ tục chỉ ra trong công việc cho việc tài liệu hóa công việc

8. Bao nhiêu quyền lực là cần thiết cho 1 nhà quản lý dự án

Giám đốc DA phải có khả năng chỉ địng nguồn lực cần thiết cho việc hòan thành DA. Nếu họ không có quyền hạn đưa ra các quyết định về nhân sự, qui trình, và phương pháp mà chính những thứ này ảnh hưởng đến sự thành công của DA, thì đó chính là sự bó buộc. cũng bằng lập luận như vậy bạn không muốn giao quyền cho nhà quản lý dự án kém
Tổng quát hóa, nhà quản lý dự án càng có nhiều kinh nghiệm, giao quyền càng nhiều. Trong khi đó sự khác nhau của các tổ chức khác nhau, quyền lực thể hiện trong cấu trúc nằm trong tổ chức đó và nó cũng xác định quyền hạn của nhà quản lý dự án.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: