Customer-driven project management

The Missing Knowledge Area

One critical factor is missing from the Project Management Knowledge Areas (PMI, 2000). While the existing Knowledge Areas are necessary to successfully plan and execute a project, they are not sufficient. A project manager can flawlessly execute each of the component processes in the Project Management Framework and still fail.

The missing knowledge area is Project Customer Management. Some will argue that customer issues are already adequately addressed within the existing framework. However, recent changes in the project management environment require that more than secondary attention be paid to the customer's integral role in the successful management of projects.

Company executives are now holding project managers accountable for customer satisfaction, customer loyalty, support costs, and No Trouble Found (NTF) warranty returns, all of which can be traced to how well the customer has been integrated into the project management process.

This paper describes new mindsets and methodologies for integrating the customer into the practice of project management. Using these techniques, project managers can not only bring their projects in on time and under budget, they can also deliver reduced support costs and increased customer loyalty as well.

The Customer as Stakeholder

The idea that the customer must be more tightly integrated into the project management process is not new. In the 2000 edition of A Guide to the Project Management Body of Knowledge, (PMBOK^®)the customer is listed prominently as a project stakeholder. It is the project manager's responsibility to determine the customer's requirements and then “manage and influence those requirements to ensure a successful project” (PMI, 2000, 16). In a similar vein, Alan Cooper, creator of the Stage-Gate™ process, implores his readers to “spare no effort in building the customer or user into your new product process” (Cooper, 2000, 44).

How is customer integration accomplished today? Many organizations use Quality Function Deployment (QFD), a quality system aimed at increasing market share by mapping the subjective desires of the customer into the language of the engineer (Terninko, 1997). Six Sigma is another approach, and was designed to be, among other things, a metric with which an organization can improve customer-focused quality (Tennant, 2002).

But what has been lacking in most projects thus far is not intent, but technique. Conventional tools for capturing the customer point of view – including focus groups, voice of the customer (VOC), QFD, Six Sigma, usability testing, and customer advisory panels – are good ways to focus the project team on macro design issues and to define product feature sets. But when used to direct low-level design decisions, such as user interface layout and product behavior, these techniques often produce more conflict than convergence.

In each of these methodologies, the customer is a laboratory specimen, the subject of analysis, a vessel from whom data is extracted. Data is collected on customer needs, wants, likes, dislikes, expectations, task performance, and product requirements. But customers cannot describe everything they need and want and expect in sufficient detail to drive low-level design. For example, a customer may say he wants a calculator built into his watch, but he won't tell you how to assign functions to the buttons on the watch so that the time can be easily set. A customer will say she wants a laundry room and a basement in her new house design, but she won't notice that the laundry room and basement doors can bang into each other until she actually lives in the house awhile. And yet, these are the levels of the customer experience to which the project team must dive in order to avoid low customer loyalty and high support costs. The devil is in the design details.

The Customer as Design Component

To capture the data required to manage project planning and execution at the lowest levels – levels required for product/service design and implementation – project managers must instill a fundamental shift in the concept of the customer into their teams. Instead of treating customers as external data sources, they must fully integrate customers into the project by treating them as components in the design.

Every time a project team designs a product, they also design a customer. The product has certain functionality that customers use to help them achieve results. But to achieve those results, the product demands the customer have certain functionality, too. The customer must know what buttons to push on the product, when to push them, and how to respond to errors and unexpected conditions. This customer functionality is dictated – designed – by the same project team who designed the product.

A product's ideal customer is one who knows all results that can be achieved with the product, knows the correct sequence of actions that must be taken to achieve each result, and knows all of the failure indicators that prevent a result from being achieved and how to correct them. These are the product's minimum customer requirements – all the things a customer is required to know and do in order to achieve results with the product. The question is: how many of the product's customers actually meet these minimum requirements? Does the ideal customer, as the project team has designed him or her, actually exist?

Most project teams never think about the customer they have designed and whether the design is viable. Yet customer designs fail much more often than product designs – just look at the high support costs for complex products. If a customer cannot be found that meets the product's minimum customer requirements, then the product, in effect, has no long-term customers. In the short term, customers can be enticed to buy the product through effective marking campaigns and the promise of desirable results, but if these results cannot be realized, the product will die from the costs of returns, support, customer ill will, and negative publicity.

The lesson is this: you must design your customer as carefully as you design your product.

In fact, product design and customer design must proceed in tandem – you cannot design one without designing the other. Every product design decision has an effect upon the customer design and vice versa. Every button added to the product is another button the customer is required to know how to use; every nondescript error message is another error condition the customer must decode. Likewise, every customer requirement that is reassigned to the product may add cost and time-to-market to the project.

For every function that must be performed, a conscious decision must be made whether to assign it to the product or to the person (Exhibit 1). For example, twenty years ago a person installing a new memory card into a computer was required to read instructions – which is nothing more than program code for the human processor – to set switches for the starting memory address. Today, this functionality has been rewritten as computer code and happens automatically when the memory card is inserted. What was once a person function is now a product function.

Exhibit 1. Assigning functionality

A Project's #1 Objective

The #1 purpose of a project is to enable a customer to achieve Job 1 Results. All other project objectives are secondary, including schedule and budget.

Job 1 Results are all of the outcomes customers want to achieve with a product or service (Bowie, 1996). Job 1 Results are revealed by asking the customer to fill in the blank in this sentence: “I purchased this product or service so I could_________.” For a portable CD player, the customer's Job 1 might be to listen to music while exercising. For a cell phone, Job 1 might be to call business associates and clients while traveling.

Job 2 Results, on the other hand, are requirements, imposed by the product, that must be met before the Job 1 Result can be achieved. Job 2 Results are the means to the Job 1 ends, and can be very undesirable. Tasks like installation, configuration, troubleshooting, searching, and reading are Job 2 requirements foisted upon customers by complex product designs. No one fills in the blank in the sentence above with “I purchased this product so I could spend three hours installing it” or “I purchased this service so I could spend my lunch hour waiting in line.”

It takes great courage for project managers and company executives to make Job 1 the #1 project objective. Several years ago, Western Digital demonstrated their commitment to Job 1 by delaying shipment of a new line of consumer hard disk drives when they discovered customers were likely to fail in the installation process, a Job 2 requirement. If customers failed in the installation, the Job 1 Result of storing more files and programs on their computers would never be realized. While disastrous from a revenue perspective, the decision to hold the drives until the fatal flaw in the customer design could be fixed saved millions in support and warranty costs and avoided a customer loyalty meltdown.

Designing the Total Customer Experience

While designing a process by which the customer and the product can collaborate to achieve Job 1 is essential to planning and executing a project, there is one more aspect of the relationship between the customer and the product that must be managed. Project teams must also capture, analyze, and design the Total Customer Experience (TCE).

A Customer Experience is a collection of events, perceived from the customer's point of view, that occur en route to a Job 1 Result. The Total Customer Experience is the net effect on the customer of these events over the life of the customer/product relationship.

A product provides a roadway to Job 1 Results over which its customers must travel. How the project team assigns functional responsibilities determines the nature of the road and the customer's experience of driving it. The ideal road leads directly to the Job 1 Result with a minimum of distance. A product that provides this type of customer experience is a product that “just works.”

Far more common, however, are products that lead their customers down a circuitous path to get to the Job 1 Result. These products construct roads full of dangerous curves, detours, dead ends, and obstacles through which the customer must navigate to reach Job 1.

If the road becomes too difficult and time-consuming, the customer will simply turn back and find another road (product). Even if they stay the course and reach the Job 1 Result, chances are high that many customers will avoid using the same road again and will advise others to find an alternate route.

Thus, to design the Total Customer Experience, project teams must design, in detail, every inch of the roadway leading to Job 1 Results. Total Customer Experience Design is an engineering discipline that applies the laws of human behavior to product development. It must be taken into account to create a successful product.

The Job 1 Model

The Job 1 Model focuses project teams on Job 1 and provides a methodology for using the customer experience to simultaneously design the customer and the product/service.

Exhibit 2. The Job 1 Model

In the model (shown in Exhibit 2), a product and a person (customer) are collaborating to achieve a Job 1 Result. To achieve this result, a set of actions must be taken (represented by the center arrow), some of which are assigned to the product and some of which are assigned to the person. The product has been programmed with the functionality (instruction code and data) necessary to perform all actions assigned to it. The problem arises when the person is assigned responsibility for actions whose instruction code and/or data are not “preinstalled.” It is then the project team's responsibility to “install” this missing functionality in the customer, and guarantee that it will be compiled and executed without errors.

To solve the problem of missing customer functionality, most project teams try to reshape customer behavior to conform to the demands of the product. Customers must learn to use the products; to learn, they must read the documentation, search online help systems, and commit time to learning how to use the product through various training and e-learning offerings. If these techniques fail – if the customer refuses to learn or cannot find the needed information – the Job 1 Result cannot be achieved and the product fails. Designs based on expectations of learning frustrate customers, generate NTF returns, and create customer assassins – people who feel so wronged by a product or service that they devote their lives to denigrating the product/service and the company that made it.

Example: Managing a Project to Produce a Calculator Watch

To illustrate how to use the Job 1 Model to capture, analyze and redesign the customer experience of a product, imagine that you're the project manager assigned to produce your company's first calculator watch., based upon market research indicating a growing customer need for this feature set. The lead engineer on your team designs the following process for setting the time:

1. Press the MOD button three times. The hours begin flashing, telling you that you can now set the time.
2. Press any even-numbered button to select which time field you want to set (date, hours, minutes, seconds). Then, press any odd-numbered button to change that field.
3. Press MOD again when you're done.

Exhibit 3. Calculator watch

Step 1: Taking Inventory

An Information Inventory captures instructions and data responsibilities in the Job 1 Model that a product design assigns to its customer. Remember these instructions are the code the customer executes to perform assigned actions; data are the bits of information the customer must know before the instruction can be executed. Think of these as the software that must be installed in the customer in order for the Job 1 Results System to function properly.

Here is the Information Inventory for the calculator watch:

Exhibit 4. Information Inventory

The instructions are the lines of code the user must execute; the data are the parameters that allow each instruction to be executed. The next question to ask is this: How many human beings are out there who have this code preinstalled? In other words, how many people could pick up this watch and set the time without referring to these instructions? The answer: aside from employees who work at the watch company, very few.

This watch company has just designed a product for a user who does not exist (not a terribly astute marketing move)! The only salvation for this product now lies in the hands of the project team, who must find a way to program users with this missing information. However, your customer-driven project team understands that an instruction sheet won't solve the problem, that most users will either lose the instruction sheet or reject these absurd requirements outright and buy another watch.

Step 2: Relevance, Accessibility, and Effectiveness

The next step is to evaluate the Information Inventory from the customer's point of view. Ninety percent of the total customer experience for a product or service comprises the information the customer is required to know. Especially important is whether each information requirement is relevant to the Job 1 Result, accessible, and effectively presented. For each instruction and its requisite data, ask:

For each question, rank the answer as either High (H) if the information has very high relevance, accessibility, or effectiveness, or Low (L) if the information has very low relevance, accessibility, or effectiveness.

The scores for the calculator watch are below:

Exhibit 5. RAE Scores for calculator watch

The data requirements shown in bold italics are of particular concern, since each is both irrelevant and inaccessible. Why? Because memorizing that even-numbered buttons do one thing while odd-numbered buttons do another has nothing to do with the Job 1 Result of telling the time. Furthermore, it's difficult to remember to press the MOD button three times in order to enter time-setting mode; the only way most people will remember this is by reading the instruction sheet, which users clearly don't want to do for what should be a simple, routine task.

When users are assigned irrelevant information responsibilities, they get angry and frustrated. When users have to search for irrelevant information, they get even angrier. Irrelevant and inaccessible information requirements are likely to obstruct the user from setting the time, a critical Job 1 Results System failure. Job 1 Results System failures will cost the watch company money: in support, bad will, product returns, and low market share.

Step 3: Redesigning the Job 1 Results System

Once you have discovered critical failures in the Job 1 Results System, you must redesign it to increase the likelihood of success. You do this by:

• Eliminating or reassigning irrelevant information requirements so the user doesn't have to deal with them. In the watch example, can you think of a design that would eliminate the requirement that users memorize what even-numbered buttons do versus what odd-numbered buttons do?
• If irrelevant information cannot be eliminated completely from the user's view, then at least make certain the information is readily accessible. If, for some odd reason, you could not eliminate the need for users to know what even-numbered and odd-numbered buttons do, how could you make their functionality more obvious, eliminating the need to refer to the instruction sheet each time they set the time?
• Making sure that all remaining information is presented effectively. This is standard technical writing technique; for example you would not use words to describe a piece of information that is best represented as a photo or illustration.

Your final design may not be perfect, but at least it will be improved. Every piece of information you can eliminate from the customer's requirements is a victory for the customer and for you. Every piece of information that you can deliver to the customer instead of making them search for it in an external source (manual, help system, another person) improves the customer experience. Every piece of information that can be absorbed quickly and easily, without mental translation from one form to another, improves user communication.

Conclusion

Perhaps the easiest way to begin integrating your customer into your project is to replicate all product activities in the project life cycle for the customer component. For example, make a customer design spec listing all expected customer functionality when you create the product design spec. When you conduct product performance testing, conduct customer performance testing also.

Assign one person on your team as the “customer architect” to oversee the project from the customer's perspective and to assess the effect of project decisions on the customer experience and on customer-driven costs (support, returns, and negative loyalty).

Finally, begin the difficult process of educating your organization on what it means to execute a successful project. Resist the temptation to declare victory if a project completes on time, meets its quality goals, and doesn't exceed its budget. Remember that the badge of success can only be awarded by the project's customers. In other words, your project cannot succeed unless your customers do.