Reporting vs. Processing Relationships

You see Reporting Relationships on the organization chart.  They represent the conduit through which authority and accountability flow within the organization.

Processing Relationships dictate how work actually gets accomplished.  Each Customer-supplier transaction represents a processing relationship within the project system.

The figure below illustrates the difference between reporting and processing relationships.  The vertical line, connecting you, your boss, and any subordinates you might have, represents reporting relationships.  The horizontal line, connecting you with your Customers and suppliers, represents processing relationships.

Your role in a line organization may be linked closely to a set of reporting relationships.  In contrast, the most effective project teams focus primarily on processing relationships.  In fact, process management as a means to address non-project related organizations is gaining momentum in many industries.  More and more organizations are replacing departments with cross-functional processes as the conduit through which decisions and actions take place.

To illustrate Customer/supplier relationships, consider the following:

A project leader has to make last minute travel arrangements to present a proposal to a potential Customer.

The Scope Summary might be:

“Make a successful presentation to Amtec, Inc. Directors tomorrow”.

Given this outcome, the following roles exist:

Project Customer: Amtec, Inc. Directors

Supplier: The manager

Product: A persuasive and informative presentation

The project leader prepared the proposal based on calculations and estimates from Design Engineering.

Thus, these roles also exist:

Internal Customer: the project leader

Supplier: Design Engineering

Product: Accurate calculations and estimates

As this simple project illustrates, both external and internal Customer/supplier transactions are vital to the success of a project.

To identify the supplier, product and Customer, use the following questions for each task in the plan:

1. Who does it (i.e., completes the step)? =  The Supplier
2. Who gets it (i.e., received the output of the step)? =  The Customer
3. What is it (i.e., the outcome of the step)? =  The Product/Service

Some examples of Customer/supplier relationships:

Customer:      Design Engineer

Supplier:        Programmer

Product:         Error-free code

 

Customer:      Accounting

Supplier:        Information Systems

Product:         Software

 

Customer:   Payroll Administration

Supplier:     Project Team members

Product:      Time Sheets

With these three questions, any project team can clearly define critical transactions within the project.

Just as important, any team member can use the mirror image of these questions to identify their own suppliers:

1. What do I (we) need to complete this activity or operation?
2. Who will provide it to me (us)?

By clarifying these Customer/supplier relationships up front, project team members can resolve potential confusion and conflict before it happens.  This helps the project team remain focused on the intended project outcome.