Tự học PM

A fine WordPress.com site

Archive for June 2013

ETC – Estimate to Completion

leave a comment »

Lexicon Definition: Trong PMBok định nghĩa như sau:

  • The expected cost to finish all the remaining project work.
  • Là chi phí dự tính để hoàn thành tất cả công việc còn lại của project.

budget

Calculation Method:

  1. Assuming work is proceeding on plan, the cost of completing the remaining authorized work: ETC = EAC – AC.
  2. Reestimate the remaining work from the bottom up: ETC = Reestimate.

EAC & ETC

Trên thực tế để cùng với EAC, ETC cung cấp một thông tin quan trọng liệu có còn đủ tiền để hoàn thành những công việc còn lại của project hay không? 

Advertisements

Written by hoantv

June 24, 2013 at 3:17 pm

Posted in 07. Prj Cost Mgt

EAC – Estimate at Completion

leave a comment »

Lexicon Definition: Trong PMBok định nghĩa gắn gọn về EAC như sau:

  • The expected total cost of completing all work expressed as the sum of the actual cost to date and the estimate to complete.
  • Là tổng chi phí dự kiến hoàn thành tất cả công việc, là tổng của chi phí thực tế cho đến nay và chi phí ước tính cho đến khi hoàn thành.

Objective: Create forecast based on past performance on the project.

Image

Calculation: Cách tính toán đã có công thức, tuy nhiên tùy thuộc vào ngữ cảnh (scenario) mà công thức cũng khác nhau.

  1. If the CPI is expected to be the same for the remainder of the project: EAC = BAC / CPI.
  2. If future work will be accomplished at the planned rate: EAC = AC + BAC – EV.
  3. If the initial plan is no longer valid: EAC = AC + Bottom-up ETC.
  4. If both the CPI and SPI influence the remaining work: EAC = AC + [(BAC – EV) / (CPI x SPI)]

Trong hầu hết các dự án đơn thuần sản xuất phần mềm và với quy mô vừa và nhỏ thì Project Cost = Project Effort.

Image

Ghi chú thêm: một số thuật ngữ dùng trong MS Project.

  1. BCWS = PV: Budgeted Cost of Work Scheduled
  2. BCWP = EV: Budgeted Cost of Work Performed
  3. ACWP = AC: Actual Cost of Work Performed

Written by hoantv

June 24, 2013 at 2:57 pm

Posted in 07. Prj Cost Mgt

EVM: Earned Value Management

leave a comment »

Trong PMBok định nghĩa như sau:

Earned Value Management (EVM) is a methodology that combines scope, schedule, and cost measurements to assess project performance and progress.

Đây là một phương pháp rất hay được sử dụng để đo performance của project.

Phương pháp này tích hợp scope baseline với cost baseline cùng với time baseline để tạo ra performance baseline, giúp cho project management team đánh giá, đo performance và progress của project. Đây là một project management technique đòi hỏi sự hình thành dựa trên sự tích hợp các baseline (scope, time, cost) dựa vào đó mà performance có thể được tính toán trong suốt duration của project.

EVM phát triển và monitor 3 mảng chính sau đây của từng work package hoặc control account:

  1. PV (Planned Value): Là ngân sách phê duyệt được lập kế hoạch cho công việc được hoàn thành của một activity, hoặc một WBS component, không bao gồm management reserve. Khoản ngân sách này được phân bổ bởi giai đoạn trong suốt dự án, nhưng mà ở một thời điểm nhất định thì PV xác định lượng công việc vật lý mà đã được hoàn thành. Tổng PV còn được tham chiếu như là Performance Measurement Baseline (PMB). Tổng PV của project còn được biết đến là Budget at Completion (BAC).
  2. EV (Earned Value): là một thước đo công việc thực hiện thể hiện bằng ngân sách phê duyệt cho công việc đó. Đây là ngân sách liên quan đến công việc được phê duyệt đã được hoàn thành. Đối với mỗi thành phần thì EV không thể lớn hơn PV. EV thường được sử dụng để tính toán tỷ lệ phần trăm hoàn thành của project.  Tiêu chuẩn đo lường tiến độ nên được thiết lập cho mỗi thành phần WBS để đo lường tiến độ công việc. PM giám sát EV, gồm cả sự tăng thêm từng bước để xác định tình trạng hiện tại và tình trạng lũy kế để xác định xu hướng hiệu suất trong dài hạn.
  3. AC (Actual Cost): là chi phí thực hiện phát sinh cho công việc thực hiện trên một activity trong một khoảng thời gian cụ thể. Nó là tổng chi phí phát sinh trong việc hoàn thành công việc mà EV được tính toán. AC cần phải tương ứng trong việc xác định những gì đã được dự toán trong PV và được tính toán trong EV. AC sẽ không có giới hạn trên, bất cứ điều gì đã bỏ ra để đạt được các EV đều sẽ được tính toán.

Các công thức tính toán SV, CV, CPI, SPI, TCPI:

Image

Cách nhớ công thức CV, SV, CPI, SPI: lấy EV làm trung tâm:

PMP-exam-Formulas-600x435

Giải thích về kết hợp CPI, SPI:

evm-en

Mô tả trên graph:

Image

Chi tiết về các chỉ số dùng để dự báo (forecasting) như EAC, ETC sẽ được mô tả ở một post khác.

Written by hoantv

June 23, 2013 at 5:03 pm

Posted in 07. Prj Cost Mgt

Direct/Indirect Cost – Chi phí trực tiếp vs Chi phí gián tiếp

leave a comment »

Ngoài Fixed/Variable Cost, buổi thảo luận ngày 2013/6/21 cũng mất thêm khoảng nửa tiến nữa về Direct/Indirect Cost.

Direct/Indirect Cost là việc phân loại chi phí theo phương pháp phân phối chi phí cho một đối tượng chịu chi phí.

  1. Direct Cost (Chi phí trực tiếp): là chi phí liên quan trực tiếp đến đối tượng chịu phí và có thể tính trực tiếp cho đối tượng đó một cách rõ ràng. Nguyên văn định nghĩa tiếng Anh trong PMBok: These costs are attributed directly to the project work and cannot be shared among projects (Ex: Wages, Material, Equipment,…)
  2. Indirect Cost (Chi phí gián tiếp): cũng là loại chí phí liên quan đến đối tượng chịu phí nhưng không thể tính trực tiếp được cho đối tượng chịu phí một cách rõ ràng. Cụ thể, chi phí gián tiếp liên quan đến nhiều đối tượng chịu phí. Do vậy chi phí gián tiếp được phân bổ vào các đối tượng chịu phí theo một phương pháp phân bổ nào đó. Nguyên văn định nghĩa tiếng Anh trong PMBok: Overhead costs that incurred for the benifit of more than one project (Taxes, Training, Project management software licence,…)

direct_indirectcost

Ví dụ:

Chí phí trực tiếp:

  • Ở khía cạnh cty: chi phí dành cho Bộ phận phát triển, sản xuất trực tiếp tạo ra sản phẩm.
  • Ở khía cạnh project: là effort của quản lý (PM + PL + PMO + QA)  + Chi phí trực tiếp phát triển (Developer + Tester) + Chi phí thuê chuyên gia (nếu có) + Chi phí training nghiệp vụ/kỹ thuật đặc thù (nếu có) + Chi phí cài đặt môi trường/mua lisience đặc thù (nếu có) + Chi phí thuê đường truyền/mua sắm thiết bị riêng (nếu có).

Chi phí gián tiếp:

  • Ở khía cạnh công ty: Chi phí cho Ban giám đốc, Bộ phận Admin, HR, IT, Comtor (Về lâu dài mà nói thì Comtor cũng nên được tính vào chi phí trực tiếp là chuẩn bài nhất :)), Chi phí training để nâng cao technical chung cho nhân viên (việc này sẽ làm tăng năng suất của những người được training khi họ tham gia những dự án sau này).
  • Ở khía cạnh project: Chi phí cho Comtor

Written by hoantv

June 22, 2013 at 4:13 pm

Posted in 07. Prj Cost Mgt

Fixed/Variable Cost – Chi phí cố định vs Chi phí biến đổi

with one comment

Buổi thảo luận ngày Thứ 6 (2013/6/21) rất sôi nổi về phân biệt các loại chi phí, mỗi người đều có các ý kiến khác nhau, hoặc là theo kinh nghiệm, hoặc là theo cảm nghĩ.

Riêng mềnh, mặc dù trước đây cũng đã từng đọc qua rồi, tuy nhiên việc quản lý cost chưa thực sự ngấm vào máu, quản lý dự án chủ yếu là đạt tiến độ+chất lượng+delivery ngon là OK roài, nên còn amateur lắm. Mới gần đây thì mới thấy được sức ép về quản lý cost.

Dựa vào cách ứng xử của chi phí theo sự biến đổi của mức độ hoạt động, chi phí của cty thì chi phí được chia làm 2 loại: Fixed cost và Variable cost.

  1. Fixed cost (Chi phí cố định): là các chi phí không thay đổi tùy thuộc vào quy mô sản xuất hoặc doanh thu. Nguyên văn ở PMBok: These costs remain constant throughout the project (Cost of office setup, rentals,…)
  2. Variable cost (Chi phí biến đổi): là các khoản chi phí mà phụ thuộc vào quy mô sản xuất hoặc doanh thu. Nguyên văn ở PMBok: Costs that vary depending on the amount of wok or production (Cost of material, supplies, wages,…)

Image

Ví dụ như ở cty mình thì theo mình những chi phí sau là chi phí cố định:

  • Chi phí thuê văn phòng, gồm 2 tầng của toàn nhà VP khá xịn, chắc cũng tốn phết 🙂
  • Chi phí tiền lương+bảo hiểm cho nhân viên fulltime.
  • Chi phí mua ô tô và thuê lái xe riêng cho sếp 🙂

Chí phí biến đổi:

  • Chi phí cho nhân viên partime, hợp đồng ngắn hạn phải thuê thêm khi cty nhiều việc.
  • Chi phí văn phòng phẩm, nước uống
  • Chi phí mua máy tính cho nhân viên,…

Nếu phân loại chi phí theo đơn vị nhỏ hơn như từng project (cty mình thì thuộc loại balanced matrix) thì chủ yếu là nhìn thấy chi phí biến đổi, ít nhìn ra (hoặc mềnh chưa nhìn ra) chí phí cố định:

  • Chi phí quản lý dự án (PM/PL/PMO/QA)
  • Chi phí cho developer, tester.
  • Chi phí thuê chuyên gia support.

Các loại chi phí này thì rõ ràng là tỷ lệ thuận với quy mô của project roài.

Image

Để đánh giá hoạt động hiệu quả thì:

  • Ở khía cạnh cty nói chung: Doanh thu >= Chi phí cố đinh + Chi phí biến đổi.
  • Ở khía cạnh project nói riêng: Total Estimated Effort >= Actual Effort (bao gồm cả chi phí quản lý.

Written by hoantv

June 22, 2013 at 3:41 pm

Posted in 07. Prj Cost Mgt

Network Diagram Method và áp dụng trong thực tế?

leave a comment »

Theo PMBok thì Network Diagram (còn được gọi là Project Schedule Network Diagram) là một thành phần không thể thiếu trong khi tạo schedule: là output của Sequence Activities process.

Network Diagram chỉ thể hiện các sự phụ thuộc về logic (logical relationship) giữa các hoạt động của dự án.

Phương pháp Network Diagram áp dụng lý thuyết đồ thị có hướng (cấu trúc mạng lưới) vào trong các thuật toán để lập kế hoạch tiến độ và tổ chức thực hiện dự án.

Ví dụ đơn giản sau đây là một Network Diagram:

Image

Có nhiều phương pháp sơ đồ mạng đã được phát triển, dưới đây là một số phương pháp chính hay nhắc đến:

  1. CPM (Critical Path Method): là phương pháp xác định đường đi dài nhất trong network tính từ thời điểm khởi công đến thời điểm kết thúc dự án. Đường đi dài nhất (hay còn gọi là Đường găng) chính là tổng thời gian thực hiện dự án.
  2. PERT (Project Evaluation and Review Technique): là phương pháp áp dụng kết hợp giữa lý thuyết xác suất thống kê (để ước tính thời lượng của công việc) với dạng sơ đồ mạng đường găng (CPM) sử dụng lý thuyết đồ thị.
  3. ADM (Arrow Diagram Method): là phương pháp sơ đồ mạng CPM thể hiện activity bằng mũi tên. Loại này chỉ thể hiện được mối quan hệ FS (Finish to Start).
  4. MPM (Metra Potential Method): là phương phá sơ đồ mạng CPM thể hiện activity bằng nút (node), quan hệ giữa các nút bằng mũi tên (do người Pháp phát triển độc lập với PERT vào năm 1958).
  5. PDM (Precedence Diagram Method): là phương phá sơ đồ mạng CPM thể hiện activity bằng nút (node), quan hệ giữa các nút bằng mũi tên do Mỹ phát triển trên cơ sở cải tiến phương pháp CPM của Hoa Kỳ và MPM của Pháp. Phương pháp này chú trọng đến việc thể hiện tất cả các mối quan hệ trên thực tế giữa các activities mà phương pháp ADM không thể hiện được. Phương pháp PDM là cơ sở thuật toán cho phần mềm Microsoft Project.
  6. CCM (Critial Chain Method): sơ đồ mạng chuỗi găng.

Chi tiết về các phương pháp sơ đồ mạng thì mỗi cái sẽ có một topic riêng.

Quay trở lại về việc áp dụng trong thực tế như thế nào cho hợp lý ở các dự án phát triển phần mềm?

Trong dự án phát triển phần mềm, một trong công việc quan trọng nhất mà chúng ta thường tập trung vào làm rõ trong giai đoạn lập kế hoạch là Xác định phạm vi dự án (Define Scope). Một trong những tài liệu quan trọng phải tạo được ra là WBS (Work Breakdown Structure). Mục chi tiết nhất trên WBS gọi là gói công việc (work package).

Từ WBS này chúng ta sẽ tạo ra được 2 loại sơ đồ, một cái ở mức tổng thể (master) và một cái ở mức chi tiết (detail).

Hình sau mô tả sự mapping giữa WBS và Network Diagram:

Image

Tiếp theo ở giai đoạn tạo schedule, bạn thường phải tạo 2 loại schedule sau mà buộc phải lấy kết quả từ Network Diagram:

  1. Master Schedule
  2. Detail Schedule

Bạn cũng có thể nói là tôi chả bao giờ tạo Network Diagram mà các dự án mà tôi từng làm PM đều thành công đó thôi. Đúng, bạn có thể đúng. Theo tôi lý do bạn đúng bởi vì (1) bạn là người nhiều kinh nghiệm và (2) các dự án đó thường là quy mô nhỏ, ít phức tạp mà thôi.

————————————————-

Chia sẻ thêm: Để mà tạo ra được một tài liệu schedule đầy đủ, chi tiết, và nhất là chính xác ngay từ sớm là việc rất khó vì rất nhiều lý do, đại loại như:

  1. Mức độ rõ ràng của estimate: thời gian đầu rất khó để mọi thứ sẵn sàng cho bạn xơi ngay.
  2. Scope cũng hay bị thay đổi: thêm/bớt/update work package.
  3. Resource cũng không phải sẵn sàng ngay từ đầu.
  4. Change request: cái này cũng hay có trong suốt dự án.
  5. Risk: cái này cũng là một phần tất yếu trong suốt dự án và rất đau đầu.

Written by hoantv

June 20, 2013 at 5:54 pm

Posted in 06. Prj Time Mgt

Padding – Vấn đề đáng suy nghĩ.

leave a comment »

Trong mọi dự án thì đều có những phần mà chúng ta biết và phần không biết, gọi là Knowns và UnKnowns. Đại khái là 2 phần này được tổ chức như hình dưới.

Image

Cái mà thuộc nhóm “Knowns Knowns” thì là những cái đã có trong kế hoạch của PM rồi.

Nhưng vấn đề rắc rối là ở những cái còn lại, vấn đề thêm thời gian, chi phí (padding) vào chính là những chỗ này. Hay nói cách khác, padding thường xảy ra như là một phản ứng tự nhiên ở những chỗ mà PM/ team member chưa biết rõ ràng.

Điều này dẫn đến hệ quả là gì? Chính là dẫn đến các rủi ro, cơ hội đã bị che dấu đi, việc mà đáng lẽ ra người estimate cần phải nhận diện rõ ràng công khai cho PM biết.

Không thể đòi hỏi một dự án phải biết hết mọi thứ ở một thời điểm (nhất là khi tạo kế hoạch), nhưng nguyên tắc chung là phải đảm bảo tất cả những phần chưa biết đều phải được nghiên cứu, phân tích kỹ lượng, dự phòng thông qua tiến trình quản lý rủi ro (Risk Management Process). Thông qua tiến trình quản lý rủi ro, những phần chưa biết sẽ được nhìn nhận, đánh giá như những điểm xấu (Threats), hoặc thậm chí là cơ hội tốt (Oppoturnities).

———————————————————————————————————

Dưới đây là một bài sưu tầm trên Internet về Padding:

MANAGING PADDING IN TIME ESTIMATES

Một trong những công việc “khó nhằn”, mà cũng dễ mắc sai lầm nhất của PM trong giai đoạn tạo schedule là estimate thời gian.

Trong thực tế, hầu hết developer hoặc PM đều có xu hướng add thêm thời gian vào các estimate của họ, và vấn đề này gọi là “Padding”.
Có 2 nguyên nhân dẫn đến vấn đề này:
1. Do sức ép từ phía management là hãy rút ngắn duration của dự án, điều này dẫn đến việc rút ngắn schedule một cách không khả thi. Đôi khi (thường là do những người trẻ, thiếu kinh nghiệm) cứ bị cuốn theo luồng của sức ép tôi ưu này và tạo ra các estimate không khả thi. Là PM, có vẻ bạn cũng đã biết điều này. Và sau đó, khi tạo schedule, bạn thường add thêm một tỷ lệ % nào đó (ví dụ 10%, 15%, 20%,…) để tạo một cảm giác gọi là an toàn, kể cả là khi phía management đã rút ngắn schedule của bạn rồi.
2. Khác hẳn nguyên nhân trên, bây giờ member của bạn đều là những người có đủ kinh nghiệm, nhưng cũng chính vì lẽ này mà mà họ đã estimate cho cả việc phía management cắt giảm estimate của họ đi. Sau khi estimate thì họ tự thêm “padding” vào và làm cho estimate của họ trở lên dài hơn (không khả thi). Bằng cách này thì họ muốn chắc chắn là sau khi bạn (PM) và phía management rút ngắn schedule thì họ vẫn đủ khả năng để hoàn thành nhiệm vụ của mình.

Các câu hỏi cần PM trả lời được trong vấn đề này là:
1. PM có biết team member tạo esimate như thế nào không?
2. PM có thể phán đoán là estimate của team member chính xác hay không?
3. PM có biết họ đã estimate duration của các task một cách tối ưu rồi, hãy là họ đã thêm thời gian dự phòng (padding) vào rồi?
4. PM có tinh chỉnh, chỉnh sửa estimate của team member không?
5. Bạn có thêm padding khi biết rằng management sẽ rút ngắn schedule và đặt bạn vào một “Impossible Mission”? Hoặc thậm chí bạn tự rút ngắn schedule khi bạn biết là team member của bạn đã thêm thời gian dự phòng (padding) rồi?

Suy nghĩ sâu hơn thì một câu hỏi rất nghiêm trọng phát sinh:
Việc trao đổi ý kiến, quan điểm trong tổ chức của bạn (team member với bạn, bạn với management) một cách trung thực hay không? Hay là mọi người đều đang cố gắng lừa dối nhau?

http://pmstories.com/2007/09/14/managing-padding-in-time-estimates/

Written by hoantv

June 17, 2013 at 5:48 pm