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