Chapter 13: Managing Customers and Beneficiaries

---

Without a doubt, the most troubling aspect of any complex project is having success with your customers and beneficiaries. Numerous references to this project management challenge have been made throughout the book. Now, it is time to give this subject our full attention, starting out with a little self-disclosure. Prior to becoming a project manager, my information technology (IT) background was spent selling, delivering, and managing the sales and delivery of highly technical IT services. Among other things, this was excellent preparation for project management. Despite what a lot of people think, the sales profession is tough. It takes hard work to be effective, and it is more about hard work than golf. I know very few people who spend a lifetime in sales. Everyone I know who spent significant time in that profession neither regretted the lessons learned nor leaving that line of work for a more emotionally stable career opportunity. What I am going to do in this chapter is apply some of the tricks of the sales trade to the quixotic world of customer and beneficiary management for project managers.

13.1 How it is Supposed to Work

When walking through the requirements gathering process earlier in this book, I spoke of the need to articulate assumptions as the first step toward defining project deliverables. Working with assumptions is fine as an early step, but they must be closely examined to be sure that they are based in reality and can garner a reasonable level of universal acceptance. Let us take a moment to examine the assumptions most project managers make about customers and beneficiaries. We will start by revisiting the distinction made between these two classes:

1. The customer funds the project.

2. The beneficiary reaps the rewards of the project deliverables.

Sometimes, the customer and beneficiary are one and the same. The larger the project is, however, the less likely this is to be true. This is because large projects are generally "top down," that is, driven by significant corporate objectives that tend to cross the parochial boundaries of individual departments or business units. Therefore, with most complex IT projects, the customer will be the corporation funded through the IT department, whereas the beneficiaries would vary depending on project goals, for instance:

• Everyone

• Anyone with an office in the Pacific Rim

• All users still on unswitched, 10-megabit Ethernet local area networks (LANs)

Now, let us look at Exhibit 1, which includes the basic assumptions made about these two subsets of the corporate citizenry.

Exhibit 1: Expected Behavior

If these assumptions were actually true, it would be because you stumbled across the perfect customer and beneficiary. I have yet to do that. Especially with complex projects with millions of dollars on the table, no customer in their right mind is going to sit idly by and trust you to deliver exactly what they believe they are paying for without their ongoing advice and consent. Similarly, no beneficiary is going to resist the temptation to leverage those millions to his own benefit, regardless of scope or anything else that constrains your behavior.

Please take a moment to reflect on this issue vis-à-vis your own experience. This chapter is based on the idea that these assumptions are naïve if not unfortunate and, if believed, can introduce as much risk into a project as anything I can imagine. If I am not communicating this concept well, ask yourself how many times you have been angry with a customer or beneficiary because they were making your job harder! Salespeople joke all the time that if it were not for customers, the job would be easy. Right. Without customers, there would be no sales jobs or, in our case, project management positions.

---