Abstract
Industry news is buzzing about how agility is required to succeed in today’s economy. Industries including automotive, consumer goods, retail, even construction have realized that just-in-time inventory and build-to-order are management approaches that can assist market position and market value. Yet, these industries still use a more traditional approach to manage crucial and time-sensitive projects. This paper explores how project managers, program managers, and the project management office (PMO) can introduce nimbleness and speed into current project management processes and provides an approach to determining if agile project management should be applied to a project along with some techniques to overcome the organizational resistance that can be anticipated.
Introduction
Despite the industry buzz about the need for agility in today’s economy, many industries continue to use a more traditional approach to manage the very projects that enable agility in their core businesses. Organizations have invested in the development and adoption of project management techniques, including PERT and earned value management, since the days of World War II. In the economies of that “big business” era, an emphasis was placed on quality and doing it right. This translated into processes that were hierarchical and rigid in nature, with an emphasis on serial phases and “permission” gates between phases.
As a global economy started to evolve, new management techniques, such as concurrent engineering, entered the marketplace. Today doing it right is no longer good enough. Corporations must now also get it done rapidly. Consumers’ desire for speed has transformed business behaviors. If a corporation cannot quickly respond to a market need, that need will be fulfilled elsewhere, perhaps outside the local economy. Project and program managers leading critical initiatives need to understand and appreciate these business pressures and be ready to adapt their processes accordingly, to be more agile.
Society underwent a paradigm shift in the latter part of the 20th century with the emergence and acceptance of the Internet and its associated technologies. Consequently, we are approaching the state of a single global society and economy or, as Thomas Friedman (2005) called it “a flattened world”. This shift impacts the way businesses approach the management of projects. Organizations and project managers need to be ready to respond with tools and techniques such as agile project management.
Much is being written these days about the need for agility in business, especially in information technology and in projects related to developing corporate differentiators. Yet, it’s questionable whether there is a true appreciation for what is meant by the term “agility.” To the dismay of some managers, agility does not mean unmanaged or undocumented. Rather, agility means the ability to quickly adjust and respond to changing business needs.
Definition of Agility
The word agility is derived from the Latin, agere, means “to drive, act,” implying a sense of ownership, and the ability to drive something forward. Other definitions mention “ready ability to move with quick easy grace.” So it is also associated with the quick and easy changes of direction and form called for by today’s business environment. Additionally, the definition refers to “having a quick resourceful and adaptable character.”
So, agility has three characteristics important to project management in this new business world:
- Sense of ownership and authority,
- Quick and easy changes of direction, and
- Resourceful and adaptable.
Agile Project Management
Now, let’s take those attributes defined previously as “agility” and apply them to the practice of project management as we know it. For purposes of clarity, I will use the term “traditional project management” (TPM) to define the project management techniques predominant today, that is, the method focused on centralized decision making and control within a hierarchical organizational structure. TPM has been proven successful in projects whose solutions can be relatively defined, scoped, and estimated (both time and cost), such as most construction projects.
However, today’s business projects likely have high degrees of unknowns and uncertainties associated with them, especially when viewed in the global economy. Many project managers would suggest today that it is nearly impossible to document all requirements, even at a high level, at the beginning of any project, given the speed of economic dynamics. Only after product development commences does the customer begin to realize that what they needed is not exactly what they requested. The cost to business and consumers for this behavior is immense when projects are not completed satisfactorily, with missed schedules and cost overruns. An approach that deals with the reality of continuous change or which incorporates discovery and learning throughout the project life cycle must be utilized instead. That approach is agile project management.
Agile Project Management versus Agile Product Development
Introducing agility into your projects does not mean replacing your current processes. Agile project management is a new and better way to handle the old problem of “I will know it when I see it” associated with defining project deliverables. You tailor the traditional approach to project management with an approach that meets the agile needs of the project. Agile project management, by its nature, supports direct customer inclusion, adjustments, and even redirection utilizing a type of iterative approach that deals with the level of uncertainty encountered. Through the application of the concepts of quick iterations through a project’s activities, developing usable product along the way, to the project team can address uncertainties in scope, business, and the economy. Agile project management, based on the six principles shown in the Exhibit 1, still relies on the same A Guide to the Project Management Body of Knowledge (PMBOK® Guide – Third Edition) processes and disciplines, just implemented with different practices and tools that supplement the TPM approaches the organization already uses.
Exhibit 1: Six Principles for Agile Project Management
Agile Product Development
Agile project management focuses on the overall management of the project. Agile product development, on the other hand, focuses on engineering activities associated with the project’s product, be it a software product or a new pharmaceutical or automotive product. Agility is equally important in these activities, since without a sense of fast movement when developing the product, the project would be bogged down. Some of the methods used include extreme programming, test-driven development, and just-in-time manufacturing, to name a few. The project manager and the project teams must realize that these product development approaches supplement agile project management approaches. The project management approach and the product development approach should be integrated when the team develops their overall project life cycle model.
Agile Project Management for All Projects?
Many organizations are experimenting with or implementing agile development approaches within software development projects, to expedite and increase IT’s throughput. While this is encouraging, and might help IT with resource allocations, it is not sufficient to address business needs. Many of today’s projects extend beyond the boundaries of software development. If the entire project is not accomplished with agility and nimbleness, the benefits gained in software development efforts might be lost.
Overall performance measurement is something else to consider when contemplating agile project management for the organization. If performance measurements indicate that improved market position or improved resource utilization could be gained through agile project management, then adopting agile practices becomes a strategic decision across the enterprise.
Adoption Challenges
We have become accustomed to using formal predictive approaches to force uncertainty resolution in a project and to prevent changes in the project’s scope. With agile project management, change and uncertainty become the norm. The project team needs the ability to adapt to ensure project success.
A survey conducted by the Agile Project Leadership Network (Barnett, 2007) asked about the challenges organizations faced when implementing agile software development techniques. The greatest concerns expressed related to implementing agile techniques centered around “soft” issues—issues related to people and the organization, not to the methodology or the tools. These observations are equally pertinent to organizations adopting agile project management.
Those that have become comfortable and accustomed to pre-planned linear approaches to projects tend to resist doing non-linear, or adaptive, work. Often this resistance is demonstrated through actions like scapegoating, projection of negative claims on a process, or “killing off” the leader in the hopes that if only we had the right leader our problems would be solved.
In reality, as project managers, we are not frequently in positions of real authority to drive organizational change. We are, nonetheless, in a strategically challenging and personally risky position relative to communicating new approaches—approaches that will require a change in thinking, attitude and perceptions—to project team members and sponsors.
The following are some suggestions as to how project managers and PMO staff can help with the adoption of these new approaches.
PMO as Process Cheerleader
PMOs generally take a leadership role in helping organizations determine when new and better techniques in the application of project management should be adopted or adapted into practice. Decisions about when and how agile project management techniques are incorporated into the organization’s project management “bag of tricks” are in the PMO’s bailiwick. There are situations where traditional project management techniques are best suited for delivery and situations where agile techniques are warranted. The PMO should guide project managers and sponsors as they determine when to use a certain methodology for delivery, establishing boundaries and a structure for all projects, no matter what the delivery process. The PMO should work with project managers and project teams to determine how to best adapt existing processes to be more agile, more nimble, and in the education and communication of these adaptations to the rest of the organization. Additionally the PMO should serve as the leader in measuring the impact agile techniques have on the business’s overall performance.
Project management processes that we see most often impacted by agile techniques are those associated with project initiation and planning and project controls. It is here that we recommend the PMO spend time providing tools and assistance.
Project Request
Estimation for Budget Purpose. One method used on agile projects is to “box in” exploration activities and estimate non-exploratory activities as you normally would. Establish a finite budget and schedule for exploratory activities, based on past experiences and knowledge. Inform all engaged in the funding decision that there is a high degree of risk in the budget number associated with the project, because exploration is required before you can estimate the remaining aspects of the project. When the original budget is consumed, you will determine overall progress, and engage the team and project sponsor in determining how to proceed. If more exploration is warranted, seek additional funding, and/or adjust the estimates associated with the rest of the project, based on the knowledge gained through the exploration.
If it is not possible to obtain additional funds or delivery date relief, use the knowledge from the exploration to adjust the scope of the final product, again, in collaboration with the project sponsor and using a trade-off matrix similar to that shown in the project data sheet depicted in Exhibit 2 to guide the decisions. This approach is similar to the spiral model of software engineering in that there is acknowledgement of uncertainty in the early iterations of the project.
Exhibit 2: Project data sheet including trade-off matrix
This “time box” method can be effective in organizations where budgeting and resource allocation are performed as part of an overall annual portfolio management process. If you are in an organization not constrained by annual planning and budgets are a bit more fluid, then you might consider “rolling wave planning,” where the estimates are provided only for the next iteration through the project. At the end of each cycle, there is a determination, made in collaboration with the project team and project sponsor, if the next cycle is viable, and to request funding and resources and develop the detailed schedule and budget at that time.
Both of these approaches are not for the timid or inexperienced project team. The team needs to be able to draw on past experience to speak with confidence about what is needed to adequately explore a new technology, or a new product approach. They then need to be able to visualize how the end product(s) could be delivered in smaller pieces, with each piece building on a prior one.
Identifying Project End Date. Determining the project end date in projects managed with agile techniques is really no different than the methods used in determining end dates in projects managed traditionally. However, in agile projects, there is a clear understanding at the beginning that the project plan, including the schedule, will indeed change, as iterations are completed. The project plan at the beginning is only a plan—not a finite prescription of how the project will unfold.
One key concept that project sponsors need to hear is that project plan changes do not mean the planned final project end date will necessarily change. For one project, the end date may be more important than the final group of features; or it may be determined that the budget will be exceeded but achieve all features by adding resources. A discussion on these constraints is held during project initiation, when determining if agile project management is the right set of techniques to use on the project. They should then be re-affirmed during the project charter development, and then at the chartering of each of the iterations, acknowledging the constraints might change during the project’s life cycle.
Estimating time in an agile project is based on two concepts that are explored by Mike Cohn (2006): “velocity” and “ideal time” vs. “elapsed time.” Velocity is the rate at which a project team completes development of some number of product features. Ideal time is defined as the time it takes to accomplish a task when all peripheral tasks are stripped away—that is, when all “waste” is removed from the essential task. Elapsed time, on the other hand, is the clock time it actually takes to accomplish a task. When estimating the schedule for an agile project, the project team should be encouraged to think in terms of ideal time, since all non-essential tasks will be factored into the project team’s velocity. In other words, estimate the effort, not the duration. This is an aspect of schedule estimating that will be foreign to some team members and is worth some concentrated training and awareness.
In an agile project, the project manager and team are continuously planning the next set of activities, the next iteration of the project. There should be a high degree of certainty in the schedule for this next iteration, with decreasing certainty in future iterations. This concept of deliberate schedule uncertainty is one of the largest challenges a project manager will face when adopting agile project management in an organization where the culture is more comfortable with, and policies and processes are aligned with, traditional project management.
Stakeholder Management
Education Regarding Agile Techniques.
During the project’s initiation phase, the project manager (and PMO) needs to educate the project’s stakeholders on what it means to be managing a project with agile project management techniques. All stakeholders, not just the primary project team, need to be educated as to what agile project management is and is not and what is expected of their respective roles. There is a new vocabulary (sprints, velocity, stand-ups, etc.), a difference in how status is reported (daily status meetings), and multiple releases of functioning products (software or physical).
- Sponsor: Status will be made available to them at a certain location (portal) and in different formats than before. The traditional weekly status report is not effective or efficient with agile projects.
- Project Team: Agile product development is known for quick periods of development, unburdened by all but the most necessary documentation. This calls for a disciplined process with strict time-boxing and mandatory, daily meetings.
- Users: Bits of functioning product will be available to validate and use while further product advancement continues, instead of one big acceptance period at the end.
Agile project management emphasizes quick iterations through a project. So, there needs to be the realization that while high-level feature requirements with a rough order of magnitude for major deliverables may be able to be defined, by no means will all of the project requirements be visible and able to be defined at project initiation. Therefore, in preparation for the volatility that will come, the focus of initiation in an agile project is less on the “what” than it is on the organizational aspects which will be directing and supporting the project.
Obtaining Buy-in and Participation.
Before embarking on the application of agile project management methods, the project manager overseeing such an effort should understand the risk profile of the organization. Organizations that will readily embrace agility welcome change as a means of opportunity; they are not threatened by change. Organizations that tend to be risk-averse, that have a high need for centralized control and decision making, and where management traditionally determines progress based on completion of documents and deliverables, will be harder environments in which to introduce agile practices, because the concepts of agile project management do not align with the principles of the business. A risk-averse organization will place a preponderance of importance on time and status reporting, an attribute of a false sense of control. There will be well-defined processes associated with procurement activities and acquisitions will require multiple levels of signature.
In such an environment, the project manager should clearly communicate the benefits of agility in terms the company will accept and openly address any risks that might be seen. The project manager should plan on an extended period of communications, awareness, and education, highlighting how agile project management techniques supplement traditional project management techniques. The project team will need to have a plan that embraces the supporting business functions, that brings these functions into the “agile team” so that they understand (1) how they can contribute to agility and (2) why agility is not a threat to the controls they have in place to protect the organization.
After the stakeholders have had some education in agile project management and understand why it is being applied, the project manager must clearly engage the stakeholders in a cost/benefit analysis to ensure they fully understand why agile project management is of benefit to the project. By taking the time to do this analysis, the project manager will start the process of obtaining the necessary buy-in and active stakeholder participation.
More Change in How We Manage Projects
One Methodology—Different Adaptations.
Avoid the tendency to develop a new methodology whenever a new approach to a business discipline arises. Instead, practice tailoring the existing project management methodology. Agile project management can be accomplished with a few adaptations of existing processes, such as daily stand-up status meetings supplemented with a monthly formal report, in lieu of formal weekly reports. Another adaptation is the use of some visual planning tools to permit the project team real-time access to update documents such as risk registers. The PMO should take a lead in determining where these adaptations are viable and in exploring how to best implement them.
Determining When to Use Agile Method.
Agile project management is not suitable for all projects. Agile project management reflects “just enough” project management discipline to ensure the project will achieve its stated goals with minimal risks. Projects that are being executed in dynamic environments (rapidly changing marketplace, fuzzy concept of product features, unstable internal organization) are perhaps better suited for agile project management because the benefits associated with nimbleness would out-weigh the associated project risks.
The decision to apply agile project management methods is not one that the project manager or project sponsor should make in a vacuum. It is a collaborative decision, for which all must assume responsibility for the outcome. The associated benefits and risks need to be clearly understood by all project stakeholders, and organizational management needs to be supportive of the decision. We have developed the agile project management questionnaire (Exhibit 3) as a tool to assist in this discussion, encouraging dialogue regarding the project’s constraints, risk factors, and need for speed.
Exhibit 3: Agile project management questionnaire
Ready to be Agile?
Today’s global business environment requires businesses to be agile. Ultimately, the decision to embrace agile project management will be made by our competitors if we do not make it ourselves. Let us ensure we are prepared by having the ability to envision how project deliverables might be developed in usable components, in increments over short periods of time. We need to be able to plan and execute projects with flexibility and decisiveness and react quickly. We need to be able to conduct periodic checkpoints and be prepared to not continue a project (perhaps because the market is not responding to the initial product), knowing the organization has the benefit of some completed product – not just a stack of documentation. More than ever, our businesses demand we be nimble, adaptive, creative and yet in control of the projects entrusted to us. Are we ready? Are our teams ready?