From Global to Regional: How De-Globalization is Reshaping Software Development 

From Global to Regional: How De-Globalization is Reshaping Software Development 

High-Performance Collaboration, Outsourced Engineering Team, Remote Work, Software Development, Strategic Digital Nearshoring, Successful Outsourcing

Written by Luis Aburto- 

Hands interacting with a digital world map representing the shift from global to regional software development.

For decades, global software development followed a simple logic: find the best talent at the lowest cost, no matter where in the world it lives. Time zones were managed, cultural gaps were bridged, and the software kept shipping. But as the global order shifts, that formula is being challenged, and so is the assumption that software delivery is immune to geopolitics.

In 2022, many companies with teams in Ukraine saw their operations halted overnight. U.S. export controls are increasingly restricting access to critical cloud and AI infrastructure in China. Attacks on undersea cables have exposed vulnerabilities in global internet connectivity. And more countries are tightening control over data, digital talent, and software supply chains.

In 2025, the conversation around globalization has intensified. Recent point to a growing consensus among economists and business leaders: the era of hyper-globalized trade and supply chains is being restructured. Rising tariffs, geopolitical realignment, and regional trade blocs are accelerating a shift toward localization and strategic decoupling.

What do these events have in common? They signal the arrival of a new era, one where global integration is no longer a given, and where resilience in software development must be earned, not assumed.

The Shift: From Globalization to Fragmentation 

We are not witnessing the end of globalization, but rather its transformation. The model of deep, frictionless global integration that defined much of the past three decades is giving way to a more fragmented, controlled, and regional system. Instead of chasing the lowest cost globally, many companies are prioritizing stability, alignment, and resilience within trusted regions. 

This shift is reflected in the rhetoric and actions of governments and business leaders alike. As international institutions weaken and trade tensions rise, companies are being pushed to reevaluate the vulnerabilities built into their global operations. Strategic decoupling, whether intentional or reactive, is now part of mainstream decision-making for many organizations. 

Key drivers of this shift include:

  • Geopolitical tensions and the formation of new regional blocs, as countries seek to reduce dependence on politically unstable or adversarial trading partners
    Economic nationalism and policies favoring domestic or allied suppliers, including tariffs, reshoring incentives, and export restrictions.
  • Cybersecurity risks heightened by nation-state actors, infrastructure sabotage, and the weaponization of digital supply chains
    Regulatory pressure around data localization, intellectual property protections, and labor compliance, which can vary widely across jurisdictions 

In this environment, global operations are being restructured not simply for efficiency or cost savings, but for strategic resilience, a foundational requirement for long-term continuity and competitiveness.

Scio focuses on secure, resilient software development in response to global fragmentation and cybersecurity challenges.

Why Software Development Is Affected 

While physical supply chains have received much of the attention in discussions about de-globalization, distributed software development is also highly susceptible to geopolitical disruptions, often in ways that are less visible but equally consequential.

  • A conflict, regulatory crackdown, or even targeted sabotage, such as damage to undersea fiber optic cables or critical digital infrastructure, can cut off access to talent or tooling, particularly if a development hub becomes inaccessible or politically unstable overnight. These infrastructure vulnerabilities add an additional layer of risk, as companies often depend on a handful of chokepoints for their global communications and cloud-based tools.
  • Sanctions can interrupt payment channels or cloud service agreements, stranding teams mid-project or forcing abrupt transitions to alternative infrastructure.
  • Engineering teams working across conflicting legal frameworks may face compliance or IP protection risks, as differing data residency laws or intellectual property rights create exposure.
  • Developers may lose access to global platforms like GitHub, Docker Hub, or AWS services, or be forced to rely on unstable VPNs or workarounds that slow productivity and introduce security risks.
  • Political unrest or changes in labor law may create sudden hiring or retention challenges, undermining team continuity and morale.
    Increased scrutiny from investors and enterprise clients means companies must now prove the operational resilience of their distributed teams as part of vendor risk evaluations. 

These risks may not be visible on a Jira board or in a sprint retrospective, but they are real, and they can derail product timelines, introduce hidden costs, compromise data integrity, or weaken overall software quality if not proactively identified and managed.

Rethinking Sourcing Strategy: Risk-Aware Engineering 

To adapt, technology leaders are shifting their sourcing mindset from cost-driven to risk-aware. That doesn’t mean abandoning global talent, but it does mean being far more intentional about where, how, and with whom your engineering work is delivered. 

This shift involves a more holistic view of software talent sourcing, one that accounts for not just operational capabilities, but geopolitical alignment, digital infrastructure stability, and long-term viability. It also recognizes that sourcing strategies are no longer static. In a volatile world, resilience demands agility and the ability to reconfigure delivery models when needed.

Here’s what that shift looks like:

  • Evaluating not just the capabilities of a vendor and their people, but their geographic and geopolitical profile, including political stability, trade relations, and cybersecurity maturity.
    Avoiding overconcentration of critical functions in one region or firm by building geographic diversity into your engineering footprint.
  • Prioritizing alignment with stable, accessible, and politically compatible locations that reduce legal, regulatory, and operational friction.
  • Building optionality into team structures, with flexible paths to rebalance, scale, or transition work depending on emerging risks or strategic shifts.
  • Partnering with vendors that demonstrate transparency, robust identity verification practices, and ethical hiring standards to avoid risks such as misrepresentation or fraud.
  • Incorporating resilience metrics into vendor evaluations, ensuring your outsourcing partners have contingency plans and recovery protocols in place.

The goal is not to eliminate risk altogether, an impossible task, but to anticipate, distribute, and manage risk in a way that protects both continuity and innovation.

Scio evaluates strategic software sourcing through a geopolitical lens, emphasizing risk-aware engineering decisions.

Nearshoring: A Strategic Middle Path

In this context of economic and geopolitical uncertainty, nearshore outsourcing becomes even more strategic. Nearshoring offers a hedge against geopolitical disruption by keeping operations closer to home and within more stable economic zones. At the same time, it enables companies to achieve cost efficiencies and tap into scalable talent pools, without incurring the long-term liabilities and rigidity of direct, in-house hiring. This combination is particularly valuable in uncertain times, offering companies the ability to stay agile, control labor costs, and accelerate execution while minimizing exposure. 

For U.S.-based companies, nearshoring, particularly to Mexico and Latin America, is a compelling alternative. In addition to cost and productivity efficiencies, it offers a blend of: 

  • Political Stability and Predictability: Mexico and key Latin American countries offer relatively stable political environments, reducing the risk of disruptive events compared to more volatile outsourcing regions.
    Robust Regulatory and Legal
  • Frameworks: The USMCA agreement ensures clear and consistent regulatory frameworks between the US and Mexico, offering predictable rules for data protection, intellectual property rights, labor laws, and cross-border commerce.
  • Aligned Economic Interests and Strong Diplomatic Relations: Mexico and the United States share tightly integrated economies. These economic ties minimize the risks of disruptive trade sanctions, tariffs, or restrictive economic policies that have impacted other regions.
  • Robust Bilateral Security Cooperation: Mexico coordinates closely with the U.S. on security, intelligence, and regional stability, helping reduce geopolitical risks in the region.
  • Reduced Infrastructure Vulnerabilities: Proximity reduces reliance on vulnerable undersea cables. Mexico has robust, direct connections to U.S. networks, lowering the risk of major connectivity disruptions.
  • Lower Cybersecurity Threat Exposure: Politically aligned countries tend to pose fewer cybersecurity risks. Nearshoring within North America under USMCA offers greater transparency and lowers the chance of state-backed cyber threats.
  • Talent Integrity and Verification: Mexico and most major countries in Latin America have mature educational systems, established professional standards, and extensive verification infrastructures. This helps minimize risks related to talent fraud, misrepresentation, and credential falsification common in less regulated outsourcing markets.
  • Ease of Geographical Diversification and Redundancy: Many nearshore vendors maintain multiple operational centers across Mexico and other countries in Latin America. This geographical diversity enables seamless continuity and rapid failover in case of localized disruptions, further enhancing resilience.
  • Ease of travel and face-to-face collaboration, enabling in-person visits with minimal logistical risk compared to long-haul or politically sensitive destinations, especially valuable for relationship building, onboarding, and team alignment.
  • Closer proximity to key stakeholders and decision-makers, which enables more responsive collaboration and deeper alignment between technical execution and business priorities. 

This model doesn’t just mitigate risk, it often accelerates productivity and integration, thanks to smoother communication, greater cultural fit, improved responsiveness, and a more resilient and adaptable operational setup.

Scio team collaborating over a digital world map, representing strategic nearshoring opportunities in Mexico and Latin America

The Bottom Line: Global Isn’t Dead, It’s Evolving 

Global software development isn’t going away, but the rules are changing. The companies that thrive in this new era will be those that treat resilience as a priority, not an afterthought. In this environment, companies must evolve from reactive adaptation to proactive strategy, embedding resilience into their sourcing, operations, and partnerships. 

That means regularly auditing your current engineering footprint not just for efficiency, but for exposure and fragility. It means rethinking where your teams are located, how easily they can collaborate, and what contingencies exist for business continuity if disruption occurs. 

And perhaps most importantly, it means partnering with organizations that understand how to build reliable, distributed capabilities in an increasingly unpredictable world, partners who offer not only talent, but infrastructure, cultural alignment, transparency, and adaptability. 

In this next chapter of global software development, success will go to those who treat resilience as a strategic asset, not an operational afterthought.

Luis Aburto_ CEO_Scio

Luis Aburto

CEO
The show must go on: Developing a venue booking app with UPick

The show must go on: Developing a venue booking app with UPick

Customer Experience, Outsourced Engineering Team, Successful Outsourcing

The show must go on: Developing a venue booking app with UPick

As the year winds down, it’s time to look back and celebrate all of our achievements of 2021, the challenges and the goals we conquered, and the clients whose projects we helped to become reality. 

This time, let’s take a look at the story behind the development of the UPick app, which had the goal of creating a useful and reliable booking tool for both venues and artists, and how we helped them bring that dream from concept to a product you can use today. Enjoy!

What goes into making a good idea into reality? For the creators of UPick, it meant finding a reliable team that could build upon their idea, understand the concept completely, and offers the best technical know-how to bring it from paper into every smart device you can imagine. The beginning was simple enough; back in 2020, a couple of friends were looking into an area of opportunity no one else seemed to be exploring yet: what if you could simplify the process to book a show for a venue through an app?

The show must go on Developing a venue booking app with UPick_2

The pandemic gave them a wide-open window to implement a solution for an industry that felt the consequences of this crisis deeply. Live shows account for nearly 50% of the music industry’s revenue, so six months into the pandemic, according to the World Economic Forum, shutdowns had already cost venues around the world 10 billion dollars in sponsorships and ticket sales, with no end in sight. 

But with vaccination rates increasing, it was probably a good time to try and bring shows back, and UPick’s creators thought that an app that offered a quick way to reconnect performers with venues had some fertile ground to grow.

So, in February 2021 they started considering Scio as a partner, looking for developers who could create this app from scratch, decide the full scope of the final product, and make important decisions about the direction of the platform.

This was the first time our clients worked with Nearshore developers, and the advantages of having a fully experienced team equipped and ready to roll inside your own time zone became invaluable, keeping the costs of development down without sacrificing quality. 

Since our clients had never been involved in a project of this size, constant communication to decide the specifics of UPick was critical, going from things like how to monetize the service, to the best hosting platforms to use.

Typically, development at Scio consists of a 5-step plan designed to arrive at a solution in the most productive way possible. Understanding users and their needs, as well as the objectives and constraints of the app itself, was Step 1. Step 2 involved analyzing the requirements of the app in order to trace a plan for the UX/UI and architecture of the platform. Then, Step 3 is pure Agile Development, up to the official launch, which was Step 4. And after the kick-off, is a matter of support to ensure the quality of the app, giving ongoing maintenance and adding features as a Step 5.

The Scioneers chosen were a Programming Lead who developed the architecture of the app, a UI designer tasked with creating a comfortable and stylish interface, another one assigned to create a search bar and review functions within the app, and a QA lead who would make sure everything worked perfectly.

Communication was key. Thanks to daily scrums, a core pillar of our process, we walked our client through the progress of the project, needing nothing more than 15 minutes every day to discuss the changes and challenges that surfaced, as well as what we accomplished, every week.

The show must go on Developing a venue booking app with UPick_2

Here, we solved tons of questions born during development, like “how will a band schedule a show?”, “how will refunds work?”, and “how will the venues and bands make deals?” to more technical matters, like choosing a cost-effective hosting solution (AWS in our case), implementing login credentials from Apple, Spotify, and social media (including some necessary workarounds), to selecting the best payment processor. 

Also, as we briefly mentioned, the business plan of the app had to be revised entirely once the booking process was decided, as Upick could easily be cut out from the deal between venue and performer, and our team took care of that.

The biggest breakthrough was deciding to make UPick a “progressive application”, where a web portal could function as an app with consistency across devices, like desktops and smartphones, making it as convenient as possible.

Then features were added, like the ability to share photos, videos, setlists, and even playlists from Spotify, and we had to rethink the way bands could contact venues as our understanding of these deals grew.

Progress went smoothly until finally reaching our Minimum Viable Product, where one of UPick’s users, whom the client showed a preview, managed to run all of their bands through the platform before it was 100% finished, which not only showcases the talent of our team but also made the customer base excited about the final product.

All in all, by September the app was ready to be launched, a whole project contained within the chaotic year of 2021, where Scio was able to offer the exact solutions UPick was looking for. A learning experience for both our team and our clients, we celebrate the effectiveness of Nearshore development, which can deliver no matter the circumstances.

The Key Takeaways:

  • Since communication is crucial to make a product succeed, choose a development option that can communicate with you at the best time possible.
  • It doesn’t matter if the details of your idea haven’t been ironed out yet, a good team will help you with those decisions.
  • Development time of an app, depending on scope, doesn’t have to be too long. It took us around nine months to bring UPick from concept to reality.
  • Some APIs are not very friendly, but there are always workarounds to any obstacle.
  • If better ideas surge during development, it’s good to always voice them. The schedule might need to be reworked, but the final product is always going to be better.
Agile Project Initiation

Agile Project Initiation

Agile Methodology, Customer Experience, Project Management, Successful Outsourcing

If you search on the Internet for «agile project initiation» you are going to find a LOT of templates. People want structure and easy answers, so of course, these simple answers rise to the top of every search. Many (if not most) of the templates offered are pared-down formats from the Project Management Book of Knowledge (PMBOK) Project Initiation Documents (PID). There is nothing basically wrong with the idea of using templates or most of the templates offered, except – they tend to become prescriptive when they should be taken as guidance.

From the Agile Manifesto: «…we have come to value:

Working software over comprehensive documentation,»

With that in mind, we should ask – why do we document agile projects? Often, the answer is – because it is required (by someone) when in reality the answer should be – to communicate. But again, that simple answer fails to guide us to the necessary outcome:

  • Documentation should be a natural part of agile project initiation, but not the goal. It should proceed from on-going discussions between stakeholders, the product owner and the development team that is developed in Sprint 0, but it must not end there. The conversations and the documentation of outcomes must continue through the lifecycle of the project and the product.

  • strawman

    Initial documentation is just a strawman

    Documents gathered from product owners and key stakeholders are starting points, not final documents. Documents developed by a designated team member to fill out a template are strawmen to be examined, discussed, questioned, and used as a base for the ongoing development of understanding within the entire project team.

  • Living documentation formats should be preferred over static. In smaller projects, it may not be necessary to manage documentation formally, but in most cases using the same concepts as those used for source code management is a valid guideline. Properly maintained, living documentation answers the questions, «when was this decision made? by whom?» and gives a revision history that tells the story when necessary, but only makes it apparent when needed. It needs to include simple artifacts of these discussions – photographs of whiteboards, screenshots of modified mockups, etc. – in preference to notes developed after the fact and out of the sight of the team.
  • During Sprint 0, the aim must be to develop enough trust among the project team members to allow questions and dialog to form the base for a common understanding of those items that are included in most PID templates. If initial documentation is «handed down from on high» to team members without open, trusting discussion – it cannot be internalized by the team and it will not respond to the inevitable changes that will come as discovery and learning continue throughout the project. Agile software development embraces change by allowing the project team to recognize the inconsistencies and discoveries that will come out during development, surface them and deal with their impact through discussion and collaborative negotiation.

And before we get too far away from it – there are some really strong ideas in the Agile Modeling page on Agile/Lean Documentation. Honestly, though, there is a lot of information in that reference that should really be digested as a part of understanding agile, not as a guideline for a new project. For that purpose, this short piece is a better resource. But, if the outcome of project initiation is not a bunch of filled out PID templates that we can all take back to our cubicles and file away – What is it?

Agile Project Initiation is All About Communication

With the ideas we have mentioned in mind, we have to acknowledge that open, trusting, collaborative communication does not happen automatically in an agile project team. There are natural stages that every group will go through before they can have the kind open discussion needed without fearing it will harm relationships and respect. Discussions need to be wider than the project infrastructure, technology, and user stories, without the feeling an individual is stepping over the boundaries by asking about non-functional issues. We might need to know:

  • Does the culture and background of key user profiles matter to the software development team?
  • Does the role of key subject matter experts (SMEs) in product development for an organization make a difference to who needs to be included in discussions?
  • Are we using a Lean Product Development model with the inclusion of stakeholder users as part of Minimum Viable Product (MVP) development?
  • If we are working in a DevOps implementation, how does that change our standard production procedures?

There are all sorts of questions that are not (and cannot be) included in standard PID templates but could be critical to a specific project. If we don’t discuss our viewpoints and ask questions, we run the risk of assuming we have a common understanding and making decisions based on those assumptions. Every project, every team, every organization is different. In the best case, we can open ourselves up to collaborative discussion by getting the team together, face-to-face during project initiation, for dialog and team building using team games and facilitation with a bias to being productive, explorative, and fun. Using these techniques, we can strengthen the bonds and shared risks necessary to maintain a successful project throughout its lifecycle.

facetofaceIn cases where face-to-face project initiation is not possible (hopefully more rare than the rule), much can be accomplished with video/voice meetings if they are relatively short and like agile documentation, structured just enough to ensure the meetings reach necessary outcomes and allow for continued direct discussions among stakeholders in the team when needed. There is nothing much worse than sitting in a meeting where a long, passionate discussion between two team members seems to be sucking all the air out of the room – and the meeting outcomes are lost.

This piece is relatively short and again, more of a guideline than a prescription for agile project initiation, as it should be if we are to «eat our own dog food.» Bottom line:

  • Don’t be afraid to pull out a template when you start your next project, or when you look at it – crumple it up and throw it away so you can start your own list based on what you know and don’t know.
  • What you think you know or don’t know are assumptions and should be treated as such both during project initiation and throughout the project. Only a discussion with open questions between team members can validate ideas and give us a basis for moving forward. And the assumption that is understood as valid today may not be completely correct at another time.
  • Documentation must be limited to what is necessary when it is necessary and maintained throughout the project as living knowledge. Agile documentation should not be the domain of one person or one role. It must be available and dynamic – allowing everyone on the team to contribute when necessary – in a wiki-style rather than as a bunch of locked Word documents.
  • Agile project initiation should focus on both the productive side – bringing together the information needed to organize the project, initialize environments, and the functional user stories needed, as well as the people/team side – developing the understanding, trust, and communication necessary to work collaboratively throughout the project. Ignoring either side is perilous. Assuming the job is done at the end of Sprint 0 is fatal.

Scio is a vendor of agile, nearshore services for software development projects with our customer base in North America. We can provide project-based or dedicated teams as required for each situation. We would be glad to discuss how our broad base of experience and skills could help you be successful with your next project. Contact us for more information.

Successful Software Development Outsourcing

Successful Software Development Outsourcing

Customer Experience, Nearshore, Project Management, Successful Outsourcing

As a provider of nearshore successful software development services, Scio has a proprietary interest in assuring the success of our customers’ outsourcing projects. But of course, in that respect, we’re no different than any service provider. So, it could easily be said that this article and more that will follow on this critical subject have a built-in bias we can’t ignore. We want you to understand our experience, our business model, and how it shapes our approach to providing outsourced services. We hope that understanding will lead you to explore working with us and to hire our team. So yes, this is an exercise in self-interest…. But that said, we also have an interest in promoting improvement in our industry and the knowledge of critical success factors (CSFs) for the outsourcing of software development. This certainly isn’t a new subject – both the buyers and the sellers of outsourcing services have been trading tips, CSFs, and white papers on the subject for years. A quick Google search will turn up thousands of papers from professional societies, trade journals, buyers and suppliers in the field. But it is a sufficiently rich subject, with ongoing learning and improvement, to continue the conversation among participants. Do we have important information to add? We believe we do and we’re willing to expose our knowledge and experience so you can judge for yourself. To begin the discussion, let’s set a few common terms in context:
  • Outsourcing is a broad subject and different industries approach it from different angles. In basic terms, we’re only discussing the outsourcing of software development, but many of the lessons learned in outsourcing across other industries do apply.  The term comes from tying together the words used to describe «outside resourcing» – bringing resources from outside a company to meet business needs. With that in mind, outsourcing can describe the contract of work to a provider in the same building, city or country, just as well as it can describe the outsourcing of work to a provider in a different country or a different continent.
  • Information Technology (IT) Outsourcing is generally considered to be a subsector of Business Process Outsourcing (BPO) that involves operation, management and maintenance of IT services and infrastructure within an organization. Although technical skills are necessary to maintain aspects of IT operations, generall software development is not the primary driver of IT outsourcing contracts.
  • Offshore or Offshoring is a term that, like outsourcing, has many meanings specific to the industry where it is used. For our purposes, it means the use of service providers with working hours that have very little or no overlap with their clients. Generally, these providers are on different continents with completely opposite work periods. A great deal of successful software development outsourcing is done by offshore providers so it is not intended to have a negative connotation. But, in many software development projects, communication and collaboration are key and in that respect, using offshore services requires special adaptations that both the client and the provider must be aware of and enforce.
  • Nearshore or Nearshoring in our context refers to the contracting of work to providers in a different country that shares significant working hours overlap and often shares a border, region or continent. Scio is a nearshore provider of software development services to North American clients. Our services leverage the benefits of a nearshore relationship with our clients so the situations where we work best tend to exploit those advantages. Successful software development outsourcing relies to a large degree on the relationship between the client and the service provider and the requirements of the work itself. Some software development can leverage nearshore advantages better than others. Some providers have adopted practices that lower the risks inherent in software development outsourcing, regardless of their physical proximity to their client teams. Regardless, understanding the differences between offshoring and nearshoring of software development projects is an important subject for all participants in the industry. There is no «one size fits all» as evidenced by the growth of both nearshore and offshore development centers within large outsourcing consultancies.
  • Agile Software Development is a methodology that is widely used across the software development industry. It is based on the idea that software development projects should be composed of short, iterative cycles producing valuable software incrementally while allowing for the evolution of the results based on constant consultation and interaction with the client and user base. The methodology itself is constantly improving and allows for adaptation to many situations. Because of this flexibility, the agile practices adopted for one project or practiced by a development team will vary, but overall the basic principles as they apply to client and team interactions and software quality during a project are expected to remain.
  • Scrum Software Development is an extension of the agile framework for software development down to the team level. It includes descriptions of roles, processes, and ceremonies that strengthen agile principles and give structure to the software development process. Like agile, it is an adaptable methodology but it does include more detail specific to the software development process. Scio provides software development teams using a proprietary implementation of agile and scrum. Not all software development projects require agile or scrum, but most can benefit from some level of integration with the methodologies.
  • Distributed Agile Teams are a part of the outsourcing of software development when you use either nearshoring or offshoring of a part of your agile team. In agile/scrum methodology, a premium is placed on open and frequent, face-to-face interactions between the development team and the product owner from the client-side. But, agile is also practical and adaptable, so there are practices that help to overcome the team isolation and improve interaction when parts of your team are remote. Scio is a provider of distributed agile teams for software development and integrates the practices necessary to assure success in these situations in all our projects.

What is a Successful Software Development for You?

It is hard to discuss «success» without knowing what it means to clients in general and it is almost impossible for a specific project to be «successful» unless all participants understand what it means from the start. In simple terms, most people would say without thinking it means providing software on time, on or under-estimated costs and that delights users – but that simple definition ignores all the trade-offs and pitfalls that need to be avoided or mitigated and the stakeholders who must be satisfied to arrive at a successful outcome. In researching the literature on this subject, an IEEE literature review came upon the subject that found some interesting results:

Top 5 CSFs for Success in Software Development OutsourcingSuccess Factors for Outsourcing

  1. Contract Flexibility
  2. Trustworthy Relationship Management
  3. Competitive Bidding
  4. Consultation and Negotiation
  5. Quality Management

Last 5 CSFs for Success in Software Development Outsourcing

  1. Time Management
  2. Culture Awareness
  3. Intellectual Property Rights
  4. Data Security and Privacy
  5. Detailed Specification of Product and Project
These results came from a specific set of criteria concerning the basis of the outsourcing contract and relationship, as well as the contract and contract management – rather than a soft assessment of project outcomes, so it is probably not what you might think at first. But consider the elements of the top 5:
  • Contract flexibility, like agile practices in software development, this allows the project to evolve in various ways to reach a successful outcome. It is a realization of the simple fact that at the outset of a project, and throughout the development cycle, participants don’t know what they might discover or how they will work together. A flexible contract, instead of locking them into a tight box, provides a framework for realizing opportunities not foreseen at the beginning of a project or dealing with unexpected issues that might derail the project. A good contract focuses on the objectives of the outsourcing relationship rather than operational details.
  • Trustworthy relationship management gives everyone involved the ability to bring issues up without fear and mistrust. It allows open negotiation during the development process without bringing everything to a screeching halt. Again, it acknowledges the established truth of software development – there are things we don’t know and opportunities we haven’t considered that will be discovered as we move forward. We won’t be able to consider them if we don’t have a relationship of trust between the players.
  • Competitive bidding, when it is done not just on price, but on a range of weighted factors, helps to increase the feeling of trust and control between the service provider and the client. Everyone understands what is important from the outset or has explored the issues until a successful conclusion is reached. Blind bidding, where bids are submitted, but no discussion or negotiation occurs among the top bidders and the potential client do not build this level of understanding however. No amount of paper and diagrams can substitute for the level of understanding that can be reached in direct, verbal negotiation.
  • Consultation and negotiation are a realization of the fact that constant communication is necessary in all software development projects to insure the development is on track to meet the goals set out in the beginning of the project or, where needed, the teams can negotiate in good faith to reach alternative outcomes that better fit the situation as it has developed. Virtually all software development projects need both a mechanism to ensure open communication and negotiation.
  • Quality management, not just against a set of detailed requirements (that is number 15 in this list after all). When everyone is involved in quality, it becomes a key to reaching a successful outcome. But as the agile methodology guides us, only if the management of quality is a continuous process throughout the incremental software development process. If it can only provide feedback at the end of prescribed  phases or the end of the project, the risk of going off-the-rails becomes too large and failure to reach the necessary outcomes of a project area almost assured.
Now, of course, you are likely to see a different list in your head or have a specific list of CSFs in mind for a project. But list brings up an important consideration – what weight should you put on the need to deal with change and to work successfully with your vendor throughout a project or relationship? And it is important to understand, this is a result of the frequency of a CSF being identified among several papers, not the weight it was given in any one paper, if indeed weights were given. So the number of times a CSF was mentioned in the surveyed literature produces the order of the list.

Nearshore? Offshore?

Successful Software Development We find these kinds of communication problems come up in many aspects of the provider/client relationship in outsourced software development. Agile and scrum development practices address these problems well, but in the case of offshore services, the agile model becomes stretched in ways that require adaptations that can be costly or distracting in the course of project operations. That is not to say that nearshore distributed teams, a model we use frequently,  do not require specialized planning and adaptations, but it is part of our standard practice package, not something we do on a one-off basis. We find all projects benefit from attention to better communication and tighter relationships between our teams and their product owners. And we have that built-in advantage of nearshore; our development team is working in real-time with the client team. There is a lot more to discuss successful software development outsourcing – and we will be doing just that as we continue to provide information from the field.
What Do You Need? A Software Development Team? Or an Engineering Team?

What Do You Need? A Software Development Team? Or an Engineering Team?

Agile Methodology, Customer Experience, Outsourced Engineering Team, Product Development, Project Management, Successful Outsourcing

Of course, the first question for anyone looking at this is – what is the difference? Let’s start by saying that we’re not speaking specifically about “product engineering” – although it plays a part in this discussion. We’re actually looking at software development teams broadly, how they work and what they can (and can’t) do for your development efforts.

What Do You Need? A Software Development Team? Or an Engineering Team?

Today’s IT environments can be complicated beasts – with unique mixes of internal and remote API’s, web services, service-based components, virtualized infrastructure, and various open source, proprietary and custom applications. Orchestrating this architecture to provide the internal and external business services for an organization is an increasingly critical operational concern. Depending on the size and complexity of the environment, it is likely to be managed by one or more skilled engineers who are focused on the security, standardization, automation, scalability, availability and reliability of IT systems.

Traditionally, software development teams have been separated from this complexity to some degree by internal standards for application architecture and operation developed by IT. But, as the maturity of IT environments has progressed and agile has become the standard of the tech industry, software development teams are gradually being integrated into combined engineering and engineering teams under DevOps implementations. At this point, there are many different levels of integration between IT engineering and software development teams and if you are considering outsourcing a project – knowing what you are asking for is an important part of your research and decision process.

So, let’s set up a scenario: You are about to embark on a custom software development project. For the sake of this discussion, let’s assume the application to be developed is strategic and tied to your business model. With so many applications and systems available on the market, if it wasn’t – you would probably just adapt an off-the-shelf application for your purpose. You have a charter and description of the business problems your custom application needs to address, a general budget and executive support. The decision has been made to outsource this project rather than do it in-house.

With that in mind, let’s insert some different conditions that could make a significant difference in your needs for an outsourced team:

  1. New, but fully-backed venture with basic organizational structure but with no IT engineering beyond office systems automation and help desk.
  2. Existing IT team with legacy experience but little experience with modern infrastructure or IT operation patterns. No dedicated development team or significant custom applications.
  3. Traditional operations, IT and software development but siloed – not integrated other than by operational standards.
  4. An enterprise-level organization with a fully-integrated IT operations and development team in a DevOps style implementation with a significant portfolio of custom applications that are under continuous development and/or maintenance.
  5. A new venture of an existing entity that is expected to operate as a free-standing organization based to a large extent on the services provided by the new application(s) developed during the project.
There are other complexities we could imagine, but for the most part, they can be addressed as variations of these five scenarios and the basic conditions we set up for this discussion.

1. The New, Mostly Naked, Venture

As a new and growing company, there is always (or there should be) pressure to be efficient and do things right from the beginning. If you have a technical leader in your team and/or a significant part of your operation is based on leveraging software applications to provide your services, there is a natural tension – should you focus on your customers, your value proposition and lead your software development at the product level (leaving the actual development to an outsourcing partner), or should you build and control everything in-house? We’ve covered this question before and it is a significant decision – but now, we’re considering a little deeper level of thought. If you are considering an application that will actually support all or a significant part of the services you offer and your revenue – the proper operation and maintenance of that application is a strategic decision.

Your application must be:

  1. Planned with a set of operational standards in mind.
  2. Scalable, so it can grow along with your business without significant rewrites and basic changes in architecture.
  3. Logically broken into maintainable and extensible modules so it can be enhanced and the value of individual services can increase as they find their place in your portfolio.
  4. Reliable across upgrades, changing loads, and new features through the full product lifecycle.
  5. Economical to operate and maintain based on a solid architecture and the ability to leverage automation across all levels of development, deployment, and maintenance.
What Do You Need? A Software Development Team? Or an Engineering Team?

Photoshoot at Cluster 8/1/16

If you are a new venture and you want to spend your time focusing on your customer, the value of your services, and managing feature-fit, you shouldn’t expect an outsourced development team to simply take on these issues from day one. They may deliver a wonderful application that provides everything you need, except the five points above. Although your customers will be happy, you have just purchased a load of technical debt. Like any loan, it will come due at some point and the longer you wait to deal with these shortcomings – the more expensive they will be to retire.

So as an entrepreneur with enough problems on your plate, you have a choice (remember – our scenario is that you’re going to outsource this project):

  • Dig in and hire a really competent engineering team that has real world experience in larger operations and understands where you are going. It is going to be expensive, time-consuming and at times – frustrating. You will have more expertise sitting around than you need in the early days, but it is an investment you need to make in lieu of the cost of redoing much of your early work when all your predictions come true. You don’t want to have to operate your business while changing the undercarriage as it speeds down the road. Once you have your engineering team and they understand your business model and where you are headed, they can manage your outsourced development team – but with both sides being new to you it is likely to be a fairly inefficient match in the beginning. Expect six to nine months to hire, train, and begin your project and another period of time integrating your outsourced team (which you also have to select) and your in-house engineering to the point where the combined team can be productive.
  • Find an outsourcing partner that can provide the engineering skills as a part of the team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. The application should be designed with the five points above in mind from the start. If the vendor operates as a partner with your organization, doing that part of the development and operation successfully is part of their value proposition to you. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. Finding the right vendor will not be as quick as it might be if you were only looking for an outsourced development team (there are many pretenders in the field), but in the end, you should be able to get your project running faster, with better efficiency, lower cost, and risk.

The choice is yours and (of course) there are other factors you may have to consider in your situation – but at a high level, if cost, time-to-market, and lowering distractions from your emerging business are concerning, an outsourced engineering and development team would seem to be a strong option.

2. Existing IT Team, No Internal Software Development Team & Little or No Current Experience with Custom Apps and Modern Infrastructure

At first, this would seem to be a simple match for an outsourced development team – and in some cases it may be. But, the lack of current experience with custom application development and modern infrastructure in this situation should be concerning. Companies in this position tend to be service-based, SMB/E organizations with established client bases, regional strength in their market and a strong, competitive need to grow. As we pointed out at the beginning, we are assuming there is a budget for this project and the company is committed to outsourcing but – they have an existing market and they can’t afford to burn their existing customers while they transition to a new or expanded level of services. Because of that limitation, even without considering the eventual operation and maintenance of the new application once it is released, an organization in this position can’t afford to overburden their existing staff with development of a mission-critical, custom application and the operational planning needed while they continue to serve and maintain their existing services. The staff must be involved in the changes but only to the extent that they need to be to be able to take a role as things move forward.

Again, we come down to some choices:

    Hire one or two technical leads/product and project managers who will take the position of planning the new application, its architecture, and operational requirements while managing the outsourced development team. They will need to be much more experienced than the existing IT team so there will be some initial friction and it will (again) take time, be costly and frustrating. It will take time to get them up to speed and integrated into the team before an outsourced development team can be selected and put to work. The reason to use only one or two resources, in this case, is to hold down costs, but doing so will only make each resource more critical and (probably) more expensive.
  • Hire outside consultants to develop the operational architecture, requirements and train your internal team. Since the internal team is unlikely to be large or have the skills necessary, there will still be a need to hire additional internal resources, but it can be delayed to some extent. The downside of this strategy is that when experienced staff is added eventually, they may or may not agree with the direction put in place by the consultants and there may be a period of realignment and unexpected technical debt. Also, the use of external consultants to manage all or part of the work done by the outsourced development team can create an “arms length” relationship with the development team that can make it difficult to have the level of collaboration and trust you need to avoid communication problems, especially with agile development.
  • Find an outsourcing partner that can provide the engineering talent as a part them team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. If you want to transition the outsourced team out at some point, you will still need to hire additional staff for operations and maintenance of your new applications, but you should be able to have them work in parallel with your outsourced team during the transition and lower the burden significantly.

Any of the three options could be successful but if you find the right outsourcing vendor, it would be a faster, less costly and less risky route to get your project going. But, of course, it depends on finding an outsourcing vendor with the option to include engineering skills in their team and to have a flexible approach to providing the team you need.

3. Siloed Operations, IT & Software Development Teams

This scenario lends itself to slightly larger and more technically-based operations than we discussed in the second scenario. This is the type of organization we expect to find in an established ISV with a strong client list in a specific vertical. Their operations are usually as they have been for a decade or more. Their IT staff is established and has a strong operational base. Their software development team is well-versed in their existing applications, the technologies they use and the customer base they work with. If they didn’t have to step out of that box to build this new application, we can easily assume they wouldn’t need to outsource and their engineering is just fine for what they are doing today.

What Do You Need? A Software Development Team? Or an Engineering Team?But that is the rub. We’re examining a scenario where they need to extend themselves into new technologies and possibly change their operations significantly. And because we’re assuming their teams are informal, separate silos – we’re also assuming they know about the higher efficiencies they could achieve if they began to shift to a DevOps methodology but – again, like our second scenario, they have existing customers and products/services in the field to maintain and support. Like most companies in this situation, their backlog of feature requests for their existing software is just what they can handle at the moment. Adding another layer of work would just mean something would have to give. An outsourced development team, in this case, makes sense and this organization is likely to have customer-facing product development well-in-hand. But, what they don’t have is a scalable organization to match the importance of the project and a broad understanding of new technologies and architectures they need to consider to streamline their organization.

So, in this case, an outsourcing vendor who can bring in engineering experience as a part of their team skill and experience, a flexible, scalable team makeup and willingness to work in a partner role to help their existing team rethink and realign their operations could be a real asset. It is risky to try to do both at once with the same team, but if both teams have regular work to do and can collaborate to adapt operations over time it can be an opportunity that would be nearly impossible any other way. Again, the critical step is to have the skilled resources available as an integrated part of the team who can lead the effort to plan architecture and operations before development gets underway and you find that serious adjustment is needed. There are risks in this scenario, certainly, but there is also an upside to making changes in parallel with everyone onboard the organizational development and change initiative.

4. Mature Enterprise with Integrated DevOps style IT and Software Development

Again, we’ve moved the situation up the scale a bit but we’re still committed to outsourcing and we’re still considering what type of a team we need. In this case, the internal team has an implementation of DevOps and even if it is not complete, it is moving forward with staff support and commitment. Like scenarios two and three, our existing team has a number of custom applications in production and knows what it is doing when it comes to operations and development. We can assume they are fully engaged and the time allotted to this project is short, or they would simply hire as needed and do the project internally.

Since this organization has a DevOps implementation, there is already an assumption that new development resources will have experience in both development and systems architecture for continuous development and maintenance. Bringing on a team that doesn’t have that type of cross-functional experience and mindset would be a serious problem. They simply wouldn’t be able to hold up their end. In this case, if the project is to be outsourced, the incoming team must be able to handle both engineering and agile software development if they are going to hold up their end and integrate with the larger team successfully.

5. Spin Out/Off Venture with Software-Based Service

You might think this scenario would be a lot like the first, but spin-out ventures tend to be better positioned and planned simply because they usually come from organizations with a strong market position and goals that are carefully evaluated before the venture is started. In most cases, staff members come from the “mother ship” with a background in product development and deep understanding of the market they are going into. But, because the loss of technical resources inside the home organization could seriously impact production there for a prolonged period, they rarely pull out more than a few senior IT resources. With that in mind, their team is usually fully aware of current technologies and methodologies, even when they may come from an organization that culturally has not be able to move to them as quickly as they might wish.

A spin-out gives this core team an opportunity to move in fresh directions with less organizational baggage and legacy overhead. So, in some ways, they may look like scenario two with little IT in the beginning – but the big difference is they have experience in the product development side of custom software and how supporting systems can be orchestrated. They are better positioned to evaluate partners and decide on the roles they want in-house versus outsourced. Since we said at the beginning that all scenarios would be based on a decision to outsource – the question is still, “Do we just need an outsourced software development team or do we also need an integrated engineering component?”

The decision comes down to how much of the burden the mother organization wants to continue to shoulder and how expensive the “charge-backs” would be if they did. Leaders of spin-outs usually have strong stock incentives to keep costs in line and move relatively quickly to prove their direction is worthy of the risk. If using existing services inside their home company would create complications, slow product development, and increase costs – they will think twice about that direction. Since we have specified that they have already decided to outsource this project, we can assume they are not looking to spend any time taking on problems that do not get their services and products into the market. But that said, we know the IT resources in the venture are limited and if they want to go to a modern continuous release methodology so they can incrementally improve and tune their applications, they will need to have flexible, integrated teams of engineers and developers from the beginning so that their applications are architecturally and operationally sound from the beginning.

Bottom Line

The bottom line here is that software development is shifting away from internally-focused product development,  siloed enterprise teams and monolithic applications to incremental release patterns, agile organizations, and customer-focused lean product development. Not everyone is there now. There are many different ways to implement change. But, all of these organizations have chosen to take on custom application development for a strategic initiative, the opportunity now is to do it better with an eye toward the future of their organization. This is just one small part of the change they seek, but it is an important one to consider. So, yes – an outsourced team that brings a range of engineering skills and experience along with their development background can be a big advantage for any of these situations, with a vendor who will operate as a partner in the organization.

Scio provides nearshore, outsourced software development and flexible teams with a range of software development and engineering skills based on our experience in many verticals and situations. Our teams can have flexible roles and their bias is toward agile methodologies broadly. If you have a project in mind, please contact us to discuss how our unique blend of skills and experience can benefit your organization. We would be happy to take the time to listen and provide insight into how we could partner for success.