Most tech projects involve two parties – a client, and the technology or software development partner they choose to work with on the project. Such projects are often subject to gaps in communication and understanding between the client-side project manager and their development partner’s team. These gaps can cause friction, which can balloon into real issues and delays. Plug them at the beginning, to ensure that your tech development project goes smoothly.

Here are some of the common gaps in project management on a tech project, and how you can address them.

Project managers with limited tech knowledge

Client-side IT project managers aren’t always fully aware of what goes into building tech products. This is to be expected – they aren’t subject matter experts, nor do they work directly with the programming languages and platforms that their agency counterparts do. 

However, since the client’s project manager may not completely understand the details of the project, this can cause gaps between client and dev partner. The same points may need to be clarified multiple times. 

Managers may believe that they are more informed than they really are, as a result of which they refuse to be educated on the subject by their partner. Misunderstandings arising from this kind of mistaken belief can result in unrealistic client expectations, or over-commitment by the partner under pressure.

Failure to build strong project foundations

The initial data gathering, discovery, analysis phase is the most important, as that’s when the foundation of the project is created. If this takes inordinate time, the project can get stuck in a never-ending loop as the project manager keeps seeking inputs and approvals from all internal stakeholders! Worse, if it takes inordinate time, this can result in a rush during the actual development process. When goals are set incorrectly, on the other hand, it can cause cascading issues. 

Your development partner will ask you for goals, KPIs and KRAs, but you may not know the answer – and you may not know whom to ask! In such cases, project managers may take a long time to revert, which further slows the project in the early stage, resulting in rushed work towards the end of the development.

Naturally, a dev partner wants to support their client to complete the project successfully! They often try to paper over the cracks by proposing project targets from their own end. This can set the entire project on the wrong foot.

Another key area where building a strong project foundation is vital is in the case of app modernization projects for legacy applications. In such projects, an existing app is already delivering on specific business objectives, works with certain dependencies, and offers functionalities to address a specific set of requirements. If a project manager is not able to correctly and comprehensively communicate about the intricacies of the legacy system, this may in turn affect feature releases and key deliverables defined for the modernized application.

Building trust takes time

Client expectations of time and budget are often unrealistic. This could be because:

• They are afraid that if they show any relaxation, they could be unnecessarily billed  by the agency
• They have “heard” that it should be faster and/or cheaper
• They want to plan based on business goals, not based on development time needed

Your partner, in almost all cases, is looking at building a strong long-term relationship with you. They know the market reality and the actual costs that go into project development. 

At the same time, the risk due to change management is considerable. So, in some cases, larger software companies do pad their fees and timelines. It is possible that this may result in large, bloated contracts. However, smaller agencies are more focused on building and maintaining relationships in the long term, and cannot risk losing a contract due to bloated cost estimates. In either case, ask for transparency in quoting and work towards building the trust with the partner and your stakeholders.

All ‘changes’ are not made equal

As a client you may, for instance, value a change that you can see – a UI/UX change – more than a “minor” change on the database. However, database changes are complex and time consuming – much more so than frontend changes. If you are not aware of this fact, you may expect that the backend change should be completed much faster than the frontend change.

As another example, imagine that, once the timeline and budget are finalized to your satisfaction, the partner comes back to you with a query, needing additional input on the project. It may take some time for a new project manager to share this information. However, since the final delivery time is fixed by external factors, this eats into time available for final project completion.

As a result, your partner may not be able to meet the delivery date originally committed. This may cause a breakdown in trust, and a belief that the development is taking too long to complete, when in fact, there’s just a mismatch of ideas and understanding.

Though they are heavily dependent on their tech partners, clients naturally actively participate in, and even drive, timelines and costing. However, when this happens without an objective baseline for comparison, or without sufficient technical knowledge, it can cause avoidable friction. Over time, this can create mistrust, with the client feeling like they’re being billed without justification, which in turn makes the development partner feel that their integrity is under question. Before it reaches that situation, it’s important for both sides to take a step back at an early stage to smooth over and secure the relationship.

Plugging these gaps

When you’re not fully aware of the technical details that your partner is sharing with you, ask for more information. Similarly, ask for an explanation when you can’t understand why the estimated cost or time is higher than expected. 

Of course, this is a two-way street and the shortcoming can equally be at the tech partner’s end, by failing to communicate sufficiently or by incorrectly assuming that the client is aware of certain technical concepts. If your partner is not open to frank and clear discussion, that’s a cause for worry and a potential reason to look elsewhere.

If your business requirements demand faster delivery than your partner can commit, do sit down with them to discuss options. Your partner may be able to add extra resources for the urgent project. Alternatively, you could plan to create an MVP (minimum viable product) instead of a full app launch, or simply accept some technical debt which could be resolved later.

In our experience, an approach of open communication, transparency and trust from both sides can help resolve most project management challenges. At CloudNow, we believe that every client is a potential long-term partner, and we work to build lasting trust and relationships with each.