Although a lame story, Let's say you are responsible for initiating and managing a new software project in your company with complex bureaucracy and management. You have found that it is highly feasible to work with Agile methodology instead of Waterfall.
But Waterfall has been how the things had always been done, yet you know that the team is ready for Agile and project is an exact type of work that would benefit from some "lean" approaches. Worse still, management won't listen, also because "The Board" won't listen.
What you do is that you go to that well-known, highly-paid consultant, discuss the situation and he basically says, "OK, You are right. Also this and that."
Then in your presentation to the board while pitching Agile, you say, "Agile is the way to go. I asked Patrick Kalzumeus, and he said it was a good idea."
And that's it.
That "credibility" is one of many ways how a business consultant may "add value" to a highly organized company.
1. What's the proposed issue/improvement?
2. What are the recommended options?
3. How much time will it take to get done?
In other words, all you really need to communicate is why we're doing it, and when it will be done.
In my experience, they're not interested in challenges faced in implementation. Keep things simple, and deliver on time, and you'll be speaking the "language which management can understand". That's basically all there is to it.
Your line manager may be interested in a technical issue / improvement and understand its value without further explanation -- for instance, we're using a brute force algorithm that takes exponential time to foo the bar in the Baz module. It's got test coverage and the problem has a known logarithmic solution, so we could rewrite that in a week to be more efficient, and still be confident it's accurate.
Your department head may be willing to consider fixing a problem that affects efficiency or security or expected timelines -- we've identified the likely cause of at least one class of those outage events you've raised concerns about. If you want to fix it immediately, we would have to push back delivery of the Quux feature by a week while we rewrite a portion of the Baz application, but other risks are minimal.
The C-suite is mostly interested in problems/solutions framed as "how does this save us money" or "how does this make us money" -- we intend to invest a week in technical maintenance work that will allow us to save 25% of our monthly hosting costs by scaling back hardware requirements, and reduce the frequency of outage events that we have to pay out for on under our SLAs by 75%. That would cost $10,000 in developer time and delay our product schedule by a small though measurable amount, but I estimate it would save us an average of $48,000/year in costs.
The other piece I've seen is being able to handle "I want Foo by X". It's easy to take on the engineer mindset and say "Sorry, that's not possible. The whizbangs alone would take more than that time!", but what do you do when they simply repeat "I want Foo by X"?. Picture the various Star Trek series where the engineer would say it'd take 5 hours to fix something and the captain retorts "you have 2". It's real.
The skill which really makes me jealous are the folks who are able to read between the lines and get at why they want Foo and why they need it by X. Instead of saying "Sorry, no can do!" they're able to offer Bar instead, and because they understand the deeper motivations of why Foo is being requested they understand why the manager is likely to accept Bar instead of Baz.
This is pretty similar to your C-suite descriptions, now that I reread it. But it's a different spin on it.
One tactic I can suggest (if your manager isn't a totally unreasonable cartoon tyrant) is to simply be explicit about it and ask "can you explain more about why you need Foo?" and then "what's driving the deadline of X?" Understanding the business case is generally necessary - though not always sufficient - for coming up with an alternative solution.
I suspect that part of the gap between people who are and are not good at this is how well apprised they are of the general conditions, initiatives in other departments/teams, and short-term strategic goals of the company.
Some of that is on the person who may or may not put in the effort to remain informed; and some of that is on the company's management that may do a good or a poor job of communicating those things proactively between departments/teams and from senior management down to junior management and line workers.
Depends on the individual, not on the job title. In my experience, managers of any level value information as simply put as possible. If they ask questions, then you answer them, but otherwise just tell them what they need to know.
i.e., "the expensive consultant said it was okay, so don't fire anyone in management, or our technology team, if it goes sideways."
in other words, they're actually helping you do your job because they can compare your recommendation to other companies and teams in the industry and make sure everyone is doing things sanely. in your case, you were smart, and made the right recommendation, so they agreed with you. good job, you're competent, and aren't putting an established company into a risky situation like you would at a startup, which generally does not hire consultants, because they have nothing to lose and everything to gain.
you probably didn't see it that way, i'm guessing.
(More seriously, being unable to trust your employees to give useful feedback is a sign that your culture is a disaster)
I was hired to come in and assess the software that they were developing - they were working with some contractors, some vendors, and a smattering of other people, and wanted to know if their current method was working, how to address some concerns they had, and whether their current vendor was doing a good job.
I discussed it extensively with them, looked over the code and repositories, their current deployment, their backlog, looked at their priorities and basically told them "They seem like they are doing a good job, with the caveat that using contractors and vendors means you will never develop those skills in house, so I would hire at least one competent programmer internally to work with the vendors/contractors you hire, in order to develop that expertise, if you intend to use custom software as a core part of your business on a continuing basis".
This was conveyed via a written report with citations and via a meeting with the C-level executives of the company.
For this review and strategic suggestions they paid me about $1200 for an afternoon's work. That doesn't count time that went into acquiring the gig, scheduling, following up, or billing, just billable hours.