Xây dựng & Quản lý                 Dự án HTTT

1

ự

ự

ả

Xâ y d n g v à q u n lý d á n HTTT

ẫ

ậ  D n n h p Xác định dự án Phân tích khả thi Chọn lựa dự án Quản lý dự án

2

1. Dẫn nhập

• Dự án là gì?

Dự án là tập các hoạt động nhằm tạo ra một  HTTT mang lại các giá trị công việc hoặc kinh  doanh cho tổ chức. Tập các hoạt động có thời  điểm bắt đầu và thời điểm kết thúc rõ ràng.

3

• Dự án HTTT phải được bắt đầu bằng việc hiểu rõ  HT sẽ cải tiến công việc hoặc kinh doanh của tổ  chức ra sao. Nói khác đi, phải hình dung được HT  mang lại những giá trị nào cho tổ chức.

• Đặc điểm của dự án.

­ Nhiều người liên quan.

­ Những người liên quan ở nhiều đơn vị.

­ Hướng về mục tiêu.

­ Các công việc có thứ tự nhất định.

­ Có sản phẩm rõ ràng khi kết thúc.

­ Nhiều ưu tiên khác nhau.

4

­ Việc truyền thông xuyên qua tổ chức.

• Đặc điểm của dự án (tiếp theo).

­ Nhiều hoạt động và hoạt động phức tạp.

­ Mang tính duy nhất.

­ Có ngày bắt đầu và ngày kết thúc.

­ Có rủi ro và những điều không chắc chắn.

­ Nguồn lực và tài chính có giới hạn.

5

­ Những người liên quan có thể xác định.

ự

ự

ả

Xâ y d n g v à q u n lý d á n HTTT

ự

Dẫn nhập Xá c đ n h d á n ị Phân tích khả thi Chọn lựa dự án Quản lý dự án

6

2. Xác định dự án

• Khi một nhóm người trong tổ chức (TC) xác định  tồn tại nhu cầu công việc hay kinh doanh  (business needs) mà tổ chức cần phải đáp ứng, từ  đó thúc đẩy ý tưởng cần một HTTT tốt hơn để có  thể đáp ứng nhu cầu  DA bắt đầu hình thành.

• Bối cảnh hình thành DA thường như sau:

Vấn đề, khó khăn  nhu cầu  giải pháp …

7

hình thành DA

• Giám đốc dự án hay người chịu trách nhiệm dự  án (project sponsor) là người nhận thức được  nhu cầu công việc hoặc kinh doanh mà HT mới  cần phải đáp ứng.

• Giám đốc dự án sẽ làm việc trong suốt các giai  đoạn của vòng đời phát triển HT nhằm bảo đảm  dự án đi đúng hướng dưới quan niệm công việc  hoặc kinh doanh.

8

• Vai trò giám đốc dự án như là điểm liên hệ  chính (primary point of contact) trong quá trình  xây dựng HT.

• Tùy theo kích cỡ và phạm vi của DA mà Giám  đốc DA có thể là một người hoặc một nhóm  người (nhà quản lý + chuyên viên IT).

• Khi hình thành DA cần xác định mục tiêu DA.  Ta có mối liên hệ: Nhu cầu công việc / kinh  doanh  Yêu cầu công việc HT  Mục tiêu DA.

­ Mức cao ám chỉ sự trừu tượng, tổng quát. ­ Yêu cầu là những gì HT phải thực hiện hoặc những  chức năng mà HT phải có.

9

• Yêu cầu công việc HT ở thời điểm này được  hiểu là yêu cầu công việc / kinh doanh mức cao  (high­level business requirements), cần phải  được thông qua bởi tổ chức.

• Giám đốc DA cần phải hiểu rõ mục tiêu DA và  nhận thức được các giá trị công việc / kinh doanh  (business values) sẽ đạt được từ HT.

­ Các giá trị cụ thể có thể đo được và lượng hóa dễ  dàng (giảm 2% chi phí vận hành HT).

­ Các giá trị mơ hồ hình thành từ trực giác, sự tin tưởng  có cơ sở về những lợi ích khó đo được mà HT sẽ đem  lại cho tổ chức (cải tiến phục vụ khác hàng, tăng sức  cạnh tranh).

10

• Giá trị bao gồm các giá trị cụ thể (tangible  values) và giá trị mơ hồ (intangible values).

• Tóm lại, trong quá trình xác định DA thì Giám  đốc DA cần làm rõ:

­ Nhu cầu công việc, kinh doanh của TC. ­ Yêu cầu công việc, kinh doanh của HT. ­ Những giá trị công việc, kinh doanh mà HT  sẽ mang lại cho TC.

(System’s Business Requirements  System Request)

11

• Trong nhiều tổ chức, khâu xác định dự án  thường được bắt đầu bởi một kỹ thuật gọi là xác  định yêu cầu hệ thống (System Request).

• Yêu cầu HT (System Request) là một tài liệu  mô tả lý do tại sao phải xây dựng HT và những  giá trị mà tổ chức mong muốn HT sẽ mang lại.  Bản yêu cầu HT được hoàn thành bởi Giám đốc  dự án.

• Bản yêu cầu hệ thống thường có năm phần:

12

1. Project Sponsor 2. Business Need 3. Business Requirements 4. Business Value 5. Special Issues or Constraints

• Bản yêu cầu hệ thống đầy đủ cần được đệ trình  lên để tổ chức xem xét (Hội đồng Quản trị, Ban  Giám đốc, …) và thông qua.

• Sau khi thông qua yêu cầu HT, PTV cần tiến  hành phân tích khả thi nhằm đạt được những  hiểu biết đầy đủ hơn về những cơ hội cũng như  hạn chế liên quan đến khả năng thực hiện DA.

13

• Phân tích khả thi là bước rất quan trọng vì nó  giúp ta xem xét các yếu tố giúp thực hiện dự án  thành công cũng như các rủi ro có thể ảnh  hưởng đến sự thất bại của dự án.

ự

ự

ả

Xâ y d n g v à q u n lý d á n HTTT

ả

Dẫn nhập Xác định dự án P h â n t íc h kh t h i Chọn lựa dự án Quản lý dự án

14

3. Phân tích khả thi

• Phân tích khả thi (feasibility analysis) sẽ thu  thập thông tin nhằm hướng dẫn tổ chức quyết  định xem có nên tiếp tục thực hiện dự án hay  không, hay cần điều chỉnh mục tiêu, phạm vi dự  án một cách phù hợp hơn.

15

• Phân tích khả thi cũng xác định những rủi ro  chủ yếu (important risks) có thể có đối với dự án.  Những rủi ro này phải được chú ý đến nếu như dự  án được thông qua bởi tổ chức.

• Phân tích khả thi bao gồm các phân tích:

­ Khả thi kỹ thuật (technical feasibility). ­ Khả thi tài chính (economic feasibility). ­ Khả thi tổ chức (organizational feasibility).

Phân tích khả thi kỹ thuật

• Nhằm trả lời câu hỏi “liệu chúng ta có đủ khả  năng kỹ thuật để xây dựng HT hay không?”

16

­ NSD và PTV có quen thuộc, kinh nghiệm đối  với lĩnh vực công việc, kinh doanh của TC?  ­ Đội ngũ thực hiện DA có quen thuộc với kỹ  thuật xây dựng HT?

• Phân tích khả thi kỹ thuật còn liên quan đến:

­ Kích thước, độ phức tạp của DA (bao nhiêu  người tham gia, thời gian thực hiện)? ­ HT mới tương thích với HT hiện thời ra sao  (trao đổi, chia sẻ dữ liệu)?

Phân tích khả thi tài chính

• Nhằm trả lời câu hỏi “liệu chúng ta có nên xây  dựng HT hay không?”

17

­ Xác định chi phí và lợi ích. ­ Gán giá trị cho chi phí và lợi ích. ­ Xác định dòng chảy tiền mặt. ­ Đánh giá khấu hao.

• Xác định chi phí và lợi ích.

­ Chi phí phát triển HT (lương đội ngũ thực  hiện DA, tiền thuê tư vấn, chi phí phần cứng  và phần mềm, tiền huấn luyện, tiền thuê  mướn văn phòng và thiết bị, …). Các chi phí  phát triển HT chỉ trả một lần.

18

­ Chi phí vận hành HT (lương đội ngũ kỹ thuật  như nhà quản trị mạng, chi phí nâng cấp  phần cứng, bảo trì phần mềm, …). Các chi  phí vận hành HT được trả theo thời gian khi  HT bắt đầu hoạt động, không trả một lần.

• Xác định chi phí và lợi ích (tiếp theo).

­ Lợi ích xác định được tức là những lợi ích có  thể đo lường, đánh giá qua con số được  (giảm nhân viên, tăng lương, giảm thời gian  xử lý công việc, …).

19

­ Lợi ích không xác định được tức là những lợi  ích khó đánh giá bằng con số, dựa trên trực  giác, kinh nghiệm nhiều hơn (tăng khả năng  cạnh tranh, tăng năng lực đội ngũ nhân viên,  cải tiến chất lượng phục vụ khách hàng, theo  dõi số liệu hàng hóa chặt chẽ hơn, …).

Bảng phân tích chi phí ­ lợi ích

ợ Ch i p h í Ch i p h í ợL i íc h L i íc h

Xá c đ n hị Xá c đ n hị - - - -

M hơ ồM hơ ồ - - - -

20

• Các chi phí và lợi ích mơ hồ thường gây khó  khăn cho việc xác định chi phí và lợi ích. Tuy  nhiên chúng lại rất cần thiết để trả lời câu hỏi  “HT sẽ mang lại những giá trị gì cho tổ chức?”

• Sau khi xác định các chi phí và lợi ích, cần  gán các số tiền ước tính cho chúng.

­ Công việc này khó khăn vì HT chưa thực  hiện, chưa được phân tích và thiết kế kỹ.

­ Dùng biện pháp ước tính và chấp nhận sai  số  Cần tư vấn kết hợp kinh nghiệm.

­ Cần phải lượng hóa các chi phí và lợi ích  mơ hồ không xác định được.

21

­ Liệt kê và thảo luận nhiều hơn những chi  phí và lợi ích mơ hồ không thể lượng hóa.

• Việc phân tích lợi ích và chi phí không mang  tính thời điểm mà mang tính quá trình tức là có  yếu tố thời gian.

• Việc xác định dòng chảy tiền mặt (cash flow)  giúp cho thấy sự so sánh giữa chi phí và lợi ích  theo thời gian.

22

• Nhược điểm của xác định dòng chảy tiền mặt là  không cho ta thấy được mức khấu hao của chi  phí cũng như lợi ích qua thời gian  Đánh giá  khấu hao.

Xác định dòng chảy tiền mặt

23

Đánh giá khấu hao

PV nghĩa  là Present  Value,  NPV  nghĩa là  Net  Present  Value.

24

Phân tích khả thi tổ chức

• Nhằm trả lời câu hỏi “nếu chúng ta xây dựng HT,  liệu HT có được người dùng chấp nhận không và  HT có kết hợp được với guồng máy hoạt động hiện  thời không?”

25

­ Mục tiêu dự án có sát với với mục tiêu kinh  doanh hoặc chiến lược phát triển của tổ chức? ­ Phân tích khả thi tổ chức đối với những người  liên quan đến DA (stakeholders)? ­ Sự chấp nhận thay đổi, sự tham gia của NSD  trong quá trình triển khai DA ra sao?

• Những người quan trọng cần quan tâm trong quá  trình phân tích khả thi tổ chức (important  stakeholders):

­ Project champion(s).

­ Organizational Managers.

­ System Users.

26

• Cần nhận thức và hiểu được vai trò của những  người này đối với khả thi tổ chức vì họ có ảnh  hưởng đến việc chấp nhận hệ thống hay không khi  nó được bàn giao sau khi xây dựng.

ự

ự

ả

Xâ y d n g v à q u n lý d á n HTTT

Dẫn nhập Xác định dự án Phân tích khả thi Ch n l a d á n ự ọ ự Quản lý dự án

27

4. Chọn lựa dự án

• Từ bản yêu cầu hệ thống (System Request) và  kết quả phân tích khả thi, tổ chức (Hội đồng Quản  trị, Ban giám đốc, …) xem xét:

­ Giá trị DA mang lại cho TC (yêu cầu HT). ­ Rủi ro khi xây dựng HT (phân tích khả thi).

28

• Việc xem xét được thực hiện trong bối cảnh tổ  chức có nhiều DA cần thực hiện cùng lúc nhưng  tài nguyên thì có hạng. Từ đó quyết định tiến hành  hay hủy bỏ DA.

• Việc chọn lựa thực hiện dự án thường được  xem xét dựa trên các yếu tố:

­ Kích cỡ dự án.

­ Chi phí thực hiện.

­ Mục đích của dự án.

­ Thời gian thực hiện.

­ Mức độ rủi ro.

­ Phạm vi dự án.

29

­ Khả năng hoàn vốn đầu tư.

ự

ự

ả

Xâ y d n g v à q u n lý d á n HTTT

Dẫn nhập Xác định dự án Phân tích khả thi Chọn lựa dự án Qu n lý d á n

ự

ả

30

5. Quản lý dự án

• Quản lý dự án (project management) là quá trình  lập kế hoạch và kiểm soát sự phát triển của HT  trong một khung thời gian và chi phí xác định.

• Nhà quản trị dự án (project manager) là người  chịu trách nhiệm chính quản lý các công việc và  vai trò mà chúng cần được phối hợp với nhau một  cách cẩn thận trong quá trình thực hiện DA.

31

• Ngày nay, quản trị DA thực sự được xem là một  nghề chuyên môn, và PTV cần được đào tạo về  chuyên môn này.

• Yếu tố then chốt giúp việc quản trị DA thành  công là cần sự đánh giá xác thực những công  việc cần được hoàn thành và quản lý dự án ứng  với những đánh giá đó.

• Bốn bước chính trong quản trị dự án:

­ Xác định kích cỡ dự án.

­ Lập và quản lý kế hoạch công việc.

­ Tuyển dụng nhân viên.

32

­ Phối hợp các hoạt động dự án.

Xác định kích cỡ dự án

Project Size

P

r

o

j

e

• Quản trị dự án liên quan đến việc cân nhắc  hoặc thỏa hiệp giữa ba yếu tố kích cỡ dự án  (theo nghĩa những gì DA thực hiện), chi phí thực  hiện dự án và thời gian hoàn thành dự án.

c

t

C

o

s

t

Project Time

33

Điều chỉnh một  thành phần sẽ ảnh  hưởng đến các  thành phần còn lại

• Việc xác định kích cỡ dự án còn được gọi là  ước lượng dự án (project estimation).

• Cơ sở để ước lượng DA bao gồm:

­ Phương pháp xây dựng HT đang dùng.

­ Những dự án được hoàn thành trước đó.

­ Kinh nghiệm của nhà phát triển hệ thống.

34

• Ước lượng DA là một quá trình, bắt đầu với các  ước lượng thô sau đó được làm rõ và cụ thể dần  khi dự án được tiến hành.

• Có hai cách cơ bản để tính thời gian cần thiết  hoàn thành dự án.

­ Dùng thời gian dành cho việc thực hiện giai  đoạn lập kế hoạch để dự đoán thời gian cần  thiết cho toàn bộ DA, dựa trên mức phần  trăm chuẩn công nghiệp, hoặc mức phần  trăm của kinh nghiệm của chính tổ chức.

35

­ Dùng phương pháp cho điểm chức năng  (FP ­ Function Point Approach) để tính thời  gian cần thiết cho toàn bộ DA.

Ví dụ tính thời gian cần thiết hoàn thành dự án  dựa trên mức phần trăm chuẩn công nghiệp

Planning

Analysis

Design

Implementation

15%

20%

35%

30%

Industry Standard For Web Applications

Actual 4

Estimated 3.3

Estimated 8

Estimate d 9.33

Time Required in Person Months

36

• Dùng phương pháp FP để tính thời gian cần thiết  hoàn thành dự án.

­ FP gọi là điểm chức năng, được xem như là  công cụ dùng để đo kích thước chương trình.

1. Tính độ lớn hệ thống (theo FP và dòng lệnh).

2. Tính công sức cần cho DA (person­months).

3. Tính thời gian cần cho DA (months).

37

­ Việc tính thời gian cần cho dự án được thực  hiện qua ba bước:

­ Cho điểm chức năng dựa trên đánh giá độ phức tạp  của các thành phần trong HT. Các thành phần này  bao gồm inputs, outputs, queries, files và program  interfaces  cho kết quả là Total Unadjusted  Function Points (TUFP).

­ Cho điểm sự phức tạp của các khía cạnh của HT.  Các khía cạnh này bao gồm data communications,  transaction rate, complex processing, …  cho kết  quả là Total Processing Complexity (PC).

­ Dùng PC để điều chỉnh giá trị của TUFP  cho kết  quả là Total Adjusted Function Points (TAFP)  tính  số dòng lệnh cần lập trình cho hệ thống.

38

Tính độ lớn HT (theo FP và số dòng lệnh):

Complexity

Description

Low

Medium

High

Total

Total Number

Inputs

6

3 x 3

2 x 4

1 x 6

23

Outputs

19

4 x 4

10 x 5

5 x 7

101

Queries

10

7 x 3

0 x 4

3 x 6

39

Files

15

0 x 7

15 x 10

0 x 15

150

3

1 x 5

0 x 7

2 x 10

25

Program Interfaces

Total Unadjusted Function Points (TUFP):

338

39

Overall System

Scale of 1 to 5

Data communications Heavy use configuration Transaction rate End-user efficiency Complex processing Installation ease Multiple sites Performance Distributed functions Online data entry Online update Reusability Operational ease Extensibility

3 0 0 0 0 0 0 0 2 2 0 0 0 0

Total Processing Complexity (PC):

7

40

Processing Complexity (PC) = 7

Adjusted Processing Complexity (PCA) =

0.65 + ( 0.01 x 7 ) = 0.72

Total Adjusted Function Points (TAFP) =

0.72 (PCA) x 338 (TUFP) = 243

Lines of code = 243 (TAFP) x 30 (VB) = 7290

41

(Hệ số 30 ứng với việc dùng ngôn ngữ lập trình  Visual Basic để coding)

Language

Approximate Number of Lines of Code per Function Point

C COBOL Java C++ Turbo Pascal Visual Basic PowerBuilder HTML Packages (e.g., Access)

130 110 55 50 50 30 15 15 10 - 40

42

­ Công sức (effort) là hàm của độ lớn hệ thống và tốc  độ sản xuất (lượng công việc mà một người có thể  hoàn thành trong một thời gian xác định).

­ Nghiên cứu đưa ra mô hình COCOMO để ước tính  công sức theo số dòng lệnh cần lập trình cho hệ thống.

­ Theo mô hình COCOMO thì ước tính như sau:

Công sức (person­months) = 1.4 x Số ngàn dòng lệnh

­ Ví dụ với 7290 dòng lệnh lập trình bằng VB thì cần  công sức là 7.290 x 1.4 = 10.20 person­months.

43

Tính công sức cần cho DA (person­months):

­ Ước tính theo công thức:

Thời gian (months) = 3.0 x Công sức1/3

­ Ví dụ với công sức là 10.20 person­months thì ước  tính thời gian cần cho dự án là 3.0 x 10.201/3

­ Chú ý thời gian ước tính trên dành cho các giai đoạn  phân tích, thiết kế và thực hiện; nó không bao gồm cho  giai đoạn lập kế hoạch.

­ Chú ý công thức ước tính công sức theo mô hình  COCOMO trên chỉ áp dụng cho những dự án phần  mềm quản lý có qui mô nhỏ đến vừa (khoảng 100000  dòng lệnh và cần đến 10 lập trình viên hoặc ít hơn).

44

Tính thời gian cần cho DA (months):

Lập và quản lý kế hoạch công việc

• Bản kế hoạch công việc (workplan) là một thời  gian biểu động ghi chép lại và theo dõi tất cả  các tác vụ (tasks) cần phải được hoàn thành  trong quá trình thực hiện dự án.

(Từ tác vụ có thể được hiểu là những công việc cụ thể  và xác định cần phải thực hiện. Một công việc được mô  tả bởi một số các tác vụ.)

45

• Tính “động” (dynamic) ở đây nhằm nói đến sự  cập nhật và điều chỉnh các tác vụ trong bản kế  hoạch công việc trong khi dự án được tiến hành.

• Để lập bản kế hoạch công việc, trước hết nhà  QTDA phải xác định được các tác vụ cần phải  thực hiện.

• Sau đó các tác vụ sẽ được trình bày trong bản  kế hoạch công việc ở dạng đồ họa bằng sơ đồ  Gantt hay sơ đồ PERT.

• Những kỹ thuật trên giúp nhà QTDA hiểu và  quản lý được sự tiến triển của DA theo thời gian.

46

• Nhà QTDA có thể dùng phần mềm MS Project  để lập bản kế hoạch công việc sau khi xác định  được các tác vụ cần thực hiện.

• Làm thế nào để xác định được các tác vụ?

­ Dựa vào mục tiêu dự án, thường được liệt kê  trong bản yêu cầu HT (System Request).

­ Dựa vào phương pháp luận hiện dùng để  xây dựng hệ thống (VD mô hình thác nước).

­ Dựa vào kinh nghiệm quản trị các dự án  tương tự đã được thực hiện thành công.

47

­ Ngoài ra cần xác định mối liên hệ giữa các  tác vụ (thứ tự thực hiện giữa các tác vụ).

THÔNG TIN TÁC VỤ

Tên của tác vụ Ngày bắt đầu  Ngày hoàn thành Cá nhân chịu trách nhiệm thực hiện Kết quả do tác vụ tạo ra Tình trạng hoàn thành Mức ưu tiên Các tài nguyên cần cho việc thực hiện Thời gian thực hiện ước tính Thời gian thực hiện thực tế

48

• Với mỗi tác vụ cụ thể, cần phải xác định đầy đủ  các thông tin sau:

­ Phân chia một công việc lớn (work) thành các công  việc nhỏ hơn.

­ Với mỗi công việc nhỏ (subwork) lại phân chia nó  thành các công việc nhỏ hơn nữa.

­ Khi một công việc nhỏ được xác định thì ta xem nó  là một tác vụ (task).

­ Sắp xếp các tác vụ vào một danh sách phân cấp có  đánh số.

­ Danh sách này được gọi là một cấu trúc phân chia  công việc (WBS – Work Breakdown Structure), và nó   chính là xương sống của bản kế hoạch công việc.

49

• Một kỹ thuật thường dùng để xác định tác vụ là  phân nhỏ công việc (kỹ thuật WBS).

• Bản kế hoạch công việc được tạo ra bằng  cách liệt kê tất cả các tác vụ trong cấu trúc  WBS với sự bổ sung các thông tin sau:

­ Khoảng thời gian ước tính cho tác vụ.

­ Cập nhật tình trạng hiện thời của tác vụ.

­ Sự phụ thuộc lẫn nhau giữa các tác vụ.

­ Các mốc thời gian quan trọng.

50

­ Nhà QTDA có thể dùng sơ đồ Gantt hoặc sơ  đồ PERT để trình bày bản kế hoạch công việc.  Mỗi sơ đồ có những ưu điểm riêng.

Ví dụ sơ đồ Gantt

Tasks

Week 2 3 4 5 6 7 8 9 10 11

Go to library Go to bookstore Select and purchase books Skim books Write phase one Read book carefully Write phase two

51

Ví dụ sơ đồ Gantt

52

Ví dụ sơ đồ Gantt

53

Ví dụ sơ đồ Gantt

54

Ví dụ sơ đồ Gantt

55

Ví dụ sơ đồ PERT

Order Order furniture furniture

4

2

Furniture Furniture setup setup

Locate Locate facilities facilities

Remodel Remodel

1

5

6

Move Move inin

Interview Interview

Hire and Hire and train train

3

56

Ví dụ sơ đồ PERT

Order Order furniture furniture

2

Furniture Furniture setup setup

Locate Locate facilities facilities

6

1

Remodel Remodel

Move Move inin

5

7

S

Interview Interview

Hire and Hire and train train

4

3

57

Ví dụ sơ đồ PERT

6 weeks 6 weeks

44

F F

d d

e e

r r

s s

u u

r

e e

r

3 weeks 3 weeks

r r e e n i t u n i t u

r r

t

t

n n

O r O r f u f u

u u

22

i i

t

t

p p

u u

r

r

e e

s

c

s

c

Remodel Remodel

L L

11 weeks 11 weeks

8 weeks 8 weeks a t e a t e c iliti e c iliti e

o o f a f a

Move Move inin

11

55

66

1 week 1 week

I I n n t t e e

r r

d tr a i n d tr a i n

v v i i e e

n

n

w w

4 weeks 4 weeks

H ir e a H ir e a

9 weeks 9 weeks

33

58

Ví dụ sơ đồ PERT

5 Delivery Lag 5 days

7 Install System 1 day

2 Select Software 5 days

1 Start 0 days

8 Finish 0 days

4 Purchase System 1 day

6 Train User 3 days

3 Select Hardware 3 days

59

­ Dạng sơ đồ hình thanh. ­ Giám sát tình trạng DA ở thời điểm bất kỳ.

• Sơ đồ Gantt.

• Sơ đồ PERT.

­ Dạng lưu đồ. ­ Thấy được sự phụ thuộc các tác vụ. ­ Tính được hiểm lộ (critical path).

60

• Quá trình ước tính các tham số cho mỗi tác vụ  trong bản kế hoạch công việc (sơ đồ Gantt, sơ  đồ PERT) là quá trình làm mịn dần khi DA được  tiến hành.

Việc thay đổi các tham số của tác vụ trong bản kế hoạch  công việc được tiến hành như mô hình dự báo bão

Design

Analysis

Im plem entation

Time

Planning

61

Project Stage

Tuyển dụng nhân viên

­ Xác định xem dự án cần tất cả bao nhiêu người làm  việc. Những người này cần có năng lực gì (kiến thức,  kỹ năng chuyên môn và cá nhân).

­ Phân công người có năng lực phù hợp với nhu cầu  dự án. Động viên, thúc đẩy tinh thần nhân viên  hướng đến hoàn thành mục tiêu dự án.

­ Giảm thiểu tối đa các mâu thuẫn nảy sinh giữa các  nhân viên trong quá trình thực hiện dự án. Quản lý  và giải quyết mâu thuẫn một cách thích hợp.

62

• Tuyển dụng nhân viên nhằm nói đến các vấn  đề sau:

• Nhà QTDA cần phải lập kế hoạch nhân dự  cho dự án.

Ví dụ với dự án cần đến công sức 40 person­months  và thời gian là 10 tháng thì trung bình cần có một  nhóm khoảng 4 nhân viên làm việc toàn thời gian.

• Số lượng nhân viên cần cho dự án thường dựa  trên ước tính công sức (effort) và thời gian cần  cho dự án.

63

• Qui tắc kinh nghiệm cho thấy một nhóm làm  việc tốt không nên quá 10 người. Nếu cần  nhiều hơn có thể chia thành các nhóm con.

Phối hợp các hoạt động dự án

• Quản lý dự án không phải là sự quản lý các  tác vụ một cách độc lập và riêng rẻ.

• Giữa các tác vụ luôn có sự phụ thuộc vào  nhau. Kết quả của tác vụ này có thể là điều kiện  thực hiện cho tác vụ khác.

• Sự chậm trễ hoặc thất bại của một tác vụ có  thể ảnh hưởng đến việc thực hiện tác vụ khác.

64

• Quản lý rủi ro là hoạt động quan trọng trong  quá trình phối hợp các hoạt động dự án.

­ Thay đổi phạm vi  quản lý phạm vi.

­ Thay đổi mục tiêu  điều chỉnh mục tiêu.

­ Thay đổi nguồn lực  điều chỉnh tác vụ.

­ Quản lý sự thay đổi là công việc khó khăn của nhà  QTDA, nhưng việc này luôn xảy ra trong thực tế.

­ Có người ví von: “Lập kế hoạch để mà thay đổi”   Lập kế hoạch giúp ta chủ động đối phó với sự thay  đổi để giảm thiểu, khắc phục rủi ro để hoàn thành dự  án (đáp ứng nhu cầu, đúng thời gian, không vượt chi  phí).

65

• Trong thực tế luôn có sự thay đổi trong quá  trình thực hiện dự án:

Tó m l

i, c h ú n g t a đ ã n ó i v …

ạ

ề

ẫ

ị

ậ  ự

ả

ự

D n n h p  Xá c đ n h d á n P h â n t íc h kh t h i  Ch n l a d á n  Qu n lý d á n

ọ ự ả

ự

66