In July 2021, Paul Harris, Coacto\u2019s principal consultant joined the Consultancy Dreamin\u2019 line up. Within his Experience Tract session, Paul shared some of his most valuable Salesforce ecosystem experiences and focussed on the things you might not be expecting when delivering consultancy services. <\/p>\n\n\n\n
It felt right to share each and every tip mentioned in Paul\u2019s session on our website and this week, we\u2019re going to explain the importance of expecting change.<\/p>\n\n\n\n
Our experience across a whole variety of projects is that requirements are very rarely set in stone. Picture this; businesses, particularly fast paced or fast growing have moving targets which can make decision making rather challenging. The same goes for having the focus and the right amount of spare cycles away from the business as usual to get a project off the ground. Businesses who will be working with a Salesforce consultant, will always have choices to make and that\u2019s why it\u2019s important, especially for us to expect change and (try to) be prepared for any eventuality. After all, even the best projects that have been planned with all scope defined and documented, will experience changes to plans, scope and delivery.<\/p>\n\n\n\n
Managing change<\/strong><\/p>\n\n\n\n On a recent very large project for a pharmaceutical company, significant changes of direction were presented to us during a Salesforce, ERP and SAP integration project. In particular the SAP project was taking significantly longer than expected to complete. We had to push outputs from the Salesforce ERP system into SAP, and pull back data from SAP to update the ERP system. With significant changes in the SAP project, the requirements and interfaces for our integration to SAP were changed five times, in flight too, resulting in significant re-design and re-work. It\u2019s important to note that our team remained on the project and worked with the company to manage the changes effectively until the project was completed successfully.<\/p>\n\n\n\n A good technique that we use with our customers’ requirements is the MoSCoW technique. This process allows our development and implementation team to work directly with a customer to prioritise requirements such as Must, Should, Could<\/em> and importantly things that Won\u2019t<\/em> be done.\u00a0 It\u2019s great practice for us to get decisions or specific instructions that may not be in the best interests of the project, or likely to cause ramifications in the future in black and white too.\u00a0 We also use this technique for any changes which may be suggested for a project so that we can assess whether a requested change is the right choice.<\/p>\n\n\n\n We understand that our customers will change their minds and accept that new requirements can appear out of nowhere and sometimes at the last minute. James Dyson built 1000 prototypes of his first vacuum cleaner because only when he had designed, built or tested something was there a change apparent. That doesn\u2019t mean you have to agree to the change. Timelines, budgets, impact, resources and other factors can determine whether change is needed now. If you don\u2019t make the change, recognise that you are storing technical debt. Have a process for revisiting proposed changes, record the outcome of any discussions around a go or no-go options and take it from there.<\/p>\n\n\n\nWe understand why changes happen.<\/strong><\/h2>\n\n\n\n