7 Hidden Secrets for a Successful Off/Near Shore Development
Beyond the standard project management processes using an Agile development system, here are 7 secrets you probably didn't think about which contribute to a successful project completion
7 Hidden Secrets You Didn't Know
There are so many horror stories of companies who were thoroughly disappointed with their development outcomes using outsourced off-shore software development companies. For example, a San Diego start-up developing a Telehealth application cited a low-ball development price of less than $30K that would include video conferencing/conversations with the doctors, along with creating a medical record that could be integrated into the client's EHR system. One year later, they are suing that company and have already started developing with another company along the same vein, and appear to be making the same mistakes as before. To ensure you follow best practices for successful software and business development, it is recommended that you take courses with TechSpeak for Entrepreneurs.
If you Google search for tips for successful offshoring development, you'll find a number of articles produced by outsourced off-shore software development organizations. Most advice published by these sources follow the more obvious tips for successful software development. Tips such as providing specific details, communication, setting clear goals, engage and interact and choosing the right team are obvious activities for all software development to those of us who are experienced in software development, whether it is off-shore or your own in-house development team. However, we've developed a different list of seven hidden secrets that you won't find anywhere else. These are secrets that will make a stark difference in improving your chances of success that come from decades of experience in using different off-shore, near-shore, and on-shore software developers as viewed from the customer's point of view.
Secret #1 - Technical Lead Is Near You
While the development resources can be off-shore or near-shore, the best way to ensure success is to have the technical leadership be resident in a close time zone as you. Close would be within 3 hours like it is in the US. The most important person in the development process using outside resources is your development team technical lead. That technical lead can be on your team or on their team. That person(s) must be extremely strong and is essential to fill in gaps that absolutely will occur during the development process. Being in the same or similar time zones, the technical lead can be readily available for rapid and constant adjustments that occur during development. The technical lead is the primary communication conduit between you and the project team, and the technical competence of that individual can make or break the project. Obviously, the technical lead needs to have excellent communication skills which can actually be quite challenging for highly technical leaders.
Secret #2 - Embrace Exactness
Using off/near shore resources creates a natural barrier due to language, cultural, and time zone differences. What may be obvious to you will be invariably interpreted differently, even with written product specifications. When d developing software, the more exact you can be with providing guidance on the requirements, the better the end result will occur. We call this Embrace Exactness. There are two tools for producing exactness; prototype builds and functional requirement documentation.
Prototype building is essential to this concept. Either you will need to supply this capability, or your development resource needs to supply this capability. There are tons of prototype tools available to simulate the end application. A few of the popular ones are Figma, Adobe XD, InVision, and Sketch. While this provides an obvious guide to the UI and user flow, what might not be so obvious is that performing this extra step can make a significant impact on the architecture and design of the back-end. The prototype can convey how the data architecture is to be organized. Back-end development is significantly harder and more costly to change while mid-stream in the development cycle. Developing a prototype during the early stages of development, bridges many of the comprehension gaps that typically occur with off-shore teams. Prototypes are essential too, for early customer feedback, and can be used as a demo for the sales team until the real application becomes available.
Secret #3 - Product Management
We're a bit biased on this secret. Whether you hire a seasoned Product Manager or not, what is essential is that a great product management function is essential to a successful project. Building the wrong product has THE most impact on wasted development costs. Specifying product requirements needs to be clear, and concise as close to the beginning of the project as possible in order to minimize the re-do factor. If you don't have an experienced Product Management function on your team, you need to make sure there's a competent and experienced Product Management function being provided by the outsourced developer. Product owners focus on what to build, not how to build it. During daily stand up meetings and demos/sprint reviews, product owners can provide the most value by evaluating development progress from a functional, end-user perspective. They generally shouldn’t be focusing on specific coding decisions, but on the user stories, and the key tasks users need to be able to accomplish.
Many organizations mistake the technical lead of the project, for a product manager, which leads to project issues. They are entirely different skill sets. Excellent product managers help bridge the gaps between the business and technical worlds translating business needs to technical jargon made for the technical audience, the developers, to consume. Technical product leads provide direction on implementation not which features to include. They don't tie features and functionality to how it relates to business success.
A major contribution by an Expert Product Management is the production of Functional Requirements, documentation on HOW the application works with WHAT features but not on HOW to design the software. Excellent product management results in reduced resource waste and avoids scope creep, focusing on the MVP (MinimalViable Product) to ensure projects are completed on time and under budget.
Secret #4 - Be Involved
There are some outsourced companies that only allow you to interact with the project manager and the technical lead. This leads to the development process being at arm's length, which increases the risk of an undesirable outcome. To be successful, choose an outsource development partner that will allow you to participate in close collaboration in the development process.
While you don't need to micromanage the outsourced developers, being intimately familiar with project implementation during the development phase and ready to immediately address any issues that invariably occur is essential to project success. At a minimum, a technical lead from your own team should be involved with the outsource dev team's daily scrums. You should participate by either reviewing Agile user stories to ensure they are correct or by generating the user stories for the outsource team to follow. This activity can be done by your technical lead or a technical product manager. Ideally, the scrums are led by your team, with the outsourced developers taking direction from your own tech team.
Secret #5 - High Level Docs
While documentation is certainly important, there are two high-level docs that are especially important to be developed for medium and high-complexity software applications. Medium or high-complexity products would be defined as a team of 5 or more developers needed to complete the project at the target deadline. The two documents are the software architecture and data flow architecture documents. Software architecture documents cover topics such as a block diagram of the software architecture, software components or technology stack, developer tools, cloud services to be used, data models, programming languages and how internationalization is managed (if appropriate). The data pipeline architecture will encompass topics such as data sources and/or categories, ETL/ELT process, data pipeline automation, data integrity, data security, data provenance (if being considered), data editing, and data revisioning,
Secret #6 - Create a Winning Team Culture
Our favorite NBA team is the Warriors, who recently won their 4th championship in 8 years. This winning record is considered a dynasty in the professional sports world. Part of their success is attributed to creating a winning team culture. What is a winning team culture and how do you create it? There are books written on this topic, but here are a few items to consider. 1) A winning team culture is whereby the "team" is more important than the individual by everyone who is part of the day-by-day development. Leaders check their ego at the door and every team member is considered important to the success. 2) Make the experience of working on the project to be enjoyable. That means the team members you select for the project should meld with your "joy style" as well as bring an atmosphere of levity to the work atmosphere. During the year whereby the Warriors had the worst record in the league, they still brought the "winning culture" to their practices. They played music in practice, still made fun of each other, made fun of themselves, did birthday videos, and invited the player’s kids to come in and shoot. 3) Create an atmosphere of learning and growing and getting better, being in a really healthy environment. 4) Treat each team member as part of your own organization, even though technically they work for the outsourced development company. Make them feel like they're just as important to your company as your in-house employees.
Secret #7 - Plan Tomorrow Today
It is always difficult to know what the future holds, particularly when you're scrambling to make a project to be on time and under budget based on today's requirements. However, to the best extent possible, future product plans should be explored near the beginning of the project development to ensure that the final architecture can either support future needs or has an easy reasonable path for minor modifications to the architecture in future product releases. Major changes to the back-end based on future product requirements are extremely painful and result in a ripple effect across the entire product and customer experience. Or worst yet, essential new product requirements would not even be considered because the ROI on the development cost doesn't substantiate the increased forecasted revenue for the new product requirements.