Vendor projects don't have to fail
Large organizations regularly have a need to implement major IT projects and often turn to external vendors for specialized expertise or additional capacity.
Unfortunately more often than not these IT projects fail and it is usually the vendor that gets blamed. But though there may be disreputable companies out there who are only out to make a fast buck, the vast majority of IT vendors are well-intentioned professionals trying to do the best for their clients.
Yet even with the best intentions in the world we still often get wasted time, money, and resources. Why is that? What can we do to fix it?
The problem arises from the competing accountability pathways between the client team and the vendor team. Their core motivations are slightly different and rather than try to pretend that isn't the case, the key to success is to ensure that the overall project is led by client resources and not vendor resources. This way we have the equal footing necessary for effective compromise to happen.
Let's go into this in a little more detail.
Profitability vs ROI
First off it does not take any great insight to realize that the root of the problem lies in the fact that scope changes throughout the course of the project. The vendor has been hired to solve a particular problem but when digging into things the initial problem definition inevitably morphs somewhat.
This is true of any project, whether entirely handled by an internal development team or outsourced to an external vendor. With an internal project there exist myriad project management and agile development techniques that can be used to address that issue.
However in the case of a vendor led project there is a unique dynamic at play that changes the calculus when dealing with this scope creep. We need to take a step back and look at the way the project is managed. Or more specifically how accountability flows up through the project.
Vendor and client personnel in general are ultimately accountable only to their own respective organizations. This means that the vendor team on the ground is accountable only indirectly to the client.
While the ultimate goal for the vendor is profitability, the client seeks to maximize their return on investment by solving the motivating problem of the project as cheaply as possible.
Both the client and the vendor want to have a successful project and in a perfect world that would be enough. However when compromise is necessary these slightly different motivations drive ever more divergent pathways as discussions over the actual utility of the solution devolve into discussions over contractual obligations.
Dedicated Project Leadership
So how do we solve this problem? How do we get the vendor and client team to get aligned?
The answer is we don't.
There is no ethical way that a vendor project manager can sacrifice the long term health of their business. Smart vendors will compromise, sometimes to their own short-term detriment in the service of the larger goal of long term success. But that is a cost benefit analysis that they need to do internally.
On the other side, the vendor's profitability is not the concern of the client. While it is good business to work harmoniously with your vendors and wish for their success, in the end this is about effectiveness not friendship.
The key insight is to realize that the ultimate measure of success for the client is the ultimate measure of success for the project. And as such the overall project accountability should trace up to the leadership of the client organization instead of the vendor's.
What that means in practice is that instead of relying on the vendor to lead the project the client must put in place their own dedicated project leadership.
In effect the the project is run by the client team with the vendor acting as the subject matter expert for their product or service.
Ideally the client team should have dedicated personnel for all business to technical interface roles (business analysts, trainers, helpdesk, etc) and have these interface teams work with vendor teams directly. But if that is not possible then at least the overall project leadership should be made up of dedicated client resources.
In this case the overall project manager should be a client resource but it is also beneficial to have someone on the client team who can act as a liaison to the vendor's technical resources by advocating for the client's position when technical decisions need to be made.
(This becomes more important the more customization is required of the core vendor product and is absolutely critical when dealing with a soup to nuts completely custom application development project)
These project leaders could be contractors or from a different vendor but the point is that the overall project leadership team should be beholden to client leadership and not to the vendor's leadership. This way they have no conflict of interest.
It is critical that the project manager be empowered with authority to make tactical decisions. It should be made clear that all communications must come through them, ie they are not merely the client representative but are truly leading the effort.
If they are merely a figurehead that can be routed around via backchannel communication between the vendor and client leadership then we are back where we started.
What this does is free up the the vendor team to advocate for their organization's best interest and the client team to advocate for their organization's best interest. Between the two lies the compromise that leads to success.
Final Thoughts
The real world of business is selfish but shouldn't be self-centered. Clients can promote successful outcomes by ensuring they have an advocate in a position of influence built into the project structure from the beginning.
