Managing Vendors

Tips and ideas for employees and managers who work with vendors

Skills Needed to Manage Vendors

Posted on | November 30, 2009 | No comments yet. Click to add yours or a question.

Skills Needed to Manage Vendors
Except for seasoned managers of outsourced programs and projects, many professionals who find themselves taking on this responsibility suddenly become aware of all the things they need to know and be good at doing. These are the lucky ones. Many struggle with the role, doing their best, but are unaware of all it takes to be successful in the long term. They end up working harder and often being frustrated and surprised by problems that arise, and things that do not go as expected.
In this post I continue to examine what it takes to be effective in managing vendors and, hopefully, find the role satisfying through being effective and influential. Hopefully this will be valuable for professionals about to be assigned to manage outsourcing, those who are already in the role and finding their way, and to more senior managers who are setting up those who will manage outsourced work.
________
Projects and programs can vary enormously in scope and scale. Both can be large enough to have an executive in charge, with multiple Vendor Managers responsible for single programs and projects, or components. Unless I indicate otherwise, I focus on the role of a Vendor Manager who is solely responsible for the day-to-day management of a single project or program.
In the previous post, I talked about differences between Project Managers and Program Managers. In this post, I bring those together and look at what they have in common when it comes to skills and expertise. And for this post, I have left out the stages of establishing an outsourced initiative, defining the work, and selecting a vendor. That is a whole extra dimension that I will talk about in other posts.
People chosen for the job of vendor manager are typically those who have been working on the specialized function that is being outsourced. This depth of knowledge of the subject is very important. They know the underlying subject matter, and the kind of results they are looking for. They may also have management experience – of internal teams, project management, budgets, quality, conducting meetings, planning and review. All of these are helpful in the outsourced management work.
But there are specific areas of expertise that come into play when outsourcing. Either they are unique to managing outsourcing, they take on much greater importance, or have to be applied differently. Let’s look at just a few of these, to highlight some differences.
If you are a vendor manager, assess which of these you feel that others would rate you as “Strong”, or which of these are areas where you need to build expertise:
• Communication – with people in other disciplines (specialist managers are often shielded from this)
• Relationship skills as an essential part of working with vendors and stakeholders. This involves a broad range of communication skills, problem-solving, leadership, accommodation, flexibility, support, understanding and more.
• Problem-solving against a contract-driven relationship, rather than with a team of colleagues
• Meeting skills – more formal requirements in outsourcing to set up agendas and required outcomes, then monitor and document decisions, resolutions, responsibilities and follow-up
• Industry knowledge and market economy – the context the vendor is working in, how to anticipate changes
• Cross-cultural communication, agreements, business processes with the “same company” underpinnings
• Negotiating across company boundaries, with “outsiders” and with a contractual baseline
• Risk management (internally and with vendor) – analyze, anticipate and balance risks and responses
• Quality control and management based on specified metrics and service levels, best practices
• Management with contractual authority versus line management
• Legal elements – Agreements, contracts, liability, intellectual property, assets ownership, international laws
• Documenting and reporting – results, changes, costs, meetings, agreements, problems and resolutions, lessons learned
• Financial skills, analyze and compare project budgets and costs
• Business basics to understand vendor business models and health
• Operational processes and procedures, including vendor structure and supply chain
• Working with multiple stakeholders inside own company and client organizations
• Partnering methods and requirements as a way of doing business with vendors
• Governance of outsourcing within the company, and how it works, from initial sourcing to executive review
These are just some of the areas of expertise for a manager of outsourced work. Assessing strengths and identifying areas to develop is just the start. The next step is to look at where and how to gain the knowledge and skills, and who can help in this. First, what does it look like when someone is strong in any of these areas? What do they do differently that reflects this strength? And how does their work benefit?
I am currently working on a more detailed checklist and assessment form outsourcing expertise, which I will post on the Think180 site, with a link in this blog. If you would like to be notified when it is available, please email me, or follow on Twitter.

Except for seasoned managers of outsourced programs and projects, many professionals who find themselves taking on this responsibility suddenly become aware of all the things they need to know and be good at doing. These are the lucky ones. Many struggle with the role, doing their best, but are unaware of all it takes to be successful in the long term. They end up working harder and often being frustrated and surprised by problems that arise, and things that do not go as expected.

In this post I continue to examine what it takes to be effective in managing vendors and, hopefully, find the role satisfying through being effective and influential. Hopefully this will be valuable for professionals about to be assigned to manage outsourcing, those who are already in the role and finding their way, and to more senior managers who are setting up those who will manage outsourced work.

________

Projects and programs can vary enormously in scope and scale. Both can be large enough to have an executive in charge, with multiple Vendor Managers responsible for single programs and projects, or components. Unless I indicate otherwise, I focus on the role of a Vendor Manager who is solely responsible for the day-to-day management of a single project or program.

In the previous post, I talked about differences between Project Managers and Program Managers. In this post, I bring those together and look at what they have in common when it comes to skills and expertise. And for this post, I have left out the stages of establishing an outsourced initiative, defining the work, and selecting a vendor. That is a whole extra dimension that I will talk about in other posts.

People chosen for the job of vendor manager are typically those who have been working on the specialized function that is being outsourced. This depth of knowledge of the subject is very important. They know the underlying subject matter, and the kind of results they are looking for. They may also have management experience – of internal teams, project management, budgets, quality, conducting meetings, planning and review. All of these are helpful in the outsourced management work.

But there are specific areas of expertise that come into play when outsourcing. Either they are unique to managing outsourcing, they take on much greater importance, or have to be applied differently. Let’s look at just a few of these drawn from our workshop, “Managing External Resources“, to highlight some differences. If you are a vendor manager, assess which of these you feel that others would rate you as “Strong”, or which of these are areas where you need to build expertise:

  • Communication – with people in other disciplines (specialist managers are often shielded from this)
  • Relationship skills as an essential part of working with vendors and stakeholders. This involves a broad range of communication skills, problem-solving, leadership, accommodation, flexibility, support, understanding and more.
  • Problem-solving against a contract-driven relationship, rather than with a team of colleagues
  • Meeting skills – more formal requirements in outsourcing to set up agendas and required outcomes, then monitor and document decisions, resolutions, responsibilities and follow-up
  • Industry knowledge and market economy – the context the vendor is working in, how to anticipate changes
  • Cross-cultural communication, agreements, business processes without the comfort of “same company” commonality
  • Negotiating across company boundaries, with “outsiders” and with a contractual baseline
  • Risk management (internally and with vendor) – analyze, anticipate and balance risks and responses
  • Quality control and management based on specified metrics and service levels, best practices
  • Management with contractual authority versus line management
  • Legal elements – Agreements, contracts, liability, intellectual property, assets ownership, international laws
  • Documenting and reporting – results, changes, costs, meetings, agreements, problems and resolutions, lessons learned
  • Financial skills, analyze and compare project budgets and costs
  • Business basics to understand vendor business models and health
  • Operational processes and procedures, including vendor structure and supply chain
  • Working with multiple stakeholders inside own company and client organizations
  • Partnering methods and requirements as a way of doing business with vendors
  • Governance of outsourcing within the company, and how it works, from initial sourcing to executive review

These are just some of the areas of expertise for a manager of outsourced work. Assessing strengths and identifying areas to develop is just the start. The next step is to look at where and how to gain the knowledge and skills, and who can help in this. First, what does it look like when someone is strong in any of these areas? What do they do differently that reflects this strength? And how does their work benefit?

I am currently working on a more detailed checklist and assessment form outsourcing expertise, which I will post on the Think180 site, with a link in this blog. If you would like to be notified when it is available, please email me (jgeverett@think180.com).

Category: Handling corrections and changes, Learn to manage vendorts, Managing projects, Metrics, Negotiating, Partnering, Program Manager skills, Project Leader skills, Service Levels, Training, communication
Tags: > > > > > > > > >

Program Vs Project Managers

Posted on | November 25, 2009 | 2 Comments

What is the difference between being an outsourced program manager and an outsourced project manager, and what is the right expertise to be effective in these roles?
In both cases, subject matter expertise can be an important knowledge base for the manager, on which to overlay the essential management skills.
Where a project or program has been outsourced, there is a different management approach and understanding needed. Even for an experienced manager, the differences between handling an externally resourced (vendor/provider) project or program, and one that is internally resourced (fellow employees), can take some adjustment.
Managing programs requires ongoing steering and maintenance of quality and service, as well as being aware of the ongoing needs of stakeholders. There is a need for analytical abilities, problem-solving and relationship skills, as well as understanding the needs and service experience for any recipients of the service. Program management typically lends itself more to partnering and collaboration, through joint reviews of processes and procedures, and ways to enhance ongoing delivery for quality and efficiency.
Managing projects is more about getting things done on time and according to a set plan, within budget, and meeting specifications. Key skills in project management include understanding project timelines and critical paths, resource management, and financial control, and monitoring events for potential causes of delay and cost overruns.
Different mindsets, different personality types for the two roles.
When the project or program is outsourced, then a separate set of skills and experience is required for the management of an established engagement (meaning that the vendor has been selected and started work). The vendor manager (for either a project or program) must be able to interpret and manage by written agreements rather than day-to day behaviors, and ensure results in what is delivered, not how it is done. This is the hardest shift in mindsets for professionals and experienced managers taking on outsourcing for the first time.
In upcoming posts, I will expand on these roles, and list the common and separate skills and expertise required.

What is the difference between being an outsourced program manager and an outsourced project manager, and what is the right expertise to be effective in these roles? Is there a difference in the type of person or management style that will make a person more suitable for one than the other?

Where a project or program has been outsourced, there is a different management approach and understanding needed than if that project or program was being kept in-house. Even for an experienced manager, the differences between handling an externally resourced (vendor/provider) project or program, and one that is internally resourced (fellow employees), can take some adjustment.

In both cases, subject matter expertise can be an important knowledge base for the manager, on which to overlay the essential management skills. It also puts the manager in a stronger position to provide direction, and ensure standards are met.

Managing programs requires ongoing steering and maintenance of quality and service, as well as being aware of the ongoing needs of stakeholders. There is a need for analytical abilities, problem-solving and relationship skills, as well as understanding the needs and service experience for any recipients of the service. Program management typically lends itself more to partnering and collaboration, through joint reviews of processes and procedures, and ways to enhance ongoing delivery for quality and efficiency.

Managing projects is more about getting things done on time and according to a set plan, within budget, and meeting specifications. A mindset of control is important. Key skills in project management include understanding project timelines and critical paths, resource management, and financial control, and monitoring events for potential causes of delay and cost overruns.

Different mindsets, different personality types for the two roles.

When the project or program is outsourced, then a separate set of skills and experience is required for the management of an established engagement (meaning that the vendor has been selected and started work). The vendor manager (for either a project or program) must be able to interpret and manage by written agreements rather than day-to day behaviors, and ensure results in what is delivered, not how it is done. This is the hardest shift in mindsets for professionals and experienced managers taking on outsourcing for the first time.

In upcoming posts, I will expand on these roles, and list the common and separate skills and expertise required.

Category: Assigning work, Defining the work, Handling corrections and changes, Managing projects, Negotiating, Partnering, Program Manager skills, Project Leader skills, Service Levels, communication
Tags: > > > > > > > > > > > >

Deceptive? Or just vague?

Posted on | November 20, 2009 | No comments yet. Click to add yours or a question.

This quick post is a suggestion for vendor sales persons working with IT Project Leaders. It is a simple way to build trust.

Professionals with scientific and technical training typically like to work with facts. This goes along with a more structured way of working (not necessarily inflexible, just structured).

A more traditional form of sales pitch tends to have a process that walks a prospect through a path of benefits, with a few leading questions. And a technical decision-maker is typically looking for facts, numbers and specifications.

When a sales presentation is high on hyperbole, and scarce on specifics, especially in response to a question, this may lead to mistrust, or at least doubt.

The dilemma is that facts and specs alone may not give the true picture. There may be new combinations of features or technologies whose benefits need to be explained in a specific order.

So a smart sales person will understand the thinking style and preferred way of operating with their client or prospect. And if this means a tightly structured meeting, with clear goals and agenda, then this how it needs to be.

And if the client is sharp and knowledgeable, then going through a labored presentation, with all the information and features, can turn them off.

If you are an IT Project Leader working with a vendor sales person or account manager, help them understand how you like to work, so they have the chance to demonstrate they know how to adapt to your needs.

Category: Think180
Tags: > > > >

What Do Your Metrics Measure?

Posted on | November 11, 2009 | No comments yet. Click to add yours or a question.

A recent experience I had as a consumer-level customer of a cable company prompted me to revisit the bigger issue of SLAs and metrics, both validity and reliability, in outsourced programs with customer service call centers.

First, here are two very important yet often or misunderstood definitions:

  • Validity is whether you are actually measuring what you think you are measuring.
  • Reliability is whether you are measuring it accurately.

My issue: I wanted to be sure and get the latest HD-DVR (Digital Video Recorder) for my home TV setup. Most of the units presently being installed were a two-year old model, with numerous stories in online forums about poor picture quality. I was told confidently by a Customer Service call center agent that all the local offices had the new units in stock, and I just had to ask for one.

But my visit to the local office was a different story. No new HD-DVR boxes, only the old ones. No idea when they would be available. So I took an old one. After hooking up the older model supplied, the picture was only fair quality. My previous (non-DVR) box had given a stellar picture.

So I called Customer Service again to find out how to get a new box. At the end of the call, my question had not been answered, although the agent had tried hard, and was friendly. In the absence of having the information I needed, she even made up an explanation. But by the end of the call, she could not tell me when or where I could get the newer unit.

It seemed that she had no access to any database or bulletin of information about the availability or performance of one of their key products, and could not tell me when they would be in. For me to obtain this product, I would have to go down to the local office and see if they were in stock. The agent was not able to give me the telephone number for this office, and the best she could do was send me a bulletin about availability. But she could only send this USPS, and these newer units typically fly off the shelves within hours.

During the call, the agent kept reminding me of her name. At the end of the call, she asked if there was anything else she could help me with. It wasn’t her fault, so I refrained from telling her that she had not helped me with anything in the first place. But, wait for this, she said that I would be getting a follow-up call, and that she would greatly appreciate if I could rate her service as a “10″. The first agent had also asked this.

Applying the definitions

On the question of validity, what would I be rating – friendliness (9), patience (9), effort (8), knowledgeability (2), initiative (3), solving my issue (0). Is my rating of her, or is it of the overall experience and resolution? So whatever the rating, it is hardly valid, since what is being measured is unclear.

On the question of reliability, whatever dimension or factor I was rating, the fact that she asked me (and others) to rate her a 10 must contaminate and skew the ratings. Since other agents from this company have also asked the same thing, this leads me to believe that it is a scripted request. Either that or the agents have tacitly developed a shared approach to get good ratings. And do the agents try hard to give the impression (or temporary illusion) to the customer that they have resolved the issue, so that the follow-up call will yield a “10″ rating? This makes the aggregated number highly unreliable as reported metric.

And if this customer service call center was an outsourced service provider, then the client was not gathering very good metrics against their SLAs. This is where I thought, “Hmm. If these agents work for a call center vendor, and the average ratings are what the vendor is being measured on against the SLAs, then this is hardly a valid or reliable metric.”

And the opportunity is lost to get an accurate picture of the customer experience, and improve processes (in this case a better knowledge base and bulletin system for agents). This is equally applicable whether the “customers” are consumers, or if the service is IT support for internal corporate employees.

So my point from this story is, if you are managing a vendor that interfaces with your customer, then make sure you know what is happening at the customer interface, and how the metrics are measured and gathered. Look at validity and reliability, how the metrics are measured, and if there are any factors and behaviors that contaminate the results.

Category: Call center, Contracts & Agreements, Metrics, Service Levels
Tags: > > > > > > > > >

Practical Terminating Factors

Posted on | October 23, 2009 | No comments yet. Click to add yours or a question.

Following the earlier post on Terminating Vendor Relationships, this post touches on operational issues, transitioning, and what makes a program different from a project.

_____________

Recent searches on this blog around terminating vendor relationships show this is a hot topic. Answers to questions about this depend on many aspects of the work, including the original agreement, reasons for terminating (project changes, client-side factors, or vendor performance), and the terms of the contract that spell out termination procedures.

Also, whether the engagement is a project or a program will have a large impact on how the vendor relationship, or work on this project/program, will be terminated.

So, we need to look at reasons, strategies, processes, risks and consequences. What has been included in the contract about obligations on both sides in the case of a termination? Are there clauses for a no-fault termination, and are there triggers if there is a performance issue (such as late deliverables, quality, or service levels not being met)?

The most straightforward (and possibly easiest) situation is where the termination has been anticipated (in the correct sense of this word, meaning preparatory plans made or steps taken in advance), and there is no fault on either side. Both client and vendor follow the procedures and steps agreed.

It may be that the work had a limited life and, while the exact timing was not known, both parties knew it was finite. This could be supporting a new product line that did not perform as well in the market as was hoped. Or, it could be that the product or initiative being supported was wildly successful and the scope of work grew beyond the capacity of the vendor to grow with it.

In another set of circumstances, a project may be canceled, or a program phased out. The vendor will no longer be needed on that. So for now, let’s assume that we are not redeploying the vendor on other programs or projects.

This is the time to be clear on the difference between projects and programs. A project typically has a finite timeline. It has specific completions and deliverables due by specified and agreed dates. There are also milestones and stages. Payment is structured against deliverables or completion of milestones. A program is typically ongoing and is measured by metrics and service levels.

In both cases, plans have to be made to either wrap up the work or transition to another vendor (or bring in-house). This means that for a project, progress will be halted, or completed to a point of legal obligation, or where it makes strategic/operational/financial sense. A program may have stakeholders (or recipients) and needs to be phased out so that there is minimal impact.

Alternatively, if a project or program is being assigned to another vendor, then a handoff needs to be planned to ensure an effective and smooth transition. Stakeholders may need to be involved. If the handover is harmonious, the job is a lot easier. The client has the leverage of payments for the project against the completion of milestones to the quality and time agreed, and for the program against the meeting of service levels and other metrics.

Key factors in a transition include the critical path and milestones (for projects), and how service levels are maintained (for programs). It may be possible for the incoming vendor to deploy additional resources to offset the loss of momentum and acquired knowledge. Or (if there is trust and a good relationship) the client may pay the outgoing vendor to train the new vendor.

Each situation is unique, and is handled differently. The primary concern for projects and programs that remain active is continuity, and keeping costs and losses within limits. Another key factor is ensuring the transition of capital assets and infrastructure. A less tangible asset is the knowledge and operational, process and product experience accumulated by the outgoing vendor.

Part of any process should be a detailed review of the terms of the agreement that remain in place after the termination. These will include reinforcing the non-disclosure clauses, use of intellectual property (this goes both ways), confidentiality of client data, non-compete clauses, any other residual obligations, or handling undisclosed or overlooked elements that may come to light at a later date (such as promises made to customers, or guarantees on applications developed but not fully deployed at the time of termination).

Category: Contracts & Agreements, Handling corrections and changes, Managing projects, Negotiating, Service Levels, Terminating vendors, Transition project or program
Tags: > > > > > > > > > > > > > > > > > >
keep looking »

About Think180

Think180 helps companies get the best results with their service providers (vendors). Our core product is an in-house customizable workshop for Delivery Managers, or entire teams who outsource. This has been run successfully for many clients, including Palm, Philips, Harrah's, BP, Vantive, Avaya and others.

Subscribe to this blog

Search

Email Author

Think180 Links

Archives