IT development is a complex process where knowledge means power. In an agency-client relationship, the client often draws the shorter straw. Why? Simply because he is not an expert in the IT game, the agency is. Therefore the client is heavily dependent on the agency's advice and solution. Dev houses with insufficient moral credit can easily exploit such an imbalance. Here is what to do about it.
Let's start with a short story. I recently saw a LinkedIn post from a copywriter saying that her clients asked for help with a new horrible website, without any SEO setup, bad UX, and visible bugs. The website was built by a well-known agency for quite a lot of money. The agency didn't care; otherwise, they wouldn't deliver it in such a bad shape.
Clients were desperate. They paid a hefty sum for a website that was miles away from their expectations. Brands help us orient in fields we don't know, so when they chose a well-established supplier, they expected a smooth ride and results. Unfortunately, they didn't get either, and what's worse – this isn't a rare case. Right in comments, people told similar stories. None of them sounded new to me.
I, my partners, and other colleagues have a similar (repeating) experience in our careers – but on a larger scale. I am talking about complex IT projects for large corporations where millions are at stake, not just a few tens of thousands for a simple website. Shockingly enough, the problem remains the same.
I personally stood on the client's side countless times while we had to deal with shoddy work delivered from outsourced development agencies. That's always tough – the budget is spent, launch date nears, and you look at the "final" product and wonder what went wrong.
You know the saying "expectations vs. reality", right? When I founded my first startup, we were successfully funded by an angel investor and decided to outsource the creation of the app so we would have been able to focus on business development entirely.
Result? Bad UX (our inexperience), laggy, slow, and failing to cope with thousands of active users after the release. In the end, the code was so unsatisfactory that we were forced to throw it all away and rewrite it ourselves, which cost us a substantial amount of funds and time.
A couple of years later, I stood on the other side of a deal. As a project manager in a development agency, I led assigned projects. Some turned out to be a success, while others failed. Overpromising and poor quality management sentenced a few promising projects to death. I would still have a problem to stand up and look straight into the eyes of our former customers who spent millions and got unfinished garbage with bugs, unsuitable architecture after the deadline, and without needed scalability. I was responsible for some of the project mistakes, but the biggest blunder of all was that I didn't raise my voice enough and let this partially happen.
I had to run away from the last project that became a huge and pricey fiasco. By the way, the product was never released due to low software quality.
This is just a part of my background from which I draw a motivation to do things differently now, and that's why I founded a development agency with transparency and high-quality services at its core. Every IT professional should realize that a client is in their hands, and they should act accordingly.
Warning light should start beeping in your head every time you encounter any of these practices.
Agencies will promise heaven on earth to close the deal. Unfortunately, problems usually start right after a contract is signed, and you soon realize that the agreement won't be fulfilled in time and for the stated budget. If an agency promises a short deadline without knowing the whole scope of your project, you should proceed with caution. The same goes for budgeting – it is easy to send an underpriced offer to look cheaper against other rivals without knowing the exact scale, but you know when something seems too good to be true, it probably isn't real.
What to do about it: Consult with someone who is not interested in the deal.
The deal is sealed, and work begins – the client is happy for now, and no questions are asked. What happens in this situation? Regular updates are sporadic, and the client doesn't know how the project moves forward. Non-transparency leads to misunderstandings when the client is usually not acquainted with risks, challenges, team, and the whole development process. Again, if the agency you work with doesn't allow you to inspect a project's git or testing environment, you should be concerned. The initial brief is crucial, but large apps need attention and constant dialogue between the client and the agency. Otherwise, you may end up paying for a product in significantly lower quality than the one you imagined.
What to do about it: Always ask for regular updates and access to all essential parts of the code.
As a client, you hope to launch your project and grow it over the years. You are thinking ahead. On the other side, there is a short-term thinking agency that cares about covering its expenses, making a quick profit, and moving on to another project. Instead of a long-term partnership where the agency would make much more money by providing a constant value to the client, they transfer the team elsewhere.
How is it possible that agencies with this attitude even exist and aren't haunted by their reputation? I believe that this is due to a significant imbalance between the supply and the demand. Nowadays, there are more startups than ever, and not everyone can code. Therefore even bad agencies can survive.
What to do about it: Before choosing a supplier, find someone who has a history with them and can tell you how the cooperation went. However, even the not so good agencies may have great reviews. Try to dig deeper and find projects in which the agency participated and which now look different or aren't on the market at all.
Project management is pivotal for success, but many agencies still try to save money on project management roles. How can you save money? Hire juniors! It is excellent for juniors to get their hands on a large project, but it is not so great for clients. Project managers are responsible for translating the client's needs to the development team and ensuring that both sides understand each other.
What to do about it: Always ask for experienced project managers to achieve a desirable outcome.
Yes! I came across a practice where an agency charged a senior developer rate, but a rookie did the job. When you understand code, you see its flaws immediately, but as a client, you probably won't even notice until the whole app starts crashing, and you have to rewrite large parts to make it work. Also, you should pay well less for a junior developer than a senior one. Unfortunately, that is not always the case.
What to do about it: Get to know the team to be sure that it can deliver the desired results.
Don't get me wrong. Everyone started as a junior, but you have to learn from more experienced colleagues as a newbie. If there is an agency staffed only with enthusiasts who built a small website and think they know everything about delivering projects, back off. Even if they are bright and skilful, the probability of wrong decisions that affect the whole architecture rises tremendously without seniors. Never let the agency train its team for your money.
What to do about it: Before you seal the deal, check whether the agency has senior people who will be assigned to your task. Never go with juniors only.
This point is linked to the second practice, but I want to make it very clear. The client must always see progress, a demo, first version of a product, outputs of sprints, etc. to feel included. Otherwise, he won't be able to express his remarks. There is always a place for misunderstanding in communication, and that's normal, but you have to sort out these issues as soon as they arise. If not, you put the whole project in jeopardy.
What to do about it: Be in frequent touch with project managers or product owners. Lack of communication always indicates troubles.
Only a fortune teller can give a client a fixed price without knowing every need and the scope. No analysis and no design mean no real clue, just assumptions. A fixed price is usually not the best way to drive a project's budget. Why? New requests and challenges arise along the way, and there is always a variable that couldn't have been estimated correctly. These factors may lead to a complete shift in scope, and when there is a fixed price, there is no space for manoeuvres. In this scenario, the agency will do the absolute minimum to deliver at least something but a minimum isn't good enough for a competitive market. Sure, a client can always pay for changes and additional development – but is it really a change request when there was no clear scope in the beginning?
What to do about it: As a client, you may think that a fixed price is beneficial to you. However, in large projects where you don't have a clear picture of the outcome, it may be the fatal trap.
I don't think that this blog post will change the way some agencies work. But if it saves one client from making a wrong decision, then it wasn't pointless. One final remark? I see a trend that I labelled "junior founders". What is it? People start their own development houses even during their studies, and I think that is great. It has one catch, though. You can be a prodigy with incredible coding artistry, but still, you lack real project and product experience where something always happens. These junior founders then have no other option but to learn the whole development process on the go for client's money. And that's unfair.
At Jimmy, we are changing the game of IT outsourcing. I will describe it in the next article. We help clients to build products people love.
Reach out to get more information.