Fishing in the Workday Ecosystem

Too often in the consulting world I see engagements that feed a client temporarily but do not emphasize teaching them how to feed themselves. We all have heard the old adage, 'Give a man a fish feed him for a day, teach a man to fish, feed him for a lifetime.'

Regardless of how you feel about fish (I'm a fan), you would think that leaving a customer with the ability to prevent issues and to troubleshoot their own processes would be a good thing right? That customers who know more about the product that they are implementing would be more satisfied and more competent at an earlier stage than customers who do not know as much.

Why then does it seem like teaching someone to fish is not always or even often the case? I think that there are a few reasons why we just keep handing the customer another fish or why we as a customer just keep eating that fish and then when we are hungry again buying another one.

Many consultants have no training or education background. They themselves are highly trained and often highly experienced but they have probably not participated as facilitator or an educator in training or knowledge transfer sessions in the past. They may not feel that they are qualified to conduct an ad hoc or impromptu training.

There are time pressures in most engagements and most Statements of Work do not allow for or set aside time and resources for knowledge transfer. The assumption is that the customer will get their training from a training resource such as the vendor or from more experienced members of the customer project team. As a customer you may not be setting aside time or resources in the project for knowledge transfer.

Customers may not appreciate how powerful and important contextual knowledge transfer is in terms of accelerating adoption, ROI, and reducing issues with the implementation/conversion. Bite sized knowledge transfer delivered in the context of an issue is often more meaningful than classroom lecture and theory.

Finally it appears that budgetary and time away from project considerations mean hard decisions as to who is to go to training, what we fail to realize often however is that we have resources available to receive less formal but often even more critical training as the project unfolds.

So how can we move from giving a fish to teaching a customer how to fish? How can we as a customer move to paying for each fish separately and not paying instead for the secrets of how to fish? I think there are some steps we can take that will add this kind of value to the engagement and not put us behind the Eight Ball when it comes to the timeline.

Document important or significant issues and fixes or workarounds. Take the time later, if you are pressed for time now, to 'flesh' out the scenario as if you were going to use this as learning lesson. Take a screen shot, write some text, link back to imbedded help or documentation if available. If you cannot engage the customer in a delivered knowledge transfer right now (the lesson is most powerful when it is contextual) then save it for later when you can. As customer demand documentation. If there isn’t time to document a complex workaround or fix or solution then there isn’t time to deliver the solution. When it ‘breaks’ during the next release you will wish you had the documentation. Knowledge transfer around the issue is so much easier when there is documentation.

Don't disrupt important processes in order to deliver the training, unless the issue is critical enough to warrant a 'side bar'. An example might be a production critical issue or error that the customer made and will likely make again if they do not understand why it is so important and how what they are doing relates to the overall project success. Customers don’t walk away with the vague promise that this will be addressed later if you are not comfortable with what is happening. It is YOUR project and your employees who will have to suffer if YOU don’t know what just happened, whether it will happen again, or how it all fits together.

As a consultant you may need to 'eat' some hours for knowledge transfer if the Statement of Work or Project Scope does not allow for it. You may decide to do this because of the impact on the overall success of the project and the customer's end satisfaction. As a customer you may need to repurpose or even pay or some more hours if you are demanding appropriate knowledge transfer throughout the project.

A customer that is 'live' but has been given few tools to do their own troubleshooting or dealing with issues may well be the 'repeat' customer a consulting organization is looking for but they won't be a happy customer or a referable customer and they may well 'vote with their feet' and find someone else to partner with if they feel that they have been fed too many 'fish' and not given the opportunity to learn to fish for themselves.

Training doesn't have to be formal. Knowledge transfer can occur throughout the project. The more you do it the better and more efficiently you will be able to do it and you can often re purpose the job aids and screen captures and videos you have created to use with other customers. Learning how to train and educate will only make you a better consultant. Customers don’t lose sight of the forest for the trees, going ‘live’ is critical, meeting deadlines is critical, going live on time if you don’t know what to do with the application once your consultants leave is a recipe for disaster.

Let’s learn how to fish, sure it can get kinda messy when you have to clean them but do you really want to pay someone to come and deliver a fish to you every time you are hungry?*

*No fish or worms were harmed in the writing of this blog.