Back in 1990 and early 2000 large outsource deals were signed and where a part of IT operations was give to just one vendor. Then came the era that individual programmes were given to single vendors but multiple vendors existed as partners and suppliers to one single organization. Stage 3 is multiple vendors in the same programme and this seems to have plagued eCommerce programmes specially.
It is a fact that more than 30% of the worlds non innovative code is written in India. Equally it is also a fact that if you are a big organization you have an Indian IT Company as your partner or service provider and will have an account manager from your partner organization sitting within your premises. The role of account manager is different for service provider and product company. The account manager of a service company is given the job of expanding the footprint in your organization apart from ensuring service delivery of agreed services. Understanding this role and its KPIs can be very useful in getting your work around the service provider as account managers as the most influential lots in the service provider's host organization.
If you bind the contract correctly, a single vendor system can be a very healthy and progressive relationship. Lack of competition can create a laggardness in resolving issues though. But then you cannot treat them as vendors, they are just like your own organization. You have to live with them and get around their issues and see the commitment and knowledge the have about your platform and business.
When you loose trust in this model you go for the multi vendor model and some managers go overboard in sourcing the best resources in a single life cycle stage from different companies! For eg. building the infrastructure team with resources from 2 or more companies and independent contractors each of who has been an expert in his field. This model lacks accountability and fails sooner than you can think if you have the lead of the team also from one of the vendors. If you have your own, above average, capable employee handling this, then you can expect some results to come out of this.
Another scenarios is where design is done by one vendor and development is done by another and solution support is a third one. I remember worlds biggest retail player had this model and it introduced only delays. The subsequent partner in the chain is always going to find issues with the previous one. Again loss of accountability and unclear lines of responsibility. I was supporting a platfrom where second level was provided by my team, infrastructure was provided by a hosting provider. Unclear lines of responsibilities was always the primary reason when we used to push the issue over the border. I am guilty, but the setup forced me to do it as one of my KPIs was to keep the issue lower and this was an easy way out to dose the fire. This setup is extremely common in a cloud hosting. However the scope and responsibilities are very well defined in this situation now and we hardly have the issue.
A multi vendor scenario works only with clear lines of responsibility and governance in a single project / programme. Normally it is beneficial to have a single project with a single vendor. All other models have considerable more amount of challenge in management.
Contract issues next.
-v
If you bind the contract correctly, a single vendor system can be a very healthy and progressive relationship. Lack of competition can create a laggardness in resolving issues though. But then you cannot treat them as vendors, they are just like your own organization. You have to live with them and get around their issues and see the commitment and knowledge the have about your platform and business.
When you loose trust in this model you go for the multi vendor model and some managers go overboard in sourcing the best resources in a single life cycle stage from different companies! For eg. building the infrastructure team with resources from 2 or more companies and independent contractors each of who has been an expert in his field. This model lacks accountability and fails sooner than you can think if you have the lead of the team also from one of the vendors. If you have your own, above average, capable employee handling this, then you can expect some results to come out of this.
Another scenarios is where design is done by one vendor and development is done by another and solution support is a third one. I remember worlds biggest retail player had this model and it introduced only delays. The subsequent partner in the chain is always going to find issues with the previous one. Again loss of accountability and unclear lines of responsibility. I was supporting a platfrom where second level was provided by my team, infrastructure was provided by a hosting provider. Unclear lines of responsibilities was always the primary reason when we used to push the issue over the border. I am guilty, but the setup forced me to do it as one of my KPIs was to keep the issue lower and this was an easy way out to dose the fire. This setup is extremely common in a cloud hosting. However the scope and responsibilities are very well defined in this situation now and we hardly have the issue.
A multi vendor scenario works only with clear lines of responsibility and governance in a single project / programme. Normally it is beneficial to have a single project with a single vendor. All other models have considerable more amount of challenge in management.
Contract issues next.
-v
No comments:
Post a Comment