Updated: Mar 14
Lack of healthy communication is still an obstacle to software development and innovation. Recently, Deloitte even suggested companies use a common language for digital transformation. Businesses and engineers are like dreamers and realists. They will never completely understand each other. That's why projects turn to the towers of Babel.
Recently, I found a great book, "Negotiations with Delphines" by Max Romenskiy, where the entire communication between techies and non-techies was described in detail. The two teams are so different that people have to write manuals on how they get along with each other. There would be no big deal in these disagreements if they were not about:
a vast number of project failures
investments into development without a particular business goal
eternal disputes about budget functionality and other stuff, which ultimately leads to a time-consuming development process and often - to the building of invalid solutions
Since the consequences are not funny, enterprises are working on the communication issue. They build "bridges" between business and tech to gather all the ideas under one roof and consider them from different points of view. Outsourcing, intelligent IT governance, even in-house technology committee - all methods are applicable.
We're here to explore how they will work in practice and what simple rules can help you achieve smooth communication between all stakeholders during software development.
You may also like: Who Runs The Funding Innovation Process?
How Business Can Cooperate With the Developers: 4 Common Models
In-house software development
Regardless of the frequency, scale, and variety of software development projects, each enterprise has its own in-house IT department. It takes care of daily routine and makes tech decisions about any initiative (no matter who will turn ideas into reality).
Therefore, the first obstacle for business leaders is to find a common language with their talents. Fortunately, companies follow IT governance principles and do it in various ways. IT governance is about the intelligent management of software development inside enterprises which helps marry business requirements and tech ideas.
McKinsey reports that the technology committee creation is the most common engagement model of IT governance here. A technology committee is a sort of department or board that manages tech processes by considering business aspects. It's a middle link between business leaders and developers.
About 12% of the Global Fortune 500 have board tech committees. This approach is popular among telecom, healthcare, finance, utilities, and IT enterprises. The practice is gaining momentum. But since businesses face many more obstacles to digital transformation because of the pandemic and geopolitical changes, tech committees will be mainstream soon.
Consequently, companies can opt for one of the below tech committee models:
Regular engagement. It requires the involvement of all stakeholders having a solid tech background. This option applies to telecom and IT companies.
Standing technology committees with a medium level of tech expertise support retail, finance, and healthcare enterprises.
Advisory tech committees. They are temporary and needed for global project management, such as migration to a new stack or cloud.
An informal update is a general approach for companies that have difficulties cdiscussing tech agendas.
You may also like: All You Should Know About IT Governance in Telecom
Third-party Involvement Models
A company conducts a tender to choose a relevant contractor (vendor) that will run software development by itself. The enterprise controls product creation indirectly by communicating with the contractor's management. The main communication link between the developers and a client is a Project Manager - a team member who handles the project's organization, planning, and management.
Imagine that outsourcing and outstaffing had a baby. It would be a dedicated team. Here, a vendor provides a client with a team of its employees, selected following requirements. The vendor takes an administrative burden when the client can cooperate with the team directly. Usually, clients involve in-house talents to be a management and communication link between business leaders and the dedicated team.
It's a cooperation model when a company (client) involves third-party developers recruited by a contractor (outstaffing company). The outstaffing company hires tech specialists following the client's requirements. It provides them with a convenient environment & work conditions. The client communicates directly with the engaged developers, including them in in-house teams. Consequently, internal IT governance rules apply to involved specialists as well.
You may also like: How to Choose a Software Development Company
Top 5 Tips Allowing Business Leaders and Developers to Be On The Same Page
Don't wait for 100% accurate and steady requirements
The business environment is not predictable. Even considering all conditions and forecasts is not a panacea for unexpected changes. Managers know it. So making updates in tech requirements is a usual thing for them. Meanwhile, they might become a confusing challenge for developers. Both parties should accept it to avoid difficulties.
Create a business case
Project Managers have a magnificent practice: they hop on a call with clients to create a business case. It's a document where the purpose and capabilities of each product feature are explained from the business perspective. This approach helps business and tech sides remain on the same page and understand the role of system components considering their functionality and expected business results they should provide. It eliminates misunderstandings since all involved stakeholders know why software has certain features, how they will support business development and what technical benefits they can bring. Unfortunately, most companies ignore business case creation forgetting that this tool is another proven communication link between developers and business leaders.
Invest in clear and detailed project documentation
Managers have to remember that project documentation is a core guideline for engineers. No matter who begins the project, continues it or maintains the designed product. It's arduous to update a product without clearly understanding how it was designed. Businesses set tasks, but engineers can't perform them because of the data absence. So, managers should ensure documentation creation before its lack becomes an issue.
Don't expect perfect testing of all scenarios
The testing stage helps a team discover weaknesses of just created software and eliminate them before they cause damage to a client. But it's impossible to try a product in all situations. A "black swan" event might arise and make a company initiate updates. It means a business side shouldn't demand from QA/AQA Engineers and the rest of the team to move mountains.
Write meeting memos
The best way to stay on the same page is to write detailed meeting memos. It will allow businesses and developers to track their ideas & agreements and follow them in a high workload.
Proper communication with people is still an eternal topic for discussion. We can deal with this issue at the domestic level. But frequently, it doesn't help us find the right words for those who design innovative software products for us.
A manager and an engineer will always have different experiences, knowledge, and focus of perception. The first one is a business person. The other one is a creator. They will not understand each other, and there is no versatile way to ensure seamless communication between them.
Anyway, joint efforts can work wonders. All brilliant - easy: not to demand impossible things, consider differences, and capture actions.
Are you looking for reliable allies who understand your business needs? Drop us a line to use JEVERA's management and tech expertise.