A long time the <packt> publishing offered all of their books for really good price. I bought them all but didn’t really have time to read them for a long time, but finally I started one by one.
The End-to-End implementation somehow made it on top of the list and I really enjoyed the book. Kristian has really similar approach to implementations and the book resonated very well with me.
14 chapters, each with intro and summary, covering the whole process. Which activities, whom to include, what to take care about. I feel it is almost aimed at the companies implementing internally, to people without Salesforce experience. Some of the steps/tasks/chapters are so obvious, at the same time I feel they can bring a real value to someone at the beginning of their journey.
- overview of current business capabilities – I always hated this diagram so much yet understand it can bring an immense value. The tricky part for me is, that every single one of us can have a different view on the situation, can group and name the capabilities differently and it was always hard for me to come with something I would be happy with, something which won’t be obvious to everyone since beginning but would bring some new insights – but that’s probably not needed at all;
- list of delivery methodologies – I still struggle with the subtle differences between Agile, Scrum and Kanban and probably like some bits from each of them. Obviously I won’t be a great project manager;
- change managements frameworks – important part of every project which is being ignored on every single project I’ve been part of and some simplified into „management will send an email“ (in its best form). Seeing three frameworks listed in the book I want to learn more and while there is this module on Trailhead I don’t feel it gave me enough;
- KPIs or how we will spot successful implementation – very often I have to wonder how the implementation itself might improve those KPIs -> I do understand lowering processing time, but generate more leads?
- I’ve never heard of Conway’s law which says that companies do mostly lift and shift into new system, unless provided external input -> strong case (according to Kristian) to involve an implementation partner. Sadly I remember the implementations where the analyst just asked how the processes work now and didn’t care to suggest any possible improvements;
- a user story should be linked to business objectives, should have a purpose bigger than moving the process into its next step, they shouldn’t describe the solution but rather the need, problem and outcome (YES!). And another book I should prioritize – Salesforce Business Analyst Handbook;
Oftentimes, experienced functional consultants are asked to act as business analysts to run workshops, illicit requirements, and challenge the organization’s assumptions and old way of working. However, solid business analyst skills are distinct from declarative development on the Salesforce platform. While some functional consultants are great business analysts, not all are.
- deployment plan should include not just the pre/post deployment steps (still can of weird we need them these days when automated pipelines should handle everything) BUT also stakeholder communication plan – back to change management and the whole „project awareness“ topic which is hard to see in the wild. And I spoke with Ceska Sporitelna (in Czech) it is super hard as well as people don’t have really time to grasp any extra communication and are very often surprised later on that some features already exist and they don’t have a clue;
- speaking about communication, learning and documentation that’s one of the hardest topic I ever faced – as I always acted on the partner side, this was the typical area the customer didn’t want to pay for and rather do it themselves (but never had capacity to do so). Seeing what „training“ might/should include as everyone has different affinity to different learning methods gives me so many ideas, which would make the training the most expensive part of the delivery – workshops, videos, cheat sheets, one-pagers, FAQ, in-app guidance and all of that grouped by different personas and constantly updated. I probably know why at IrishDreamin the ClickLearn application won the demojam;
- when to transfer from hypercare to ongoing production support? As a partner we push into as soon as possible, seeing these four questions (have you aligned your processes, is the team trained and onboarded, are you reaching adoption targets, are you begin to achieve the business results you laid out) it should take way longer than what we typically aim for. But it is back to the KPIs you want to achieve, some of them are usually pretty long term I would say. And Kristian says kind of the same in the summary of the chapter, speaking about 1 – 12 months to begin achieving the results, not sure we should wait with go-live for that long;
Shield the development team from the Steering Committee meeting
- the continuous improvement phase after go-live and consideration to modify the partner model – different partner (due to different knowledge/experience), in-house combined with partner (and where is the line), full in-house or anything completely different;
- how to translate new feature requests into existing capabilities of your implementation and how to handle (limit/promote) the fact that as people start using the platform and learn more about the possibilities (out of the box, configuration, development) they will utilize the platform more;
All in all such a great book to learn how to deliver product into a company (yours or someone else). While there are references to Salesforce I don’t feel it is related only to SF, can be rather used by anyone.
Napiš komentář, díky!
