What Makes Outsourcing Successful?

Outsourcing has been a hot topic for many years and much has been written about its pros and cons.  But what makes it successful?

Diane Frank of CIO recently wrote an article entitled “So You Inherited a Crummy Contract” and it made some excellent points.  Using experts (how could I disagree), realigning expectations (always an issue), implementing neutral governance (interesting???) and putting staff skin in th game (a gigantic problem).  But it also got me to thinking; What Makes For a Successful Outsourcing Relationship?

I’ve been involved in outsourced relationships dating back to Regan’s first term in the early ’80’s and I’ve seen great successes and unbelievable failures in both the public and private sectors.  My conclusion from all this is that the key to success or failure is in the “relationship”.

In a successful relationship there is mutual respect and trust between the outsourcer and their client.  This is difficult to achieve since most of the “Joe the Plumbers” view outsourcing in terms of either lost jobs or being unceremoniously transferred to work for a new company that they didn’t select.  Clearly there is some truth to both perspectives and it typically can take sometime for employees who remain with the client and those transferred to rebuild an atmosphere of trust.  Understanding this issue and taking steps to address it will typically fall to the CIO.

An approach, which seemed to work, was to make the simple statement that it didn’t matter who paid you, we all worked for the same customer.  It was then paramount to “walk the walk” everyday and deal identically and fairly with everyone.  In most cases, this open and collaborative style worked wonders.

Where this didn’t work, and not surprisingly it was in a public sectors environment where the concept of customer didn’t exist, was a situation where the relationship was driven by the “contract”.  The people involved were proud of the performance based contract they had written and felt their sole responsibility was to administer the contract.  There was no understanding of the views and concerns of the outsourcer and no concept that a relationship based upon mutual respect and trust was a two way street.

As a result of not working to develop this relationship, and both parties were equally responsible, an antagonistic relationship developed.  The outsourcer didn’t trust their client and felt they were constantly looking for ways to argue that a service they wanted was “free” or somehow covered in some arcane way by the contract.  The client felt that the outsourcer was constantly looking for way to “stick it to them”.  What made this situation almost comical was that planned spending levels for IT services under the contract were being under spent by millions of dollars.

Relationship is key.  Critically important to developing a productive relationship is deciding exactly  what kind of relationship is desired by the parties.  “Success” will be determined by how these expectations are either met or not met.  Also, over the term of the agreement these expectations can and will change making flexibility another key success factor.

Outsourcing can and does work and like all relationships: it is not an event, but a journey.

So if you’ve inherited a crummy outsourcing contract or if your entering into a new contract, make the development of the relationship based upon mutual respect and trust a top priority.  This means that both parties listen to and understand the other parties perspective.  As a Gartner consultant who worked for me once noted, if you want the outsourcer to perform a certain task “free”, it ain’t going to happen.  Consider bringing in a facilitator (i.e., neutral governance) if the relationship you want isn’t happening.

William A. Crowell, Principal

Magellan Associates, LLC

www.magellan-associates.com

CIO Perspective – Managing Complex Projects

Managing Complex Projects

I’ve been giving some thought to what I can offer from my 38 years of experience in IT starting as a consultant in an operations research firm and rising to the CIO position in both private and public sector organizations. What struck me was the continuing failure of highly complex systems projects even though we have invested millions in training project managers through such organizations as the Project Management Institute (PMI – http://www.pmi.org/). Michael Krigsman, a well respected expert in studying IT project failures, noted in recent blog (http://blogs.zdnet.com/projectfailures/?p-4967) that CRM projects have failed from a low of 18% in 2005 to 70% in 2002 and most recently was 47% in 2009. Why is this happening and what is failure?

Let’s take the latter issue first. Failure can be defined along several dimensions. Clearly a project started and then closed before delivering an operational systems is a failure. Significant cost or schedule overruns or systems that do not deliver the expected benefits can also be classified as failures or partial failures. Failures are all to familiar and I have seen a number of them during my career. For example, when I was the CIO of a medium sized mid-western publisher I inherited a book order fulfillment system project that meet all the above criteria. It was over budget, behind schedule and lacked the functionality the business required. It was also a technical disaster. The firm had contracted with a vendor whose application ran on one vendor’s hardware and wanted it to be converted to another vendor’s hardware, a much more complex and high risk endeavor than expected.

As we consider our options I noted that the company had contracted for a multi million dollar system for the book group that had sales of approximately $30.0 million, or about 3% of the firms overall sales. That didn’t seem to make sense. Were there lower cost and less complex commercial systems that would meet the businesses needs. The answer was yes, so we canceled the existing effort and had the lower cost system implemented within six months. The strategic error, which Michael discusses in his article referenced above, was an inappropriate IT strategy given the small size and lack of business complexity of the unit.

A certified PMI project manager would most likely have missed this key issue although they might have spotted the complex and high risk IT strategy being implemented. However, the fact is most project failures occur based on poor strategies (technical and business), conflicting goals, and lack of management/user support or even more important their active involvement in the project.

Additionally, I have encountered countless “bad contracts” especially in the public sector that lack the flexibility to adjust to changing situations. PMI’s Project Management Body of Knowledge (PMBOK Guide) notes that project requirements tend to become more clear as a projects progresses through the life cycle. Yet most contracts for new systems are pursued as fixed price/schedule efforts that are inconsistent with the above reality. I’ve learned that there needs to be a clause in contracts that allow the organization and its contractors to periodically review requirements, cost and schedules to see if resets are appropriate.

So why do so many projects continue to end in failure? It’s not a lack of project management tools, techniques, processes or procedures which are well documented in PMI’s PMBOK. It’s the lack of the latter skill “management” at all levels that contribute to failure. Although my experience is anecdotal and not scientific, as I look back over a long career, when there was good to great managers involved projects were amazingly successful and when poor or inexperienced managers were at the core of the initiative catastrophes were the end result.

In college, I learned that management involved planning, organizing, staffing directing and controlling the thing(s) that one was involved in managing. Applying these basic functions and the principles that underly them, I was successful in managing any number of highly complex projects early in my career before project management was a recognized field and way before a PMI and PMBOK existed. I’ll be focusing on management as it related to complex projects in future blogs on this topic.

Hello world!

This is my first entry directly into the blogging world.  I’ve been posting blogs on CIO Magazines’s site for a long time but never blogged directly to the web.  I’ll be transferring some of my blogs from CIO.com and blogging here in the future.

Some background on me!

William A. Crowell is a Principal with Magellan Associates and rejoined the firm in March of 2008. Bill’s primary areas of interest are strategic planning, organizational development, project planning, project health assessments, outsourcing, and open source technologies.

His career in Information Technology spans over 35 years and has included serving as CIO of San Diego County, California; CIO of the Department of Human Services in Oregon, CIO of Teva Pharmaceuticals, and CIO of Meredith Corporation.

He has extensive experience in both the private and public sectors and has served in key executive positions within Federal, State and Local governments. His career also spans multiple industries and includes international as well as domestic experience. Bill enjoys sharing his view on technology and how it can be applied by today’s organizations and writes on these topics for CIO Magazine’s web site www.cio.com.