Luận văn Thạc sĩ Kinh tế: Xác định các yếu tố rủi ro ảnh hưởng đến thành công của dự án phần mềm, tình huống nghiên cứu: Công ty TNHH KMS Technology

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC KINH TẾ Tp.HỒ CHÍ MINH

NGUYỄN THỊ PHƯƠNG XÁC ĐỊNH CÁC YẾU TỐ RỦI RO ẢNH HƯỞNG ĐẾN THÀNH CÔNG CỦA DỰ ÁN PHẦN MỀM TÌNH HUỐNG NGHIÊN CỨU:

CÔNG TY TNHH KMS TECHNOLOGY VIỆT NAM

Chuyên Ngành: Quản Trị Kinh Doanh : 60340102 Mã Số

LUẬN VĂN THẠC SĨ KINH TẾ

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS-TS. VÕ THỊ QUÝ TP. Hồ Chí Minh – Năm 2012

LỜI CAM ĐOAN

Kính thƣa Quý thầy cô, kính thƣa Quý độc giả,

Tôi tên là Nguyễn Thị Phƣơng, là học viên Cao học khoá 18 – Lớp

Quản trị Kinh Doanh K18 – Trƣờng Đại học Kinh tế Tp HCM

(MSSV : 7701080867).

Tôi xin cam đoan luận văn nghiên cứu sau đây là do bản thân tôi thực

hiện.

Cơ sở lý luận là tham khảo từ các tài liệu thu thập đƣợc từ sách, báo,

các nghiên cứu đã đƣợc nêu trong phần tài liệu tham khảo. Dữ liệu phân tích

trong luận văn là thông tin thu thập thông qua phỏng vấn trực tiếp những nhân

viên chủ chốt tại doanh nghiệp phần mềm KMS Technology.

Tôi cam đoan đề tài này không hề sao chép từ các công trình nghiên

cứu khoa học nào khác.

Tp.Hồ Chí Minh, ngày 27 tháng 12 năm 2012.

Học viên

Nguyễn Thị Phƣơng

LỜI CẢM ƠN

Sau một thời gian nỗ lực, tôi đã hoàn thành đề tài “Xác định các yếu tố

rủi ro ảnh hƣởng đến thành công của dự án phần mềm. Tình huống nghiên

cứu : Công ty TNHH KMS Technology Việt Nam”. Trong suốt quá trình thực

hiện, tôi đã nhận đƣợc sự hƣớng dẫn và hỗ trợ thông tin nhiệt tình từ quý thầy

cô, bạn bè, ngƣời thân. Vì vậy, tôi xin phép đƣợc gửi lời cảm ơn sâu sắc đến :

- TS. Võ Thị Quý, là giáo viên hƣớng dẫn luận văn cho tôi trong suốt

quá trình thực hiện đề cƣơng cho đến khi hoàn tất luận văn. Đề tài này sẽ

không thể hoàn thành nếu không có sự hƣớng dẫn nhiệt tình của cô.

- Cảm ơn các anh chị đồng nghiệp tại công ty KMS Technology đã

nhiệt tình hỗ trợ và tƣ vấn, giúp đỡ tôi trong quá trình thu thập dữ liệu để

phân tích.

- Và cuối cùng, cảm ơn chồng tôi Nguyễn Văn Đoan đã động viên, ủng

hộ tinh thần và tạo mọi điều kiện tốt nhất cho tôi hoàn thành luận văn kịp thời

hạn quy định.

Tp.Hồ Chí Minh, ngày 27 tháng 12 năm 2012.

Học viên

Nguyễn Thị Phƣơng

iii

MỤC LỤC

LỜI CAM ĐOAN ........................................................................................................ i

MỤC LỤC .................................................................................................................. iii

DANH MỤC CÁC BẢNG BIỂU .............................................................................. vi

DANH MỤC CÁC HÌNH ........................................................................................ viii

DANH MỤC CÁC TỪ NGỮ VIẾT TẮT ................................................................. ix

MỞ ĐẦU ..................................................................................................................... 1

1. Giới thiệu lý do chọn đề tài.................................................................................. 1

2. Câu hỏi nghiên cứu .............................................................................................. 2

3. Mục tiêu nghiên cứu ............................................................................................ 2

4. Phạm vi, giới hạn của nghiên cứu ........................................................................ 2

5. Phƣơng pháp nghiên cứu ..................................................................................... 2

6. Ý nghĩa thực tiễn của nghiên cứu ........................................................................ 3

7. Cấu trúc đề tài ...................................................................................................... 3

CHƢƠNG 1 – CƠ SỞ LÝ THUYẾT ......................................................................... 4

1.1 Tổng quan .......................................................................................................... 4

1.2 Các khái niệm cơ bản ......................................................................................... 5

1.2.1 Dự án ........................................................................................................... 5

1.2.2 Khái niệm thành công dự án ........................................................................ 6

1.2.3 Vòng đời của dự án phần mềm.................................................................... 6

1.2.4 Rủi ro ........................................................................................................... 8

1.3 Các yếu tố rủi ro ảnh hƣởng đến dự án phần mềm ............................................ 9

1.3.1 Nhóm rủi ro về sự quản lý của các thành phần hữu quan ......................... 14

1.3.2 Nhóm rủi ro về yêu cầu và lịch trình ........................................................ 16

1.3.3 Nhóm rủi ro về quản lý dự án ................................................................... 19

1.3.4 Nhóm rủi ro về môi trƣờng phát triển ...................................................... 22

1.4 Phƣơng pháp nghiên cứu Delphi ................................................................... 23

1.4.1 Lịch sử hình thành.................................................................................. 23

1.4.2 Phƣơng pháp Delphi ............................................................................. 23

1.4.3 Quy trình tiến hành phƣơng pháp Delphi ............................................ 24

1.4.4 Số vòng phỏng vấn trong phƣơng pháp Delphi ................................... 26

1.4.5 Câu hỏi phỏng vấn trong phƣơng pháp Delphi .................................... 26

1.4.6 Sự đồng thuận trong phƣơng pháp Delphi ........................................... 27

1.4.7 Các chuyên gia trong phƣơng pháp Delphi ......................................... 28

1.4.8 Sử dụng phƣơng pháp Delphi .............................................................. 29

1.4.9 Hạn chế của phƣơng pháp Delphi ........................................................ 29

1.4.10 So sánh phƣơng pháp Delphi và phƣơng pháp chuyên gia ............... 30

1.5 Tóm tắt chƣơng 1 ............................................................................................. 31

CHƢƠNG 2 – GIỚI THIỆU CÔNG TY KMS TECHNOLOGY ............................ 32

2.1 Giới thiệu chung về công ty KMS TECHNOLOGY ....................................... 32

2.2 Các dịch vụ chiến lƣợc của KMS TECHNOLOGY ........................................ 33

2.3 Nguồn lực của KMS TECHNOLOGY ............................................................ 34

2.4 Quy trình phát triển phần mềm và chất lƣợng dịch vụ của KMS .................... 34

2.5 Các dự án đã hoàn thành trong năm 2011 và quý I, II năm 2012 ................... 35

2.5.1 Dự án Livescribe ................................................................................... 35

2.5.2 Dự án HMS (Health Market Science) ................................................... 36

2.5.3 Dự án MarketLive ................................................................................. 36

2.5.4 Dự án Alere ........................................................................................... 36

2.5.5 Dự án Invivodata ................................................................................... 37

2.6 Tóm tắt chƣơng 2 ............................................................................................. 37

CHƢƠNG 3 – PHÂN TÍCH KẾT QUẢ KHẢO SÁT.............................................. 38

3.1 Xác định các yếu tố thuộc nhóm rủi ro về sự quản lý của các thành phần hữu

quan ........................................................................................................................ 38

3.2 Xác định các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình ..................... 43

3.3 Xác định các yếu tố thuộc nhóm rủi ro về môi trƣờng phát triển ................... 48

3.4 Xác định các yếu tố thuộc nhóm rủi ro về quản lý dự án ................................ 52

3.5 Tóm tắt chƣơng 3 ............................................................................................. 58

KẾT LUẬN ............................................................................................................... 59

4.1 Kiến nghị .......................................................................................................... 59

4.2 Hạn chế và gợi ý cho các nghiên cứu tiếp theo ............................................... 61

TÀI LIỆU THAM KHẢO ......................................................................................... 62

Tài liệu tiếng Việt .................................................................................................. 62

Tài liệu tiếng Anh .................................................................................................. 62

PHỤ LỤC 1 – CÂU HỎI NGHIÊN CỨU ................................................................ 66

PHỤ LỤC 2 – KẾT QUẢ PHỎNG VẤN ................................................................. 67

PHỤ LỤC 3 – DANH SÁCH CÁC CHUYÊN GIA ................................................ 69

DANH MỤC CÁC BẢNG BIỂU

Bảng 1-1: Tóm tắt các yếu tố rủi ro theo Sharma, 2008

Bảng 3-1: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 1

Bảng 3-2: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 2

Bảng 3-3: Tỉ lệ khác biệt các yếu tố của nhóm thành phần hữu quan giữa vòng 2 và 1

Bảng 3-4: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 3

Bảng 3-5: Tỉ lệ khác biệt các yếu tố của nhóm các thành phần hữu quan giữa vòng 3, 2

Bảng 3-6: Các yếu tố thuộc nhóm rủi ro về sự quản lý thành phần hữu quan – vòng 4

Bảng 3-7: Tỉ lệ khác biệt các yếu tố của nhóm các thành phần hữu quan giữa vòng 4, 3

Bảng 3-8: Tóm tắt tỉ lệ khác biệt các yếu tố của nhóm các thành phần hữu quan giữa

các vòng

Bảng 3-9: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 1

Bảng 3-10: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 2

Bảng 3-11: Tỉ lệ khác biệt các yếu tố về về yêu cầu và lịch trình giữa vòng 2 và 1

Bảng 3-12: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 3

Bảng 3-13: Tỉ lệ khác biệt các yếu tố về yêu cầu và lịch trình giữa vòng 3 và vòng 2

Bảng 3-14: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 4

Bảng 3-15: Tỉ lệ khác biệt các yếu tố về yêu cầu và lịch trình giữa vòng 4 và vòng 3

Bảng 3-16: Tóm tắt tỉ lệ khác biệt các yếu tố về sự quản lý các bên liên quan giữa

các vòng

Bảng 3-17: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trƣờng phát triển – vòng 1

Bảng 3-18: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trƣờng phát triển – vòng 2

Bảng 3-19: Tỉ lệ khác biệt các yếu tố về môi trƣờng phát triển giữa vòng 2 và 1

Bảng 3-20: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trƣờng phát triển – vòng 3

Bảng 3-21: Tỉ lệ khác biệt các yếu tố về môi trƣờng phát triển giữa vòng 3 và 2

Bảng 3-22: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trƣờng phát triển – vòng 4

Bảng 3-23: Tỉ lệ khác biệt các yếu tố về môi trƣờng phát triển giữa vòng 4 và 3

Bảng 3-24: Tóm tắt tỉ lệ khác biệt các yếu tố về môi trƣờng phát triển giữa các vòng

Bảng 3-25: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 1

Bảng 3-26: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 2

vii

Bảng 3-27: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 2 và vòng 1

Bảng 3-28: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 3

Bảng 3-29: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 3 và vòng 2

Bảng 3-30: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 4

Bảng 3-31: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 4 và vòng 3

Bảng 3-32: Tóm tắt tỉ lệ khác biệt các yếu tố về quản lý dự án giữa các vòng

Bảng 3-33: Tóm tắt các yếu tố rủi ro đƣợc xác định

viii

DANH MỤC CÁC HÌNH

Hình 1-1: Mối liên hệ giữa rủi ro dự án với chi phí/lợi nhuận

Hình 1-2: Vòng đời của dự án phần mềm

Hình 1-3: Tóm tắt các yếu tố rủi ro của các nhà nghiên cứu

Hình 1-4: Các nhóm rủi ro trong dự án phần mềm

Hình 1-5: Quy trình tiến hành phƣơng pháp Delphi

DANH MỤC CÁC TỪ NGỮ VIẾT TẮT

Tiếng Anh

Tiếng Việt

Cụm từ viết tắt

Business Analysist

Nhân viên phân tích yêu cầu khách hàng

Quality Asurance

Nhân viên đảm bảo chất lƣợng

SDLC Software Development Life Cycle Vòng đời của dự án phát triển phần mềm

MỞ ĐẦU

1. Giới thiệu lý do chọn đề tài

Công nghệ thông tin đóng vai trò quan trọng trong cuộc sống của chúng ta

ngày nay. Công nghệ thông tin góp phần vào sự tăng trƣởng và phát triển của đất

nƣớc. Bên cạnh những thuận lợi do ngành công nghệ thông tin mang lại, vẫn tồn tại

một số lƣợng lớn các dự án phần mềm thất bại, vƣợt chi phí, trễ hạn, độ tin cậy kém

và không thỏa mãn ngƣời dùng. Theo nghiên cứu của Standish Group, trên thế giới

có 44% dự án phần mềm đƣợc gọi là thách thức (trễ hạn, vƣợt chi phí hay thiếu

những tính năng cần thiết), trong khi có 24% dự án thất bại (hủy bỏ trƣớc khi hoàn

thành hoặc đƣợc giao và không bao giờ đƣợc sử dụng). Nhƣ vậy, tổng cộng 68% số

dự án là không thành công hoặc thách thức, một con số khá lớn [49]. Theo

Boehm[7], 15-35% các dự án phần mềm bị hủy bỏ, trong khi các dự án còn lại phải

chịu trễ tiến độ hoặc vƣợt chi phí hay không đáp ứng các mục tiêu của dự án. Tỷ lệ

thất bại cao của các dự án phần mềm có thể là do đặc tính rất cơ bản của bản thân

phần mềm. Các dự án phần mềm là tập hợp của các chƣơng trình lớn với các tƣơng

tác và phụ thuộc chức năng; liên quan đến việc tạo ra một sản phẩm mà chƣa bao

giờ đƣợc tạo ra trƣớc đó. Dự án phần mềm nói chung là phức tạp và việc phát triển

của dự án diễn ra trong một môi trƣờng năng động, điều kiện kinh doanh và công

nghệ thay đổi trong quá trình thực hiện dự án. Ngƣời sử dụng thƣờng không chắc

chắn về nhu cầu của họ và thƣờng xuyên thay đổi yêu cầu khi dự án đang thực hiện.

Kết quả là các dự án phần mềm bị vƣợt chi phí, trễ tiến độ, độ tin cậy kém và không

thỏa mãn ngƣời dùng [28].

Đã có nhiều nguyên cứu xác định nguyên nhân của thất bại và chậm trễ trong

dự án phần mềm. Những nguyên nhân này đƣợc gọi là rủi ro ảnh hƣởng đến dự án

phần mềm. Mc. Farlan [34], Brooks [9], Boehm [8] đã xác định đƣợc một số rủi ro

chẳng hạn nhƣ mức tiêu hao sức lực cao, thiếu hỗ trợ quản lý cấp cao, sự hiểu lầm

về yêu cầu, tình trạng thiếu hụt nhân sự, ƣớc lƣợng sai … có ảnh hƣởng đến kết quả

thành công của dự án, dẫn đến sự chậm trễ và thất bại của dự án.

Ở Việt Nam, các nghiên cứu về rủi ro trong dự án phần mềm chƣa đƣợc phát

triển và áp dụng rộng rải, do đó chúng ta chƣa có những chuẩn mực xác định đƣợc

các yếu tố rủi ro ảnh hƣởng đến thành công của dự án phần mềm.

Vì thế, học viên đề xuất đề tài “Xác định các yếu tố rủi ro ảnh hưởng đến

thành công của dự án phần mềm, tình huống nghiên cứu: công ty TNHH KMS

Technology”

2. Câu hỏi nghiên cứu

Đề tài đƣợc thực hiện nhằm trả lời cho câu hỏi nghiên cứu sau đây:

- Những yếu tố rủi ro nào ảnh hƣởng đến thành công của dự án phần mềm,

tình huống nghiên cứu: công ty KMS Technology Việt Nam.

3. Mục tiêu nghiên cứu

Thông qua phỏng vấn các chuyên gia đang làm việc toàn thời gian tại KMS

Technology, đề tài nghiên cứu đƣợc thực hiện nhằm:

- Xác định các yếu tố rủi ro ảnh hƣởng đến thành công của dự án phần mềm

tại KMS Technology.

- Đƣa ra các biện pháp kiến nghị để hạn chế các rủi ro và nâng cao tỉ lệ thành

công của các dự án trong tƣơng lai.

4. Phạm vi, giới hạn của nghiên cứu

Phạm vi khảo sát trong nghiên cứu này chỉ giới hạn đối với các dự án phần

mềm đã hoàn thành năm 2011 và quý I, II năm 2012 tại công ty KMS Technology

Việt Nam. Việc áp dụng cho thành phố Hồ Chí Minh hay toàn lãnh thổ Việt Nam sẽ

thuộc về các nghiên cứu khác trong tƣơng lai.

5. Phương pháp nghiên cứu

Phƣơng pháp nghiên cứu định tính đƣợc dùng trong luận văn. Dữ liệu thu

thập thông qua phỏng vấn trực tiếp, chat, email. Dữ liệu thu thập đƣợc xử lý và từ

đó xác định đƣợc các yếu tố rủi ro ảnh hƣởng đến thành công của dự án phần mềm.

6. Ý nghĩa thực tiễn của nghiên cứu

Đề tài nghiên cứu mang đến ý nghĩa thực tiễn cho công ty KMS Technology

vì nó bổ sung kiến thức cho các nhà quản lý dự án, có cái nhìn tổng quan về các yếu

tố rủi ro ảnh hƣởng trực tiếp đến dự án của doanh nghiệp mình và từ đó rút ra cách

thức kiểm soát tác động của rủi ro tới dự án phần mềm để đảm bảo sự thành công

của dự án trong tƣơng lai.

7. Cấu trúc đề tài

Luận văn bao gồm các chƣơng sau:

- Chƣơng mở đầu: trình bày tóm lƣợc lý do, mục tiêu, ý nghĩa, phạm vi,

phƣơng pháp nghiên cứu cũng nhƣ cấu trúc và tóm tắt của luận văn.

- Chƣơng 1: trình bày các lý thuyết về rủi ro, các yếu tố rủi ro trong dự án

phần mềm, thành công của dự án phần mềm. Đồng thời chƣơng này cũng trình bày

về phƣơng pháp nghiên cứu Delphi đƣợc sử dụng trong luận văn.

- Chƣơng 2: giới thiệu về công ty KMS Technology và các dự án đã hoàn

thành trong năm 2011 và quý I, II năm 2012.

- Chƣơng 3: trình bày kết quả của nghiên cứu sau quá trình xử lý dữ liệu.

- Chƣơng kết luận: đƣa ra các kết luận, và kiến nghị của nghiên cứu.

CHƢƠNG 1 – CƠ SỞ LÝ THUYẾT

1.1 Tổng quan

Trong 10 năm gần đây, ngành công nghiệp phần mềm phát triển nhanh

chóng, cả về các hoạt động cốt lõi và dịch vụ. Tuy nhiên, ngành công nghiệp phần

mềm vẫn là ngành có số lƣợng dự án thất bại và chậm trễ rất lớn. Theo nghiên cứu

của Standish Group [49], trên thế giới có 44% dự án phần mềm đƣợc gọi là thách

thức (trễ hạn, vƣợt chi phí hay thiếu những tính năng cần thiết), trong khi có 24%

dự án thất bại (hủy bỏ trƣớc khi hoàn thành hoặc đƣợc giao và không bao giờ đƣợc

sử dụng). Nhƣ vậy, tổng cộng 68% số dự án là không thành công hoặc thách thức,

một con số khá lớn. Theo Boehm [7], 15-35% các dự án phần mềm bị hủy bỏ,

trong khi các dự án còn lại phải chịu trễ tiến độ hoặc vƣợt chi phí hay không đáp

ứng các mục tiêu của dự án.

Các dự án phần mềm là tập hợp của các chƣơng trình lớn với các tƣơng tác

và phụ thuộc chức năng; liên quan đến việc tạo ra một sản phẩm mà chƣa bao giờ

đƣợc tạo ra trƣớc đó. Kết quả là các dự án phần mềm dễ bị vƣợt chi phí, trễ tiến độ,

độ tin cậy kém và không thỏa mãn ngƣời dùng [28]. Hơn nữa rất khó để dự đoán sự

thành công của dự án vì phạm vi của dự án thay đổi liên tục tùy thuộc vào thị

trƣờng; do đó các nguồn lực phải đƣợc tái phân bổ dẫn đến trễ tiến độ và vƣợt chi

phí. Các dự án phần mềm thƣờng liên quan đến nhiều thực thể nhƣ công ty, phòng

ban, cá nhân …Và thƣờng có cảm giác không có liên hệ giữa các nhân viên lập

trình và quản lý, điều này dẫn đến hiểu lầm và thiếu tin tƣởng [28]. Rõ ràng, sự

phát triển dự án phần mềm ẩn chứa nhiều rủi ro. Vì vậy, quản lý những rủi ro liên

quan là quan trọng hàng đầu trong việc phát triển dự án phần mềm, đặc biệt là trong

các dự án phần mềm quy mô lớn. Nếu rủi ro không đƣợc kiểm soát ở giai đoạn đầu

của dự án, nó sẽ gây ra một sự gia tăng theo cấp số nhân trong chi phí của dự án

nhƣ hình dƣới [32]

Hình 1-1: Mối liên hệ giữa rủi ro dự án với chi phí/lợi nhuận

1.2 Các khái niệm cơ bản

1.2.1 Dự án

Dự án là một quá trình gồm các công tác, nhiệm vụ có liên quan với nhau,

đƣợc thực hiện nhằm đạt đƣợc mục tiêu đã đề ra trong điều kiện ràng buộc về thời

gian, nguồn lực và ngân sách [2]. Theo Turner va Muller [52], dự án là nỗ lực tạm

thời trong điền kiện nhân lực, tài nguyên và tài chính của tổ chức để thực hiện các

yêu cầu kỹ thuật, phạm vi công việc trong mối quan hệ ràng buộc thời gian và chi

phí để đạt đƣợc lợi ích, đƣợc xác định bởi mục tiêu số lƣợng và chất lƣợng.

Dự án phần mềm là dự án trong đó phạm vi duy nhất của công việc với các

thông số kỹ thuật nhất định mà cần phải đƣợc hoàn thành trong một thời gian nhất

định tại một chi phí nhất định [1]. Đối tƣợng liên quan chính của một dự án phần

mềm là khách hàng, là ngƣời sẽ sử dụng hệ thống cho các mục đích kinh doanh của

mình. Đối tƣợng quan trọng thứ hai của một dự án phần mềm là các nhân viên tham

gia thực hiện dự án, ngƣời xây dựng hệ thống phần mềm.

1.2.2 Khái niệm thành công dự án

Một dự án đƣợc gọi là thành công khi hoàn thành đúng tiến độ, nằm trong

ngân sách đƣợc duyệt, phù hợp với các chỉ tiêu kỹ thuật đã đề ra, và làm thỏa mãn

các thành phần hữu quan (stakeholders’ satisfaction). [55]

Đánh giá dự án đƣợc gọi là thành công hay thất bại còn phụ thuộc vào sự

cảm nhận của các bên liên quan. Cùng kết quả đầu ra của dự án, nhƣng đánh giá

thành công của mỗi bên tham gia khác nhau vì mục tiêu và sự ƣu tiên đƣợc xác định

khác nhau tƣơng ứng với vai trò của các bên trong dự án [4]. Trong đề tài này, đánh

giá thành công của dự án trên quan điểm của các nhân viên tham gia thực hiện dự

án, ngƣời xây dựng hệ thống đƣợc sử dụng bởi khách hàng.

1.2.3 Vòng đời của dự án phần mềm

Trƣớc khi tìm hiểu những rủi ro tác động đến sự thành công của các dự án

phần mềm, cần thiết phải hiểu đƣợc các giai đoạn của vòng đời phát triển phần

mềm.

Vòng đời của dự án phát triển phần mềm (Software Development Life Cycle

–SDLC) là một khuôn khổ đƣợc sử dụng để hiểu và phát triển các hệ thống thông

tin và phần mềm thành công. Đó là một quá trình đƣợc sử dụng bởi hầu nhƣ tất cả

các nhân viên lập trình và các công ty phát triển phần mềm nhƣ là tiêu chuẩn trong

quá trình phát triển phần mềm. SDLC có nhiều mô hình và mỗi mô hình có những

điểm mạnh, điểm yếu của nó, ƣu và nhƣợc điểm riêng.

Các hoạt động tiêu biểu liên quan đến vòng đời phát triển phần mềm bao gồm:

Hình 1-2: Vòng đời của dự án phần mềm

Thu thập yêu cầu: xác định rõ các yêu cầu là bƣớc đầu tiên trong quá trình

phát triển phần mềm. Yêu cầu hệ thống có thể thay đổi tùy thuộc vào các sản phẩm

phần mềm sẽ đƣợc phát triển. Vì vậy, cần phải phân tích cẩn thận các yêu cầu cần

thiết cho sự phát triển của sản phẩm [45].

Phân tích yêu cầu: bƣớc này nghiên cứu tính khả thi về các yêu cầu thu thập

đƣợc trong bƣớc đầu tiên. Trong giai đoạn này, nhân viên lập trình phải giao tiếp

với khách hàng và phân tích các yêu cầu và hệ thống của họ. Trong giai đoạn này

cũng cần chuẩn bị kế hoạch hoặc tiến độ của dự án, chi phí ƣớc tính cho việc phát

triển và thực hiện hệ thống, ngày giao hàng dự tính cho mỗi giai đoạn của quá trình

phát triển hệ thống. Giai đoạn này là nền tảng của quá trình phát triển phần mềm,

các bƣớc tiếp theo trong SDLC sẽ dựa trên các phân tích đƣợc thực hiện trong giai

đoạn này [45].

Phân tích hệ thống và thiết kế: đây là một giai đoạn quan trọng trong phát

triển phần mềm. Các phân tích đƣợc thực hiện và các thiết kế của hệ thống sẽ đƣợc

phát triển nhƣ thiết kế cơ sở dữ liệu, thiết kế đặc tả chức năng, thiết kế tài liệu ….

Cần phải chuẩn bị các tài liệu thiết kế bởi vì giai đoạn tiếp theo, cụ thể là giai đoạn

phát triển, dựa trên các tài liệu thiết kế này để thực hiện. Khi cấu trúc của tài liệu và

các phân tích đƣợc chuẩn bị tốt, nó sẽ làm giảm thời gian thực hiện trong các bƣớc

tiếp theo là giai đoạn phát triển và kiểm thử trong SDLC [45].

Giai đoạn phát triển (lập trình): đây là giai đoạn mà phát triển phần mềm

thực sự diễn ra. Giai đoạn này dựa trên các tài liệu thiết kế đƣợc chuẩn bị trong giai

đoạn trƣớc đó. Mã đƣợc viết bằng ngôn ngữ lập trình đã chọn. Các mã sẽ đƣợc

chuyển đổi thành các file thực thi trong giai đoạn này [45].

Kiểm thử: đây là giai đoạn đảm bảo chất lƣợng của phần mềm, đảm bảo

phần mềm đƣợc giao không có lỗi. Điều này đƣợc xác định bằng cách kiểm tra mã

phát triển. Các công cụ và kỹ thuật khác nhau dùng để kiểm tra ở các cấp độ khác

nhau nhƣ kiểm tra hồi quy, kiểm tra hiệu suất …. Dựa trên nhu cầu, các phƣơng

pháp kiểm thử đƣợc lựa chọn và báo cáo lỗi. Sau quá trình này, các nhân viên lập

trình một lần nữa đi vào giai đoạn phát triển để sửa lỗi và kiểm thử một lần nữa.

Quá trình này tiếp tục cho đến khi hệ thống không còn thấy lỗi [45].

Triển khai: đây là một trong những giai đoạn cuối cùng của SDLC. Trong

giai đoạn này, tài liệu thiết kế cho bảo trì và nâng cấp đƣợc thực hiện [45].

Hỗ trợ, bảo trì và nâng cấp: đây là giai đoạn cuối của SDLC. Và là một

quá trình không ngừng: khi môi trƣờng thay đổi, các vấn đề mới đƣợc phát hiện và

yêu cầu mới đƣợc xác định, tính năng mới cần đƣợc thêm vào các phần mềm hiện

có. Tất cả điều này đƣợc thực hiện trong giai đoạn hỗ trợ và bảo trì của SDLC [45].

Toàn bộ vòng đời của dự án phát triển phần mềm liên tục tiếp xúc với cả rủi

ro nội bộ và bên ngoài. Những rủi ro có mặt trong tất cả các giai đoạn của SDLC và

trách nhiệm của ngƣời quản lý dự án hoặc là loại bỏ hoặc làm giảm tác động của nó

đối với dự án. Các loại rủi ro khác nhau của dự án phần mềm sẽ đƣợc thảo luận

dƣới đây.

1.2.4 Rủi ro

Có rất nhiều khái niệm về rủi ro, mỗi tác giả lại đƣa ra một định nghĩa khác

nhau về rủi ro.

- Rủi ro là sự biến động tiềm ẩn ở những kết quả. Rủi ro là những mất mát,

thiệt hại, nguy hiểm, khó khăn hoặc điều không chắc chắn có thể xảy ra [16].

- Rủi ro là bất trắc có thể đo lƣờng đƣợc [21].

Trong dự án phần mềm, rủi ro đƣợc định nghĩa nhƣ sau:

- Rủi ro là sự ngẫu nhiên gây ảnh hƣởng nghiêm trọng đến thành công của

dự án phần mềm [25].

- Rủi ro là một phần của công việc phát triển, quy trình, môi trƣờng mà nếu

bỏ qua, sẽ làm tăng khả năng thất bại của dự án phần mềm [38].

- Rủi ro là bất trắc không lƣờng trƣớc liên quan đến sự thay đổi và bổ sung

các yêu cầu kỹ thuật trong giai đoạn phát triển phần mềm [17].

- Rủi ro là tập hợp các yếu tố, điều kiện gây ảnh hƣởng nghiêm trọng đến

thành công của dự án phần mềm [54]. Trong luận văn này rủi ro đƣợc giải

thích theo định nghĩa này.

1.3 Các yếu tố rủi ro ảnh hƣởng đến dự án phần mềm

Đã có rất nhiều nghiên cứu xác định, phân tích rủi ro trong dự án phần mềm.

Các nhà nghiên cứu đã xác định rất nhiều yếu tố rủi ro ảnh hƣởng đến thành công

của dự án phần mềm.

- Boehm [8] bằng kinh nghiệm và qua bảng khảo sát các nhà quản lý dự án

có kinh nghiệm đã xác định mƣời yếu tố rủi ro ảnh hƣởng nhiều nhất đến thành

công của dự án phần mềm. Đó là: (1) thiếu hụt nhân sự, (2) lịch trình và ngân sách

không thực tế, (3) phát triển sai các chức năng, (4) phát triển giao diện ngƣời dùng

sai, (5) vƣợt phạm vi đề ra, (6) khách hàng thay đổi yêu cầu liên tục, (7) thiếu công

cụ thực hiện dự án, (8) phân công công việc không hiệu quả, (9) hiệu suất làm việc

kém, (10) căng thẳng trong công việc.

- Field [15] và Reel [40] liệt kê những rủi ro cần tránh để thực hiện một dự

án thành công: hiểu sai yêu cầu của khách hàng, xác định sai phạm vi dự án, quản

lý kém, sự thay đổi trong việc chọn kỹ thuật, nhu cầu kinh doanh thay đổi, thời hạn

không thực tế, sự phản đối của ngƣời sử dụng, mất nguồn tài trợ, thiếu nhân viên

có kinh nghiệm, nhà quản lý không chịu rút kinh nghiệm từ những sai lầm.

- Keil và các cộng sự [25] sử dụng kỹ thuật Delphi với sự tham gia của các

nhà quản lý dự án nhiều kinh nghiệm từ Mỹ, HongKong, Phần Lan, đã đƣa ra các

yếu tố rủi ro ảnh hƣởng nhiều nhất đến thành công của dự án phần mềm. Danh

sách rủi ro bao gồm:

 Thiếu cam kết của quản lý cấp cao cho dự án, thiếu sự tham gia của

ngƣời dùng và thất bại trong việc đạt đƣợc cam kết của ngƣời dùng,

nhà quản lý thiếu kỹ năng.

 Hiểu sai yêu cầu của khách hàng, quản lý sự thay đổi yêu cầu kém

gây ảnh hƣởng đến chi phí và lịch trình dự án.

 Quản lý kém mong đợi của ngƣời sử dụng cuối cùng, nhân viên thiếu

kỹ năng và kiến thức cần thiết, nhân sự không đủ hoặc không phù

hợp.

 Thay đổi phạm vi hay mục tiêu và xung đột trong nội bộ khách hàng.

Tuy nhiên, những phân tích này không liên hệ với vòng đời phát triển dự án.

- Schmidt và các cộng sự [44] liệt kê các yếu tố rủi ro ảnh hƣởng đến dự án

phần mềm và sử dụng kỹ thuật Delphi để xác định các yếu tố rủi ro tiêu biểu. Các

yếu tố đó là:

 Thiếu cam kết của quản lý cấp cao

 Thất bại trong việc đạt đƣợc cam kết của ngƣời dùng

 Hiểu sai yêu cầu của khách hàng

 Thiếu sự tham gia của ngƣời dùng

 Nhân viên thiếu kỹ năng và kiến thức cần thiết

 Quản lý sự thay đổi yêu cầu kém

 Thay đổi phạm vi hay mục tiêu của dự án

 Sử dụng công nghệ mới

 Không quản lý mong đợi của ngƣời sử dụng cuối cùng

 Nhân sự không phù hợp hoặc không đủ

 Xung đột trong nội bộ khách hàng.

- Jiang và các cộng sự [23] đã sử dụng công cụ phần mềm đo lƣờng rủi ro

liên quan đến các đặc điểm khác nhau của một dự án phát triển phần mềm đƣợc

phát triển bởi Barki và các cộng sự [6] và đã chỉ ra rằng: quy mô dự án, ứng dụng

phức tạp, công nghệ sử dụng, không đủ nguồn lực, nhóm làm việc thiếu chuyên

môn, thiếu sự hỗ trợ của ngƣời dùng, ngƣời sử dụng thiếu kinh nghiệm, quyền lực

và trách nhiệm của các bên không đƣợc xác định rõ ràng, cƣờng độ của các cuộc

xung đột (trong nội bộ khách hàng hay giữa khách hàng với doanh nghiệp) là chín

yếu tố rủi ro hàng đầu mà một dự án phần mềm có thể gặp phải.

- Iacovou và các cộng sự [22] xác định các yếu tố rủi ro quan trọng trong dự

án phần mềm: thiếu cam kết của quản lý cấp cao, hiểu sai yêu cầu của khách hàng,

rào cản ngôn ngữ, thiếu quản lý dự án ở phía khách hàng, quản lý kém mong muốn

của ngƣời dùng, nhân viên thiếu kỹ năng và kiến thức cần thiết.

Hình 1-3: Tóm tắt các yếu tố rủi ro của các nhà nghiên cứu

Nhƣ vậy, có rất nhiều nghiên cứu đã thực hiện để xác định các rủi ro trong

dự án phần mềm. Các phƣơng pháp khác nhau đã đƣợc sử dụng để đƣa ra danh sách

các yếu tố rủi ro quan trọng. Kết quả là, đã có danh sách các yếu tố rủi ro khác

nhau với một số điểm tƣơng đồng và một số khác biệt. Một số yếu tố rủi ro chỉ ảnh

hƣởng đến các dự án cụ thể trong điều kiện cụ thể. Tuy nhiên, một số yếu tố đƣợc

báo cáo là rất thƣờng gặp và có tác động mạnh đến thành công của dự án. Một số

yếu tố rủi ro có thể kiểm soát trong khi những yếu tố rủi ro khác không thể đƣợc

kiểm soát bởi ngƣời quản lý dự án.

Năm 2008, Sharma và các cộng sự [45] đƣa ra một danh sách đầy đủ và toàn

diện bao gồm tất cả các yếu tố rủi ro ảnh hƣởng đến các dự án phần mềm. Các rủi

ro này đƣợc chia làm 4 nhóm: nhóm rủi ro về sự quản lý của các thành phần hữu

quan, nhóm rủi ro về yêu cầu và lịch trình, nhóm rủi ro về môi trƣờng phát triển dự

án, nhóm rủi ro về quản lý dự án.

Rủi ro

Khả năng kiểm soát rủi ro

Hình 1-4: Các nhóm rủi ro trong dự án phần mềm

Bảng 1-1: Tóm tắt các yếu tố rủi ro theo Sharma, 2008

Nhóm rủi ro

Các yếu tố

Thiếu cam kết của quản lý cấp cao

Văn hóa doanh nghiệp không hỗ trợ sự thành công của dự án

Nhóm rủi ro về

sự quản lý của

Thiếu sự tham gia của ngƣời dùng

các thành phần

Khách hàng thiếu trách nhiệm và cam kết

hữu quan

Xung đột giữa khách hàng và doanh nghiệp hay trong nội bộ khách

hàng

Truyền thông sai lệch về các yêu cầu của khách hàng

Phạm vi, mục tiêu của dự án không rõ ràng

Yêu cầu của khách hàng thƣờng xuyên thay đổi

Việc quản lý thay đổi không đúng cách

Nhóm rủi ro về

Lịch trình và ngân sách không thực tế

yêu cầu và lịch

trình

Hiểu sai yêu cầu của khách hàng

Mong muốn của khách hàng không thực tế

Thực hiện các công việc phụ thêm ngoài dự án (gold plating)

Ƣớc lƣợng lịch trình và chi phí không chính xác

Hiệu quả làm việc của bên thứ 3 (third party)

Nhóm rủi ro về

Cạnh tranh làm thay đổi lịch trình

môi trƣờng phát

Thay đổi phạm vi do thay đổi mô hình kinh doanh

triển dự án

Thiên tai

Nhóm rủi ro

Các yếu tố

Lập kế hoạch không đầy đủ

Thiếu phƣơng pháp quản lý dự án

Sử dụng kỹ thuật mới

Thiếu phân công trách nhiệm rõ ràng

Thiếu kiến thức về kỹ thuật

Nhóm rủi ro về

quản lý dự án

Phân bố nhân sự không phù hợp

Nhân viên nghỉ việc

Thiếu sự cam kết của các thành viên thực hiện dự án

Thiếu công cụ đo lƣờng sự tin cậy

Thiếu công cụ để xác nhận và kiểm thử

1.3.1 Nhóm rủi ro về sự quản lý của các thành phần hữu quan

Nhóm này cho thấy rằng các dự án thƣờng thành công khi có sự cam kết của

cả quản lý cấp cao và ngƣời dùng cuối, tức là những ngƣời thực sự sẽ sử dụng hệ

thống. Nếu không có điều lệ, nhiệm vụ rõ ràng, dự án chỉ đơn giản là không khả thi.

Thiếu sự cam kết của cả quản lý cấp cao và ngƣời sử dụng là một rủi ro cao. Nhƣng

cam kết ban đầu là không đủ. Khi một dự án đã bắt đầu, quản lý dự án phải định kỳ

đánh giá mức độ cam kết của các quản lý cấp cao và ngƣời sử dụng để tránh gặp

tình huống mà các sự hỗ trợ cho các dự án đột nhiên bị cắt. Những rủi ro này thuộc

nguy cơ cao và khó kiểm soát bởi ngƣời quản lý dự án. Quản lý dự án phải thực

hiện các bƣớc hợp lý để đảm bảo rằng họ có sự hỗ trợ và cam kết cần thiết để cung

cấp một dự án thành công. Danh sách các rủi ro thuộc thể nhóm này là:

1.3.1.1 Thiếu cam kết của quản lý cấp cao

Dự án có thể bị gián đoạn nếu không có sự hỗ trợ của quản lý cấp cao cho bộ

phận mình. Sự hỗ trợ của quản lý doanh nghiệp trong việc cung cấp tài chính và

ủng hộ cho những thành viên trong dự án rất quan trọng. Nếu quản lý doanh

nghiệp không hỗ trợ cho dự án, tạo áp lực thời gian thì rất khó phát triển. Quản lý

doanh nghiệp có ít khả năng để đánh giá giá trị của dự án, các công việc khác và có

xu hƣớng tiết kiệm chi phí. Nhiều dự án thất bại vì tiết kiệm chi phí mà cắt bỏ

ngƣời quản lý dự án. Keil và các cộng sự [25] nhận thấy rằng thiếu cam kết của

quản lý cấp cao là rủi ro quan trọng nhất tác động đến các dự án phần mềm. Sự hỗ

trợ quản lý cấp cao là cần thiết trong suốt quá trình thực hiện dự án và quản lý cấp

cao cần phải công khai và xác định rõ ràng các dự án ƣu tiên hàng đầu.

1.3.1.2 Văn hóa doanh nghiệp không hỗ trợ sự thành công của dự án

Văn hóa doanh nghiệp có thể gây bất lợi cho dự án do phe phái trong công

ty, văn hóa tổ chức thay đổi liên tục hoặc có nguy cơ thay đổi, và các ƣu tiên nội

bộ khác. Tất cả điều này sẽ dẫn đến việc hỗ trợ quản lý yếu kém và thất bại của dự

án [3]

1.3.1.3 Thiếu sự tham gia của ngƣời dùng

Rủi ro này đã đƣợc nhiều lần đề cập bởi các nhà nghiên cứu khác nhau. Rủi

ro này có trong mƣời nguyên nhân hàng đầu gây thất bại cho dự án phần mềm của

nhiều nghiên cứu. Nếu khách hàng không tham gia vào dự án, nó sẽ dẫn đến việc

giải thích sai về phạm vi và mục tiêu của dự án và do đó có thể dẫn đến mất tiền,

mất thời gian [47][59].

1.3.1.4 Khách hàng thiếu trách nhiệm và cam kết

Rủi ro này cũng là rủi ro cơ bản trong danh sách đƣợc xác định bởi Keil và

các cộng sự [25]. Nếu khách hàng không tham gia vào dự án, có một nguy cơ là

các nhân viên lập trình giả định các chức năng và yêu cầu kinh doanh, dẫn đến mục

tiêu của dự án không đạt đƣợc. Đây là lỗi do sự thiếu trách nhiệm của khách hàng

trong quản lý dự án.

1.3.1.5 Xung đột giữa khách hàng và nhà thầu

Thù oán hay hận thù cá nhân có thể xảy ra giữa khách hàng và các nhà thầu

phần mềm nhƣ là một kết quả của sự hiểu lầm, bất ngờ thay đổi phạm vi của hợp

đồng, giao hàng bị trì hoãn, hoặc một số tranh chấp khác giữa khách hàng và nhà

thầu [24].

1.3.2 Nhóm rủi ro về yêu cầu và lịch trình

Nhiều dự án phải đối mặt với sự không chắc chắn và bất ổn về yêu cầu của

sản phẩm. Một số điểm không chắc chắn này có thể chấp nhận đƣợc trong giai đoạn

đầu, rủi ro ảnh hƣởng thành công của dự án càng tăng nếu các vấn đề đó không

đƣợc giải quyết khi dự án tiến triển. Nếu các yêu cầu liên quan đến các yếu tố rủi ro

không đƣợc kiểm soát, nó có thể gây ra hoặc xây dựng các sản phẩm sai, hoặc xây

dựng các sản phẩm kém chất lƣợng, dẫn đến việc khách hàng không hài lòng.

Những rủi ro ở nhóm này có thể đƣợc kiểm soát bởi phần lớn ngƣời quản lý dự án,

nhƣ giao tiếp khéo léo với ngƣời sử dụng hoặc khách hàng. Những rủi ro thuộc

nhóm này là:

1.3.2.1 Truyền thông sai lệch về các yêu cầu

Đôi khi chính các khách hàng không chắc chắn những gì họ mong muốn từ

dự án. Rủi ro này có thể bị ảnh hƣởng bởi sự hiểu lầm về yêu cầu của nhà thầu

hoặc khách hàng, hay mong đợi bất thành văn của khách hàng, hoặc đặc điểm kỹ

thuật mà ngƣời sử dụng cuối cùng không đƣa vào. Mâu thuẫn có thể xảy ra giữa

các ngƣời dùng càng đẩy mạnh vấn đề truyền thông sai lệch về các yêu cầu.

Truyền thông sai lệch về các yêu cầu là một trong những yếu tố rủi ro lớn nhất vì

truyền thông sai lệch có thể làm phức tạp việc truyền tải các thiết lập ban đầu của

yêu cầu, trao đổi thông tin và thay đổi yêu cầu tiếp theo [22].

1.3.2.2 Phạm vi, mục tiêu dự án không rõ ràng

Boehm [8] chỉ ra rằng các bên liên quan khác nhau trong một dự án phát

triển phần mềm có các mục tiêu khác nhau, thƣờng xung đột với các mục tiêu của

các bên liên quan khác.Ví dụ, ngƣời dùng yêu cầu một hệ thống thân thiện với

ngƣời sử dụng, tốc độ nhanh với nhiều chức năng có thể hỗ trợ nhiệm vụ của họ.

Trong khi, các nhân viên lập trình hy vọng gặp phải những thách thức kỹ thuật thú

vị. Những kỳ vọng khác nhau tạo ra xung đột cơ bản khi đồng thời tiếp cận. Kết

quả là phạm vi không rõ ràng hoặc hiểu sai phạm vi và mục tiêu của dự án. Hơn

nữa, việc xác định không rõ ràng các thông số kỹ thuật làm yêu cầu không có tính

hữu dụng, gây ra độ lệch về cả mốc thời gian và ngân sách

1.3.2.3 Thƣờng xuyên thay đổi yêu cầu

Các bên liên quan (bao gồm cả ngƣời dùng) liên tục thay đổi các chức năng

của phần mềm trong suốt vòng đời dự án. Khi thay đổi các nhu cầu của ngƣời sử

dụng sẽ dẫn đến thay đổi các yêu cầu của dự án. Các nhà nghiên cứu [7][25] đề

nghị cố định một phần các chức năng và ngày giao hàng. Cũng có lập luận rằng,

các yêu cầu không nên cố định trong môi trƣờng kinh doanh thay đổi nhanh chóng

ngày nay, một thiết kế cố định không thích hợp với thực tiễn kinh doanh. Với một

thiết kế cố định, các nhân viên lập trình có ít sự linh hoạt trong việc thay đổi các

thông số kỹ thuật. Tuy nhiên thay đổi yêu cầu liên tục và không kiểm soát đƣợc sẽ

ảnh hƣởng lên chất lƣợng, chức năng, lịch trình, thiết kế, tích hợp và kiểm thử sản

phẩm; chắc chắn sẽ dẫn đến sự chậm trễ trong tiến độ dự án.

1.3.2.4 Việc quản lý thay đổi không đúng cách

Nếu không có sự quản lý phù hợp trong việc thay đổi của phần mềm, các

doanh nghiệp thiếu một sự hiểu biết đầy đủ về các phần mềm trong quy trình kinh

doanh của họ. Điều này bao gồm quản lý sự thay đổi trong quá trình phát triển

phần mềm, thay đổi khi phần mềm đang đƣợc sử dụng, và các thay đổi liên quan

đến yêu cầu, các mô hình, và các trƣờng hợp thử nghiệm. Điều này cũng bao gồm

quản lý cả những thay đổi riêng lẻ và những thay đổi phụ thuộc. Các nhà nghiên

cứu cho rằng việc quản lý thay đổi không đúng cách là một trong những nguyên

nhân hàng đầu dẫn đến sự thất bại của dự án phần mềm [19][39].

1.3.2.5 Lịch trình và ngân sách không thực tế

Dự án không thể đạt đƣợc mục tiêu của nó khi ngân sách, chất lƣợng, tiến

độ, mức độ thực hiện của dự án là không thực tế. Dự án không đáp ứng các cam

kết trong ngân sách có thể dẫn đến việc phải ngừng dự án. Các nhà nghiên cứu cho

rằng, rủi ro về lịch trình và thời gian là một trong những rủi ro quan trọng và phức

tạp vì rất khó để ƣớc lƣợng lịch trình một cách chính xác và nhất quán. Đối với các

dự án lớn, độ phức tạp càng cao thì việc ƣớc lƣợng chính xác càng khó, dẫn đến

khó khăn trong việc lập lịch cho dự án. Ropponen và Lyytinen [41] cho rằng rủi ro

trong lập kế hoạch và thời gian sẽ đƣợc cải thiện với quản lý dự án có kinh nghiệm.

Một lịch trình cố định có thể dẫn đến áp lực tiến độ và những nhân viên chịu áp lực

này không làm tốt những việc cần thiết, kết quả là không có khả năng tạo ra sản

phẩm đạt yêu cầu.

1.3.2.6 Hiểu sai yêu cầu của khách hàng

Rất tốn thời gian và khó khăn để thu thập và ghi lại tất cả các yêu cầu chi

tiết từ tất cả các ngƣời dùng tiềm năng, kết quả nhóm dự án không biết đầy đủ về

những gì đƣợc yêu cầu để hoàn thành dự án thành công. Điều này có thể dẫn đến

khả năng phát triển một hệ thống không đƣợc sử dụng, bởi vì việc phân tích hệ

thống thích hợp để phát triển một tập hợp đầy đủ và chính xác các yêu cầu đã

không đƣợc thực hiện. Một số các nhà nghiên cứu đã xác định sự hiểu sai yêu cầu

là một trong mƣời rủi ro hàng đầu ảnh hƣởng đến các dự án phần

mềm[15][44][53].

1.3.2.7 Mong muốn của khách hàng không thực tế

Theo Keil và các đồng sự [25], các vấn đề liên quan tới kỳ vọng của ngƣời

sử dụng có thể xảy ra bất cứ khi nào mong đợi của ngƣời dùng không thực tế. Điều

này xảy ra do lập kế hoạch không đầy đủ và không thu thập thông tin từ khách

hàng. Đôi khi các nhóm dự án cũng đƣợc tiếp xúc với kỳ vọng không thực tế từ

quản lý cấp cao hoặc ngƣời quản lý dự án. Những cản trở này dẫn đến các vấn đề

nghiêm trọng trong các dự án phần mềm.

1.3.2.8 Thực hiện các công việc phụ thêm ngoài dự án (gold plating)

Gold plating có nghĩa rằng nhóm nghiên cứu tập trung vào phân tích và làm

việc ở các mức độ chi tiết quá nhiều trong khi mất tầm nhìn của mục tiêu dự án.

Thƣờng thì các nhân viên lập trình và các nhà phân tích cho rằng khả năng bổ sung

hay thay đổi, đƣợc gọi là mạ vàng (gold plating), mà họ nghĩ rằng sẽ làm cho hệ

thống tốt hơn và hấp dẫn hơn theo quan điểm của họ. Những sai lệch có thể dẫn

đến việc ngƣời dùng không hài lòng và tốn các chi phí không cần thiết [8].

1.3.2.9 Ƣớc lƣợng lịch trình và chi phí không chính xác

Một ƣớc tính ban đầu không chính xác có thể dẫn đến việc phân bổ ngân

sách , hoặc thời gian, hoặc cả hai không đầy đủ, gây thất bại cho dự án. Ƣớc lƣợng

mọi khía cạnh của dự án, có các hành động hạn chế những việc có thể trong quá

trình phát triển hoặc nâng cấp của một sản phẩm, và giới hạn các tùy chọn có sẵn.

Ngƣời ta tin rằng ƣớc lƣợng phạm vi dự án dựa trên các kỹ thuật hoặc kinh nghiệm

quản lý là không chính xác và các ƣớc lƣợng thƣờng dựa trên các giả định đơn giản

và quá lạc quan, hoặc bi quan đƣợc thực hiện để phù hợp với những gì ngƣời khác

muốn nghe. Không cần phải nói, ƣớc lƣợng nhƣ vậy thƣờng dẫn đến tai họa. Nếu

ƣớc lƣợng có tính thực tế thấp, dự án sẽ bị thiếu nhân sự ngay từ đầu, và tệ hơn

nữa, là nhân viên phải làm thêm giờ quá mức hoặc kiệt sức. Ngƣợc lại, đánh giá

quá cao một dự án cũng có thể có tác dụng tƣơng tự nhƣ bất kỳ ƣớc lƣợng không

chính xác khác [16][44].

1.3.3 Nhóm rủi ro về quản lý dự án

Nhóm rủi ro này liên quan đến việc thực hiện thực tế của dự án. Quản lý dự

án có thể kiểm soát những rủi ro này, và do đó những rủi ro này đƣợc coi là vừa

phải. Trong những trƣờng hợp bình thƣờng, những rủi ro này không gây ra mối đe

dọa nghiêm trọng đối với dự án, do đó, chúng thuộc loại nguy cơ thấp. Tuy nhiên,

quản lý dự án không thể đủ khả năng xử lý hết những rủi ro này. Thất bại trong việc

quản lý rủi ro ở nhóm này có thể dẫn đến phần mềm kém chất lƣợng hoặc trễ hạn

hay vƣợt ngân sách. Những rủi ro sau đây thuộc về nhóm này:

1.3.3.1 Lập kế hoạch không đầy đủ

Kế hoạch không đầy đủ có thể làm cho toàn bộ dự án rối rắm. Kế hoạch giúp

xác định các kẽ hở trong dự án và ngƣời quản lý dự án có thể dùng các công cụ và

kỹ thuật để khắc phục những kẽ hở này. Lập kế hoạch tỉ mỉ tại giai đoạn tiền dự án

giúp xác định rủi ro ở các giai đoạn đầu thực hiện. Rủi ro này cũng đƣợc đề cập đến

nhƣ là một trong mƣời rủi ro hàng đầu ảnh hƣởng đến các dự án phần mềm [47].

1.3.3.2 Thiếu phƣơng pháp quản lý dự án

Quản lý dự án kém đƣợc xem nhƣ là một nguyên nhân chính gây ra rủi ro và

thất bại trong dự án phần mềm. Một kế hoạch đầy đủ và hoàn chỉnh có thể không

nhất thiết phải đƣợc trình bày nhƣng một chiến lƣợc quản lý toàn diện và phù hợp

với định nghĩa rõ ràng về vai trò và trách nhiệm phải đƣợc thực hiện càng sớm càng

tốt. Theo các nhà nghiên cứu, yêu cầu thƣờng xuyên không rõ ràng trong bất kỳ tài

liệu nào. Quản lý dự án từ phía khách hàng thƣờng thực hiện chuyển tiếp e-mail (và

chuyển tiếp một lần nữa, và một lần nữa) cho đến khi chúng đến các nhà cung cấp.

Nên sau đó rất khó để tìm ra trách nhiệm, quản lý và nguồn lực cho mỗi yêu cầu

thay đổi riêng biệt. Vì vậy, xác định vai trò của các thành viên dự án và thiết lập

những quan hệ giao tiếp thích hợp là rất quan trọng [46].

1.3.3.3 Sử dụng kỹ thuật mới

Rủi ro xảy ra khi sử dụng công nghệ mới hoặc các công nghệ mà đƣợc sử

dụng không thành công tại các công ty khác. Rủi ro này có thể tăng hơn nữa nếu có

sự thay đổi trong công nghệ trong quá trình thực hiện dự án. Các nghiên cứu cho

thấy rằng sự ổn định và khả năng tƣơng thích của phần cứng và phần mềm là

nguyên nhân chính của vấn đề. Công nghệ chƣa đƣợc chứng minh hoặc không quen

thuộc có thể gây ra sự thất vọng và dẫn đến hiệu suất thấp hoặc xung đột [59].

1.3.3.4 Thiếu phân công trách nhiệm rõ ràng

Đối với các dự án phần mềm lớn có đội ngũ lãnh đạo nhiều nhƣng không có

phân công trách nhiệm rõ ràng, dẫn đến dự án không đáp ứng các mục tiêu của nó.

Nếu mỗi nhóm trƣởng đều liên lạc với khách hàng, nó có thể tạo ra một tình huống

là khách hàng phải thông tin đến tất cả các trƣởng nhóm do đó trì hoãn dự án [51].

1.3.3.5 Thiếu kiến thức về kỹ thuật

Nhân viên dự án có thể không có đủ kiến thức về công nghệ, hoặc kinh

doanh, hoặc có thể chỉ cần không có kinh nghiệm để xử lý các dự án. McLeod và

Smith [35] chỉ ra rằng, rủi ro phát sinh từ những ngƣời có kỹ năng không đầy đủ (cả

về kỹ thuật và quản lý) cũng nhƣ mức độ kinh nghiệm. Việc thiếu kinh nghiệm với

công nghệ cũng làm tăng khả năng xảy ra rủi ro này. Điều này là một trong những

nguyên nhân chính của sự chậm trễ và thất bại của các dự án phần mềm [25][34].

1.3.3.6 Phân bố nhân sự không thích hợp.

Nhân viên dự án không phù hợp dẫn đến sự thất bại của dự án phần mềm.

Một trong những lý do chính đằng sau là thiếu quy hoạch dự án và dự toán. Nhân

viên dƣ thừa sẽ dẫn đến tăng chi phí cho dự án, cũng nhƣ thiếu nhân viên sẽ dẫn đến

kiệt sức nhân viên, tình trạng làm thêm giờ quá mức điều này gây tiêu hao sức lực

và hiệu suất kém [42].

1.3.3.7 Nhân viên nghỉ việc

Nhân viên nghỉ việc trong quá trình thực hiện dự án có tác động tiêu cực rất

lớn, vì cực kỳ khó khăn để có thể tìm đƣợc ngƣời có đầy đủ kinh nghiệm kỹ thuật

trong một thời gian ngắn và hơn nữa, phải mất thời gian cho họ để thích nghi trong

một môi trƣờng mới. Những điều này có tác động tiêu cực đến năng suất của các dự

án phát triển phần mềm [59].

1.3.3.8 Thiếu sự cam kết của các thành viên thực hiện dự án

Thiếu cam kết từ các thành viên thực hiện dự án dẫn đến kết quả là hoạt

động kém hiệu quả và cung cấp các sản phẩm chất lƣợng kém. Các nghiên cứu đã

xác nhận rằng thiếu cam kết từ các thành viên thực hiện dự án là do thiếu tin tƣởng,

thiếu sự cân bằng hoặc nhóm đa dạng, và không đầy đủ thông tin liên lạc [14].

1.3.3.9 Thiếu công cụ đo lƣờng sự tin cậy

Độ tin cậy đƣợc định nghĩa là xác suất của lỗi phần mềm trong quá trình hoạt

động với một thời gian quy định trong một môi trƣờng nhất định. Độ tin cậy là một

thuộc tính quan trọng của chất lƣợng phần mềm, cùng với chức năng, hiệu suất, khả

năng sử dụng, tiện dụng, cài đặt, bảo trì, và tài liệu. Độ tin cậy phần mềm khó đạt

đƣợc. Khó khăn của vấn đề bắt nguồn từ sự hiểu biết không đầy đủ về độ tin cậy

phần mềm và đặc điểm của phần mềm nói chung. Hạn chế về thời gian và ngân

sách sẽ làm hạn chế các nỗ lực cải thiện độ tin cậy phần mềm [59].

1.3.3.10 Thiếu công cụ để xác nhận và kiểm thử

Phát triển và kiểm thử hệ thống là hai giai đoạn quan trọng nhất của bất kỳ

dự án phát triển phần mềm nào. Các phƣơng pháp và kỹ thuật lập trình và kiểm thử

cần phải đƣợc chuẩn bị đầy đủ. Việc sử dụng phần mềm và phần cứng không ổn

định và không tƣơng thích có thể gây ra rủi ro đáng kể cho dự án. Công cụ cần thiết

để xác nhận và kiểm thử các ứng dụng hoặc sản phẩm không thể thiếu cho việc thực

hiện và triển khai thành công các phần mềm. Nếu công cụ không có đúng lúc, nó có

thể trì hoãn việc triển khai, do đó ảnh hƣởng đến tiến độ tổng thể của dự án [37].

1.3.4 Nhóm rủi ro về môi trƣờng phát triển

Nhóm rủi ro này có thể xuất phát từ môi trƣờng dự án tồn tại cả trong và

ngoài tổ chức. Những ngƣời quản lý dự án ít hoặc không có khả năng kiểm soát

những rủi ro thuộc nhóm này. Nhóm rủi ro này có khả năng xảy ra thấp, do đó,

không đƣợc xem là rất quan trọng. Tuy nhiên, nếu chúng xảy ra, có thể đe dọa

nghiêm trọng cho dự án. Những rủi ro này rất khó khăn để dự đoán. Những rủi ro

thuộc nhóm này là:

1.3.4.1 Hiệu quả làm việc của bên thứ 3 (third party)

Nhà thầu đƣợc lựa chọn không phù hợp với mục đích của dự án. Nhà thầu

không thể cung cấp một giải pháp đáp ứng mục tiêu thời gian, chi phí, chất lƣợng và

hiệu suất. Điều này có thể ảnh hƣởng nghiêm trọng đến hiệu suất tổng thể của dự

án khi bất kỳ sự chậm trễ nào từ bên thứ ba có thể làm hỏng toàn bộ tiến độ dự án

dẫn đến tăng chi phí và thời gian [27].

1.3.4.2 Cạnh tranh làm thay đổi lịch trình

Toàn cầu hóa đã làm nảy sinh những thách thức mới và một trong những

thách thức là phải theo kịp với các đối thủ cạnh tranh. Đối thủ cạnh tranh có thể xây

dựng các giải pháp phần mềm nhanh hơn, với nhiều chức năng hơn và chi phí rẻ

hơn, tích cực triển khai các sản phẩm trong cùng một thị trƣờng [5].

1.3.4.3 Thay đổi phạm vi do thay đổi mô hình kinh doanh

Với bất kì sự thay đổi môi trƣờng nào, việc theo kịp tiến độ dự án là rất quan

trọng. Các nghiên cứu đã tìm ra rằng đôi khi do những thay đổi trong môi trƣờng

cạnh tranh, phần mềm trở nên lỗi thời và không còn cần thiết cho ngƣời sử dụng.

Theo một số nhà nghiên cứu, đầu tƣ kinh doanh trong lĩnh vực công nghệ thông tin

có thể bị ăn mòn do thay đổi điều kiện thị trƣờng ngƣời tiêu dùng hoặc các tiến bộ

trong công nghệ phần mềm. Đôi khi, toàn bộ dự án có thể bị cắt giảm hoặc chấm

dứt do thay đổi trong mô hình kinh doanh. Nhà quản lý cấp cao có thể rút lại sự hỗ

trợ cho dự án do chuyển dịch cơ cấu của doanh nghiệp hoặc khách hàng đột nhiên

trở nên thờ ơ với sản phẩm [3].

1.3.4.4 Thiên tai

Thiên tai rất hiếm khi xảy ra nhƣng nó là một trong các yếu tố rủi ro quan

trọng nhất. Thứ nhất vì nó không thể kiểm soát đƣợc và thứ hai nó có thể gây ra

thiệt hại hoàn toàn cho dự án dẫn đến mất tiền, mất thời gian và thậm chí tính

mạng[3].

1.4 Phƣơng pháp nghiên cứu Delphi

1.4.1 Lịch sử hình thành

Tên gọi Delphi là lấy từ một địa danh ở đền Apollo, cổ Hy Lạp, theo truyền

thuyết là nơi gặp gỡ của các vị thần để trao đổi về những điều tiên tri của mình.

Thuật ngữ phƣơng pháp Delphi đề cập đến vô số những quy trình giao thiệp nhóm

để dự báo và đề ra quyết định. Khái niệm cơ bản của nó xuất hiện vào thập niên 50

của thế kỷ trƣớc, tại tổ chức RAND Corporation, là kết quả của công trình nghiên

cứu đƣợc không quân Mỹ tài trợ, để tìm ra những phƣơng thức đúng đắn trong việc

sử dụng những ý kiến tƣ vấn của các chuyên gia. Quá trình điều tra khảo sát này sử

dụng ý kiến của các chuyên gia để nhận dạng những phát triển công nghệ khả dĩ

trong 10-20 năm tới và ƣớc tính khả năng xảy ra cũng nhƣ thời gian thực thi

chúng[11].

1.4.2 Phƣơng pháp Delphi

Nhƣ chúng ta đã biết, rất khó để suy luận và tổng hợp kiến thức từ các

chuyên gia (Hwang và các đồng sự, 2006), đặc biệt với các kiến thức và chuyên

ngành khác nhau. Để giải quyết vấn đề này, phƣơng pháp Delphi là một phƣơng

pháp tối ƣu để thu thập kiến thức cho chuyên gia ở các thời điểm khác nhau, những

thời điểm này đƣợc cân nhắc lựa chọn trong khi việc xin ý kiến của các chuyên gia

đã đƣợc tiến hành (Chu and Hwang, 2007). Phƣơng pháp cho phép tổng hợp có hệ

thống những đánh giá của chuyên gia về một chủ đề cụ thể thông qua một bản câu

hỏi và đƣợc phản hồi liên tục với các thông tin sơ lƣợc về các lựa chọn từ những sự

phản hồi đầu tiên (Delbecq và các đồng sự, 1975). Delphi là một phƣơng pháp

nghiên cứu định tính khá chính xác và có khả năng giải quyết các vấn đề nhằm góp

phần trong việc ra quyết định và để đạt đƣợc sự nhất trí theo nhóm ở các phạm vi

khác nhau (Cochran, 1983 and Uhl, 1983) [10].

1.4.3 Quy trình tiến hành phƣơng pháp Delphi

Phần trƣớc cung cấp một cái nhìn sơ bộ về phƣơng pháp Delphi làm việc nhƣ

thế nào, phần này sẽ đi vào chi tiết hơn về các hoạt động của phƣơng pháp Delphi.

Trƣớc tiên, cần trả lời hai câu hỏi. Đầu tiên là tại sao hỏi ý kiến của nhiều chuyên

gia thay vì chỉ duy nhất một chuyên gia. Lý do là một cá nhân khi trả lời có thể

quên đi một điều gì đó hoặc sai khi xem xét một vấn đề. Clayton nói rõ rằng bằng

cách kết hợp ý kiến của một số lƣợng lớn các chuyên gia, việc xác định sự thật sẽ

chính xác hơn [11].

Câu hỏi thứ hai nếu một nhóm là tốt hơn so với một cá nhân, tại sao không

để các chuyên gia trong một phòng với nhau để cho phép họ động não và rút ra một

sự đồng thuận? Nếu các chuyên gia ngồi trong cùng một phòng dễ có hiện tƣợng

một vài cá nhân chi phối, kiểm soát các cuộc thảo luận và có khả năng quyết định

sự đồng thuận bất chấp sự phản đối ban đầu, các thành viên còn lại thì e dè hơn.

Phƣơng pháp Delphi với việc khảo sát ẩn danh có thể ngăn ngừa các vấn đề trong

giao tiếp mặt đối mặt nhƣ vậy. Ngƣời tham gia có thể trả lời với những ý kiến thật

lòng hơn [11][29].

Bắt đầu

Xác định vấn đề

Xác định nhóm chuyên gia

Thực hiện khảo sát

Phân tích kết quả

Đạt đƣợc sự đồng thuận?

Không

Ý kiến tổng hợp

Kết quả cuối cùng

Có

Hình 1-5: Quy trình tiến hành phương pháp Delphi

Đầu tiên là xác định vấn đề cần nghiên cứu. Trong luận văn này, vấn đề

nghiên cứu là xác định các yếu tố rủi ro ảnh hƣởng đến thành công của dự án phần

mềm. Bƣớc tiếp theo là xây dựng bảng câu hỏi có các dữ liệu cần thiết để các

chuyên gia trả lời cho câu hỏi nghiên cứu. Kế đến là xác định các chuyên gia sẽ

tham gia khảo sát.

Các câu hỏi đƣợc sau đó đƣợc gửi đến các chuyên gia và các câu trả lời sẽ

đƣợc thu thập, phân tích và tóm tắt. Nếu không đạt đƣợc sự đồng thuận, các câu trả

lời tóm tắt sau đó sẽ đƣợc gửi trở lại các chuyên gia để cho phép họ suy nghĩ lại về

những câu hỏi mà giờ đây họ có thêm các thông tin từ các thành viên khác trong

nhóm. Quá trình gửi các câu hỏi và sau đó nhận đƣợc câu trả lời và phân tích chúng

tiếp tục theo mô hình vòng lặp. Mỗi khi bảng câu hỏi mới đƣợc phân phối là đánh

dấu sự khởi đầu của một vòng mới. Số vòng đƣợc xác định bởi việc đạt đƣợc sự

đồng thuận ý kiến của các chuyên gia. Thời kỳ sơ khai của phƣơng pháp Delphi, do

thiếu công nghệ, bảng câu hỏi đƣợc gửi bằng phƣơng pháp gửi thƣ truyền thống.

Tùy thuộc vào số vòng cần thiết để đạt đƣợc sự đồng thuận, quá trình mất từ vài

tháng đến một hoặc hai năm để hoàn thành. Kỹ thuật ngày nay cho phép quá trình

khảo sát nhanh hơn, trong luận văn này, tất cả các thông tin liên lạc sẽ đƣợc thực

hiện thông qua sự kết hợp giữa phỏng vấn trực tiếp, qua chat và qua e-mail.

1.4.4 Số vòng phỏng vấn trong phƣơng pháp Delphi

Nhƣ đã đề cập ở phần trên, mỗi lần một bảng câu hỏi đƣợc phân phối cho

các chuyên gia và trả lại cho ngƣời nghiên cứu tạo thành một vòng của phƣơng

pháp Delphi. Câu hỏi đặt ra là cần thiết phải thực hiện bao nhiêu vòng Delphi để

đảm bảo dữ liệu đƣợc ổn định. Clayton nói rằng chỉ cần bốn vòng và là vòng cuối

cùng đƣợc gửi ra để "cung cấp lý do tại sao họ đồng ý hay không đồng ý với kết quả

cuối cùng" [11]. Chan và các đồng sự thì thống nhất trong nghiên cứu của họ bằng

cách thiết lập bốn vòng [10]. Tuy nhiên, Ludwig cho rằng “Vòng Delphi tiếp tục

cho đến khi đạt đƣợc sự đồng thuận hoặc không còn thông tin mới" [31]. Trong khi

một nghiên cứu tại Scotland, bởi Tiến sĩ Kerr, giới hạn số vòng là ba [26]. Trong

nghiên cứu gần đây, Hasson và các đồng sự giới hạn số lƣợng các vòng tùy thuộc

vào "thời gian cho phép" [20]. Các nghiên cứu đã không tìm thấy một số cụ thể của

số vòng cần thiết. Hầu hết các nhà nghiên cứu sử dụng phƣơng pháp Delphi dựa

trên tiêu chuẩn là sự đồng thuận và thời gian cho phép. Dựa trên các phân tích trên,

phƣơng pháp Delphi trong nghiên cứu này sẽ có tối thiểu là hai vòng và tối đa là

bốn vòng.

1.4.5 Câu hỏi phỏng vấn trong phƣơng pháp Delphi

Mitchell đi sâu vào nghiên cứu chi tiết việc xây dựng và quản lý các câu hỏi

Delphi. Ông cho rằng chiều dài bảng câu hỏi phụ thuộc vào việc phải mất bao lâu

để mỗi chuyên gia trả lời bảng câu hỏi. Ông cho rằng, bảng câu hỏi không nên quá

30 phút để trả lời [36]. Mitchell cũng thảo luận về việc xây dựng các câu hỏi cho

mỗi vòng của phƣơng pháp Delphi. Theo ông, câu hỏi cần phải rõ ràng và không

nên giống hệt nhau từ vòng này đến vòng khác bởi vì sự lặp lại có thể gây ra sự

nhàm chán cho ngƣời tham gia, điều này gây cản trở kết quả khảo sát [36]. Clayton

cũng thảo luận về các câu hỏi theo từng vòng. Ông nói rằng câu hỏi vòng 1 nên

đƣợc diễn đạt một cách rõ ràng nhƣng cho phép sự tự do nhất trong trả lời (câu hỏi

mở). Sau khi các câu trả lời vòng một thu thập đƣợc, một báo cáo tóm tắt các ý kiến

trả lời đƣợc soạn và sau đó gửi lại cho các chuyên gia để bắt đầu vòng hai. Trong

vòng hai, bắt đầu quá trình tìm kiếm sự đồng thuận. Để hỗ trợ trong việc tìm kiếm

sự đồng thuận, ngƣời khảo sát phải cung cấp lý do khi muốn thay đổi câu trả lời

trƣớc đó của các chuyên gia. Trong vòng 3 và vòng tiếp theo, các bảng hỏi nên tóm

tắt các câu trả lời với một bản tóm tắt lý do cho việc thay đổi các các câu trả lời và

quá trình này tiếp tục cho đến khi sự đồng thuận đƣợc đáp ứng [36]. Các câu hỏi

trong nghiên cứu này sẽ đƣợc xây dựng theo các nghiên cứu của Clayton và

Mitchell. Số câu hỏi sẽ đƣợc giới hạn đến 10 hoặc ít hơn. Thời gian cần thiết để

hoàn thành bảng câu hỏi đƣợc ƣớc tính là 20 phút. Bảng câu hỏi đƣợc thay đổi trong

mỗi vòng dựa trên kết quả của vòng trƣớc. Điều này sẽ đảm bảo mỗi chuyên gia có

cơ hội để đánh giá lại từng câu hỏi.

1.4.6 Sự đồng thuận trong phƣơng pháp Delphi

Các vòng Delphi cuối cùng phải kết thúc. Nhƣ thiết lập trƣớc khi bắt đầu,

một khi đạt đƣợc sự đồng thuận, các vòng sẽ không còn tiếp tục. Theo từ điển

Webster’s New International Unabridged định nghĩa sự đồng thuận là nhất trí hay

thỏa thuận chung trong các quan điểm [57]. Nếu định nghĩa đƣợc áp dụng cho

phƣơng pháp Delphi trong nghiên cứu này, một khi các chuyên gia đạt đến ý kiến

đa số, quá trình này hoàn tất. Vì vậy, trong điều khoản của các ứng dụng của

phƣơng pháp Delphi cho nghiên cứu, đồng thuận đƣợc định nghĩa là tỷ lệ các ý kiến

khác nhau giữa các vòng trƣớc và vòng tiếp theo là ít hơn 10%. Trong trƣờng hợp

tỉ lệ ở vòng 4 là cao hơn 10% hoặc không có câu trả lời cho một yếu tố nào đó tại

vòng bất kỳ, nó sẽ không có sự đồng thuận và yếu tố này là không đáng kể cho

nghiên cứu và vòng tiếp theo, nó sẽ đƣợc bỏ ra khỏi câu hỏi .

1.4.7 Các chuyên gia trong phƣơng pháp Delphi

Một trở ngại khác khi thực hiện phƣơng pháp Delphi là chọn bao nhiêu

chuyên gia thì thích hợp. Spinelli tiến hành nghiên cứu sử dụng phƣơng pháp

Delphi và các chuyên gia bao gồm 24 thành viên chủ chốt có hiểu biết về các yếu tố

ảnh hƣởng đến môi trƣờng chung ... "[48]. Ludwig tiến hành nghiên cứu, nhƣng có

một cách tiếp cận khác để thiết lập nhóm chuyên gia. Ludwig nói rằng "số ngƣời trả

lời đƣợc xác định bằng số lƣợng ngƣời cần thiết để tạo thành một đại diện tổng hợp

của các phán đoán và tóm tắt khả năng thông tin của nhóm nghiên cứu". Ludwig

sau đó tuyên bố "Đa số các nghiên cứu Delphi đã sử dụng từ 15 đến 20 ngƣời trả lời

và chạy trong thời gian vài tuần" [31]. Chan và các cộng sự đã nêu trong quá trình

lựa chọn của họ "mƣời thành viên của nhóm trả lời đại diện cho một phân phối rộng

rãi của những chuyên gia ..." [10]. Một nghiên cứu của Des Marchais giảm kích cỡ

của nhóm chuyên gia đến sáu [13]. William và Webb tóm tắt phƣơng pháp lựa chọn

nhóm chuyên gia bằng cách "Đầu tiên, không có thoả thuận liên quan đến kích

thƣớc của nhóm chuyên gia, cũng không có bất kỳ khuyến cáo nào liên quan đến kỹ

thuật lấy mẫu" [58].

Nhóm chuyên gia đƣợc thiết lập để trả lời các câu hỏi nghiên cứu đặt ra

trong luận văn này dựa vào số năm kinh nghiệm của các thành viên và đại diện các

thành phần tham gia dự án.

Một khi kích thƣớc của nhóm chuyên gia đã đƣợc quyết định, tiêu chuẩn xây

dựng là cần thiết để đánh giá các chuyên gia. Trong khi thảo luận về chủ đề lựa

chọn thành viên của nhóm chuyên gia, Mitchell phát biểu rằng "Không có báo cáo

nào trong nghiên cứu Delphi về vấn đề lựa chọn này" [36]. Dawson và Brucker,

trong ngiên cứu của họ, tóm tắt các tiêu chí để xác định các chuyên gia đƣợc sử

dụng trong một số nghiên cứu Delphi trong lĩnh vực của họ. Tựu chung là: kinh

nghiệm chung trong bảy năm, kinh nghiệm cụ thể là năm năm, ít nhất một bài báo

đƣợc công bố, ít nhất một lần trình bày tại hội nghị quốc gia và kinh nghiệm gần

đây trong vòng ba năm qua [12].

Với nghiên cứu này, những tiêu chuẩn chung đƣợc yêu cầu: kinh nghiệm

chung là năm năm; kinh nghiệm cụ thể là ba năm, kinh nghiệm gần đây trong vòng

năm năm qua, và không có các bài thuyết trình hoặc các ấn phẩm và chi tiết của các

chuyên gia mà tác giả lựa chọn cho nghiên cứu này để tránh sự thiên vị trong ý kiến

của họ nhƣ bên dƣới:

• Nhóm 1: 10 ngƣời quản lý dự án chủ chốt (những ngƣời có hơn 5 năm làm

việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, lãnh đạo sự thay

đổi và quản lý dự án).

• Nhóm 2: 10 ngƣời chủ chốt của bộ phận phát triển sản phẩm (những ngƣời

có hơn 5 năm làm việc cho công ty phần mềm, và họ là những kỹ thuật viên phát

triển sản phẩm (developer), các nhà giám sát và quản lý kỹ thuật).

• Nhóm 3: 10 ngƣời quan trọng của QA và BA (những ngƣời có hơn 5 năm

làm việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, và các nhà

quản lý).

Tham khảo danh sách các chuyên gia ở phục lục 3.

1.4.8 Sử dụng phƣơng pháp Delphi

Phƣơng pháp Delphi đã có nhiều công dụng trong nghiên cứu. Theo cuốn

sách về phƣơng pháp Delphi: Kỹ thuật và Ứng dụng, phƣơng pháp Delphi chủ yếu

đƣợc sử dụng nhƣ một công cụ dự báo vào đầu những năm 1960 và tiếp tục tới ngày

hôm nay. Phƣơng pháp Delphi đƣợc sử dụng để: dự báo quy phạm, xác định giá trị;

ƣớc lƣợng chất lƣợng cuộc sống, mô phỏng và đƣa ra quyết định thực tế và lập kế

hoạch. Cuốn sách cũng chỉ ra rằng các phƣơng pháp Delphi đƣợc sử dụng rộng rãi

để " phán xét dữ liệu đầu vào " khi các dữ liệu khác là không có hoặc quá tốn

kém[30]. Hasson và đồng sự nói rằng phƣơng pháp Delphi đƣợc sử dụng thƣờng

xuyên trong y tế và khoa học xã hội [20]. Mitchell trích dẫn một bảng liệt kê việc sử

dụng các phƣơng pháp Delphi theo lĩnh vực nghiên cứu tổng cộng là 800 nghiên

cứu. Delphi đƣợc sử dụng nhiều nhất trong khoa học vật lý và kỹ thuật (26% của tất

cả các nghiên cứu đƣợc tiến hành) và đứng thứ hai là sử dụng trong kinh doanh và

kinh tế (23%) [36].

1.4.9 Hạn chế của phƣơng pháp Delphi

Mặc dù Delphi là một phƣơng pháp dự báo có lịch sự phát triển lâu đời, đƣợc

áp dụng khá phổ biến và có độ tin cậy cao, nhƣng nó vẫn tồn tại nhiều hạn chế đáng

kể. Penelope (2003) cho rằng phƣơng pháp Delphi thƣờng bị chỉ trích ở những điểm

liên quan đến nhóm chuyên gia, sự đồng thuận, xây dựng bảng câu hỏi, tình trạng

nặc danh, và tƣơng tác giữa các thành viên trong nhóm tham gia.

Bên cạnh các ƣu điểm thì phƣơng pháp Delphi cũng có những nhƣợc điểm.

Thực tế khi áp dụng phƣơng pháp này cho thấy rằng chi phí cho cuộc trƣng cầu khá

lớn, thời gian kéo dài, có thể làm thay đổi thành phẩn của nhóm chuyên gia. Những

câu trả lời trực tiếp của các chuyên gia dễ mang tính chủ quan. Mặt khác các chuyên

gia phải xem lại các ý kiến của mình gây ra phản ứng không thuận lợi trong một số

chuyên gia, dễ gây ra sự chán nản, điều đó có thể ảnh hƣởng tới chất lƣợng và một

điều nữa là khó có thể chọn đƣợc một nhóm chuyên gia tƣơng đồng về chất lƣợng.

Cuối cùng, kết quả nghiên cứu dùng phƣơng pháp Delphi có thể thành kiến

nếu các thành viên trong nhóm chuyên gia không đƣợc lựa chọn cẩn thận.

1.4.10 So sánh phƣơng pháp Delphi và phƣơng pháp chuyên gia

Giống nhau: đều là phƣơng pháp thu thập và xử lý những đánh giá, dự báo bằng cách tập hợp và hỏi ý kiến các chuyên gia.

Khác nhau:

Phƣơng pháp Delphi Phƣơng pháp chuyên gia

Ẩn danh Giao tiếp mặt đối mặt

Ngƣời tham gia có thể trả lời với những ý kiến thật lòng hơn Chịu sự thống trị bởi một số cá nhân, sự xung đột giữa các cái tôi, sự hạn chế diễn đạt

Ý kiến chủ quan Đƣa ra nhiều tƣởng sáng tạo hơn các nhóm không tƣơng tác

Ngƣời tham gia hài lòng với kết quả thảo luận hơn

Có thể thành kiến nếu các thành viên trong nhóm chuyên gia không đƣợc lựa chọn cẩn thận.

Dễ dàng tham gia, tiết kiệm thời gian và linh hoạt hơn. Đòi hỏi phải có sự chuẩn bị kỹ lƣỡng trƣớc.

Phải có cuộc họp các chuyên gia

Cho phép các chuyên gia ở rải rác khắp nơi tham gia mà không cần gặp mặt.

1.5 Tóm tắt chƣơng 1

Chƣơng này đã trình bày lý thuyết nền về rủi ro, các yếu tố rủi ro trong dự án

phần mềm, thành công của dự án phần mềm, đồng thời đƣa ra các định nghĩa và

khái quát các lý thuyết khác nhau về các yếu tố rủi ro và thành công của dự án phần

mềm của các nhà nghiên cứu trên thế giới. Chƣơng 1 cũng đã trình bày về phƣơng

pháp Delphi, phƣơng pháp dùng để nghiên cứu cho luận văn.

CHƢƠNG 2 – GIỚI THIỆU CÔNG TY KMS TECHNOLOGY

Chƣơng 1 đã trình bày lý thuyết về các yếu tố rủi ro và thành công của dự án

phần mềm . Phƣơng pháp Delphi dùng cho nghiên cứu cũng đã đƣợc trình bày.

Chƣơng 2 sẽ giới thiệu về công ty KMS Technology, công ty là đối tƣợng nghiên

cứu của đề tài này.

Chƣơng 2 gồm các phần (1) giới thiệu chung về KMS Technology, (2) các

dịch vụ chiến lƣợc của KMS Technology, (3) nguồn lực của KMS Technology, (4)

quy trình phát triển phần mềm và chất lƣợng dịch vụ, (5) các dự án đã hoàn thành

trong năm 2011 và quý I, II năm 2012.

2.1 Giới thiệu chung về công ty KMS TECHNOLOGY

Công ty KMS Việt Nam đƣợc ra đời từ năm 2008 từ một nhóm kỹ sƣ phần

mềm có kinh nghiệm làm việc với các khách hàng đến từ nƣớc Mỹ. Hiểu đối tác và

tự tin vào khả năng của đội ngũ nhân lực hiện có... đội ngũ lãnh đạo KMS nhìn thấy

cơ hội thành công và nhanh chóng đón đầu xu hƣớng xuất khẩu gia công của các

doanh nghiệp tại thị trƣờng này.

Từ 10 thành viên ban đầu, đến nay KMS đã có đội ngũ nhân lực đến 350

ngƣời; từ khách hàng đầu tiên Livescribe, hiện số đối tác của công ty đã mở rộng

đến con số 36, tất cả đều đến từ thị trƣờng khó tính bậc nhất thế giới - nƣớc M ỹ...

Qua 3 năm làm việc với khách hàng ở bên kia bán cầu, Tổng Giám đốc KMS

Nguyễn Việt Hùng cho biết, công ty luôn duy trì đƣợc mức độ hài lòng từ phía

khách hàng ở mức độ lớn hơn 4, trên thang điểm 5. Doanh thu 9 tháng cuối năm

2011 của công ty đạt 4,96 triệu USD - một thành tích xuất sắc với công ty có quy

mô vừa và nhỏ. Về doanh thu, KMS tăng trƣởng gấp đôi mỗi năm.

Với những thành công ấn tƣợng, KMS đã đƣợc tặng danh hiệu Sao Khuê

2011 dành cho đơn vị xuất sắc trong lĩnh vực gia công phần mềm. Năm 2012,

KMS Technology đã vinh dự giành cú đúp tại Sao Khuê 2012 cho 2 hạng mục Dịch

vụ gia công xuất khẩu phần mềm và Nhóm các sản phẩm, giải pháp phần mềm mới

của Việt Nam.

2.2 Các dịch vụ chiến lƣợc của KMS TECHNOLOGY

 Dịch vụ phát triển phần mềm theo yêu cầu (Custom Application

Development): KMS Technology đảm nhận trọn gói việc phát triển các hệ thống

ứng dụng phần mềm theo yêu cầu khách hàng. Đối với dịch vụ này, khách hàng sẽ

cung cấp yêu cầu chuyên môn về lĩnh vực mà hệ thống phần mềm sẽ đƣợc triển

khai và ứng dụng, KMS Technology sẽ chịu trách nhiệm đề xuất giải pháp công

nghệ, kiến trúc hệ thống phần mềm, và hiện thực các tính năng để đáp ứng đƣợc

nhu cầu kinh doanh của khách hàng, cũng nhƣ đáp ứng đƣợc các yêu cầu khắt khe

về thời gian, chất lƣợng của thị trƣờng Mỹ với chi phí cạnh tranh so với các doanh

nghiệp đến từ Trung Quốc và Ấn Độ. ·

 Dịch vụ bảo trì hệ thống, sản phẩm phần mềm, quản lý ứng dụng

(Application Management): Đây là dịch vụ chiếm tỉ trọng khá lớn trong khối lƣợng

công việc nhận đƣợc từ thị trƣờng Mỹ tại KMS Technology Việt Nam. Các bài toán

cần giải quyết trong loại hình dịch vụ này bao gồm:

 Đáp ứng yêu cầu về mặt chất lƣợng cũng nhƣ thời gian hoàn thiện các

phiên bản “vá lỗi” phần mềm và nâng cấp tính năng theo đúng cam kết

hỗ trợ từ khách hàng của KMS Technology đến khách hàng cuối của họ.

 Nắm vững kiến thức về công nghệ, kiến trúc, mã nguồn hệ thống

cũng nhƣ hiểu rõ các qui tắc kinh doanh của khách hàng để có thể phát

triển các chức năng mới cho hệ thống hiện tại.

 Dịch vụ kiểm thử và đảm bảo chất lƣợng phần mềm (Software Testing):

Bài toán về bảo đảm chất lƣợng và áp lực về mặt thời gian hoàn thành dự án trong

những thời điểm mang tính quyết định (thƣờng là thời điểm phát hành các phiên

bản cập nhật hay các phiên bản mới ra thị trƣờng) là thách thức lớn nhất trong dịch

vụ này. Đây là dịch vụ có số lƣợng nhân lực tham gia nhiều nhất tại KMS

Technology. Đối với một số khách hàng, đội ngũ KMS Technology đã đạt đƣợc sự

tín nhiệm tuyệt đối từ phía khách hàng và đƣợc giao trọng trách trọn vẹn trong việc

kiểm thử các dòng sản phẩm khác nhau của khách hàng.

2.3 Nguồn lực của KMS TECHNOLOGY

Nhân lực và Công nghệ

Chỉ trong thời gian ngắn, 4 năm, KMS Technology đã tập hợp và xây dựng

đƣợc một đội ngũ nhân lực chất lƣợng cao làm việc trong ngành công nghệ thông

tin. Năm 2012 tiếp tục đánh dấu một bƣớc tiến mới trong việc tăng trƣởng qui mô

về nhân lực tại KMS Technology, đã đạt đến cột mốc 350 ngƣời vào tháng 9 năm

2012. Với tỷ lệ ~55% nhân lực cấp cao (bao gồm nhân sự quản lý, kiến trúc sƣ phần

mềm, và các nhân sự cao cấp trong ngành lập trình và kiểm thử), KMS Technology

có khả năng đáp ứng các yêu cầu công nghệ mới nhất và đảm bảo đƣợc chất lƣợng

dịch vụ tốt nhất.

Về bằng cấp chuyên môn, nhân viên KMS Technology đã gặt hái đƣợc nhiều

chứng chỉ nổi tiếng của Microsoft, Sun, và ISTQB. Ngoài ra, trong năm 2011, 2012

KMS tiếp tục đƣợc Micrsoft chứng nhận là Đối Tác Vàng / Bạc cho các lĩnh vực

 Đối tác vàng Phát triển các ứng dụng trên Web - Gold Web Development

 Đối tác bạc Phát triển phần mềm ứng dụng – Silver Software Development

Cơ sở hạ tầng / Tính sẵn sàng / An toàn thông tin

Với đặc thù của mô hình Outsourcing và yêu cầu khắt khe của khách hàng tại

Mỹ, KMS Technology đã xây dựng một hệ thống cơ sở hạ tầng thông tin với tính

sẵn sàng cao và thực hành các nguyên tắc trong bộ chuẩn về An toàn thông tin

ISO27001 nhằm bảo đảm bảo mật và an toàn thông tin, tập trung vào các điểm sau:

hạ tầng thông tin, con ngƣời, qui trình, phần mềm hệ thống hỗ trợ.

2.4 Quy trình phát triển phần mềm và chất lƣợng dịch vụ của KMS

Qui trình phát triển phần mềm

Với bề dày kinh nghiệm hoạt động trong lĩnh vực phát triển phần mềm và

đội ngũ nhân sự thành thạo các qui trình phát triển phần mềm khác nhau (trên nền

tảng lý thuyết cũng nhƣ thực hành), KMS Technology đã hoàn thiện một qui trình

phát triển phần mềm đặc trƣng nhằm đáp ứng nhu cầu thực tế trong điều kiện phục

vụ khách hàng tại Mỹ. Qui trình phát triển phần mềm của KMS đƣợc chọn lọc từ

các chuẩn CMMi, RUP, và Agile với các mục tiêu cụ thể nhƣ sau:

 Linh hoạt để đáp ứng đƣợc nhiều loại hình hoạt động đặc thù của các

khách hàng khác nhau. Trong khi một số khách hàng áp dụng một cách chặt chẽ các

nguyên lý CMMi, một số khách hàng khác lại đòi hỏi chuẩn Agile.

 Đề cao vai trò quan trọng của việc giao tiếp giữa các thành viên trong dự

án và khách hàng. Sự truyền đạt thông tin chính xác, kịp thời trong nhóm là một yếu

tố cốt lõi quyết định thành công cho dự án, chất lƣợng sản phẩm và sự hài lòng của

khách hàng.

 Sẵn sàng đáp ứng các nhu cầu thay đổi một cách nhanh chóng với chi phí

hợp lý nhằm phục vụ nhu cầu kinh doanh của khách hàng.

 Tập trung vào tính hiệu quả, tránh áp dụng một qui trình nặng nề, máy

móc làm ảnh hƣởng đến thời gian và chi phí của dự án. Qui trình cần phải hƣớng

đƣợc sự tập trung của mọi nỗ lực trong nhóm dự án đến mục tiêu cuối cùng là một

hệ thống phần mềm đƣợc chấp nhận bởi ngƣời dùng cuối.

Chất lƣợng dịch vụ

Với việc kết hợp thế mạnh nhân sự, công nghệ và cơ sở hạ tầng một cách

chặt chẽ theo qui trình, KMS Technology tiếp tục hoàn thành xuất sắc mục tiêu

mang đến sự hài lòng cao nhất từ phía khách hàng khi hợp tác với KMS

Technology, với mức độ hài lòng đƣợc duy trì ở mức trên 4 (trong thang điểm 5)

trong hai năm liên tiếp 2010 và 2011. Kết quả thăm dò chính thức mức độ hài lòng

của khách hàng đối với các dịch vụ do KMS cung cấp (đƣợc tiến hành theo quí

trong năm 2010, hai lần trong năm 2011) luôn đạt ở mức trên 4 (Tốt). KMS

Technology nhận đƣợc rất nhiều khen ngợi cụ thể cho những đóng góp quan trọng

đến sự thành công của khách hàng.

2.5 Các dự án đã hoàn thành trong năm 2011 và quý I, II năm 2012

2.5.1 Dự án Livescribe

Livescribe là dự án đầu tiên của KMS, ký hợp đồng vào 1/2009. Đây là dự

án phát triển phần mềm cho bút thông minh Livescribe SmartPen.

 Số thành viên: Dự án có 12 thành viên bao gồm một quản lý dự án, 4 nhân

viên đảm bảo chất lƣợng, 7 nhân viên lập trình.

 Thời gian dự án là 2 năm. Từ đầu năm 2012 đến nay, dự án chuyển qua

giai đoạn bảo trì, số thành viên bây giờ là 4.

 Chi phí dự án: KMS và Livescribe ký kết hợp đồng theo giờ, 18 USD/h

(Nguồn: Báo cáo năm 2011 và quý I, II năm 2012, công ty KMS Technology)

cho nhân viên cấp cao (senior), 16 USD/h cho kỹ sƣ.

2.5.2 Dự án HMS (Health Market Science)

Khách hàng HMS là nhà cung cấp hàng đầu về cung cấp dữ liệu, giải pháp

quản lý và thông tin thị trƣờng tại Mỹ. Ban đầu, KMS chỉ thực hiện việc bảo trì cho

những phần mềm đang tồn tại của HMS. Sau 6 tháng sau, nhận thấy KMS đã hoàn

thành tốt việc vá lỗi và đảm bảo chất lƣợng, HMS đã giao luôn việc nâng cấp phần

mềm và phát triển những phần mềm mới cho KMS.

 Số thành viên: ban đầu dự án có 10 thành viên, đến bây giờ đã tăng thành

47 thành viên, chia làm 7 nhóm nhỏ.

 Thời gian dự án: giai đoạn 1 hoàn thành trong 1,5 năm. Từ tháng 6 năm

 Chi phí dự án: KMS và HMS ký kết hợp đồng

2012 đến nay, dự án chuyển qua giai đoạn 2.

theo tháng,

(Nguồn: Báo cáo năm 2011 và quý I, II năm 2012, công ty KMS Technology)

200000USD/tháng.

2.5.3 Dự án MarketLive

MarketLive phần mềm thƣơng mại điện tử giúp các nhà bán lẻ, các nhà tiếp

thị trực tiếp, và các nhà sản xuất bán hàng hóa và các dịch vụ trực tuyến.

 Số thành viên dự án: trong giai đoạn 1 có 43 thành viên, chia làm 4 nhóm

nhỏ (production, upgrade, support, automation).

 Thời gian dự án: giai đoạn 1 hoàn thành trong 1,5 năm. Từ tháng 6 năm

2012 đến nay, dự án chuyển qua giai đoạn 2, nhóm nhỏ upgrade không đƣợc

tiếp tục kí hợp đồng (do đối thủ Ấn Độ cạnh tranh với chi phí thấp hơn). Số

thành viên còn 37 trong giai đoạn 2.

 Chi phí dự án: KMS và MarketLive ký kết hợp đồng theo giờ, 20 USD/h

cho nhân viên cấp cao (senior), 18 USD/h cho kỹ sƣ.

2.5.4 Dự án Alere

Alere là dự án về sức khỏe (healthcare), KMS làm dịch vụ kiểm thử và đảm

bảo chất lƣợng phần mềm. Dự án thực hiện kiểm thử cho các website về quản lý

bệnh nhân sử dụng trong các bệnh viện hay công ty bảo hiểm.

 Số thành viên dự án: có 45 thành viên, chia làm 3 nhóm nhỏ (Wellness

Portal, PCMS, Genentech).

 Thời gian dự án: kéo dài 2 năm. Alere không tiếp tục kí hợp đồng với

KMS khi Alere sử dụng kỹ thuật mới mà KMS không đủ kinh nghiệm trong

kỹ thuật này.

 Chi phí dự án: KMS và Alere cũng ký kết hợp đồng theo giờ, 20 USD/h

(Nguồn: Báo cáo năm 2011 và quý I, II năm 2012, công ty KMS Technology)

cho nhân viên cấp cao (senior), 18 USD/h cho kỹ sƣ.

2.5.5 Dự án Invivodata

Invivodata là cũng dự án về sức khỏe (healthcare), KMS làm dịch vụ kiểm

thử và đảm bảo chất lƣợng phần mềm. Dự án thực hiện kiểm thử cho phần mềm

quản lý bệnh nhân, quá trình điều trị sử dụng trong các bệnh viện. KMS đã giúp

Invivodata tiết kiệm đƣợc 25% chi phí, giảm 50% thời gian thực hiện dự án cho

Invivodata so với khi dự án đƣợc giao cho Falls Church trƣớc đây.

 Số thành viên dự án: có 30 thành viên trong giai đoạn 1

 Thời gian dự án: của giai đoạn 1 kéo dài 8 tháng. Từ tháng 6/2012,

Invivodata tiếp tục ký kết giai đoạn 2 với KMS, tăng số thành viên lên 37.

 Chi phí dự án: KMS và Invivodata cũng ký kết hợp đồng theo giờ, 20

(Nguồn: Báo cáo năm 2011 và quý I, II năm 2012, công ty KMS Technology)

USD/h cho nhân viên cấp cao (senior), 18 USD/h cho kỹ sƣ.

2.6 Tóm tắt chƣơng 2

Chƣơng này đã giới thiệu về công ty KMS Technology Việt Nam, các chiến

lƣợc, nguồn nhân lực của công ty, đồng thời cũng trình bày về các dự án đã hoàn

thành năm 2011 và quý I, II năm 2012.

CHƢƠNG 3 – PHÂN TÍCH KẾT QUẢ KHẢO SÁT

Bằng việc hỏi ý kiến của 30 ngƣời chủ chốt trong công ty theo phƣơng pháp

Delphi, đầu tiên tác giả xác định đƣợc những yếu tố rủi ro ảnh hƣởng đến thành

công của dự án phần mềm, kế đến tóm tắt những yếu tố của mỗi nhóm rủi ro ảnh

hƣởng đến thành công dự án phần mềm và báo cáo kết quả thu thập đƣợc qua mỗi

lần phỏng vấn. Kết quả khảo sát đƣợc trình bày bên dƣới.

3.1 Xác định các yếu tố thuộc nhóm rủi ro về sự quản lý của các thành phần hữu quan

Để xác định những yếutố rủi ro của nhóm này ảnh hƣởng đến thành công dự

án phần mềm, tác giả đã hỏi ý kiến của 30 ngƣời chủ chốt với những thông tin dƣới

đây:

Câu hỏi: “Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về

sự quản lý của các thành phần hữu quan ảnh hƣởng đến thành công dự án phần

mềm?

Nhóm chuyên gia:

• Nhóm 1: 10 ngƣời quản lý dự án chủ chốt (những ngƣời có hơn 5 năm làm

việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, lãnh đạo sự thay

đổi và quản lý dự án).

• Nhóm 2: 10 ngƣời chủ chốt của bộ phận phát triển sản phẩm (những

ngƣời có hơn 5 năm làm việc cho công ty phần mềm, và họ là những kỹ thuật viên

phát triển sản phẩm (developer), các nhà giám sát và quản lý kỹ thuật).

• Nhóm 3: 10 ngƣời quan trọng của QA và BA (những ngƣời có hơn 5 năm

làm việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, và các nhà

quản lý).

Tham khảo danh sách các chuyên gia ở phục lục 3.

Những yếu tố theo bảng 3-1 – vòng 1 đƣợc tác giả thu thập đƣợc sau khi

phỏng vấn mỗi thành viên của nhóm chuyên gia theo phƣơng pháp Delphi

Bảng 3-1: Tóm tắt các yếu tố thuộc nhóm rủi ro về sự quản lý của các thành phần hữu

quan – vòng 1

Số thứ tự

Yếu tố rủi ro

Số ngƣời trả lời 7 4 17 20

1 2 3 4 5

Thiếu cam kết của quản lý cấp cao Văn hóa doanh nghiệp không hỗ trợ sự thành công của dự án Thiếu sự tham gia của ngƣời dùng Khách hàng thiếu trách nhiệm và cam kết Xung đột giữa khách hàng và doanh nghiệp cũng nhƣ xung đột trong nội bộ khách hàng

Qua vòng phỏng vấn đầu tiên, có 5 yếu tố thuộc nhóm rủi ro về sự quản lý

của các thành phần hữu quan đƣợc chỉ ra bởi nhóm chuyên gia. Theo phƣơng pháp

Delphi, để đạt đƣợc sự đồng thuận, tác giả phỏng vấn vòng 2 với câu hỏi sau: “Dựa

vào những yếu tố rủi ro đính kèm được tổng hợp từ tất cả các thành viên, theo

anh/chị, còn có thêm yếu tố rủi ro nào? Và yếu tố rủi ro nào ảnh hưởng đến thành

công dự án?” Câu hỏi này đƣợc tác giả hỏi tất cả các thành viên trong vòng 1 và

thu thập đƣợc kết quả nhƣ bảng dƣới:

Bảng 3-2: Tóm tắt các yếu tố thuộc nhóm rủi ro về sự quản lý của các thành phần hữu

quan – vòng 2

Số thứ tự

Yếu tố rủi ro

Số ngƣời trả lời 5 6 14 27

1 2 3 4 5

Không có yếu tố nào đƣợc nêu thêm ở vòng 2. Tỉ lệ khác biệt giữa vòng 2 và vòng 1

nhƣ bảng sau:

Bảng 3-3: Tỉ lệ khác biệt các yếu tố về sự quản lý của các thành phần hữu quan giữa

vòng 2 và vòng 1

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 1)

Số ngƣời trả lời (vòng 2)

(1)

(2)

Thiếu cam kết của quản lý cấp cao

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1) (3)=100*[(2)- (1)] /(1) 28.57

Văn hóa doanh nghiệp không hỗ trợ sự thành công của dự án Thiếu sự tham gia của ngƣời dùng

17.65

16.67

Khách hàng thiếu trách nhiệm và cam kết Xung đột giữa khách hàng và doanh nghiệp cũng nhƣ xung đột trong nội bộ khách hàng

Không có yếu tố nào đƣợc chấp thuận do tỉ lệ khác biệt đều lớn hơn 10%. Để

đạt đƣợc sự đồng thuận tác giả tiếp tục phỏng vấn vòng 3 với câu hỏi: “Dựa trên

những yếu tố rủi ro ở vòng 1 và vòng 2 (được đính kèm), anh/chị vui lòng chọn

những yếu tố rủi ro chính ảnh hưởng đến thành công dự án phần mềm và cần phải

khắc phục?”. Dữ liệu thu thập ở vòng 3 nhƣ bảng dƣới:

Bảng 3-4: Tóm tắt các yếu tố thuộc nhóm rủi ro về sự quản lý của các thành phần hữu

quan – vòng 3

Số thứ tự

Yếu tố rủi ro

Thiếu cam kết của quản lý cấp cao

Số ngƣời trả lời 0

Văn hóa doanh nghiệp không hỗ trợ sự thành công của dự án

Thiếu sự tham gia của ngƣời dùng

Khách hàng thiếu trách nhiệm và cam kết

Xung đột giữa khách hàng và doanh nghiệp cũng nhƣ xung đột trong nội bộ khách hàng

Có 2 yếu tố không đƣợc chọn ở vòng 3 sau khi thảo luận giữa các thành viên.

Các thành viên đã nhận ra rằng đó không phải là rủi ro chính, ít khi xảy ra hơn các

yếu tố còn lại. Do đó 2 yếu tố này không đƣợc liệt kê trong vòng phỏng vấn tiếp

theo. Tỉ lệ khác biệt giữa vòng 3 và vòng 2 nhƣ bảng sau:

Bảng 3-5: Tỉ lệ khác biệt các yếu tố về sự quản lý của các thành phần hữu quan giữa

vòng 3 và vòng 2

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 2)

Số ngƣời trả lời (vòng 3)

(1)

(2)

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2) (3)=100*[(2)- (1)] /(1) 7.14

3 4

7.41

7.14

Thiếu sự tham gia của ngƣời dùng Khách hàng thiếu trách nhiệm và cam kết Xung đột giữa khách hàng và doanh nghiệp cũng nhƣ xung đột trong nội bộ khách hàng

Không có yếu tố nào có tỉ lệ khác biệt lớn hơn 10%. Nên tác giả tiếp tục

phỏng vấn vòng 4 với câu hỏi: “Anh/chị có thay đổi ý kiến của mình ở vòng 3

không? Nếu có, vui lòng chọn những yếu tố rủi ro mới, nếu không cũng vui lòng

chọn lại những yếu tố đã chọn”. Câu hỏi này cũng đƣợc hỏi tất cả các thành viên

trên và thu đƣợc dữ liệu nhƣ hình dƣới:

Bảng 3-6: Tóm tắt các yếu tố thuộc nhóm rủi ro về sự quản lý của các thành phần hữu

quan – vòng 4

Yếu tố rủi ro

Số thứ tự 1

Thiếu sự tham gia của ngƣời dùng

Số ngƣời trả lời 15

Khách hàng thiếu trách nhiệm và cam kết

Xung đột giữa khách hàng và doanh nghiệp hay trong nội bộ khách hàng

Tỉ lệ khác biệt giữa vòng 4 và vòng 3 nhƣ sau:

Bảng 3-7: Tỉ lệ khác biệt các yếu tố về sự quản lý của các thành phần hữu quan giữa

vòng 4 và vòng 3

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 3)

Số ngƣời trả lời (vòng 4)

(1)

(2)

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3) (3)=100*[(2)- (1)] /(1) 0

1 2

3.45

Thiếu sự tham gia của ngƣời dùng Khách hàng thiếu trách nhiệm và cam kết Xung đột giữa khách hàng và doanh nghiệp cũng nhƣ xung đột trong nội bộ khách hàng

Từ kết quả trên, ta thấy 3 yếu tố rủi ro thuộc nhóm về sự quản lý của các thành phần hữu quan có ảnh hƣởng đến thành công dự án phần mềm với tỉ lệ khác biệt nhƣ sau:

 0.0% cho yếu tố rủi ro thiếu sự tham gia của ngƣời dùng

 3.45% cho yếu tố rủi ro khách hàng thiếu trách nhiệm và cam kết

 0.0% cho yếu tố rủi ro xung đột giữa khách hàng và doanh nghiệp hay trong

nội bộ khách hàng

Bảng bên dƣới tóm tắt tỉ lệ khác biệt của 3 yếu tố trên qua các vòng phỏng vấn nhƣ sau:

Bảng 3-8: Tóm tắt tỉ lệ khác biệt các yếu tố về sự quản lý của các thành phần hữu quan giữa các vòng

Yếu tố rủi ro

Số thứ tự

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1)

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2)

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3)

17.65

7.14

7.41

3.45

16.67

7.14

Thiếu sự tham gia của ngƣời dùng Khách hàng thiếu trách nhiệm và cam kết Xung đột giữa khách hàng và doanh nghiệp cũng nhƣ xung đột trong nội bộ khách hàng

Nhƣ vậy, từ 5 yếu tố đƣợc xác định từ vòng phỏng vấn đầu tiên nhƣ bảng 3-1. Tuy

nhiên chỉ có 3 yếu tố rủi ro ảnh hƣởng đến thành công dự án phần mềm đạt đƣợc sự

đồng thuận của nhóm chuyên gia nhƣ bảng 3-7.

Còn đối với các yếu tố rủi ro nhƣ thiếu cam kết của quản lý cấp cao, văn hóa doanh

nghiệp không hỗ trợ sự thành công của dự án không xảy ra tại công ty KMS vì

KMS là công ty mới, số dự án còn ít nên lãnh đạo công ty rất hỗ trợ cho các dự án

và có tâm huyết xây dựng môi trƣờng làm việc thoải mái, tạo cho nhân viên cảm

giác công ty nhƣ ngôi nhà thứ 2 để họ toàn tâm làm việc.

3.2 Xác định các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình

Để xác định những yếu tố rủi ro của nhóm này ảnh hƣởng đến thành công dự

án phần mềm, tác giả đã hỏi ý kiến của 30 ngƣời chủ chốt với những thông tin dƣới

đây:

Câu hỏi: “Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về

yêu cầu và lịch trình ảnh hƣởng đến thành công dự án phần mềm?

Nhóm chuyên gia:

• Nhóm 1: 10 ngƣời quản lý dự án chủ chốt (những ngƣời có hơn 5 năm làm

việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, lãnh đạo sự thay

đổi và quản lý dự án).

• Nhóm 2: 10 ngƣời chủ chốt của bộ phận phát triển sản phẩm (những ngƣời

có hơn 5 năm làm việc cho công ty phần mềm, và họ là những kỹ thuật viên phát

triển sản phẩm (developer), các nhà giám sát và quản lý kỹ thuật).

• Nhóm 3: 10 ngƣời quan trọng của QA và BA (những ngƣời có hơn 5 năm

làm việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, và các nhà

quản lý).

Tham khảo danh sách các chuyên gia ở phục lục 3.

Những yếu tố theo bảng 3-9 – vòng 1 đƣợc tác giả thu thập đƣợc sau khi

phỏng vấn mỗi thành viên của nhóm chuyên gia theo phƣơng pháp Delphi

Bảng 3-9: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 1

Yếu tố rủi ro

Số thứ tự 1 2 3 4 5 6 7

Truyền thông sai lệch về các yêu cầu của khách hàng Phạm vi, mục tiêu của dự án không rõ ràng Yêu cầu của khách hàng thƣờng xuyên thay đổi Việc quản lý thay đổi không đúng cách Lịch trình và ngân sách không thực tế Hiểu sai yêu cầu của khách hàng Mong muốn của khách hàng không thực tế

Số ngƣời trả lời 11 19 30 17 14 5 13

Yếu tố rủi ro

Số thứ tự 8 9

Thực hiện các công việc phụ thêm ngoài dự án (gold plating) Ƣớc lƣợng lịch trình và chi phí không chính xác

Số ngƣời trả lời 2 21

Qua vòng phỏng vấn đầu tiên, có 9 yếu tố thuộc nhóm rủi ro về yêu cầu và

lịch trình đƣợc chỉ ra bởi nhóm chuyên gia. Theo phƣơng pháp Delphi, để đạt đƣợc

sự đồng thuận, tác giả phỏng vấn vòng 2 với câu hỏi sau: “Dựa vào những yếu tố

rủi ro đính kèm được tổng hợp từ tất cả các thành viên, theo anh/chị, còn có thêm

yếu tố rủi ro nào? Và yếu tố rủi ro nào ảnh hưởng đến thành công dự án?” Câu hỏi

này đƣợc tác giả hỏi tất cả các thành viên trong vòng 1 và thu thập đƣợc kết quả

nhƣ bảng dƣới:

Bảng 3-10: Tóm tắt các yếu tố thuộc nhóm rủi ro về về yêu cầu và lịch trình – vòng 2

Yếu tố rủi ro Số ngƣời trả lời

15 16 30 10 17 10 11

Số thứ tự 1 2 3 4 5 6 7 8 5

9 Truyền thông sai lệch về các yêu cầu của khách hàng Phạm vi, mục tiêu của dự án không rõ ràng Yêu cầu của khách hàng thƣờng xuyên thay đổi Việc quản lý thay đổi không đúng cách Lịch trình và ngân sách không thực tế Hiểu sai yêu cầu của khách hàng Mong muốn của khách hàng không thực tế Thực hiện các công việc phụ thêm ngoài dự án (gold plating) Ƣớc lƣợng lịch trình và chi phí không chính xác 22

Không có yếu tố nào đƣợc nêu thêm ở vòng 2. Tỉ lệ khác biệt giữa vòng 2 và

vòng 1 nhƣ bảng sau:

Bảng 3-11: Tỉ lệ khác biệt các yếu tố về về yêu cầu và lịch trình giữa vòng 2 và vòng 1

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 1)

Số ngƣời trả lời (vòng 2)

(1)

(2)

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1) (3)=100*[( 2)-(1)] /(1) 36.36

Truyền thông sai lệch về các yêu cầu của khách hàng Phạm vi, mục tiêu của dự án không rõ ràng

15.79

3 Yêu cầu của khách hàng thƣờng xuyên

thay đổi

4 Việc quản lý thay đổi không đúng cách

41.18

Lịch trình và ngân sách không thực tế

21.43

6 Hiểu sai yêu cầu của khách hàng

100

7 Mong muốn của khách hàng không thực tế

15.38

150

Thực hiện các công việc phụ thêm ngoài dự án (gold plating)

9 Ƣớc lƣợng lịch trình và chi phí không

4.76

chính xác

Nhƣ vậy, ngoài 2 yếu tố yêu cầu của khách hàng thay đổi và ƣớc lƣợng lịch

trình không chính xác, các yếu tố còn lại không đƣợc chấp thuận do tỉ lệ khác biệt

đều lớn hơn 10%. Để đạt đƣợc sự đồng thuận tác giả tiếp tục phỏng vấn vòng 3 với

câu hỏi: “Dựa trên những yếu tố rủi ro ở vòng 1 và vòng 2 (được đính kèm), anh/chị

vui lòng chọn những yếu tố rủi ro chính ảnh hưởng đến thành công dự án phần

mềm và cần phải khắc phục?”. Dữ liệu thu thập ở vòng 3 nhƣ bảng dƣới:

Bảng 3-12: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 3

Yếu tố rủi ro

Số ngƣời trả lời

Số thứ tự 1 2 3 4 5 6 7

0 17 29 0 17 0 11

Yếu tố rủi ro

Số ngƣời trả lời

Số thứ tự 8

Thực hiện các công việc phụ thêm ngoài dự án (gold plating) Ƣớc lƣợng lịch trình và chi phí không chính xác

Có 4 yếu tố không đƣợc chọn ở vòng 3 sau khi thảo luận giữa các thành viên.

Các thành viên đã nhận ra rằng đó không phải là rủi ro chính, ít khi xảy ra hơn các

yếu tố còn lại. Do đó 4 yếu tố này không đƣợc liệt kê trong vòng phỏng vấn tiếp

theo. Tỉ lệ khác biệt giữa vòng 3 và vòng 2 nhƣ bảng sau:

Bảng 3-13: Tỉ lệ khác biệt các yếu tố về yêu cầu và lịch trình giữa vòng 3 và vòng 2

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 2)

Số ngƣời trả lời (vòng 3)

(1)

(2)

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2) (3)=100*[(2)- (1)] /(1)

6.25

3.33

5 7

9.09

Phạm vi, mục tiêu của dự án không rõ ràng Yêu cầu của khách hàng thƣờng xuyên thay đổi Lịch trình và ngân sách không thực tế Mong muốn của khách hàng không thực tế Ƣớc lƣợng lịch trình và chi phí không chính xác

Không có yếu tố nào có tỉ lệ khác biệt lớn hơn 10%. Nên tác giả tiếp tục

phỏng vấn vòng 4 với câu hỏi: “Anh/chị có thay đổi ý kiến của mình ở vòng 3

không? Nếu có, vui lòng chọn những yếu tố rủi ro mới, nếu không cũng vui lòng

chọn lại những yếu tố đã chọn”. Câu hỏi này cũng đƣợc hỏi tất cả các thành viên

trên và thu đƣợc dữ liệu nhƣ hình dƣới:

Bảng 3-14: Tóm tắt các yếu tố thuộc nhóm rủi ro về yêu cầu và lịch trình – vòng 4

Yếu tố rủi ro

Số thứ tự 1 2

Phạm vi, mục tiêu của dự án không rõ ràng Yêu cầu của khách hàng thƣờng xuyên thay đổi

3 4 5

Lịch trình và ngân sách không thực tế Mong muốn của khách hàng không thực tế Ƣớc lƣợng lịch trình và chi phí không chính xác

Số ngƣời trả lời 16 30 17 11 21

Tỉ lệ khác biệt giữa vòng 4 và vòng 3 nhƣ sau:

Bảng 3-15: Tỉ lệ khác biệt các yếu tố về yêu cầu và lịch trình giữa vòng 4 và vòng 3

Số thứ tự

Yếu tố rủi ro

Số ngƣời trả lời (vòng 3)

Số ngƣời trả lời (vòng 4)

(1)

(2)

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3) (3)=100*[(2) -(1)] /(1)

5.88

3.45

Từ kết quả trên, ta thấy 5 yếu tố rủi ro thuộc nhóm về yêu cầu và lịch trình có ảnh hƣởng đến thành công dự án phần mềm với tỉ lệ khác biệt nhƣ sau:

 5.88% cho yếu tố rủi ro phạm vi, mục tiêu của dự án không rõ ràng

 3.45% cho yếu tố rủi ro yêu cầu của khách hàng thay đổi

 0.0% cho yếu tố rủi ro lịch trình và ngân sách không thực tế

 0.0% cho yếu tố rủi ro mong muốn của khách hàng không thực tế

 5.0% cho yếu tố rủi ro ƣớc lƣợng lịch trình và chi phí không chính xác

Bảng bên dƣới tóm tắt tỉ lệ khác biệt của 5 yếu tố trên qua các vòng phỏng vấn nhƣ sau:

Bảng 3-16: Tóm tắt tỉ lệ khác biệt các yếu tố về yêu cầu và lịch trình giữa các vòng

Yếu tố rủi ro

Số thứ tự

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1)

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2)

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3)

15.79

6.25

5.88

3.33

3.45

Phạm vi, mục tiêu của dự án không rõ ràng Yêu cầu của khách hàng thƣờng xuyên thay đổi Lịch trình và ngân sách không thực tế

21.43

3 4 Mong muốn của khách hàng không thực

15.38

4.76

9.09

tế Ƣớc lƣợng lịch trình và chi phí không chính xác

Nhƣ vậy, từ 9 yếu tố đƣợc xác định từ vòng phỏng vấn đầu tiên nhƣ bảng

3-9. Tuy nhiên chỉ có 5 yếu tố rủi ro ảnh hƣởng đến thành công dự án phần mềm đạt

đƣợc sự đồng thuận của nhóm chuyên gia nhƣ bảng 3-15.

Đối với yếu tố rủi ro nhƣ truyền thông sai lệch về các yêu cầu của khách

hàng, hiểu sai yêu cầu của khách hàng, việc quản lý thay đổi không đúng cách, thực

hiện các công việc phụ thêm ngoài dự án chỉ xảy ở giai đoạn này đó của quá trình

phát triển và điều này sẽ đƣợc khắc phục ngay sau đó, chứ không để đến cuối dự án

nên yếu tố rủi ro này không ảnh hƣởng lớn đến thành công của các dự án ở KMS.

3.3 Xác định các yếu tố thuộc nhóm rủi ro về môi trƣờng phát triển

Để xác định những yếu tố rủi ro của nhóm này ảnh hƣởng đến thành công dự

án phần mềm, tác giả đã hỏi ý kiến của 30 ngƣời chủ chốt với những thông tin dƣới

đây:

Câu hỏi: “Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về

môi trƣờng phát triển ảnh hƣởng đến thành công dự án phần mềm?

Nhóm chuyên gia:

• Nhóm 1: 10 ngƣời quản lý dự án chủ chốt (những ngƣời có hơn 5 năm làm

việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, lãnh đạo sự thay

đổi và quản lý dự án).

• Nhóm 2: 10 ngƣời chủ chốt của bộ phận phát triển sản phẩm (những ngƣời

có hơn 5 năm làm việc cho công ty phần mềm, và họ là những kỹ thuật viên phát

triển sản phẩm (developer), các nhà giám sát và quản lý kỹ thuật).

• Nhóm 3: 10 ngƣời quan trọng của QA và BA (những ngƣời có hơn 5 năm

làm việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, và các nhà

quản lý).

Tham khảo danh sách các chuyên gia ở phục lục 3.

Những yếu tố theo bảng 3-17 – vòng 1 đƣợc tác giả thu thập đƣợc sau khi

phỏng vấn mỗi thành viên của nhóm chuyên gia theo phƣơng pháp Delphi

Bảng 3-17: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 1

Yếu tố rủi ro

Số thứ tự 1 2 3 4

Hiệu quả làm việc của bên thứ 3 (third party) Cạnh tranh làm thay đổi lịch trình Thay đổi phạm vi do thay đổi mô hình kinh doanh Thiên tai

Số ngƣời trả lời 3 24 9 13

Qua vòng phỏng vấn đầu tiên, có 5 yếu tố thuộc nhóm rủi ro về môi trƣờng

phát triển đƣợc chỉ ra bởi nhóm chuyên gia. Theo phƣơng pháp Delphi, để đạt đƣợc

sự đồng thuận, tác giả phỏng vấn vòng 2 với câu hỏi sau: “Dựa vào những yếu tố

rủi ro đính kèm được tổng hợp từ tất cả các thành viên, theo anh/chị, còn có thêm

yếu tố rủi ro nào? Và yếu tố rủi ro nào ảnh hưởng đến thành công dự án?” Câu hỏi

này đƣợc tác giả hỏi tất cả các thành viên trong vòng 1 và thu thập đƣợc kết quả

nhƣ bảng dƣới:

Bảng 3-18: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 2

Yếu tố rủi ro

Số thứ tự 1 2 3 4

Hiệu quả làm việc của bên thứ 3 (third party) Cạnh tranh làm thay đổi lịch trình Thay đổi phạm vi do thay đổi mô hình kinh doanh Thiên tai

Số ngƣời trả lời 4 28 13 23

Không có yếu tố nào đƣợc nêu thêm ở vòng 2. Tỉ lệ khác biệt giữa vòng 2 và

vòng 1 nhƣ bảng sau:

Bảng 3-19: Tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa vòng 2 và vòng 1

Yếu tố rủi ro

Số ngƣời trả lời (vòng 1)

Số ngƣời trả lời (vòng 2)

Số thứ tự

(1)

(2)

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1) (3)=100*[(2)- (1)] /(1) 33.33

Hiệu quả làm việc của bên thứ 3 (third party) Cạnh tranh làm thay đổi lịch trình

16.67

44.44

Thay đổi phạm vi do thay đổi mô hình kinh doanh Thiên tai

76.92

Không có yếu tố nào đƣợc chấp thuận do tỉ lệ khác biệt đều lớn hơn 10%. Để

đạt đƣợc sự đồng thuận tác giả tiếp tục phỏng vấn vòng 3 với câu hỏi: “Dựa trên

những yếu tố rủi ro ở vòng 1 và vòng 2 (được đính kèm), anh/chị vui lòng chọn

những yếu tố rủi ro chính ảnh hưởng đến thành công dự án phần mềm và cần phải

khắc phục?”. Dữ liệu thu thập ở vòng 3 nhƣ bảng dƣới:

Bảng 3-20: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 3

Yếu tố rủi ro

Số thứ tự 1

Hiệu quả làm việc của bên thứ 3 (third party)

Số ngƣời trả lời 0

Cạnh tranh làm thay đổi lịch trình

Thay đổi phạm vi do thay đổi mô hình kinh doanh

Thiên tai

Có 3 yếu tố không đƣợc chọn ở vòng 3 sau khi thảo luận giữa các thành viên.

Các thành viên đã nhận ra rằng đó không phải là rủi ro chính, ít khi xảy ra hơn yếu

tố còn lại. Do đó 3 yếu tố này không đƣợc liệt kê trong vòng phỏng vấn tiếp theo.

Tỉ lệ khác biệt giữa vòng 3 và vòng 2 nhƣ bảng sau:

Bảng 3-21: Tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa vòng 3 và vòng 2

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 2)

Số ngƣời trả lời (vòng 3)

(1)

(2)

Cạnh tranh làm thay đổi lịch trình

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2) (3)=100*[(2)- (1)] /(1) 7.14

Không có yếu tố nào có tỉ lệ khác biệt lớn hơn 10%. Nên tác giả tiếp tục

phỏng vấn vòng 4 với câu hỏi: “Anh/chị có thay đổi ý kiến của mình ở vòng 3

không? Nếu có, vui lòng chọn những yếu tố rủi ro mới, nếu không cũng vui lòng

chọn lại những yếu tố đã chọn”. Câu hỏi này cũng đƣợc hỏi tất cả các thành viên

trên và thu đƣợc dữ liệu nhƣ hình dƣới:

Bảng 3-22: Tóm tắt các yếu tố thuộc nhóm rủi ro về môi trường phát triển – vòng 4

Số ngƣời trả lời 30 Số thứ tự 1 Yếu tố rủi ro Cạnh tranh làm thay đổi lịch trình

Tỉ lệ khác biệt giữa vòng 4 và vòng 3 nhƣ sau:

Bảng 3-23: Tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa vòng 4 và vòng 3

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 3)

Số ngƣời trả lời (vòng 4)

(1)

(2)

Cạnh tranh làm thay đổi lịch trình

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3) (3)=100*[(2)- (1)] /(1) 0

Từ kết quả trên, ta thấy 1 yếu tố rủi ro thuộc nhóm về môi trƣờng phát triển có ảnh hƣởng đến thành công dự án phần mềm với tỉ lệ khác biệt nhƣ sau:

 0.0% cho yếu tố rủi ro cạnh tranh làm thay đổi lịch trình

Bảng bên dƣới tóm tắt tỉ lệ khác biệt của yếu tố trên qua các vòng phỏng vấn nhƣ sau:

Bảng 3-24: Tóm tắt tỉ lệ khác biệt các yếu tố về môi trường phát triển giữa các vòng

Yếu tố rủi ro

Số thứ tự

Cạnh tranh làm thay đổi lịch trình

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1) 16.67

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2) 7.14

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3) 0

Nhƣ vậy, từ 4 yếu tố đƣợc xác định từ vòng phỏng vấn đầu tiên nhƣ bảng 3-

3-17. Tuy nhiên chỉ có 1 yếu tố rủi ro ảnh hƣởng đến thành công dự án phần mềm

đạt đƣợc sự đồng thuận của nhóm chuyên gia nhƣ bảng 3-23.

Đối với các yếu tố rủi ro nhƣ hiệu quả làm việc của bên thứ 3, thiên tai, thay

đổi phạm vi do thay đổi mô hình kinh doanh không xảy ra cho các dự án đã hoàn

thành tại KMS.

3.4 Xác định các yếu tố thuộc nhóm rủi ro về quản lý dự án

Để xác định những yếu tố rủi ro của nhóm này ảnh hƣởng đến thành công dự

án phần mềm, tác giả đã hỏi ý kiến của 30 ngƣời chủ chốt với những thông tin dƣới

đây:

Câu hỏi: “Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về

quản lý dự án ảnh hƣởng đến thành công dự án phần mềm?

Nhóm chuyên gia:

• Nhóm 1: 10 ngƣời quản lý dự án chủ chốt (những ngƣời có hơn 5 năm làm

việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, lãnh đạo sự thay

đổi và quản lý dự án).

• Nhóm 2: 10 ngƣời chủ chốt của bộ phận phát triển sản phẩm (những ngƣời

có hơn 5 năm làm việc cho công ty phần mềm, và họ là những kỹ thuật viên phát

triển sản phẩm (developer), các nhà giám sát và quản lý kỹ thuật).

• Nhóm 3: 10 ngƣời quan trọng của QA và BA (những ngƣời có hơn 5 năm

làm việc cho công ty phần mềm, và họ là đội ngũ lãnh đạo, giám sát, và các nhà

quản lý).

Tham khảo danh sách các chuyên gia ở phục lục 3.

Những yếu tố theo bảng 3-25 – vòng 1 đƣợc tác giả thu thập đƣợc sau khi

phỏng vấn mỗi thành viên của nhóm chuyên gia theo phƣơng pháp Delphi

Bảng 3-25: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 1

Yếu tố rủi ro

Số ngƣời trả lời 25 16 19 30 30 30 30

Số thứ tự 1 2 3 4 5 6 7 8

Lập kế hoạch không đầy đủ Thiếu phƣơng pháp quản lý dự án Sử dụng kỹ thuật mới Thiếu phân công trách nhiệm rõ ràng Thiếu kiến thức về kỹ thuật Phân bố nhân sự không phù hợp Nhân viên nghỉ việc Thiếu sự cam kết của các thành viên thực hiện dự án

9 10

Thiếu công cụ đo lƣờng sự tin cậy Thiếu công cụ để xác nhận và kiểm thử

Qua vòng phỏng vấn đầu tiên, có 10 yếu tố thuộc nhóm rủi ro về quản lý dự

án đƣợc chỉ ra bởi nhóm chuyên gia. Theo phƣơng pháp Delphi, để đạt đƣợc sự

đồng thuận, tác giả phỏng vấn vòng 2 với câu hỏi sau: “Dựa vào những yếu tố rủi

ro đính kèm được tổng hợp từ tất cả các thành viên, theo anh/chị, còn có thêm yếu

tố rủi ro nào? Và yếu tố rủi ro nào ảnh hưởng đến thành công dự án?”. Câu hỏi

này đƣợc tác giả hỏi tất cả các thành viên trong vòng 1 và thu thập đƣợc kết quả

nhƣ bảng dƣới:

Bảng 3-26: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 2

Yếu tố rủi ro

Số ngƣời trả lời 26 18 20 29 30 30 30 18 10

Số thứ tự 1 2 3 4 5 6 7 8 9 10

Không có yếu tố nào đƣợc nêu thêm ở vòng 2. Tỉ lệ khác biệt giữa vòng 2 và

vòng 1 nhƣ bảng sau:

Bảng 3-27: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 2 và vòng 1

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 1)

Số ngƣời trả lời (vòng 2)

(1)

(2)

25 16 19 30 30 30 30

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1) (3)=100*[(2) -(1)] /(1) 4 12.5 5.26 3.33 0 0 0

26 18 20 29 30 30 30

1 2 3 4 5 6 7 8

12.5

42.86

9 10

44.44

Ngoài các yếu tố: lập kế hoạch không đầy đủ, sử dụng kỹ thuật mới, thiếu

phân công trách nhiệm rõ ràng, thiếu kiến thức về kỹ thuật, nhân sự không thích

hợp, nhân viên nghỉ việc, các yếu tố còn lại không đƣợc chấp thuận do tỉ lệ khác

biệt đều lớn hơn 10%. Để đạt đƣợc sự đồng thuận tác giả tiếp tục phỏng vấn vòng 3

với câu hỏi: “Dựa trên những yếu tố rủi ro ở vòng 1 và vòng 2 (được đính kèm),

anh/chị vui lòng chọn những yếu tố rủi ro chính ảnh hưởng đến thành công dự án

phần mềm và cần phải khắc phục?” Dữ liệu thu thập ở vòng 3 nhƣ bảng dƣới:

Bảng 3-28: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 3

Yếu tố rủi ro

Số ngƣời trả lời 27 17 22 28 29 30 30

Số thứ tự 1 2 3 4 5 6 7 8

9 10

Thiếu công cụ đo lƣờng sự tin cậy Thiếu công cụ để xác nhận và kiểm thử

Có 2 yếu tố không đƣợc chọn ở vòng 3 sau khi thảo luận giữa các thành viên.

Các thành viên đã nhận ra rằng đó không phải là rủi ro chính, ít khi xảy ra hơn các

yếu tố còn lại. Do đó 2 yếu tố này không đƣợc liệt kê trong vòng phỏng vấn tiếp

theo. Tỉ lệ khác biệt giữa vòng 3 và vòng 2 nhƣ bảng sau:

Bảng 3-29: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 3 và vòng 2

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 2)

Số ngƣời trả lời (vòng 3)

(1)

(2)

26 18 20

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2) (3)=100*[ (2)-(1)] /(1) 3.85 5.56 10

27 17 22

1 2 3 4

3.45

30 30 30

3.33 0 0

29 30 30

5 6 7 8

5.56

Không có yếu tố nào có tỉ lệ khác biệt lớn hơn 10%. Nên tác giả tiếp tục

phỏng vấn vòng 4 với câu hỏi: “Anh/chị có thay đổi ý kiến của mình ở vòng 3

không? Nếu có, vui lòng chọn những yếu tố rủi ro mới, nếu không cũng vui lòng

chọn lại những yếu tố đã chọn”. Câu hỏi này cũng đƣợc hỏi tất cả các thành viên

trên và thu đƣợc dữ liệu nhƣ hình dƣới:

Bảng 3-30: Tóm tắt các yếu tố thuộc nhóm rủi ro về quản lý dự án – vòng 4

Yếu tố rủi ro

Số thứ tự 1 2 3 4 5 6 7 8

Số ngƣời trả lời 28 17 21 28 28 30 30 18

Tỉ lệ khác biệt giữa vòng 4 và vòng 3 nhƣ sau:

Bảng 3-31: Tỉ lệ khác biệt các yếu tố về quản lý dự án giữa vòng 4 và vòng 3

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 3)

Số ngƣời trả lời (vòng 4)

(1)

(2)

27 17 22 28 29 30 30

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3) (3)=100*[(2)- (1)] /(1) 3.7 0 4.55 0 3.45 0 0

28 17 21 28 28 30 30

1 2 3 4 5 6 7 8

5.88

Từ kết quả trên, ta thấy 8 yếu tố rủi ro thuộc nhóm về quản lý dự án có ảnh hƣởng

đến thành công dự án phần mềm với tỉ lệ khác biệt nhƣ sau:

 3.7% cho yếu tố rủi ro lập kế hoạch không đầy đủ

 0.0% cho yếu tố rủi ro thiếu phƣơng pháp quản lý dự án

 4.55% cho yếu tố rủi ro sử dụng kỹ thuật mới

 0.0% cho yếu tố rủi ro thiếu phân công trách nhiệm rõ ràng

 3.45% cho yếu tố rủi ro thiếu kiến thức về kỹ thuật

 0.0% cho yếu tố rủi ro nhân sự không thích hợp

 0.0% cho yếu tố rủi ro nhân viên nghỉ việc

 5.88% cho yếu tố rủi ro thiếu sự cam kết của nhóm dự án

Bảng bên dƣới tóm tắt tỉ lệ khác biệt của 8 yếu tố trên qua các vòng phỏng vấn nhƣ sau:

Bảng 3-32: Tóm tắt tỉ lệ khác biệt các yếu tố về quản lý dự án giữa các vòng

Yếu tố rủi ro

Số thứ tự

Tỉ lệ khác biệt (giữa vòng 2 và vòng 1) 4 12.5 5.26

Tỉ lệ khác biệt (giữa vòng 3 và vòng 2) 3.85 5.56 10

Tỉ lệ khác biệt (giữa vòng 4 và vòng 3) 3.7 0 4.55

1 2 3 4

3.33

3.45

0 0 0

3.33 0 0

3.45 0 0

5 6 7 8

12.5

5.56

5.88

Nhƣ vậy, từ 10 yếu tố đƣợc xác định từ vòng phỏng vấn đầu tiên nhƣ bảng 3-25.

Tuy nhiên chỉ có 8 yếu tố rủi ro ảnh hƣởng đến thành công dự án phần mềm đạt

đƣợc sự đồng thuận của nhóm chuyên gia nhƣ bảng 3-31.

Còn đối với các yếu tố rủi ro nhƣ thiếu công cụ đo lƣờng sự tin cậy, thiếu

công cụ để xác nhận và kiểm thử không xảy ra tại công ty KMS vì KMS là đối tác

vàng của Microsoft, tự phát triển các sản phẩm để hỗ trợ cho việc kiểm thử, quản lý

yêu cầu phần mềm (nhƣ sản phẩm qTrace, qTest đang đƣợc bán ra thị trƣờng) nên

rủi ro liên quan đến công cụ kiểm thử không là vấn đề ở KMS.

Bảng 3-33: Tóm tắt các yếu tố rủi ro được xác định

Số thứ tự

Nhóm rủi ro

Yếu tố rủi ro đƣợc xác định

1 Nhóm rủi ro về sự quản lý của các thành phần hữu quan

Thiếu sự tham gia của ngƣời dùng Khách hàng thiếu trách nhiệm và cam kết Xung đột giữa khách hàng và doanh nghiệp cũng nhƣ xung đột trong nội bộ khách hàng

2 Nhóm về yêu cầu và lịch trình

Phạm vi, mục tiêu của dự án không rõ ràng Yêu cầu của khách hàng thay đổi Lịch trình và ngân sách không thực tế Mong muốn của khách hàng không thực tế Ƣớc lƣợng lịch trình và chi phí không chính xác

Cạnh tranh làm thay đổi lịch trình

3 Nhóm về môi trƣờng phát triển dự án

4 Nhóm về quản lý dự án

3.5 Tóm tắt chƣơng 3

Thông qua khảo sát ý kiến của các thành viên chủ chốt theo phƣơng pháp Delphi, có nhiều yếu tố rủi ro đƣợc xác định ở vòng đầu tiên. Tuy nhiên, qua 3 vòng phỏng vấn, 17 yếu tố đƣợc xem là quan trọng ảnh hƣởng đến thành công của dự án phần mềm tại công ty KMS Technology Việt Nam.

KẾT LUẬN

4.1 Kiến nghị

Dựa trên những yếu tố rủi ro đã đƣợc xác định ở bảng 3-4-9, bằng kiến thức

đã học và việc thảo luận với các thành viên chủ chốt, tác giả đề xuất những kiến

nghị nhằm hạn chế những rủi ro và tăng tỉ lệ thành công dự án trong tƣơng lai cho

công ty.

 Đối với rủi ro về việc thiếu sự tham gia của ngƣời dùng: phải

thƣờng xuyên lấy ý kiến ngƣời dùng về phần mềm đang phát triển.

 Đối với rủi ro về việc khách hàng không thực hiện cam kết, xung

đột với khách hàng: Giám đốc dự án cần nâng cao kỹ năng mềm và biết tận dụng

sự hỗ trợ của khách hàng, đặc biệtlà sự hợp tác của khách hàng với đội dự án. Bên

cạnh đó, giám đốc dự án cũng phải trang bị cho mình khả năng giữ liên lạc với

khách hàng. Đây là điều quyết định đối với mối quan hệ với đối tác.

 Đối với rủi ro về không dành thời gian để xác định rõ phạm vi dự

án: Lên kế hoạch dự án tốt cần xác định tình trạng của vấn đề và phạm vi dự án.

Giám đốc dự án cần thông tin liên lạc về dự án với mọi ngƣời liên quan. Họ có thể

sẽ phát hiện ra những hiểu lầm về phạm vi của dự án hay những yêu cầu nảy sinh

của hệ thống khi bộ phận công nghệ thông tin chuyển biểu giải trình về công việc

với hàng nghìn dòng mô tả chức năng và đặc tính của hệ thống. Việc thử nghiệm

cũng rất quan trọng đối với sự thành công của dự án, đặc biệt khi dự án sắp hoàn

thành.

 Đối với rủi ro về thay đổi yêu cầu dự án: Nên theo chu trình yêu

cầu thay đổi chính thức: Các cá nhân nếu có yêu cầu thay đổi cần giải thích những

thay đổi cụ thể bằng văn bản thay đổi phạm vi, và nhà quản lý dự án cần xác định

yêu cầu này sẽ có tác động nhƣ thế nào đến ngân sách và thời hạn. Nhà đầu tƣ phải

ký xác nhận yêu cầu thay đổi phạm vi này. Phải thƣờng xuyên liên lạc với khách

hàng và tìm hiểu kỹ yêu cầu của khách hàng. Lập ra các biểu mẫu để có thể dễ dàng

quản lý các yêu cầu khách hàng đƣa ra.

 Đối với rủi ro về ƣớc lƣợng lịch trình và chi phí không chính xác:

Kiểm tra, đánh giá trong mỗi giai đoạn của dự án là một phƣơng pháp để đảm bảo

thành công dự án.

 Đối với rủi ro về thiếu những nhân viên có chuyên môn phù hợp:

Những nhà quản lý dự án và CNTT cần một cái nhìn toàn diện về chuyên môn và

khối lƣợng công việc của tất cả nguồn lực, bao gồm cả các tƣ vấn viên, nhà thầu, và

những công ty đối tác. Họ thƣờng lơ là trong việc đánh giá chuyên môn của những

nguồn nhân lực này mặc dù họ đảm nhiệm phần lớn công việc. Phần mềm quản lý

dự án có thể mang lại cái nhìn tổng quan về chuyên môn và khối lƣợng công việc

của mỗi bên tham gia. Khi các nhà quản lý dự án và công nghệ thông tin hiểu rõ

công việc của từng ngƣời, họ phải tìm ra đƣợc cách phân bổ các nguồn nhân lực

trong các dự án và lƣợng công việc hàng ngày. Nên đồng bộ hóa nhân viên và dự án

hết sức có thể. Một giải pháp hữu hiệu là bổ nhiệm một ngƣời quản lý nguồn nhân

lực, ngƣời này sẽ chịu trách nhiệm chỉ định nhân viên cho mỗi dự án và đảm bảo

phân bổ nhân viên phù hợp với các dự án.

 Đối với rủi ro về thiếu những nhà quản lý dự án có kinh nghiệm:

thuê những nhà quản lý dự án có bằng cấp và khả năng theo yêu cầu để quản lý các

thành phần tham gia. Một nhà quản lý dự án giỏi phải có nhiều khả năng. Họ cần

phải biết cách tổ chức các cuộc họp, xử lý rủi ro, và quản lý nhiều thành phần khác

nhau – nhân viên lập trình, nhân viên đảm bảo chất lƣợng, và nhân viên phân tích

yêu cầu. Một nhà quản lý dự án kinh nghiệm cũng cần thành thạo bất kỳ công nghệ

nào đang đƣợc triển khai. Tăng cƣờng đào tạo, giám sát, huấn luyện và chia sẻ kinh

nghiệm trong nội bộ công ty. Công ty có thể tổ chức những khóa đào tạo cho các

trƣởng nhóm, những ngƣời sẽ trở thành quản lý dự án trong tƣơng lai, nhƣ là một

cách chuẩn bị những nhà quản lý tốt. Theo dõi kết quả đánh giá đào tạo nhân viên.

 Đối với rủi ro về phƣơng pháp quản lý dự án: một phƣơng pháp

quản lý dự án giúp tiến hành dự án hiệu quả và giúp nhà quản lý nhận thức đƣợc các

hoạt động liên quan đến việc tiến hành dự án. Xác định đúng ranh giới của tiêu

chuẩn và phƣơng pháp sẽ loại bỏ các rủi ro liên quan đến các dự án công nghệ

thông tin.

 Đối với rủi ro về thiếu kiến thức về kỹ thuật: Đầu tƣ cho bộ phận

nghiên cứu và phát triển, điều này giúp doanh nghiệp nắm bắt, dự đoán những thay

đổi về công nghệ, để có chiến lƣợc giúp thích nghi với những thay đổi đó.

 Đối với rủi ro về thiếu sự cam kết của các thành viên thực hiện dự

án: Vạch ra hƣớng phát triển sự nghiệp rõ ràng cho từng nhân viên, để nhân viên cố

gắng phấn đấu đê đạt đƣợc mục tiêu sự nghiệp của mình. Giao tiếp cởi mở trong

công ty và trong dự án, điều này không những khuyến khích nhân viên làm việc mà

còn giảm rủi ro bất hợp tác giữa các thành viên.

4.2 Hạn chế và gợi ý cho các nghiên cứu tiếp theo

Trƣớc tiên đề tài này chỉ thực hiện trong phạm vi công ty KMS Technology

theo phƣơng pháp Delphi. Theo kinh nghiệm của các nhà nghiên cứu thì phƣơng

pháp này cũng có những khuyết điểm nhất định. Tuy nhiên giá trị của nghiên cứu sẽ

đƣợc nâng cao hơn nữa nếu nhƣ thực hiện trên toàn địa bàn thành phố Hồ Chí Minh

hay các thành phố lớn khác trên lãnh thổ Việt Nam nhƣ Hà Nội, Cần Thơ, Đà

Nẵng… với số lƣợng chuyên gia lớn hơn để có thể mang lại mức độ đại diện đƣợc

cao hơn. Đây cũng là một gợi ý cho các nghiên cứu tiếp sau.

Thứ hai, đây là một đề tài định tính, nó chỉ xác định đƣợc các yếu tố rủi ro,

không cho thấy mức độ tác động của các yếu tố này lên sự thành công của dự án

nhƣ thế nào để thông qua đó doanh nghiệp cần chú trọng giảm thiểu rủi ro nào

nhằm tăng tỉ lệ thành công của dự án. Đây cũng là hƣớng gợi ý cho các nghiên cứu

tiếp theo.

Cuối cùng, nghiên cứu chỉ xác định các yếu tố rủi ro bất lợi ảnh hƣởng đến

thành công dự án. Còn nhiều yếu tố rủi ro thuận lợi khác cũng ảnh hƣởng đến thành

công dự án…. Đây cũng là hƣớng gợi ý cho các nghiên cứu tiếp theo.

TÀI LIỆU THAM KHẢO

Tài liệu tiếng Việt

1. Lê Huy Tùng (2011), “Ảnh hưởng của sự thỏa mãn thù lao đến sự gắn kết với tổ chức của nhân viên văn phòng tại địa bàn thành phố Hồ Chí Minh”, luận văn thạc sĩ, Trƣờng Đại học Kinh tế Tp HCM.

Tài liệu tiếng Anh

2. Agarwal, N., and Rathod, E.U.(2005), Defining Success for Software

Projects: An Exploratory Revelation, The Journal of Systems and Software, vol. 24.

3. Baar, B.D.(2006), Surprise, now you’re a software project manager, Multi-

media publication Inc..

4. Baccarini, D., Salm, G., and Love, P.E.D.(2004), Management of risks in information technology projects, Industrial Management & Data Systems, Vol. 104, No. 4, pp. 286-295.

5. Baker, B. N., Murphy, D. C., and Fisher, D. (2008), Factors affecting project success, Project Management Handbook, second edition, New York: Van Nostrand Reinhold, pp. 902 – 909.

6. Bannerman, P.L. (2008), Risk and risk management in software projects: A reassessment , The Journal of Systems and Software, vol. 81, pp. 2118-2133.

7. Barki, H., Rivard, S., and Talbot, J.(2003), Toward an Assessment of

Software Development Risk, Journal of MIS, vol. 10, no. 2, pp. 203-225. 8. Boehm, B.W. (1991), Software risk management principles and practices,

IEEE Software, Vol. 8, no. 1, pp.32–41.

9. Boehm, B.W.(1989), Organizational Climate and Culture (ed.), Jossey-Bass,

CA.

10. Brooks, Jr., F.P. (1986), No Silver Bullet—Essence and Accidents of Software Engineering, Information Processing, vol. 86, pp. 1069-1076. 11. Chan, Albert P.C. et.al (2001), Application of Delphi Method in Selection of Procurement Systems for Construction Projects, Construction Management and Economics.

12. Clayton, Mark J (Dec 1997), Reengineering Delphi: A Technique to Harness

Expert Opinion, Educational Psychology.

13. Dawson, Matt D and Brucker, Penny S (2001), The Utility of the Delphi

Method in MFT Research,The American Journal of Family Therapy, p132- 134.

14. Des Marchais, Jacques E (July 1999), A Delphi technique to identify and evaluate criteria for construction of PBL problems, Medical Education, 33:504 p504

15. Engel, A., and Last, M. (2007), Modeling software testing costs and risks using fuzzy logic paradigm, Journal of Systems and Software, vol. 80, no.6, pp. 817-835.

16. Field, T. (2007), When BAD things Happen to GOOD projects, CIO, pp. 55-

62.

17. Galorath, D.D., and Evans, M.W.(2006), Software Sizing Estimation and Risk Management, Auerbach Publications, United States of America, pp. 339-393.

18. Gefen, D., Wyss, S., and Lichtenstein, Y.(2008), Business Familiarity as Risk Mitigation in Software Development Outsourcing Contracts, MIS Quarterly, vol. 32, no. 3, pp. 531-551.

19. Gerbing & Anderson (1988), An Update Paradigm for Scale Development Incorporing Unidimensionality and Its Assessments, Journal of Marketing Research, Vol.25, Page 186-192

20. Han. W.M., and Huang, S.J. (2007), An empirical analysis of risk

components and performance on software projects, Journal of systems and software, vol. 80, no. 1, pp. 42-50

21. Hasson, Felicity et.al (2000), Research Guidelines for the Delphi Survey

Technique, Journal of Advanced Nursing.

22. Higuera, R. and Haimes Y. (2006), Software Risk Management, Carnegie

Mellon University, Software Engineering Institute.

23. Iacovou, C.L., and Nakatsu, R.(2008), A risk profile of offshore-

outsourced development projects, Communications of the ACM, vol. 51, no. 6, pp.89-94.

24. Jiang, J., and Klein, G.(2001), Software project risks and development

focus, Project Management Journal, vol. 32, no. 1, pp. 20-26.

25. Jones, C. (1993), Assessment and Control of Software Risks, Prentice-Hall,

Englewood Cliffs, NJ.

26. Keil, M., Cule, P., Lyytinen, K., and Schmidt, R. (1998), A framework for identifying software project risks, Communications of the ACM, vol. 41, no.11, pp. 76-83.

27. Kerr, Malcom (November 2001), The Delphi Process, Rarari Internet Site

http://www.rararibids.org.uk

28. Krasner, H.(1998), Looking over the legal edge of unsuccessful software

projects, Cutter IT Journal, vol. 11, no. 3, pp. 11-22.

29. Kwak, Y.H., and Stoddard, J. (2004), Project risk management: lessons learned from software development environment, Technovation, Vol. 24, pp. 915-920.

30. Le Van Quyen (2011), How to improve production productivity, case study

Tribeco JSC, MBA thesis at CFVG Viet Nam

31. Lindstone, Harold A. and Turoff, Murray, The Delphi Method: Techniques

and Applications, Listed on http://www.is.njit.edu/pubs/delphibook. p 615.

32. Ludwig, Barbara (October 1997), Predicting the Future: Have you

considered using the Delphi Methodology, Journal of Extension 35.

33. Mangione. C.( 2008), Software Project Failure: the Reasons, the Costs,

CIO Updates, http://www.cioupdate.com/reports/article.php/1563701/Software-Project- Failure-The-Reasons-The-Costs.htm.

34. Masticola S.P.(2007), A simple estimate of the cost of software project

failures and the breakeven effectiveness of project risk management, First international workshop on the economics of software and computation, IEEE.

35. McFarlan, W. (1982), Portfolio Approach to Information Systems,

Journal of Systems Management, vol. 33, no. 1, pp.12–19.

36. McLeod, G. and Smith, D.(2006), Managing IT Projects, Boyd and

Fraser Publishing, Massachusetts.

37. Mitchel, V.W, (1991), The Delphi Technique: An Exposition and Application, Technology Analysis & Strategic Management. 38. Pan, J. (2010), Software Reliability, Carnegie Mellon University,

http://businessffwdblog.com/?m=200909.

39. Purao, S., Paul, S., and Smith, S. (2007), Understanding enterprise

integration project risks: A focus group study, 18th International Workshop on Database and Expert Systems Applications, pp. 850-854.

40. Rasmussen, M., Orlov, L.M., and Bright, S. (2007), Taking Control Of IT Risk Defining A Comprehensive IT Risk Management Strategy, Forrester Research.

41. Reel, J.S.(1999), Critical success factors in Software Projects, IEEE

Software, May – June, 18-23.

42. Ropponen J., and Lyytinen K.(2000), Components of Software Development Risk: what influences it- a project manager survey, IEEE Transactions on Software Engineering, vol. 26, no. 2, pp. 98-112.

43. Sakthivel, S. (2007), Managing Risk in Offshore Systems Development,

Communications of the ACM, vol. 50, no. 4, pp.69-75.

44. Sam Thomas (2010), Software Development Project Risk, Project Success

And Their Inter-Relationship, Kochi - 682 022, page 120-125 45. Schmidt, R., Lyytinen, K., Keil, M., and Cule, P.(2001), Identifying software project risks: An international Delphi study, Journal of Management Information Systems, vol. 17, no. 4, pp. 5-36.

46. Sharma, A., Gupta, A. and Khilnani, D. (2008), Identification and Ranking

of Software Project Risks, Asia Pacific Business Review, Vol. 4(2), 116-122.

47. Smite, D.(2006), Requirements Management in Distributed Projects,

Journal of Universal Knowledge Management, vol. 1, no. 2, pp. 69-76.

48. Smith, D., Eastcroft, M., Mahmood, N., and Rode, H.(2006), Risk

factors affecting software projects in South Africa, South African Journal of Business Management, vol. 37, no. 2, pp.55-65.

49. Spinelli, Teri (1983), The Delphi Decision-Making Process, The Journal of

Psychology, 113:73-80. p74

50. Standish report - CHAOS Summary 2009,

http://www1.standishgroup.com/newsroom/chaos_2009.php.

51. Thomas, G. and Fernandez, W. (2008), Success in IT Projects: A Matter of Definition?, International Journal of Project Management, vol. 26, pp. 733- 742.

52. Thomsett, R. (1995), Project Pathology: Causes, Patterns and Symptoms of

Project Failure Training Notes Project Risk Management, Thomsett Company, London.

53. Turner J.R. and Muller R. (2003), On the nature of the project as a

temporary organization, International Journal of Project Management, vol. 21, pp.1-8.

54. Turner J.R. (2009), Project Management: a profession based on

knowledge or faith, International Journal of Project Management, vol. 17, no. 6, pp. 329-342.

55. Wallace, L., Keil, M., and Rai, A. (2004), How software project risk affects project performance: an investigation of the dimensions of risk and an exploratory model, Decision Sciences, vol. 35, no. 2, pp. 289-321.

56. Wateridge, J. (1998), How Can IS/IT Projects Be Measured For Success?, International Journal of Project Management, vol.16, no. 1, pp. 59- 63 57. Watts, N. (2010), The Triple Constraints of project management,

Business FFWD, http://businessffwdblog.com/?m=200909.

58. Webster’s New International Dictionary 2nd Edition Unabridged. G&C

Merriam Company, Springfield Mass, 1934.

59. Williams, Patricia L. and Webb, Christine (1994), The Delphi Technique: A

Methodological Discussion, Journal of Advanced Nursing

60. Zhou, L., Vasconcelos, A., and Nunes, M.(2008), Supporting decision

making in risk management through an evidence-based information systems project risk checklist, Information Management and Computer Security, vol. 16, no. 2, pp. 166-186.

PHỤ LỤC 1 – CÂU HỎI NGHIÊN CỨU

Để tìm ra các yếu tố rủi ro ảnh hƣởng đến thành công dự án phần mềm tại công ty

KMS Technology và các kiến nghị cải tiến sắp tới cho KMS, các anh/chị vui lòng

cho biết thông tin theo các câu hỏi dƣới đây:

I. Thông tin chung

1. Họ tên:……………………………………………………….

2. Giới tính: Nam □ Nữ □

3. Chức vụ:………………………………………………………..

4. Bộ phận:…………………………………………………….

5. Tuổi:…………………………………………………………………

6. Kinh nghiệm làm việc:…………………………….

II. Thông tin nghiên cứu

Các rủi ro trong dự án phần mềm đƣợc chia làm 4 nhóm: nhóm rủi ro

về sự quản lý của các thành phần hữu quan, nhóm rủi ro về yêu cầu và lịch trình,

nhóm rủi ro về môi trƣờng phát triển dự án, nhóm rủi ro về quản lý dự án.

2.1. Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về sự quản lý

của các thành phần hữu quan ảnh hƣởng đến thành công dự án phần mềm?

2.2. Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về yêu cầu và

lịch trình ảnh hƣởng đến thành công dự án phần mềm?

2.3. Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về môi trƣờng

phát triển dự án ảnh hƣởng đến thành công dự án phần mềm?

2.4. Theo kinh nghiệm của anh/chị thì yếu tố nào thuộc nhóm rủi ro về quản lý dự

án ảnh hƣởng đến thành công dự án phần mềm?

PHỤ LỤC 2 – KẾT QUẢ PHỎNG VẤN

Kết quả khảo sát 30 chuyên gia tại công ty KMS nhƣ bên dƣới:

Bảng: Các yếu tố rủi ro về sự quản lý của các thành phần hữu quan qua các vòng

phỏng vấn

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 1)

Số ngƣời trả lời (vòng 2)

Số ngƣời trả lời (vòng 3)

Số ngƣời trả lời (vòng 4)

Bảng: Các yếu tố rủi ro về yêu cầu và lịch trình qua các vòng phỏng vấn

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 1)

Số ngƣời trả lời (vòng 2)

Số ngƣời trả lời (vòng 3)

Số ngƣời trả lời (vòng 4)

7 Mong muốn của khách hàng

không thực tế Thực hiện các công việc phụ thêm ngoài dự án (gold plating) Ƣớc lƣợng lịch trình và chi phí không chính xác

Bảng: Các yếu tố rủi ro về môi trường phát triển qua các vòng phỏng vấn

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 1)

Số ngƣời trả lời (vòng 2)

Số ngƣời trả lời (vòng 3)

Số ngƣời trả lời (vòng 4)

Hiệu quả làm việc của bên thứ 3 (third party) Cạnh tranh làm thay đổi lịch trình Thay đổi phạm vi do thay đổi mô hình kinh doanh Thiên tai

Bảng: Các yếu tố rủi ro về quản lý dự án qua các vòng phỏng vấn

Yếu tố rủi ro

Số thứ tự

Số ngƣời trả lời (vòng 1) 25

Số ngƣời trả lời (vòng 2) 26

Số ngƣời trả lời (vòng 3) 27

Số ngƣời trả lời (vòng 4) 28

1 2

3 4

5 6

7 8

PHỤ LỤC 3 – DANH SÁCH CÁC CHUYÊN GIA

Họ và tên Chức vụ Số thứ tự Nhóm chuyên gia

Nhóm lập trình viên

Nhóm quản lý dự án

Nhóm đảm bảo chất lƣợng và phân tích yêu cầu (QA và BA)

Đoàn Phi Hải Võ Thanh Vinh Trần Trọng Đại Nguyễn Xuân Khoa Trần Thanh Minh Lê Thanh Mai Trần Thị Nhân Đỗ Văn An Nguyễn Thành Trung Trần Thành Đạt Nguyễn Thanh Dự Phạm Phƣớc Vũ Phan Minh Long Bùi Lệ Trang Bùi Thanh Phong Đỗ Văn Khôi Nguyễn Minh Trí Thiều Quang Trung Trần Văn Lâm Phan Loan Duyên Lê Thị Mỹ Huyền Nguyễn Ngọc Giàu Đỗ Hải Lê Đỗ Thị Lệ Thi Lê Thùy Giang Nguyễn Quốc Hùng Nguyễn Thùy Trâm Trƣơng Quang Bảo Trƣơng Bích Huyền Đặng Khánh Ngọc 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 Software Architect Software Architect Software Architect Senior Software Engineer Senior Software Engineer Software Architect Software Architect Senior Software Engineer Software Architect Senior Software Engineer Director Director Senior Engineer Manager Engineer Manager Director Engineer Manager Engineer Manager Senior Engineer Manager Senior Engineer Manager Engineer Manager Senior QA Engineer QA Architect Senior QA Engineer Senior BA Senior QA Engineer Senior BA Senior BA Senior QA Engineer QA Architect Senior QA Engineer Số năm kinh nghiệm 14 10 15 9 8 13 12 9 12 10 13 15 13 12 14 9 10 9 10 13 10 9 8 9 11 10 12 8 13 11