In recent years, the implementation of Agile mindsets or methodologies has become an increasingly common trend within organizational management. In a 2017 McKinsey Quarterly survey of 2,500 business leaders, 75% of respondents said organizational agility was a top or top-three priority, and nearly 40% were in the process of conducting an organizational-agility transformation [1]. In a 2018 Forbes article [2], Agile was described in adulatory terms:
“…The world is entering a new age: the age of Agile. An unstoppable revolution is now under way in our society, affecting almost everyone. Agile organizations are connecting everyone and everything, everywhere, all the time. They are capable of delivering instant, intimate, frictionless value on a large scale.”
With this type of public praise, it seems that any executive not working on Agile may be accused of dereliction of duty. However, much of the hyperbole is coming from those who have a vested interest in the Agile movement, e.g., consultants and providers of Agile services and products. According to those sources, it would appear that Agile is well suited to revolutionize any business or industry, including engineering & construction. Indeed, major capital project owners are responding to the allure of Agile, with many working to apply the concepts to capital project delivery.
However, as many are aware, no one trend, technology or person holds the key to a complete and sustainable solution. Executives are always looking for the latest initiatives to spur success: Lean, Six Sigma, LeanSigma, Total Quality Management, Modularization, and Critical Chain Management are all examples of fads and trends that spike and may level off to stability if sustainable value is provided, fade away if not, or be renamed and absorbed into new fads. The initiatives mentioned above exhibit the characteristics of fads: they’re simple, falsely encouraging, one-size-fits-all, novel but not radical, easy to cut and paste, and legitimized by gurus and disciples, i.e., consultants [3]. To assist in avoiding the many dangerous pitfalls of Agile as a management fad and achieve best possible project delivery, we pose the question, Does Agile apply to capital projects? This article explores what Agile means, summarizes the origin of Agile in software development, contrasts software development and capital project delivery, assesses the implications of the differences, and considers options for achieving best possible project delivery.
Agile has many different meanings; it depends on who you ask. The Merriam-Webster dictionary’s definition of agile is: “1: marked by ready ability to move with quick easy grace or 2: having a quick resourceful and adaptable character.” Many times, executives employ these meanings of the term as aspirational characteristics they would like to have in their companies and that is the extent of their application of “agile”.
The transfer of “Agile Development” practices from software development projects has led to the management trend in which Agile (note: we now use the terms “Agile” and “Agile Development” interchangeably) can be a mindset, a set of methods / toolkit, such as kanban, sprint and scrum, or a means of structuring an organization (self-organizing teams). Its primary purpose is to develop and deliver faster, better products and software.
Agile stems from efforts in the software engineering world by those who did not like the waterfall and time fence approach of the earlier pioneers of software engineering. Various sources have been credited with coining the term “software engineering” including Frederich Bauer [4] and Margaret Hamilton [5]. Many concepts, including Data Warehouse, Software Factories and Sprints, were modifications of industrial and manufacturing practices to accelerate product introductions. As the demand for software increased, speed to market became an overriding priority, lowering the priority of other goals such as quality. As computer users from that era know, the “blue screen of death” became an accepted occurrence. A reboot or delete of the offending application was the tedious, and usually effective, solution. In comparison, this constant reset of the product is not a solution to engineering and fabrication for physical products.
There has been an intuitive recognition, which gained steam in the 1990s, that traditional waterfall approaches to software development were unwieldy, time-consuming and morale-killing for software development teams. In 2001, a group of software development professionals formulated and published the Agile Manifesto [6] in an effort to break the traditional software development project mold and free software developers from unreasonable, unproductive constraints. From this initial trajectory, Agile Development momentum exploded into general use.
A definition of Agile in the context of capital project delivery is given as: a collection of values, principles, and practices originating from the Agile Manifesto that is used to improve project delivery.
The following non-exhaustive lists summarize Agile values and practices, edited to apply a capital project vernacular. However, we make a strong disclaimer that the lists below are neither comprehensive nor indisputable. However, they capture core Agile terminology and practices and will suffice for discussion on whether Agile works for capital projects. There are many different, sometimes conflicting, sources of information as to make claim and counterclaim a central feature of discussion about Agile. There is no governmental or internationally recognized agency that maintains standards for Agile Development. Anyone with a website can post Agile definitions and claim authority. There are no scientific laws of Agile. It seems that executives wanting to implement Agile for capital projects are on their own in deciding values, principles, and practices that work for them. That is unless they hire the consultants, service providers or software companies promoting Agile.
| AGILE PROJECT VALUES | |
| 1. | Individuals and interactions over processes and tools |
| 2. | Working structures/products/designs over comprehensive documentation |
| 3. | Customer collaboration over contract negotiation |
| 4. | Responding to change over following a plan |
Table 1: Capital Project Version of Agile Values [7]
The twelve Agile principles below have been paraphrased from the original Agile Manifesto’s 12 principles.
Below provides definitions of some common conventions used by those who practice Agile.
Scrum – a framework for project work planning through work completion. The result of the work could be anything that is produced as part of a capital project, e.g., a design, a drawing, a product, or a structure.
Sprint – an event whereby a designated amount of work is targeted for completion in a fixed period of time. Typically, a Sprint is from two to four weeks of work. Sprint participants determine and complete work requirements through self-organization.
Kanban – a method for tracking work. Not primarily a WIP control mechanism as in Lean. Can be done with software or with physical boards and sticky notes.
User Stories – a way to define requirements or features for projects.
Time boxing – a method of limiting the amount of time required to complete a given amount of work. A Sprint is a form of time boxing.
Having provided history, definition and description for reference, we now identify and contrast characteristics of Agile software development and capital project delivery. This contrast identifies issues to be considered in determining Agile’s suitability for capital projects.
Agile Development has proven very successful in transforming software development. For instance, Cisco reports a 44% decrease in critical and major defects through application of Agile techniques. [8]
Prior to the emergence of Agile Development, software development was typically managed using the Waterfall method. This was a result of software being a component of a larger solution which most often included hardware, i.e., a mainframe computer or some other device. With the advent of micro-computers, operating systems, the internet and later cloud-based software, the requirement for software to be a component of an overall, or what is known as a whole solution, diminished. Software itself became a product. For instance, companies such as Autodesk, Facebook and Salesforce do not offer products but rather offer software that operates on products brought to market by other companies such as Apple, Dell, Samsung, etc.
| COMPANY | HARDWARE | OPERATING SYSTEM | SOFTWARE |
| Apple | ● | ● | ● |
| – | ● | ● | |
| Xerox | ● | ● | – |
Table 2: Hardware and Software Companies and Their Offerings
Software companies are members of a wider ecosystem and the characteristics of software as a product enable them to play across several hardware and operating system providers. To enhance competitiveness and take advantage of rapidly changing technology, companies developing software often avoid long development cycle times driven by traditional waterfall development practices. Speed is prioritized over quality and resource optimization. Companies often do not wait until complete software design and testing is done. Indeed, a “complete” design is often a moving target. These companies typically release software versions without all of the originally conceived or desired features. Additionally, these version releases often have a number of bugs that may have been eliminated with more extensive testing.
This practice is obvious when looking at common software products. The following timeline depicts the release of new cellphone hardware, operating system software and operating system updates for Apple (Figure 1) and Google (Figure 2). The figures show a timeline of months from left to right starting in April 2007 and ending in January 2020. The orange lines represent software (operating system) releases, the blue lines are hardware (phone) releases and the green lines are software updates.
Figure 1: Apple iPhone and IOS Version Upgrades and iOS Update Release Dates
Figure 2: Google Android Operating System Version Upgrades and Update Release Dates
Clearly, both Apple and Google have settled into annual releases of hardware and operating systems and then release software updates to the operating system as needed. They leverage the ability to issue software without complete testing, as shown by the sequence of operating system releases and software updates relative to the release of hardware in Figures 1 and 2. While Apple and Google (“dogfooding” is the term Google uses for software development) both practice Agile iterative software code launches, hardware releases are driven by waterfall development and testing requirements.
A 2016 Bloomberg interview with Johnny Soruji, Apple’s Senior Vice President, Hardware Technologies, provides more insight.
“If there’s a bug in software, you simply release a corrected version. It’s different with hardware [where] ‘you get one transistor wrong, it’s done, game over,’ Srouji says. Testing proceeds for several days on one element of the chip, then moves on to the next, and then the next, until the process is done, which can take months. ‘We beat the silicon as much as we can,’ Srouji says. ‘If you’re lucky and rigorous, you find the mistakes before you ship.’” [9]
The fundamental differences between capital projects and software development projects should give pause in any headlong rush to apply Agile on construction projects. We describe those differences in more detail next.
It is important to understand the major differences between projects’ goals, challenges, and characteristics to determine what works best for project delivery and when. As mentioned above, a primary goal for many software development projects is speed to market. The same is true for capital projects but many capital project characteristics throttle speed to market and dictate more structured management methods than may be required for software development projects.
A strong indicator of required management methods is the physical attributes (physicality) of the end product. On one side, software development projects may contain millions of lines of code and require new programming languages or technologies. For the most part, all of the work on software development occurs in the digital world. To fix a software bug requires determining the problems in the code, coding a fix, testing the fix and then coordinating updates of the current version. As end products move from the digital world, physicality of the end product imposes increasing adjustment penalty. Adjustment penalty refers to the cost or effort required to change a product or asset, as seen in Figure 3.
Figure 3: Adjustment Penalty Increases as Physicality Increases
As we move from pure software to physically manufactured products, additional considerations are added including supply chain decisions, re-tooling of plants, construction of new plants, ramp-up, and HSSE (health, safety, security, environment) requirements. Achieving life safety requirements for physical products requires more engineering, more testing and more certification.
To illustrate these complexities, take the recent example of the Boeing 737 MAX airliner fleet that was grounded for 20 months, from March 2019 to November 2020, due to flight control software that was installed because of hardware requirements. Briefly, the 737 MAX’s engines were mounted very far forward on the wing due to their size. This introduced a tendency to lift the nose too high on takeoff. The flight control software was modified from an older 737 model to compensate. Tragically, both the software fix and pilots’ training on the new hardware were not adequately addressed, resulting in two crashes and hundreds of deaths. Due to the fatalities from a 737 MAX crash in 2018 and again in 2019, Boeing established a $100 million relief fund for affected families and communities. [10] In January 2020, about 400 finished 737 MAX airplanes were in storage because they couldn’t be delivered to their customers [11]. Extreme testing, verification and rework is required to return the 737 MAX to service. It requires a waterfall sequence of software modifications, then hardware testing with documentation. The Federal Aviation Administration would take a dim view of sprints to provide fixes, release software to hardware integration, run the hardware and, if there are any problems, fix the hardware performance problems (plane crashes) with new software releases all the while providing minimal documentation of the changes.
There is some discussion that the era of unfettered maneuverability may change even for consumer software giants like Facebook, Google and Apple. With the passage of the EU’s General Data Protection Regulation and passage of California’s Consumer Privacy Act, there will be more serious implications for software development errors that result in legal violations of privacy. Although software, hardware and networks are transforming the digitalization of transportation, air quality, water purity, buildings, materials, and environment, the system will never be solely responsible for the public’s overall health, safety, security or environment—you can’t sue a “system.” For the foreseeable future, this responsibility will always be with humans and their organizations. Although the fads and fashions will continue to change, it may be that we are at the dawn of an age where Agile techniques will be curtailed in recognition of moral or legal responsibilities resulting from providing consumer and industrial software products [12] [13].
In contrast to software development, capital projects do design, engineering, fabrication, build, and install once. It would be hard to imagine capital project delivery for liquid natural gas (LNG) plants or hospitals using the same approach as Facebook does for software updates. First, “bugs” in the structure or systems could cause catastrophic results – the LNG plant might blow up or the hospital might collapse, or systems could fail resulting in injury or loss of life. Second, the amount of resources required to build a new version of a building on an annual basis would be prohibitive. Third, the amount of time required to build large structures is often longer than a year, so planning on replacing a building every year wouldn’t be possible—the new building would have to be replaced before the existing building project was completed.
In capital projects, risk mitigation is a huge effort and may include 3D modeling, prototype build and test and onsite build and testing. For the most part, software products do not require a significant amount of regulatory and external financing constraints.
Current regulatory requirements in the software business are far different than that of the construction business. For the most part, software and product development do not require: 1) planning permission including environmental impact studies and the associated acceptance, 2) permitting including building and operating / occupancy, and 3) review by third-party financing and bonding companies. For instance, for building a new hospital in California, the Office of Statewide Health Planning and Development (OSHPD) requires very detailed design to be completed for submission for a building permit. Any changes in design then require an extensive re-review and approval process.
Capital project regulatory specifications dictate design and construction process requirements that do not exist for software development projects. For a simple example on a small capital project, consider the process to build a house where there are building codes. The process often requires that the design be approved before construction can commence. Usually, the permit for construction has to be publicly displayed on the job site before construction starts so anyone passing by can see the project has been approved. If building commences and there is a desired change to the design, the change must be described in detail and the entire new design approved prior to additional work progressing (there may be flexibility on timing, but the requirement is not waived). Once construction has finished, the house must be reviewed to ensure that it complies to the design as submitted and approved.
These types of approval and inspection requirements and associated documentation are what Agile Development tries to reduce to a bare minimum or eliminate. Since the requirements for software development are usually self-imposed by a company, there is much more flexibility to change them than if dealing with state or federal legal requirements. Software inspection is often performed by end-users once the software is released. Customer inspection, also known as using new software, provides results as reported bugs.
In contrast, approval and inspection processes cannot be circumvented in capital projects. On the contrary, constructing a building in or near a protected wetland or laying a pipeline across wilderness areas guarantees that the approval and inspection process will be extremely detailed and exacting for good reason.
Another difference between capital projects and Agile software projects is requirements definition timing, as seen in Table 3. This characteristic is affected again by the physical nature of projects.
| PROJECT TYPE | EXAMPLE | REQUIREMENTS | REQUIREMENTS TIMING |
| Fixed Site Construction | Hospital | Pre-defined | Prior to construction |
| Deployment Construction | Network of electric car charging stations | Pre-defined | Prior to construction, some modification due to location |
| Maintenance, Repair and Overhaul (MRO) | Power plant turnaround | Partially known | Some known prior, many discovered during turnaround |
| Software Development | Operating system creation | Partially known | Can be changed right up to release |
Table 3: Project Types and Requirements Timing
The first two project types in Table 3 necessitate requirements definition of the project before design and engineering start. Certainly, there are adjustments made to compensate for engineering or construction problems discovered during the project but a company doesn’t invest in a major capital project by starting with “user stories” to decide if they should be building a 5 MTPA LNG plant. In addition, due to the physicality of construction, changes are often extremely expensive.
An MRO project has a very specific set of maintenance activities defined in extensive detail prior to a turnaround. Turnarounds are usually severely time constrained. For a refinery losing millions of dollars in revenue every day the refinery is shut down or a power plant taking power capacity offline in a major metropolitan area, every minute of down time counts. Additionally, MRO projects are complicated by unknowns such as turbine blades being discovered to have severe moisture erosion on inspection and requiring full replacement. These MRO projects are not the type of exercises performed by self-organizing efforts to determine what is required.
It is also not fair to say that software development projects are completely open-ended. There are specific requirements for an operating system to be developed for the hardware of a new phone. On the other hand, the definition of a new customer management system (CMS) can start from a very wide funnel of user-story requirements before getting to the final product. Additionally, software project requirements can often be changed right before release of the software. For the CMS, there is no physical reason why, for example, a sorting function couldn’t be added the day before release.
In summary, Agile Development encourages “tinkering” as part of the project to define a final design. A team that is tinkering with a software design is trying different things to see if they work or if people like them. That is a primary characteristic of Agile and it is hard to see how that translates substantially to improving capital project delivery. It seems fairly easy to see how tinkering might actually hurt capital project design and delivery.
There are huge differences between management requirements for software development and capital project delivery. Even so, many of the Agile practices cited above are already done in capital projects. They are not called by the same names, but these Agile practices often don’t result in best possible outcomes for capital projects. Next we look at initial phases of capital projects where the work shares similarities to software. Then we’ll go deeper into a construction example for further discussion as to how Agile practices are already applied and how they can work against project success.
For most capital projects, a high-level process description is as shown as in Figure 4.
Figure 4: High Level Capital Project Process Map
For any project, whether in Define, Design /Engineer or Construct, there is a schedule with time fences with a list of tasks that need to be completed. At a more granular level, there are “lookaheads” where planners or managers are taking smaller chunks of work and doing detailed planning about what needs to happen to accomplish the work in a time frame of, for example, two to four weeks. At the most granular level, particularly during construction, there are shift stand up meetings, where the shift’s activities are coordinated based on the work available. These elements are not much different than the elements of the Scrum framework shown in Figure 5.
![The Scrum Framework [14]](https://projectproduction.org/wp-content/uploads/2020/10/image006-1024x439.png)
Figure 5: The Scrum Framework [14]
Following is a table with a comparison of the elements of traditional project controls and associated time frames. It makes sense that Agile and traditional project controls would have similar elements of management, as they’re both managing tasks over time.
| AGILE | PROJECT CONTROLS | TIME FRAME |
| Product Backlog | Master Schedule | Entire project |
| Sprint Backlog | Lookahead | 4 weeks to 1 week |
| Daily Scrum | Stand up meeting | Daily |
Table 4: Comparison of Agile Elements and Traditional Project Controls Elements
Interestingly, capital project owners have demonstrated use cases of excellent results in reducing cycle times when applying Agile techniques to the initial phases of a project such as Design or Detail Engineering. This points to the question, “What accounts for Agile’s improved results over traditional project controls, in the initial capital project phase, given that both use essentially the same management elements?” We propose a couple of reasons:
The similarities between software development for software products and design / engineering for capital products seems to ease the application of Agile to capital project delivery, especially in design and engineering processes. In fabrication, delivery, construction and commissioning, the suitability of Agile methods for project delivery is much more questionable.
The Agile approach for design and engineering can produce good results for certain types of projects, as has been demonstrated. However, it is a dangerous practice to draw universal conclusions from limited data.
Judging from software development results, Agile’s best results will be in small capital projects, but Agile has high odds of failure in design and engineering for large capital projects. The Standish Group has been conducting extensive surveys of Agile Development usage in software projects since 1994. Project success rates of only 18% occur when using Agile with large software projects, which is much better than with a traditional waterfall approach (3%). Given that Agile has been in use for 16 years or so, the data does not support the idea that Agile practitioners are still working out the kinks in a new process.
Agile has fundamental flaws that cripple software project management, though it often works better than traditional software development waterfall practices. According to the Standish Group research on over 10,000 software projects, “size was the single most important factor in the resolution of project outcome.” Small software development projects have a success rate of 58%—is this an aspirational goal for anyone? [15] Would a hospital be satisfied with a 58% success rate for heart surgery patients? Capital project executives considering Agile as a management approach are cautioned about expecting some miraculous solution to all their project delivery problems. As long as they keep the Agile focus to small projects and to the design and engineering phases, results may improve but that’s only if capital projects in design and engineering behave just like software development projects. There are potential problems with the Agile approach that could actually make results worse in capital project design and engineering.
As discussed above, instituting regular meetings, reporting and planning would be beneficial in capital project design and engineering. However, Agile Development in design and engineering can lead to increased cost for capital projects. The reason has to do, again, with the physicality of capital projects and all the attendant requirements of regulation. If engineering is done with self-organizing teams working quickly in sprints with little documentation, the danger is that the overall physical sequence constraints (waterfall requirements) of the capital project will be violated resulting in extensive rework. For instance, if the software controls for an airplane are designed before the wing position for the engines is finalized, there will be rework.
Another primary gap in Agile Development for any type of project is in capacity planning.
“There is also a misconception in terms of using the capacity of the Development Team for planning. Some believe that calculating the team capacity in hours and estimating all the task is the best way for to (sic) plan a Sprint. I think we all can agree that it will take a lot of time. Let’s look at using the capacity without detail calculation. Basically, check with your team if there are any holidays in the current Sprint or absences. Now, look how does it compare to full capacity and what is the impact to the Velocity. (sic) It is simple as that. Please, if you still want to go with precise calculations, remember to leave a buffer for the unexpected.” [16] – Scrum.org website
There are two points here that make this typical Agile approach unsuitable for project delivery:
To summarize, Agile may bring some benefits to engineering and design of small capital projects by speeding up the coordination process, i.e. increasing meeting productivity, if there is a heavily bureaucratic culture in the company’s capital project management process. However, there is a real danger that this same increase in speed can lead to increased rework and costs if self-organized teams are working quickly and not coordinating with the waterfall coordination dictated by the physicality of capital projects. Agile benefit translates from software development to capital projects primarily for small projects and seemingly for only the design and engineering phases of a capital project. In many cases, Agile methods ignore other success requirements. Other than isolated successes, the demonstrated results of Agile should give executives pause when considering how best to establish an overall capital project delivery approach. When it comes to the physical aspects of capital projects, i.e. fabrication, delivery, installation/construction and testing, the question of Agile’s suitability is even more pronounced.
Most capital project managers use Agile techniques in construction though they don’t call them that. If the overall results of these Agile approaches in construction had been even mildly successful for on-time and on-budget performance, would Agile’s suitability even be a question? For further discussion of Agile in the physical domain of capital projects, we will provide an example of construction of a refinery.
![Construction of HPCL Visakh Refinery in India [17]](https://projectproduction.org/wp-content/uploads/2020/10/image007.png)
Figure 6: Construction of HPCL Visakh Refinery in India [17]
When building out a refinery, construction teams typically prioritize work by areas first (as seen in Figure 7) then they will shift to a systems focus as system components become available to commission. The systems closely correspond to the green blocks in Figure 8. In Figure 8, the 1, 2 and 3 Crude Oil Distillation Units (CDU) are first in the refinery process. The Propylene Recovery Unit (PRU) is three operations away from CDU though physically, right next to the CDUs as shown in Figure 7. This incongruence between physical location and process flow sequence applies also to commissioning. There is very often no one-to-one correspondence of area to commissioning system. For instance, the CDU commissioning process will require pressure testing pipes flowing across different areas.
![Area Layout Diagram for HPCL Visakh Refinery [18]](https://projectproduction.org/wp-content/uploads/2020/10/image008.png)
Figure 7: Area Layout Diagram for HPCL Visakh Refinery [18]
![Block Diagram for HPCL Visakh Refinery [19]](https://projectproduction.org/wp-content/uploads/2020/10/image009.png)
Figure 8: Block Diagram for HPCL Visakh Refinery [19]
| AGILE ELEMENT | CONSTRUCTION EQUIVALENT | NOTES |
| Project Backlog | All the tasks and associated resources (materials, equipment and people) required to complete the tasks | Construction approach is to get as much of that as possible to the site to be able to work as “efficiently” as is possible. |
| Sprint Backlog | Two week lookahead | Available areas, materials and resources to work on in the next couple of weeks. Checked against schedule and sequence requirements but earning hours is the primary goal |
| Daily Scrum | Stand up meeting | What can we work on this shift? Many work fronts open, keep people busy by moving to open areas with available equipment and materials |
Table 5: Everyday Agile Construction Practices
It is instructive to see how this Agile approach to onsite construction can contribute to project delays and cost overages. The Agile approach and some site construction practices are similar but there are still chronic problems in capital project delivery. The practices do not provide success without understanding and appropriate control of the underlying production systems. The Construction Agile practices also provide physical representation of problems seen in the virtual world of design and engineering.
We’ll further develop the refinery example to focus on welding. When completing the physical structure of a refinery, there are thousands of welds that have to be welded. Systems can’t be completed and commissioned until all the welds in the system are done. As mentioned, one system may cross multiple areas. Figure 9 details welds required for an actual refinery construction project. The welding activity described is only for a portion of the refinery construction, the full construction activity would be much more complex.
The following diagrams illustrate a common Agile approach which is typically highly counter-productive. The approach ignores the waterfall requirements of commissioning systems and takes an Agile focus on getting work done. It perfectly follows three of the four Capital Project Agile Values in Table 1.
The fourth Agile value of customer collaboration over contract negotiation has already been baked in at this point in the project – there is nothing to be done about customer requirements at this stage.
Figure 9 provides an illustration of the required sequence and number of welds by system that remain to be completed. Welding work has been going on for months. The dates along the top are the days when each system is scheduled to be completed in the project. Day 1 is the date the data was reported. All systems are to be completed 156 days from Day 1. The rows show the systems in order of scheduled completion to enable commissioning. The numbers in the chart represent the number of welds remaining to be completed for each system, so left to right is the sequence of the number of welds required to be ready for commissioning.
Figure 9: Remaining Weld Requirements to Have Systems Ready for Completion
There are a number of interesting observations about this plan. For instance, why are so many systems required to be ready during one day, for example Day 89? Is that even possible given construction and welding resource capacity? This certainly raises doubt about Agile’s suitability for handling this type of project when those are questions that Agile does not consider. Looking at Figure 10, we see the welds that have actually been completed, as of Day 1, using the Agile approach described above.
Figure 10: Actual Welds Completed to Date
Has the Agile approach to construction resulted in the sequence required for commissioning? Figure 10 shows that there are welds completed that are not needed for 146 days. Of the welds completed, 81% of them have been completed at least 89 days before the system is scheduled to be completed. Furthermore, of the systems scheduled to be commissioned within the next 86 days, only 22% of the welds have been completed. While the Agile construction approach has provided plenty of earned hours for reporting progress on construction, there appears to be a strong disconnect when it comes to completing commissioning on time.
Given the number of welds completed to date, all of the systems highlighted in orange would be completely welded if all welds had been completed in commissioning sequence. One could surmise that perfect sequencing of weld completion is highly unlikely given the variability encountered on the construction site, so maybe not all of the 18 systems would be welded complete at the date of the report. However, is it not also obvious that this self-organizing, co-located, Agile approach to work resulted in tremendous wasted effort completing welds that weren’t needed for months? This wasted effort does not even include all the waste associated with managing and coordinating massive amounts of inventory on site. See Shenoy [20] for more detailed treatment of the use of inventory on job sites. Hopefully, the physical example of welding on a construction site provides illustration of how the same types of waste can occur in design and engineering. The wasted effort is not so obvious in design and engineering given the virtual nature of the work product.
We started this paper with the question, Does Agile Apply to Capital Projects? As we have shown, Agile methods can be applied in capital projects. The question remains as to whether any executive would bet their career on rolling out Agile methods across their company for capital projects. In other words, is Agile suitable for capital projects?
Based on our research and experience, it seems that Agile is not well suited to capital projects. Agile is a loose collection of values, principles and practices that is often applied to improve project delivery. In contrast to the hard science that is used to determine, for example, the suitability of a subsea tree valve for the pressure, temperature, corrosion and flows it will encounter, there is no hard science of Agile to understand the resource utilization levels, work-in-process requirements, cycle times and variability levels that dominate and determine the results of every capital project. These parameters must also be viewed in the context of waterfall and sequence requirements and the overarching financial and regulatory requirements for every capital project. The physicality of capital projects does not facilitate an empirically-based approach to project delivery where “fail-fast” can lead to delays at best and loss of life at worst.
In further discussion of the suitability question, we review the twelve principles of Agile as described earlier.
| AGILE PRINCIPLE | CAPITAL PROJECT SUITABILITY | |
| 1 | Customer satisfaction through early and continuous delivery – Customers are happier when they receive working structures/products/designs at regular intervals, rather than waiting extended periods of time between delivery | A capital project typically delivers a final structure or product that is delivered once |
| 2 | Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes | Working to avoid delays on the 737 MAX due to the feature change led directly to loss of life. Working to avoid delays should not be a primary aspiration. Operations science applied to projects enables optimal variability buffering while still achieving schedule and cost |
| 3 | Frequent delivery of working structures/products/designs – Scrum accommodates this principle since the team operates in sprints or iterations that ensure regular delivery of working structures/products/designs | As discussed in the refinery welding example, frequent completion of work does not guarantee optimal results and may be counter-productive |
| 4 | Collaboration between the business stakeholders and project personnel throughout the project – Better decisions are made when the business and technical team are aligned | Same for any project and any approach |
| 5 | Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams | Same for any project and any approach |
| 6 | Enable face-to-face interactions – Communication is more successful when project teams are co-located | Co-location is no guarantee of more success. Reference the remote work going on in the COVID pandemic. Companies are realizing co-location is not a critical factor of success |
| 7 | Working structures/products/designs are the primary measure of progress – Delivering functional structures/products/designs to the customer is the ultimate factor that measures progress | Referring again to the refinery welding example, a focus on output without waterfall, regulatory and financial considerations is counterproductive |
| 8 | Agile processes to support a consistent project pace – Teams establish a repeatable and maintainable speed at which they can deliver working structures/products/designs, and they repeat it with each release | This is a widespread fallacy. Variability in demand is a fact of life. Is it not more realistic to establish a system that can analyze and manage fluctuations in demand, i.e. pace, then to try and artificially flatten demand? |
| 9 | Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change | Same for any project and any approach |
| 10 | Simplicity – Develop just enough to get the job done for right now | So general as to have trivial content. This is similar to saying, “Buy low, sell high” |
| 11 | Self-organizing teams encourage great structures/products/designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products | There is no question that motivated, engaged team members are desired for any capital project. However the important financial, regulatory, waterfall and sequence requirements of capital projects leave little room for teams to organize the work on their own without overall coordination |
| 12 | Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently | Same for any project and any approach |
Table 6: Comparison of Agile Principles for Capital Projects
Finally, it is interesting that there is no mention of safety in Agile values, principals or practices. Safety does not appear to have ever been a primary Agile focus.
Given that the Agile Development process does not appear well-suited to capital project delivery, what should executives do? There is no doubt that companies should strive to have reaction agility to manage the variability inherent in project delivery environments while meeting regulatory requirements. There have been successes with Agile Development and given the narrow areas where Scrum can work, it can be applied. However, success in project delivery for large complex capital projects requires much more science and technology than Agile offers. The good news is that there is no need to reinvent the wheel.
Concurrent Digital Engineering (CDE) provides a well-defined set of technologies and practices to handle even the most complex capital projects. [21] Embracing the loose collection of values, principles and practices that comprise Agile Development seems a seriously incomplete effort for managing complex capital projects. Wouldn’t anyone driving capital project delivery be better off using the technology and advanced design practices that have been proven to work in other complex industries as well as in capital projects?
Agile Development is not based on any hard scientific foundation. The co-creators of Scrum, Ken Schwaber and Jeff Sutherland describe Scrum science as follows: “Scrum implements the scientific method of empiricism.” This is a way of saying the science of Scrum is based on their experience. In large, complex capital projects, people’s experiences might lead to very different conclusions. We have seen many times when this type of empirical reasoning is deeply flawed. For instance, some people think that cycle times (durations) will increase with more work-in-process and some people on the same team think cycle times will decrease with more work-in-process. These conflicting empirical assessments of project behavior lead to the chronic capital project delivery failures the industry produces. Fortunately, Project Production Management provides a solution based on the fundamental, practical science of Operations Science and incorporates the technologies of CDE to provide proven, predictable results in major capital projects.
Toyota’s Chief of Agile, Nigel Thurlow, states the case well, “The truth is that you don’t do Agile (just like you don’t do Lean); you become Agile by following a number of practices and techniques.” [22]
Executives contemplating Agile methodologies for projects should not position an Agile program as an overarching solution to capital project delivery problems. There are too many gaps in the Agile approach as applied to project delivery due to major differences between software projects and capital projects. The underlying scientific foundation of Agile has intrinsic knowledge gaps due to its empirical basis, which makes Agile ripe for the worst abuses of buzzword initiatives.
Agile methodologies can be used to restructure bureaucratic and wasteful meetings and approval processes, but Agile is not a replacement for the practices and techniques required to successfully deliver capital projects
Traditional project delivery practices and techniques are also ineffective, as evidenced by chronic project delivery failures. Executives should implement operations science-based project delivery approaches to establish effective project delivery.
As evidenced on hundreds of major capital projects, executives who do not incorporate Operations Science and a “project as production system” view will not be able to establish repeatable success in project delivery.
Companies that own or manage projects should adopt the science and technology of Project Production Management since it has been demonstrated as a comprehensive, scientific and successful approach to delivering capital projects. To learn more about the science and technology available for successful capital project delivery, contact Ed Pound at the Project Production Institute at epound@projectproduction.org.
| [1] | Aghina et al., “The five trademarks of agile organizations,” 22 January 2018. [Online]. Available: https://www.mckinsey.com/business-functions/organization/our-insights/the-five-trademarks-of-agile-organizations. [Accessed July 2020]. |
| [2] | S. Denning, “Forbes,” 2 January 2018. [Online]. Available: https://www.forbes.com/sites/stevedenning/2018/01/02/why-agile-is-eating-the-world%E2%80%8B%E2%80%8B/#7c54e9264a5b. [Accessed July 2020]. |
| [3] | D. Miller and J. Hartwick, “Spotting Management Fads,” October 2002. [Online]. Available: https://hbr.org/2002/10/spotting-management-fads. [Accessed July 2020]. |
| [4] | G. Booch, “IEEE Xplore,” 27 September 2018. [Online]. Available: https://ieeexplore.ieee.org/document/8474489. [Accessed October 2020]. |
| [5] | Wikipedia, “Software Engineering,” [Online]. Available: https://en.wikipedia.org/wiki/Software_engineering. [Accessed October 2020]. |
| [6] | ibid. [Online]. |
| [7] | e. a. Beck, “Manifesto for Agile Software Development,” 2001. [Online]. Available: https://agilemanifesto.org/. [Accessed July 2020]. |
| [8] | Scaled Agile, “CASE STUDY: Cisco,” [Online]. Available: https://www.scaledagileframework.com/cisco-case-study/. [Accessed October 2020]. |
| [9] | B. Stone, A. Satariano and G. Ackerman, “The Most Important Apple Executive You’ve Never Heard Of,” 18 February 2016. [Online]. Available: https://www.bloomberg.com/features/2016-johny-srouji-apple-chief-chipmaker/. [Accessed October 2020]. |
| [10] | Boeing, “737 MAX Updates,” [Online]. Available: https://www.boeing.com/737-max-updates/. [Accessed July 2020]. |
| [11] | C. Isidore, “CNN Business,” 21 January 2020. [Online]. Available: https://www.cnn.com/2020/01/21/business/boeing-737-max-production-halt/index.html. [Accessed July 2020]. |
| [12] | H. Taneja, “The Era of “Move Fast and Break Things” Is Over,” 22 January 2019. [Online]. Available: https://hbr.org/2019/01/the-era-of-move-fast-and-break-things-is-over. [Accessed October 2020]. |
| [13] | T. Ahram, B. Amaba and W. Karwowski, “A System‐of‐Systems Engineering Approach to Leadership and Innova‐tion: Sustainable STEM Education and Workforce Development through the Smart Cities Initiative,” in Proceedings of the World Congress on Engineering Education 2013, Doha, Qatar, 2013. |
| [14] | Scrum.org, “WHAT IS SCRUM?,” [Online]. Available: https://www.scrum.org/resources/what-is-scrum. [Accessed July 2020]. |
| [15] | Standish Group, 2015. [Online]. Available: https://standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf. [Accessed July 2020]. |
| [16] | K. Kaczor, “Scrum Myths: Sprint Backlog fully built and assigned in Sprint Planning,” 13 February 2017. [Online]. Available: https://www.scrum.org/resources/blog/scrum-myths-sprint-backlog-fully-built-and-assigned-sprint-planning. [Accessed July 2020]. |
| [17] | V. Kumar, “HPCL board gives nod for Visakh Refinery expansion,” August 24 2016. [Online]. Available: http://www.vizagrealestate.com/hpcl-board-gives-nod-visakh-refinery-expansion/. [Accessed July 2020]. |
| [18] | B. Lalita, “Introduction to HPCL Visakh Refinery,” [Online]. Available: https://image1.slideserve.com/2955472/slide3-l.jpg. [Accessed July 2020]. |
| [19] | B. Lalita. [Online]. Available: https://image1.slideserve.com/2955472/slide15-l.jpg. [Accessed July 2020]. |
| [20] | R. Shenoy, “PPI Position Paper: Understanding the True Cost and Impact of Inventory,” 2019. [Online]. Available: https://projectproduction.org/journal/. [Accessed July 2020]. |
| [21] | B. Amaba, J. Craig and others, “Concurrent Digital Engineering for Capital Projects,” 2019. [Online]. Available: https://projectproduction.org/journal/concurrent-digital-engineering-for-capital-projects/. [Accessed July 2020]. |
| [22] | N. Thurlow , Interviewee, Bringing agility to Toyota. [Interview]. 22 August 2018. |
