Have you ever heard the term "IT and the Business?" Have you ever said "IT and the Business?" Did you know every time you say "IT and the Business" a baby kitten dies?
OK, that last part isn't true and probably a little harsh, but that's the way I feel when I hear it. This phrase insinuates separation and difference. Us and them. Think Sharks and Jets, but without all the singing and dancing (West Side Story for those of you who don't get the reference). Opposing groups who may be forced to get along, but don't like it.
We don't say "Sales/Marketing/HR/Finance/Accounting and the Business." Doesn't sound right. Clearly IT has a stigma. Technology and those professionals that manage it are involved with almost every aspect of business operations. However, they're often considered outsiders. CIO's and their teams, though having made progress, have a long road ahead of them to remove this paradox.
Even though the IT Department has a continual uphill battle with "IT and the Business", project management is perfectly positioned to help wage the war against this mindset. Whether you're in an IT PMO, EPMO, or just a project leader sitting in a functional area tasked with leading a more technologically focused project, you can help!
But, you may say, how can I help change this mindset? Here are some tips to lessen the "IT and the Business" impact:
There are no "IT" specific projects, only enterprise impacting initiatives. First, when someone says "That's an IT project!", remind them even though there is a heavy technology focus, it will impact more than just the IT department (often it's multiple areas of the organization).
Let me give you an example. I worked for a SaaS provider that helps companies move from on-premise to cloud based solutions. One of the bigger, and tougher, functions of these moves is data migration. The operational owner of the project told me "Data migration is an IT function." As I explained, the IT function is pretty straight forward. The defining and cleaning up of data is a whole lot harder.
Fast forward about a month after that meeting. The operations and IT staff were working hand-in-hand defining what Alt Address Field 3 meant and cleaning up 15,000 duplicate records. The operations owner and team admitted later that yes, it was a lot more work than they ever imagined.
Governance; the 4-Letter 10-Letter Word. What do I mean by that? When someone requests an IT project and you say "Great idea! Let me run it past governance to see if they approve and get it prioritized", you'll probably get a 4-letter colorful metaphor in response.
Governance can get some bad press! But in reality, it's a repeatable decision-making framework designed to govern a company's capital investments, which IT is usually a pretty big portion of. It ensures the right projects are being done at the right time, and the right people are available to do them.
I've seen governance used as a bureaucratic hammer to demolish project requests. Not good. Instead, if someone goes out of their way to make an IT suggestion, THANK THEM! A simple "Thank you" goes a long way. Let them know their request will need to go through governance, but it's there to ensure people and resources are working on the highest organizational priorities, those that align with strategic goals. Post-governance, follow-up with the person on the decision. If the request doesn't move forward, let them know. Also, assure them it's been noted and if a future project comes up similar to their request, you'll be reaching out.
Watch Your Language!! I don't know how many times I've seen technology leaders say they'll embed IT staff with operational groups. That way, they can learn operational language and processes. Even if technology staff do get imbedded, there are some IT folks that dream in 1's and 0's. Understanding operational language doesn't compute with them. We don't ask operational users to understand tech speak. This is not always the best idea and can be a waste of people's time.
If your project management team/group can swing it, hire a solid Business Analyst. A BA is a PM's BFF on IT projects. My preference is to have BA's specialize in just 2-3 operational areas of the company. For example, one BA in a PMO I managed was embedded with HR and Accounting. She understood their language, processes, and pain points. She gathered technology requirements and helped answer questions from both the operational side and technical side throughout the project. She also got insight into what they were planning in the future.
Can't get a BA? There may be someone within technology that can grasp operational language. Consider giving them a technology liaison role for this specific project. Yeah, it's kind of an unofficial role in companies I've worked with, but one that adds a lot of project value. In this partnership, the PM gathers the requirements with the technical liaison asking clarifying questions to ensure they're thorough and accurate. They do tech work 50% of the time, answering questions of the tech team the other 50%. If a technical issue comes up, they can ask the operational users the right questions to resolve quickly.
Bring Your Team Out From Behind the Curtain! Remember in the Wizard of Oz, when everyone was in front of the wizard and Toto pulls back the curtain? The wizard yells "Pay no attention to the man behind the curtain!" I started consulting at a company where in a kick-off meeting, the sponsor, who was from Document Management, shook hands with the lead application developer. They'd worked at this company for 5 years, sat on the same floor, been on a couple different projects where they traded emails, but had never met face to face. I spent extra time on intros that day!
Projects bring people together from a variety of functional areas. Project managers can help tear down silos by bringing people together for different project meetings, and allowing for informal discussions to take place. Relationships can be built and greater trust between groups established.
Now, I've had an app dev manager tell me to never, Ever, EVER have his staff in the same room as "the business people." His reason was those business people will ask them to do stuff. So instead, when someone had a question, I'd march them over to someone else's desk. There'd be a quick introduction, then Q&A. It didn't matter if it was the tech or operational person, a walk was in order. You could do this with video calls, also.
Dumb-Down Your Reports. I've seen status report decks as long as 22 pages and riddled with industry-specific jargon and internal acronyms not all people and departments understood. They were also "Watermelon Status Reports", where on the outside it was reported as green, but once you looked on the inside, it was red.
Whether you're a decision maker on what reports are provided or not, if status goes to someone in management, dummy it down! What KPI's do they care about? Report those in a single page dashboard vs. a small novel. Keep the language simple and concise. Avoid jargon and IT-specific speak. If there are questions or feedback, take those into consideration and adjust if necessary.
Consider These Partnerships. I've been asked, "If I can't call them the business, what should I call them?" I prefer to call them "Partnerships." Operational Partners. Technology Partners.
So what does one little word do? A partnership is an alliance. It says we're cooperating for the common good of the company. We're in this together. We want what's best and to be successful. It's a powerful word and in removing the "IT and the Business" paradox, partnerships go a long way to forming unity.
"IT and the Business." Will this paradoxical term ever go away? Probably not. Company leadership, especially those in technology, have a long hill to climb. But, project management is poised to help reduce its use. For the betterment of the company, I hope they do!!
