We are starting a project where an outside vendor is involved. That vendor will be installing the "system." As such, they are going to be providing a schedule, etc... for the project. It was agreed to, that our organization will also be providing a project manager that will work closely with that project manager, and coordinate the efforts of the organization to ensure everything is being done to make the implementation a success. I am going to be that person.
Has anyone dealt with a situation like this before?
Yes, this is a common practice here. I suggest that you establish clear lines of communication and that both of you know what limits there are on your authority to make changes etc. The biggest problem I had in the last project was getting the vendor to meet their milestones with viable product. Saving Changes...
Bill CottunGoverment Services Manager| Entara Management ServicesLouisville, Ky, United States
There seems to be an unstated question regarding multiple projects mangers which is “who is boss when there is more than one project manger.
From a pragmatic perspective, the pm for whom ever is paying the bills is boss; as that pm approves the project invoices. Also from a pragmatic perspective, projects that are well planned have a higher probability of being well executed, regardless of the number of project mangers.
That said, it has been my experience that on large projects there is rarely just one project manager. If the roles and responsibilities of each pm are well defined in the project plan the project generally progress well. On projects where the roles and responsibilities of each pm are not well defined in the project plan, those projects rarely progress well.
Good planning helps address potential areas of conflict ahead of time. Good planning does not guarantee the project will not have conflict between project managers, but it does provide for a higher probability of successful conflict resolution through a well defined escalation path.
If there is more than one project manager on a project, there is a high probability that there is one or more contracts associated with the project. If you are one of the project managers, be sure to do an independent and thorough analysis of all contract related documents so you personally understand who is to do what when. It can be laborious, time consuming and at first you may not consider yourself to be qualified to do such an analysis, but if you do not know what your contractual obligation is, you will not know what you are legally responsible for.
The answer to your unstated question is you are the boss for that portion of the project for which you, your company and/or client are legally responsible. Make sure your role and responsibilities are well defined in the project plan, even if the other project manager roles and responsibilities are not.
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Anonymous,
Interesting post and replies. And, I agree with the comments offered. We see quite a few PMOs seeking to approach this kind of a project effort in which there often are multiple sub-projects that each have or could have their own project manager, sometimes internal and sometimes vendor, as a program. This is beneficial for a number of reasons but three come to mind quickly:
This provides an overall program owner that at the end of the day is accountable for the success of the business initiative - the program and all of the projects of the program.
This helps to clearly distinguish roles and responsibilities between the program manager and the project manager(s).
This also sets an expectation of what the program manager is there to do, ie. dual project managers really make no sense at all. And, the company project manager overseeing the vendor project manager has a much more to do than to just check up on the vendor project manager and likely needs to be enabled with the authority to act as a program manager internally and in the eyes of the vendor.
Of course, PMI has a program management standard, the PgMP, and more and more organizations are seeking to implement the best practices of that standard, certify their program managers, and manage business initiatives that used to be viewed as big projects with sub-projects as a program. To me, this makes sense for no other reason than to have one person that is empowered to manage the program and accountable for its success.
Great post..! I hope we hear and learn from others..!
Saving Changes...
Paul HuardProject Manager| Hana Ventures LLCPalo Alto, Ca, United States
Too often, these engagements start with vague or high-level statements of work, so if it is not too late, detail out the statement of work. Be sure to have everything thought through, written down, communicated and signed off by both sides.
Vendors need to pay for their resources and maximize their revenue, so expect expensive change orders if there are even minor changes.
Include all those PMP docs:
Project plan (wbs, schedule, milestones, etc.)
Resource plan, especially what types of resources the vendor will supply
ask to review and have approval authority for vendor-provided resources
Quality/Acceptance plan
testing and acceptance criteria for milestones
make sure your QA resources are ready for early milestones and maybe helping you with defining the acceptance criteria even now.
ensure you, as PM, have approval authority
Risk Plan
what if x occurs?
penalties if your/their deliverable is late?
if you're late they may claim a change order because their resources must stay on the project longer.
Communications Plan
especially important because internal communications may already be somewhat standard, but standards for you and your vendor may not exist
separate mailing lists for your team and your team + vendor, because you may not want to communicate everything to the vendor
Procurement plan
very important and should be tied to accepted milestones
DO NOT PAY until they are 100% done with a milestone
Finally, ask around to see if anyone has used this vendor before. I had one vendor that I was immediately suspicious of, so I asked around and found out they were terrible. They wanted to install brand new call center software using the same servers the current call center was running on. I told management the risks were too great and asked that the project be cancelled unless the current system was left in place as a fallback. The vendor provided loaner servers so we went forward. The new system went live, crashed in 3 hours and thankfully we were able to switch back to the old system in minutes. The vendor tried to bring the system live 4 more times over the following 3 weeks and it continued to crash and we continued to fall back to the old system. If we hadn't kept the old system I guarantee it would not have been pleasant for me :-)
On the other hand, I've worked with excellent vendors, but the stories aren't as good.
Paul's post is excellent. I would add one more important thing to this though.
Scope Management Plan.
Too many times when you have an external vendor and the contract type is a time and materials one. The scope of the project keeps changing or creeping. The scope management has to be the resposibility of the internal project manager. Saving Changes...
Anonymous
Hi,
I am in this situation and the vendor is not meeting milestone and I have the feeling to be in a never-ending project. What would you recommend to resolve the conflict? Saving Changes...
Robert ProlProject Manager| KPMG LLPEast Sandwich, Ma, United States
Most things with two heads are referred to as monsters.
I've completed many projects in this environment, and have found that the best way to ensure success is to clearly state that the vendor relationship is a vendor relationship. So the company paying the bills must own the project manager. The vendor project manager manages the project as it is defined by the vendor, but you as the project manager for the organization paying the bill manages the overall project - or program, depending on the overall span.
If you look at the five phases of project management as defined by PMI, your phases reach farther than theirs. The vendor was probably hired either in your planning or executing phase, and this in turn places their project in subordination to yours.
If you don't spend the time up front defining the relationship (as others noted), you will pay later. Saving Changes...
The concept of an "owner's project manager" and a "contractor's project manager" is very, very common in the construction industry. The contractor has a PM to oversee his or her work, while the building owner has a project manager who oversees the contractor's work and any additional issues that are special for the owner. The owner's PM might coordinate the move-in of tenants, for instance, while the contractor has no responsibility for those issues.
Usually the owner controls the contractor's performance by payments. Payments are often made only if certain milestones are reached. Sometimes there are penalties or incentives based on schedule performance. Any type of pay-for-performance arrangement will help.
Whenever I hear about a "never ending project" the payment relationship with the vendor is almost always time-and-materials (typically per-hour consulting fees). The vendor does not have a financial incentive to complete the work, because then the job will end.
I have sometimes had to end vendor relationships because of these issues. Sometimes the vendor is simply incapable of finishing the job. If so, then you want to get a new vendor as soon as possible. Other times it has been possible to re-negotiate contract terms, to set a clear end-date and some performance-based payment milestones.
Occasionally we have withheld payment due to non-performance on the contract, even in situations where the contract was strictly per-hour rates. Doing so can be tricky and can cause your own company problems and legal liabilities. Be careful about withholding payments, and speak to your lawyers before doing so.
If the vendor is clearly not performing the work you paid them to do, though, you want to change the situation immediately. Do not let the problem get any worse. Have a meeting where you are frank about your concerns, and start figuring out your list of options. Saving Changes...
Robert BerlinProject/Process Management Consultant| Clover Consulting IncHartland, MI, United States
I have been involved with several projects having two project managers. In all instances, I served as the Technical Project Manager and partnered with a Business Project Manager. We both reported to the Project's Steering Committee.
The key I found to managing this relationship between the project managers is to clearly define the areas of responsibility between the two positions. This also needs to be clearly understood and supported by the Project Sponsor and the Project Steering Committee. Once the accountability and responsibilties are established, published, and accepted by the project governing bodies, the project went well with the dual project managers.
Saving Changes...
Mark HipwellSr. Project Manager| Jaguar Land RoverAshby De La Zouch, Leicestershire, United Kingdom
The key thing to do is to get each 'project manager' to write down what they think are the goals and objectives of the project. Variation in the answers almost always means that there are two projects going on that are inter-related.
A good approach is to define one as a work package (for example, a technology work package) with an associated Work Package Manager, and the other as the 'parent' project.
Quite often the Work Package may require more effort than the Parent project, but that doesn't detract from the fact that the effort is in support of some other activity or goal. Were that other activity or goal not taking place, the work package activity would not be being undertaken.
In a RACI chart of the parent project, the parent project manager would be Accountable, the Work Package Manager would be Responsible.
In the RACI chart for the Work Package, the Work Package Manager would be Accountable, the parent project manager would be Consulted.
The point to note is that the work package is only a work package to the project manager. To the person managing the work package it is a project. Saving Changes...
