In the best of all worlds there would be no unspoken issues. Whether it’s life in general, or IT projects (that’s the topic here !). No unspoken issues is an ideal, but it never happens (like all ideals). There’s always something that we knowingly avoid telling our client, partner, service provider, etc. Generally we hide an inability, ignorance, simple uncertainty, etc. I try, and I think it’s fruitful, to avoid unspoken issues as much as possible. It’s always, always, always, a risk that you’re creating unnecessarily for your project. It only complicates the execution of the project. It introduces ambiguity in the expression or resolution of needs. It prevents proper project organization, etc. From the moment you cast a shadow over the project, don’t be surprised to suffer the consequences.

Knowing that in the end often no one is fooled and that the unspoken issue has a price: Amplification of stress? On a part that you don’t really master but on which you’ve sold yourself? Amplification of damage, if you let a technical or functional aspect drag on that you know perfectly well is failing? Amplification of workload? One of the team members isn’t up to the task? You have to tell them. They will have to make the effort to get up to speed or will have to leave the project, but in this second case, they will have been informed, and the wound will be less severe and more understandable, etc, etc.

Isn’t it obvious that an inexperienced young person says yes to everything (oh those CVs I see! Gentlemen professors of technical institutes, of computer schools, have the decency to explain to your students not to put the glossary of technipedia in their CV, nor -by the way- to offer themselves as Project Manager from their first professional year), whereas an old experienced hand will rather say no, a sign of trust… (find me a Samurai maxim that expresses that in 4 words).

Don’t let anomalies drag on, don’t let dirty code drag on, don’t let misunderstandings, mix-ups drag on, they will come back to hit you in the face. I know it’s not simple, I’m the first to shirk the task sometimes, but you’ll be surprised to see the relationship you maintain with your counterpart strengthen, to see project management become clearer, to make things more SIMPLE.

This can be related to the courage of agile methods. Remember that Lean asks you not to let an anomaly drag on. etc.

The unspoken issue is not necessarily your doing. Try to persuade your clients not to abuse it, to understand where they hide. Guess the real stakes hiding behind certain requests, behind certain blockages, etc.

Joker for pre-sales commercial aspects: for me personally these things are much simpler since I’ve been a consultant (with my 2 partners at SmartView), we do consulting: truth, frankness are therefore essential and natural, and above all I commit in my name, on my work. I don’t commit on a hypothetical team that will execute the project. But I can’t throw stones at the salespeople of companies like IT service companies. If the contractual part isn’t always fair, nor fair-play: we’re going to choose the cheapest without taking quality into account, it can be understandable that the answer isn’t always true. We understand well that too many projects are flawed from the sales phase. Hence in my opinion the success of agile methods today.

I’m also not asking you to proclaim everywhere and loudly everything that’s happening on the project. I’m calling on your intelligence to understand clearly where the boundary lies.

Unspoken issues in IT projects are like family secrets, in the end they break people, dynamics, teams, projects.