How can I better communicate possible pitfalls?

Question

In about a decade of working as a full-stack software developer, I've found that through experience I'm easily able to predict well ahead how things could possibly "go wrong". Most of the time I can solve this myself, I am lacking some information which is then given, or even people think it is a great remark and are thankful I thought about it. Other times however I need someone on a level above me to take action to address this, or I am not being heard and dismissed.

An example would be that mid-project, a change of technology is suggested, which is considered to take only a little time as most things should be able to be re-used, but I know from experience that this will take longer. So I express this as a concern to the team and to the manager, sometimes even quoting I've been through this before at another project, but it gets waved away. Eventually, it happens that it takes about as long and it is pretty frustrating because not only do I have to watch it going as I said it would, I also somehow end up getting told I'm at fault because I didn't believe in the changes or I couldn't have predicted all of this.

Now since I work as a consultant, I've learned to give advice once and then drop it if it isn't being heard and try to do what I can to help things along, and maybe cover myself by having things in writing. If the client wants to ignore my advice, and I have documented that the advice had been given, and they gave me on paper that they want it the way they ask, then that's basically a costly mistake on their part.

People, however, get upset when they notice they have made expensive mistakes and generally don't take the higher road of admitting fault. Maybe that is just something I'll need to learn to live with, consultants are an easy scapegoat, you just claim they did a poor job and replace them. So document and don't take it personally.

However, I am wondering if there are ways or techniques in which one could express themselves, when very sure of a case, to make it so that you are taken seriously. I don't want to resort to anything underhanded, so no psychology tricks. What I've tried is telling the story of a previous case, finding and listing a few challenges which will need answers to try and clarify not all angles are covered, sharing documentation on best practices and why they are that, or at worst I've had to remind that I actually have worked with something for X years because sometimes people seem to forget your qualifications. I feel though after doing this repeatedly, you generally become that whiner and it is even worse to get anything through.

So in short, how can I be taken more seriously in my advice so that bad things don't have to happen and I don't become wildly unpopular?

Answer 1

There are several bias that work against your warnings being heard. First, people are often overly optimistic about their ability to carry change, and put on their blinders when it comes to potential obstacles. Second, depending to the way you communicate, if you often warn people about bad stuff, it's also possible they believe you are being overly cautious. There are also reasons that could lead to lower the perceived value of your insight : being from another company, being low hierarchical status...

An example would be that mid-project, a change of technology is suggested, which is considered to take only a little time as most things should be able to be re-used

In this scenario, I would first question what are the requirements for changing technology, and try to weight my estimation of costs versus the estimated gain from changing. It's possible your warning is unheard because the perceived benefits outweighs costs anyway. So if you anticipate that is the case, you could save yourself credit for raising a point uselessly.

I also somehow end up getting told I'm at fault because I didn't believe in the changes or I couldn't have predicted all of this.

Well, this is dysfunctional and not how things should happen, but people are always eager to search external causes when things don't go well, and you happen to be one, which is also why you shouldn't expect people to acknowledge for their mistakes.

In addition to your suggestion to argument as precisely as possible, another technique to be heard without being a whiner is that, whenever possible, you communicate positively instead, and present lesser cost alternatives to achieve the same goal. Presenting potential risks on solution A, but coming with a solution B that doesn't present this risk, is a rather positive way of avoiding the pitfall.

Answer 2

For situations where you have some control over the culture of software development - for example, when you're a team lead, or you're a consultant involved in the planning phases of a project, etc., I think it is quite reasonable for you to impose some formality with regards to the analysis and consideration of "risk".

For example, I've always liked doing something similar to the following: for any project estimated to take 10 developer days or more, require that a project description gets written before any development starts. The length/complexity of this document should reflect the complexity of the project (so for a 10 day project a few paragraphs would suffice). In addition to the what, why, and how of the project, there should be a section on risks, and the efforts taken to mitigate those. Finally, require that a project/design review meeting is held (again, the length of the meeting should be proportional to the complexity of the project; a 10 day project probably only requires 30 minutes) - where the developers assigned to the project present the items in the document to reviewers, and together everyone works together to make sure nothing important was overlooked.

By creating a culture where risks (etc.) need to be thought about, and presented up front, people get used to considering pitfalls, evaluating how costly they might be, and designing projects plans which try to mitigate some of them.

Answer 3

Fact is that as a contractor or consultant you are the perfect scapegoat. Just don't worry about it. You give your best advice. If it is ignored, then you do what you can, take the money (which should be generous) and the blame, and run. Everyone at the company is happy because they were not blamed, and you should be happy about the payment. That's life.

Answer 4

Seems like you already tried most of the common advices, and you are even aware of CYA and that you shouldn't just say bad things about everything all the time. At this point, I'm not sure if there is much more you can do, except realize that humans are not perfect and some will take irrational choices and make mistakes again and again.

If you are at the point that you can't do anything anymore to help them, try to either not care (I know, that's harder than it sounds), or walk away and look for a job where you and your opinion as a consultant is more valued.

PS: Even I with my less than one year experience in software development know that change of technology mid project will take longer than expected, and for this, neither the technologies in question nor the first time estimate matter.

Answer 5

In my experience, this problem can occur for software projects especially those delivered using Agile or Scrum that don't pay sufficient attention to the Design and Architecture aspect.

Here are a few recommendations:

• Ensure customers understand the importance of laying solid foundations. The analogy I use with people is that "we're just about to start pouring concrete so it's important that we get foundational decisions about system architecture (especially wrt Infrastructure and Data) right from the outset. Not perfect but as good as possible. Because if we need to make major changes, it won't be trivial."
• Decouple the front and backend. I've seen many software development projects where the front-end is tightly bound to the database (with SQL queries) and/or legacy backend systems and then they wonder why they can't reuse any of their code if/when they move from web to mobile app or whatever. Building abstraction between the front and back end via the use of APIs enables a lot more flexibility and reusability further down the line.
• If there are important decisions to be made then ensure that they're logged in a decision register. i.e. Recommendation, decision, who, when, why etc. At least that way there's a clear audit trail and perhaps some learnings can be gleaned over time.
• If there's a major unknown then get it logged as a risk, along with a suggested treatment to help avoid/reduce/mitigate the risk. Ensure it's in an "IF trigger THEN impact" format.

Unfortunately that's a part of IT, you can make recommendations and from time to time the customer might ignore it, take other advice or move in another direction. I wouldn't get frustrated by it. Just try to keep the tone of any conversations constructive (i.e. Not "I told you so" of course!). The earlier you can make recommendations, potentially the more likely they might get accepted. Just try to understand if there are any "hot buttons" or "sacred cows" beforehand, i.e. firm decisions which are unlikely to be overridden quickly or easily.