Communicating non-viability of project

Question

I'm a consultant usually brought in by companies doing project management on big projects, setting up operations etc. The last few years I have been dealing mainly with digital and creative agencies.

This sector historically has a low level of expertise within software development. The lifespan of agency projects, once released, are often measured in months rather than years, since most projects are in some way marketing related. As such they are not accustomed to the complexity or scope of "real" software development.

My problem is as follows: When presented with a new project, which I can rather quickly dismiss as unfeasible (we're talking extremely unrealistic projects), I have trouble communicating why it cannot be done. I argue the technical complexity and the requirements versus the time and price scope. I am however not able to make my points persuasive.

Essentially my recommendations get ignored, and the client looks around until they've found a vendor or individual who says "yes it can be done". Both times, the projects crashed and burned. Reason being they were so amazingly unrealistic, that even inexperienced technical project managers would dismiss them right away.

What kind of approach or what kind of arguments would you use when presented with something unrealistic, yet highly desired by major stakeholders? Maybe any literature to read on the subject?

Answer 1

I would suggest the following approach on how to communicate in this particular type of situation:

1) Be clear who you need to communicate to

This may sound obvious, but it's not always so. It's important to be clear about who is the decision-maker and needs to be informed of your assessment of the situation and your recommendation - in other words: who you need to sell it too. Usually it's the sponsor, but you may not have direct access to him/her (in which case you need to communicate first to the person(s) in between), or sometimes it is a whole group of people.

2) Work out what their interests are in the project

You need to gear the communication to what the decision-makers are interested about, what matters to them and will get them to really see the impact of continuing on the wrong path. You have to see it from their perspective. For example, if you're dealing with a Marketing executive, he probably won't care too much about the technical argument (or even understand it) but will be more likely to respond if you tell him that he will not get any returns on his next digital campaign or that his brand will be damaged. By doing this you are focusing on them (not on what you think).

3) Use your experience and lessons learnt as part of your argument

It sounds like you have some great experience to share in seeing this sort of situations happen. Use it: "Company X did a similar project, they spent $1M and had to postpone the brand launch by 6 months. It cost them $3M in lost revenue". This should pique someone's interest and I wouldn't call someone trying to stop a company losing money a "killjoy".

4) Focus on the impact and make your communications as clear and simple as possible

Present your information well, either as part of a formal presentation or in a document; keep it focused on the actual impact/consequences of following a certain path (what if we do it? what if we don't?). Don't drown people with details, especially technical stuff if you are speaking with non-technical people. Translate it for them into impact statements that they can relate to and it's also important to offer alternatives. Use simple language, avoid jargon and acronyms, keep it short and make use of good visuals to support your point of view.

Finally whilst as a consultant it may not be strictly your responsibility to make the decision (indeed you are here to advise, your client decides to take it or leave it), I think it's important that you take the opportunity to voice your concerns upfront. Then you have a choice yourself to get involved in the project or not.

Answer 2

I fear my answer will probably not be applicable to your problem because of the fleeting nature of the projects and the capabilities you report in your stakeholders and sponsors.

However- In the business I work in we always, without exception, do a Business Case first (and spend a little research money to investigate where key data are not known). The business case, essentially boils down to:

a. What are the tangible benefits (over a period of time, e.g. 3-5 years) of doing this thing (i.e how much money will we make, or how much loss will we prevent)

b. How much will it cost us over the same period

We usually look at a number of solutions in the business case that have a range of costs and potential benefits.

Then the whole shooting match is reviewed by the people holding the purse strings to see if, in a nutshell, the benefits to the business are worth the costs to the business.

Such an artefact would not immediately solve your present issue- it is easy to make a business case look good by notionally increasing the benefits and/or decreasing the costs on paper, but do it a series of times and the person responsible for writing the cheques begins to ask questions when they are continually asked to spend money without realising the promised benefits.

In an ideal world you would also have a robust review of the stated benefits, including benefits realisation measuring in place, and the stated costs as part of the review process- but that can vary from org to org...

Maybe in your case, do a "post mortem" or "lessons learned" review after each crash and burn, documenting the busienss case and following up with why the money spent was excessive or the stated benefits weren't realised, and make sure that Finance get those reports. You don't personally need to keep saying no, eventually the more finance-oriented people will begin asking questions of the more gung ho people and some degree of reality should start to creep in.

Or maybe they just all like being gung ho media types on the white hot bleeding edge of the digital age (as long as it is someone else's money they are spending!)

Good luck

Answer 3

You are a consultant, not an employee of the organizations which choose these risky projects, right? As a consultant, your only role is to advise a path to your customer, explaining its benefits as compared to its costs, penalties, and risks, in an unemotional, objective way. After that, it is their choice; your scope is finished.

Consulting is not about being "right" or winning an argument. It is about presenting several alternate paths, including the less than desirable one, each with its pros and cons, and making a recommendation. With trust, you'll become more persuasive, but it is not really about that.

I would advise a customer of several paths, make my recommendation, then, if they choose something different, help them with their risks and recovery plans if things do not turn out right. That's the job.

EDIT: I don't get it. You're doing all this but you're asking what? You are building a business case, you outline benefits, costs, and risks of alternate paths, you make your recommendation, but they choose a path you did not recommend but it is not about being right?

If you are doing all the right consulting things but are not being persuasive, is it about the quality of your work? Is your research not rigorous? Is your writing incoherent, irrelevant, or not compelling?

Here's the thing: it could be very well your customer, who prefers to wing it than make decisions based on evidence. That is NOT uncommon. Transplant yourself to a different customer and set of projects, and your work and recommendations could have dramatically different results.

What I tried to explain above is, your work product ends at the recommendation. If you are proud of your work, notwithstanding all of our work could be improved in some way, then you did your job and you should be claiming success...DESPITE their decision. If your work product could use some improvement, that's one thing; you can work on that because we all work on that all the time. But you cannot take ownership or impeach your ability to persuade based on their ultimate decision and crashing into the wall.

Answer 4

I'd say it's about managing expectations. The guy hiring you has probably been given a budget for some customised software and he imagines that customised means it can be whatever he wants. You have to explain that even though it's customised you can't start with a blank page, it's going to have to be built on an existing platform. And all the other disadvantages that I'm sure you're aware of, try to spell them out from the start.

For example, the more they want the system to do, the more complex it will be and so the more training, testing and maintenance will be required. So maybe try to sell them on simplicity. You have to make them want a system that will do a limited amount of stuff, but do it well, not some snake oil solution that will do everything and nothing.

So if you sell them on simplifying their processes and replacing, say, the spreadsheets they use for managing their projects, and make them aware of how 'feature creep' makes the project more complex, and that's a BAD thing, then they have some idea of what is achievable.

I don't know whether there is literature about managing expectations but you hear politicians do it all the time, usually when they're rowing back on the promises they made before getting elected. ;)

Answer 5

Penalty clause for non-performance or an outcomes based contract

Whether a project is feasible or not could be subjective. My suggestion is that you should try to come up with a few objective measures of success. Also, define how exactly that will be tested and what specific thresholds must be passed. And then lobby for a penalty clause to be built into the vendor contract for non-performance.

Or use an outcomes based contract such as this one, where you agree on 'statements of target outcomes'.