Partnering with your outsourcing vendors
 
|
|||
 | |||
|
Sign up to receive this and other networking newsletters in your inbox.
In past articles, I have focused on remote hosting of applications and services. But now that we have widened the focus of this newsletter to outsourcing, I'm going to look at not only the remote hosting of services and applications, but the steps that occur before and after the " location " decision.
As an example, in one of my previous roles I was part of a decision to transfer our company's Web-based services to a third party hosting provider. In this particular case, Level 3 was our provider of choice.
But before that decision came about - one in which I was tangentially involved - I had to first determine the case for either buying or developing in-house the applications that were to be hosted by Level 3. In that process, I was intimately involved at various levels of application development and implementation.
We were building a Web-based financial interaction system and I was trying to determine if we needed to do the development with a partner, or rely upon our internal staff to build it. As in most cases with the Internet economy, speed was of the essence...more so than cost (remember, this was two years ago, before the bubble burst and cost became a concern).
My decision model looked something like the following:
* High-level feature requirements built out in tandem with a business analyst.
(a) This included a series of interviews with our informal customer council.
* Internal calculus with my existing expertise in working with the capabilities of the development group.
* Product outline with the vice president of engineering.
(a) Discussion of resources available.
* Basic request for proposal submitted to local Web-oriented application development groups.
* Due diligence for several off-the-shelf product options.
* Build or buy pros/cons with financial issues, compared to time-to-delivery possibilities (this is the Hamlet part and also the piece that requires internal political machinations).
* Decision - in this case, for external development.
* Creation, with the business analyst, of a functional specification.
* Selection of the development firm based on previous work primarily, and cost secondarily.
* Management of the development effort assigning the internal business analyst and a development representative to the project.
Obviously there were more details in this process and it certainly was not linear. But for the most part, this highlighted the process that I went through. Importantly, though, there were some parts of this that required " crossing the chasm " decision-making that I will cover in the next article.
Some of the key areas were:
* My own confidence in the development staff to accomplish what I wanted.
* Political feather-smoothing if I decided to go around the internal development group.
* Looking at outside development that was offshore and a lower cost.
* Considering off-the-shelf products that I had to weigh the positives of stable code that was relatively inexpensive and rapidly deployable, but not customized exactly to the market requirements that I'd earlier laid out.
If you have comments on my high-level outline here, please let me know.
RELATED LINKS
Network World, 02/11/02
ASPs aim to change stripes
Network World, 02/11/02
Senior Analyst Tim Wilson is with Enterprise Management Associates in Boulder, Colo., an analyst and market research firm focusing exclusively on all aspects of enterprise management. Wilson has over 10 years of experience in covering e-business and enterprise management issues, most recently with InternetWeek, where he was chief of reporters. He can be reached by clicking here.
