This paper will briefly discuss agile approaches to project management concepts as developed in the software industry, with a generic, non-IT focus. The application of these tools and methods to non-IT projects, and how these fit into “traditional” project and program management methods will be discussed.
The main portion of the paper will be two case studies where these principles were applied: a construction project and a performance improvement program implementation based on Six Sigma. Finally, a discussion on the value of training outside of a specific job focus will close out the paper.
The key takeaway and conclusion of this paper is that agile tools, methodologies, and thought processes can add significant value to non-IT projects if applied correctly.
Introduction to General Agile Project Management Tools and Methodologies
Software projects have traditionally been done by the waterfall method, which is a sequential method similar to what is used in construction or any other project. A software project would go through initiation, planning, coding, and testing, and then be delivered to the end user. As Information Technology (IT) projects grew larger and more complex, and some of the requirements became more ambiguous, significant project issues occurred, including cost overruns, delays, and project failures. Also, there was a feeling among programmers and others that traditional project management methods were cumbersome and outdated for software projects.
A new philosophy was proposed. In February 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development (Beck et al., 2001).
According to Beck et al. (2001), the Agile Manifesto is based on 12 principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Exhibit 1 shows the iterative nature of agile, with sprints, and the burn-down of features/tasks that are required to be completed. Sprints continue until the project is completed.
Agile is iterative and incremental in nature. Most agile development methods break tasks into small increments (typically two to six weeks). Each iteration involves an integrated team working in all functions: planning, requirements analysis, design, coding, testing, and release. The team “burns down” the overall number of tasks/features by completing a sprint. At the end of the iteration, a working product is sometimes demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. It also enables a user to provide timely feedback to the team and add or modify features. Agile has been mischaracterized and/or misused as a Wild West approach with no real planning, schedule, or documentation. Executed correctly, just the right amount of planning, documentation, and so on is utilized for an agile project. This effort can be part of an overall program or project that follows the Project Management Institute's methodology.
This agile approach is especially useful for ongoing product development. For example, a scheduling software program that has periodic releases can add features and functionality each sprint, with a usable product at the end of each sprint. When timing, features, and marketing are aligned properly, the software can be released.
This is a very simplified description of agile practices, and many books, training programs, and standards provide detailed descriptions of the various methodologies and their implementation principles. There are also related topics and methods.
Application of Agile Project Management Tools and Methodologies
Construction Management Application
Traditional projects are performed in a single continuous flow, with sequential steps that include project initiation, project planning, project execution, and project closeout. Typical construction projects have an initiation/planning phase, a design phase, a construction phase, a testing phase, and a turnover to the user phase, followed by project closeout. There are more elaborate models with multiple phase gates and bid phases, but the main point in common is the sequential nature, with user input happening primarily in the planning and or design phase. During the construction phase, another sequential work plan is put together, typically in a project schedule, built up by trade or geographic areas (e.g., floors, buildings, etc.). The typical large construction project has multiple contractors working for a general contractor, with a separate designer and a separate owner, and in some cases separate end users (tenants), with complex contracting methodologies in place.
In a perfect world, the construction scheduling, planning, and execution processes would be detailed and robust enough to avoid project issues and delays. However, a significant number of projects, especially large and complex ones, have delays and cost increases. Aside from material costs, the most significant cost element in construction project is labor. Project labor costs increase from the baseline plan when delays occur. It may seem obvious, but to avoid delays the project needs the right people, at the right location, with the right material and tools, and with the right work instructions.
Delays and overruns can result from not having the right material on hand at the right time, which may occur due to supplier backlogs, shipping delays, funding restrictions, and so forth. Delays can occur from not having adequate work instructions on hand at the right time (work packages), which may result from incomplete or inaccurate design and documentation, delays in decision making or instructions, or changing scope. Finally, delays from labor shortages can occur due to an inability to find the right trades, scheduling issues with vendors or contractors, and so on. There are, of course, also weather delays or other external events. In typical projects these delays can result in contractor claims and counterclaims, especially when blame starts to be identified. These legal issues can further delay the project and increase costs. The focus can quickly become more about individual project participants’ bottom line than the overall project's success.
Traditionally, construction projects are thought of as poor candidates for an agile approach, as they are typically very sequential in nature and changes are expensive as projects move further down the life cycle. A change during design might cost $1, but during active construction will cost $100 to implement, so there is a strong incentive to fix the design as solidly as possible and then execute projects. Also, there is a concern that this approach would be unsuitable for highly regulated environments such as nuclear or medical.
There have been many efforts to improve construction productivity, with initiatives such as lean construction and what is called integrated project management (IPM) or integrated project delivery (IPD). There is much to learn from these approaches as well as agile, and they have many core principles in common.
The practitioner should evaluate many types of tools and techniques to optimize the project.
Case Study One—Construction
Centrus Energy Corp. is a trusted supplier of enriched uranium fuel for a growing fleet of international and domestic commercial nuclear power plants. Centrus is working to deploy the American Centrifuge technology for commercial needs and to support U.S. energy and national security. Its headquarters is in Bethesda, Maryland, with significant operations in Piketon, Ohio (Exhibit 2), and Oak Ridge, Tennessee. Centrus supplies low-enriched uranium to commercial utilities to fuel nuclear reactors worldwide. Low-enriched uranium is a key component of the fuel used by nuclear power plants to generate electricity.
Between June 2012 and April 2014, Centrus and the U.S. Department of Energy (DOE) executed a cooperative research, development, and demonstration (RD&D) program to confirm the technical readiness of the American Centrifuge, the next-generation U.S. uranium enrichment technology.
The $US350 million RD&D program supported building, installing, operating, and testing commercial plant support systems and a 120-machine cascade that could be incorporated into a full commercial enrichment plant in Piketon, Ohio, which is planned to operate 96 identical cascades.
Centrus completed the RD&D program within budget and on schedule. DOE certified the completion of all ten program technical milestones and all five performance indicators.
Centrus began operating the commercial demonstration cascade in October 2013, and in December 2013 the cascade achieved 20 machine years of operations at commercial plant specifications. During that performance run, Centrus successfully completed three important milestones demonstrating centrifuge manufacturing quality, centrifuge operational reliability, and sustained production.
The program utilized 169 companies from 28 states to support RD&D construction, manufacturing and operations activities. During construction of the demonstration cascade systems in early 2013, the program added more than 300 workers in Ohio, Tennessee, and other states, raising the total project workforce to more than 1,100 workers.
Agile and the RD&D Project
As in any large, complex project, there were many challenges to overcome. The first challenge in this project included a tight, mandated time frame, with specific milestones from the customer, which had negative consequences if they were missed. The second challenge related to funding, which was limited in terms of availability and usability periods (tranches). Finally, this project was performed in a highly regulated environment, with oversight by the Nuclear Regulatory Commission (NRC) and the Department of Energy (DOE).
The project used an earned value management system and Primavera scheduling software through its Project Management Office (PMO) to control and report on the project formally on a monthly basis.
Traditional contracting methods and construction project management, such as firm fixed price, and purely sequential hand-offs between activities (design to construction, construction to testing, etc.) would not support either the schedule or the funding profiles. The project adopted many agile methodologies to complete construction safely, on time, and under budget, while meeting all milestones successfully.
Centrus acted as the owner and at-risk construction manager, and as the field construction superintendents. The majority of contracting for engineering, design, construction labor, and other labor was done via time and material contracts with work done under Centrus procedures. Informal adoption and use of the agile principles as an execution strategy was critical to the project's success.
Exhibit 3 describes the agile principles, a translation to the construction world, and how it was implemented during the RD&D project.
It should be noted that there was not a formal discussion or formal implementation of an agile approach rolled out to the project. This was felt to be potentially confusing and not value added. The project implemented the principles without labels.
The execution of the project, using these agile tools and methodologies, resulted in a project completed on schedule, and under budget, with no safety issues and no findings or deficiencies from the various oversight or regulatory agencies. The integrated team approach, with an agile mindset, resulted in significantly higher than average productivity for a construction project, and significantly higher than average productivity for a nuclear construction project.
The potential downside with this approach was the risk acceptance by Centrus. All cost and schedule risk was accepted by Centrus for the construction portion of the project. The enthusiastic participation of all participants, including engineers, union tradespeople, construction firms, operations, and the construction leadership team, was required. A common, shared, communicated vision and goals helped keep the project focused.
Case Study: Implementing a Performance Improvement Program
Although Centrus has always supported improvement efforts, there was not a formal performance improvement system in place. In the fall of 2014, the management team introduced a new program (Exhibit 4). It was decided to base the performance improvement program on the American Society for Quality Six Sigma body of knowledge, as this is an internationally recognized organization that has training and certification programs already in place.
The traditional model for implementing a Six Sigma program or other similar performance improvement program is to create the entire program first with outside training and experts, with a typical implementation time ranging from 6 to 12 months and significant cost associated with the rollout.
Centrus elected to implement the program in tranches/sprints, with an agile mindset. The first activity was to develop and implement training. A training program was adapted from industry and an initial class went through the program. At the end of this effort, we had a core group of trained personnel, to the ASQ BoK for Green Belt Certification (REF ASQ). This ties into the agile method, because just having trained personnel in the field adds benefits to the organization and to the employee. The other benefit is that the overall cost was significantly lower than with the traditional method.
We ran two parallel sprints next. One was to have the next class, implementing the lessons learned from the pilot class. The other effort was to start putting in the support infrastructure to enable Six Sigma–related projects at the plant.
The main concept from agile was to deliver usable outputs from each sprint, providing ROI to the organization and the end users. The implementation of the system continues to this day, with more training and other value added activities provided.
Value of Training Outside of a Specific Job Focus
There is a tendency to focus on “core” training for personnel that is solely related to their job function. For example, a project manager might get training on scheduling or risk management. This core training is critical to success, but when you have a person who is experienced and executing his or her job function well, what is the next step? There are three valuable areas to consider: (1) conference attendance/presenting—attending conferences can expose an individual to a wide range of current best practices and methods that can be utilized back in the attendee's company, (2) general training—a project manager may need exposure to the general business body of knowledge, perhaps accounting or IT security, and (3) training in an area that is outside the “core” area and outside of the general knowledge area—such as agile.
This third area of training is how the Centrus personnel were exposed to the concepts of agile. This was outside the core focus areas of portfolio/program/project management, but it provided new tools and concepts that were of significant value in these projects.
The challenge for management is to justify and fund these non-core areas of training.
The paper provided two case studies of the use of agile tools and methodologies in industries and projects other than software or information technology. The very beneficial results and outcomes from the case studies provided proven examples of the success of the application.
It is recommended that some of the principles of agile be evaluated for use in other industries/projects and management make investments in non-core training for their personnel.