Introduction
Over the past few years I have helped a few junior consultants on their journey to deliver their first SuccessFactors module implementation and I thought I would share some tips and tricks I gave them from my experience so far (10 years in April 2022).
Have the right mindset
- Don't panic :
- There are complex requirements and/or technical hurdles in every implementation. Accepting it will help us find the confidence to leverage all different knowledge sharing platforms (Partner Delivery Community, Launchpad, Implementation guides…) and in many cases will make us feel less alone in tackling issues. After many years working as an implementation partner these challenging requirements will become the ones we enjoy working on because we know they make us more knowledgeable after the project.
- When a new issue is submitted to us we should always try to see the issue ourselves because sometimes words can't express correctly what is actually happening or the issue may be a process error instead of a configuration error. This golden rule has saved me a lot of time. Here is an example : a customer is reporting that the Executive Review Import Feature in Compensation isn't working as it should for the Merit recommendation column. We test and it is working fine as per our understanding which is that only the merit amount can be edited through that feature, not the merit percentage. However mass editing the percentage is exactly what the customer was trying to do and this loss of time (3-4 emails over several days) could have been avoided with a screen share as soon as the issue came up.
- We cannot build things if we don't understand : we need to have the customer walk us through their current processes (for example for Compensation and Variable Pay : examples in excel with the math of every calculation as well as confirmation of the effective date of the data that need to be used) and ask as many questions as it takes to understand the requirement. Not asking enough questions because we feel bad having to ask several times is going to delay failure because we won't be able to deliver something that works.
- Assess the situation:
- Do we think it is not working because we are lacking knowledge ? if so then we need to get help from a colleague as soon as possible and ask that colleague as many questions as possible to not forget how things are built.
- Or is this something we think we can tackle by tracing through the problem one step at a time ? (revert changes slowly until everything works again then add changes back until the issue is singled out / if nothing works we should try to be creative and compare different environments).
Time is key
- Anticipate and start implementing on day 1 of the project plan. Sometimes by anticipating early enough we bring to light significant integration issues (data is missing in another module and we need a colleague to fix it first). We don't want to be asking a colleague for help 2 days before the expected iteration presentation date, nor do we want to push back an iteration presentation 24 hours before. We also want to schedule quick checks and walkthroughs with the customer before Iteration 1 presentation to make sure what is being worked on is correct and avoid escalations at iteration 1.
- In case of a first implementation after obtaining the certification we should focus on the module out of several that we have never implemented before and not underestimate the complexity of specific parts of a module (eg. business rules in Employee Central or Variable Pay in Compensation which is much more difficult to implement than Salary Review and consumes most of the implementation time even for the most senior consultants).
Communicate to build trust
- At the beginning of a project it is important to create a human contact with the customer team, either by adding our video to all conference calls or preferably by being onsite for the first workshops.
- It's OK to say "I don't know" but there are better ways to say it, for example :
- "I would need to test and get back to you because I haven't used this feature in a long time."
- "I will prepare a demo of this feature with a summary of implementation options."
- Share meetings notes with highlighted action items (To do SAP / To do Customer) AND links to recordings (if any) with customers shortly after the call. Systematically recording all Teams or Zoom meetings and sharing them with my customers in a sharepoint folder they can easily access has made a huge difference in their adoption of the module. Notes and recordings also help us remember how things were built for a specific customer after we lose access to an environment.
- Avoid proposing a potential solution off the top of our head if we haven't tested it. Everything needs to be thoroughly tested before a customer makes a decision on it.
- If a specific pain point is brought up in workshops focusing on overall design, we should propose to schedule a specific call about it after the workshop and before the dedicated call first discuss it with the broader project team (including decision makers that may not be attending the workshop) to have the paint point confirmed. If the pain point is creating difficult discussions (for example a specific product feature is pointed out for what seems to the customer like a gap) we should avoid debating it with the customer during the session and instead make notes to discuss with the implementation team first (project manager and colleagues).
- When we start in this role we are often told that the workbook the customer fills with requirements (with our help) is a document we cannot deviate from during an iteration. My experience is different : a workbook is only a tool we can leverage to build confidence. The most important thing is to build trust in the system and provide hands-on experiences (especially in iteration 1) and if that means we need to deviate from the workbook then we should do so (as long as we document the change and the project team is OK with it). If a customer doesn't trust our solution after iteration 1 we will most likely need to work a lot more in iterations 2 and 3 to catch up. This means that defining a testing strategy for iteration 1 that the customer feels confident with and being available to help them test is almost as important as configuring the module. This is the Consulting part of our role as implementation partners.
Be efficient and look good on screen shares
- We need the right tools for the job. Since we make many screenshots every day we need a software that will automatically save all our screenshots without having to do "Save As" for each of them. Snagit does it but there are many others.
- Keep our desktop and browser favorites clean and organized, especially if we share our screen with customers a lot. Impressions go a long way.
- When demoing something to a customer in a call we should try to use only one browser and one tab at a time and go relatively slow in our comments and clicks so that the customer can follow more easily. I would even recommend this approach when working on implementation changes because it helps in better remembering the steps we just took (if we have 5 tabs open and constantly switch between them, chances are high we are going to forget a key step in the process and won't get the expected outcome).
- Last but not least : we should take good care of our demo environment. It's our best friend not only to troubleshoot issues but also to demonstrate leading practices or specific features without having to do too much preparation work.
Happy implementations !
Xavier
(If you found this blog useful please consider giving it a Like)
