Are The Project Triple Constraints Still Relevant?

There are many articles recently about the traditional project triple constraints: scope, schedule and budget, and how PMI recently in the PMBOK Guide, Fourth Edition (hereafter, the PMBOK Guide) replaced the triple constraints by a larger list of project constraints that project managers should consider.

The list of project constraints proposed by PMI is an extension of the triple constraints. Besides scope, schedule and budget, it includes resources, quality and risks. And it is not the full list, to quote the PMBOK Guide:

Managing a project typically includes:

  • Identify requirements,
  • Addressing the various needs, concerns, and expectations of the stakeholders as the project is planned and carried out,
  • Balancing the competing project constraints including, but not limited to:
  1. Scope,
  2. Quality,
  3. Schedule,
  4. Budget,
  5. Resources, and
  6. Risk.

So, are the traditional project triple constraints still relevant? Here are some of my thoughts

Continue reading

The Indispensable Couple of Risk Management: Risks Review and Risks Audit

Risks review and risks audit are different activities and have different purposes. Yet people often confuse these processes. Moreover, risks review is performed far more often, while risks audit is at least as much important. In fact, during project these processes should be performed simateneously and iteratively.

The main purpose of risks reviewing is to identify new risks, reassess risks likelihood, impact and urgency, and to check if risk triggers have appeared. In other words, we should answer the following questions

  • Are there new risks due to changes to the project schedule, budget, requirements etc. ?
  • Is our assessment of risk probabilities, impacts and urgency still actual? Do we need to revise?
  • Have the risk triggers occurred yet?
  • Do we have to change risks response plan as a result of changes to the project schedule, budget, requirements etc. ?

Risks audit, on the other hand, is the process of revising risk management activities. Its main objective is to ensure that we are effectively performing risk management.

Continue reading

Understanding Risk Attitude and Tolerance

Communication is crucial for every project. Most of the time project managers spend on communication with stakeholders. In order to effectively communicate with stakeholders, a project manager should understand their characteristics, among them are risk attitude and risk tolerance. This article will address these concepts in terms of the PMBOK Guide, Fourth Edition (hereafter, PMBOK Guide)

However, before getting into details, let’s define these terms first.

According to the PMBOK Guide, risk tolerance is “the degree, amount or volume of risk that an organization or individual will withstand”. If an organization or a stakeholder is willing to accept risks with high impact on the project objectives or with high probabilities, they are considered to have high risk tolerance.

Risk attitude, on the other hand, does not have official definition in the PMBOK Guide. It is only said that risk attitudes “are driven by perception, tolerances, and other biases, which should be made explicit whenever possible” (page 276).

There are 4 types of risk attitudes: risk averse, risk neutral, risk seeking and risk tolerant. Each type reflects a level at which a person is comfortable to risk. The image below from the book Understanding and Managing Risk Attitude may give you an easy way to understand risk attitudes.

Continue reading

Upstream and Downstream Project Management

I recently read a great article on Seth’s Blog : Upstream and Downstream, which discussed about the importance of “getting out of the box” in our job. It is right to project management, too. Although most project managers are proactive, many just get concentrated too much on their own activities and forget about the big picture.

Upstream project management

The main function of project managers is to balance various project constraints: scope, schedule, budget, risks, stakeholders’ expectations etc. However, if a project manager over-focuses on internal project environment, she may get lost in details and forget about the business needs of her project. By taking a closer look at the organization strategy and the project’ business case in a larger context, a project manager has a chance to deliver more value to her company.

Moreover, project sponsors are mostly senior management, who are more strategy-oriented than business-operation-oriented. To gain and maintain support for projects from these key stakeholders, a project manager should understand the business requirements for her project and regularly communicate with senior management not only about project status, but also about the extent to which her project is aligned with organization strategy.

Downstream project management

In many projects there is a group of stakeholders whose interest is not considered closely enough: end-users, i.e. those who will use the product of the project. Many project managers work most closely with customers, who authorize the project, give formal acceptance or rejection for project deliverables, etc. Actually, if a project team take into account end-users’ expectations seriously enough, they can avoid many problems with customers.

What are the impediments for project manager to go upstream and downstream

Many project managers choose to stay “in box”, not because they do not understand the importance of going upstream and downstream, but because it is safer for them to stay within the comfort zone. There are also many project managers who implement project management methodology just to “protect” themselves from being blamed. The main challenge for project managers to broaden their activities is to establish a trust relationship with key stakeholders: sponsor, customer, key end-users and project team. It is the most important responsibility for project managers to gain common understanding from these groups. Support from key stakeholders is the key for successful upstream and downstream project management