Recently we have completed a merchandising solution upgrade project and have organized a meeting post completion to review lessons learned during the project. This is what our team has fed back on lessons learned. We are sharing our learnings for your benefit, reach out if you would like to get in touch and discuss in more detail these or additional specific points.
The scope and timeline of our project was the Merchandise Operations Management solution suite from Oracle Retail. The end to end project timeline was six months that included all activities from initial planning through full user testing and post-upgrade go-live stabilization.
The project outcome was a success both from timeline and budget perspective: we have completed the project on time, on budget and also on scope. We have also learned many valuable lessons on the way that have proven to be extremely useful in subsequent projects. This is what we have learned:
KEY LESSONS LEARNED
1. Management Process Make sure an explicitly defined and agreed/accepted escalation process is defined and created from the very beginning between team members, PM and management on all parties in the project for streamlined communication and escalated issue management when escalation is needed and occurs. 2. AB testing Make sure that in the project sufficient resources are assigned to manage tasks in an accelerated A/B testing method (two teams, team A and team B, do the iterations of the upgrade test runs in alternation, passing documentation to the passive team which then in turn does the next iteration. 3. Estimation In estimating effort in duration and man days, make sure you includea. Sufficient time duration for all steps like documentation, iterative runs, etc.
b. Sufficient resources/man days to do A B runs.
c. Sufficient duration for communication delays depending on number of parties involved in the project. The more parties the longer the total aggregate delay duration in the project.
d. Sufficient duration for at least 3-5 iterations on testing through all upgrade scripts, this effort turned out to be significantly higher than initially estimated, many many small (and some large) issues had to be ironed out before end to end run was stable for a PRD execution.
4. Status sharinga. Make sure you systematically do daily team standup meeting for entire team so everyone knows who is doing what, who needs to do what (TODO), and what the open issues/TODOs are along with their statuses (make sure everyone in the project team is on the same page).
b. Keep the meetings short and discuss issues in detail only with people involved, only keep the entire team in the standup as long as it takes to share status.
5. Communication:a. Make sure all communication, internal and external, if done outside of the central issue tracking cloud solution (e.g. on Skype, emails, phone, etc.) get uploaded to WIKI/Issue Tracking Solution to the appropriate article/issue so it does not get lost. This includes everyone updating Tickets/WIKI with up to the end of each day status of what they have done on an issue, what they have tried, (SQLs, source code, results) so if someone takes over the issue, knows what has been done already!
b. If the client does not use Tickets consistently, then Quickborn logs all issues that come in on non-Ticket channels (on emails, phone calls, SMS-es, etc).
c. Make sure Oracle is kept in the loop at all times, some issues that come up may need to be escalated to Oracle, having them involved on a continuous basis will significantly decrease their reaction time and consequently project timeline will be protected.
