1

The Approach

Ingredients of eCommerce Success

• Motivations based on numbers/profits/ROI,

• Board involvement and support,

• Courage to adapt your offline business and

processes,

– prices & offer,

– logistics,

– product management,

– integrations.

• Physically written e-Commerce Strategy,

• On-board eCommerce Manager,

• On-board CTO or Technical consultant.

2http://www.slideshare.net/divanteltd/surprising-failure-factors-when-implementing-ecommerce-and-omnichannle-ebusiness

Organizational traps

• eCommerce success is incompatible with

a Silo-based-organization - it should

involve marketing AND sales AND IT …

• Setup RACI diagram - stakeholders who’s

who:

• Keep Business Owner informed,

• Make sure Product Owner is

decisive

• Your stakeholders needs will be

contradictory and can vary in time -

collect them, try to find a consensus,

design and show something easily

understandable

http://divante.co/blog/starting-ecommerce-management-boards-common-mistakes/

Your Team

Product Owner- details,

- making decisions &

finding consensus within

the Organization,

- problem solving.

Business Owner- interested in budget & time,

- results,

- not for problem solving.

Project Manager- providing results,

- making decisions,

- problem solving.

The Team- focused on technology,

- not business guys,

- details, quality, results.Managers- focused on their people,

- focused on partial

processes,

- Product Owner must

cooperate with them

Organization Vendor

T&M vs. Fixed price

Agile - T&M• Ongoing demos / retro meetings,

• Control over deadlines: deploy often / deploy early,

• Typically you work in SCRUM or other Agile

methodologies,

• Full control over the project, features, and quality,

• Clarity - pay only for hours spent on the project,

• No UATs wars at the end of the project - overall

quality.

5

Waterfall - Fixed• Almost no control over the project after analysis

phase,

• Months with no feedback from the end users,

• Waterfall methodologies in use

• Specifications over quality

• Little to no communication

• Company team involvement

• UATs wars.

http://divante.co/blog/timematerials-definitely/

Agile traps

• Is your company ready for Agile?

• To remember: Business Owners are focused on results / time / budget

• It’s tempting to start development without proper analysis and schedule/estimation

• It’s easy to overrun the budget and/or schedule without the desirable results,

• It’s required to book time for daily demo meetings,

• It’s required to gather feedback early

• Requires ongoing updates for BO(steering committees?)

• Healthy Trust but verification is required

• No surprises rule

Agile in eCommerce = Use Waterfall instead :-)

1. Do the analysis at the start, create backlog,

use User Stories and Mockups for a better

understanding at a business level

2. Estimate the entire project - budget and

deadline

3. Don’t negotiate down the dates and don’t

be too optimistic

4. Trust but verify ongoing results - be active

on demos and daily meetings.

Analysis and backlog

• Create detailed brief,

• Pricing you got from Sales rep != final budget,

• Final budget can be created after analysis phase

– business process description,

– user stories,

– mockups,

– integrations (always risky part)

• Never start development without analysis if you are

required to stick to the budget and/or deadline,

• Involve your team in the analysis process,

• Prioritize requirements using MoSCoW

Paper Prototypes

8Concept 1 Concept 2 Concept 3

Budgeting

• Fixed price required? Use MoSCoW - MUST = 60% of budget; SHOULD + COULD =

40%,

• Check if budget is realistic:

– communication + PM (about 20% of development time),

– time needed for tests (20% of development) + fixes,

– buffer for risky parts (eg. 30% buffer on integrations),

– buffer for change orders (it depends, 20-30%?),

– every time you put business / end users in front of the

system, there will be change orders :)

• monitor project progress weekly:

– time spent / total time;

– time spent / time estimated;

– team pace;

– working hours until the end of the project

9

Requirements consensus

• There is no “single stakeholder” at

your company,

• Requirements consensus sometimes

needs an offline processes adoption

(common minimal denominator),

• Engage end users early - analysis,

tests,

• Plan pilot-phase carefully - select

early adopters from your company

units,

• Late changes often result in budget

overrun.

10http://divante.co/blog/7-worst-mistakes-product-manager-avoid/

Workshops - achieving consensus

We work in teams. We generate ideas using personas.

Then we do paper prototyping

After that each team presents mockups and discusses them with other teams. Then we choose the best ideas and build one coherent mockup prototype.

Project plan and schedule

• In SCRUM we try to map

the entire backlog to

sprints until the end of the

project using JIRA,

• You can use MS Project as

well but it’s hard to make

updates,

• We create Project

Knowledge documents

using Google Docs:

– Schedule,

– Resources +

availability,

– Open risks registry,

– Open Issues registry,

– RAG light reports

12

Ongoing cooperation

and reports

• Daily meetings are for the Team,

• Once per sprint, retro + demo,

• RAG light reports - budget burning, team pace

etc.,

• SCRUM - each sprint’s results should be

accepted,

• Bugs after sprint are normal - it’s how

development works; Plan some buffer for

issues if you don’t to have completely closed

sprints,

• Book your resources while sprint planning (eg.

business people to consult with),

• Be clear about tasks - set “Acceptance

criteria”

UATs

• Ongoing tests are focused on particular issues/tickets,

• UATs should be focused on overall business processes,

• Not all business users are equally tolerant of issues;

• Invite testers carefully - avoid backfire

• Create test scenarios for key Use cases / business processes,

• If is often okay to have 100-300 bugs after UATs,

• UATs should be done prior to Pilot phase (with end business users),

• Budget some space for changes after Pilot phase to fit end user's needs.

Product launch

• Deployment - most risky, most stressful

moment,

• Plan everything

– Plan A,

– Plan B,

– Plan C :-)?

• Plan DAY-0 with an hourly schedule,

• What can go wrong?

• Schedule with no surprises

– 2 weeks for UATs,

– 2-3 weeks for fixes,

– 2 weeks for re-tests,

– Code Freeze period,

– 3-4 weeks for Pilot phase,

– GO LIVE!

15http://divante.co/blog/launching-product/

Thank You!

Piotr Karwatkasay hi@divante.co

For more visit:

http://divante.co/knowledge

We base on the expertise we’ve got from a number of projects and generalize it to find the gold rules eCommerce.