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