Agile PMP: Managing Software Projects in the Face of Uncertainty

Mike Cottmeyer, Agile Consultant, Version One

Abstract
Traditional project management often makes a fundamental assumption about software development that does not always prove true. There is an implicit assumption that the process of creating software is predictable and should be thoroughly planned at the beginning of the project. With proper planning, the project will become predictable. This assumption ignores the extreme volatility many organizations have experienced in attempting to deliver new products to emerging markets. If organizations are going to improve the rate of project success, project management organizations must begin to realize the hidden costs of this assumption and the profound risk introduced when this assumption proves invalid. Agile project management provides a framework for project success when traditional project management processes no longer work. Agile offers a framework for delivering maximum value in uncertain problem domains where high quality and speed to market are your primary business drivers.

Introduction
As uncertainty increases and market timing becomes more critical to meet customer expectations, an organization must have the ability to adapt quickly to stay competitive. For many industries, 18-month product cycles are no longer acceptable. The more likely it is that requirements will change, the more business agility organizations must demonstrate. Responsive organizations must take a different approach to project portfolio management and adopt a more adaptive style of project management. Traditional frameworks that ask stakeholders to lock in requirements early will fail in the face of rapid change. For organizations that deliver projects in fast-paced, highly uncertain markets, it makes less sense to rely on project management techniques that emphasize large-scale predictive up-front planning. The cost of change management is too high for these kinds of projects, and these approaches restrict the ability to be responsive to customers changing demands. The software industry requires an alternative approach to efficiently and effectively recognize uncertainty and embrace change. Agile project management establishes a framework that affords stakeholders the ability to deliver maximum customer value within established time and cost constraints.

Traditional Project Management

Projects are defined in A Guide to the Project Management Body of Knowledge (PMBOK Guide)Fourth edition as a temporary endeavor undertaken to create a unique product, service, or result. (Project Management Institute [PMI], 2008 p.5) Project managers have the responsibility of identifying requirements, making sure the objectives of the organization are well understood, balancing the competing demands for quality, scope, time, and cost; and adapting the project management approach to meet the expectations of the various stakeholders Traditional Project Managers routinely answer the following five questions: 1. 2. 3. 4. When will the project be done? How much will it cost? Does the organization agree what done looks like? What are the risks to delivering on time and on budget? 2009, Mike Cottmeyer Originally published as part of 2009 PMI Global Congress Proceedings- Orlando, Florida 1

5.

How will we mitigate those risks?

Traditional projects are considered successful when they are delivered on time, on budget, and all agreed-upon features meet the customers quality expectations. Managing each of these three variables, often called the triple constraints, is the primary job of the project manager.

Balancing the Triple Constraint

A dynamic relationship exists between time, cost, and scope. Should one of these three variables change on a project, there is necessarily a change in one (or more) of the other two variables. Understanding and managing the relationships among these three variables is the primary responsibility of the project manager. Scope is the starting point for a traditionally managed project. The project manager interviews the project stakeholders and documents the features that must be delivered as part of the project. This is the first step in determining an acceptable outcome for the project. Scope is documented a various levels of detail on software project: the project charter, a project definition document, a market requirements document, and possibly a product requirements document. Project costs are the sum of all capital expenditures, contractor expenses, and the internal costs of labor. Project managers are responsible for tracking project expenses in relationship to the approved project budget. It is important that the actual project expenditures not only fall within budget, but that the planned expenses happen at the right time on the project. Time is tracked by the project manager in the overall project schedule. The schedule defines when all of the project deliverables should be completed and who is going to perform the work. The project schedule defines the sequence of the deliverables and project dependencies, and is helpful for tracking physical percent complete and calculating Earned Value. The Project Schedule is often a primary means of communicating project status.

Agile Project Management

Agile project management begins with the premise that software projects are not predictable. Market uncertainty is going to drive change. The more uncertain we are about our projects, the more the organization must plan to adapt. The implication of market uncertainty is that requirements will need to be changed over the life of the project. Requirements uncertainty makes scope an inadequate starting point to begin assessing the project performance characteristics. Rather than begin the schedule development processes with an assessment of project scope, the project stakeholders assess the time and money that they are willing to invest to bring a product to market. Time and cost are elevated as the primary drivers on agile projects and are often established before the scope is defined. Agile project requirements are written as thin vertical slices of the overall system and constructed in such a way that they are largely independent and can be prioritized and implemented in any order. Writing requirements in this manner is critical to varying scope with minimal impact to the project team. Agile teams begin to measure how fast they are able to complete thin vertical slices of functionality and therefore understand how much of the requirements can be delivered within the project constraints.

Mitigating the Risk of Uncertainty

To mitigate the risk of uncertainty, agile teams deliver working software frequently to the project stakeholders. The stakeholders have the opportunity to inspect outcomes and have the ability to change requirements, change direction, or stop the project at any time based on what they have learned about the emerging product. Agile is based on a foundation of empirical process control. Models of empirical processes are derived by categorizing observed inputs and outputs, and defining controls that cause them to occur within prescribed bounds. Empirical process modeling involves constructing a process model strictly from experimentally obtained input/output data, with no recourse to 2009, Mike Cottmeyer Originally published as part of 2009 PMI Global Congress Proceedings- Orlando, Florida 2

any laws concerning the fundamental nature and properties of the system. No a priori knowledge about the process is necessary (although it can be helpful); a system is treated like a black box (Schwaber, n.d.). Agile organizations deliver working software in small increments, keep the evolving product highly visible, and inspect outcomes frequently. Agile project managers focus on continuous improvement of the emerging product, the emerging product requirements, and the processes that the performing organization is using to deliver software.

Measuring Progress on Agile Projects

Agile project managers are concerned with two primary performance indicators on an agile project: backlog size and velocity. The product backlog is the list of requirements for an agile project. It represents a prioritized collection of features ready to be built by the project team. Backlog items are be estimated in ideal hours, ideal days, or more abstract units such as story points. The sum total of these estimates, regardless of unit, is the total size of the backlog Project velocity measures how much backlog the team was able to deliver in a given iteration. Velocity can be measured on any consistent time interval and represents the throughput of the team or the rate at which the backlog can be completed. Time to completion is calculated by this simple formula:

Intervals to Complete = Backlog Size/Estimate Per Interval

Burndown Chart
Ideal velocity describes the rate at which the team must complete features to deliver the project within the time and cost constraints determined by the project stakeholders. Measured velocity is determined by measuring the actual throughput of the team during each time interval. The difference between the ideal velocity and the measured velocity is a primary indicator of project performance on an agile project. The closer the measured velocity is to the ideal velocity, the more likely the project will deliver the entire backlog within the time allowed.

Exhibit 1: Burndown chart. If the team is performing ahead of the ideal line, the project stakeholders have the option of adding additional scope to the project or finishing the project early. If the team is performing behind the ideal line, the project stakeholders will have the option to remove scope or extend the deadline.

Cumulative Flow Diagram

The cumulative flow diagram communicates similar information as the project burndown but adds additional data elements to the report. The top line bar indicates the total size of the backlog over time. The lower bars show the size of backlog items completed over time. A fixed scope project would have a flat top line, and if the team is 2009, Mike Cottmeyer Originally published as part of 2009 PMI Global Congress Proceedings- Orlando, Florida 3

delivering at their ideal velocity, you would expect the lower bar and upper bars to converge at the end of the project.

Exhibit 2: Cumulative flow diagram. This is often called a burn-up chart. Burn-up charts are useful to communicate scope creep during the life of the agile project. A burndown chart will show a team performing behind idea velocity if the scope increases during the life of the project.

Velocity Trend
Teams with predictable velocity can accurately predict when they will fully deliver the project backlog. If time and cost are fixed constraints, they will know what features can be delivered within those constraints. Teams with unstable velocity are not predictable and result in unpredictable project outcomes.

Exhibit 3: Velocity trend. Measuring team velocity over time allows the project manager to understand how likely it is that project outcomes will occur.

Goals of Agile Project Management

Agile project managers still answer the same five questions: 1. 2. 3. When will the project be done? How much will it cost? Does the organization agree what done looks like? 2009, Mike Cottmeyer Originally published as part of 2009 PMI Global Congress Proceedings- Orlando, Florida

4. 5.

What are the risks to delivering on time and on budget? How will we mitigate those risks?

Agile project managers are considered successful when they have worked with the performing organization to deliver the most scope possible, to the satisfaction of the project sponsors, within the time and cost constraints established by the business. As you might imagine, this approach requires a great deal of trust between the project stakeholder and the performing organization and a much greater degree of ongoing collaboration. Agile project managers focus less on up-front project planning and more on managing the processes through which value is delivered to the organization. Agile project managers focus more on collaboration with the business and servant leadership to the team.

Agile Project Management Value System Self-Organization

Agile project managers recognize that individual decisions made by the project team will lead to either project success or project failure. The team must take responsibility for delivery and be allowed to organize in way to maximize their opportunity to be successful.

Empowerment
Agile project managers create the projects environment. They establish the team and work with them to define the processes and frameworks, the agreements with the organization in which they are operating. While agile project managers are responsible for managing the environment the team works within, they encourage local decision making and autonomy whenever possible.

Trust
Trust is a critical success factor for high-performing teams. The agile project manager expects the best out of people, elevates the individual, and gives them respect. They help foster a team culture that values people and encourages healthy relationships.

Accountability
Agile project management is a commitment-driven framework. The team has a tremendous amount of autonomy to decide how work will get done. The trade-off for this autonomy is frequent delivery. The team must deliver what it says it will deliver on schedule. It is important for the agile project manager to establish a culture of accountability and encourage a do what it takes approach to delivering working software

Making the Transition Now Agile Project Management Plans

Traditional project managers often create a document called a Project Management Plan. This document describes how the project will be managed within the nine Knowledge Areas defined in the PMBOK Guide (PMI, 2008). Much of agile project management can be described within the framework of the traditional project management Knowledge Areas and can be included in a traditional Project Management Planning Document.

Feature-Based Deliverables
A mistake often made by traditional project managers is to track activities in the project plan rather than deliverables. Project managers seeking to leverage agile planning concepts should focus on building project plans 2009, Mike Cottmeyer Originally published as part of 2009 PMI Global Congress Proceedings- Orlando, Florida 5

with feature-based deliverables rather than activities. These project managers can define what capabilities need to be in the system by what time, even if they are using traditional predictive methods.

Iterative Planning
An organization may require the project manager to deliver a fully planned Gantt chart prior to the project start date. Project managers can introduce detailed planning on iterative cycles to synchronize the team and provide a sanity check on the published schedule. Data gathered during the iterative planning meeting can be used to update and control the traditional plan.

Daily Stand-up Meetings

Daily meetings have long been used by both traditional project teams and agile project teams. These daily checkpoints increase visibility between team members and give the project manager real-time information on project deliverables. These meetings can help foster a sense of team work and collaboration and drive shared accountability for project outcomes.

Conclusion
Many of todays projects operate in an environment of profound uncertainty. Agile project management techniques can offer a framework to ensure acceptable project outcomes when traditional project management processes break down. Agile project management can deliver maximum value in uncertain problem domains where high quality and speed to market are your primary business drivers.

References
Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK guide) Third edition. Newtown Square, PA: Author. Schwaber, K. Scrum development process. Retrieved from http://jeffsutherland.com/oopsla/schwapub.pdf

2009, Mike Cottmeyer Originally published as part of 2009 PMI Global Congress Proceedings- Orlando, Florida

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.