This is the third and final video of a series that explains and compares the Work Breakdown Structure (WBS) and Scrum’s product backlog. In this video, Frank Velazquez compares and contrasts the two artifacts and how they support very different approaches to project scope management between traditional project management, or Waterfall, and Agile. This understanding is crucial for viewers implementing Agile in organizations steeped in traditional project management.
Most fixed-price contracts are inherently anti-Agile. It is not because they set a budget ceiling for a project. I and many others argue that budget and schedule constraints actually enable Agile project planning. The issues associated with fixed-price Agile software development contracts lie in how project management determines and enforces scope, budget, and schedule constraints.
Predictive vs. Adaptive Planning
Most fixed-price contracts ignore a fundamental disconnect between traditional project management and Agile practice. Traditional project management planning is predictivewhile Agile planning is adaptive. Fixed-price contracts require planners to define the three constraints of the Iron Triangle – scope, cost/budget, and schedule – upfront.
Figure 1: The Iron Triangle
In traditional software projects, project management closely tracks task progress towards scheduled milestones and the associated budget burn rate. There is little room to change project plans when things go awry. Also, projects lose the flexibility to change plans based on lessons learned and discovery of new requirements during development.
In contrast, Agile planning “breaks” the Iron Triangle by allowing scope to “float” within budget and schedule constraints. This means that given a fixed budget and timeframe, project sponsors, stakeholders, and software development teams collaborate to determine what to build during development. We control Agile software development projects primarily by managing scope.
We determine what viable and valuable capabilities to develop, deploy, and release within budget and time constraints. As long as project sponsors and stakeholders work with development teams to continually refine and prioritize requirements, teams will deliver the most important product / system / solution features at appropriate levels of quality and complexity. In Agile projects, sponsors have the flexibility to:
Continue developing the current implementation as planned
Pivot to a different implementation approach
Stop when enough useful functionality is developed and fielded
Cancel development altogether if necessary
Control vs. Flexibility
Fixed-price contracts are one way traditional project managers attempt to mitigate project risk. Government agencies prefer fixed-priced contracts because they shift project risk onto vendors. Vendors bid based on solution requirements stated in requests for proposals (RFPs). It is up to the vendors to ensure their proposals accurately reflect the cost of satisfying requirements, within the specified timeframe, and at a competitive price that allows them to make money.
Since no one can predict the future, vendors often do the following:
Challenge any interpretation of requirements that may increase project scope (scope creep)
Vendors are disincentivized to accept changes in requirements that may perturb the plan and cost them margin.
Meanwhile, project sponsors worry they will not get what they paid for in terms of functionality and quality. Those worries often translate into burdensome tracking and reporting requirements.
Agile provides opportunities to inspect and adapt solutions and their development. This transparency is Agile’s safeguard against scope creep and project and solution underperformance.
Unfortunately, traditional project managers often forgo opportunities to define and validate solutions during development. Instead, they favor traditional project management tracking and reporting. They focus on tracking tasks completed rather than validating value delivered. Even the misnamed concept of “Earned Value Management” (EVM) assumes a deliverable’s value during development equals the budgeted cost of the effort expended on it, regardless of its ability to provide business or mission value.
The Agile Alternative
Instead of attempting to manage all three Iron Triangle constraints as variables, keep cost and timeframes fixed while managing scope. Rather than tracking task completion, deliver working functionality early and often to validate that development teams built the right things in the right way. This places responsibility for defining the solution or “product’ squarely on project sponsors, with help from stakeholders and development teams. Traditional project managers often struggle with this approach because it is a product management approach rather than a project management approach.
Conclusion
Fixed-price contracts do not have to run counter to Agile practices. They can be written to allow project sponsors and stakeholders to define what business or mission capabilities they need, within fixed cost and schedule constraints.
Doing so encourages developing solutions by starting small and building on successes. After all, it is much easier to cancel a $10 million project after six months than a $100 million dollar project after two years. This Agile approach to fixed-price contracts ensures that something of value comes from the investment while opening the door to future investments based on business or mission success.
System integration software projects require formal risk management. Here’s how to do it agilely.
Table of Contents
If you work in system integration projects, you have likely wondered how to manage project risks within your organization’s chosen Agile approach. This is a topic seldom discussed in certification courses for Agile-based approaches such as Scrum. The two major reasons for this are:
Most of these courses focus exclusively on team-level Agile. In other words, how does a small team of individual contributors work together under the Agile approach? Individual small teams tend to work on smaller efforts that require much less coordination. In most of these situations, formalized risk management is overkill.
Managing risk is baked into Agile because Agile is an inherently empirical way of working. Since Agile development is iterative and incremental, teams narrow the scope of what they build to fit within short time frames. This enables them to, quickly and frequently, build, test, fix, deploy, evaluate and change what they build, and how. Every iteration of value delivery brings multiple opportunities to address risk “in real time.” In other words, Agile spreads risk management across the entire development effort.
However, system integration projects are typically large and complex, with multiple teams working across organizations while managing multiple dependencies. The larger the project, the more risk project sponsors and stakeholders assume. A formalized approach to risk management becomes a priority.
So, what does a formalized Agile risk management approach look like? It looks a lot like a traditional risk management approach with three main differences:
Agile risk management is more adaptive than predictive
Agile projects perform risk management activities more frequently and faster than traditional projects
Risk management activities in Agile projects are much more coupled to project execution than in traditional projects
Before describing a formalized Agile risk management approach, let’s level set understanding about project risk management. Along with the short background provided here, I highly recommend reading this article from pmi.org about risk analysis and management.
Risks, Opportunities, and Issues
The third edition of the Project Management Body of Knowledge (PMBOK Guide) defines risk as:
An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.
Project Management Body of Knowledge (PMBOK Guide), Third Edition
By that definition, risks are not just harbingers of negative outcomes. They may also be opportunitiesto affect positive outcomes. Once a negative risk becomes reality, it becomes an issue.
Risk Categories
Categorizing project risks is helpful. Doing so facilitates risk tracking across the entire project scope. It also communicates that risk management is everyone’s job, not just that of project management. Table 1 lists a typical set of project risk categories and their associated extended categories[1]:
Table 1: Typical Project Risk Categories
Risks belonging to the external, organizational, and project management categories are typically:
Closely aligned to high-level project concerns outside the control of development teams
Less dynamic and fluid than technical risks
Almost exclusively in the realm of project and program management and/or product management
Much of Agile literature and training narrowly focus on technical risks. This aligns with their focus on Agile execution by small teams. However, external, organizational, and project management risks often impact projects far more.
The Risk Management Cycle
Figure 1: The Risk Management Cycle
Both traditional and Agile projects execute the activities of the Risk Management Cycle depicted in Figure 1. Table 2 lists and describes each activity of the cycle[2]:
Traditional project management tries to account for all project tasks and milestones upfront. Agile planning breaks up the planning horizon into increments. These increments facilitate changing plans when circumstances change. To be effective, a project’s risk management approach must align to the chosen project management approach.
While all projects, whether they adopt a predictive or adaptive planning approach, perform every activity of the Risk Management Cycle, they emphasize different activities.
A predictive risk management approach emphasizes risk forecasting (prediction) and analysis. Risk analysis entails determining the probability of occurrence and expected project impact of individual risks. The rationale is that the earlier project managers identify and prioritize project risks, the sooner they can address them before they become issues.
An adaptive risk management approach emphasizes keeping risks small by defining, developing, and delivering system functionality iteratively and incrementally. This allows teams to handle risks while their potential for project impact is small and to continually monitor risks as solutions evolve and grow.
Traditional vs. Agile Risk Management Characteristics
I’ll now discuss the key differences between how traditional and Agile projects manage risk.
Traditional Risk Identification and Evaluation
Traditional projects develop and execute detailed plans that span the entire project timeline. Project management often breaks up larger projects into planning packages as part of “rolling wave planning”, but each of those planning packages are themselves detailed plans. Project plans are based on the resources needed to complete the entire scope of deliverables at a certain cost (The Iron Triangle).
Project plans start with requirements definition. The entire set of approved requirements defines project scope. Changes to requirements mean changes to project scope, which translate into schedule and cost changes.
Similarly, traditional risk management tries to identify and evaluate project risks and opportunities prior to or at the start of projects. While risk management is supposed to happen throughout a project’s timeline, traditional projects tend to perform the bulk of Risk Identification and Evaluation upfront.
The problem with this arrangement is that people cannot predict the future. The larger and more complex the project, the more likely project requirements and risks will change.
Traditional project management develops and executes plans assuming requirements, and the design approaches that implement them, are inherently correct and will not change. This opens projects to the greatest risk of all: building the wrong thing.
Risk Identification and Evaluation activities in traditional projects often cannot keep up with the accelerated pace of modern software development. In many organizations, risk management is relegated to weekly or monthly risk management boards. By the time a board adjudicates a risk it may already be an issue.
Agile Risk Identification and Evaluation
While some degree of upfront Risk identification and Evaluation happens in Agile projects, the planning horizon is typically far shorter than that of traditional projects. Also, most Risk Identification and Evaluation of technical risks happen as part of development, rather than resulting from a separate risk management process.
Traditional Risk Handling and Controlling
Traditional (Waterfall) projects typically get one pass through the Software Development Lifecycle (SCLC). That pass is strictly constrained by schedule, resources, and cost. As a result, there is often little room to add risk management activities to the schedule.
Project managers and developers are incentivized to deliver according to plan. This puts pressure on them to ignore risks until they become issues. They also forgo opportunities in favor of “flying the plan.”
Agile Risk Handling and Controlling
The Agile SDLC is fast moving and iterative. Every feature software development teams deliver goes through its own “mini-SDLC”. Agile planning coupled with DevOps automation support this:
Agile provides frequent opportunities to evaluate what development teams build and how
Adaptive planning allows sponsors, stakeholders, and development teams to change requirements, plans, and approaches
Teams add risks to their work backlogs and prioritize them, thus integrating Risk Handling actions into team workflows
Shorter development timeframes with frequent deliveries / releases provide: 1) More frequent and earlier warning of emerging risks; 2) More feedback from which to gauge the effectiveness of risk management efforts
Recommended Approach
The Agile SDLC improves management of technical risks. However, as stated earlier, external, organizational, and project management risks often impact projects far more than technical risks. Agile teams have the flexibility to manage technical scope. They have far less control over funding and major project milestones.
External, organizational, and project management risks influence the overall business or mission context within which teams develop solutions. Project leadership must actively manage these risks before they impact the work of development teams.
Agile projects should leverage traditional risk management tools and techniques to manage more strategic, slower-moving risks. Project leaders would then work with development teams to translate such risks into actionable work items and prioritize them. All project members should have access to risk management reporting and the ability to submit risk candidates as part of their work.
Conclusion
Too often, risk management gets short shrift, especially in Agile projects. Risk management is an integral part of project planning, regardless of the software development approach employed. Combining Agile requirements definition and planning, with DevOps automation, and a robust risk management process helps teams deliver valuable software capabilities, cost-effectively, and in time to be valuable.
[1,2] Lavanya, N., Malarvizhi, T., “Risk Analysis and Management,” Project Management Institute, 3 March 2008, https://www.pmi.org/learning/library/risk-analysis-project-management-7070
