The most common error when it comes to rolling out a project is not having the support team in place in the time required. Most of the time there is so much focus on development that Programme Managers forget support needs to be in place before the project goes live.
The challenge is not just to get the resource but the get them to know the technology and project. If its a grass root project then your existing will not have the skills and if you are working on a technology replacement then your existing team will have requirements that will need to be managed and above all your existing team will need to know the new technology and accept it.
I joined a project to manage support in Central Europe on the day the site was going live! The next time it was a little better. The support team was in place before going live but they were in love with their current process and created a lot of noise around the solution developed which eventually caught the higher management's attention and unnecessary issues and delay.
Depending on the size of the project, you will need at least 2-3 people in the project who know the technology platform well. My manager gave me a team of 4 where no one had worked on the technology including me and we were pushed in the project on the very last day! Sleepless nights, but still cannot deliver what was expected!
There is a dangerous strategy applied by companies where they seek entry by showing credentials on the how successfully the have supported live eCommerce sites with their 24X7 module and then slowly show you the capability of their support team on the project and ask suggest they can take the development as well. I have been twice handed over projects by our sales team where clients were lured with this illusion. There are some facts which should be clear. Support team members are NOT developers! They look at a different side of the world and they have a different skill set! Supporting a live site on a platform does not mean that you can develop on the platform with out assistance. Yes, it is easy for you to understand how the system behaves but this is miles away from being able to develop. And if the support team starts developing who is going to support?
Also to be frank, providing support with team in UK and US is just expensive but effective. There are too many overheads to support a live site from remote locations without any local presence. You have to make sure that at least one person is there locally to handle the business team else you are running. Again different teams managing different part of the support function is a good break up when it comes to reducing the risk of too much dependency on one vendor but is a nightmare to work out the integration. Specially if both / any one vendors offer complete services and you have selected only a part of it. There are OLAs possible between each one of them but they don't really work as such vendors are always up to grab each others business and not full attention is given to do the job at hand to the fullest.
I was servicing L2 when Infrastructure was serviced by another vendor team of the customer and L3 was done by the vendor who developed the site. After the services were stable my main KPI given to me was to get a pie of Infrastructure, L3 and a bit of development as well. So even when I would want to focus on getting the system stabilized and metrics correct part of my focus was diverted because of this.
In another assignment I was leading development and customer staffed the support team with contractors and consultants. This never again is an issue because these contractors work on time and material basis on short term contract and don't have the ownership to put the ship on the right track This resulted in massive delays as simple things too much more time to get resolved as there was no incentive for the contractors to complete the work in time or earlier and good benefits of pushing it because each one of them was paid more than 600 GBP per day!
The Golden rule is to have key internal players with the right technical experience, training and KPIs be supported by a responsible external vendor and clear lines of ownership defined.
Next - The multi Vendor NightMare...soon
-v
No comments:
Post a Comment