When you have two entities, you have two differing opinions. Two sets of goals. Often these don’t align, and as a result, you have a clash.
Nowhere is this more apparent than during a business transformation that involves technology. When Business and IT stakeholders silo themselves apart, delays and misunderstandings inevitably arise, as do tempers. There is the predictable finger-pointing, as well as the persistent constant challenge to accomplish anything effectively in a way where both sides are happy.
Ultimately, it’s the project that suffers.
The Problem with Tribalism
When you let people take sides, you’re left managing tribalism. Both IT and Business see the project in vastly different shades. IT sees the project as a purely technology effort to make some combination of hardware and software work. Business sees it as a magical “plug-and-play” where they get to give a wish list of functionality that will, of course, always be built as conceptualized so that, afterwards, they can go about their business, pun or no pun.
In reality, any project that involves core operational change through implementation of different tools should really be considered a business transformation project enabled by technology. That’s the mantra. It’s about one team and one vision.
Seeing it this way is a big ego hurdle for those folks who want to prioritize getting the project done to meet solely their needs, regardless of the associated dependencies or work to support the larger enterprise ecosystem.
So, assuming that no one side “wins” on any transformative project, but rather that all win or lose together, how can you better break down the silos that both tend to naturally create?
1. Admit There’s a Problem
Naively thinking that Business and IT teams will always get along without a little effort and tender love and care will doom your project from day one. It’s normal for any two factions to have opposing views, so acknowledging this from the start will go a long way to easing the ensuing headache.
Get feedback on what the concerns and pain points are from both teams early on so you have a clear understanding of how to bridge their apparent divide. Some divides may not be merely apparent, but to keep your sanity, initially take the stance that in most instances everyone will end up doing the right thing for the larger good once they all understand what that is.
2. Have A Business Lead For All Seasons
Since the assumption here is that we’re dealing with a technology-heavy project, typically IT will be in the driver’s seat unless conversations already have been had. Assuming they have not yet occurred, you will need to have them to ensure that someone from Business is appointed to be the Business champion as part of the project leadership team, whose role will be to fit the tech solution to the Business needs and Return on Investment (ROI).
What we don’t want is merely a fancy technology solution that can do many wonderful things. We are embarking on a transformation to deliver a better technology tool that enables the right people following the right processes to do their jobs more effectively.
To be maximally effective, this Business Lead should have good relationships across the impacted Business departments and stakeholders, and ideally have fairly good relations with key Technology stakeholders. After all, the Business Lead is the foundational bridge between our two IT and business silos. Through thick and thin, through the good times and the crises, the Business Lead’s job is to ensure continued support and engagement from the community of leaders and users that will have to live with the new solution for years to come. To that end, the Business Lead must be properly empowered with the agency and authority to make decisions, deals, trades, compromises, and anything else required to deliver project success for the Business without alienating IT.
3. Align Final Project Objectives To the Technology
When it comes to Final Project Objectives (FPOs), Business typically focuses on the ROI since it frequently funds projects, being the profit center. On the other hand, IT, being a cost center, is usually concerned with delivering features to spec and moving on to the next project, as they have many Business customers to satisfy.
Being misaligned about the FPOs can further encourage tribalism. The FPOs shouldn’t be purely IT or Business-focused and should, instead, bring in everyone to educate them on what they are doing on the project and why they’re doing it. Map the ROI to actual process improvements, both within the system, and outside the system. Map headcount avoidance opportunities to specific automations, steps reductions, better analytics that require less manual effort, and faster decision making. In short, get as granular as possible to trace the impacts of the transformation across people, process, technology, and data to the FPOs and overarching ROI so a common understanding of which features of the solution are critical for success and how technology empowers the business to attain its goals.
By doing so, you show both sides the value of the project, create objectives they can buy into, and unify your team to adopt one project mission statement.
4. Keep the Lines of Communication Open and Deliberate
It’s not enough to say you need a set of strategies for connecting Business and IT. As we all know, culture eats strategy for breakfast. If these silos are an ingrained part of your company’s culture, unless you get clever, you’re going to be slogging uphill like Sisyphus pushing the rock.
You must understand the culture of your environment so you can adapt your stakeholder management strategy to succeed in that particular culture.
Communication needs to happen at every level and at every phase of the project. Start at the top. Extended team leaders need to know the bigger picture of what’s going on in the project, and so do the regulatory or compliance stakeholders. Without bringing them all into the fold, you will surely suffer further rifts and divisions along your journey among key stakeholders and the troops on the field.
And speaking of those troops, you need to understand that each team sees the project through its own lens and pull them out of those biases.
On the Business side, it’s all too easy to make a giant list of requirements and throw them at IT without giving the why it needs these functions. There need to be conversations about how Business will use the end solution so that IT understands the purpose around what it’s building. At the same time, it’s important to enable the Technology groups to manage the architecture and build, and to resist the temptation by Business to dictate the ‘how’ of realizing the requirements.
On the IT side, what sometimes happens is that teams develop in a black box. IT takes the requirements from Business, then the IT teams disappear for months and come back with a built solution that isn’t in line with what Business actually needs.
The more touchpoints there are with end users, line managers, and leadership through all stages from design through release, the better your results will be.
5. Know That Proactively Managing Change Impacts Is a Core Function Of A Business Transformation
So how do you change the culture of how things have always been between the two factions? Having an integrated Organizational Change Management (OCM) approach from the beginning is the key. Some people think OCM is simply sending newsletters and at the very end of the project training team members. In reality, when it is properly implemented, it’s constantly course-correcting and explaining why various changes need to happen for the greater good of the project and the enterprise. It’s managing resistance, coaching and process clarification for both Business and IT, monitoring team dynamics, and gathering new information. It is a highly iterative adaptive process to integrate the various moving parts of your business transformation. After all, the fundamental goal of integrated change management is to ensure that Business stays engaged throughout the project, and that IT keeps listening to Business so that those FPOs remain aligned with where you were when you started.
It requires constant vigilance and driving agreement, not just between IT and Business teams on the project, but also among their respective leadership groups. Talk about what is working, and what isn’t. Have conscious transparency. Change management requires flexibility, something we all rail against at times, but know that ultimately it is the best way forward.
Bring IT and Business reps to the table when you start the planning and design process and make sure there are people present from both teams at all meetings. You may get resistance (“I can’t spare my Lead right now.”) but stress that it’s good for the project and that it creates more trust and better dialogue.
General awareness of what’s going on is okay, but a specific understanding is the goal. Part of communication is ensuring that everyone in both IT and Business can answer questions like:
- Do you know what the final objective of the project is?
- Do you know what business process you’re building this for or how that process works?
- Do you understand what roles will be involved in the new business process?
- Do you know who on the project owns this process? Have you talked to them?
- Do you understand how your job or function will change as a result of doing things the new way?
6. Foster Relationships of Respect and Care
It may seem a little touchy-feely, but how you deal with interpersonal relationships is key in breaking down those silos. Especially if you have contractors outside of the company, as they can create their own tribalism.
Your entire project team should be one little happy productive universe. Spread that religion. Encourage team members to forget where they came from or where they feel their loyalties lie. This isn’t high school.
Still, despite your best efforts, you’ll find that cliques will still form and tend to congregate together. You have to make an active, concerted effort to continuously have a cross-functional dialogue. Host team dinners or happy hours to mix IT and Business teams, as well as draw in those contractors.
Speaking of those contractors, make them feel like part of the family from the start. Treat them like new employees and work to erase the lines that often occur between internal and external staff. They are, after all, just as important to the project. Let them know that.
Develop relationships both with the team as a whole, as well as individuals. This gives you insight into who they are as people, not cogs in the wheel. Those one-on-one relationships will be instrumental in moving the project forward, especially during the tough periods, because once you know people, you can play to their strengths and help them shine, which, in turn, helps the project succeed.
It is also imperative that leadership takes enough time and effort to recognize accomplishments by team members, especially cross-functionally. When you praise collectively, you minimize that divide. It’s easy to get bogged down in the day-to-day, but realize that appreciation is motivation.
Our base instinct on a project is to hunker down and focus, and to skip over the soft stuff, but it’s important to connect to people on a human level so that you are able to break down those silos.
7. Think About Business Process Debt
We talk a lot about technical debt, which happens when you build a solution too quickly only to realize those shortcuts will create technical issues down the road. But what about business process debt?
To avoid it, make sure the new business process maximizes the efficiencies and capabilities of the technology, and on the flip side, that the technology architecture is sufficiently flexible to support changes and evolution of the business process so that your solution has some measure of being future proof.
Rather than deploying a new technology just to end up falling back to old ways of doing things, ensure that you have actively focused to calibrate the business process to maximally take advantage of the new technology capabilities. Pay special attention to the organizational structure to make sure you have clearly defined the hierarchy of roles and handoffs of who does what in what order, who authors, who approves, and what information is available to whom throughout the process.
Organizational structure changes tend to be harder to alter once put in place, so use the transformation project as the opportunity to optimize in this domain. Ultimately to avoid business process debt, end-to-end process design from first principles should be the starting point, and existing constraints, limitations, or integration with other processes should take place as the secondary fit-gap, not the other way around.
Technical debt is ultimately much easier to fix than “process debt.” Once people start doing things a certain way, they create data according to that process, which creates reporting based on that process, and it creates habits based on the process. Tech debt happens “under the hood,” so in some sense it’s invisible to Business. But business process debt is almost always impossible to get rid of unless you do another transformation project, as it affects every user, leader, and report recipient.
8. Don’t Get Stuck In the Past Because You’re Managing The Future
You created a plan, and you’re sticking to it, darn it. While, yes, your plan is useful as a map in guiding the direction of the project, but remember the map is not the territory. A plan shouldn’t be carved in stone but only be so firm as to be useful. Review requirements constantly to ensure they haven’t changed or become irrelevant. Along the journey of a nine-month timeline, you may end up realizing you’re working on a set of nine-month-old goals. Some may not be completely relevant anymore, so be ready to be brutally flexible if you need to cut scope or change course. Technology changes rapidly. Economic conditions can flip at any point. To drive success it is critical to instill a habit among your Business and IT teams of a forward outlook and a culture of courage to recognize if circumstances have changed that the project must inflect appropriately.
A related need is to continually get team members to re-engage and leaders to recommit. Investment in and support for the project isn’t a permanent guarantee, and emotions will shift how willing a given team member or leader is to giving it their all.
Old silos will always be found, and new silos are going to pop up naturally, and it will take continuous effort to break them down. But doing so has immense benefits for your project, as well as for team morale.
9. Do What’s Best for the Company
Have the flexibility and openness to imagine doing things a different way if it makes sense. “How” you get to the solution matters less than getting the “what” and the “when” you’re seeking. This requires courage and innovative thinking, but ultimately is the key to success. Your process may need to change slightly to create a solution that will work for you long-term.
There’s a concept called “tensegrity” in architecture, or tensional integrity, that finds the perfect balance between being hard enough to withstand stress, but also flexible enough to bend as needed. I see this as how teams must partner on projects. Have a plan but be willing to adapt and set ego aside to keep the focus on delivering the greater good for the organization.
Keep your eye on KPIs, future-proofing the operations and fostering respect among IT and Business. Business may push back against change, pointing to the idiosyncratic requirements that cannot be varied, due to market and customer demands. IT may do the same, claiming fundamental technology or stability limitations, but in the end, spread the gospel that “we’re not spending a bunch of time and money to keep doing things the same way, but to do things better,” according to what better means (efficiency, cost, compliance).
Each individual on a project, as well as each team involved, sure, will have their own perspective on what’s priority on a project, but it’s important to communicate the value of that team mentality that puts everyone on the same page. Where silos exist, cohesion suffers. But when you break down unnecessary barriers, you have the ability to work faster and more adaptively to move the project forward. Understand that this is a necessary part of a business transformation, and if done well, it not only creates a better environment for you to succeed with your current project, but this approach will also set the stage for better cohesion and collaboration on future projects.
Share: