The Importance of Context in Consulting
As a consultant, I am often brought into projects that are already underway. Typically, I am not privy to the initial kick-off discussions, the full project scope, or a complete understanding of all the stakeholders involved. My role is often “constrained” to a specific aspect of the project, and the clients usually provide information and context only for that particular piece.
While this approach makes sense—it is efficient and focuses on leveraging the consultant’s expertise—it also has a downside. Without a broader understanding of the project’s context, my deliverables can sometimes be sub-optimal, lacking alignment with the larger objectives.
To illustrate, I’d like to share two examples from my consulting experience.
Example 1: Navigating Resistance Without Context
In one project, I was tasked with building a new data warehouse from scratch using a modern database technology. The existing codebase was poorly documented, and I was told that no additional documentation existed. The business team was not cooperative, leaving me to rely solely on the codebase to understand the requirements. I diligently translated the entire codebase into the new database platform. When it was time to test the new system, the business team continued to be unavailable. Their lack of engagement was stalling progress.
Under pressure from my manager, I worked extra hours to perform the verifications myself. I compiled the results and sent them to the business for sign-off, but after a week without any response, I escalated. I shared the verification material with all stakeholders, including their Chief Information Officer, and requested that the project be closed unless objections were raised.
This prompted a meeting with their IT coordinator and the manager of their data applications. It was in this meeting that I finally received the missing context: the business team was resistant to the new system. They felt it was being imposed on them without adequate support or change management. They were already proficient with the existing platform and saw no immediate benefit in switching to the new one.
Armed with this new perspective, I made adjustments. I prepared a simple document comparing the old and new systems, highlighting key queries and demonstrating the added functionality of the new database. For instance, the new system allowed users to load only specific tables, significantly speeding up analyses. I organized a meeting to walk the business team through these changes, answer their questions, and address their concerns.
This time, the response was different. The business team engaged, validated the new system, and even expressed enthusiasm for its features. By understanding their perspective, I was able to bridge the gap and ensure the success of the project.
?
Example 2: Recognizing When to Step Back
In another project, I was brought in to support a newly formed team of business analysts at an SME. The team included market experts who were technically skilled and capable of gathering and assembling data to support the analysts. However, their workflow was somewhat chaotic—Excel sheets were being shared via email, leading to inefficiencies.
My task was to streamline this process by providing structured data to the analysts. At the outset, I was given the broader context and observed the team’s interactions for a week. What I noticed was that, despite the apparent inefficiencies, the team was highly collaborative, comfortable with their processes, and productive. Introducing a layer of data governance or formalized processes, in this case, would likely disrupt their workflow and slow them down.
领英推荐
I shared my observations with the project lead, suggesting that the team might function better without my involvement. While this was a risky move—I risked losing the project—I felt strongly that my involvement would not add value and could even create frustration. The project lead appreciated my input, confirmed it with the team, and decided to proceed without additional data governance.
Interestingly, this decision led to a positive outcome for me as well. The same project lead referred me to a colleague who needed a data engineer for her project. That engagement lasted a year and resulted in a fulfilling experience where I delivered significant value to the analysts.
?
The Takeaway: Context Is Key
These experiences highlight an essential truth: context is crucial for consultants to deliver optimal results. Without it, projects can suffer from misaligned priorities, stakeholder resistance, or inefficiencies.
As consultants, we often have to work within constraints, but there are steps we can take to mitigate the challenges posed by a lack of context:
?
Consulting is not just about delivering expertise—it is about aligning that expertise with the client’s unique environment and objectives. By seeking out the larger context, we can navigate challenges more effectively, thus unlocking value for the client and transforming the consultant's work into an engaging and rewarding experience.
?
?