Wednesday, December 7, 2011

Vested Outsourcing - An Implementation


In March of this year I wrote a post about Vested Outsourcing principles, since that time I have been able to implement these concepts into a major IT Development outsourcing deal.  In this engagement, I have been fortunate in that the client is very interested in creating a true partnership with a sourcing company.  This partnership is based on creating additional value for their company not simply offshoring work to save money.  This is not to say that saving money was not important but it was not the overriding concern.

Lessons Learned

In this post I will outline how we created a vested arrangement; that is how we put the five principles of vested outsourcing into practice; ultimately creating a win-win for both parties.  Before I describe how we went about this, I want to articulate some of the advantages and lessons learned during this journey:
  • Starts Early - Creating a vested deal and building a true partnership starts early in the process.  We started the RFI/RFP process with partnerships in mind.  This meant being cognizant of the candidate partner's costs of sales up front.  We weeded out candidates before the cost of sales became high.  We kept the lines of communication open and created a transparent/open process that was fair to all participants.
  • Why are we Doing This Again ... -  Establish clear achievable goals and communicate your them early and often(see staying on message and communication below).  As with any large project sometimes the foundational reason for the effort is lost in the day to day, this must stay in the forefront of your mind.  We spent a significant amount of time before the project kicked off to be sure the goals an objectives were clear and sold to the senior leadership. 
  • Stay on Message - suppliers are not yet comfortable working in this model, as such, messaging is crucial.  In short, they will be suspicious.  Stay on message and remember; how you behave is more important than what you say.  You can talk partnership but you better act it as well.
  • Communication - It is absolutely key to create a communication plan and execute against that plan.  The constituents include employees, incumbent vendors, and candidate partners.  Part of communication is articulating what is important to you as the buyer.  One way we did this was in the form of a term sheet.  The term sheet is a set of contractual terms that the buyer can not be flexible on -- defining this early has the benefit of keeping cost of sales down for participants (if they were not happy with the terms they could drop out early) and it sped up contract negotiations on the back end.
  • Differentiators - If you are engaging a tier-1 or even a tier-2 outsourcing vendor then it is safe to say they can handle the technologies involved, this is not their first rodeo -- how then will they differentiate themselves?  Most clients assume differentiation comes from the team they put on the ground.  While the team is important, the actual staffing structure is more critical to partnership success.  If you don't like a particular team member, the partner will be more than happy to swap that person out.  Your overriding concern should be the structure of the organization (this will not change) and how that structure fits with your company's org structure.  Culture is equally important.  Are they order takers?  You need a partner who will tell you if you are going off the rails not a yes man.  Senior leadership commitment is another differentiator - are you getting the attention of thier senior leaders, do they understand what you mean by a partnership, and are they commited to making this work?
  • Scope -  We did not limit our scope to the immediate problem (development sourcing) but broadened our perspective to include process improvement initiatives that are key to the success of the sourcing effort but cut across the development organization, affecting the entire enterprise.  These improvement initiatives encompassed areas such as: knowledge management, SDLC, metrics, technical readiness, organizational culture, etc.  Including process improvement initiatives provided two main benefits - smoothed the sourcing transition and secondly provided a funding and process mechanism to initiate projects that typically are not easy to fund in IT organizations; for example: architecture, new technology analysis, strategic non-project based work.

The Five Rules in Practice

We were able to put the five rules of Vested Outsourcing (see March post for an intro to the five rules) into practice.


  1. Outcomes Based -We looked for ways and coached the candidate partners to assist in identifying specific outcomes not transactions.  The candidate partner has seen many sourcing deals you need to leverage that experience throughout this process.  They brought many ideas to the table.  In this case the client was very interested in code quality and the ability to flex capacity to meet business demand.  It seems obvious to say, focus the sourcing arrangement to the outcomes but being crisp regarding outcome definition and consistent in the message is intricate, nuanced, and requires some thought.
  2. Focus on the What - To be sure we focused on what needs to be accomplished and not how to perform a task.  We created a small team within the sourcing project to analyze each area and document what the goals were, being careful to stay away from implementation.  This sub-team then met with the candidate partners to solicit their best ideas regarding implementation.  Forming a clear delineation in the project team between the what and the how helped to steer the group in the right direction.  You will need to take care when staffing this sub-team, as this was a development initiative and developers tend to immediately dive down into the how of the solution - train and focus the group to stay away from implementation for this exercise.
  3. Metrics - What metrics were needed to be sure we continue to achieve our target goals?  Comparatively, this was an easy rule to put into practice as our candidates came to the table with a wealth of experience in this area.  The difficulty arose not in getting the correct metrics but getting those measures into a useful format, tool, and within a governance model that provides oversight.  We answered these latter issues with a comprehensive knowledge management approach and an integrated governance model that includes all aspects of IT management.
  4. Pricing Model - The contracting process can not take place in isolation in a vested outsourcing deal.  In a usual outsourcing arrangement the lawyers come in at the end and hash out details that would have been better discussed at the implementation team level.  You and your partner should be prepared to work through contacting the same way you worked through the RFI/RFP process, that is in an open and collaborative method.  The pricing has to tie together the "what of the deal" and the metrics; governance will then become the administrative arm of the model
  5. Governance - Governance ties the entire process together.  We established an enterprise governance structure with integration points into the sourcing initiative.  This model was used to integrate into other areas of IT into the sourcing project.  The client partner remained on the governance team in the out years but their focus changed from supporting the client to supporting the deal.  That is a challenging transition to make, but one that is necessary if the deal is to be balanced and successful in the long term.  Our governance process provided oversight back to what we want to accomplish - if we were careful and thoughtful around what needed to be accomplished then governance of the relationship can have the proper focal point.

Over the next few months as we begin transition and eventually move to steady state I will be updating this blog to report our progress, lessons learned and specific benefits and challenges we faced along the way.

-npv


Sunday, March 6, 2011

Outsourcing - A Better Way

As a software engineer and security professional one can not help but be exposed to and involved in outsourcing of all types - BPO (Business Process Outsourcing), software development and maintenance, KPO (Knowledge Process Outsourcing), etc.  While outsourcing does not necessarily mean off-shoring the two are usually closely linked.

Defining our terms -- Outsourcing is the process of subcontracting services to a third party.  Where off-shoring is relocating the business processes from one country to another.   The overwhelming reason companies outsource work is to lower costs and increase efficiencies.

The Usual Approach - We run your mess for less

I have been involved in evaluating vendors, negotiating contracts, and implementing outsourcing deals across many business domains for the last ten years.  In the vast majority of cases a senior executive (or team) decides to outsource to save many -- typically thinking that they will take advantage of the labor arbitrage because outsourcing and off-shoring are thought of as the same thing.  The senior staff's thinking goes something like: "we have problems let someone else (the experts) run/manage this thing".

The marching orders are then filtered down to the line staff that evaluates vendors, negotiate the deals and lives with the day to day consequences.  This dance usually takes the form of the company doing the outsourcing writing contracts and statements of work telling the service provider how they want to manage the work and for the most part the processes are the same as those used before outsourcing.  In addition to these process constraints the contracts are usually written to manage piece work.  That is to say, suppliers are reimbursed by how many operations they perform or manage.  For example; vendors that manage data centers get reimbursed by number of servers managed, calls centers by how many calls, and if you outsource development then you pay for each of the developers.  The incentive for the outsourcing vendor is to sell more of whatever it is they are managing.  Cost savings are not passed along and innovations are not sought; why would they be.

Now how is this process managed?  Not by mutual cooperation because it is a zero sum game.  It is managed by nit-picking the contract by both sides, antagonism and the larger more powerful company throwing it's muscle around (the proverbial 300 pound gorilla).

Overlay these process inefficiencies with a piece-work mentality, all wrapped around a zero sum game based contract and there is no wonder that the typical outsourcing arrangement evolves from, year one when the supplier tells the company "don't worry you will see savings when the process settles down".  In year two, the company moves to disillusionment and hope that this will turn itself around.  To finally, in year three of a seven year deal where the company is just counting down the time until it all ends.

Vested Outsourcing - A Better Way

Over the last two years I have been involved in a better approach and methodology to outsourcing.  It is called Vested Outsourcing (VO) - www.vestedoutsourcing.com.  Unlike other approaches VO has been tested in academia and across a number of business sectors (public and private).  VO is based on research conducted by the University of Tennessee and the Air Force in which five key tenets were developed and built upon, to set the stage for companies to fix their outsourcing issues.  I have become involved in VO as a research analyst conducting a VO study for the University of Tennessee (UT) and as a implementer of VO concepts for companies across the USA as an associate with a consulting company (www.capto-consulting.com).  My work in these two areas has convinced me that VO is truly a better way to outsource.

I won't try to explain all of VO in one blog post (there are many other sources for that) but I will summarize the five rules of vested outsourcing:




Rule 1: Focus on the outcome - As you look to outsource, the focus should be on the goals not on the transactions.  The supplier is paid to meet mutually agreed upon outcomes.  Outsourcing is then about buying and achieving desired business outcomes not about transaction management.

Rule 2: Focus on What not How -  Remember earlier in this post, I was talking about running your mess for less... well usually the company outsourced a function because they wanted to leverage the experts.  When it came time to write the contract they are then structured specifically telling the experts how to do their tasks.  A vested deal focuses on what the outcome should  be not telling the supplier how to implement.

Rule 3: Agree on Clearly Defined Measurable Outcomes - I am convinced that the focus shifts to measuring transactions because it's easier.  remember Rule 1 - stay focused on the outcomes and measure results against those.

Rule 4: Optimization of Pricing Model Incentives - this involves the balance of risk and reward while setting up a deal that is mutually beneficial to both parties and adhering to tenets of VO.  In the past I have witnessed companies that have set up incentive structures for vendors and then went to great lengths NOT to pay them the incentive.  In a vested deal the pricing is optimized and tied to outcomes the customer wants to pay the incentive - it is to the advantage of all parties to reach their outcomes based incentives.

Rule 5: Governance Structure that Provides Insight Not Only Oversight - In a vested deal we look for insights, ways to improve outcomes, methods and processes that help all parties reach their goals. 

Due to space constraints this is a simplification of VO but hopefully it will entice you to do more research.  I am involved with a number of companies at this time assessing their capabilities for outsourcing, implementing VO, and researching the field.  VO as a methodology will be a fundamental enabler or successful outsourcing.


-npv

Thursday, December 16, 2010

Head First Java - What a way to learn Java and OO programming

I occasionally teach Java programming at a local university and I am always on the lookout for books that can easily explain the necessary concepts to students.  In addition, (like most people in the technical field) I have purchased literally hundreds of books over the years to explore new topic and to keep up on trends.

Most programming books are very formulaic -- Basic overview; Hello World; each chapter takes a concept and shows some coding samples etc... these books are text heavy and proceed with some esoteric examples that do not transfer well to student/reader experience.

Wow what a difference when I stumbled upon Head First Java; A Brain Friendly Guide by Kathy Sierra and Bert Bates.   As I was browsing this book on Amazon I thought what kind of programming book is this -- cute pictures from the 1950's; strange graphics; not much text per page -- this can't be any good; does not appear serious enough.  Was I wrong!  The creators of the series and the authors have created an incredible way to make learning a new and technical topic easy, fun, and engaging; all without loosing touch with the material.  A huge amount of serious technical material is covered.  I actually found myself reading the book cover to cover and learning a few new things along the way.


What I Really Liked

  1. Examples that are easy to understand - when explaining inheritance they use common household items and animals for their examples.  This makes it easy to understand and explain to students.  Many other books use the concept of shapes to explain inheritance -- from my experience this does not translate well to student's experience.
  2. Making it Visual - actually help the reader remember concepts and puts the new material into a familiar "schema" so recall is easier.
  3. Conversational - it's written in a conversational style free of jargon to help comprehension.  Then the computer speak is added - now the reader understands the concept and is buzz word compliant.
This book is a bit dated; the 2nd edition was published in 2005; up to Java 5.0.  This does not affect the quality of the work or detract from its value as a teaching aid.

I could go on because I love this book; but I will close by saying this book Rocks -- buy it for anyone interested in leaning Java and OO concepts; you won't regret it.

Good reading...

-npv

Tuesday, December 7, 2010

Windows Live Mesh 2011 - Key Component in My Backup Plan

I have recently experienced a PC failure.  The failure necessitated that I send the machine back to the manufacturer.  My business requires that I be back up and running within a few hours which technically I was because I had a spare PC.  The issues I experienced were as follows:
  • backups were a few days old - not bad but had some problems,
  • bookmarks were missing,
  • reconfiguring software took time - outlook, accounting packages, IDE environments, etc.
  • the "feel" between PC was different and took a while to get my productivity level back up.
In short, it took a few days to be back up and running normally.  I wanted a better way to seamlessly move from one environment to the other and started to look for a more automated solution.  This post explains what I did.

Windows Live Mesh 2011

I needed a program that would keep my documents, source code (that is not in source control), pst files, bookmarks, and music all in sync between two PC's and that is where Windows Live Mesh 2011 comes in.  Microsoft advertises Mesh to do three main things (http://explore.live.com/windows-live-mesh-devices-sync-upgrade-ui?wa=wsignin1.0):  Keeps files up to date across numerous computers, connect computers remotely, and sync program settings between computers -- sounds like what I needed.

I then configured my backup PC to match my working PC with respect to software and settings -- which I no longer use a "old" computer as a backup; I spent the extra money to have two computers of equal configuration for the kinds of tasks I subject them to.

I then loaded and configured Windows Mesh to sync the two computers.  Microsoft's documentation and intuitive nature of Mesh made this easy.  I can now move from one system to the other seamlessly.  If my main PC should crash now I would be back up and running in the time it takes me to sign on to my backup.  It is truly a hot back up.  I have added to this the additional precaution of using windows backup of each PC should they have to have some type of full recovery but that seems unlikely.

Another feature of Windows Mesh is that Microsoft provides 5GB of cloud storage free of charge.  I use this to sync some data to the cloud. 

If your business requires seamless PC recovery you may consider this solution.

-npv

Wednesday, November 17, 2010

Windows Azure - Data Storage in the Cloud

Cloud Computing

Industry hype has not been in short supply regarding cloud computing -- there is even a Microsoft commercial touting cloud computing for the every day user -- but until relatively recently I have not had clients asking me about it for industrial strength applications.  I have put up a quick and dirty Amazon EC2 instance for some non-mission critical applications but I have not had mission crucial apps move to the cloud, why would this be the case - FUD, security, control, cost ...

I am now getting some serious queries related to the Microsoft Cloud offerings.  Windows Azure offers two persistent data storage choices -- Windows Azure Table Storage and SQL Azure.  In this post I will discuss features of the two choices, how they differ, and when one is a more appropriate choice.


SQLAzure

In Microsoft's cloud environment SQLAzure is analogous to SQLServer.   It's not a 1:1 match, at the present time SQLAzure has a number of limitations compared to full blown SQLServer see http://msdn.microsoft.com/en-us/library/ee336245.aspx for more info. In general SQLAzure can be thought of as cloud based SQLServer.  There are many good reference on Microsoft's site or provided by others to get you started.

What I immediately liked about SQLAzure was once you have a dB setup you can access it using the old familiar tools like SQLServer Management Studio (as long as you are using 2008 R2) and accessing the dB via your applications will also be familiar ground for the developers.  As a matter of fact Microsoft provides tools for you to create and test connection strings; often times a topic of confusion, if the number of web discussions is any indication.

When getting started one area where SQLAzure differs from SQLServer is that you can not use the SSMS GUI to modify the schema or add data to tables, this work has to be done using SQL statements - templates are provided for assistance.  Houston to the rescue (well kind of) -- https://manage-ch1.cloudapp.net/.

Project Houston is a very early Microsoft beta Silverlight application that supports tables, views, data entry, and stored procedures thru a SSMS like GUI.  Folks who have been working with Microsoft for a while will know that when they call something beta it's going to be rough (this is early beta, so brace yourself)  in contrast with Google a company that is known for betas that last for 5 years+. 

Azure Table Storage

Now this construct will take some getting used to for people who are longtime RDBMS users.  There has been some movement in the industry to simplify the RDBMS model -- loosen the rules a bit, if you will.

See:  http://perspectives.mvdirona.com/CommentView,guid,afe46691-a293-4f9a-8900-5688a597726a.aspx or http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_ or http://nosql-database.org/

With table storage you don't have to deal with pesky features like indexes, referential integrity, views, or stored procedures.  When I first started working with Table Storage I was reminded of IBM's VSAM (Virtual Storage Access Method) Keyed Sequence Data Sets or maybe a more common analogy would be a simple spreadsheet.  Like a KSDS in VSAM the key provides efficient querying with limited constraints. Like a spreadsheet the table in Table Storage does not have a schema.  The rows are a simple structure that contains data and the data does not have to be of a common type. 

When to Use Which Technology

The bottom line question that is usually posed is; when would I use one approach over the other.

Size Matters -- From a data volume (scalability) point of view Table Storage is more scalable than SQLAzure, by far.  Table Storage can currently scale to 100TB in size where SQLAzure limit is 50GB.

NoSQL or Not - If you are a traditional RDBMS company and you see benefits with the approach then you will opt for SQLAzure.  If you are in the NoSQL camp and want a less restrictive more RESTful  approach for data persistence then Table Storage would be more appropriate for your enterprise.

In-Out of The Cloud - With either approach data can be accessed via an application from in or out of the cloud.  If you need the flexibility to move data from the cloud back into your data center databases then SQLAzure is the better choice.  Not only does SQLAzure align from a technical perspective but there are tools to assist you in this migration.

Money Matters -  As always cost will be a factor in any decision.  Microsoft provides pricing information (http://www.microsoft.com/windowsazure/pricing/) and maybe you can cut a better deal if you are a large enterprise.  I have signed up for Microsoft cloud services via the MSDN which allows developers access for testing and planning, an option for you to kick the tires for low cost.

I would be willing to bet that as new software is released SQLAzure looks more and more like SQLServer and the data limitations are removed.



Good luck in the cloud....

-npv

Monday, November 1, 2010

Android Development with Hello, Android 3rd Edition

In a previous post I talked about my experience with the Android 2 phone and my desire to look into it from a development perspective.  To that end, I purchased Ed Burnette's book Hello, Android 3rd Edition.  What a great book on getting started with developing for the Android.

Basic Concepts to the Complex

Hello, Android takes you from the very basic steps of getting the Eclipse IDE set up for development to the more complex topics of data persistence (local storage and SQLite), graphics, and publishing to the Android market.  Ed does this by taking an example; a Sudoku application and demonstrates the topics while building an application.   I find this method of teaching technical material very effective and it worked extraordinarily well for me.

I especially liked the getting started chapters -- laying down a good foundation and I enjoyed learning about SQLLite a very nice little dB engine in a 150KB package.

One area I wish was covered in more detail is security in the Droid 2 development process.  This is an area I plan on exploring in the future.

Overall, a great book to get you started in Android 2 development and highly recommended.

-npv

Monday, September 13, 2010

Android Development

Life with an Android

I bought a Motorola Android phone 4 weeks ago and fell in love with it.  What I liked about it was its; fit-and finish, Google application integration, and the intuitive UI.  I had to purchase an application that would sync my Outlook contacts, notes and calendar but other than that everything I needed was on the phone when I opened the box.  Who knows, maybe I have incentive to get off Outlook soon.

I had to return the phone due to a hardware issue.  I was reluctant because after 4 weeks it was set up how I liked it, things were working great.  The day my replacement phone arrived I thought I was in for a few hours of work as I made the switch.  I was in for a pleasant surprise -- after activating the phone and giving it my gmail account info I was up and running on the new phone in less than10 minutes -- all my settings with the exception of my speed dial numbers were set up automatically.  It was fantastic.  I was impressed.

Open Platform

I then started looking into application development on the Android and discovered lots of benefits to being on the Android  OS.  It is a truly open development platform based on Linux and open source.  As a developer you are not locked into a vendor.  Third party applications are treated as equals to native applications.  Third party app developers have access to the same API's, all code is executed in the same run time environment, system services are exposed the same way to all developers, and you are permitted to add your code to the Android market place.

Installing the Tools for Android Development

I thought it would be interesting to explore the Android development environment.  So I set up my PC to do some Android programming, if you are going to do this you will need to:
  • Download and install the latest Sun JDK SE.
  • Download and install Eclipse - I used Eclipse IDE for Java Developers.
  • Install the Android SDK.
  • In Eclipse you will install a plug-in called the Android Development Toolkit (ADT).
Each of the components listed above is free of charge and you will find plenty of instructions on the web to walk you through the install process.  However, as I set up my development environment I did run into an error that I had a difficult time figuring out a solution for and I could not find an answer for on the web.

Error in Eclipse Setup -- Android not showing up in Eclipse Preferences

After the ADT plug-in is installed within Eclipse you should then be able to set your preferences for the Android environment by selecting Window -- Preferences and Android should be the second option in the left-hand pane.  However, in my environment (Windows 7 Ultimate, 64 bit) the Android option was not available.  Strangely, I had to run the Eclipse program as an administrator (even though I was signed on with admin privileges) and install the ADT (after uninstalling it from my first try), the Android preference option was then available.  You don't have to continue to run Eclipse as an admin only for the initial set up.

I plan on doing some application development for this platform and periodically I will report my findings and any issues/solutions.

Hope this helps

-npv