I have been part of big transformation programme in the UK for one of the world's largest retailer and was a part of the eCommerce venture of the second largest sports company into Europe and North America. I currently work as a solution consultant for retailers in London. Normally when a programme fails by default the implementation part is on the line of fire. However when you see closely there are some mistakes which if avoided could have brought different results.
Since I worked on different areas of eCommerce implementation and support, this cannot be completed in one single blog and hence will be writing different chapters over a period of time. The information provided can be useful to Business stake holders, IT Programme and Project managers. If there is anything that is of specific interest and is not in my blog feel free to connect and I will try to find relevant information and send across if I dont have experience on it. And if you find you can contribute a different experience write it up and put the link in the comments.
You will find a lot of material on the web which tells you what you SHOULD DO to make an ecommerce programme successful. However it is difficult to find things which tell you what you SHOULD NOT. Thats the only reason I have taken the reverse approach.
Chapter 1 - Resource Management
There are many type or sourcing issues but the the biggest of all is experienced skill set for the role. It is very dangerous to build a team with people who are not experienced enough to play the allocated role. This causes nothing but delays as such people learns on the job.
If you are a business stake holder or a lead in the implementation team, it is your responsibility to ensure that not only your team is staffed sufficiently with the right number and quality of experience, but also your counter part team has right level of experience to compliment your team. Most of the time we give importance to fetching the development team with the right skills but we forget that the person who owns the requirement should be capable enough to play his role. Staffing a BA with 10 years of Banking experience is a eCommerce website project is perhaps a bigger risk and issue than getting a developer who has worked on IBM and not ATG Commerce. Looks an obvious statement but still happens all around.
Apart from the development teams, role-to-skillset mapping issues are seen generally observed for Programme Managers, Release Managers, Business Leads, and above all QA teams. And the most common skillset missing is domain knowledge and prior experience of releasing a transactional website specially in the QA domain.
Apart from skills, the time to start staffing is also an issues. Since all the focus is on development it is found to be a common mistake to get the operations staff in time and give them sufficient time to prepare their processes.
Project change management is a skill and an art which only a few have mastered. Most projects fail because of the failure to arrest change and wild thoughts of the business team. You cannot allow your business team to behave like a have a "Toddler In a Toy Shop"(TITS) Syndrome!I want this, and this and this ...and...everything!" Staffing of a project / programme manager who has seen a previous project getting "successfully" executed is a key factor. Domain knowledge is as important as being Prince2 or PMP certified.
From the technology partner perspective there is a massive issue of role-skill mismatch. This i have seen specially with Indian Software Service Providers. Resources of these companies are jack of all trades and master of none. partly it is because of the past growth of companies and their hunger to grow more and partly because of the model they operate they cannot afford to keep resources to only 1 technology or platform or domain. If you as a lead staff resources just to show a face to the client then there is trouble. I think the respect will be more if you can say "We don't have this skill in house and hence cannot staff".
In a nutshell, development team is not the only area of your project / programme where the right skills are needed. It is mostly the other areas which fail and bring the project / programme down.
Next Chapter on Requirements will be there soon.
No comments:
Post a Comment