The Business of APM

What does a business executive want from a product development and project management process? She wants three key things. First of all, she wants the process to be reliable to produce innovative results project after project. Second, she wants the process to be predictable so she can effectively plan and manage such business activities as financial management, staffing, and product launches. Third, she wants dependable , reality-based information, because visions can be wrong, business models can be wrong, people may hit blocks they can't get past, and progress is not always smooth. If the project needs to be terminated , she wants to do it earlier rather than later. Dependable progress reports enable managers to take appropriate actions early.

Note that the word "repeatable" isn't in the agile lexicon. Implementing repeatable processes has been the goal of many companies, but in rapidly changing environments, repeatability turns out to be the wrong goal; in fact, it turns out to be an extremely counterproductive goal. Which brings us to the critical difference between reliable and repeatable. Repeatable means doing the same thing in the same way to produce the same results. Reliable means meeting targets regardless of the impediments thrown in your wayit means constantly adapting to meet a goal.

Confusion about reliable and repeatable has caused many organizations to pursue repeatable processesvery structured and precisewhen exactly the opposite approachmildly structured and flexibleworks astonishingly better for new product and service development. If your goal is to deliver a product that meets a known and unchanging specification, then try a repeatable process. However, if your goal is to deliver a valuable product to a customer within some targeted boundaries, when change and deadlines are significant factors, then reliable processes work better.

Reliable, Not Repeatable

Failure to differentiate between highly uncertain and highly certain project environments causes much of the confusion about measuring project performance. This confusion stems from two sourcesthe definition of scope and the difference between estimates and constraints.

Repeatable processes reduce variability through measurement and constant process correction. The term originated in manufacturing, where results were well defined and repeatability meant that if a process had consistent inputs, then defined outputs would be produced. Repeatable means that the conversion of inputs to outputs can be replicated with little variation. It implies that no new information can be generated during the process because we have to know all the information in advance in order to predict the output results accurately. Repeatable processes have severe problems with product development projects: precise results are rarely predictable, inputs vary considerably from project to project, and the input-to-output conversions themselves are highly variable.

Reliable processes focus on outputs, not inputs. Using a reliable process, team members figure out ways to consistently achieve a given goal even though the inputs vary dramatically. Because of the input variations, the team may not use the same processes or practices from one project, or even one iteration, to the next . Reliability is results driven. Repeatability is input driven. The irony is that if every project process was somehow made repeatable, the project would be extremely unstable because of input and transformation variations. Even those organizations that purport to have repeatable processes are often successful not because of those processes, but because of the adaptability of the people who are using those processes.

Even at best, a repeatable process can only deliver what was specified in the beginning. A reliable, emergent process can actually deliver a better result than anyone ever conceived of in the beginning. An emergent process can produce what you wish you had thought about at the start if only you had been smart and prescient enough.

Herein lies a definitional issue with project scope. With production-style projects, those amenable to repeatable processes, scope is considered to be the defined requirements (and constraints). But in product development, requirements evolve and change over the life of the project, so "scope" can never be precisely defined in the beginning. Therefore, the correct scope to consider for agile projects isn't defined requirements but the articulated product vision. Project managers may be worried about specific requirements, but executives are concerned about the product as a wholedoes it meet the vision of the customer or product marketing? When management asks the ever-popular question, "Did the project meet its scope, schedule, and cost targets?" the scope part of the answer should be evaluated according to the vision, value, and totality of the features delivered, not on the set of specific features defined at the start of the project.

Another source of confusion arises from viewing cost and schedule as estimates rather than constraints. For a repeatable manufacturing process, the costs and schedule estimates are predictive; the actual results should approximate the estimates. But what happens when the project is volatile and initial estimates are very likely to be wrong? Does this mean executives shouldn't expect predictable results, that they should just accept results as they unfold?

Let's look at an example to answer the question. The project team develops a release plan with the best estimates it can make early in the project. Let's assume that the team estimates the project will take 15 months and cost $4.5 million. Product marketing then counters, as always, "That will never fly, we have to have the product in 9 months, for no more than $3.0 million." Vigorous negotiation, further refinement of feature definitions, and feature reduction establish a "plan" that both engineering and product marketing agree on for 11 months and $3.5 million. Everyone understands that significant changes will occur during the projectfeatures will change, technology will become better understood , and hundreds of other changes will occur. However, the product vision remains, and the 11 months and $3.5 million remain as constraintsa target rather than a prediction.

When things change, decisions need to be made and tradeoffs must occur. The product's vision, schedule, and cost become boundaries to guide these change decisions. As long as the project remains within its constraints, swapping one feature for another doesn't change the project "scope." When the product manager comes up with an exciting group of new features, he has to determine which others can be deferred in order for the project to remain within the constraints. In an agile project, he can no longer scream, "These new features have to get into the product. We're lost without themjust find a way!" He has to be a part of finding the way, which could be going back to the executive sponsor with a change to the project constraints.

Agile project management is both reliable and predictableit can deliver products that meet the customer's evolving needs within the boundary constraints better than any other process for a given level of uncertainty. Why does this happen? Not because some project manager specified detailed tasks and micromanaged them, but because APM establishes an environment in which people want to excel, meet their goals, and do the best they can.

The last paragraph raises another issue, identified in the phrase "for a given level of uncertainty." While APM is reliable, it is not infallible, and it cannot eliminate the vagaries of uncertainty or the surprises encountered while exploring. APM can shift the odds toward success. If executives expect projects to deliver on the product vision, within the constraints of specified time and cost, every time, without failthen they should be running an assembly line, not developing products.

Finally, neither the best project manager nor the best team performance can trump organizational politics. Nor can any methodology make up for outrageous fantasies or dictatorial edicts. These traits make for what Ed Yourdon (1999) calls "death march" projectsprojects that have failed before they begin and go downhill sharply from there. Agile project management can't deliver on fantasies, and its management style is at the opposite end of the spectrum from dictatorial edicts. Agile methods won't help you on death march projects. The only useful strategies for such projects are (1) to get outnow; (2) if you can't get out, hide; and (3) if you can't hide completely, tell managers exactly what they want to hearbecause it's exactly what they deserve.

Progress Reporting

APM is not abdication of control; it's an endorsement of accountability and a revised definition of "what" to control. Project teams should be accountable for performance, for results that they have had a part in planning. Periodic progress reporting assists the project communityexecutives, project manager, and teamin controlling the project and determining when to take adaptive action. Because agile projects are often exploring areas of high risk and uncertainty, early recognition of issues and problems is essential to early adaptive action. By employing short, timeboxed iterations and reviewing working features that demonstrate real progress (or lack thereof), APM provides the tools needed to identify problems early, when there is a wider set of adaptive actions available, including project termination.

A manufacturing process operates on known information. A product development process essentially purchases information. The uncertainty of product development turns a project into an information discovery process in which money and time are spent gathering requirements, trying out designs, building features (or models), and testing alternatives. At the end of each iteration, additional information is known about the product. The project team, managers, and executives access the progress information, compare it against targets, decide if the project is still viable , determine if new targets are needed, and identify adaptive actions. They are essentially asking the question, "Was the information generated worth the money and time we spent on this last iteration?" This is a very different question than, "Did the project conform to plan?"

Production-style project management begins with deterministic, predictive plans and then exercises control over those plans, so it can be characterized as having a "conformance to plan" control mentality . APM begins with project plans that adapt over time to changing conditions. In order to have both predictability and innovation, we have to broaden our controls from conformance to plan to conformance to vision and value. Conformance to value recognizes the critical nature of the business outcome of a project. If we produce a product that's on schedule, on budget, and meets specifications but doesn't sell in the market, we have not been successful.

The saying "The map is not the territory" should be emblazoned on project progress reports, as some measurements often hide real progress. Working product (or simulations and models, in some cases) are the ultimate in reality-based, verifiable , dependable progress measurements. Features are donefinished and acceptance tested by customersor they are not. Measuring feature completion closes the gap between the map and the territory.

Progress reporting helps the project community determine if the project is still moving in the right direction and whether the customer feels that she is getting value for the money. If the customer or product manager confirms that value is being delivered, the project proceeds to the next iterative delivery cycle. If value has not been delivered, then the project is terminated or adaptive action is initiated. At the end of an iteration the customer may say, "I thought I understood what I wanted four weeks ago, but now that I see the results, and based on recent business information, we now need to change direction." Or, the development group may deliver a set of features, but for some reason it missed what the customer intended. In either scenario there is little blaming, and the response is, "Now that we know what we now know, how do we best move forward?"