Deliver Customer Value

While this may appear to be a simple principle, one nearly too simple to articulate , it is one that must be emphasized over and over lest project team members forget. When organizations get bigger and administrivia increases , when compliance activities take a larger and larger portion of a team's time, when the communications gap between customers and project team members widens, and when project management plans focus on interminable intermediate artifacts, delivering something useful to the customer gets lost. [1]

[1] In this book, the term "customer" represents a wide range of entitiescommercial business-to-business customers, retail consumers, and customers internal to an organization. The people included in each of these instances vary, from those who actually use a product, to executives who approve purchase, to product managers who coordinate customer interactions with development organizations. I will use the terms "customer team" and "product manager" to represent all of the potential combinations of customers.

In defining customer value, one question always comes to the fore, "Who are the customers? Are they users of the product, or managers, or other stakeholders?" A direct answer is that the customer is the individual or group that uses the created product to generate business value. This definition separates customers from other stakeholders, so in this book the word "stakeholders" will represent these other individuals associated with the project.

If we want products that deliver outstanding customer value, then we must have a customer-developer partnership, one with responsibilities and accountability on both sides (and similar relationships with key suppliers). Agile teams constantly seek customer involvement and are always asking the question, "Is what we are doing useful to you in meeting your business goals?"

While delivering something useful to the customer remains paramount, keeping all the participants informed and involved is critical to success. Senior management may have different project objectives than the project sponsors. For IT projects, the project sponsor may be a marketing executive who focuses on features and business value, while IT management may constrain the project with architectural requirements.

The success of any product involves meeting expectationsthose of the ultimate customer, those of management stakeholders, and those of the project team itself. There is a big difference between requirements and expectations: requirements are tangible ; expectations are intangible. Yet ultimately, it is the intangible expectations against which actual results will be measured. Cultivating committed customers and stakeholders means involving them in dialogue about both requirements and expectations. As colleague Ken Delcol comments, "This also includes the Kenny Rogers school of managing the communications with customers and stakeholdersknow when to hold, when to fold, when to walk away, and when to run. Project managers must have the business savvy to understand this."

There are two particularly important issues involved in delivering customer value in a new product development (NPD) environment: focusing on innovation and adaptability rather than efficiency and optimization and concentrating on delivery rather than compliance activities.

Innovation and Adaptability

"We live in a time where creativity, innovation, and imagination drive the world," write Tom Wujec and Sandra Muscat (2002). Creating new products and services differs from making minor enhancements to existing ones. The first must focus on innovation and adaptability, while the second usually focuses on efficiency and optimization. Efficiency delivers products and services that we can think of. Innovation delivers products that we can barely imagine. Efficiency and optimization are appropriate drivers for a production project, while innovation and creativity should drive an exploration-type project. A production mindset can restrict our vision to what appears doable. An exploration mindset helps us explore what seems impossible .

Optimization implies that we already know how to do something but that we now need to improve it. Innovation implies that we don't know how to do something, and searching for that knowledge is paramount. No project, no product development effort is all one way or all the other, but project managers (team members, customers, and executives) should understand this fundamental difference when deciding how to plan and manage their projects.

The customer value goal of APM has two equally critical components : creating innovative products that deliver outstanding customer value today and tomorrow. The and tomorrow phrase speaks to the need for adaptability, which in turn speaks to the importance of technical excellence. Products that meet today's customer requirements but cannot adapt easily to future needs are doomed to short life spans .

APM's core purpose of creating innovative new products and services means dealing with constant technological and competitive change, generating novel ideas, and continually reducing product development schedules. The core purpose is not reducing cost, although that may happen, or gaining efficiency, although that may happen also. However, there are times when even the most innovative team needs to bring a bit of efficiency to their projectall part of the balancing act that makes project management interesting, and difficult.

Planning and Control to Execution

When project managers focus on delivery, they add value to projects. When they focus on planning and control, they tend to add overhead. [2]

[2] Ken Delcol observes, "The reality in NPD is that you need both, and the trick is balance, which changes through the development lifecycle. Most people don't get this."

A quick review of the general management literature uncovers hundreds of books on leadership and strategy, but interestingly enough, very few on how to actually execute. Ram Charan, a distinguished author and consultant to CEOs, echoes this observation. "As I facilitated meetings at the CEO and division levels, I watched and studied, and I saw that leaders placed too much emphasis on what some call high-level strategy, on intellectualizing and philosophizing, and not enough on implementation" (Bossidy and Charan 2002).

With respect to project management, Greg Howell and Lauri Koskela (2001) argue that traditional project management practices focus too much on management-as-planning and a thermostat model for control, and not enough on what the major project management focus should beexecution.

According to Howell and Koskela, the common project management approach is composed of three processes that exchange informationplanning, controlling, and executing. In construction projects, they see several troubling aspects of traditional planning. First, the motivation for planning often comes from outside the project; that is, plans are developed to satisfy legal, regulatory, or management requirements rather than being based on the work that needs to be accomplished. Second, the motivation to plan often relates more to the desire for control than the needs of actual work execution, perhaps because the people planning the work are not involved in the doing of the work. This happens constantly in software development, where the task-based planning that project managers use for control has little relationship to how software engineers really work. Third, planning and control become the focal points; execution is considered of minor importance, and legitimizing the project takes precedence over producing results.

Control has historically centered on correction rather than learning, because plans were viewed as reasonably correct, and translating the plan into action was considered a simple process. Witness the conventional "wisdom" that construction itself (carpentry, electrical, plumbing, etc.) is merely manual, mechanical work without much decision making or creativity (just follow the plans) or that software programming is just coding what's specified. If plans are viewed as correct, then control focuses on fixing mistakes and explaining discrepancies, not learning something new that might legitimately alter the plans. Other problems with this historical view of control include inappropriate manipulation of work in order to meet the plan, reduced possibilities for collaboration, incorrect interpretation of performance, and reluctance to revise plans.

APM is an execution-biased model, not a planning-and-control- biased model. In APM, the project manager's primary role is to facilitate creation of a product vision and guide the team toward making that vision a reality, not to develop plans and schedules and control progress such that the "plan" is implemented. However, we need to interpret the forgoing ideas carefullyAPM is not an anti-planning model. Planning (and control) is an integral part of APM; it is just not the focal point. As with many aspects of agile development, there is a wide gap between one thing being less important than something else and being un important.

Once project teams focus on execution, a next critical step is then to concentrate on value-adding activities, those that assist the team in delivering results, rather than those that merely ensure compliance.

Delivery versus Compliance

APM is first and foremost about deliverydelivering results and delivering value to customers. Too many project managers, too many project office members, too many organizations have drifted toward compliance as their primary, if often implicit, focus. Compliance activities, at their best, attempt to mitigate the risk of mistakes, fraud, poor performance, and financial overruns. Managers want reports . Accountants want numbers . Auditors want sign-offs. Governmental agencies want documents. Standards groups (ISO, SEI, and others) want proof of compliance. Legal departments want everything. Failure to differentiate between delivery and compliance results in ever-increasing compliance workproducing documents for regulators, lawyers , or managementwhile delivering products falls to secondary priority.

In one of my favorite books, Systemantics: How Systems Work and Especially How They Fail , John Gall (1977) warns against the rising tide of "systemism""the state of mindless belief in systems; the belief that systems can be made to function to achieve desired goals." Gall's point is that "the fundamental problem does not lie in any particular system but rather in systems as such ." These systems become the goal rather than the means to a goal.

Adherents of these "systemisms" would argue that implementing these programs should not result in losing track of the primary goal (results rather than process). But Gall points out how this subversion becomes inevitable through two of his axioms: 1) "Systems Tend to Expand to Fill the Known Universe" and 2) "Systems Tend to Oppose Their Own Proper Functions, Especially in Connection with the Phenomenon of 'Administrative Encirclement' "(Gall 1977).

Consider, for example, the rounds of procedures and mounds of documentation that are required to gain ISO or CMM certification. I worked with a company that had workaround after workaround to circumvent its ISO processes. Changing the standard processes was so burdensome that everyone used workarounds. However, they did have one solution for the volumes of process documentsa sophisticated automation system in which just the list of processes went on for page after page after page. I examined an auditor 's report (ISO certification requires periodic audits ) of some 10 pages that were filled with compliance issues such as failures to sign or date a form or the absence of some document. There was not a single substantive delivery issue mentioned in the report! Managers had to spend time analyzing this audit report and then writing another report about how they would keep these terrible things from happening again, when of course their only concern was to placate the auditors, not to make meaningful improvements in the system.

Clearly, this company's ISO "system" had run amok. However, the system had become so ingrained in the companyand maintaining certification such a mantrathat getting out from under the burden was proving exceedingly difficult. This illustrates Gall's first axiom , which says systems tend to expand to fill the known universe. Once underway, systems become very difficult to change, and compliance, not delivery, becomes the goal. At the point where employees are trying to deliver results, these systems are almost universally hated because they impede progress. The systems, as Gall says, inevitably tend to oppose their own proper functioning.

Project managers need to relieve the project team from as much compliance work as possible, even if that means taking on the tasks themselves . Several years ago, when talking to a project manager of a very successful CMM Level 5certified software development organization, I asked him about all the documentation, metrics, and reporting work that went into certification. "Oh," he said, "I take care of most of that myself . The development team needs to concentrate on the real work."

Building process frameworks that don't succumb to Gall's axioms is difficult. Agile frameworks do need minimal documentation and a mechanism to convey knowledge about project success and failure to others in the organization. The answer isn't eliminating either documentation or process, but approaching both from a simplified, lean, barely sufficient, just-enough perspective. Streamlining processes, targeting a level of bare sufficiency, and recognizing the difference between compliance and delivery activities (although some activities have aspects of both that aren't always easy to separate) will pay big dividends in delivering value to customers faster and at a lower cost.

Lean Thinking

Many of the ideas of the agile movement first arose within lean manufacturing, which began in the automotive industry in Japan in the 1980s. One of the fundamental tenets of lean manufacturing is the systematic elimination of waste; that is, any activity that doesn't deliver value to the customer. One way to streamline projects (doing fewer things, doing the right things, eliminating bottlenecks) involves differentiating between delivery activities and compliance activities and applying appropriate strategies to each. [3]

[3] For background information in this area, although the authors don't refer to compliance or delivery activities, see (Womack and Jones 1996).

While lean manufacturing ideas have been used in the United States for a while, lean product development ideas, especially those of Toyota, have gained less recognition. The Toyota development system offers huge potential productivity gains by eliminating non-value-adding compliance activitiesmany organizations stand to increase their productivity three to four times! Allen Ward is the man responsible for bringing many of the ideas from Toyota's lean product development system to the US. When Ward asks Toyota's American engineers and managers how much time they spend adding value (i.e., actually doing engineering work), their response averages 80%. The same question asked of engineers and managers at American automobile companies averages 20%. How can you compete with companies that are getting four times as much value-adding work from their development engineers? (Kennedy 2003)

Try this survey in your organization, but be prepared for a shock . Ask your entire staff or your project team, including managers, how much time they spend doing engineering or development activitieshow much time do they spend adding value to the customer? How many of your "improvement" initiatives (CMM, ISO, Six Sigma, TQM, BPR) have just added layer after layer of forms, procedures, meetings, and approvals to teams trying desperately to produce something useful? Too much structure not only kills initiative and innovation, it consumes enormous chunks of time. The fundamental issue is not that these initiatives are valueless, because they are not, but that they fundamentally value structure over individual knowledge and capability. And that's why they are so difficult to implementpeople feel devalued.

The issues surrounding delivery versus compliance activities have special significance for project managers. First, project managers need to analyze project activities to maximize time spent on delivery. Second, project managers must analyze their own activities to determine whether they are contributing to delivery or compliance. For example, when a project manager creates a status report for management, she is " complying " with a management dictum. However, when she is coordinating the activities between two feature teams or assisting a team in reaching a critical design decision, she is contributing to deliveryshe adds value to the delivery process.

Lean thinking provides one way to separate delivery from compliance activities, which in turn enables companies to optimize delivery activities (Womack et al. 1990; Womack and Jones 1996). The four tenets of lean thinking are:

1. Specify value
2. Identify the value stream
3. Flow
4. Pull

Value can only be defined by the ultimate customer, and it is expressed in product termscustomer needs, price, time, and quality. The customer in this analysis is always the end consumer, one out in the marketplace. Identifying the wrong customer (e.g., internal management) can lead to misinterpretation of marketplace value.

A value stream consists of the activities required to bring a product to customers: product development, order processing through delivery, product manufacturing. Each of the specific activities is then analyzed to determine where it adds value and where it doesn't.

Flow thinking encourages everyonemanagers and staffto abandon the traditional batch-and-queue mode of thinking for that of small-lot flow. In other words, whatever the step, keep activities flowing from one to the next without delays for approvals or waiting for the next department. For example, a drug development team using rapid experimentation techniques would not be exhibiting flow if it constantly had to wait for lab testing results.

Finally, pull thinking means waiting for customers to ask for products, rather than building a large inventory and then "pushing" product to customers. Dell Computers operates a pull system, waiting until a customer's order "pulls" the product through the system. [4]

[4] For more on Lean Development, see (Poppendieck and Poppendieck 2003).

Necessary Compliance

It is important to note that there are good reasons for some compliance activitieswe just need to keep them from impeding progress. Project managers can add value to a project by handling compliance issues well.

Every organization, every company, every project team has legitimate compliance issues. For example, in the automotive industry, an enormous volume of documentation must be retained for potential product liability lawsuits and government crash investigations. In the pharmaceutical industry, companies may decry US Food and Drug Administration (FDA) inefficiencies , but few consumers would want to buy drugs unfettered by federal regulation. Executives have a responsibility to shareholders, employees, and customers to exercise oversight, which may take the form of audits, project status reports, purchasing policies, or certifications.

The activities surrounding these compliance efforts don't deliver customer value (except in a convoluted, roundabout way), but they are necessary activities nonetheless. In short, compliance is a cost of doing business. But compliance work can also strangle innovation, raise costs dramatically, and lengthen product development cycles.

As Figure 2.2 shows, compliance activities can spiral out of control as performance shortfalls are "fixed" by additional compliance activities ("We'll never make that mistake again!"), which in turn negatively impact delivery results. Large companies tend to put heavy processes in place to prevent low-probability mistakes, burdening the delivery process with paperwork and controls.

Figure 2.2. The Compliance Loop

There are actually two kinds of compliance activitiesinternal and external. External compliance can't be avoided and shouldn't be. Government regulations were established for a reason, but when the reasons expire, the regulations rarely follow. The strategy for most external compliance activities is to do just enough, but no more than is absolutely required. Internal compliance activities grow with the size of an organization. Clearly a 50,000-person organization will have more compliance activities than a 100-person one. But the objectives of APM are the samereduce the burden of compliance work as much as possible and don't let it interfere any more than necessary with delivery activities.

For necessary compliance activities, the strategy should be to minimize them and get them off the critical path and the critical people. Compliance activities should be examined from a risk management perspective: What do we have to accomplish in order to balance the cost of compliance with potential risks? This is an extremely important point. Compliance activities do not, nor should they be expected to, produce customer value. We should think of all compliance activities as overhead and oversight cost, necessary to some degree but subject to minimization based on the risk involved.

Delivering Value

Another salient point is that too many people (especially managers and process designers) think compliance activitiesreviews, checkpoints, formal documentation, and elaborate and detailed plansadd value. One of the other tenets of lean thinking (and agile development) is to trust the people actually doing the work and to push decision making and collaboration down to the working level. A very simple but infrequently used method of distinguishing delivery from compliance activities is to ask those doing the work, "Does this activity help you deliver customer value, or is it overhead?" Unfortunately, many managers and process designers don't like the answers they receive.

A colleague recently recounted a story that illustrates the trouble (along with confusion about "empowerment") that this confusion between delivery and compliance can cause. In a company he previously worked for, senior managers decided to " empower " employees, so they pushed all the project management activities down to the engineers. Now, rather than designing products, engineers spent much of their time on budgeting, status reporting, and other administrivia that project managers had previously handled. The engineers didn't feel empowered, they felt burdened. They were spending valuable engineering design time feeding the company's paper mill.

While compliance activities can be costly, an even more serious problem is their impact on development time. For example, if we view formal documentation (e.g., a design document) as helping deliver value, we would assign the task to developers. However, if we view that design document as a compliance artifact, we would try to offload it from developers so they could concentrate on value-adding activities.

Let's postulate that during a design session, a team constructs a series of design diagrams on a whiteboard. From a product delivery perspective, taking digital photos of the diagrams and storing them in a project folder may be sufficient. However, from a compliance perspective (say, to maintain ISO certification), the diagrams need to be formalized and documented in a standard format. Once the design diagrams are complete on the whiteboards , support staffnot the engineersshould be available to transfer the low-ceremony diagrams into formal documentation. Support staff free the engineering staff to continue delivery activities with minimal schedule impact, plus their salary costs are lower. When we fail to differentiate delivery and compliance activities, we mistakenly regard cleaning up and formalizing documentation as helping developers build better products. By offloading , we force ourselves to confront the true cost of compliance, and we keep compliance activities from wrecking development schedules.