What are Absolute and Big "NOs" for a Consultant to be Successful in an Engagement? - 3Ps & a Bonus "P"

 

1. Preconceptions
2. Prejudice
3. Talking About the Perceived Benefits

 

And your best friend is the 4th P - Preparation (An intense one)

As IT consultants and enterprise architects, delivering value in complex engagements requires more than technical expertise—it demands a strategic mindset that avoids common pitfalls and prioritizes client needs. This blog post, outlines three critical mistakes to avoid: Preconceptions, Prejudice, and Talking About the Perceived Benefits. It also emphasizes the 4th P: Preparation. This article expands on these principles from an IT consulting and enterprise architecture perspective, integrating best practices from modern enterprise architecture, particularly API-centric approaches, to provide actionable insights and examples.

1. Preconceptions: The Danger of Assumptions

Definition and Impact

Preconceptions occur when consultants assume solutions without thoroughly analyzing the client’s environment, needs, or constraints. In IT consulting, this might mean presuming that a specific technology, such as cloud computing or microservices, is universally applicable. Such assumptions can lead to misaligned strategies, wasted resources, and dissatisfied clients. For example, recommending a complete cloud migration without assessing data sovereignty or legacy system dependencies can introduce unnecessary complexity and costs.

Enterprise Architecture Perspective

Enterprise architecture demands a tailored approach, as IT landscapes vary widely across organizations. A key best practice, as outlined in 16 Common Enterprise Architecture Best Practices by digitalML (Enterprise Architecture Best Practices), is adopting an API-centric architecture. This requires understanding how existing systems can be integrated or exposed via APIs rather than assuming they must be replaced. Preconceptions about replacing legacy systems can overlook their value and disrupt operations.

Example

Consider a mid-sized manufacturing company seeking to modernize its supply chain management system. A consultant with preconceptions might immediately propose a cloud-based ERP solution, citing scalability and cost-efficiency. However, a deeper analysis might reveal that the existing system, though outdated, is deeply integrated with critical processes and customized to meet unique needs. A complete overhaul could be costly and risky. Instead, the consultant could propose exposing key functionalities via APIs, enabling incremental modernization while preserving stability. This aligns with the best practice of data-driven decisions (Best Practice #5), using system usage and performance data to inform strategies.

How to Avoid

To mitigate preconceptions, consultants should conduct comprehensive discovery sessions, leveraging tools like SWOT analysis, stakeholder interviews, and technical assessments. Creating a holistic catalog of the client’s IT landscape (Best Practice #7) ensures decisions are based on a clear understanding of the current state. For instance, tools like the ignite Platform can map APIs and systems, providing a data-driven foundation for recommendations.

Preconception Pitfall	Consequence	Mitigation Strategy
Assuming cloud migration is always best	Ignores data sovereignty, legacy dependencies	Conduct technical assessments, use API integration
Presuming microservices suit all projects	Overlooks organizational maturity, complexity	Analyze DevOps readiness, business needs
Recommending new systems without analysis	Disrupts operations, increases costs	Create holistic system catalog, engage stakeholders

2. Prejudice: Overcoming Biases

Definition and Impact

Prejudice in consulting involves biases against certain technologies, methodologies, or the client’s team, which can lead to suboptimal decisions and strained relationships. In IT, this might manifest as dismissing legacy systems as obsolete or assuming the client’s IT staff lacks the skills to adopt new technologies. Such biases undermine objectivity and collaboration, critical for successful engagements.

Enterprise Architecture Perspective

In enterprise architecture, prejudice can lead to favoring certain architectural patterns or technologies without due diligence. For example, an architect might prefer proprietary solutions over open-source alternatives based on past experiences, ignoring cost, flexibility, or community support. The best practice of treating all APIs as products (Best Practice #10) encourages a neutral evaluation of all system components, ensuring even legacy systems are assessed for their business value.

Example

An enterprise architect working with a financial services firm might have a prejudice against COBOL-based mainframe systems, viewing them as outdated. They might recommend rewriting the system in a modern language like Java, overlooking the fact that the COBOL system is mission-critical, well-maintained, and supports processes embedded in the organization’s operations. A more effective approach would be to modernize incrementally, perhaps by containerizing the application or integrating it with newer systems via APIs. This aligns with aligning business capabilities to APIs (Best Practice #2), objectively mapping system contributions to organizational goals.

How to Mitigate

Consultants should strive for objectivity by continuously educating themselves on diverse technologies and methodologies. Structured decision-making frameworks, such as cost-benefit analysis or alignment with business goals, can reduce bias. Respecting the client’s existing assets and team expertise is also crucial. For example, collaborating with the client’s IT team to leverage their knowledge of legacy systems fosters trust and ensures practical solutions.

Prejudice Pitfall	Consequence	Mitigation Strategy
Dismissing legacy systems	Ignores reliability, business value	Evaluate systems objectively, consider API integration
Bias against client’s team	Hinders collaboration, erodes trust	Engage team early, leverage their expertise
Favoring proprietary solutions	Increases costs, limits flexibility	Use structured frameworks, explore open-source options

3. Talking About the Perceived Benefits: Aligning with Client Priorities

Definition and Impact

This pitfall involves emphasizing benefits that the consultant perceives as valuable rather than those that matter to the client. In IT consulting, this can lead to a disconnect between expectations and reality, resulting in dissatisfaction or project failure. For instance, promoting advanced features of a new system when the client prioritizes cost savings or compliance can misalign the project’s focus.

Enterprise Architecture Perspective

Enterprise architects often face the temptation to pursue idealized architectures that may not address the client’s immediate needs. The best practice of improving API discoverability and reuse (Best Practice #8) emphasizes understanding what the client values—whether it’s cost reduction, faster time-to-market, or enhanced customer experiences. By framing solutions in terms of these priorities, architects ensure alignment with client goals.

Example

When proposing a new customer relationship management (CRM) system, a consultant might highlight AI-driven analytics and advanced integrations, which are powerful features. However, if the client’s primary concern is improving basic sales tracking and reporting, these features might be seen as overkill and not justify the investment. Instead, the consultant should focus on how the CRM streamlines sales processes and enhances data accuracy, while outlining how additional features could provide long-term value. This aligns with automated, flexible governance (Best Practice #11), tailoring solutions to specific client needs.

How to Align

Effective communication involves understanding the client’s key performance indicators (KPIs) and success metrics. By framing solutions in terms of how they impact these metrics, consultants can ensure proposals resonate with the client’s objectives. Regular feedback loops and validation sessions help maintain alignment throughout the project.

Perceived Benefits Pitfall	Consequence	Mitigation Strategy
Promoting irrelevant features	Misaligns with client goals	Understand client KPIs, tailor proposals
Focusing on idealized architecture	Delays practical outcomes	Prioritize quick wins, align with strategy
Ignoring compliance needs	Risks regulatory issues	Validate solutions against client requirements

4. The 4th P: Preparation—The Foundation of Success

Importance

Intense preparation is the cornerstone of successful IT consulting and enterprise architecture engagements. It enables consultants to demonstrate expertise, build credibility, and deliver value from the outset. Without thorough preparation, the risks of falling into preconceptions, prejudice, or misaligned benefits increase significantly.

Components of Preparation

• Business Understanding: Gain insight into the client’s industry, market position, and strategic goals.

• Technical Due Diligence: Assess the current IT landscape, including infrastructure, applications, and data.

• Stakeholder Analysis: Identify key decision-makers, their interests, and potential influencers.

• Solution Research: Stay abreast of industry best practices, emerging technologies, and proven methodologies.

• Risk Anticipation: Foresee potential challenges and develop mitigation strategies.

Enterprise Architecture Best Practices

• Holistic Cataloging: Using a unified catalog (Best Practice #7) to map APIs, systems, and capabilities provides a comprehensive view, essential for informed decision-making.

• Stakeholder Engagement: Focusing on enabling a small group of API stakeholders (Best Practice #4) ensures the architecture meets key players’ needs, building a foundation for broader adoption.

• Standardization: Implementing domain and information models (Best Practice #14) standardizes data and processes, facilitating smoother integration and reducing miscommunication risks.

Example

Before starting a digital transformation project for a retail client, an enterprise architect conducts extensive preparation. This includes analyzing the client’s e-commerce platform, understanding their omnichannel strategy, reviewing sales data to identify pain points, and researching successful case studies from similar retailers. Using a tool like the ignite Platform, the architect creates a holistic catalog of the client’s IT landscape, identifying gaps, redundancies, and opportunities for reuse. This informs a roadmap that addresses specific needs, such as improving mobile checkout experiences or integrating with third-party logistics providers, while planning for long-term scalability.

Conclusion

Avoiding preconceptions, prejudice, and misaligned benefit communication is critical for IT consultants and enterprise architects. By embracing intense preparation and integrating best practices—such as adopting API-centric architectures, prioritizing data-driven decisions, and treating all systems as potential assets—consultants can deliver tailored, value-driven solutions. As the digital landscape evolves, particularly with the rise of API-driven ecosystems, these principles become even more essential for driving successful business outcomes and building lasting client relationships.

Further Readings:

16 Common Enterprise Architecture Best Practices

HTH...

A Tech Artist 🎨

Navigating & Making Sense Out of Networking For AI/GenAI - Don't Be Fooled Yet Again by the Presentations Based Promises

 

While we have all witnessed highs and lows of AI, accelerated and fueled by GenAI in the last 2 years, where everyone in every industry including IT would assume You are stupid if you can't spell that out, yet there are very little concrete evidences put forward by business and technologies companies to fortify their claims and how fantastically they have been solving the problems which were not possible earlier at all or how they have taken a very transformation approach to solve them beside everyone in competition is left behind and hence "You should use our products and services", if you want to join that "elite group" as well.

Now there are perhaps enough talks, materials, white papers and podcasts which you might have come across at some point supporting that hype.

On the contrary if You speak with the real world practitioners (hard to identify and find) or me who don't easily get intimidated by the "shiny new tech", here are few things You may want to consider while picking up your:

1. Preferred Solutions
2. Preferred OEMs
3. Preferred Systems Integrator
4. Preferred Managed Services Provider 

Why Should I care ? - Well actually you should, See - If you are still looking for answers to these questions, You have likely missed the bus and is now trying to cope up with the industry and your competition. Or perhaps, it's a mandate given by business to your company's IT team, Product team and so forth.

Now you might have been playing with some of Gen AI capabilities either for fun or really seriously (outside mandates from business) using the public clouds, since its cheaper to play, test and throw/dismantle and do it all relatively cheaply, but in the absence of a firm "Strategy", you have either "underdelivered" or "failed" or perhaps "had little success" and want to leverage those learnings to further fortify your strategy and make course corrections.

Meanwhile the big management and IT consulting firms must have been reaching out to your Board, MD & CXOs claiming that they have successfully solved this puzzle and have enough evidences and credibility to showcase and telling you that you should now onboard them as partner to this endeavor into unchartered territories. It will only cost You few millions $$$ and 6-12 months of time to transform your business forever, And how you will be the next "MAANGx" - X being the latest addition to the group as You. Happy Ending !!!

What you either often forget or have a "dejavu" moment of is:

I have seen everything working perfectly on presentations earlier too beside from my partners - consulting firms, vendors, large public cloud providers, systems integrators or managed service provider telling me how they are putting their credibility and life on the line for me to be successful. 

So remember, as an enterprise (small-mid-large) You have:

• A large baggage of your technical debt 
• Absence of  strong and foundational architectural + design practices within IT, though on paper everyone claims they have
• Believing this time Your partners in crime won't ditch you or would leave you in the middle
• No incentives to put together a good solution but a solution that serves the immediate needs/mandates, it always works like that in Enterprises and Telcos, later you can blame it on - pace of technology change, people issues, process issues, technology issues, urgent needs etc...
• Hiring smart people only solve half of the problem at best ...ever

So rather ask your "Partners" to move beyond the presentations, market research data and help you with:

• A short-mid terms AI strategy 
• What accelerator's, assets, frameworks, reference architectures, models, test results they have in place to expedite the whole process with speed and agility and yet minimizing the risks
• Show, don't tell about - Your experiences (Industries, scale, labs, poc/pilot, expertise & depth, partner ecosystems with level of innovation/MVPs, success stories that you can validate yourself beyond the presentations
• Help build a strong and evidence based business case with ROI instead of just a bunch of excel sheets thrown on you
• Can they do a BTO (Build, Transfer & Operate), Org. wide AI upskilling is a long uphill battle which most are loosing without admitting at this point 
• Choice of consumption models (IaaS & PaaS), don't pour all your money into promises

And at last, the technical details around:

• Clear cut business cases
• Supported models (small, large, multi-layer, multi-tier)
• Accuracy (data) & course correction methods + Architectural tradeoffs
• Supported vs. required integrations
• Quality and controls
• Runtime environments
• Performance boost methods, metrics and measurements  
• Dev vs. Test vs. Production pipeline
• Tokens (Free vs. Paid, How many, Cost per token, Cost breakdown per token use, Length of Prompt/Description, Error rates)
• Hallucinations
• Privacy, compliances and regulations 
• Sustainability footprint (ESG metrics and Power needs)
• Investment protection 
• High level and tentative cost + efforts for each level of customizations
• Adoption roadmap, milestones, success metrics and RACI
• Governance & risks mgmt.
• Cost management, quality assurance & ROI
• Program structure & stakeholders

And next time when you read about - how "X/Twitter" has put together a data center running 100K+ GPUs in just 19 Days - Remember you are not "Elon Musk" and most likely your company don't have one either beside the risk appetite that "X" has is far bigger. 

But otherwise, all You know are the execution details, behind the scenes how much time and effort they have put in for coming up with a strategy and plan is what you no clue about, beside they are known for they high standards and hence they became this big. 

But if you think "strategy" is something you can fully "outsource", you are bound to learn your lessons sooner than later.

So stay grounded and keep it real. 

HTH...

A Tech Artist 🎨

Further Readings

Elon Musk Has Activated the World’s ‘Most Powerful AI Training Cluster.’ It’s Equipped With 100,000 Nvidia GPUs

Nvidia eyes data center Ethernet as its next multi-billion-dollar biz

Incorporating generative AI into your company’s technology strategy

Amazon, Google make dueling nuclear investments to power data centers with clean energy

AI and its carbon footprint: How much water does ChatGPT consume?

Meta's Mark Zuckerberg says energy constraints are holding back AI data center buildout

Why Zuckerberg’s multibillion-dollar gamble doesn’t just matter to Meta

Meta loses $200 billion in value as Zuckerberg focuses earnings call on all the ways company bleeds cash

Has the AI bubble burst? Wall Street wonders if artificial intelligence will ever make money

The AI bubble has burst. Here's how we know

Shiny object syndrome

Bonus Materials For GenAI Enthusiasts From Web - Credit to Original Creators  

What Your Mamma Never Told You About "Asking So Many Questions" - A Short Perspective By An Architect

Architects often exhibit a propensity for excessive questioning, a characteristic perhaps inherent to their training in making rational and informed decisions. However, their education frequently falls short in equipping them to navigate the VUCA (Volatile, Uncertain, Complex, and Ambiguous) landscape and the inherent ambiguity that often pervades project requirements. Consequently, architects tend to seek definitive answers based on known information, overlooking the potential value of questions that can significantly impact project outcomes.

Beyond technical expertise, architects should possess a broader perspective, capable of zooming in on intricate details while maintaining a holistic view of the project. This requires a diverse toolkit, encompassing not only experience and humor but also the ability to effectively communicate and collaborate with stakeholders across various levels of technical proficiency.

In the dynamic world of IT, effective communication between architects and stakeholders is crucial for successful project delivery. However, a common pitfall is the tendency for architects to demand excessive detail and clarity from stakeholders, often overlooking the nuances and complexities of their perspective.

Understanding Stakeholder Perspectives

It's essential to recognize that stakeholders may not possess the same level of technical expertise as architects. Their primary concern is often to achieve specific business outcomes, rather than delve into intricate technical details. Additionally, stakeholders may have varying levels of understanding of the project's scope and constraints.

The Importance of Contextual Understanding

Architects should strive to understand the broader context of the project, including the business objectives, constraints, and potential challenges. This will help them tailor their communication style and provide more relevant information.

Multiple Paths to the Same Goal

It's important to remember that there are often multiple ways to achieve a desired outcome. While architects may have a preferred approach, it's essential to consider other viable options and be open to different perspectives.

The Evolving Nature of Requirements

In today's rapidly changing business landscape, requirements can evolve over time. Architects should design solutions that are adaptable and can accommodate future changes.

Navigating Ambiguity and Uncertainty

Stakeholders may intentionally introduce ambiguity into requirements for various reasons, including fair play, commercial negotiations, or to foster creativity. Architects should be prepared to handle such situations effectively and seek clarification when necessary.

Effective Communication Strategies

To bridge the gap between architects and stakeholders, consider the following strategies:

1. Active listening: Pay close attention to what stakeholders are saying and ask clarifying questions to ensure understanding.
2. Plain language: Avoid technical jargon and use clear, concise language that stakeholders can easily understand.
3. Visual aids: Use diagrams, charts, and other visual aids to illustrate complex concepts.
4. Iterative approach: Involve stakeholders throughout the project lifecycle to ensure that their needs and expectations are met.
5. Prioritize information: Focus on the most critical details and avoid overwhelming stakeholders with unnecessary information.

By adopting these strategies, architects can foster better communication with stakeholders, leading to more successful projects and improved outcomes.

Further Readings:

The Architect Elevator — Visiting the upper floors

When Asking Too Many Questions Undermines Your Leadership

How Mindfulness Can Help Engineers Solve Problems

Navigating Ambiguity: Creating Opportunity in a World of Unknowns

Mastering Uncertainty: How to Thrive in an Unpredictable World

Thinking In Bets

Thinking, Fast and Slow

Leading in Ambiguity: How to Transform Uncertainty into Possibilities

Six Simple Rules: How to Manage Complexity without Getting Complicated

Cracked it!: How to solve big problems and sell solutions like top strategy consultants

What's Your Problem?: To Solve Your Toughest Problems, Change the Problems You Solve 

Upstream: The Quest to Solve Problems Before They Happen

Consulting Myth Busting - They are very good problem solvers

 

Though Consulting and Enterprise Architects comes in many shapes and sizes, one of the common misconceptions I often hear and have to address is - "They are better problem solvers, specially if problems are complex in nature".

 

I politely disagree.
 
They are often people who are better "Problem Framers" beside "System Thinkers".
 
Few things for You to consider:
 

1. You may still be solving the wrong problem.
2. You are still forcing yourself to solve problem which might be multi-dimensional/discipline in nature. So you can at max fix your part of the problem only. (Outputs not outcomes). Many just unintentionally do it to grow their pride and be seen as heroic.
3. There are only probably 2 books in the market You can find on problem framing, you can still find 100s on problem solving.
4. You really need to practice hard to win against your own conscious/unconscious bias.
5. You need to fight against the status quo (Your environmental needs to be successful).
6. You got to be expert at everything and yet you are not an expert at anything. (You will only get this point if You have lived through it for real).

If you are deeply in love with any particular discipline or is passionate about, You are not really a consultant. Find a better word for yourself and your identity.  

 

More on problem framing and why It doesn't really matter in 99% cases in the future post maybe.

HTH...

A Tech Artist 🎨