As we’ve learned through our own clients, the greatest cost to a successful engagement is usually internal. While economic costs of top talent have soared over the last decade, companies — and software development agencies in particular — have found more cost-effective ways to accomplish the same tasks.
Outsourcing development is likely one of the most common strategies to accomplishing more output with less resources. And while outsourcing to talented coders in Eastern Europe, Asia and Latin America has proven successful for many, the cost of failure is huge. Extreme cases can involve intellectual property stealing and being left vulnerable to security breaches, however, the most common and therefore most costly downside remains, poor project management and communication.
Our clients, in particular, share that more important than simply executing on tickets and tasks, are the organizational intelligence (e.g., project management efficiencies and product improvement) that come from an established, open and transparent feedback loop.
Development can go wrong
Take one of our client’s projects as an example: to protect their identity and respect their NDA, we’ll simply call them Tax Software Co. Like many medium-to-large enterprise service companies that live in traditionally non-tech sectors, there comes a point where domain expertise seeks to create a tech stack to leverage Machine Learning and Artificial Intelligence to improve and automate parts of their business. And that is exactly what Tax Software Co. sought out to do when they hired an outsourced Software Development Agency. Let’s call them the Other Guys.
Like other domain experts with a big dream, they were clear on their pain points, but not on how to solve them. The pain points were communicated to the Other Guys and deliverables and sprints were promised. The product roadmap looked great: wireframes and competitive research in Sprint 1, architecture build in Sprint 2, integrations in Sprint 3, and so on.
As you can imagine, Tax Software Co. felt great. They could see their product and from their perspective, they had the right vendor with the right skillset.
Wanting to be a “good client”, Tax Software Co. gave trust and leeway to the Other Guys’ Project Manager and checked in at the beginning and end of each sprint. Tax Software Co. thought that the calls at the beginning of the sprint were sufficient to provide all requirements and context for the Project Manager (who was the only point of contact on the call) to communicate them to their engineering team.
However, they were wrong.
Tax Software Co. realized after the second sprint, as they were beginning to miss important goals and milestones, that the scope was changing mid-sprint.
The requirements, which were based on integrations with other softwares and systems, were not working and therefore were not achievable.
And so the Other Guys would prepare findings, share what activities were performed during that sprint, and then conclude that the requirements needed clarification. Lastly – and this was the worst part – they were told that the hours dedicated to the sprint would need to be used instead to research feasibility of the requirements, so rather than work to meet the milestones, the time Tax Software Co. believed was getting them closer to their product goals, was actually driving them farther away.
They were out of the feedback loop: they communicated with one Project Manager, there seemed to be different engineers and designers on the project and they didn’t have direct access to the code. Four months and thousands of dollars later, Tax Software Co. was without their product and left with lessons of what not to do when hiring a Software Development Agency.
To make sure they could carve out what they had developed, they hired an external consultant to audit the code. And that process highlighted failings:
- First was requirements, how to define them specifically and to stay away from general objectives. When you have a bad project manager, they are going to bring up all the reasons a big objective couldn’t get done, and they will find ways to execute on the specific tasks that are actionable. Maximize the actionable tasks, especially the ones that move the needle on the bigger objectives.
- Second was how to track and measure progress. Tax Software Co. was reviewing on a macro basis when at the beginning of a new relationship, there needs to be iterative review. Transparency is seeing work performed in real time (or close to real time), and while Tax Software Co. felt they were being good managers, product development requires iterative validation, and the only way they were validating was at the end of a Sprint where in-progress review and measurement was necessary. There was no project management system outside of that which was created at the initial onset of scoping. A project management system is only as good as it is used, and this was not. Do not assume that developers are good project managers, verify early and constantly and make sure there’s a transparent system that communicates this outside of meetings which are time drains, and in the case of Tax Software Co., were consistently disappointing and not effective for course correction.
- Third, get and provide feedback to improve product functionality and revise requirements in real time. One of the auditors’ findings was that a three-week sprint was too long, it allows developers to push their tasks to the last minute and create what is possible in a short amount of time. It was counterintuitive: a greater sprint time provided for less work. Another finding was that the PM was likely moving work to different offshore developers. There was no consistency. Have a feedback loop where you can see when work is being performed and you can provide feedback and where a fixed team is learning your product requirements. This will evolve the collective team and create a better product.
In conclusion, these are the issues that we take into consideration when developing products for our clients, and here you can find some tips to avoid these kinds of inconveniences.
- Ask your vendor if they can include a technical lead in each meeting, to validate what is possible and what is not. You will also save time having a lead on the call because the PM doesn’t need to communicate requirements again as they were provided by the client. A technical lead is also good to have on the call to confirm assumptions and viability in real time.
- Record every meeting and share with the client. Doing so allows you to document requirements after the meeting so you don’t need to take notes and can focus on the conversation. This applies to both sides, allowing for more focused and present meetings.
- Open a Slack/ Discord channel with your vendor to allow communication between client and developer during the sprint, this allows for a close feedback loop. You want iterations to be tight as possible and while these tools can be counterproductive if overused, every team should define what kind of information is communicated live in Slack versus in their project management system (e.g., Jira, Asana, Trello) to make it more effective.
- Ask for access to the project management tools that the development team is using so you can track activities in real time and get faster feedback when things don’t go according to plan.
Know Your Team
If you are in this situation where trust and results are compromised by a software development agency and need help to make progress the right way, don’t hesitate to reach out by click on hte link
.