What are some of the fallacies of agile in capital projects and construction projects?

We often read articles about agile, agile project management, and agile development. Further, many of these articles could be from global associations or even “top” business consultancies. However, the challenge with many of these articles is that the authors of these posts insist that agile development works on capital projects and construction projects. For many years we asked them to explain to us how agile development works on a capital project or a construction project, even the construction of a house. There answers …

there answers is _____ i.e., blank.

First, agile or agility?

Before we go on into the core message, we must differentiate between agile and agility. As many of you know, agility is about being flexible, dynamic, responsive to change, etc. On the other hand, agile is about development, as in software development or product development. Therefore, it is critical to understand that our post is about agile development, not agility.

Definition of Capital Projects

Those of us who use the term capital project often take it for granted. We forget that some professionals might not know what it means.

The origin of the term is related to globally accepted accounting practices and taxation. Capital investments are also known as CAPEX, Capital Expenditures. Tax regulations consider CAPEX as the amount of the investment that is depreciated over the useful life of the product. In contrast, we have OPEX Operating Expenditures. From a tax perspective, the amount of the OPEX will be expensed in the year it is spent.

In the previous paragraph, I shared the origin of the term and what it means. However, depending on the context, most of the time we use this term, it is likely that we are talking about projects that would include the construction of a facility.

Therefore, a simple definition would be: capital projects would be capital investment by project owners to turn the project’s product into an asset that produces value to the organization.

Agile in Capital Projects

Agile – as in – agile development is mostly about software development. However, we can accept that it can be used in other types of projects, where the product can be developed incrementally. We wrote about this in the past and even have a series of videos. Therefore, to keep this short, we ask you to follow the links that we are sharing here.

The argument for agile in capital projects

So, what the argument of Agilists who insist that agile works in capital projects?

Sprints/Increments

One of the arguments is that in Agile Development, the team can divide the work into small pieces that can be accomplished in short increments. However, there are two problems here:

The first, the increment in agile development, should include the whole cycle, analysis, design, build, test, release. Whereas, in capital projects, it is impossible to do this entire cycle within a short time, even in two months. In agile development, the increment is released to the customer, whereas in construction, that is not relevant and is of no beneficial use to the customer.

The second problem with this reflects the lack of awareness of how capital projects are planned and structured. We use something called Work Breakdown Structure, have Agilists ever heard of this? Is not the concept of WBS is to break down the work into smaller, manageable pieces?

Planning

Another argument by Agilists is that traditional project management, or waterfall (which is not the same), requires “perfect” plans. In other words, there should be upfront, detailed plans, which will not allow for changes. “If there is a change, we must start all over again.” Well, I will let my friend Bill Duncan answer this, which was the subject of a LinkedIn post.

One final statement, have these Agilists heard about rolling wave planning?

Customers interface

I always love this argument since my answer is quick and short. One of the comments we hear promoting Agile over Waterfall (implied traditional) is that Agile requires an ongoing customer interface. Whereas, in a traditional setting, customer’s input and engagement only happen at the interface points, like the start or end. Two quick answers:

First, have these guys ever worked on a capital project?

Second, when I was working on capital projects, on the project owner team, throughout the implementation phase, our team would be located at the contractor office. In other words, the project owner team and the general contractor team are often in the same building and on the same floors. In construction, we are in the same trailers or adjacent trailers. Does that mean we cannot talk daily? Does that mean we do not have ongoing engagements? Not according to Agilists.

Multi-disciplinary teams

Although there are many more points that we can discuss, I will end it with this argument. In a post today on LinkedIn, someone made the argument that those in capital projects can learn from Agile development teams. We can learn about the concept of multi-disciplinary teams.

In response, I did a short slide presentation that I was going to post today. However, I decided to write this article and share those slides here.

In capital projects, and among organizations with good project management maturity, we use the concept of Integrated Project Teams, which is another term for multi-disciplinary teams. Download and see the slides.

Closing Comments

Agility, being flexible, adaptive, dynamic, is a core feature of mature project management practices. Further, we believe that by default, good project management is Adaptive Project Management.

Agile development can be great where it is applicable. Competent project managers know that Agile Development is NOT for construction and capital projects. Have fun with this last image.