Continuing on as part of the Admin2Consultant series, Ben and I decided that we want to try and paint a picture of as many angles of a consultant’s life as we could, in order to help those considering the move to becoming a consultant, assess every facet.
One of the best ways we thought we could do this, is to write a ‘day in the life of’ for each of our days to show how broad a consultants role is and also to showcase the disparity of tasks expected from consultants, amongst consultancies.
We hope that this helps to highlight to those considering the move that it’s not only the industry, knowledge, skills and the platform you will need to research, but also the firm itself to make sure that it’s the right fit for you.
Below you can find a rough timeline of what a typical day on client site might look like for me personally. Whereas it’s quite easy for me to give you a timeline, what isn’t so easy for me is to give you a description of the activities and tasks that I might be carrying out while on site as they are so broad. I hope that this gives you some useful insight.
A day in the life
06:55 – Leave Dalston; 277 to Highbury & Islington (start clearing inbox), Victoria line to Oxford Circus, Bakerloo line to Marylebone
07:48 – Train to Bicester North (clear inbox, configure, troubleshoot, produce materials)
08.37 – Taxi to client site
08:55 – Arrive on client site
09:00 – Meeting number 1 / troubleshoot / configure / write user stories
11:30 – Meeting number 2 / troubleshoot / configure / write user stories
13:00 – User training session (try and squeeze lunch in here or wait until 3)
15:00 – Ad hoc meeting / troubleshoot / configure / write user stories
16:00 – Create backlog for train journey home
16:55 – Taxi to Bicester North
17:16 – Train to London Marylebone (clear inbox, produce business process maps, user stories, do admin, troubleshoot, configure)
18:15 – Bakerloo line to Oxford Circus, Victoria line to Highbury & Islington, Overground to Dalston Junction
19:15 – Arrive home
Meetings – Here it’s hard to quantify what I might typically be expected to discuss in meetings, but a range of topics and a description follows.
By far and away my most common type of meeting will be a requirements gathering session. I may have to meet with a range of potential users, mid or senior level management to gather their requirements and desires for how the system should operate. These sessions can range anything from 1- 4 hours and have been known to go on all day. These will be intense sessions where I am required to drill down into an extremely low level of detail, steer and drive the conversations towards the gaining the essential information that I need to configure the system.
While on smaller projects I may be steering and dictating the direction of the projects, on larger projects I will typically need to be present as a member of the ‘project steering committee’ or something of similar ilk. This is to report on my progress for the role that I am playing in that particular project. These meetings may require me to report my findings, outline potential risks and suggestions for risk mitigations, solutions and also provide input to project timelines and roadmaps. Again, these sessions are typically quite intense and tend to involve the more senior levels of management (C – level or directors of the board), but do tend to be shorter in length due to the nature of their participants.
Those familiar with Agile methodology will be familiar with the famous daily stand-up, whereby the development team and the scrum master are required to report on progress achieved over the course of the previous day, any potential blockers for the day ahead and the progress that they hope to make over the day ahead. Here, the persons present are normally required to speak in a high level of functional or technical detail and will be more concerned about the lower, more granular levels of detail. These meetings are typically no longer than 10-15 minutes long.
Troubleshooting & Change Requests
These can be my favourite or my most dreaded type of meeting. Always ad hoc, almost always cognitively testing, but certainly, never, ever, the same. Here, I’m normally faced with a problem from a client looking to solve either a ‘bug’ or more likely, presented with a new ad hoc requirement (change request). Sometimes these queries can be easily solved and the user isn’t aware of a piece of functionality or needs a brief bit of training to help them work out how to solve their problem in the system. These requests are normally satisfying as users are always very thankful to have you give your time to help them make their lives easier. At other times, the problems can be far more taxing and can take days of thought, a number of consultants/developers to create a solution, workaround or deliver an extra piece of functionality to solve a users request. Again, here, it’s generally quite satisfying to deliver that end solution and receive the gratitude of the user base, but be warned the perils of always delivering solutions to ad hoc problems, you may end up delivering far beyond the scope of the project before you know it!
The challenge I find with training, is trying to make it exciting and engaging. While this is easier with more exciting pieces of functionality or development, I always find it hard to engage users with the most basic level of training on Salesforce functionality. Here you will almost always be exclusively training the end user base, but it’s also fairly common to train mid and senior level management on reports and dashboards. The way you need to adapt your communication skills to convey information to each person across all levels of hierarchy and find the best way to get them to absorb information should not be understated here.
I left my favourite to last. These are the sessions where I get to really flex my grey matter and Salesforce consultancy skill set. For me personally, there’s nothing I love about my job more than sitting in a room with a couple of consultants / developers / architects and designing functional and/or technical solutions to meet our clients requirements. This is where my core knowledge about the platform is tested, where I learn and upskill myself the most from my colleagues and is also the point where I identify areas where I need to improve my platform knowledge.