Buyers versus Users

The new project manager (PM) or systems engineer (SEs) knows that the Seller, the person or organization providing deliverable products or services, must fulfill the scope defined by the Buyer. The Seller and Buyer usually negotiate a Project Scope Description which the project Sponsor includes in the Project Charter. Details of the project scope description may be found in the contract, Statement of Work, and any subsequent approved Change Requests.

 

The PM also knows that the Project Requirements must detail the project scope through requirements analysis and through creation of a Work Breakdown Structure (WBS) that has enough granularity to define project tasks at a manageable level.

 

New PMs or SEs may overlook the importance of a third party: Users.

 

Users are people or organization who put their hands on the product or receive the service. The Buyer may or may not be the User. For example, as part of a project to set up a business office, a manager (the Buyer) may want to buy spreadsheet software for his analysts (Users).

 

In one contract, my company upgraded communications equipment for an agency (the Buyer) that needed new types of signal channels. The Buyer owned the equipment, but another contractor provided the operators, and yet other agencies utilized the communication channels.

 

Even though we took our direction from our contract with the Buyer, we coordinated with the third-party Users to validate the Buyer's requirements. Unhappy Users would have been reflected by an unsatisfied Buyer, which would have cost us future business.

 

The PM must gain acceptance from the Buyer by satisfying the requirements. However, in many projects, the PM must also define the requirements in enough detail to ensure that they reflect the Buyer's needs. This implies added responsibilities:

• The differences between needs and requirements must be identified as early as possible in order to prevent expensive changes later.
• If meeting the needs increases the scope, schedule, or cost, the PM must inform the Buyer and negotiate changes as soon as possible.
• The PM needs the courage to help the Buyer understand what he needs and what he will not receive.
• Enough time should be spent during the planning phase of a project to ensure that meeting the scope, requirements, and needs will result in a happy Buyer.

Returning to the example in the first paragraph: The manager may think he can get by with Lotus 1-2-3 (ca. 2000), but the analysts are familiar with Excel 2007 and need the new functions that come with Excel 2013. The PM needs to advise the Buyer to take a class in computer literacy.

Copyright (C) 2013, Richard Wheeler. Permission granted for use not involving publication.
Expand this commen