SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
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.
Piotr Karwatka - Managing IT project with no doubts. How to work with Agency, manage process and expectations and execute successful Magento project using SCRUM methodology.
Ingredients of eCommerce Success
• Motivations based on numbers/profits/ROI,
• Board involvement and support,
• Courage to adapt your offline business and
– prices & offer,
– product management,
• Physically written e-Commerce Strategy,
• On-board eCommerce Manager,
• On-board CTO or Technical consultant.
• eCommerce success is incompatible with
a Silo-based-organization - it should
involve marketing AND sales AND IT …
• Setup RACI diagram - stakeholders who’s
• Keep Business Owner informed,
• Make sure Product Owner is
• Your stakeholders needs will be
contradictory and can vary in time -
collect them, try to find a consensus,
design and show something easily
- making decisions &
finding consensus within
- problem solving.
- interested in budget & time,
- not for problem solving.
- providing results,
- making decisions,
- problem solving.
- focused on technology,
- not business guys,
- details, quality, results.Managers
- focused on their people,
- focused on partial
- Product Owner must
cooperate with them
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
• 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
Waterfall - Fixed
• Almost no control over the project after analysis
• Months with no feedback from the end users,
• Waterfall methodologies in use
• Specifications over quality
• Little to no communication
• Company team involvement
• UATs wars.
• 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
• It’s required to gather feedback early
• Requires ongoing updates for BO
• 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
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,
– 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
Concept 1 Concept 2 Concept 3
• Fixed price required? Use MoSCoW - MUST = 60% of budget; SHOULD + COULD =
• 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
• There is no “single stakeholder” at
• Requirements consensus sometimes
needs an offline processes adoption
(common minimal denominator),
• Engage end users early - analysis,
• Plan pilot-phase carefully - select
early adopters from your company
• Late changes often result in budget
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
• We create Project
using Google Docs:
– Resources +
– Open risks registry,
– Open Issues registry,
– RAG light reports
• Daily meetings are for the Team,
• Once per sprint, retro + demo,
• RAG light reports - budget burning, team pace
• SCRUM - each sprint’s results should be
• Bugs after sprint are normal - it’s how
development works; Plan some buffer for
issues if you don’t to have completely closed
• Book your resources while sprint planning (eg.
business people to consult with),
• Be clear about tasks - set “Acceptance
• 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.
• Deployment - most risky, most stressful
• 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!
For more visit:
We base on the expertise we’ve got from a number of
projects and generalize it to find the gold rules eCommerce.