Skip to main content

From the Sponsor’s Desk – The Offshoring Challenge, Part 2

In my last post, The Offshoring Challenge, Part 1, we looked at a situation where a project manager with no prior experience in offshoring ran into serious trouble with the offshore developer. The project was delivered, but at double the original cost and significantly late and only after terminating the offshoring contract. We also looked at how a Great PM would have leveraged the Project Pre-Check fundamentals of stakeholders, defined processes and a best practice based decision framework to achieve great results.

In this post, we’ll look at the challenges a company faced when it chose to use an offshore developer to rebuild its core administrative systems. That’s why I call this post The Offshoring Challenge, Part 2.

The Situation

This organization provided a number of key administrative services to the domestic and international financial services communities including banks, trust companies, investment dealers and others. Their core administrative processes and systems were not able to address the clients’ growing demands for faster response times and improved and expanded services through online and internet based offerings.

The Goal

The company’s plan was to redevelop their core administrative processes and systems and leverage modern technologies to provide the most advanced services of their kind in the world. The company had a total of 400 employees and clearly lacked the capacity to handle the challenge ahead of it although it did have a wealth of expertise in the business and application architecture fronts. Consequently they sought an offshore development partner.

The Project

The organization created a steering committee to guide project progress. The steering committee was chaired by the CEO and included all VP’s from all the organizations affected by the planned change. A senior business executive was designated as sponsor and a consultant brought in by the business was appointed PM. A $20 million contract was negotiated with a software development vendor in India. The overall budget was established at $40 million.

The Results

The project was organized into five phases to be delivered over four years with the bulk of the work, and risk, in the last three phases. The first two phases were delivered largely on budget and plan. And then the fun began!

The Negatives:

  • The members of the steering committee had no formal roles on the project other than oversight and they took to that assignment with zeal, harpooning anyone whose performance may have been less than stellar. There was frequent finger pointing across the table — at the business, IT and vendor teams and their own members. Of course, those conflicts carried on outside the steering committee meetings and infected the business, IT and vendor team relationships as well. It was a caustic environment.
  • The designated sponsor wasn’t really the sponsor after all. He didn’t initiate the change. He didn’t have the economic, logistical or political power to make the change happen. In fact, he had no organizational role other than the project role. He could have acted as the project executive but instead tried to be the sponsor. Chaos reigned.
  • The designated PM turned out to be a consultant to the business and spent most of her time developing business specifications. The IT organization assigned senior staff to manage various development components but had no one in place to provide overall project management.

The Positives:

  • The offshore developer provided a senior project manager at the company’s site and another at their offshore location and the two controlled and coordinated all software development activity. That resulted in a very positive outcome and contributed significantly to the success that was achieved.
  • The designated business sponsor, IT development managers and the vendor PM had twice weekly conference calls with their counterparts offshore to review progress and resolve issues. In spite of the communication challenges and conflicts, the exercise worked well and was able to initiate remedial action and deliver results.
  • The in house software development methodology and existing processes for managing issues and changes were used effectively by all parties.
  • A risk plan was developed and updated periodically but was not integrated into an overall project plan. Consequently some key mitigation actions did not happen, causing schedule delays and resulting in incremental costs.

Significant quality issues started to emerge during the latter stages of phase 3 as well as  the concurrent early work on phase 4. The problems were traced to language issues, communication problems, lack of business understanding by the offshore development staff and lack of overall direction. Three major changes in the conduct of the project were instituted by the steering committee after consultation with senior vendor staff:

  • The offshore developer moved part of the development team to the client site. At one point over 100 developers were on site working hand in hand with the business staff and IT development staff.
  • There was a dramatic increase in the number of face to face meetings between the vendor’s senior staff and the company’s senior staff, in India and locally, to improve communications and foster better, faster decision making.
  • The designated sponsor was removed from the project and sponsorship accountability was placed in the hands of the CEO. A senior executive with in depth knowledge of the business and recent experience in a similar project was brought in to provide overall guidance.

The project was finally delivered successfully, a year later and over 50% more than originally budgeted. Ironically, at the end of the project, all parties involved in the undertaking were pleased with the results.

How a Great PM Would Have Helped

Even though no one had overall responsibility for managing the project until Phase 4, there were talented, knowledgeable and committed staff from the business, IT and the vendor who took a number of actions to help ensure some degree of success.

  • Senior management did a good job articulating their vision and ensuring that there were no other competing priorities to impede the progress on this mission critical venture. In hind sight, senior management also did a good job of selecting the offshore developer.
  • The business units affected contributed some of their key personnel to ensure the specs were done right and to confirm that the delivered components met their needs.
  • The IT managers involved ensured that a development methodology was in place and used consistently both locally and by the offshore developer. They also established the internal procedures for issue, change, risk and quality management as well as project control and communication.
  • The offshore developer provided talented leaders and took the appropriate actions when required to resolve the quality issues in phases 3 and 4.

A lot of good things were done on this project but with much gnashing of teeth and clenching of fists. A great PM could have made it a much more pleasant experience with improved performance in addition to facilitating the formation of a committed, collaborative and accountable stakeholder group to shape the delivered solution. A great PM would have ensured that each member of the stakeholder group understood the role they were playing (sponsor, change agent, target and champion) and the accountabilities that went with each role. In fact, that’s what actually happened when the senior executive was brought in as the project executive during phase 4.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a situation that I call Portfolio Management, the Bad. In this endeavor, the IT department took it upon themselves to implement a portfolio management solution to curb what they saw as excessive and conflicting business demands without engaging those same business units in the effort. The project was NOT a resounding success.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Don’t forget to leave your comments below.


Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at [email protected].

Comments (4)