Skip to Content

It’s called BPO. Part-II.

In my previous blog I wrote about BPO in general and promised to give a concrete example. Since my background founds in the development I made up a case of ou-servicing a non essential to a software company process.

The yin-yang business theory (Jeoffrey Moore’s core-context approach) applying for a small-to-medium software company dictates that only developing of the core product functionality is the actual core business (sorry for tautology). It may vary from company to company – ones earn on packaging components, others on developing components, thirds on services – but I want to accentuate here not on the core but the context. For 99% of the software companies managing product development processes is the context. Managing the source code (setting up a VCS, creating release policy, defining build process), all services around code quality control (following standards, checking and generation documentation, generating reports), building and defining a project management system (creating new feature definitions, assigning tasks, so lovely GANT diagrams), setting up a bug tracking system (flows of bug life-cycle, permissions, reports), building a build and a testing systems (nigh builds, unit,  regression, and load tests). These are just a few tasks every software company with more than 5 developers has and besides that has at least one full time employee coping with only some of the tasks. For a software company these services are not less out-serviceable than running a customer support service or managing financial accounts or cleaning the office.

Most of the companies still develop this service in-house. These types of  “challenges” are boring for internal stuff and they’re rarely enthusiastic to build it with excellence. As a result usually the quality of such services is lower than if it was bought from an external supplier.  Another consequence is the services are just as minimalistic as possible. My experience says that the tools chosen for the tasks really don’t affect the resulting quality. I saw productive frameworks built completely on the open source software and I know some  implementations, driving costs above a million, leading to frustrations and disappointment. In any case the internal team dealing with it permanently dreams about escaping from this “honour commitment” and another, even a bigger problem, – the organization sticks to its own vision and patterns.

Since it’s not a core activity for an organization it manages the processes at the team’s best. It naturally can’t invest much time and resources (and it shouldn’t) into getting and following the latest best practices, updating processes, experimenting and playing with different methodologies. I’m not saying they don’t care but they can’t compete with a service provider supplying such services as its core product. What services can be exposed and consumed in this case?

All the above services (managing the code, project management, bug tracking, governance…) in all possible combination plus special packages for concrete methodology including best and next practices. The good thing here is together with SOA approach today a consumer can choose only services he needs. He can integrate its own (yet) in-house systems with out-serviced ones. For instance he can have its internal version control system but transfer a feature managing system to an ASP and integrate them. Today all existing systems provide an integration API and to a certain level all the systems can be integrated.

There are many questions yet to answer for such a fictitious provider but the idea is clear I hope. Free resources of your team from doing things not adding direct value to your business. I’m sure that my imaginable case illustrate this approach well.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.