Selling the Quickstart Methodology: A Recipe for Success!
•Download as PPTX, PDF•
0 likes•24 views
Odoo Experience 2020 https://youtu.be/5PcrC4sttko
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
More from Odoo
More from Odoo (20)
Recently uploaded
Recently uploaded (20)
Selling the Quickstart Methodology: A Recipe for Success!
- 2. Methodology is a recipe Ingredients are always the same, dosing is not
- 3. Project Success is what matters
- 4. Responsibilities You and your customer working together
- 5. Simplicity Avoid wasting time & energy
- 6. Autonomy Your customer shouldn’t rely on you forever
- 7. Onboard users on time & on budget
- 8. No development? Do it only if “required”
- 9. Challenge the needs? Always! But for good reasons
- 10. Keep it simple!
- 11. Project Roles
- 14. Onboarding on time & on budget = successful project
- 15. Thank You
Editor's Notes
- Welcome everyone to this session entitled how to sell the Quickstart Methodology: A recipe for success. My name is Antoine, Business Service Manager at Odoo Belgium and I’ll be your host for the next 30 minutes
- Not do config & testing Methodo (strong & efficient) supports the Implementation => We have one Not a recipe → checking ingredients and mixing them is not enough Understand what aspects are important → you will dose them based on: Company constraints (size, industry, budget) Customer personality
- 1 objective: Project Success Sales/project will disagree, argue about a need, a requirements => That’s healthy Once you are convinced about the reason to do something then it can be implemented and it reduces risks This focus starts from the beginning of the sales cycle
- Ingredient: Mindset: as important as skills 1/ Responsibilities Drive the discussion / implementation Customer asks What & WHY You How Keep an open mind during the discussion => Get new & important infos Customer must spend time on it, it is his project
- 2nd aspect of mindset No low value tasks (never ending meetings, long documentations…) Be efficient, show results and give clear information Depending on the project it will be different: Small company: no project status meeting, no long meeting minutes & long validation process Bigger companies requires it and you have less flexibility to change that Take that extra time you will have to spend into account from the beginning when you sell the project
- Last aspect is the autonomy Don’t rely on us He needs to be able to do everything by himself: Convince internally to implement Odoo Convince that it works Train people internally Odoo easy to use BUT implementing requires the whole company It starts from the beginning Have a look at the change management presentation
- LEt’s focus on what we want to achieve through the methodology is the following: Onboard the users On time On budget Practically, let’s have a look at how decisions must be taken during the project
- Is it an issue if I choose to develop something right from the beginning? Development: Delay Complexity Expensive But needed if: Key requirements Affordable (budget & time) No dev if it is useless or if the return on investment isn’t worth the money invested
- Challenging thinking + evaluating => make good choices Challenging: Stick to the timing (simplify or delay) Stick to the budget (go-live withtout added costs) Provide a more efficient process Never accept a change request without: Agreeing the necessity Explaining the consequence Budget Delay Complexity Case by case: More complex company → less flexibility Requirements must be implemented No change can be accepted without adaptations
- People: The less the better. One person =/= best R&R clear: One person for the global consistency (SPOC) Other people must have a clear input to provide (key users) Meetings: The more people, the more communication. QS project: Straightforward commeunication SPOC = Sponsor = user LP: Different level of communication (steering commitee, project meetings, key users analysis) SPOC =/= Sponsor =/= users In meetings: collect info, no debate Doc: Ideal: customer does everything, it saves time so budget. Might be involved more or totaly => Budget it Conclusion: Anticipate and manage the expectation Budget everything: implementation & project management work Manage the risks
- Staffing: The staffing will depend on the project size & requirements For both customer & integrator 2 examples: QS projects & Large projects
- Quickstart projects which can be described as “simple” projects do not need a lot of people involved Must be: Business advisor + PL + SPOC Can be: Apps expert + dev + sponsor => Output: provide a solution for the end users This can always evolve through time if the project requires it
- We keep the same people Once a project requires it, more people might involved. Must be: Business advisor => work with the steering comity & the delivery team Steering commitee => Project director + SPOC + Sponsor => They do not handle the delivery but ensure that things are moving in the right direction Delivery team: Project leaders & developer + Key users Apps expert: punctual intervention => We deliver for the end users
- Sell the methodo as: A flexible approach => we know what to control, what are the impact, how to communicate them Adaptable over time => ability to evolve For every change, there is a consequence => impact on the customer In the end, your focus is: Time & budget => Successful project