The gap between business and IT has never been wider and some things that can be done about it
By: Rojina Sar Salari
Tags: Technology, Videogames, Project Management, Business, It

Why can’t we be friends? Why can’t we be friends? Why can’t we be friends?

As the title suggests, and case studies point to, business and IT have not been functioning well together in many organizations. Tech projects tend to be over budget, overdue, and completely missing the necessary scope. Why is this the case? Well, there is a real gap between the two, no matter what industry, including tech itself. It’s a pretty crazy phenomena. I should know, I work in IT at almost Big Tech.

Exhibit A: Cyberpunk 2077. The New York Times, laid out this tragedy of a case study perfectly. As summarized:

Inside CD Projekt Red, it was a very different story. Developers were increasingly concerned with some of the grand promises being made by management on the promotional marketing tour. Far into the game’s development, former employees said, the hyper-customizable and endlessly explorable world being sold to players was nowhere close to manifesting.

This is a prime example of how this unnecessarily wide gap bleeds into other functions of the business such as marketing. The part of the company that convinces the customer base to put their well-earned funds towards their products. Now the studio could be facing a potential lawsuit, from angry investors that bet wrong, which could potentially turn it off, place it in a box, and let it collect dust.

Below is a series of suggestions for each party that is involved in such projects. I thought to share some learnings from business school and work.

Business for Dummies

Get domain experts to comment on your plans. You probably got into that position because of your resourcefulness, so flex those skills. DO NOT PROMISE ANYTHING AT THIS STAGE. This will save you and everyone you put on the front line to deliver your idea. Make sure to consult multiple, different independent individuals, if you can. I know some organizations are small, but this should be all part of the research process. Unless you’ve had the domain experts, give you a sign-off that your plan is feasible economically, technically, and organizationally, you are not in any position to promise anything. Confirmation from domain experts acts as a control to make business plans realistic and achievable. This way, you succeed in delivering a well thought out idea, that can benefit rather than cost the company.

IT Project Management for Dummies

Prior to setting a go-live date, the absolute hardest deadline there is for software development, see if the timeline is realistic. Make sure all the work has already been estimated. DO NOT PROMISE ANYTHING AT THIS STAGE. Get those requirements from business and see what prerequisites, skill-sets, and resources are required. There will be multiple consulting sessions with business, as business needs need to be translated to functionalities that can be delivered by IT. Once the total work is broken down, you need to consider and capture risks of the project. Consult and jot down potential risks that the development team, product owners, project managers, and other stakeholders anticipate in terms of probability and impact. Outline a plan for mitigating or managing each risk. You can also use this document to manage key stakeholder expectations by being open and honest right off the bat. The document also enforces project delivery accountability as the risk register needs to be updated frequently. Once this has been done, only then can the timeline can be estimated. And try to be conservative, not just for the sake of the delivery team, but as we’ve learned this year anything can happen. So cushion that delivery date.

IT for Dummies

IT needs to be an efficient and effective power house in any organization. Make sure your delivery teams are in shape (high-performing) and have the necessary support (budget, $, funds). Management and team leads do need to step in to advocate for their delivery teams. Project work needs to something that can actually be accomplished to not only keep and attract good talent, but also to be able to sell something to the end-user. Once the balance between available work and human resources is disturbed, you’ll be playing catch-up on project work while attempting to reinstate harmony within the department. If there is too much work, you’ll always be behind with all hands on deck, with no time to breathe, jumping project to project, lifeline to lifeline. If there is too little work, you’ll underestimate the true capacity of delivery team, and teams will be working inefficiently. Aim for the happy medium as you build your delivery portfolio.

The NYT also outlined another recurring issue in IT based on that game of the year:

Employees said that during game development, there was a general attitude of building more things themselves rather than sometimes licensing other so-called “middleware” — or supporting software — from other companies with greater expertise. As a result, the developers created worse versions of features that had been perfected by other companies.

To build or not to build. IT is the question. Why reinvent the wheel?

Consider incorporating other technologies, frameworks, and best practices rather than creating your own. This way, you can focus on what really matters, delivering value to your stakeholders. If you do decide to build in-house, or with any major decision, make sure timelines and scope are adjusted accordingly.

Understanding the issues is one thing, but taking action is another. You too can contribute to successful IT projects with better planning, analysis, design, implementation, testing, deployment, and maintenance. ;-)

Recommended Watching: The IT Crowd

Thanks for reading. Connect with me.