Project management the hard way. Learn from the trenches of successful, large scale IT implementations. What’s RACI and how does SCRUM work in reality? How to communicate business owner and understand the IT guys without letting the project to fall. Presentation with case study insights from real world projects and lessons learned.

1. 1

2. 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.
2
http://www.slideshare.net/divanteltd/surprising-failure-factors-when-implementing-
ecommerce-and-omnichannle-ebusiness

3. 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/

4. 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

5. 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/

6. 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.

7. 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

8. Paper Prototypes
8
Concept 1 Concept 2 Concept 3

9. 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

10. 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/

11. 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.

12. 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

13. 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”

14. 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.

15. 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/

16. Thank You!
Piotr Karwatka
say 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.