The Mammoth Goes Live Today!

Visit tesco.com/tescobooks and you will see an ordinary site in fact ugly looking with many issues which will frustrate you as a user. You will not see a navigation on most of the pages and once you go to some areas of the site the only way to come back will be using a browser back button! the big images will hurt your eyes and login accounts that worked before will suddenly disappear! And the books that were available yesterday might not be there today!

Keeping aside the user experience (which I hope will be fixed in a few months to come) this is the single most biggest successful implementation in the world. Except the warehouse every thing is brand new for the books department. A full stack of 20+ systems went live on a single day. It is every programme managers nightmare and a good amount of people have lost their jobs! But it is finally out! There is not much you will see from a users point of view, but be patient and let it breath and grow. Its a platform which will allow Tesco to react faster to the market, and bring a lot more new things to the user in the future. 

A big congratulations to the full team working on it, some have been working on it for more than 2.5 years! This is surely a reason to celebrate.

-v

Cost and Time Over Runs

There are so many reasons that cause cost over runs in projects. Over the next few blogs will be detailing some points that can be taken care of specially in large projects. 

A large majority of projects go into cost and time overrun because of the skills of the people working on it. It is easy to catch that a vendor promised something in X million and Y months but was unable to deliver because they could not finish the development in time. It is however very difficult to assess and keep track of time eaten up by BAs and Test teams and Project manager disturbing the development team and eating their time and adding to the cost.   

For example I hire a resource to take care of the requirements from the business point of view and he keeps on calling the development team for 4-5 hours in a day asking questions which will enable him/her to understand the project very well but adds no direct value to the project. It is required; but not estimated in the estimates of the development team. Such situations arise very frequently in long running projects because of people movement.  depending on the size of the project and responsibilities of the new joiner.

This cost is different than the ramp up cost. In ramp up we assume that the cost of the new joiner not being productive for 5 - 10 days. But we take into account the cost and time spent by existing team in bringing him up to speed. This cost rises significantly of the new joiner is new to technology as well as domain along with the project. I don't have a rule of thumb yet to give a percentage you can add to the original cost when a team member is changed midway or a team is built with fresher BAs. I have been stung by this in the past 3 projects and I plan to introduce a post ramp assessment process which will give some indications of what can be expected from the person.  This also stress and confirms the fact that a knowledge management plan should be part of the overall project plan. A point to note though, knowledge management plan will reduce the cost but will not eliminate it.   

-v

  

Chapter 6 - The UX Review Vs Profit

UX Reviews
UX Reviews may add value, and same is the question is with external code reviews for inhouse solutions. But striving for perfection in UX is very difficult. Every time a bunch of users test your site you are bound to get a new feedback. The focus hence should be to go live and start the flow of money first and then put more effort on how to maximize profit with the amount of sales that you achieve. Once you are here then you can think of increasing the conversion. Getting a higher conversion definitely feels good but it is not worth if at the end you loose money becuase you spend far too much for getting the customers on the site.

In my past experience one of my customers went for UX review when they are replacing a platform. There are 2 mistakes here. First, as mentioned in my previous post, these are additional requirements over and above the change of platform. Second, Focus lost.

Now consider this; you ask me, to check with some sample users if my page is good enough to tempt them to buy and agree to pay me for giving a report. And because I am the "EXPERT", I also get paid additional money for telling you, what you should change on your page to make people buy. There is no accountability for my recommedations as there is no way you can validate the result and I still get paid! Who is going to tell you did a good job and there is nothing should change? I won't!

So, First Launch the new platform and keep the UI same as the previous one, then get the analytics on the new platform  and  if you find something is wrong with the conversion, change; but step by step.

If at all you get the reviews done then stick to one single company. If a new company does a review for the second time it WILL find issues with the recommendations made by the first one. It is the nature of the job; get paid by proving others wrong - and the speciality here is no accoutability!

When I talk of Analytics it is not the regular Web Analytics. In one of my recent project, our customer  requested to change the colour of the "Add to Basket" button from Green to Blue! From the web analytics of the small A/B test they did, they found Blue converts more than Green! Looks like absurd analysis but even if it was true at the end of the day the business would have been loosing more money by getting more orders becuase their operations where not streamlined. They were also spending too much marketing money on some of the products and the cost of the product did not consider all investments made. The best approach is to get the business model and cost structures correct and then increase the conversion. But you need the right tools like Intelligent Trader from eCommera to do this kind of analysis. UXreviews and web Analytics cannot help you achieve this.


Ofcourse this does not mean you can afford mistake that happend at Waitross recently.But if it aint broke dont fix it. Bottom line is Making Money should be the first target and improving an already acceptable and base lined usablility, second.

-v

Chapter 5 - The Contract

I am not sure why but sales teams write contract for many companies. Contract writing is crucial to understanding the line of responsibility. If it is a standard product offering or SaaS models the contract is straight forward but during customizations and services, it is very much dependent and what the client wants. Since the sales team is near to the customer it is assumed they know what the customer needs and hence they write the contract. The first point of failure. Sales teams have targets to achieve and should stay away from the details to be put in the contract. The commitments made by them needs to be delivered by someone else.

It is also important to ensure that one who writes the contract has prior experience of doing so, else he should just be assisting and not owning it. A loosely worded contract is always harmful for the vendor. No management wants to enter in a legal battle with the customer. But ironically, it is the customer who ultimately suffers delays and financial losses.

I was assisting my manager in writing a contract when he needed an statement of work. Even after explaining him the difference he would not appreciate. Finally after 5 months it all came down when we were ridiculed by the customer for not knowing basic thing.

I need a FIXED PRICE. Managers who take the decision to go fixed priced from day one have a simple assumption i.e. Since it is a platform, it has to be standard and should have been done before and hence the integration vendor should know how much effort it takes. But unfortunately the integration team just knows the product (also not completely) and not your requirements. A fixed priced implementation can be easily sold  as a simple remedy to all your budgeting and IT spend forecast issues. However, it is very difficult to manage and practically fails and proves more expensive, if you try doing it before the requirements are finalized and a high level solution design has been approved.  As a customer, you to understand the gravity because when a project fails finally you will miss the target.

From a vendor perspective, handling a fixed priced quote is extremely tricky. Scope inclusions and exclusions need to be explicit and thorough. It is best to have an experienced technical manager write the scope. Loosely worded contracts fixed priced projects are bound to be exploited by customers. A statement like "Business would like a system to allow its suppliers to induct product on their own" without any other subsequent rules can lead up to thousands of days of implementation effort.

The only thing you need to watch in time and material contracts is, the quality of resources and their intentions. No human would love to finish work, if he is paid to continue! Effortless reselling makes people greedy and lazy. T&M contracts give you the flexibility to change halfway which is missed in fixed priced implementation but there is a danger of getting lost if you do not exercise control.  

Another item that has come up these days is penalty for missing the target. You can never close this correctly and efficiently. The vendor / supplier will find 100s of loop holes in the penalty clause and you will end up spending more money in proving him wrong than recovering from him.  Working more cooperatively is a win win situation and always preferred.

Finally, you and only you, as a customer, have to control the project and put it live. Others can only help you but cannot do the job for you.

-v



  

Chapter 4 - The MultiVendor Nightmare

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

Chapter 3 - The Support Team Management

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

Chapter 2 - Requirements & Release - The Mother of all mistakes!

The project should go Live

The heart of any project are "Requirements". Whether you have got them right or wrong can be seen only once the project is live. Customers can give you the best feedback. But to get to this stage you have to go live! And that is the most important target! The project, should GO LIVE!

There are simple and practical approaches for the 2 scenarios when you launch a site. 

Scenario 1 - if you are launching your site for the first time, go with most of the out of box functionalities of the underlying platform product.
Scenario 2 - if you are replacing your platform select a platform which has most of your existing functionalities as out of box and limit the first release to existing functionalities even if customization of the platform is required.

Ecosystem Requirements while Replacing Platforms of Existing Sites

The second scenario above is the tricky one and lessons learnt here can be applied to the first one as well. Should not go for replacing only because some other platform has good out of box features. You think about this when you have substantial revenue coming from your eCommerce channel and you platform is not scalable and that should be the only reason.

Moving Requirements
Existing business is going to have targets to improve and integrate with the brick and mortar parent! Business teams are faced with this problem more than often and they never arrest this and make the biggest mistake of asking the development team to develop against a moving target! This way you will never go live!

The risk increases more when the project business team wants to have more requirements in the new site than in the existing site and these are different from the new features on the existing site! Programme managers and Project managers also get lots of requirements from their ecosystem and they spend large amount of time trying to ensure that their project / programme should gel with ecosystem. The hard fact is, with this approach, you will never go live!

Show n Tell Changes
If visualization is possible, it is a very good practise to constantly show the customer what has been develop  . However its a double edged sword and needs to be handled with care!  The benefit is once the business see what is done they might not ask you change as they now it will need more time and some other important functionality will suffer. Which is good! But it might also happen that when they see something they want to change because it does not come out the way they thought it would when they wrote the requirements!

Frankly the best solution would be a directive from top management to hold on improvement on the current site to allow the new platform to come in. But this seldom happens!

Here is an alternative approach for the above issues.

1. Set a cut-off date and note the requirements to this date and make the first internal release to this date and don't incorporate any environmental changes. 
2. Do a show-n-tell with project business team and existing site business team.  
3. Prepare a project plan for the next release to bridge the delta. 
4. Iterate again. 
5. Keep the delta's short! 
6. Ensure project business team and higher management understand why you do this (easier said than done!) 

Lets say we have Alpha, Internal, Beta and Public releases to iterate over.

1. Alpha will be your first release with the requirements agreed on day one and is only for project business community. This will make sure that you entire end to end channel works and all support process area also in place. 
2. Internal can have some / all gaps mitigated from the existing platform and is for internal employees. This
3. Beta is for a small community of users with all the gaps mitigated.
4. Public is the final release. 

Before working anything like the above a fit gap between existing platform and new platform is a must. Upto 20M it is observed that business do not explore new features a lot and hence above approach is not required. 20-50M might be difficult with the approach as businesses try to retain customer with additional features and eCommerce channel data is moderately coupled into the spine of the actual business (if not a completely online business) and above 50M the eCommerce site has too many interfaces with its eco-system and tightly coupled making the above plan almost inevitable.

In the flow above we touched another topic above which is Big Bang Vs Step by Step. Lets discuss this in the next chapter.

Replacing too many systems at the same time. 

I have seen this failing twice now and I believe this is practically suicide.  It is every business stakeholders dream to have the best systems working harmoniously on a single day and all being switched with one click. Right from Warehouse to Website there is a big stack of technology involved. But it is practically impossible to change them all in one day and the chances of failure are a 1000 times more than success. Replace one or two NON linked systems at a time.

Millions are spent in getting the correct approach for Scenario 2 and still most projects fail or get painfully delayed because the above issues.

-v

Lessons Learnt in eCommerce Programmes

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.

Commerce Website and WebApp

A very common mistake most of the business users make is to not differentiate between a commerce website and web application. Both are significantly different in use and serve completely different purpose even when you open them in the same browser!

A web application is something you use mainly inside your organization. For example your leave application system, your claims system, your resource allocation system and every other system that exists internal to your company. There are external web applications as well however they are mostly developer focused and dont fall under a common man's perspective. These applications mainly focus on functionality. Performance is a focus but no one is going to stop visiting them if they run a little slower. Yes people will start complaining about the waste of time and the IS team will be forced to refactor a part of the code to make it run faster. Hence these applications can be intelligent enough to do dynamic calculations based on user input and implement funky algorithms.

A website particularly a commerce website has to run fast and show things to the user on the click. Users dont sit to wait for the page to load. Transactions websites have to be dumb. If the data exists, show it else show something else. No calculations on the fly! This is an important concept which most of the business community does not understand when they are in the process of coming up with a transactional website and discuss suicidal requirements with their implementation teams. A lot of time and money is wasted first in convincing them that this should not be done and when they use their veto and get it implemented, in fixing the performance of the site. But finally since the implementation teams get paid for the time spent its the business team that looses. 

-v