Project Red Flags: Client Quotes That Lead to Trouble (and What to Do About Them).
If you’re pitching for work, not getting the project can suck. Even the most successful teams will see plenty of unsuccessful pitches and proposals – that’s part of the business. You win some and you lose some.
There are times however you start to see patterns in the feedback you get when you’re unsuccessful. I’ve noticed them. What’s interesting is that quite often the responses you get even before a project is underway have plenty of red flags to indicate there’s trouble on the horizon. And by trouble, I mean anything from mismatched expectations to unexpressed internal politics to the need to simply hire a scapegoat. All are salvageable if you are successful, but knowing some of these red flags will help you avoid pain later and possibly help you ask the right questions to begin with – or flat out decline the work because life it too short.
Don’t be too concerned when you hear these lines and you didn’t get the project… you’re more likely to hear there’s trouble brewin’ ahead. One or two might not derail a project, but the more of these you hear, the more concerned (if you won the work) or relieved (if you didn’t) you should feel…
“The most important thing to us is cost.”
The Client should actually be saying: “The most important thing to us is solving the right problem, but we have budget constraints. Let me share a ballpark of what they are so our expectations can line up.”
Cost is important, but that sort of constraint should be clear from the first conversation, not after providing a quote and all parties being shocked at the disconnect. Important details like the size of the budget shouldn’t be hidden like it’s some sort of magical telepathic differentiator for the winning bidder.
If you’re pitching for the work: Ask if the budget is fixed or if they have financial constraints and what they are. If the client can’t tell you or doesn’t want to, even as a ball park, that’s a red flag. In many cases, if they can’t tell you, it’s because they don’t have any budget. Or at least don’t have the approval to spend it.
If you’re the Client: Don’t waste everyone’s time. If you have budget constraints – and we all do – just say so. That’s preferable to learning later that you only have five dollars but still need to implement supply chain traceability across five continents. That’s a pretty big problem, but that’s yours to solve.
“We’re looking for a big team.”
The Client should actually be saying: “We’re looking for the right skills to solve the problems we have. If you can do that with a small group of experts rather than an army – great!”
I’ve worked with teams with six people that have run rings around multiple squads of developers with delivery managers et al, getting products to market. Small teams change the world. That’s totally a thing. Look it up.
If you’re pitching for the work: Challenge the idea of a team with scale being more effective than a small, highly skilled team. Unless the outcome you’re trying to achieve is to occupy a small country (and even then success might be a stretch), it’s unclear why explicitly wanting a big team over getting the right outcome is even a useful consideration. Big teams add complexity that becomes a barrier to achieving your client’s goals, even if they can’t see that. Deeply consider this trade-off, no matter how lucrative the work might be.
If you’re the Client: Scale only matters if you’re clear on what the problem is and if you’ve defined the solution clearly enough to indicate that scale is a central method to deliver it (and even then it may only be an assumption). Besides that, it’s meaningless grandstanding: is it important someone just wants to look like they have a huge headcount. Compensating for something?
“Your method doesn’t give us certainty around what you’ll deliver.”
The Client should actually be saying: “Full transparency: we don’t quite know what the extent of the problem. We feel we have some grasp of it but need more clarity and definition in order to know what to deliver. We’d love you to help us define that so we can understand what your deliverables will need to look like.”
If a client doesn’t know what the problem is, then how can a partner know anything about what a possible solution should look, feel or sound like?
The only deliverables that matter in building digital products are the ones that directly support building ‘the thing’. If you decide beforehand what the deliverables are going to be, as a client you’ve already constrained your stakeholders to expect a thing that only looks like the thing you’ve asked for sample deliverables for. Pretty circular, right?
These details matter. And bad results can be avoided if the certainty you’re looking for is concentrated on finding value (or solving the problem), rather than defining the deliverables that only constrain the potential paths to value.
If you haven’t nailed the problem and are expecting certainty around the solution, you’re flushing part or all of your delivery budget down the toilet.
Oh, and one more point on the problem: if you know there’s a problem and you don’t know how to solve it, that should be part of the engagement, not some element that goes unaddressed because you’ve made the assumption that ‘everyone already knows what the problem is’.
Understanding the problem to begin with is a regularly overlooked and critical failure point. The cheaper the team you engage, the less they will take the time to assess the problem for a number of reasons. The cheapest teams are for mediocre execution, not world-class problem solving.
If you’re pitching for the work: If the client really wants pretty things to hang on the wall, help them understand this is only a secondary use for them. If they’re entirely transfixed on the necessity of seeing detailed artefacts before you’re even engaged, have some anonymised ones ready to go, with a strong caveat that their deliverables may look and sound quite different. If they want to know exactly what the outputs will be but they don’t know what the problem is, pay attention to your spidey-sense. They have no interest in solving the problem and are motivated by other factors. I’ll leave that to you to figure out what they might be.
If you’re the Client: Spend more time on the problem and engage your partners to help define it – and be honest that you’re looking for that problem definition rather than trying to hide that. Then, and only then, should you start talking about what the deliverables are. Defining needn’t take a long time, but it’s the most valuable thing you will do. If your procurement process doesn’t work to support this approach, you might need to consider how to adjust it to better get results that will really move the needle: if procurement people like anything more than the power they wield over vendors as they rub their hands together and laugh in their subterranean lairs, it’s saving their company money.
And if you’re being motivated to run a project for outcomes other than getting the best result, consider finding another company.
Addendum to the above for Clients: “Other proposals included detailed screenshots, user journeys and wireframes”
Don’t get it twisted: if you want to deliver real and tangible value through a digital product these are important. But if you’re expecting that these artefacts are ends in themselves – or you’re expecting them before an engagement even begins – you’ve missed the point and likely won’t realise the value you expect. Worse, this approach implies they have become criteria for selecting a partner. You’ve never Googled “UI interface examples” or had a look around Dribbble? None of these outputs at this stage of the process solves your problem or is a serious attempt at knowing how to translate your brief into the results you want. Read that last sentence again.
Good designers follow a strong method, which will include artefacts and documents that support developing your solution. They can provide similar examples but the best designers will make artefacts that are relevant only for you. And only after you’ve engaged them with a signed contract. You should not expect work in advance for nothing.
And last point: you want to see proprietary content from another clients? No. A good partner wouldn’t do it with your work, why should you expect that?
“We want certainty around timelines.”
The Client should actually be saying: “We have a budget and an expected timeframe to get this done. Given our constraints, what can we do to meet our expected timelines? Is there any way to get to the value we expect as quickly as possible?”
Certainty is something every client wants, and should expect to a degree. As the old software adage goes: good, cheap, fast; pick two. It also applies to developing and delivering digital products.
You won’t get quality if you need to be cheap and fast
You won’t be economical if you want to be good and fast
You won’t deliver quickly if you want to be good and cheap
Unfortunately too many people expect all three. This adage is old, but it’s rarely wrong.
If you’re pitching for the work: no amount of certainty will overcome being too expensive if that is an absolute constraint, even if the client understands the additional value you bring. If you’re ok with mediocre work so you can be cheap and quick, then go for it.
If you’re the Client: Same point: if you’re ok with mediocre work so you can be cheap and quick, then go for it. Many clients think that fully realised specification document will optimise delivery and reliance on a partner (and therefore cost). These spec documents (regardless of the format or the content) don’t address defining and framing the problem, nor do they translate needs in a way that realises the best solution in the real world.
From my experience, if you want to lead an unsuccessful digital product, the first thing to do is write a specification document with a tight deadline.
“You’re obviously very intelligent”
There’s nothing along this line that is worth actually saying out loud. What this really means: It’s the first consolation prize in missing out on the work, as well as a backhanded compliment that…
“while you’re obviously very intelligent, so are we – in fact, we’re so intelligent we don’t need to understand the problem we’re trying to solve; we have a mandate to create a solution, dear fellow! And it’s problematic for us to uncover what we don’t know and be exposed for being inadequate – we just want a partner who will do what we tell them, wholly rely on our flawed perspective and then take the blame when we finally realise it was the wrong thing to do, all along.”
If you’re pitching for the work: Partnering with clients who are threatened by intelligence is the clearest red flag you can get. If they’re not partnering to get the best ideas, the best approaches and the best ultimate solution, then what are they looking for?
If you’re the Client: If you ever hear this coming out of your mouth, or you catch it forming in your brain, consider what you really mean by this. You might not need the best result in executing and delivering some level of value, but even then, you’ve immediately shown that the best outcome isn’t your main driver. Only so many people will want to partner with a client like that. And that group will only get smaller with every project.
“Although you weren’t successful this time, we have plenty of work coming up we’d love to consider you for”
What this really means: It’s the concluding consolation prize that’s meant to take the sting out of missing on the work. How you should take this entirely depends on how many of the above quotes you’ve heard along the way. The more you’ve heard, the more relieved you should be. And the faster you should decline said work in the future.
If you’re pitching for the work: and you’ve heard most of the above, and they still give you this line – run for the hills; you want no part in any of the underpaid, over-governed, under-defined mess that will follow.
If you’re the Client: and you’re tired of projects that go nowhere, seeking to solve problems that haven’t actually been defined, while trying to deliver solutions that don’t meet anyone’s needs, maybe it’s time to rethink your method.
Maybe it’s time to discover what you’ve been missing.
