I cannot understand why so many CIOS and CTOs have a fear of outsourcing software design and development, and think that building Software Labs in the insanely expensive cities, such as London, New York or San Francisco, is cool. It's not cool, it is unsustainably expensive.
There is a better way - so let's talk about the 'O' word: 'Outsourcing' - and how following a few key principles can turn this into a positive move. And this means so much more than simply the salary cost advantage of say, a nearshore or offshore region, such as Ukraine or India.
In creating new Web, mobile or Software-as-a-Service (SaaS) apps, I think that what matters most in embracing software design and development outsourcing is based on six key things:
Being Design-Led means applying Design Thinking. What I have learned about digital innovation is that Design Thinking is a great foundation for enabling a true partnership between a Software Lab and the digital entrepreneur or enterprise IT organisation. Design Thinking simply means solving problems in a people-oriented way. Often, the software design and development process lacks proper alignment between the key stakeholders: users, designers and developers.
So, to enable a coherent connection between all of the key stakeholders in the software design and development process, I believe in embracing the Stanford d.school Design Thinking method. This is five steps for digital innovation: 'Empathize: Define: Ideate: Prototype; and, Test'. These steps are executed in an iterative loop for continuous, yet rapid improvements and enhancements.
What matters most here is communications and trust. If we really Empathize with the digital entrepreneur or CIO/CTO (and all other key stakeholders), then the Software Lab team can truly understand what is really wanted, and what works, in co-creating say, a new Web, mobile or SaaS app and more generally, achieving a breakthrough, meaningful digital innovation outcome.
Throughout this approach this means that everyone has to be frank, open and flexible at all times during each of these Design Thinking iterative loops and steps. An 'Empathy Mapping' process must generate sufficient receptivity and rapport, which in turn, leads to trust - and finally, truth. Here the nearshore or offshore Software Lab must be properly connected with all stakeholders on the buyside - not working at arm's length through (wrongly) interpreting Statement of Work (SoW) or similarly written, dry Requirements documents.
Being Design-Led is very different to outsourcing software design and development to suppliers, via arm's length procurements, where competing services organisations respond to written Request For Proposal (RFP) documents, and usually where, a lack of true understanding of what's needed becomes a heavily caveated offer, invariably based on billable people hours, no challenge of assumptions made on the buyside, and rarely, any offer of shared risk/reward by the supplyside, since too little is known at the point of submitting a cold, abstract written Proposal.
The Software Lab must be a true partner of the buyside the digital entrepreneur or enterprise IT organisation. This becomes clear in many other of these six key things set-out here in this blog post.
#2. No-Code First
Software engineering accounts for the majority of spend for the entrepreneur or enterprise creating a new tech venture, Minimum Viable Product (MVP) or service. In a typical tech venture, the ratio between researcher, designer and developer is 1:5:100. However, in many tech ventures or IT organisations, this ratio is greatly influenced by how much a given app is coded ground-up, versus making use of prebuilt business logic in the cloud. This is the trade-offs between 'Code, Low-Code and No-Code'.
In my experience, too many tech ventures and enterprises underestimate what it takes to build and manage highly-scalable - and truly secure - infrastructure and services around a new app. This brings into play the key principle of being 'Code-Optimised'. This is a continuous 'make versus buy' decisioning process. Leveraging a No-Code technology can often result in up to 10x cost and time savings for a new digital venture, product or service.
The trade-offs between Code, Low-Code and No-Code also apply to packaged apps, such as Salesforce or SAP or ServiceNow SaaS solutions. This includes applying Low-Code Platforms as prebuilt business logic, such as SAP Fiori: a 'Design Language' and set of reusable components for maximising user experience with Web, mobile and SaaS apps. Similarly, with Salesforce Lightning Platform, as both No-Code and Low-Code Platform, this can also embrace a Design Language and reusable components: Lightning Design System or Eva Design System.
I assume that the arguments about on-premise versus on-demand (public cloud) computing have mostly been resolved, and bar a few exceptions, the majority of new tech ventures or services will live in a public cloud platform - e.g. Amazon Web Services (AWS), Google Cloud Platform, IBM Cloud, Microsoft Azure, or, Salesforce Heroku. However, if 'hybrid cloud' architectures are selected, to blend on-premise data centres with public or even private clouds, the key principles established here about Code, Low-Code and No-Code still apply.
So, now, the key question with new Web, mobile or SaaS apps is not about infrastructure, but about the business logic and presentation layers. What is the optimum balance of three states: Code; and/or Low-Code; and/or, No-Code? It should always start with No-Code First.
Let's define these three categories of Code, Low-Code, and No-Code.
Low-Code is the term applied to platforms that offer software developers and tech-savvy IT analysts the opportunity to create new mobile and Web apps through an optimal mix of visual development and use of prebuilt models ( or 'objects'), limiting Code to elements that cannot be created in this way.
No-Code is the term applied to platforms that enable business users and consumers to create and publish mobile and Web apps, without recourse to any form of syntax-level programming of Code. For very simple forms-based apps and workflows, the Salesforce Lightning Platform was (and still is) the leader in truly No-Code Platforms.
#3. Cost Advantage
Of course, I would always argue that outsourcing should always be a question of value over price. But in reality, moving software design and development to a nearshore or offshore Software Lab must include a clear Cost Advantage. Although I do not believe that hourly or monthly rate card on Time & Materials is anything other than a win-lose in favour of the supplyside (see #6. below), there should always be a tangible ROI Model to justify a Future State for such outsourcing.
When building the ROI Model for a new digital innovation, it is also key to understand the time-to-value advantage that a Low-Code or No-Code Platform could bring, and more widely, the calculations that yield a measurable Cost of Delay or Cost of Doing Nothing.
What really matters in software design and development outsourcing is transformation. This means that the supplyside should show how the six key things set-out in this blog post add-up to a value creation outcome - not simply a wage arbitrage difference for the software designers and developers engaged nearshore or offshore.
#4. Accountable Method
In my work with entrepreneurs and CIOs/CTOs, I know that the only constant in an enterprise IT operation, new tech venture or digital agency is change. Nearshore or offshore UX designers and software developers must work closely together with onshore customers and users, to ensure that they maintain an optimum state between best outcomes for both user experience and secure, quality software engineering. In building new Web, mobile or SaaS apps, the outsourcing firm should adopt - in the jargon - 'Scrumban' as its development method - and this should be underpinned by iterative steps of Design Thinking. This means creating an Accountable Method.
One of the key strengths to create is a true balance of in-depth User Experience (UX) design and software development skills. Design Thinking and UX design are core competencies and CTOs and CIOs should seek-out these differentiators in any talent pool for outsourced Software Lab Dedicated Teams. Underpinning this further is the use of a rigorous Design System and use of reusable business logic and components wherever possible, as noted above.
Scrumban is the combination of the 'Scrum' approach to Agile software development - combined with 'Kanban' Boards, as left-to-right progression through all tasks attributed to the creation and enhancement of a new Web, mobile or SaaS app. See infographic above. This means generating clarity for Deliverables and Acceptance in each time-boxed iteration throughout an Engagement (see #6. Deliverables, Not Hours below). Each of these iterations are typically of 1-2 weeks duration, and, for those readers not familiar with the jargon, they are commonly known as 'Sprints'.
What always matters here is prioritisation: and in the context of knowing that, for the CIO/CTO or digital entrepreneur, change is the only constant. On the Kanban Board we simply have: To Do; Doing; and, Done. In the real world of creating and continuously enhancing a 'Minimum Viable Product (MVP)', this also means changing priorities along the way.
#5. Smart DevOps
When an enterprise IT organisation, tech venture or digital agency wants to create and publish a new Web, mobile or SaaS app, I understand that this can be a very challenging process. There are many things to consider here and so, let's now consider another topic, complete with its own jargon confronting the digital entrepreneur: 'DevOps'.
As tech professionals reading this blog post know, DevOps is short for 'Development Operations': meaning the combination of mindset, method, competencies and tools applied to 'operationalise' services related to Web, mobile and SaaS apps. Done right, this means delivering the services at high velocity to shorten time-to-market; optimising cloud platform performance, whilst minimising costs; and, ensuring that user on-boarding and related app reviews are positive experiences.
Smart DevOps includes 'Continuous Integration': where developers ('Citizen Developers' too, with 'No-Code Platforms') regularly submit their code (or configuration) changes into a central repository, followed by automated building and testing at each iteration. Underpinning DevOps and Continuous Integration must be security: applying iterative and highly-structured cyber security practices at every stage (Sprint) of the software design and development lifecycle.
One of the challenges with public cloud platforms is the pricing models that digital entrepreneurs have to work with. Leading players offering 'Infrastructure-as-a-Service (IaaS)' or higher-level Platform-as-a-Service (PaaS) public cloud platforms offer 'elastic' pricing models, calculated as usage of the services online. This is how Amazon Web Services (AWS), Google Cloud Platform, IBM Cloud (Bluemix), Microsoft Azure, and Salesforce Heroku works.
For new mobile, Web or SaaS apps, this 'elastic pricing' of underlying cloud IaaS or PaaS technologies presents a significant challenge in the forecasting and validating of such usage, and therefore, understanding what the real costs for this underlying technology is going to be. This has to be calculated well-ahead of finalising a 'Minimum Viable Product (MVP)' and ongoing releases.
Smart DevOps brings together many things: the ability to define and create a Minimum Viable Product (MVP) that achieves an optimal path to timely go-live releases; an app built for scale, yet minimises costs of underlying cloud IaaS or PaaS; and, integrating customer success through structured on-boarding and support for users.
#6. Deliverables, Not Hours
The sixth key point here is: Deliverables, Not Hours. Of course, business productivity and viability relates to time, but this also means ensuring that an Accountable Method (Scrumban, as described above in #4.) enables clear communications and therefore, what comprises the 'Deliverables' in each Sprint - e.g. each period as 1-2 weeks of work, defined in a Statement of Work (SoW).
Although we know that the only constant for a digital entrepreneur is change, you want to introduce certainty wherever you can. So, if you can clearly communicate the Deliverables and 'Acceptance' criteria for each Sprint, since you can quantify the human effort here, you can also provide a 'Fixed-Price, Fixed-Time' - per Sprint. Hence, you can pay on Deliverables, Not Hours.
Over four decades, I have worked with many tech startups, digital agencies, IT services firms and enterprise IT organisations. What I have found works best is a combination of the right mindset and what I also believe is the best method for your Dedicated Teams - located in say, Ukraine or India, but indistinguishable from your onshore employees.
These things for entrepreneurs, CIOs and CTOs are difficult to judge, until you put them to the test.
If you are a digital entrepreneur or enterprise CIO/CTO, let's explore how to apply these six key things as your advantage in software design and development outsourcing: Design-Led; No-Code First; Cost Advantage: Accountable Method; Smart DevOps; and, Deliverables, Not Hours.
We just sent you an email. Please click the link in the email to confirm your subscription!