Hi, I'm Ray Sheen.
Let's talk now about actually using contractors and vendors on your project.
Contractors and vendors present some very serious project management challenges.
Many projects use contractors, vendors or suppliers,
to accomplish some of the project tasks.
They can be great help because of the extra resources or
expertise that they bring to the project, but they also have to be actively managed.
Selecting vendors for the project is often more difficult than selecting them for
a normal operation, because of the project environment.
Many times a project does not yet have a fixed specification for the goods or
services that are needed, so requirements are vague and changeable.
Of course, a project often only requires a small quantity of the goods or services.
So they have to be right on time the first time,
especially if the project is under time constraints.
This means that rapid vendor selection is a very important management decision.
The most common selection processes on projects are either a directed source.
Where a corporate relationship already exists with a preferred vendor,
selecting the low cost vendor who can meet the project schedule.
Or if it is a highly technical task, first screening possible vendors for their
technical capability, then selecting the low cost vendor who can meet the schedule.
Once we've selected the vendor or supplier, there are three types of
relationships that the project team can have with the vendor.
The first is appropriate for a supplier of commodity, goods or services, or
what is considered a commodity at least on this project.
In this case, we're purchasing something that's standard,
off the shelf commodity item.
There is nothing unique with respect to the project.
Project team's relationship with the vendor should be an arm's length
relationship.
There's no reason for the project team to directly interact with the vendor,
they have more important things to be doing.
Purchasing takes care of all the activities associated
with managing the vendor, because it's a commodity product.
The project team is just using whatever exists in the market with respect, for
feature quality levels, price, and lead times.
This is the easiest relationship for a project team and often for purchasing.
The second type of relationship is one where we do want something that is special
or unique for the project.
In this case, we're purchasing from the supplier a custom product, or
require a custom service.
However, we have a specification for what we want to purchase.
We can't leave this one entirely in the hands of purchasing.
The project team members will need to conduct periodic interaction with
the supplier, initially to answer questions about the specification.
But as time goes on, to monitor progress and ensure the supplier has interpreted
the specification correctly, and is meeting the desired performance level.
Purchasing is still in charge,
they're negotiating the contract within the project boundaries of price and
schedule and they are managing the various contractual terms and conditions.
However, the project team sets the required quality level and
the features, which are often unique and customized for the project.
When bidding, the supplier proposes a price and lead time,
then purchasing negotiates the best combination of those.
This time the project team does have regular interactions with the supplier,
but purchasing is still in the lead.
The really difficult relationship is what I call the design effort relationship.
In this case,
the project is purchasing something that is custom designed by the vendor.
The project doesn't know precisely what they're buying, but
they know what it is that they would like to do.
There are some requirements, but no detailed design specifications.
The vendor is the expert and the project is buying their expertise.
Project team members will need to have a significant level of involvement with
the vendor.
In fact, I prefer to have the team members lead this vendor
relationship with purchasing in a support role.
This is because there are numerous decisions and trade-offs to be made
throughout the project time while the vendor is doing their design work.
They need to be directly involved with the core team to ensure that their design
is compatible with project goals.
Purchasing should still do the negotiations. After all,
they're the organization's professional experts in that field.
However, this is often a difficult negotiation for
purchasing since there is no specification, and
even the scheduled dates may be negotiable portion of the contract.
Purchasing can only create a contract with general deliverables and conditions.
These will need to be refined during the execution of the project,
which will require continual interaction with the vendor.
In this case, the project team has general requirements for quality levels, features,
price, and lead time.
But all of those may be negotiable and it will ultimately come down to whether
the total solution created by the vendor can meet the project goals and objectives.
The seller proposes a solution and during the lifecycle of the project,
the deliverables are defined through negotiation.
This relationship is a very in depth interactive relationship for
the project team.
Once you've determined what you'll be purchasing from vendors,
then you can determine the appropriate relationship.
Then work with purchasing to manage your vendors effectively.