Abstract

This article describes a real-world e-business project scenario in which solid and favorable contractual documents became ineffective when, due to a hidden agenda, the sponsor was reluctant to allow them to be enforced. When a vendor refused to honor the agreed-upon project scope and engagement management process, the project manager believed that he had a strong statement of work and contract on which to rely. But the sponsor's reluctance to enforce them to full effect for fear of jeopardizing a hidden agenda prevented the project manager from leveraging them to protect the project and project team.

This case study reviews the origins of the vendor issues, offers some historical context, and then provides a narrative of the progress and escalation of the vendor problems and how the hidden agenda influenced them and hindered the project manager's ability to use the vendor management plan and contract documents. The paper concludes with some key lessons learned from the experience.

A History Lesson

When I joined the organization in which this saga unfolded, one of the first things I learned was that the IT department had a poor track record with outsourced custom development projects. In fact, much about the department was defined by a massive and expensive outsourcing failure dating back to the end of the dot-com era.

One of the primary reasons I had been hired was to run a large e-business website upgrade project that the IT department had been wanting to do for several years, for technical and support reasons and in order that it could offer more options to the business in the area of e-commerce and marketing. As a professional project manager with an excellent resume and solid track record of success in managing external vendors on custom projects, I felt confident that the project that I was to lead, which would be highly dependent on an external vendor, would avoid the past pitfalls that the department's other vendor-driven other projects had fallen into.

I reviewed the history associated with this massive, expensive outsourcing failure and learned what I could about it through informal sources, since very little about it could be found in formal project documentation, given the time that had passed. Again, since this failure had both spawned and killed careers as well as shaped policy at this company and particularly within the IT department, anecdotal information was easy to obtain.

A few weeks after I started, and had led vendor identification and request for proposal activities, the project was proposed (for the fourth or fifth time) to the executive leadership team. The assignment of a professional project manager as well as strong vendor management, vendor contracts and statements of work were presented as reasons why the project would be successful and deserving of approval to proceed. Further support was provided by our legal department's review and blessing of the contractual documents prior to sign-off by our CEO.

Not Doomed to Repeat History

As a student of history as well as a project management practitioner, I firmly believe in the saying that those who fail to learn from history are doomed to repeat it. As I drew from this organization's past failures with vendor-driven projects as well as from my own experience and knowledge, one of the steps we took to protect the project and the company was to develop a strong and detailed statement of work. We carefully defined areas over which we would have control and final approval, defined in detail every aspect of every deliverable, and ensured that the outsourced scope was divided into logical and relatively small milestones, which could not be started or completed by the vendor without written approval from the project manager. These important details would become critical later, when the project and the relationship went awry.

We incorporated all of this detail and definition into the statement of work as negotiations on cost and other aspects of the project proceeded. The vendor accepted these items into the SOW seemingly with a positive attitude, welcoming the unambiguous definitions within which we would all work together. From my company's perspective, and particularly within the project team, we were pleased and felt that we were on the same page with regard to expectations and definitions. When signatures on master agreements, statements of work, and work authorizations were obtained and the project kicked off, it seemed our vendor was ready to partner with us and truly understood our need for quality and close adherence to our existing business rules. However, one of the critical issues that we came to learn later was that the sales team responsible for working out the terms and conditions would not have much influence in getting their firm to honor them when the project was underway.

Early Signs of Trouble

Early in the project's life cycle, we encountered our first problem with the vendor. The first sets of test cases were due and delivered within a few weeks of the project's kickoff meeting. The project called for comprehensive and rigorous testing of the deliverables through the use of various system and functional tests. Due to the complex functionality, integration, and business rules of the existing website, these test cases needed to meet rigorous standards, and so we had carefully defined our right of approval of nearly every aspect of the test cases, including final approval of format and content. Also, there were to be many test cases—in the end, over 1,000 cases were identified. The outsourced scope called for the external vendor to develop this comprehensive and detailed set of test cases and to submit them to our team for review and comment before obtaining final approval. The project statement of work called for our team to define and approve the scope, format, and number of test cases as well as to review and approve the test cases.

Because these test cases would be critical to ensuring that the vendor delivered fully functional software, the testing lead on my project team was adamant that they fully cover each step in the business process or function they were to test. The first group of test cases that were provided for the team's review did not meet my team's criteria in terms of accuracy and detail, and sparked concern within the team. We spoke with the vendor's project manager to express our concern and immediately met with strong resistance to meeting the terms of the contract.

In essence, the vendor project manager stated that they had developed the test cases according to their standard process and that complying with our requirements would be considered a change request and would increase costs and extend the schedule. This incident was an early sign of trouble and occurred just a couple of weeks into the project. It was an event that came to define the project throughout its difficult life cycle. Discussions rapidly became negotiations and escalations to the next level of management, and progress on the test case development slowed and quickly fell behind schedule.

Emergence of a Hidden Agenda

The trouble with the vendor and their constant pushback on the test case requirements in the statement of work became a matter of such concern that, during a solution brainstorming session, one of the options put forth was to terminate the contract now rather than experience similar difficulties throughout the entire project. The testing lead, technical lead. and I all legitimately felt that that the vendor's approach to this issue would define their approach to every disagreement within the project. With so many business rules and complex functionality in place on the current website that had to be reproduced exactly in the new site, the opportunities for disagreement would be many.

The more practical option we settled on was to push hard on the vendor to honor the statement of work, or provoke a clear statement of their intent to disregard the agreement such that we could engage our legal team to enforce it or confirm that it had been breached, in order that we could take appropriate action. As called for in the vendor management plan I had developed, this situation was escalated to the next level of management within my department as well as with the vendor's management. It was my escalation of the issue that revealed a hidden agenda that would hinder the project team's ability to leverage the strong statement of work.

Because of the IT department's track record of difficulty with external development projects involving vendors, the key sponsor had put a lot of stake and credibility in proving the IT department's ability to successfully manage and work with a vendor on this particular project. In essence, the sponsor had sold the executive leadership on his and my ability to manage a vendor effectively on this critical project. The hidden agenda within this project was to disprove the opinion held by the senior leadership team that the IT department could not manage vendors effectively. Any hint of difficulty rising to senior executives would put this agenda at risk. Because of this hidden agenda, the possibility of resolving current and future issues with the vendor by enforcing the statement of work through escalation and forcing the vendor to disclose its intent to honor or disregard the statement of work was essentially taken away from the project team. This severely constrained my ability to use the statement of work and require the vendor to honor it or state that they would not do so and thus have legal recourse.

A Need for and Lack of Courage

Much has been written and said about the need for leaders, particularly project managers, to have and demonstrate courage when dealing with situations where the best and right course of action will be unpopular and may involve undesirable short-term consequences to those recommending or delivering the bad news. Unfortunately, circumstances caused me to approach this situation with less courage than it called for.

Relatively new in the company and still developing relationships with managers and stakeholders, I lacked the confidence and job security to pursue the right course of action, which should have been to call a halt to the project and insist that the vendor either honor the letter of the contractual agreements or declare them in breach of the contract. Wanting to present the situation accurately but without overstating it, I offset the project team's rising concern and problems with the vendor by communicating with equal weight the progress of the efforts to work through the situations that were beginning to become weekly and sometimes daily occurrences.

The key sponsor, with the hidden agenda of proving that an external development project could be successfully managed by our department, was reluctant to absorb and believe that the vendor's delivery team, with sanction from their director level, was actively disregarding the contract as well as misrepresenting project status. He was even more reluctant to contemplate the idea of communicating this information upwards as a risk to the project's success. Each time I would report on the problems we were encountering and the worsening relationship, I was told to continue to try to find a way to work things out and to reinforce our expectation that the vendor would deliver the project on time and within budget.

In the meantime, I had tried to make some progress on the issue within the vendor's organization by engaging their sales team. During the negotiations, the vendor's sales team had impressed me as one of the best and most professional I had ever worked with. But during the project's execution phase, the visits and platitudes from the vendor's earnest (but apparently powerless) sales representative and sales management helped to allay some of the sponsor's concerns, but far fewer of my own. It became evident that the sales area had little influence within the vendor's organizational structure in comparison with the project delivery area.

A Pragmatic Strategy

In the midst of the early problems, my boss, who had been absent throughout most of the kick-off phase on personal leave (and ultimately left a few weeks later), listened to my presentation of the situation and the options (including the option of firing the vendor) developed by the team, and offered a pragmatic strategy. He reminded me that our main reason for hiring an external firm was to gain specific platform expertise and assistance, not to develop test cases. His opinion was that as long as progress was made on the development of the code and platform, the test cases were of lesser importance.

Together, we reviewed the payment milestones and determined that, due to the strong contract language and the careful breakout and approval process for the milestones, we were in a strong strategic position to move the project forward to obtain the deliverables of strategic interest while containing the project's and our company's financial exposure in the event that we or the vendor should choose to terminate the contract. With this in mind, I continued to work to try to resolve the ongoing test case issue as well as new issues that continued to surface within the project, as we pressed forward with the design and development of various business requirements and functionality. Pursuing the dual strategies of moving the project forward to obtain key code and platform deliverables while continuing to negotiate on specific contractual and requirements issues began to cause morale and motivation problems within the project team, and on me as the project manager.

The Beginning of the End

At 5 months into the project's execution phase, the situation rapidly began to go from bad to worse. This condition accelerated when the latest of several contentions from the vendor that an in-scope feature was in fact out of scope had to be escalated to the key sponsor. Throughout the project's life cycle, the vendor's project manager had developed a reputation with our team for peremptorily declaring that many of our documented requirements for design and functionality were out of scope. In this latest case, the feature that the vendor's project manager decided to call out of scope had major implications for cost, schedule, and internal customer satisfaction.

I convinced the sponsor to join me and other key members of our team on a conference call with the vendor's project manager, sales director, and testing lead. For the first time, the project sponsor personally experienced the brusque communication style and attitude of the vendor's project manager as well as the vendor's overall strategy of ignoring the project's defined scope and the specifics of the contract. The first signs of understanding and concern began to appear in my conversations with the sponsor.

Despite the escalating situation, the sponsor continued to stress that the objective of making this relationship work was critical to our executives' perception of the project's success. This hidden agenda of proving that we could successfully manage and deliver the vendor-driven project influenced all negotiations and discussions with the vendor, and helped to create a false sense that the project would ultimately be delivered to everyone's mutual benefit. This impression was reinforced by the vendor's sales executive, who consistently supported continued discussions that created a false sense of progress. He moved the discussions away from the specifics of the contract and whether his firm intended to live up to it, instead focusing on how the relationship could be preserved and the project saved.

The Break-Up

As with romantic relationships, there comes a defining moment in a troubled vendor relationship when you know it's over. One or the other party commits a transgression so egregious that the injured party realizes that it's time to end the engagement. Up to this point you've been forgiving the insults and trying to make things work. I had endured the ongoing problems with the vendor's project manager and his tendency to override the specifics of the contract early and often, and I began to accept that we would terminate the relationship long before the sponsor came to the same realization. It took an onsite personal encounter with the vendor's senior management to push the sponsor to the same conclusion I had reached.

When it became clearer that the project's health and status was critical and declining, the sponsor and I flew to the vendor's headquarters to meet with the sales and delivery executives to talk about our latest major problems. My sponsor believed that he had a solid agenda and plan for the discussions. His plans focused on reinforcing why we had hired them and what we expected them to deliver, and he was confident that we would emerge from the onsite meetings with the relationship intact and strengthened and the project back on track. During the first hour of the meeting, the vendor surprised us both. The vendor had adopted a new strategy: they claimed that literally half of the project scope and deliverables we had jointly defined and agreed to was now out of scope, and further claimed that they had actually believed this all along and this was why they had behaved as they had.

The vendor's new position was beyond outrageous, and the documentation proved it. More importantly, this finally convinced the sponsor that there was no saving the relationship and that, although some final steps and good faith efforts would have to be taken before terminating the contract, the relationship with this vendor was in fact unsalvageable. After some good-faith efforts intended to better define the size and impact of the “misunderstanding,” we brought our legal team into the discussions and determined to exercise our right to terminate the contract. At this point, the strong statement of work and contract we worked so hard to develop during the initiating phase of the project finally had the effect that it should have had much earlier. It enabled our firm to clearly define what we owned and what we owed, and protected us from the vendor's claims that it was entitled to far more compensation and that we did not own key deliverables.

Hindsight, Outcomes, and Lessons Learned

There are many important items within this real-world project management scenario that offer lessons for all project managers when working with their sponsors, developing and negotiating contracts, and managing vendors.

Sponsor Willingness to Enforce the Contract

From the outset, I should have asked specifically about my sponsor's willingness to enforce the strong and favorable contract that we had negotiated. I had assumed that since we went to the effort of negotiating it and having legal review and approval of the contract, that enforcing it was a given. It was an inaccurate assumption, and on future projects I will be careful to understand how far a sponsor is willing to go to enforce a contract.

Signals of Future Behavior

With the benefit of hindsight, the vendor's refusal to honor the contract with regard to the test cases should have been a major signal that they would fight anything that would impact their profit margins. I recognized this immediately, but I should have put more urgency behind my communications given my personal experience with consulting projects and profit margins. I should have used my experience to point out the ramifications of the vendor's actions early on. We should have dug our heels in and fought out the first battle until the vendor agreed to honor the contract terms, or until we gave up and fired them. Due to the hidden agenda as well as my lack of tenure with the company, I did not believe that I was able to do this..

One Strategy that Worked

Some favorable outcomes did result from the way that we handled the situation. Because we had so carefully defined the project's milestones and deliverables, and because we had put in place requirements for signatures on documents authorizing work to start on each deliverable as well as for acceptance of each deliverable, the strategy advocated by my then-boss did work in the long term: We gained and paid for the deliverables for which we had actually hired the vendor while gaining knowledge and experience ourselves that helped make us successful when things did not work out with the vendor.

A Favorable Long-Term Outcome

Although my sponsor did not achieve the hidden agenda of proving that we could successfully manage an outsourced development project, we did prove something that is perhaps more important in the long term: that we had the knowledge and experience to develop and execute a solid vendor management plan as well as develop and execute project procurement management practices that ultimately protected the company and enabled us to take the project on ourselves.

Although it took another 14 months and 15,000 hours, the project team redeveloped the entire e-commerce website itself and successfully delivered a platform for future e-commerce growth and enhancements for the business.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Related Content

By Waity, C. J. Ore deposits are hardly the only factor project leaders use to determine future mining sites in Latin America. Everything from geopolitical turmoil to local labor markets can impact a mining…

By Wenger, Fred Project managers are accustomed to looking outside their projects for risks—at competitors, clients, suppliers, the economy, even the weather. But experience has taught me that all projects face a…

By Ali, Ambreen The collapse of a prefabricated bridge in March in Miami, Florida, USA killed six people and made national headlines. It also reignited a discussion of whether modular makes sense in large-scale…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.