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

Project Cancellation

While you are directing and managing your project execution, your sponsor tells you that your project has just been terminated. Will you complete Verify Scope process before closing your project?

Yes, verify scope provides an opportunity for the PM and the sponsor to document the project status at that moment... that can be used for lessons learnt as well for future projects. (Name withheld)

No.

Process 5.4, Verify Scope is the process of formalizing acceptance of the completed project deliverables and includes reviewing deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance of deliverables.... (PMBOK) Since the project has been canceled, no more deliverables will be accepted. Completing the Verify Scope process would waste resources.

 

Exceptions not indicated by the question

• The terms of a cancellation could include acceptance of whatever has been completed.
  
• The company could preserve the deliverables in their current state for use in future projects, in which case, knowing their quality would have value.

Note 1: If one traces the flow of outputs from the Verify Scope process, the next step for any Accepted Deliverable is process 4.6, Close Project or Phase.

 

Note 2: Documenting the project status at the time of cancellation would start with Work Performance Measurements produced by following process 5.5, Control Scope, the process of monitoring the status of the project and product scope and managing changes to the scope baseline. (PMBOK).

 

The PM would then follow process 10.5, Report Performance, to analyze the project's progress, producing Performance Reports. For the final step, following process 4.4, Monitor and Control Project Work, the PM updates Project Documents, including performance reports and issue logs. (The PM would also make other updates to Project Documents during that preceding processes.)

 

Note 3: Non-accepted deliverables would be subject to the Direct and Manage Project Execution or Perform Quality Control processes (and their design and production partner processes). The Direct and Manage Project Execution and the Close Project of Phase processes might invoke some sort of Disposal process to handle the non-accepted deliverables.

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