The 5 Cardinal Sins of Outsource Project Management
Having spent several years in the business of outsourcing software solutions and providing outstaffed development teams to clients, we’ve thankfully had the lion’s share of project success stories among our many clients. That being said, we also had a fair amount of painful lessons along the way, especially in the early years when outsourcing was still somewhat of a foreign concept in the IT industry. Although times and technologies have certainly changed over the last few decades, there are a couple time-tested truths that we’ve learned in our 15+ years of business that we always keep in mind when engaging with clients. In this article, we’re going to briefly go over some of the more dangerous obstacles to avoid when managing an outsourcing team on a project.
It’s Basically Just Communication
90% of project management issues are directly connected with faulty communication - either on the side of the client, the outsource team, and/or between them both. This miscommunication can take many forms (which we’ll get into in a little bit), but the overall root of these problems should be considered very closely. In situations where both parties are actively trying to maintain and improve communication channels, development hums along fairly smoothly and in predictable patterns. The issues arise when folks start getting lax in their reports and feedback, and misunderstandings occur or expectations are misplaced.
So what specifically should be done when maintaining solid communication with an outsourced team as a client?
Two way communication trumps one way every time
At Binary, we insist on a “window of communication” with each of our clients which constitutes at least an hour a day overlap with our working office hours and theirs. During this time, every member of our team and the client will be online and available for quick, two way communication to resolve issues, ask questions, and quickly sync up on the entire project as whole.
Some clients are content with having a sort of “lag” in communication, where engineers are working on a completely separate schedule as the project manager/owner on the client’s side, and therefore messages can take up a day to be received (due to the time difference), and another day to be answered to. This can effectively stretch out a 5 minute task across two days, which needless to say, is terribly inefficient.
Don’t have too many links in the chain of communication
Another issue closely related to this is involving a needlessly long hierarchy of stakeholders in every communication made about the project. While this may be necessary in some enterprise-level projects (or it might not be - that’s a debate for another blog post!), in our collaborations with SMB’s and startups, it is clear that the fewer people that need to pass information on to others, the better.
In our case, our clients communicate directly with each of our engineers and utilize shared channels on platforms like Slack or Hangouts in order to keep everyone informed on a topic without having to pass information along through several managers and playing the “broken telephone” game.
Some clients and dev teams insist on having a PM (or several!) to funnel information accordingly, but in nearly all of our experiences, this just adds another potential point of failure on the communication chain and wasted energy. While PMs can certainly provide value to a development team, we strongly believe that they should be an equal participant in discussions and not simply a chokepoint of information for others to go through when they need an answer.
Culture fit definitely matters
A lot of communication issues stem from an often overlooked part of outsourced collaboration - culture. While this also loosely covers things like language barriers and time differences, we can assume that most professional, high-end outsourcing firms will cope with both of those issues adequately in this day and age. However, culture can play an even deeper yet less obvious role in influencing the outcome of a project.
One of the most oft-heard complaints we hear from clients who have worked with other outsourcing firms is the lack of ownership or proactiveness in other outsourcing terms they’ve worked with. They relate experiences where outsourced devs acted simply as “monkey coders” who needed to be guided along every step of the way in the development process, and who never provided their own insight or expertise in suggesting something that might improve the platform.
In all honesty, this is an issue that has plagued us here in Ukraine over the years - 70+ years of Soviet rule indoctrinated a lot of people and taught them not to question authority or take initiative - “thinking out of the box” is still a fairly recent concept in this part of the world, relatively speaking, and it’s something we’ve spent a lot of time and resources in teaching our own engineers through things like our Academy program.
Ukraine is not alone in this regard, however, and we’ve heard our fair share of complaints from customers who worked with outsourcing companies across the globe that ran into this issue of strict hierarchies and “passive” attitudes from engineers who are too afraid or simply uncomfortable in stepping out of their comfort zone and making proactive choices/suggestions to improve a product. Therefore, it is important as a client to determine what you’re really looking for in a partner and investigate a given firm’s approach/attitude to these kinds of questions before committing yourself to a long-term engagement with them.
Be explicit, or prepare for experimentation (which costs money!)
One of the biggest red flags we see from clients is a combination of strict deadlines/budgets and a lack of detailed information and requirements about the project. While we are big advocates of Agile development practices at Binary, we want to make sure our clients understand what that entails with regards to T&M contracts and paying for developers’ time (which is how we operate).
When a client comes to us with a 10-point bullet list for a complex platform that will take 6+ months to build and very little else in terms of information, we are happy to engage with them - but there will inevitably be a lot of questions, experimentation, and ultimately large parts of the developers’ work will never make it into production as they are forced to interpret what the client wants (due to lack of detailed information). And while we’re always willing to work on such projects, it can be demoralizing for both the devs and the client to see so much (expensive!) dev time spent and “thrown to the wind” once it becomes clear how the final product should actually be versus how the devs thought it should look like!
To avoid this, we encourage our clients to spend the time upfront in creating as many detailed technical documents as possible before engaging a dev team to put together a platform, as it will inevitably be cheaper than simply having the devs guess what the client wants. And remember - there is a big difference between an MVP designed to test the market and a final release platform that should have every feature imaginable included!
Turn-key, hands off app development is a myth - you get what you put into it
Finally, it’s worth noting how many clients we have worked with in the past who have come to us with a detailed plan on how to build an app, but neither the time, energy, nor desire to spend on actively participating in its development. They envision software development as something akin to ordering a pizza (albeit a considerably expensive one) - they just tell the dev firm what they want, pay the appropriate amount of money and wait the required time, and then bam - they get their app.
However, building an application (especially a successful one, and within budget/deadlines!) is rarely this easy and does require significant, frequent input from the product owner. Devs are not mind readers, nor are they usually seasoned entrepreneurs themselves - while they can draw on their experience in making good software, they can only anticipate the desires and nuances of their end users so much. Without active involvement from the client providing feedback from themselves or users, devs have little idea how well the app is being received and what should be done to improve it.
Therefore, as a closing note, we’d simply like to point out that in our 15+ years of experience developing software, the most actively engaged product owners have an overwhelming tendency to be more successful in both their software development as well as their business in general. There is no such thing as a self-managing outsourcing team, and while experienced and qualified engineers can certainly work wonders, they are a force multiplier that should be directed by a product owner who is truly committed to the success of the platform and its development.