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 takes away the risks. And this means so much more the salary cost advantage of say, a nearshore region, such as ours in Ukraine.
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 success is based on six key things:
But, 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 Software Lab and the digital entrepreneur or enterprise IT organisation.
I believe in embracing the Stanford d.school Design Thinking process. This is five steps for digital innovation: 'Empathize: Define: Ideate: Prototype; and, Test'. These steps are executed in an iterative loop for continuous 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 Dedicated Team members can truly understand what is really wanted, and what works, in co-creating say, a new Web app and more generally, undertaking a breakthrough digital innovation. This means that everyone has to be frank, open and flexible at all times during each of these Design Thinking iterative loops and steps. This must generate sufficient receptivity and rapport, which in turn, leads to trust.
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.
Software engineering accounts for the majority of spend for the entrepreneur or enterprise creating a new tech venture, 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 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.
The trade-offs between Code, Low-Code and No-Code also apply to packaged apps, such as Salesforce or SAP 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 similar Design Language and reusable components: Lightning 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 (Bluemix), 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?
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. There are many Low-Code Platforms available today, such as Simplicité or Black Pear Software or through using Design Languages and reusable components, such as SAP Fiori, Salesforce Lightning Design System or Microsoft Fluent Design System.
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) an early pioneer of No-Code.
#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 nearshore or offshore 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 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.
#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 UX designers and software developers must work closely together with onshore customers, 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 the five iterative steps of Design Thinking.
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 Dedicated Teams.
Scrumban is the combination of the 'Scrum' approach to Agile software development - underpinned by '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. In many ways the 'product' should be thought of a 'service', which introduces the concept of Servitization.
#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.
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 differentiator 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 #3.) enables clear communications and therefore, what comprises the 'Deliverables' in each Sprint - e.g. each period as 1-2 weeks of work.
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, nearshore Ukraine (to say, UK), but indistinguishable from your onshore employees.
These things for entrepreneurs, CIOs and CTOs are difficult to judge, until you put them to the test.
So, if you are a digital entrepreneur or enterprise CIO/CTO, let's explore how you combine these six key things as your advantage in software design and development outsourcing: Design-Led; Code-Optimised; 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!