Tag Archives: Leading Megaprojects

What is the illusion of risk transfer?

Part of the following is from our book on Leading Megaprojects, A Tailored Approach. It is about the illusion of risk transfer that project owners might experience as a result of fixed-price contracting. We will first address the culture of fixed-price contracting, and next, we will discuss the illusion of risk transfer.

Continue reading

Why did I write a book about leading megaprojects?

Let me start with a few notes and clarifications. We define megaprojects as massive projects with capital costs around US$1 billion and a high level of complexity. Industrial megaprojects seem to perform better than infrastructure megaprojects. However, at best, what we have seen reported is a 35% success rate on the high end and as low as 0.5% on the questionable end. We do question the 0.5%, although it is reported by a reputable source. We also know that many organizations do follow a stage-gate process and might have project management systems. Then, why more projects fail than succeed? The response requires an analysis of the root causes. Next, the challenge is on finding a tailored approach for leading megaprojects concept to success. SUKAD has such an approach; therefore, it makes sense to write about it.

Continue reading

How to deal with the blockers of project management knowledge?

In this post, I am taking a small section from Chapter 1 of my upcoming book, Leading Megaprojects, A Tailored Approach to deal with what I call blockers of project management knowledge. The type of people who think that everything we need to know has been invented and no room for new knowledge or another perspective. I guess we need to ask universities to shut down; cancel their project management programs; or refer to some of these blockers to adopt their version of project management that they treat as the only “truth” or what I call narrow thinking or arrogance at the highest level. Is there a term for this level of arrogance? Back to the Blockers from Chapter 1.

Continue reading

How do we distinguish between project, program, and portfolio?

The following content is from Chapter 2 of Leading Megaprojects, a Tailored Approach. We want to define these terms for the context of the book. Further, we also post them here since various practitioners might have different definitions. We will be posting other definitions in the next few days. For today, we will define ‘what is a project,’ ‘what is a program,’ and ‘what is a portfolio.’

In the next few sections, we address each question, and we close with the link of a project to portfolio management.

What is a Project

The first question is about ‘what is a project,’ and here are the general points that we use to define a project:

  • A project could be anything we create from scratch or a significant modification to an existing system. Therefore, a project would require substantial effort in terms of development and delivery.
  • Also, it has a specific product (output), objectives (outcome), defined timeline (schedule), budget, and various other parameters (resources, quality, risks, etc.).
  • As a result, a project is an investment of time and money to deliver a product or service (output). Further, it must provide the capabilities to enable the realization of benefits (outcome).

Further, more on what is a project

  • The project owner can verify and accept the output at completion and closeout. However, he often cannot validate the outcome until months or years after the end of the physical work.
  • Finally, a project can be independent or part of a program. If it is part of a program, it must align with the program objective. Which in turn must align with the organizational strategic direction. On the other hand, if the project is independent, it must directly align with the organization’s strategic direction.

What Is Not a Project

In the previous message, we defined ‘what is a project.’ Consequently, we need to clarify the definition further by stressing what is not a project.

  • It is common knowledge that normal, routine, repeated actions (tasks)[1] are not projects. For example, something that requires a typical, repetitive business or manufacturing process to produce a gadget or X item would not be a project.
  • A phase of a project, or a stage, is not a project; more on this later.
  • Further, tasks that are part of a project are not projects, regardless of how big the task might be. For example, the graphical design for this book is not a project,[2] it is a piece of writing and publishing this book project, which one could label as a sub-project.

Next, let us add more information.

More information

Consequently, having said the above, we can still apply the project management process[3] on a piece of the project, be it a phase, stage, or a sub-project. The processes and process groups, such as the PDCA Cycle,[4] apply for tasks, sub-projects, or stages of a project. Consequently, it is vital to understand this point. Being able to use these processes on a piece does not make the piece a whole project. We stress this point because many practitioners confuse the processes and process groups from PMI® and ISO® as project phases.[5] Therefore, those who think that the process groups are phases mistake the process groups as the project life cycle, which is a fundamental problem. However, one might exclude micro-projects.

What is a Program

Next, we define the program, and here are the general guidelines that we follow to define a program:

  • A program is a group of related projects and may include other operational work.
  • The projects are related to a common business objective, often a long-term strategic objective that aligns with the organizational strategic direction, mission, and vision.
  • However, while working on the program, the organization may adjust the projects. For example, accelerating or slowing one or more projects in the program. The changes would be driven based on organizational needs and various other factors.[6]
  • The number of projects within a program could also increase or decrease as the organization collects feedback from the ongoing work and completed projects. Some might call this Agile Program Management, but we call it an adaptive project and program management. It is being nimble or adopting agility (discussed later in this chapter).
  • Finally, each project within the program must deliver some benefits. This would be in addition to the incremental or collective benefits of the entire program. This point might be controversial because we often see posts insisting that the business value exists only at the program level.

What is a Portfolio

We continue with the definitions and now we address what is a portfolio.

In this book, I do not refer to the term portfolio management often, because I see it as part of organizational project management. Also, a part of the management of projects and programs in the organization. Therefore, portfolio management is the highest level in the context of project management. It includes managing the overall portfolio, which consists of various change initiatives, strategic project management, project selection, and termination. In CAMMP™, portfolio management is active in the Discovery Phase, first with the idea and concept. Then, it is active at Stage Gate 2, in which the initial project authorization is granted through a portfolio assessment. During the project life cycle, portfolio management is active via the organizational and project governance.

Project Management and Portfolio Management

CAMMP Megaprojects, Program Management, Portfolio Management, What is a Project

As a result of the above definitions, the above image is the project life cycle for CAMMP MP (Megaprojects). Although this image is specific to a project, the image indirectly shows how a project integrates with portfolio management. Finally, portfolio management is active during the discovery phase, at project review and approval at stage gate 2.


[1] For differentiating tasks from projects, please refer to this blog article http://blog.sukad.com/how-to-differentiate-between-task-and-project/.

[2] We realize that the graphic designer, especially if an outside agency, might view the graphic design as their project. That is, for the service provider, the graphic design work from initial contact with the client until the successful completion of the work could be viewed as a project—a project for the service provider, not the client; more on this later in the chapter.

[3] Such as those described in ISO 21500 (Guidance to Project Management) or the PMBOK® Guide (A Guide to the Project Management Body of Knowledge®).

[4] Plan–Do–Check–Act from Total Quality Management (Deming, 195#).

[5] This is possibly one of the most common areas of confusion in the project management community today.

[6] One might consider these adjustments as being driven by the emergent strategy generated from feedback and monitoring actual performance or responses.

What are the megaprojects challenges?

The following file includes the challenges that we have identified for megaprojects from observations, experience, literature review, and case studies. The table is from our book, Leading Megaprojects, A Tailored Approach, which is work in progress now.

Continue reading

Do project owners need help transforming to lead megaprojects?

Let us repeat the title question: Do project owners need help transforming to lead megaprojects? Studies by the Independent Project Analysis (IPA) and others have clearly identified a few key facts. The facts include project owners that manage their own projects directly, achieve better results than if the projects were managed by external parties. Another finding is that about half of their clients (IPA) have an organizational project management system (OPMS) that are poor or in needs of drastic improvements. Therefore, considering these two facts, then we raise more questions.

Continue reading

A Tale of Two Megaprojects

In the previous post, we wrote explaining why we are writing a book about megaprojects. In this post, I will share one of the chapters that discuss two megaprojects. These megaprojects share a lot of similarities but different outcomes. This chapter is from my upcoming book, Leading Megaprojects, a Tailored Approach.

Continue reading

Why am I writing a book about leading megaprojects?

We define megaprojects as massive projects with capital cost around US$1 billion and a high level of complexity. Industrial megaprojects seem to perform better than infrastructure megaprojects. However, at best, what we have seen reported is 35% success rate on the high end and as low as 0.5% on the other end. We do question the 0.5%, although it is reported by a reputable source. Then, the challenge is on finding a tailored approach for leading megaprojects and since we have such an approach, it makes sense to write about it.

Continue reading