The project should go Live
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!
Lets say we have Alpha, Internal, Beta and Public releases to iterate over.
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
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.
- 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.
- Do a show-n-tell with project business team and existing site business team.
- Prepare a project plan for the next release to bridge the delta.
- Iterate again.
- Keep the delta's short!
- 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.
- 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.
- Internal can have some / all gaps mitigated from the existing platform and is for internal employees. This
- Beta is for a small community of users with all the gaps mitigated.
- 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
No comments:
Post a Comment