Why Become a Project Manager

Why has project management become a sought after career path? Well, project management has evolved significantly over time and as the nature of industry has changed the role of project manager has become more important.

Nowadays advances in technology, the changing emphasis of environmental impacts and the evolution of industry have made projects a fundamental aspect of the workplace. Whether it’s a small project to identify a new way of working, a process amendment within a team or a multi-billion dollar infrastructure programme project management plays a key role.

Good project managers are sought after across industries. Often pay rates are incredibly high, especially when project managers can also bring industry experience. Furthermore demand for project managers is global and demand for transferable skills is high. Although project workers are often on temporary contracts, the nature of the projects means they should have little problem finding a new role when a project comes to an end.
What is the added value of having a Project Manager?

As industries and trading environments change there are risks to organisations. Quite often the project acts as a tool helping an organisation to evolve through changes and discover a new way of doing things. The activities that manage change processes, the launch of new products and services or the integration of new processes are themselves full of risk. The project manager adds value by ensuring that these risks are kept to a minimum.

By allowing the project manager to plan effectively and identify risks up front the organisation is able to find the steps its needs to take through the project. Highlighting goals and setting a critical path will allow the organisation to clearly see how it will get to where it wants to be. The project manager is there to ensure that such risk occurrences do not take place and that changes are integrated effectively.


10 reasons to become a Project Manager

1. Demand
Project Management is a skill in demand. As businesses shape themselves for the future more of their operations are being driven through projects. Something that is fashionable tomorrow may not be relevant next week.

2. Money
For good project managers there are ample opportunities available in the market and plenty of money on offer. A top quality project manager in the UK with industry specific experience alongside project management skills can potentially demand a salary of £75k and above.

3. Prospects
Not only do project managers earn great salaries but there is scope for growth. No matter how big a project you are working on there are always bigger projects coming up with more responsibility. Career wise the sky is the limit for top class project managers.

4. People
As a project manager one of the main aspects of your role will be to look after and manage various stakeholders. Whether it’s other project staff, company directors, community stakeholders or suppliers you’ll be working around people all the time.

5. Travel
Global travel is definitely a bonus for project managers. As well as the UK, Europe and the States there is huge demand for project managers in Brazil, Russia, India and China (BRIC) as well as demand down under and across the developing world.

6. Sectors
For many project managers sector specialisms are not important. For others, particularly sectors such as IT, Technology and Construction, industry knowledge is incredibly useful and can help you find a niche for yourself.

7. Leadership and Management
If you are the sort of person who naturally takes on leadership and management positions within a group project management will help you to further these skills as you will be responsible for driving the performance of other members of the project team.

8. Results Driven
For those who enjoy seeing the tangible outputs of work then project management is for you. The project, with its strict time, cost and outcome parameters will very clearly allow you to see the fruits of your labour.

9. Responsibility
Project management is not for the faint hearted. From the start you will be a figurehead of the project and handed responsibility. If you like pressure then project management is for you.

10. Change
No two days are the same in project management. Each day you’ll be given different challenges. As a project manager who enjoys change this is the role for you.

10 reasons why businesses should be thankful for a Project Manager

1. Results Orientated
The most important aspect of the project manager is the focus that they bring to the role. They will make goals tangible and add processes that ensure projects are delivered on time and to budget.

2. Understand Deadlines
If you need something doing by a certain date then ask a project manager. They are specialists in timelines and understand the important tasks to ensure the job gets done.

3. Financially Astute
As budgets play such a fundamental role in project management you can trust your project manager to keep a keen eye on the numbers. No more overspend when the project manager is in charge.

4. People
One of the fundamental skills of a project manager is to engage people to work towards the shared goal of the project. As managers they can do the job of motivating staff for you.

5. Great Communicators
Not only are project managers great with staff, they’re also great with stakeholders. When a project is particularly controversial project managers will manage relationships with community stakeholders on your behalf.

6. Risk Managers
A great project manager will scan through the project with a fine-toothed comb and identify any risks to ensure the project runs smoothly.

7. Team Players
When they have to the project manager will knuckle down and help the team. It’s this kind of attitude that helps to earn respect.

8. Hard Workers
Project managers know that sometimes, especially as a project draws to a close they may have to put in those important extra hours. Project Managers are often the most hardworking people you’ll meet.

9. Flexible
The nature of the project manager role means that flexibility is the norm. Whether its travel, start times or other challenges you can rely on the project manager to be flexible.

10. Change Masters
Finally, as change is such an important aspect of projects, project managers thoroughly understand the importance of change. This knowledge could be vital in a business.

Project Management is a dynamic and exciting career. If you are looking for a different challenge every day then Project Management could well be the career for you.

Source url: https://courses.telegraph.co.uk/article-details/2/why-become-a-project-manager/

Ground rules to set you up for success

Project management, today, has many challenges – the most important being people management. Managing people is not an easy task. Conflicts crop up among people everyday.

So what is the solution? 

It’s simple – effective utilization of team ground rules.

Ground rules are policies and guidelines which a group establishes consciously to help individual members decide how to act. To be effective, ground rules must be clear, consistent, agreed-to, and followed.  Team ground rules define a behavioral model which addresses how individuals treat each other, communicate, participate, cooperate, and support each other in joint activities.

A team should create and adopt written ground rules in the project planning stage. They should be added to and revised as and when required. Every project has a unique team and functional structure. Ground rules need to be defined considering project organization in detail. A few factors to be considered are:

– Team location: Location of the team is essential in defining ground rules. A combination of stationary and virtual teams would require additional ground rules.

– Team ethnicity: Consider the ethnicity of the team members and add few ground rules for effective team work.

– Project duration: Ground rules are important for any project irrespective of  the length of the project. Consider the length of the project for defining urgency of implementation.

– Team skills and expertise: Team members should have a mix of skills and expertise in the domain to ensure the success of a project.

Project meeting

  • Be on time for all team meetings.
  • Team leader must create and disseminate agendas for each team meeting.
  • Team leader must create and disseminate minutes after each team meeting.
  • Attend full duration of all team meetings unless a case of emergency.
  • Avoid informal/social talk during team meetings.
  • Build in brief informal/social talk time before or after team meetings.
  • Be patient with alternative viewpoints, different kinds of learners, writers, & speakers.
  • No responsibilities to be assigned unless the person who is being assigned the responsibility accepts it. If a person to be given a responsibility is not at the meeting, the team leader must review that assignment or action item with the person before the responsibility is designated.
  • Set aside a regular weekly meeting time that’s kept open by all members from week to week. Keep the meeting schedule flexible, arranging meetings as needed and based on availability. Project decisions
  • Require consensus on all major team decisions. Avoid apathetic/passive decision making (e.g., “whatever you all think is right”).

 Project delivery

  • Inform team leader if unable to complete work on time.
  • Seek reader/listener feedback before handing in all deliverables.

Set deadlines for each deliverable in advance of due date to allow for collaborative revisions.

Team attitude and culture

  • Rotate responsibilities so each person gets experience with several aspects regardless of quality or qualifications.
  • Make criticisms constructive with suggestions for improvement and non-judgmental language.
  • Confront issues directly and promptly.
  • Promptly relay all interpersonal concerns/conflicts to team leaders.
  • Keep a positive attitude toward the team, individual members, projects and course.
  • Take initiative by offering ideas and volunteering for tasks.
  • Play an equal role in  the team by contributing equally to every task.
  • Be honest with any team member who is not pulling her/his weight.
  • Help one another with difficult or time consuming deliverables.
  • Ask for help from the team or other resources if “stuck” or falling behind.
  • Treat each other with respect.
  • Accept responsibility and accountability along with the authority given.

About the Author

Mahendra Gupta is a PMP and ISEB certified IT Consultant based in United Kingdom with more than 12+ years of experience in Business System Analysis and IT Project Management of wide range of projects within Banking and Trust Business sector.

source link: https://www.simplilearn.com/rules-to-set-you-up-for-success-article

Thuật ngữ quản trị dự án (st)


Thuật ngữ Nghĩa tiếng Việt
Acceptance là gì ? Đây là một chiến lược trong tiến trình hoạch định phương án đối phó rủi ro. Khi sử dụng chiến lược này, tổ chức sẵn sàng chấp nhận các hậu quả mà rủi ro gây ra nếu nó xảy ra
Acceptance Criteria là gì ? Là những tiêu chuẩn bao gồm các yêu cầu trong quá trình thức hiện và các điều kiện phải được tuân thủ và hoàn thành trước khi bàn giao dự án được chấp thuận.
Acquire Project Team là gì ?  Có được nhóm dự án: Một quy trình nhằm mục đích xác nhận lại lực với bên bộ phận quản lý nguồn nhân lực rằng nguồn nhân lực cần thiết đã được bố trí đủ để hoàn thành dự án.
Activity là gì ? Một thành phần của công việc thực hiện trong quá trình của một dự án.
Activity Attributes là gì ?  Nhiều thuộc tính với mổi thuộc tính được gán vào lịch trình công việc và có thể bao gồm trong bảng liệt kê Activities. Thuộc tính của Activity bao gồm: Mã Activity, Công việc trước đó, công việc sau đó, mối quan hệ, thời gian chéo nhau, yêu cầu về nguồn lực, ngày khả thi, các ràng buôc và các giả định.
Activity Code là gì ? Được tạo thành từ một hoặc nhiều ký tự, con số dùng để nhận biết đặt điểm công việc hoặc để phân loại lịch trình các Activities cho phép dễ dàng yêu cầu hoặc tìm kiếm Activities đó.
Activity definition là gì ? Đây là tiến trình xác định các công việc cần thiết để tạo nên sản phẩm hay dịch vụ của dự án
Activity duration là gì ? Thời gian cần thiết để hoàn thành một công việc
Activity Identifier là gì ? Là một ký tự hay con số dùng để nhận dạng được gán vào mổi Activity nhằm phân biệt giữa các Activities với nhau trong dự án. Thông thường nó duy nhất trong một sơ đồ dự án.
Activity list là gì ? đây là một dạng mở rộng của WBS, nó chứa tất cả các công việc của dự án và bản mô tả cho từng công việc. danh sách công việc là kết quả của tiến trình xác định cộng việc
Activity squence là gì ? sắp xếp công việc theo một trình tự logic và xác định xem thử liệu có mối quan hệ phụ thuộc giữa các công việc
Actual cost là gì ? là khoản chi phí thực tế đã phát sinh cho đến thời điểm xem xét, bao gồm cả chi phí trực tiếp và gián tiếp, thường được viết tắt là AC
Actual Duration là gì ?  Là đơn vị thời gian lịch trình một activities giữa ngày bắt đầu thực tế của lịch trình công việc với ngày cập nhật (data date) của tiến độ dự án so được so sánh với ngày kết thúc của một activity. (Thời lượng thực tế (Actual Duration) còn được đo bằng đơn vị giờ, ngày, tháng, năm.))
Administer Procurements là gì ? Quá trình quản lý mối liên quan trong mua sắm, thực hiện hợp đồng giám sát và kiểm soát các thay đổi và chỉnh sửa khi cần thiết.
Alternative identification là gì ? là một kỹ thuật để phát hiện ra các phương pháp hay các cách thức khác để hoàn thành dự án. Đây là một công cụ trong tiến trình hoạch định phạm vi.
Analogous estimating là gì ? sử dụng dữ liệu của dự án đã hoàn tất trước đó để ước tính co dự án hiện tại
Application Area là gì ?  Lĩnh Vực Ứng Dụng, Một loại dự án có các thành phần tương tự phổ biến đáng kể xảy ra trong các dự án, nhưng không nhất thiết phải  hiện diện trong tất cả các sản phẩm. Lĩnh vực ứng dụng thường được xác định về sản phẩm (ví dụ, công nghệ tương tự hoặc các phương pháp sản xuất giống nhau) hoặc các loại khách hàng (ví dụ, hông tin nội bộ so với bên ngoài, chính phủ so với thương mại) hoặc trong các ngành công nghiệp (ví dụ như các tiện ích, ô tô, hàng không vũ trụ, thoặc các ngành công nghiệp công nghệ, vv). Các lĩnh vực ứng dụng có thể chồng chéo lên nhau.
Appraisal cost là gì ? là một loại chi phí chất lượng liên quan đến việc kiểm tra sản phẩm hay tiến trình để đảm bảo rằng đáp ứng được các yêu cầu của dự án
Approved Change Request là gì ?  Một yêu cầu thay đổi đã được xử lý qua quy trình kiểm soát tích hợp sự thay đổi và được chấp thuận.
Assumptions là gì ? là các sự kiện hay điều kiện mà người lập kế hoạch tin rằng đúng, sẽ xảy ra. các giả định của dự án phải luôn được ghi lại bằng văn bản
Authority là gì ? Là quyền để  áp dụng quản lý nguồn lực của dự án, nền tảng ra quyết định, hoặc để phê duyệt một việc nào đó.
Avoidance là gì ? là một tong chiến lược đối phó rủi ro, chiến lược này đòi hỏi phải thay đổi kế hoạch dự án để tránh hoặc loại bỏ các sự kiện gây rủi ro và tác động của sự kiện này với mục tiêu dự án.
BAC là gì ? Là tổng của tất cả ngân sách đã dùng cho việc thực hiện công việc trong một dự án, hoặc WBS hay Activity. Nó cũng được xem như tổng giá trị kế hoạch cho dự án.
Backward pass là gì ? là một phép tính trong sơ đồ kỹ thuật mạng nhằm xác định các thời điểm bắt đầu muộn và kết thúc muộn của các sự kiện và công việc.
Balance matrix là gì ? là một hình thức tổ chức dự án trong đó quyền lực của nhà quản trị dự án và quyền lực của nhà quản trị chức năng được cân bằng
Baseline  là gì ? Là kế hoạch của dự án được chấp thuận, có thể chẩn nhận một sai số thêm vào hoặc bớt đi. Nó là cơ sở để so sánh quá trình thực hiện công việc so với kế hoặc đề ra với sai số cho phép. Thường được tham khảo so sánh với với baseline ở thời điểm hiện tại. Nhưng cũng có thể được so sánh với bản gốc. Thường được sử dụng với một vài sửa đổi (ví dụ, Đường cơ sở chi phí thực hiện, Đường cơ sở tiến độ , Đường cơ sởđo lường hiệu suất , Đường cơ sở kỹ thuật )
Baseline  là gì ? Kế hoạch gốc, kế hoạch đã được phê duyệt nhằm làm cơ sơ đo lường tiến triển của dự án, baseline thường là các kế hoạch bạn đầu về phạm vi, chi phí, thời gian…đã được phê duyệt trong các tiến trình hoạch định. Khi dự án thực hiện, người kiểm soát sẽ đo lường tình hình thực tế để đánh giá xem thực tế có tiến triển theo đúng kế hoạch hay không. Các thay đổi lớn về phạm vi, chi phí hay thời gian đôi khi đòi hỏi phải thay đổi baseline
Benchmarking là gì ? so sánh các công việc của dự án hiện tại với các công việc của dự án tương tự trước đó để đưa ra một tiêu chuẩn nhằm đánh giá tình hình thực hiện. công cụ này thường được dùng để cải thiện tình hình chất lượng trong dự án.
Bennefit measurement mehods là gì ? là một nhóm các phương pháp để lựa chọn dự án. các phương pháp này dùng nhiều cách tiếp cận để so sánh và phân tích nhằm đưa ra quyết định lựa chọn . nằm trong nhóm này gồm phương pháp: phân tích lợi nhuận/chi phí, mô hình cho điểm,…
Bottom-up Estimating là gì ?  Phương Pháp Ước Lượng Từ Dưới Lên: Một phương pháp ước lượng một thành phần của công việc. Công việc được chia nhỏ vào chi tiết hơn. Một ước tính từ những gì cần thiết để đáp ứng các yêu cầu của công viêc ở cấp độ nhỏ hơn, phần chi tiết hơn về công việc, và các ước tính này sau đó được tổng hợp thành một tổng số lượng cho thành phần công việc. Độ chính xác của dự toán từ dưới lên là dựa vào kích thước và độ phức tạp của công việc được xác định ở cấp thấp hơn và tổng hợp lên.
Brainstorming là gì ?  Một tập hợp dữ liệu nói chung và kỹ thuật sáng tạo có thể được sử dụng để xác định các rủi ro, ý kiến, hoặc giải pháp cho các vấn đề bằng cách sử dụng một nhóm các thành viên trong nhóm hoặc các chuyên gia. Thông thường, một phiên làm việc động não có cấu trúc sao cho mỗi người tham gia ý tưởng được ghi lại để phân tích sau đó.
Break-even analysis là gì ? là một kỹ thuật để phân tích đánh giá lựa chọn dự án, trong đó cân nhắc mối quan hệ giữa chi phí biến đổi của một dự án. tỉ lệ chi phí cố định càng lớn thì sản lượng (doanh thu) hoà vốn càng lớn và mức độ rủi ro cao.
Budget là gì ?  Là ngân quỹ dự toán cho dự án được chấp thuận hoặc cho WBS hoặc một và lịch trình công việc. Tham khảo thêm Estimate.
Budget at Complettion (BAC) là gì ?
Buffering là gì ? đây là kỹ thuật sắp xếp tiến độ trong đó định thêm một khoảng thời gian dự phòng cho từng công việc hoặc cho toàn bộ dự án.
Bussness case là gì ? là tài liệu đầu tiên được xây dựng để đề xuất ý tưởng về dự án với các thành phần cốt lõi: các cơ hội, các đe doạ làm phát sinh dự án,mục tiêu mà dự án hướng tới và sự phù hợp giữa mục tiêu này với các mục tiêu khác của tổ chức, mong muốn của các nhóm liện quan, các giả định, các ràng buộc…
Buyer là gì ? Là người thực hiện việc thâu mua các sản phẩm, dịch vụ, hoặc kết quả cho một tổ chức.
Cause and effect diagram là gì ? là  biểu đồ biểu diễn mối quan hệ giữa các nguyên nhân của vấn đề và tác động mà vấn đề này gây ra. biểu đồ bắt đầu từ nguyên nhân chung nhất và tiếp tục xem xét các nguyên nhân cụ thể hơn dân đến vấn đề đó. biểu đồ này còn được gọi là biểu đồ xương cá hay Ishikawa.
Change control system là gì ? là các thủ tục mô tả cách thức đệ trình một yêu cầu thay đổi và xử lý các yêu cầu thay đổi. Hệ thống này theo dõi trạng thái của các yêu cầu và xác định mức thẩm quyền phê duyệt tháy đổi đó. hệ thống cũng mô tả tác động của thay đổi với tình hình thực hiện dự án.
Check list là gì ? là công cụ thường dùng trong quản trị chất lượng để đảm bảo rằng các bước trong một tiến trình nào đó được tuân thủ nghiêm ngặt. Công cụ này cũng được sử dụng để xác định các rủi ro bằng cách thu thập các thông tin lịch sử từ các dự án trước đó.
Code of account là gì ? là một số hiệu duy nhất được phân cho từng phần từ trong WBS
Communication là gì ? là tiến trình trao đổi thông tin, trong đó có ba thành phần cơ bản là người gởi tin, người nhận tin và thông điệp. Truyền thông có thể diễn ra dưới hình thức nói hay viết, chính thức hay phi chính thức. nhà quản trị dự án có thể sử dụng đến 90% quỹ thời gian của mình cho công tác truyền thông.
Communication management plan là gì ? kế hoạch quản trị truyền thông – là trong đó chỉ rõ những loại thông tin nào mà các nhóm hữu quan cần, khi nào thông tin sẽ được phân phát cà cách thức phân phát,…
Communication planning là gì ? là tiến trình xác định rõ nhu cầu truyền thông của các nhóm hữu quan, các thông tin được tiếp nhận khi nào và như thế nào và ai sẽ nhận thông tin.
Configuration management là gì ? quản trị cấu hình – là tiến trình mô tả các đặc điểm của kết quả dự án và đảm bảo rằng các kết quả này là chính xác đầy đủ . quản trị cấu hình kiểm soát sự thay đổi đối với các đặc điểm của một đối tượng và theo dõi sự thay đổi đã được thực hiện hay được yêu cầu và trạng thái của các thay đổi đó. đây thường là một phần của tiến trình kiểm soát sự thay đổi.
Conflict là gì ? mâu thuẫn – là sự không tương thích về mục tiêu hoặc lợi ích giữa các nhóm hữu quan của dự án. môi trường làm việc của dự án thường được đặc trưng bởi tính mâu thuẫn.
Constraint là gì ? ràng buộc – là bất cứ một yếu tố nào giới hạn hành động của nhóm dự án hoặc bắt buôc, quy định hành động của nhóm dự án.
Constrainted optimization method là gì ? là mô hình lựa chọn dự án gồm các mô hình toán học phức tạp, sử dụng các thuật toán tuyến tính, linh hoạt, phi tuyến tính,…để giải quyết một vấn đề cụ thể nào đó.
Contingency reserves là gì ? dự phòng cho dự án – đây là chiến lược đối phó rủi ro nhằm tạo ra một quỹ dự phòng về chi phí, thời gian hay nguồn lực để bù trừ cho các đe doạ không thể tránh khỏi và có thể xảy ra đối với tiến độ, chi phí, chất lượng hay phạm vi dự án
Contract là gì ? hợp đồng – là tài liệu ràng buộc pháp lý giữa hai hay nhiều bên nhằm để có một sản phẩm hay dịch vụ nào đó. hợp đồng thường là tài liệu phổ biến nhất trong quá trình mua hàng của dự án.
Contract administration là gì ? tiến trình giám sát năng lực của nhà cung cấp và đảm bảo rằng các yêu cầu của hợp đồng được đáp ứng đầy đủ.
Contract close-out là gì ? tiến trình hoàn tất và thanh tán tât cả các khoản của hợp đồng và xác định xem công việc được mô tả trong hợp đồng đã được hoàn tất chính xác và đạt yêu cầu chưa. đây là tiến trình được thực hiện trước kho kết thuc dự án.
Control chart là gì ? biểu đồ kiểm soát – là một công cụ trong tiến trình kiểm soát chất lượng để đo lường kết quả của các tiến trình theo thời gian và biểu diễn các kết quả này dưới dạng đồ thị. Biểu đồ kiểm soát cũng đo lường các sai lệch nhằm xác định xem mức độ sai lệch đó có nằm trong giới hạn kiểm soát hay không.
Corrective actions là gì ? là các hành động được thực hiện nhằm điều chỉnh kết quả dự kiến của dự án đề phù hợp  với kế hoạch đề ra.
Cost bugeting là gì ? lập ngân sách cho dự án – là tiến trình phân bổ các chi phí đã ước lượng cho các hoạt động để từ đó lập nên kế hoạch gốc về chi phí (cost baseline). kế hoạch gốc này sẽ được dùng để đo lường các sai lệch và tình hình thực hiện trong suốt vòng đời của dự án.
Cost control là gì ? kiểm soát chi phí – tiến trình quản lý các thay đổi đối với chi phí của dự án bằng hệ thống kiểm soát thay đổi chi phí.
Cost estimating là gì ? ước lượng chi phí – tiến trình đưa ra một con số ước lượng về chi phí của các nguồn lực cần thiết cho tất cả các công việc trong dự án.
Cost of quality là gì ? chi phí chất lượng – tổng chi phí để sản xuất ra một sản phẩm hay dịch vu sao cho phù hợp với tiêu chuẩn về chất lượng. chi phí này bao gồm tất cả các công việc cần thiết để đáp ứng được các yêu cầu của sản phẩm, cũng như chi phí của các công việc phải làm do không phú hợp (non conformance(, do yêu cầu chất lượng. chi phí chất lượng liên quan đến ba loại chi phí: chí phí ngăn ngừa, chi phí đánh giá và chi phí sai hỏng.
Cost perfomance index (CPI) là gì ? chỉ số hiểu quả chi phí, là một chỉ số được tính toán trong phân tích giá trị thu được với công thức sau CPI=EV/EC
Cost plus fixed contract là gì ? hợp đồng chí phí cộ định cộng với một khoản phí – là loại hợp đồng mà khách hàng sẽ chi trả toàn bộ chi phí của dự án cộng với một mức phí cố định khi kết thúc hợp đồng.
cost reimburable contract là gì ? hợp đồng hoàn trả chi phí – là hợp đồng mà người mua sẽ chi trả cho người bán toàn bộ chi phí phát sinh, khi sản xuất hàng hoá hay dịch vụ
Cost variance (CV) là gì ? là môột thông số sử dụng trong phân tích giá trị thu được để đo lường mức hiệu quả về chi phí với công thức CV=…
Crashing là gì ? là một kỹ thuật rút ngắn thời gian thực hiện công việc bằng cách bổ sung thêm nguồn lực cho các công việc trên đường găng
Critical path là gì ? là một đường trong sơ đồ mạng tập hợp các công việc có thời gian dự trữ bằng zero.
Critical path method là gì ? là phương pháp tính toán tiến độ bằng cách xác định thời gian  bắt đầu sớm, kết thúc sớm, bắt đầu muộn, kết thúc muộn cho mỗi công việc trong dự án.
Critical sucess factor là gì ? các yếu tố then chốt cho sự thành công của dự án – các yếu tố cần phải được thực hiện để dự án có thể được hoàn tất.
Decision models là gì ? mô hình ra quyết định – các mô hình được dùng để lựa chọn dự án, bằng cách xem xét các tiêu chuẩn khác nhau nhằm đưa ra quyết định lực chọn.
Decision tree analysis là gì ? là kỹ thuật được sử dụng trong phân tích rủi ro của dự án trong đó xét đến các tình huống với xác xuất xảy ra của từng tình huống và kết quả mà tình huống đó mang lại. mỗi tình huống lại được chia thành các tình huống nhỏ hơn với các xác xuất và mức tác động tương ứng.
Decomposition là gì ? là tiến trình chia nhỏ các kết quả của dự án thành các bộ phận nhỏ hơn, dễ quản lý hơn sao cho các công việc, các nhiệm vụ của dự án có thể ước lượng được, lập kế hoạch được.
Deliverable là gì ? là một kết quả hay một đầu ra mà một giai đoạn của dự án hay dự án cần phải tạo ra. các kết quả này phải hữu hình, có thể đo lường và được chứng minh.
Delphi method là gì ? là một kỹ thuật dùng để thu thập thông tin trong xác định rủi ro dự án, trong đó những người tham gia thường không biết nhau hoặc không cần phải có mặt cùng một nơi.
Dependencies là gì ? mối quan hệ phụ thuộc giữa các công việc trong một dự án
Discretionary dependency là gì ? là mối quan hệ phụ thuộc  tuỳ chọn, do người lập kế hoạch quyết định. mối quan hệ này còn gọi là mối quan hệ phụ thuộc mềm.
Duration compression là gì ? rút ngắn thời gian – là một công cụ trong tiến trình xây dựng tiến độ, trong đó các phân tích toán học được sử dụng để rút ngắn tiến độ dự án mà không ảnh hưởng đế phạm vi dự án. Hai phương pháp phổ biến là crashing và fast tracking.
Earned value là gì ? đo lường tiến triển của dự án đến thời điểm xem xét hoặc giá trị của công việc đã được hoàn tất cho đến thời điểm xem xét.
Earned value analysis là gì ? phân tích giá trị thu được – là kỹ thuật phổ biến để đo lường hiệu quả dự án. Kỹ thuật này xem xét các đo lường về tiến độ, chi phí và phạm vi và so sánh tiến triển thực tế với các tiến triển kỳ vọng
Planned Value (PV) là gì ?  Kế Hoạch Giá Trị: Ngân sách được duyệt được dùng cho kế hoạch phân bổ cho công việc dựa vào lịch trình thực hiện của activity hoặc WBS. Cũng được gọi là chi phí ngân sách công việc theo lịch trình (BCWS).
Estimate at completion (EAC) là gì ? ước lượng tại thời điểm hoàn thành – ước lượng chi phí kỳ vọng của dự án hay công việc vào thời điềm hoàn thành công việc
Estimate to compleate (ETC) là gì ? ước lượng cần phải hoàn thành – thông số đ lường chi phí cần thêm để hoàn tất công việc.
Evalution criteria là gì ? tiêu chuẩn đánh giá – phương pháp chia điểm và xếp hạng các nhà cung cấp trong tiến trình quản trị mua sắm.
Expert jugdement là gì ? đánh giá của chuyên gia – là một công cụ của nhiều  tiến trình hoạch định. công cụ này dựa trên một cá nhân hay một nhóm có kiến thức và kinh nghiệm liên quan đến lĩnh vực cần xin ý kiến đánh giá.
External dependency là gì ? các mối quan hệ phụ thuộc giữa các công việc do các bên không nằm trong dự án tác động.
Extinction là gì ? một hình thức kết thúc dự án khi mà các công việc dự án đã được hoàn thành và được các bên hữu quan chấp nhận.
Failure cost là gì ? chi phí trục trặc – là một khoản chi phí chất lượng phát sinh khi nảy sinh khi phát sinh vấn đề và dự án không tiến triển theo kế hoạch
Fast tracking là gì ? sắp xếp các công việc song song – là một kỹ thuật rút ngắn thời gian thực hiện dự án bằng cách sắp xếp các công việc song song với nhau thay vì tuần tự như trước đó.
Feasibility study là gì ? nghiên cứu khả thi – là nghiên cứu được thực hiện nhằm xác định xem dự án có thể triển khai được không, gồm có đánh giá về xác xuất thành công dự án và khả năng tồn tại của các sản phẩm dự án.
Fixed price contract là gì ? hợp đồng giá cố định – hợp đồng mà người mua trả cho người bán một mức chi phí cố định cho sản phẩm hay dịch vụ cung ứng. đây cũng là loại hợp đồng mà người bán phải gánh chịu nhiều rủi ro nhất.
Float là gì ? thời gian dự trữ – là khoản thời gian cho phép một công việc có thể được trì hoãn so với thời điểm bắt đầu sớm mà vẫn không làm chậm trễ thời hạn kết thúc dự án. thời gian dự trữ còn được gọi là thời gian tự do (slack time)
Flowchart là gì ? là loại biểu đồ mô tả trình tự các bước cần phải thực hiện nhằm đạt được một mục tiêu nào đó. một lưu đồ cũng có thể biểu diễn cách thức mà các thành phần trong một hệ thống tác động liên quan với nhau.
Force majeure là gì ? bất khả kháng – là các rủi ro nằm ngoài phạm vi của quản trị rủi ro dự án như bão lụt, động đất, núi lửa, chiến tranh, khủng bố, đình công,..
Formal acceptance and closure là gì ? chấp nhận và kết thúc hợp đồng – đây là tiến trình gởi một văn bản chính thức cho người bán để thông báo rằng hợp đồng đã hoàn tất và chính thức chấp nhận (nghiệm thu) sản phẩm mà người bán cung cấp.
Foward pass là gì ? bước tính xuôi – một kỹ thuật trong tính toán tiến độ nhằm xác định ngàu bắt đầu sớm và kết thúc sớm của công việc cũng như của dự án.
Funtional manager là gì ? người đứng đầu các bộ phận chức năng trong tổ chức. đây là một thành phần quan trọng vì quyết định thành công của dự án (chi phối nguồn lực, công nghệ mà dự án sử dụng)
Funtional organization là gì ? hình thức tổ chức dự án, trong đó dự án dưới quyền quản lý của một bộ phận chức năng nào đó hoặc luân chuyển quản lý qua nhiều bộ phận chức năng khác nhau. đây là hình thức mà nhà quản trị chức năng có quyền lớn nhất đối với dự án.
Gantt charts là gì ? một công cụ để biểu điễn tiến độ của dự án. biểu đồ này cũng có thể biểu diễn đường găng, trình tự trước sau của công việc, thời điểm bắt đầu, kết thúc công việc và các nguồn lực được phân bổ cho công việc đó.
Goals là gì ? mục đích – mô tả những gì mà dự án cần làm, cần phải đạt được hay hoàn tất. mục đích phải được phát biểu bằng các ngôn tư cụ thể, rõ ràng, chính xác, có thể đo lường được và gắn với một khuôn khổ thời gian xác định
GERT là gì ? Graphical Evaluation and Review Technique – một kỹ thuật phân tích toán học dùng để biểu diễn tiến độ và ước lượng thời gian thực hiện công việc. Kỹ thuật này cho phép các tính toán xác xuất, biểu diễn các nhánh có điều kiện và vòng lặp.
Hard dependency là gì ? mối quan hệ phục thuộc bắt buộc, không thể thay đổi giữa các công việc
hard logic là gì ? như hard dependency
history information là gì ? thông tin về các dự án đã thực hiện trước đó
information distribution là gì ? phân phối thông tin – tiến trình cung cấp thông tin cho các nhóm hữu quan
Initiation là gì ? khởi sự dự án – công nhận chính thức sự ra đời của dự án.
integrated change control system là gì ? kiểm soát thay đổi tích hợp –  là tiến trình ảnh hưởng đến các yếu tố có thể gây ra thay đổi, sau đó xác định xem thay đổi có cần thiết  hay đã xảy ra chưa và tiến hành quản lý các thay đổi. các tiến trình quản lý thay đổi khác được tích hợp với tiến trình này.
 là gì ?
issues là gì ? các vấn đề, các việc cần giải quyết
inerative là gì ? manf tính lặp lại, ví dụ hoạch định không phải thực hiện một lần mà là nhiều lần, trong quá trình thực hiện có thể phải thay đổi nên hoạch định lại.
kaizen là gì ? là một lý thuyết về quản lý chất lượng xuất phát từ Nhật bản, hàm ý cải tiến chất lượng liên tục. Tất cảc các thành viên dự án nên liên tục tìm kiếm các cơ hội để cải tiến chất lượng
lags là gì ? Một lag là thời gian chờ được chèn vào giữa hai activities. Ví dụ cần 3 ngày sau khi đổ xi măng (cho đủ cứng) để tiếp tục xây hạng mục khác.
leader là gì ? người lãnh đạo
leads là gì ? Một lead được dùng để ngụ ý rằng một Activitie có thể bắt đầu trước khi hoạt động tiền nhiệm của nó hoàn tất. Ví dụ viết mã phần mềm có thể bắt đầu trước khi hoạt động thiết kế kết thúc 5 ngày
lessons learned là gì ? Bài học kinh nghiệm từ các dự án khác
logical relationships là gì ? mối quan hệ phụ thuộc giữa hai công việc, trong đó một công việc phải bắt đầu hay kết thúc  trước khi thực hiện (bắt đầu hay kết thúc) một việc khác.
make or buy analysis là gì ? phân tích làm hay mua ngoài – là một đầu vào của tiến trình hoạch định mua sắm, trong đó xem xét liệu có hiệu quả hơn về mặt chi phí nếu tổ chức tự sản xuất hay mua ngoài một loại hàng hoá hay dịch vụ nào đó. phân tích mua hay làm không chỉ  thực hiện trên mảng chi phí mà còn cả vấn đề năng lực, kỹ năng, mức sẵn sàng, các bí quyết, giấy phép,…
mandatory dependency là gì ? quan hệ phụ thuộc bắt buộc., ví dụ phải thiết kế rồi mới thi công.
mathematical analysis là gì ? là một công cụ trong tiến trình xây dựng tiến độ nhằm tính các thời điểm sớm và muộn cho các công việc trong dự án. các tính toán này chưa tính đến giới hạn về nguồn lực.
matrix organization là gì ? là một hình thức tổ chức dự án, một nhân viên chịu sự quản lý của Functional manager và Project manager, đây gọi là kiểu quản lý theo ma trận
metrics là gì ? một chuẩn đo lường có thể do Project manager chọn cho một dự án cụ thể
milestone là gì ? cột mốc thời gian gian trong dự án, có thể để xem lại một số kết quả và đánh giá tình hình trước khi tiếp tục.
mitigation là gì ? là một chiền lược giảm khả năng xảy ra và giảm mức độ ảnh hưởng của một rủi ro
need assessment là gì ? đánh giá nhu cầu, là tiến trình được thực hiện trong giai đoạn khởi sự dự án. Bước này thường được thực hiện nhằm xem xét các nhu cầu dẫn đến sự hình thành dự án
net present value (NPV) là gì ? giá trị hiện tại ròng – phương pháp này tính giá trị ròng của giá trị hiện tại của các dòng tiền tương lai bằng cách chiết khấu các dòng tiền tương lai này bằng một tỉ suất tương đương với chi phí vốn của doanh nghiệp. dự án có NPV dương thì sẽ tạo ra giá trị cho doanh nghiệp.
nominal group technique là gì ? Đây là kỹ thuật thường dùng (không phải luôn luôn) trong các cuộc họp brainstorming , nó xếp loại các ý tưởng tạo ra trong quá trình brainstorming.
payback period là gì ? thời gian hoàn vốn – một mô hình đánh giá dự án dựa trên cơ sở thời gian để thu hồi số vốn đầu tư ban đầu. dự án có thời gian hoàn vốn ngắn thì được ưa thích hơn mặc dù mô hình có nhược điểm là không tính đến dòng ngân quỹ phát sinh sau thời điểm hoàn vốn và không tính đến giá trị thời gian của tiền tệ.
performance là gì ? thành quả, các kết quả đã thực hiện được, tiến độ thực hiện được.
performance measurement là gì ? đo lường thành quả – các công cụ, các biện pháp và quy trình đo lường để đánh giá việc thực hiện dự án.
Performance reporting là gì ? báo cáo thực hiện – là tiến trình thu thập thông tin liên quan đến tiến triển của dự án và việc hoàn thành dự án, sau đó báo cáo các thông tin này đến các nhóm hữu quan.
Performance review là gì ? xem xét thành quả – việc thu thập và báo cáo về tình hình và tiến triển của dự án cho nhóm hữu quan. các báo cáo này bao gồm báo cáo thực trạng, báo cáo tiến độ và dự báo. xem xét thành quả là một công cụ của tiến trình báo cáo thực hiện
PERT là gì ? program eveluation and review technique – kỹ thuật thẩm định và đánh giá theo chương trình là một kỹ thuật lập kế hoạch tiến độ trong điều kiển rủi ro, cho phép tính đến xác xuất xảy ra của các công việc với 3 giá trị : lạc quan, bi quan và dễ xảy ra nhất.
Preassignment là gì ? phân công trước – là công cụ trong tiến trình “thu nhận nhân viên” trong đó một kế hoạch dự án được đưa ra để đấu thầu song các nhân viên đã được phân công trước như một phần không thể tách dời của dự án.
Precedence relationship là gì ? tương tự logical relationship
Prevention là gì ? ngăn ngừa/phòng ngừa – ngăn ngừa các lỗi xảy ra trong một tiến trình. Đây là mối quan tâm cơ bản của quản trị chất lượng trong dự án.
Prevention cost là gì ? chi phí ngăn ngừa – là các chi phí gắn với việc thoả mãn nhu cầu của khách hàng bằng cách sản xuất ra sản phẩm không sai hỏng
Probability là gì ? xác xuất – khả năng xảy ra của một sự kiện nào đó.
Process là gì ? Tiến trình – làm một tập hợp các bước công việc  được thực hiện theo một trình tự để đạt được mục tiêu xác định
Procurement là gì ? mua sắm/mua hàng cho dự án – là tiến trình mua hàng hàng, dịch vụ từ bên ngoài nhằm phục vụ cho dự án.
Procurement documents là gì ? tài liệu mua sắm – các tài liệu nhằm mời gọi các nhà cung cấp dự thầu về một sản phẩm hay dịch vụ nào đó. các tài liệu này bao gồm mời đề xuất (RFP), mời cung cấp thông tin (RFI), mời dự thầu (IFB), mời chào giá (RFQ).
Procurement management plan là gì ? kế hoạch quản trị mua sắm – tài liệu mô tả cách thức quản trị tiến trình mua sắm trong đó chỉ rõ loại hợp đồng sẽ sử dụng, quyền hạn của nhóm dự án, cách thức tiến trình mua sắm được tích hợp với các tiến trình quản trị khác.
Product analysis là gì ? phân tích sản phẩm – mô tả về sản phẩm của dự án nhờ một số công cụ như phân tích giá trị, phân tích chức năng, triển khai chức năng chất lượng, phân tích chia nhỏ sản phẩm…
Procduct scope là gì ? phạm vi sản phẩm – bản mô tả các thuộc tính của sản phẩm, được văn bản hoá chính thức.
Product verification là gì ? kiểm tra sản phẩm – bước trong tiến trình kết thúc hợp đồng nhằm xác định liệu công việc mô tả trong hợp đồng có được hoàn thành một cách chính xác và đúng theo yêu cầu hay không.
Program là gì ? là một nhóm các dự án được phối hợp với nhau, có liên quan với nhau.
Progressive elaboration là gì ? xác định dần dần – là một thuộc tính của dự án, có nghĩa là các tính chất, đặc điểm của sản phẩm dự án được làm sáng tỏ và tinh gọn dần dần.
Project charter là gì ? hiến chương dự án – là tài liệu thường do nhà tài trợ phê chuẩn nhằm chính thức công bố sự ra đời của dự án và là cơ sở để huy động nguồn lực cho dự án.
Project communication managment là gì ? quản trị truyền thông trong dự án – là một trong những lĩnh vực kiến thức  của PMBoK guide để đảm bao sao cho có sự truyền thông phù hợp, kịp thời đến các nhóm hữu quan trong dự án.
Project cost management là gì ? quản trị chi phí trong dự án – là một trong những lĩnh vực kiến thức của PMBoK guide liên quan đến hoạch định chi phí, lập ngân sách và kiểm soát chi phí.
Project humanresource management là gì ? quản trị nguồn nhân lực trong dự án – là một trong những lĩnh vực kiến thức của PMBoK guide nhằm đảm bảo việc sử dụng hiệu quả nguồn nhân lực trong dự án, gồm có: hoạch định tổ chức, thu nhận nhân viên và phát triển nhóm.
Project intergration management là gì ? quaản trị dự án tích hợp – là một lĩnh vực kiến thức của PMBoK guide nhằm phối hợp tất cả các phương diện của dự án.
Project life cycle là gì ? Vòng đời dự án – là tập hợp tất cả các giai đoạn từ khi bắt đầu đến khi kết thúc dự án.
Project management là gì ? quản trị dự án – là các tiến trình được sử dụng để khởi sự, lập kế hoạch, thực thi, kiểm soát và kết thúc dự án bằng cách áp dụng các kỹ năng, kiến thức, các công cụ và kỹ thuật quản trị dự án để đạt các mục tiêu đề ra.
Project management office là gì ? PMO – văn phòng quản trị dự án, là một bộ phận được lập ra để xây dựng và duy trì các thủ tục và các tiêu chuẩn cho các hoạt động quản trị dự án trong tổ chức.
project management knowledge areas là gì ? các lĩnh vực kiến thức quản trị dự án – gồm có chín lĩnh vực: quản trị thời gian, quản trị chi phí,, quản trị nguồn nhân lực, quản trị mua sắm, quản trị chất lượng, quản trị rủi ro, quản trị phạm vi và quản trị dự án tích hợp.
project monitoring là gì ? hoạt động theo dõi, thu thập thông tin để phục vụ cho công tác kiểm soát dự án.
Project plan là gì ? kế hoạch dự án – là bản kế hoạch tích hợp tất kết quả của tất cả các tiến trình hoạch định khác. kế hoạch dự án là tài liệu vô cùng quan trọng để hướng dẫn dự án trong quá trình thực hiện, đồng thời để đánh giá hiệu quả và kiểm soát dự án. kế hoạch dự án còn là một công cụ truyền thông cho các nhóm hữu quan trong dự án.
Project procurement mangement là gì ? quản trị mua sắm trong dự án – là một trong chín lĩnh vực quản trị dự án theo PMBoK guide liên quan đến mua sắm hàng hoá và dịch vụ cho dự án.
Project proposal là gì ? đề xuất dự án
Project quality management là gì ? quản trị chất lượng  dự án – là một trong chín lĩnh vực kiến thức của quản trị dự án, nhằm đảm bảo đáp ứng yêu cầu  về chất lượng của dự án. Quản trị chất lượng gồm có các tiến trình hoạch định chất lượng, đảm bảo chất lượng và kiểm soát chất lượng.
project record là gì ? các bản ghi về dự án – là tất cả các thông tin liên quan đến dự án bao gồm các báo cáo, các bản ghi nhớ, tiến độ, kế hoạch và các tài liệu khác.
project report là gì ? báo cáo dự án – là kết quả của tiến trình phân phát thông tin, có chứa các thông tin của dự án như: báo cáo thực trạng dự án và các biên bản từ các cuộc họp
Project risk management là gì ? quản trị rủi ro dự án – là mộ trong chín lĩnh vực kiến thức của quản trị dự án nhằm xác định rõ và lập kế hoạhc cho các rủi ro tiềm ẩn có thể tác động đến dự án. tiến trình này bao gồm có hoạch định rủi ro, xác định rủi ro, phân tích định tính và định lượng rủi ro, hoạch định các phương án đối phó, theo dõi và kiểm soát rủi ro
project schedule là gì ? tiến độ dự án – là bản kế hoạch về mặt thời gian cho các công việc trong dự án cũng như toàn bộ dự án trong đó chỉ rõ thời điểm bắt đầu, kết thúc và thời gian để thực hiện các công việc cũng như toàn bộ dự án.
project scope là gì ? phạm vi dự án – phạm vi dự án mô tả các công việc  cần thiết để sản xuất ra sản phẩm hay dịch vụ cho dự án, bao gồm các yêu cầu mô tả cụ thể các đặc điểm và chức năng của sản phẩm hay dịch vụ.
project scope management là gì ? quản trị phạm vi dự án – là một tong chín lĩnh vực kiến thức quản trị dự án với trọng tâm là công việc của dự án và chỉ  các công việc cần thiết để hoàn thành dự án. các tiến trình này gồm có khởi sự, hoạch định phạm vi, xác định phạm vi, kiểm tra phạm vi và kiểm soát thay đổi phạm vi.
project selection criteria là gì ? tiêu chuẩn lựa chọn dự án – một loạt các tiêu chuẩn để đánh giá dự án, xếp thứ tự ưu tiên và lựa chọn dự án để triển khai. Các tiêu chẩn này có thể là định tính hay định lượng và có thể liên quan đến nhiều lãnh vựa khác nhau như tài chính, marketing, sản xuất, công nghệ, nhân sự, chất lượng….
project sponsor là gì ? người tài trợ cho dự án – thường là một nhà quản trị cấp cao trong tổ chức, có quyền hạn phân bổ nguồn lực và hiệu lực hoá các quyết định liên quan đến dự án.
project time management là gì ? quản trị thời gian dự án – là một trong chín lĩnh vực kiến thức của quản trị dự án. quản trị thời gian gồm các công việc ước lượng thời gian của các công việc trong dự án, xem xét lại kế hoạch tiến độ, theo dõi và kiểm soát các sai lệch từ kế hoạch tiến độ.
projectized organiztion là gì ? tổ chức theo hình thức dự án – trong mô hình này, công ty được tổ chức theo dự án và Project Manager điều khiển dự án. Những cá nhân được phân công vào dự án và báo cáo cho Project manager. Khi thi, nếu bạn thấy chữ “Projectized”, bạn nên nghĩ đến chữ “no home”. Nhân viên chỉ làm các công việc dự án và khi dự án kết thúc họ không có phòng ban để trở về. Họ cần được phân công vào dự án khác hoặc làm công  việc mới. Các mối thông tin liên lạc chủ yếu xảy ra trong dự án.
quanlitative risk analysis là gì ? phân tích định tính rủi ro – tiến trình xác định các tác động mà rủi ro có thể gây ra đối với dự án và xác xuất mà rủi ro có thể xảy ra. trên cơ sở đó xếp thứ tự các rủi ro theo mức độ ảnh hưởng của chúng đến mục tiêu dự án.
quality assurance là gì ? đảm bảo chất lượng – tiến trình thực hiện đánh giá chất lượng để xác định xem dự án được thực hiện như thế nào nhằm da93m bảo rằng dự án đáp ứng được các tiêu chuẩn về chất lượng của dự án. tiến trình này nên được lặp đi lặp lại trong suốt vòng đời dự án
quality control là gì ? kiểm soát chất lượng – tiến trình nhằm giám sát các kết quả công việc để đánh giá xem các kết quả này có thoả mãn được các tiêu chuẩn về chất lượng đã nêu trong kế hoạch quản lý chất lượng không ? tiến trình kiểm soát chất lượng  sẽ đánh giá xem liệu kết quả cuối cùng có phù hợp với các yêu cầu và mô tả sản phẩm đã được xác định trong suốt các tiến trình hoạch định hay không ?
quality management plan là gì ? kế hoạch quản trị chất lượng – là bản kế hoạch mô tả rõ cách thức mà các thành viên nhóm dự án sẽ thực thi chính sách chất lượng và huy động các nguồn lực  cần thiết để triển khai kế hoạch chất lượng, đồng thời chỉ rõ các trách nhiểm của nhóm dự án trongt việc thực thi chất lượng cũng như tất cả các tiến trình và các thủ tục mà nhóm dự án và tổ chức sẽ sử dụng để thoả mãn các yêu cầu về chất lượng.
quality planning là gì ? hoạch định chất lượng – tiến trình xác định các tiêu chẩn chất lượng áp dụng cho dự án và cách thức để đạt được các tiêu chuẩn đó.
quantitative risk analysis là gì ? phân tích định lượng rủi ro – tiến trình gắm một giá trị xác xuất với từng rủi ro đã được xác định và đánh giá tác động tiềm ẩn của các rủi ro này đối với các mục tiêu của dự án.
rebaseline là gì ? điều chỉnh kế hoạch gốc.
regulation là gì ? qui định – là các điều luật hay các quy định bắt buộc được chính phủ hay cơ quan có thẩm quyền ban hành. ngoài ra các tổ chức cũng có quy định riêng của họ. các quy định đòi hỏi phải tuân thủ chặt chẽ.
requirement là gì ? yêu cầu – là các đặc điểm hay đặc tính kỹ thuật cần phải tuân thủ của sản phẩm hay dịch vụ dự án.
resource loading là gì ? tải trọng nguồn lực – nhu cầu sử dụng từng loại nguồn lực cụ thể cho từng thời kỳ của dự án.
resource allocation là gì ? phân bổ nguồn lực – là hoạt động phân bổ nguồn lực cho các công việc trong dự án . sau khi phân bổ nguồn lực, chúng sẽ được tính tải trọng nguồn lực chung của dự án để biết nguồn lực nào bị quá tải (Overlocatteded) tức là nhu cầu lớn hơn mức sẵn sàng của nguồn lực trong thời kỳ đó.
reserve time là gì ? thời gian dự phòng – kỹ thuật thêm vào một lượng thời gian nào đó cho từng công việc để dự phòng cho các rủi ro về tiến độ.
residual risks là gì ? rủi ro còn lại – rủi ro vẫn còn chưa được giải quyết sau khi đẽ triển khai chiến lược đối phó rủi ro.
resource calendars là gì ? lịch làm việc của nguồn lực – thời biểu làm việc của một nguồn lực cụ thể thế nào – mức độ sẵn sàng của nguồng lực đó cho dự án.
resource capabilities là gì ? khả năng của nguồn lực – bản mô tả khả năng của nguồn lực, máy móc, nguyên liệu,… được phân bổ cho công việc.
resource histogram là gì ? biểu đồ nguồn lực – biểu đồ biểu diễn nhu cầu nguồn lực của toàn bộ dự án theo trục thời gian.
resoure leveling là gì ? điều phối nguồn lực – kỹ thuật dịch chuyển các công việc có thời gian tự do hoặc chia nhỏ công việc sao cho vẫn không ảnh hưởng đến thời gian hoàn thành dự án, với mục tiêu làm cho nhu cầu nguồn lực trở nên đều đặn giữa các thời kỳ .
resource planning là gì ? hoạch định nguồn lực – là tiến trình xác định tất cả các nguồn lực cần thiết và khối lượng của các nguồn lực này để thực hiện các công việc của dự án.
resoure rate là gì ? đơn giá nguồn lực sử dụng cho dự án
resource requirement là gì ? yêu cầu nguồn lực – là kết quả của tiến trình hoạch định nguồn lực, trong đó mô tả loại nguồn lực và khối lượng của từng loại cần thiết cho từng công việc trong WBS
responsibility assigment matrix là gì ? ma trận phân công trách nhiệm – ma trận này làm rõ các vai trò và trách nhiệm của các cá nhân gắn với từng công việc trong WBS để đảm bảo rằng mỗi yếu tố trong WBS đề được đảm đương.
revision là gì ? xem xét lại – là hoạt động điều chỉnh lại tiến độ đã được thông qua trước đó sao cho phù hợp với các thay đổi được thông qua. một thuật ngữ khác của từ này là cập nhật (update)
reward and recognition system là gì ? hệ thống đánh giá và khen thưởng – là một công cụ trong tiến trình phát triển nhóm dự án, hệ thống này là cách chính thức để các nhà quản trị cấp cao và nhà quản trị dự án công nhận, khen thưởng và cổ vũ cho các hành vi tốt.
rework là gì ? làm lại – là hiện tượng một công việc nào đó phải thực hiện lại, để tuân thủ theo đúng yêu cầu chất lượng hay tiêu chuẩn chất lượng.
risk là gì ?  Sự kiện rủi ro là điều được xác định trước mà có thể xảy ra hoặc không; nó có thể có tác động tích cực hoặc tiêu cực lên dự án. Project manager thường chỉ quan tâm đến những mối đe doạ – điều này có thể sai lầm và tác động tiêu cực đến dự án. Đừng quên rằng còn có những tác động tích cực – “rủi ro tốt”, gọi là cơi hội
risk management plan là gì ? kế hoạch quản trị rủi ro – là tiến trình ghi rõ cách thức quản trị các rủi ro trong dự án.
risk monitoring and controling là gì ? theo dõi và kiểm soát rủi ro – là tiến trình đối phó với rủi ro khi chúng xảy ra
risk response plan là gì ? kế hoạch đối phó rủi ro – là một kế hoạch của tiến trình hoạch định đối phó rủi ro, kế hoạch này mô tả các hành động cần thiết nếu rủi ro lường trước xảy ra. kế hoạch cũng bao gồm tất cảc các rủi ro đã được xác định, mô tả về các rủi ro và các phương diện của dự án bị rủi ro tác động.
Schedule variance là gì ? sai lệch tiến độ – là một thông số tính từ phân tích giá trị thu được nhằm đánh giá mức độ thực hiện của dự án về phương diện tiến độ.
schedule change control system là gì ? hệ thống kiểm soát thay đổi tiến độ – là hệ thống các tài liệu xác định cách thức các thay đổi về tiến độ sẽ diễn ra và được quản lý như thế nào. hệ thống này cũng lưu trữ các số liệu theo dõi về yêu cầu thay đổi, mô tả các tiến trình để thực hiện thay đổi tiến độ và chi tiết hoá mức quyền hạn, để thông qua các thay đổi về tiến độ.
schedule development là gì ? xây dựng tiến độ – là tiến trình tính toán, xây dựng tiến độ các công việc của dự án, kết quả của tiến trình này là bản kế hoạch gốc về tiến độ. bản kế hoạch này xác định các thời điểm bắt đầu và kết thúc công việc, ấn định trình tự thực hiện các công việc và độ dài thời gian, đồng thời thể hiện các phân bổ nguồn lực cho công việc.
schedule performance index là gì ? SPI, chỉ số hiệu quả về mặt tiến độ – là một kỹ thuật trong phân tích giá trị thu được nhằm đánh giá hiệu quả về mặt tiến độ.
schedule updates là gì ? cập nhật tiến độ – là kết quả của tiến trình kiểm soát tiến độ nhằm điều chỉnh các công việc và ngày giờ cho phù hợp với các thay đổi đã được thông qua hay phù hợp với hành động điều chỉnh.
scope change control là gì ? kiểm soát thay đổi phạm vi – tiến trình liên quan đến việc ghi nhận và quản lý các thay đổi so với phạm vi dự án . bất cứ điều chỉnh nào đối với bản WBS đã được thông qua cũng được xem như thay đổi phạm vi . các thay đổi trong phạm vi sản phẩm cũng đòi hỏi thay đổi đối với phạm vi dự án.
scope changes là gì ? thay đổi phạm vi – là bất kỳ thay đổi nào đối với WBS đã được thông qua. thay đổi phạm vi có thể đòi hỏi phải có các thay đổi hay cập nhật đối với các mục tiêu, chi phí, các đo lường về chất lượng hay các xem xét về kiểm soát và điều chỉnh tiến độ. thay đổi phạm vi thường dẫn đến điều chỉnh tiến độ.
scope definition là gì ? xác định phạm vi – là tiến trình xác định những gì mà dự án cần thực hiện và chỉ những gì cần phải thực hiện để đạt được mục tiêu. sau đó các công việc này sẽ được chia nhỏ thành các phần việc với quy mô nhỏ hơn, dễ quản lý hơn để tạo điều kiện thuận lợi cho công tác lập kế hoạch, ước lượng và kiểm soát.
scope management plan là gì ? kế hoạch quản trị phạm vi dự án – là tài liệu phân tích mức độ tin cậy và ổn định của phạm vi dự án, đồng thời ghi nhận lại tiến trình được sử dụng để quản lý phạm vi và các thay đổi đối với phạm vi.
scope statement là gì ? là tài liệu chỉ rõ các mục tiêu, kết quả và các yêu cầu của dự án. tài liệu này được xem như tài liệu gốc của các quyết định về dự án trong tương lai. scope statement cũng thường bao gồm một phần lý giải về tính cấp thiết của dự án (Business justification)
scope verification là gì ? kiểm tra phạm vi – tiến trình chính thức hoá sự chấp nhận phạm vi dự án và chủ yếu là chú trọng đến chấp nhận kết quả công việc.
scoring model là gì ? mô hình cho điểm – là phương pháp lựa chọn các đề xuất dự án trong đó cho điểm và xếp hạng các dự án dựa trên điểm số kết quả.
screening system là gì ? hệ thống sàng lọc – là một loạt các tiêu chuẩn hiệu quả được xác định trước nhằm sàng lọc các nhà cung cấp. đây là một công cụ trong tiến trình chọn lực nhà cung cấp.
secondary risk là gì ? rủi ro thứ cấp – rủi ro bắt nguồn từ việc thực hiện một chiến lược rủi ro.
sensitivity analysis là gì ? phân tích độ nhạy – là một công cụ phân tích rủi ro nhằm đánh giá tác động của sự biến đổi của một hoặc nhiều biến số đến kết quả cuối cùng của dự án.
slack time là gì ? thời gian dự trữ.
soft logic là gì ? xem discrestionary dependency.
solicitation là gì ? mời dự thầu – là tiến trình mời thầu hoặc mời thầu có đề xuất kỹ thuật, hay mời báo giá từ những nhà cung cấp.
source selection là gì ? chọn nhà cung cấp – tiến trình thu nhận các hồ sơ thầu hoặc báo giá và lựa chọn ra một nhà cung cấp để thực hiện hay cung ứng sản phẩm, dịch vụ.
staff acquisition là gì ? thu nhận nhân viên – tiến trình huy động nguồn nhân lực và phân công nhân sự vào dự án. nhân sự có thể đến từ bên ngoài hoặc bên trong tổ chức.
staffing pool description là gì ? mô tả lực lượng nhân sự – là đầu vào của tiến trình thu nhận nhân viên, trong đó xem xét các kinh nghiệm, sở thích cá nhân, cá tính, mức độ sẵn sàng và năng lực chuyên môn của các thành viên tiềm năng của nhóm dự án.
staffing requirements là gì ? yêu cầu nhân sự – là một bộ phận của nhu cầu nguồn lực . nhu cầu nhân sự trở thành yếu tố đầu vào của tiến trình hoạch định tổ chức vì danh sách này liệt kê tất cả các loại kỹ năng  đòi hỏi, mức năng lực và các cá nhân hay các nhóm có thể cung cấp kỹ năng này cho dự án đồng thời lhuôn khổ thời gian mà dự án cần đến các kỹ năng này.
stakeholder là gì ? nhóm hữu quan – là các cá nhân hay tổ chức có quyền lợi với dự án và ảnh hưởng đến sự thành công của dự án một cách trực tiếp hay gián tiếp.
standards là gì ? tiêu chuẩn – là các qui định, hướng dẫn hay các đặc tính cần phải tuân thủ và đã được phê chuẩn bởi một tổ chức có thẩm quyền. tiêu chuẩn là đầu vào của tiến trình hoạch định chất lượng.
startvation là gì ? rút bớt nguồn lực – là một trong những hình thức kết thúc dự án trong đó nguồn lực tài chính hoặc nhân sự bị rút khỏi dự án.
statement of work là gì ? là tài liệu mô tả chi tiết các mục tiêu của dự án, công việc của dự án, các đặc tính kỹ thuật chính xác và chi tiết của sản phẩm hay dịch vụ yêu cầu và tiến độ của dự án.
status view meeting là gì ? họp đánh giá thực trạng dự án – các cuộc họp trong qua trình triển khai dự án nhằm cung cấp các thông tin cập nhật về tiển triển của dự án.
steering commitee là gì ? hội đồng tuyển chọn – là một nhóm các nhà quản trị cấp cao trong tổ chức, chịu trách nhiệm chọn lựa và sắp xếp thứ tự ưu tiên giữa các dự án cũng như ảnh hưởng đế một số quyết định quan trọng khác cho dự án. hội đồng này cũng có thể có các đại diện từ các bộ phận chức năng trong tổ chức.
team building là gì ? xây dựng nhóm – là một trong những công cụ trong tiến trình phát triển nhóm, nhằm tập hợp một nhóm các cá nhân đa dạng, sao cho họ làm việc một cách hiệu quả nhất.
team development là gì ? phát triển nhóm – là tiến trình nhằm tạo ra môi trường làm việc cới mở, khuyến khích các nhóm hữu quan cũng như để phát triển nhóm dự án thành một nhóm hiệu quả, biết phối hợp và có thể đạt được thành công.
time and materials contract là gì ? hợp đồng theo thời gian và nguyên vật liệu – là loại hợp đồng kết hợp giữa hợp đồng giá cố định và hợp đồng chi phí phát sinh, trong đó tổng chi phí được tính trên cơ sở thống nhất trước đơn giá.
top down estimating là gì ? ước lượng từ trên xuống. xem thêm analogous estimating
transference là gì ? chuyển giao – là chiến lược đối phó rủi ro, trong đó rủi ro được chuyển đến một bên thứ 3. ví dụ mua bảo hiểm.
trend analysis là gì ? phân tích xu hướng – là một kỹ thuật dự báo để đánh giá xem liệu hiệu quả dự án có được cải thiện theo thời gian hay không bằng cách định kỳ phân tích các kết quả dự án.
trigger là gì ? kích hoạt – là triệu chứng báo hiệu trước rủi ro sắp xảy ra.
variance at completion là gì ? sai lệch tại thời điểm hoàn thành – một thông số trong kỹ thuật phân tích giá trị thu được nhằm tính sự khác biệt giữa ngân sách tại thời điểm hoàn thành (BAC) với ước lượng chi phí tại thời điểm hoàn thành (EAC). VAC – BAC – EAC
variance analysis là gì ? phân tích sai lệch – là kỹ thuật phân tích so sánh giá trị thực tế với giá trị kế hoạch . phân tích sai lệch có thể được thực hiện trên phương diện chi phí hoặc tiến độ.
WBS là gì ? Work breakdown structure – cây cấu trúc công việc – là tài liệu xác định kết quả cuối cùng của công việc rồi sau đó chia nhỏ công việc này thành nhiều công việc nhỏ hơn, dễ quản lý hơn. WBS thường được sắp xếp thành các cấp với cấp sau chi tiết hơn cấp trước.
Work package là gì ? gói công việc – là công việc chi tiết nhất, ở cấp thấp nhất của WBS.
workaround là gì ? phản ứng đột xuất – là một đối phó rủi ro đột xuất khi một rủi ro không được dự tính trước xảy ra hoặc là một phản ứng chưa được lập kế hoạch trước một rủi ro đã xác định.


10 Steps to Creating a Project Plan

Feature May16 40432452 XS

One of the critical factors for project success is having a well-developed project plan. This article provides a 10-step approach to creating the project plan, not only showing how it provides a roadmap for project managers to follow, but also exploring why it is the project manager’s premier communications and control tool throughout the project.

Step 1: Explain the project plan to key stakeholders and discuss its key components. One of the most misunderstood terms in project management, the project plan is a set of living documents that can be expected to change over the life of the project. Like a roadmap, it provides the direction for the project. And like the traveler, the project manager needs to set the course for the project, which in project management terms means creating the project plan. Just as a driver may encounter road construction or new routes to the final destination, the project manager may need to correct the project course as well.

A common misconception is that the plan equates to the project timeline, which is only one of the many components of the plan. The project plan is the major work product from the entire planning process, so it contains all the planning documents for the project.

Typically many of the project’s key stakeholders, that is those affected by both the project and the project’s end result, do not fully understand the nature of the project plan. Since one of the most important and difficult aspects of project management is getting commitment and buying, the first step is to explain the planning process and the project plan to all key stakeholders. It is essential for them to understand the importance of this set of documents and to be familiar with its content, since they will be asked to review and approve the documents that pertain to them.

Components of the Project Plan Include:

Baselines. Baselines are sometimes called performance measures, because the performance of the entire project is measured against them. They are the project’s three approved starting points and include the scope, schedule, and cost baselines. These provide the ‘stakes in the ground.’ That is, they are used to determine whether or not the project is on track, during the execution of the project.

Baseline management plans. These plans include documentation on how variances to the baselines will be handled throughout the project. Each project baseline will need to be reviewed and managed. A result of this process may include the need to do additional planning, with the possibility that the baseline(s) will change. Project management plans document what the project team will do when variances to the baselines occur, including what process will be followed, who will be notified, how the changes will be funded, etc.

Other work products from the planning process. These include a risk management plan, a quality plan, a procurement plan, a staffing plan, and a communications plan.

Step 2: Define roles and responsibilities. Not all key stakeholders will review all documents, so it is necessary to determine who on the project needs to approve which parts of the plan. Some of the key players are:

  • Project sponsor, who owns and funds the entire project. Sponsors need to review and approve all aspects of the plan.
  • Designated business experts, who will define their requirements for the end product. They need to help develop the scope baseline and approve the documents relating to scope. They will be quite interested in the timeline as well.
  • Project manager, who creates, executes, and controls the project plan. Since project managers build the plan, they do not need to approve it.
  • Project team, who build the end product. The team needs to participate in the development of many aspects of the plan, such as identifying risks, quality, and design issues, but the team does not usually approve it.
  • End users, who use the end product. They too, need to participate in the development of the plan, and review the plan, but rarely do they actually need to sign off.
  • Others, such as auditors, quality and risk analysts, procurement specialists, and so on may also participate on the project. They may need to approve the parts that pertain to them, such as the Quality or Procurement plan.

Step 3: Hold a kickoff meeting. The kickoff meeting is an effective way to bring stakeholders together to discuss the project. It is an effective way to initiate the planning process. It can be used to start building trust among the team members and ensure that everyone’s idea are taken into account. Kickoff meetings also demonstrate commitment from the sponsor for the project. Here are some of the topics that might be included in a kickoff meeting:

  • Business vision and strategy (from sponsor)
  • Project vision (from sponsor)
  • Roles and responsibilities
  • Team building
  • Team commitments
  • How team makes decisions
  • Ground rules
  • How large the group should be and whether sub-groups are necessary

Step 4: Develop a Scope Statement. The Scope Statement is arguably the most important document in the project plan. It’s the foundation for the rest of the project. It describes the project and is used to get common agreement among the stakeholders about the scope. The Scope Statement clearly describes what the outcome of the project will be. It is the basis for getting the buy-in and agreement from the sponsor and other stakeholders and decreases the chances of miscommunication. This document will most likely grow and change with the life of the project. The Scope Statement should include:

  • Business need and business problem
  • Project objectives, stating what will occur within the project to solve the business problem
  • Benefits of completing the project, as well as the project justification
  • Project scope, stated as which deliverables will be included and excluded from the project.
  • Key milestones, the approach, and other components as dictated by the size and nature of the project.

It can be treated like a contract between the project manager and sponsor, one that can only be changed with sponsor approval.

Step 5: Develop scope baseline. Once the deliverables are confirmed in the Scope Statement, they need to be developed into a work breakdown structure (WBS), which is a decomposition of all the deliverables in the project. This deliverable WBS forms the scope baseline and has these elements:

  • Identifies all the deliverables produced on the project, and therefore, identifies all the work to be done.
  • Takes large deliverables and breaks them into a hierarchy of smaller deliverables. That is, each deliverable starts at a high level and is broken into subsequently lower and lower levels of detail.
  • The lowest level is called a “work package” and can be numbered to correspond to activities and tasks.

The WBS is often thought of as a task breakdown, but activities and tasks are a separate breakdown, identified in the next step.

Step 6: Develop the schedule and cost baselines. Here are the steps involved in developing the schedule and cost baselines.

  1. Identify activities and tasks needed to produce each of the work packages, creating a WBS of tasks.
  2. Identify resources for each task, if known.
  3. Estimate how long it will take to complete each task.
  4. Estimate cost of each task, using an average hourly rate for each resource.
  5. Consider resource constraints, or how much time each resource can realistically devoted to this project.
  6. Determine which tasks are dependent on other tasks, and develop critical path.
  7. Develop schedule, which is a calendarization of all the tasks and estimates. It shows by chosen time period (week, month, quarter, or year) which resource is doing which tasks, how much time they are expected to spend on each task, and when each task is scheduled to begin and end.
  8. Develop the cost baseline, which is a time-phased budget, or cost by time period.

This process is not a one-time effort. Throughout the project you will most likely be adding to repeating some or all of these steps.

Step 7: Create baseline management plans. Once the scope, schedule, and cost baselines have been established, you can create the steps the team will take to manage variances to these plans. All these management plans usually include a review and approval process for modifying the baselines. Different approval levels are usually needed for different types of changes. In addition, not all new requests will result in changes to the scope, schedule, or budget, but a process is needed to study all new requests to determine their impact to the project.

Step 8: Develop the staffing plan. The staffing plan is a chart that shows the time periods, usually month, quarter, year, that each resource will come onto and leave the project. It is similar to other project management charts, like a Gantt chart, but does not show tasks, estimates, begin and end dates, or the critical path. It shows only the time period and resource and the length of time that resource is expected to remain on the project.

Step 9: Analyze project quality and risks.
Project Quality: Project quality consists of ensuring that the end product not only meets the customer specifications, but is one that the sponsor and key business experts actually want to use. The emphasis on project quality is on preventing errors, rather than inspecting the product at the end of the project and then eliminating errors. Project quality also recognizes that quality is a management responsibility and needs to be performed throughout the project.

Creating the Quality Plan involves setting the standards, acceptance criteria, and metrics that will be used throughout the project. The plan, then, becomes the foundation for all the quality reviews and inspections performed during the project and is used throughout project execution.

Project Risks: A risk is an event that may or may not happen, but could have a significant effect on the outcome of a project, if it were to occur. For example, there may be a 50% chance of a significant change in sponsorship in the next few months. Analyzing risks includes making a determination of both the probability that a specific event may occur and if it does, assessing its impact. The quantification of both the probability and impact will lead to determining which are the highest risks that need attention. Risk management includes not just assessing the risk, but developing risk management plans to understand and communicate how the team will respond to the high-risk events.

Step 10: Communicate! One important aspect of the project plan is the Communications Plan. This document states such things as:

  • Who on the project wants which reports, how often, in what format, and using what media.
  • How issues will be escalated and when.
  • Where project information will be stored and who can access it.

For complex projects, a formal communications matrix is a tool that can help determine some of the above criteria. It helps document the project team’s agreed-on method for communicating various aspects of the project, such as routine status, problem resolution, decisions, etc.

Once the project plan is complete, it is important not just to communicate the importance of the project plan to the sponsor, but also to communicate its contents once it’s created. This communication should include such things as:

  • Review and approval of the project plan.
  • Process for changing the contents of the plan.
  • Next steps—executing and controlling the project plan and key stakeholder roles/responsibilities in the upcoming phases.

Source Link: http://www.projecttimes.com/articles/10-steps-to-creating-a-project-plan.html


Next Move: Should I study Prince2 or ITIL?


I have been with my current company for four years as a systems manager. I am an experienced manager of technical teams and have…

I have been with my current company for four years as a systems manager. I am an experienced manager of technical teams and have good general technical skills in mid-range systems, PCs and networks. I am now looking to work for a larger organisation in a service management type role. I recently applied for two positions but was turned down because I did not have an ITIL qualification. I am currently doing a BTec in network management and was looking to do Prince2 for project management. Should I now consider ITIL instead? My employer will not pay for any qualifications.

Research potential employers
Your lack of ITIL (IT Infrastructure Library) should not have been the make or break point on which you failed to get a job. You appear to have a solid IT career and obvious technical and people management skills that should make you a good prospect for any company.

It is unfortunate that your company does not recognise these project management qualifications, but you could use that to your advantage when talking to future employers. You could explain that you have the practical knowledge and ability, but have been unable to formalise this because your company is already so confident in your skills that your bosses feel paying for additional training would be a waste.

Have you looked into ITIL and compared the subject areas it covers alongside Prince2? It is my understanding that Prince (Projects in Controlled Environments) is the methodology of choice for central and local government, whereas ITIL seems to be designed more for general commercial applications. The course content looks very interesting but I suspect that you have probably covered most of it in your working day anyway.

Identify the type of company you have a desire to work for, ideally you will know the names of these companies, perhaps there is a specific business area? Use a Web site such as www.hoovers.com and type in the name of your ideal company and it will come up with a number of competitors in the same field.

Often competitors will use the same software and networks, so once you have found out which companies use which software you will generally be able to apply to all of them in the knowledge that your skills should be appropriate.

Solution by by Tracey Abbott, Zarak Technology

Keys to Delegation Success

In today’s Amazon-impacted world, customers have higher expectations of rapid turnaround, 24/7 accessibility, and increased levels of service. These events have contributed to an information overloaded society.

Not only do we receive countless emails, texts, social media messages, marketing messages and the like, but we also are expected to be able to make sense of it all and execute projects successfully – on-time, on budget and on results. A tall order to be sure!

Survival seems challenging enough, let alone thriving in these sorts of conditions. In taking a step back from the details, it becomes clear that we must employ tools to increase our chances of success. And, of course, we’d like to make the process easier and clearer along the way. One option to achieve these goals is to delegate. Those who properly delegate will have more time to focus on critical priorities while keeping details moving in the right direction. A few tips that will help ensure success include:

1. Choose wisely – One of the keys to delegating successfully is to select the “right” tasks to delegate. Delegating away your strengths rarely achieves success, and it does nothing for morale. Typically, delegating your areas of weakness can be a good approach; however, it is vital to take a few precautionary steps. Gain expert advice in surrounding yourself with strong project team members and supporters. Leverage those strengths of your team members that happen to coincide with your weaknesses. Don’t waste time delegating “C” items. Ignore them. Every action requires effort. Focus your efforts on what’s most important. Delegate the next set of priorities as you’ll want to make sure those get accomplished. Think about “C” items when all else is done.

2. Empower – Don’t throw around the word empowerment lightly. It is the rare project manager who knows how to empower his/her team. It means you must start by being a great leader. Provide guidelines. Collaborate on goals. Address the hard issues. Encourage team members to try new ideas. Support them in their failures. Take responsibility for the problems and share successes. Give your project team the ability to make decisions within their guidelines with full knowledge that they’ll be supported no matter the result. Soon, your team members will feel empowered. Once they are empowered, delegation becomes more of a collaborative affair.

3. Diversity – There are many different tasks required to ensure a successful outcome for a project team. In order to leverage your team members’ individual strengths while minimizing their weaknesses, you’ll need a diverse set of skills and people. Thus, you’ll have a much better chance of success in delegating the diverse types of tasks required if you have a broad set of skills in your team with a wide array of backgrounds. This will also stimulate ideas and debate which can encourage empowerment so long as the leader supports experimentation.

4. Core Metrics – Undoubtedly, no matter how effective you are in delegating, it will fall apart without core metrics in place. Work with your team to determine which critical milestones should be monitored. Develop leading metrics that will raise a red flag if the project is veering off-track. Put effort into making sure that the metrics selected will provide warnings in advance if needed. Don’t have too many metrics which become burdensome to track; instead, select the “right” few that will be indicators of success. Agree upon them with your team upfront.

5. Provide training & mentoring – In addition to delegating assignments, it is imperative that you take the time to accompany that task with the proper training and experiences to go with it. Mentoring can be valuable as well. Mentoring provides an example of someone who has “been there, done that” who is also an expert who is available for advice. By providing mentoring and/or helping your project team members find mentors in their area of expertise, you have, in effect, purchased insurance for your delegation. As anyone who has even been in an accident knows, insurance becomes invaluable when you need it.

Delegating project tasks has become a must in today’s new normal business environment. No leader has enough time to “do it all himself”, and no leader has the broad and diverse set of expertise required to be the ideal resource to handle every task. Instead, delegation provides not only a way to make sure the project gets done on time but it also adds to the quality of the result by leveraging team members’ strengths for the collective good.

Link source: http://www.projecttimes.com/lisa-anderson/keys-to-delegation-success.html

Memorize PMP Processes – The Easy Way

In this Article I will try to give some insight on how to memorize PMP processes, and how to relate them to the correspondent Process Group, and Knowledge Area.

We will be using the famous Project Management Process Groups and Knowledge Areas Mapping table from PMBOK guide, which is shown below, to demonstrate how we can easily relate the process to its Process Group and Knowledge Area.

As we all know, according to PMBOK® 5th Edition we have 47 PM processes, and these processes are scattered among 5 process groups, and 10 knowledge areas:

  • Initiating : 2 processes
  • Planning: 24 processes
  • Execution: 8 processes
  • Monitoring & Controlling: 11 processes
  • Closing: 2 processes.

So what is the easiest way we can use to relate each process to its process group?  It’s very obvious that Initiating & Closing process groups are not the ones that causing confusion here, since both of them has 4 processes in total, which leaves us with three Process Groups to focus on. You don’t have to memorize the 47 processes names; you just want to focus on some flash words, such as “Plan“, “Estimate“, “Perform“, “Develop“, “Control“, and “Validate“. Will discuss each one of them below.

  • Plan:
    • 11 processes have this word in its description:
      • Develop Project Management Plan: Integration Management Knowledge Area.
      • Plan Scope Management: Scope Management Knowledge Area.
      • Plan Schedule Management: Time Management Knowledge Area.
      • Plan Cost Management: Cost Management Knowledge Area.
      • Plan Quality Management: Quality Management Knowledge Area.
      • Plan Human Resource Management: Human Resource Management Knowledge Area.
      • Plan Communication Management: Communication Management Knowledge Area.
      • Plan Risk Management: Risk Management Knowledge Area.
      • Plan Risk Responses: Risk Management Knowledge Area.
      • Plan Procurement: Procurement Management Knowledge Area.
      • Plan Stakeholder Management: Stakeholder Management Knowledge Area.

All of the mentioned above processes belongs to the Planning Process Group, so if there is any question stating that you are in a process that has “plan” word, and then asks what you should do next, you should know that you are in the Planning phase of the project.

  • Estimate:
    • 3 processes have this word in its description:
      • Estimate Activity Resources: Time Management Knowledge Area.
      • Estimate Activity Duration: Time Management Knowledge Area.
      • Estimate Costs: Cost Management Knowledge Area.

All of the mentioned above processes belongs to the Planning Process Group.

  • Perform:
    • 4 processes have this word in its description:
      • Perform Integrated Change Control: Integration Management Knowledge Area.
      • Perform Quality Assurance: Quality Management Knowledge Area.
      • Perform Qualitative Risk Analysis: Risk Management Knowledge Area.
      • Perform Quantitative Risk Analysis: Risk Management Knowledge Area.

The first one belongs to Monitoring & Controlling Process Group and that because it has the“Control” word, “Perform Quality Assurance” goes under Executing Process Group, and the last two belongs to the Planning Process Group.

  • Develop:
    • 4 processes have this word in its description:
      • Develop Project Charter: Integration Management Knowledge Area.
      • Develop Project Management Plan: Integration Management Knowledge Area.
      • Develop Schedule: Time Management Knowledge Area.
      • Develop Project Team: Human Resource Management Knowledge Area.

All of the mentioned above processes belong to the Planning Process Group, except for the “Develop Project Team” belongs to Executing Process Group, and “Develop Project Charter” it belongs to Initiating Process Group.

  • Control:
    • 10 processes have this word in its description:
      • Monitor & Control Project Work: Integration Management Knowledge Area.
      • Perform Integrated Change Control: Integration Management Knowledge Area.
      • Control Scope: Scope Management Knowledge Area.
      • Control Schedule: Time Management Knowledge Area.
      • Control Costs: Cost Management Knowledge Area.
      • Control Quality: Quality Management Knowledge Area.
      • Control Communications: Communications Management Knowledge Area.
      • Control Risks: Risk Management Knowledge Area.
      • Control Procurements: Procurement Management Knowledge Area.
      • Control Stakeholder Engagement: Stakeholder Management Knowledge Area.

All of the mentioned above processes belong to the Monitoring & Controlling Process Group, the good news that 10 of 11 processes in the Monitoring & Controlling has the word “Control 🙂.

  • Validate:
    • only 1 process has this word in its description:
      • Validate Scope: Scope Management Knowledge Area, this process belongs to Monitoring & Controlling Process Group.

Project Management Process Groups and Knowledge Areas Mapping

So the advice here is you don’t have to memorize all and every process and in which Process Group and Knowledge Area it belongs, you need to focus on the flash words, as mentioned above. I hope you will find this post useful and it can help you in passing your PMP exam.

Your feedback is highly appreciated.

References: PMBOK® Guide 5th Edition by PMI

Source from: http://wafimohtaseb.com/2012/05/27/how-to-memorize-pmp-processes


Enterprise Architecture Approach in an HE Institution: 10 Practical Steps

What’s particular about doing EA in a research-intensive HE Institution like the University of Bristol?

For one thing the HE sector has some interesting dichotomies to grapple with such as the dual activities of a University like Bristol of both research and education. In a sense we are two businesses: the business of conducting research and the business of educating students, however these two activities do overlap (the researchers are often also the educators and some of the students we educate may well go on to become researchers). This has implications for our identity management and business intelligence strategies.

Another dichotomy is at the sector level at which Universities both compete and at the same time collaborate with each other. This means that we want to share considerable information about our activities (e.g. we partner up with other Universities in bids for research grants and then share research data with one another), but we may keep other information private, such as our research strategy, our IT strategy, or our student recruitment strategy and so on. Because of the nature of collaboration in our sector (plus the need to provide regular reporting to the government), some of the onus in IT terms is on data standards for interoperability and on secure, online collaboration tools to support researchers who may be geographically separated but who need to conduct research collaboratively.

There are many other complex aspects to doing EA in a University setting of course, and with a tightening of budgets and a change in the funding structure in recent years (students are now paying large sums of money for their University education) there is great pressure to rationalise IT architectures and IT support within an institution, whilst at the same time providing enough flexibility to cope with changing demands for information from the government (e.g. the REF, the KIS) and to future proof ourselves to cater for next generation research and education.

The University of Bristol is more than 100 years old and it has developed over that time with devolved budgets and much autonomy at faculty or department level. Support services at Bristol were reviewed a few years ago and a mission to centralise support, including IT, was launched. From an IT perspective it has felt rather like we have undergone a merger in an attempt to bring several, disparate organisations, all conducting their research and teaching in quite different ways into a single, harmonised organisation. So where does one start with EA in this situation?

  1. Map the existing (“As Is”) University’s Systems Applications Architecture to the Business Architecture: Get the 1000 feet view – with EA we are going to think gloStudent Lifecycle view of IT Applicationsbal even if we act local. Lifecycle diagrams (I’ve blogged about these elsewhere) are useful (an example here) in getting an initial overview of the systems architecture.
  2. Assess the how well the Applications Systems architecture “suits” the University’s Requirements Discover what are the University’s core IT systems that underpin its core processes. Do we have resilience in IT terms for supporting those core processes (note that Universities have a sense of an academic calendar, so some IT Systems are critical at certain times of the year, for example when making offers of places to students or timetabling their exams, or in some cases every few years for example in the critical period leading up to a REF submission). Do we understand the University’s required operating model  anOperating Models adapted from "Enterprise Architecture As Strategy"d do the IT Systems we have support this? For example, is it part of the University’s strategy to offer highly customised or even personalised services for students or to offer standardised services across the board? If we analyse different areas to interpret the University’s intended operating model for each then this should show  where cost savings could be made – unifying IT solutions is often cheaper, however it is essential to also understand where a diversity of technical solutions must be preserved for strategic reasons. For example, whilst it might make sense to have a unified solution for student administration, there could be good reason to allow for several different student assessment tools – because assessment might need to be carried out differently for Drama students than for Chemistry students, say. In assessing how fit for purpose the applications architecture is, there is also the significant area of information architecture which should also be reviewed – something we have only partially taken on so far at Bristol.
  3. Assess the Health of the University’s Data Architecture: if data is the life blood of the organisation then how do you measure how healthy your data architecture is? We have developed an Interface Catalogue to help understand our current data integration architecture more transparently and therefore how to improve it. In tandem we are developing an online Enterprise Data Dictionary in an attempt to centralise and maintain agreed data definitions across the organisation. We are working towards a data-centric SOA architecture in the longer term.
  4. Document Infrastructure Architecture encapsulated as a set of Services on which the Applications architecture depends – network, storage and servers. This can be shown as a layer of abstraction without worrying initially about the live, rapidly changing environment where we have deployed virtualised server solutions for example. I have documented recently about why we are doing this at Bristol – to support the analysis and the design of future improved architectures. This is the work of our Technical Architecture Virtual Team currently.
  5. Agree the level of IT innovation the University wants This is a strategic discussion to be had with senior management. Gartner Hype Cycles can be a useful way to initiate dialogue on this area as Gartner release hype cycles not only specific to the HE sector but also in relation to particular technologies. A good question is what does the technology hype cycle look like for our University? For example, will we be early or late adopters of 3D Printing, what is our strategy for MOOCs and how advanced is our Big Data strategy? Deciding where we are on new technologies is a key aspect to planning – will we need to be supporting 3D printers in every office around the University in five years time for example? And in which case what is the plan for that and what will it cost? The appetite for embracing newer technologies might vary in terms of existing skillsets and levels of resource in the IT Services department. It will also be affected by whether senior level management view IT as simply a functional thing or whether senior management are interested in what cutting edge technology can do for the University – how it could enable differentiation in an increasingly competitive sector. Our technical architecture virtual team is currently thinking about IT “horizon scanning” and documenting our thoughts using a “bricks” approach. We plan to develop the target architecture plan by examining our 2 year/5 year plans for each architectural brick, prioritising them and costing them so that we can determine a sensible roadmap for change using an holistic view of the IT architecture. We will then propose the roadmap to senior management, and aim to improve it continuously over time. Within a research intensive institution like Bristol, developing innovative IT solutions can also be part of research proposals. Similarly, the level of time that IT Services spends collaborating with the University’s research community like this should be agreed in principle with senior management at the institution.
  6. Develop the blueprint for SOA maturity and discover opportunities to partner up; Developing our University’s SOA (Service Oriented Architecture) blueprint is something we will be doing this year with the help of a product-agnostic consultant. Inputs to this process come from 1., 2. and 3. above. We will be keen to collaborate with other Universities at a similar level of SOA maturity in future and to look for opportunities for shared services going forward – with the goal of creating efficiencies.  A well aligned business architecture and a flexible data architecture across institutions will be needed to cope with this sort of endeavour, and this is no small “ask”. The UCISA EA group has plans to develop our opportunities for SOA at the sector level – the spirit of collaboration in the HE sector reaches far,  even in to the realm of IT Support services!; there are many of us undertaking Enterprise Architecture initiatives in our institutions and we are keen to continue to meet, share and learn.
  7. Develop the target (“To Be”) Technical Architecture for the University. The abstraction of required infrastructure services in 4. plus the SOA blueprint in 6 should help indicate the required To Be architecture, when appraised within the appetite-for-innovation context of 5. For example, we have several server virtualisation solutions at Bristol which we could rationalise, we have database vendor diversity which we would like to reduce without damaging corporate services and we have diverse CMS solutions and we should be initiating end of life plans for the older, legacy ones.  We also want to explore continued opportunities for Cloud solutions at the different architectural layers. We have moved email and calendaring into the cloud without too much difficulty as this was a fairly discrete part of the technical architecture to deal with. However other services have more complex interactions with each other currently and will require increased SOA maturity so that we can become agile enough to move services into the Cloud as and when we see fit. I consider the “to be” architecture to to be the reference architecture, with particular solution architectures developed to fulfill it.
  8. Encourage Senior Level Management to Engage fully with the concept of Total Cost of Ownership (TCO) Senior level management need to fully understand what this is and to be cognisant of the fact that when they approve a third party system the initial purchase is probably only the tip of the iceberg in terms of what the costs of supporting the product, upgrading it and most likely purchasing extension modules for it over time will be. For example, we are currently developing our roadmap for the launch of a second data centre and questions such as whether our products can support active-active are coming to the fore. If they are not able to then we may have to build solutions to compensate and this could add a cost to the data centre solution – a cost that we might have predicted when we first purchased the products in question. Other questions we might ask of product is whether it’s backed by only one database option and does IT services currently support that? Does the product come with a suitable web services api or will we have to augment it at our own cost? There are many such questions and it is worth looking at “non standard” products as incurring a support debt – a higher TCO – and making this transparent to senior management up front. Otherwise IT Services could find itself struggling to cope with support demands for which no budget was specifically allocated, whilst at the same time the IT architecture becomes harder to mature.
  9. Develop the IT Architecture Roadmap using all of the above. IT architecture should be a key plank of the IT strategy and the strategy should indicate what the vision of the IT plan is – the way to get from A (our current IT architecture state) to B (the future, desired state) being via a roadmap. Articulating principles (e.g. describing whether IT Services is mainly committed to building in-house solutions versus procuring third party solutions) is a key aspect of articulating the overall vision. It could be that we’re looking to create benefits such as cost reduction and so the vision will help describe where, say, moving to cloud services will reduce spending. The roadmap will likely indicate timings, dependencies and key milestones. Use of Archimate can be handy to present, visually, future architecture states along the roadmap. The 1 or 2 year projections may be clearer and more specific; longer term projections may be more generalised and allow for flexibility as the University’s strategy – as well as technology – will likely change in that time.
  10. Ensure the IT Architecture Roadmap is communicated and Service Development and Delivery Managed in Sufficiently devolved way: We are using ITIL as a framework in this respect at Bristol. Clearly there’s no point creating a roadmap if it isn’t to be fully communicated and all areas of IT Services committed to supporting it. This may mean a fresh commitment to documentation and formal processes regarding compliance with agreed IT standards and target architectural designs. Other stakeholders around the University will also need to understand the roadmap and its implications where relevant to them. The overall plan needs to be understood by senior level decision making bodies (at our University we have the Systems and Process Investment Board) such that they endorse it and accept that diverging from the blueprint could incur ‘IT debt’ as discussed above.

Source: http://enterprisearchitect.blogs.ilrt.org/