Consulting Footprints, Part 1
This topic has been on my mind lately.
As Consultants, or even staff, working in a Client’s Salesforce environment, we leave behind the tell-tale traces of our presence. Once we’re no longer working in that environment, whatever the reason be, someone else will likely be stepping in. What they see as evidence of our time in that org are the footprints we leave behind – our legacy and what those clients will say about our work.
Recently, I’ve found myself in more than one Client’s Salesforce org trying to decipher work left behind by previous consultants, staff or others – sometimes with far more frustration than I’d like. I’m positive that no one would ever want their past work to be looked upon as poor quality or sloppy.
Full disclosure – Though I’d really like to think everything I’ve ever left behind is perfect, I know better. There’s no question that over my many years of work (including pre-Salesforce) there are absolutely areas where I did not fully document or go into as much detail as I probably should have.
Many times I will ask a client “What is this object or field used for”. More often than not, the response is “I’m not sure”. They might know how the system is used at a functional level, but they are not familiar the underlying architecture that drives the functionality. I can’t tell you how many times I’ve seen objects with multiple custom fields that are undocumented and no one has any idea what they do or why they’re there. Sometimes those fields are referenced by a workflow rule or process, but tracking that down (without Ant) can be quite challenging and time consuming. Imagine a client having to do that within their own Saleforce org because the consultants who customized Salesforce for them did not fully document their work. What will that client say about the footprints left behind – the consultants’ legacy?
|The next post will detail out some recommendation on leaving behind a very nice looking set of footprints.|