qldapm-c2-quanlyphamvi.pdf

7/25/2019 qldapm-c2-quanlyphamvi.pdf

http://slidepdf.com/reader/full/qldapm-c2-quanlyphamvipdf 1/46

Quản lý phạm vi (Scope)

Chươ ng II



N ội dung

1. Quản lý phạm vi (Scope) là gì?

2. Khởi động dự án (Initiating project).

3. Lập kế hoạch phạm vi (Planning) và Xác địnhphạm vi (Definition).

4. Kiểm tra phạm vi (Verification) và Kiểm soát phạm

vi (Controling).

2



3

1. Quản lý phạm vi là gì?

Phạm vi (Scope) là một danh sách tất cả nhữnggì dự án phải làm (và cũng có thể là một danh

sách tất cả những điều mà dự án không phải làm).Dự án phải có một phạm vi được viết ra rõ ràng,nếu không dự án sẽ không bao giờ kết thúc.

Các Thành quả chuyển giao (Deliverable) lànhững thành quả của dự án mà sẽ chuyển giao:như là phần cứng, phần mềm (mua hoặc đặt làm),bảo hành, tài liệu đào tạo và chuyển giao…

Nhóm dự án và các người liên quan(Stakeholders) phải cùng hiểu những sản phẩmnào được tạo ra như là kết quả của dự án và

chúng được tạo ra như thế nào.



4

Quản lý phạm vi d ự án

Quản lý phạm vi dự án (Project scope

management)

Bao gồm các qui trình liên quan đến việc xác định vàkiểm soát những gì thuộc hoặc không thuộc dự án.

Nó bảo đảm đội dự án và những người liên quan

cùng hiểu biết về sản phẩm mà dự án tạo ra và quy

trình mà đội dự án sẽ sử dụng để tạo ra sản phẩm.



5

Qui trình Quản lý phạm vi d ự án

a. Khởi động (Initiating project): Bắt đầu một dự án hoặc chuyển tiếp sang giai đoạn tiếp theo.

b. Lập kế hoạch phạm vi (Planning): phát triểncác tài liệu nhằm cung cấp nền tảng cho cácquyết định về dự án trong tương lai

c. Xác định phạm vi (Definition): chia nhỏ các

sản phẩm trung gian của dự án thành cácthành phần nhỏ hơn, dễ quản lý hơn (workbreakdown structure-WBS).

d. Kiểm tra phạm vi (Verification): hợp thức hóa

việc chấp nhận phạm vi của dự áne. Kiểm soát phạm vi (Controling): điều khiển

những thay đổi của phạm vi dự án.



6

2. Khở i động d ự án

Khởi động dự án: Kế hoạch chiến lược và chọn

dự án.

Tr ước tiên là nhìn bức tranh tổng thể hay kế hoạchcủa tổ chức.

Kế hoạch chiến lược nhằm xác định những hoạt

động dài hạn. Dự án IT phải hỗ tr ợ những mục tiêu thương

mại,tài chánh và chiến lược của đơn vị.



7

Qui trình chọn d ự án

Dựa vào kế hoạch chiến lược tổng thể của tổ chức.

Phân tích vùng nghiệp vụ.

Xác định dự án tiềm năng.

Chọn dự án IT và Xác định tài nguyên phân bổ.



8

Các phươ ng pháp chọn d ự án

Tập trung vào nhu cầu chung

Phân tích SWOT (mạnh, yếu, cơ hội và nguy cơ)

Phân loại dự án

Phân tích tài chính

Dùng WSM (mô hình tính điểm có tr ọng số -

Weighted Scoring Model)

Thực hiện BC (Bảng điểm cân đối - Balanced

score Card): www.balancedscorecard.org



9

T ậ p trung vào nhu c ầu chung

“It is better to measure gold roughly than to countpennies precisely”

Ba tiêu chuẩn: Nhu cầu (need)

Tài chánh (fund)

Sự sẵn lòng (will)



10

Phân tích SWOT

Strengths

Weaknesses

Opportunities

Threats

Khả năng Hoàn cảnh

Thuận lợi

Khó khăn



11

Phân loại d ự án

Có thể phân loại dựa theo:

Khó khăn

Thuận lợi Những hướng dẫn

Có thể phân loại dựa theo: Thời gian thực hiện và

khi nào có cần dùng Có thể phân loại dựa theo độ ưu tiên của dự án



12

Phân tích tài chính

Phân tích NPV (Net present value): Giá tr ị hiện tại

tinh, tính lời lỗ qui đổi theo thời điểm hiện tại

ROI (Return on investment) = (total discounted

benefits - total discounted costs) / discounted costs:

Kết quả thu được nhờ đầu tư.

Thời gian hoàn vốn (Payback period).



13

Thuật ngữ

Discount rate: tỉ lệ chiết khấu.

Cast flow: dòng tiền mặt, tính bằng hiệu thu nhập

và chi tiêu. Capital: tiền vốn.

Cost of capital: chi phí của vốn.



14

Ví d ụ

Note

that

totalsare

equal,

but

NPVs

are

not.



15

Ví d ụ

Multiply

by the

discount

rate

each

year,

thentake

cum.

benefits

–

costs to

get NPV



16

Thờ i gian hoàn v ố n

Payback period: thời gian hoàn vốn



17

Mô hình tính đ i ể m có tr ọng số

Xác định tiêu chuẩn quan tr ọng

Gán tr ọng số theo tỷ lệ %

Cho điểm cho mỗi tiêu chuẩn của dự án

Tính điểm từng dự án



18

Tính đ i ể m có tr ọng số



19

Tuyên bố d ự án

Sau khi quyết định chọn dự án phải đưa ra Tuyên bố

dự án.

Tuyên bố dự án công nhận dự án và cung cấpnhững chỉ thị về việc quản lý dự án và những mục

tiêu của dự án

Những stakeholder sẽ ký vào Tuyên bố để xác nhậnviệc đồng ý với sự cần thiết và mục đích của dự án.



20

Tuyên bố d ự án (Project Charter)



21




22




23

Phát bi ể u phạm vi



24

3. Lậ p k ế hoạch và Xác đị nh phạm vi

Lập kế hoạch

Là quá trình xây dựng các tài liệu nhằm cung cấp

nền tảng về phạm vi của dự án. Tuyên bố về phạmvi (scope statement) gồm:

Bảo vệ cho dự án (project justification).

Mô tả ngắn về sản phẩm của dự án.

Tổng kết về tất cả các sản phẩm chuyển giao của dự

án.

Tuyên bố về những gì xác định thành công của dự

án.

Ví dụ: Chapter 3, pages 83-85



25

Xác đị nh phạm vi

Sau khi hoàn tất kế hoạch về phạm vi, bước tiếptheo là xác định chi tiết công việc bằng cách chiathành các công việc nhỏ hơn có thể quản lý được

Xác định đúng phạm vi:

Giúp cải tiến sự chính xác về thời gian, chi phí, và tàinguyên

Xác định nền tảng để đo hiệu suất vận hành và điềukhiển dự án

Giúp truyền đạt rõ ràng các trách nhiệm của mỗi côngviệc.



26

Phân rã công vi ệc

Cần phân rã công việc thành những mẩu có thể

quản lý.

Xác định phạm vi tốt: Xác định tốt thời gian, chi phí và tài nguyên

Xác định cơ sở cho việc đo lường và quản lý dự án

Hỗ tr ợ truyền thông rõ ràng, trách nhiệm của côngviệc



27

WBS (Work Breakdown Structure)

Một WBS là cây phân cấp của các nhóm công việc

chính mà được bao gồm trong dự án, nó xác định

toàn bộ phạm vi của dự án. Là tài liệu cơ bản trong quản lý dự án, là nền tảng

cho việc lập kế hoạch và quản lý lịch biểu, chi phí

và biến đổi dự án.



28

WBS



29

WBS



30

Ví d ụ

1.0 Concept

1.1 Evaluate current systems

1.2 Define Requirements

1.2.1 Define user requirements1.2.2 Define content requirements

1.2.3 Define system requirements

1.2.4 Define server owner requirements

1.3 Define specific functionality1.4 Define risks and risk management approach

1.5 Develop project plan

1.6 Brief Web development team

2.0 Web Site Design3.0 Web Site Development

4.0 Roll Out

5.0 Support



MS project

31



32

Phát tri ể n WBS

Hướng Analogy

Hướng Top-down

Hướng Bottom-up Hướng Mind-mapping



33

Bản đồ t ư duy (Mind-mapping)



34

Các nguyên lý c ơ bản t ạo WBS

1. Một đơn vị công việc chỉ xuất hiện một nơi trong WBS.

2. Nội dung công việc trong một mục WBS bằng tổng cáccông việc dưới nó.

3. Một mục WBS là nhiệm vụ đơn

4. WBS phải nhất quán với cách thực hiện công việc;tr ước hết nó phải phục vụ nhóm dự án và các mục đíchkhác nếu thực tế cho phép.

5. Các thành viên nhóm dự án phải tham gia phát triểnWBS để bảo đảm tính nhất quán.

6. Mỗi mục WBS phải có tài liệu đi kèm để bảo đảm hiểu

được chính xác phạm vi công việc.7. WBS phải là công cụ linh hoạt để đáp ứng những thay

đổi không tránh được, điều khiển nội dung công việctheo đúng tuyên bố về phạm vi.



35

4. Ki ể m tra & ki ể m soát

Rất khó tạo được tuyên bố phạm vi tốt và WBS tốt

cho một dự án.

Kiểm tra phạm vi dự án và giảm thiểu thay đổiphạm vi là điều khó hơn.

Nhiều dự án CNTT chịu phải tình tr ạng “phạm vi

phình ra” (Scope Creep) và thường kiểm tra và

kiểm soát phạm vi không tốt.



36

Các d ự án gặ p khó khăn

FoxMeyer Drug vỡ nợ do phạm vi phình ra (robotic

warehouse)

21st

Century Insurance Group tốn nhiều thời gianvà tiền bạc cho dự án mà có thể dùng thành phần

COTS (Commerce off-the-shelf)



37



38

C ần làm vi ệc v ớ i ngườ i dùng

Người dùng có vai trò quan tr ọng trong nhóm dự án

Có những buổi họp thường xuyên.

Chuyển những điều cần thiết cho người dùng vànhà tài tr ợ một cách thường xuyên.

Gặp gỡ giữa người dùng và người phát triển.



39

Ứ ng phó v ớ i các v ấ n đề v ề yêu c ầu

Dựa theo qui trình quản lý yêu cầu

Dùng Prototyping, Use case modeling, and JAD

(Joint Application Design)

Viết ra những yêu cầu và giữ chúng hợp thời.

Kiểm thử thỏa đáng và xuyên suốt chu kỳ sống

Kiểm tra những thay đổi từ quan điểm hệ thống.

Nhấn mạnh tới thời hạn hoàn tất nhằm tập trung

vào những gì quan tr ọng nhất Xác định rõ những tài nguyên cho những đòi hỏi

thay đổi.



40

T ạo nguyên mẫ u (Prototyping)

Xây dựng 1 mô hình làm việc “nháp” của hệ thống.

Các mô hình này có thể sẽ bỏ đi hay tr ở thành 1 phần

trong kết quả sau này. Đây là 1 công cụ hiệu quả để hiểu được yêu cầu hệ

thống, xác định được tính khả thi của yêu cầu, giải

quyết được những mơ hồ khi giao tiếp với ngườidùng



41

Mô hình Use case

Là quy trình nhận biết và mô hình hóa các sự kiện

nghiệp vụ thành tình huống sử dụng (Use case), và

xét xem hệ thống đáp ứng với các tình huống này

như thế nào.

Là công cụ r ất hiệu quả để hiểu được yêu cầu của

những hệ thống thông tin.



42

Thi ế t k ế ứ ng d ụng k ế t nố i

JAD - Joint Application Design

Thông qua các hội thảo (workshop) chuyên sâu

bao gồm các stakeholder để cùng nhau xác địnhvà thiết kế hệ thống thông tin.

Nhờ kỹ thuật này người dùng sẽ tr ở nên năng

động hơn trong việc xác định yêu cầu hệ thống.



JAD

43



44



Câu hỏi

45



?????

Thank you

Documents

qldapm-c2-quanlyphamvi.pdf