So you and your fellow directors are moving towards sign-off on an exciting project that will use Artificial Intelligence to solve some exciting challenges. Given that it is relatively unlikely that your board will have deep technical skills in this new and fast moving technology - one of the aspects of a decision that you should consider carefully is the tricky question of whether to build or buy. (Tailor made v roll-your-own in the old jargon). Here we consider some good questions to ask and some context against which you might weigh the answers.
In a general sense, (like many decisions before the board) your internal proposer or sponsor for the project should provide a reasoned analysis of the pros and cons of each available choice. Also very useful here would be a simple analysis provided by a friendly (read neutral and trusted) expert who can point out the key considerations.
Beware the subtle differences
As mentioned already in this series, an AI project is not necessarily the same as your previous and more familiar technology projects. A good example of this through a build vs. buy lens is the impact of the speed at which the AI frontier is moving. If the main reason being offered to take on the build internally is the fact that there isn’t currently a solution available in the market, then either look into the most analogous products and ask the vendors or ask your team some questions about how soon one might be available. Or both - reassure yourself they have looked widely.
Consider Generative AI, which is hot right now, attracting investment and showing real leaps in performance of large models. As I write this, Open AI has released chatGPT and a sibling technology called InstructGPT. These are both examples of large model generative AI and can in many cases create a very useful piece of prose, article or other copy from a simple instruction or prompt. (No - I am still old school and am writing this myself). I point it out simply because what seemed more or less impossible - or more to the point not viable - only a couple of years ago is now coming quickly to general availability. So if the main plank of an argument presented to you and your fellow directors to build internally rests on the fact that there isn’t a viable option to buy now, at least ask for some evidence or analysis to show that the competitive advantage or moat the organisation intends to create won't be rendered obsolete around the time the project completes.
Trade offs to consider
Like many investment decisions, it cannot always be about hard data and numerical analysis. Sometimes it is just a matter of balancing various trade-offs. Here are a few you will encounter when considering whether to build your AI yourself or buy (rent) it. By examining each lightly, I hope this will inspire some questions you can ask while considering any proposal.
Fast v Slow. This is about the speed of delivery of your project. Is time to value critical? In most cases, designing and building your own models will take longer than if you are able to access and use an open source or licensed model for your purposes. Consider the important stages in a project and how long it might take to navigate them successfully. Using available tech probably won’t eliminate any of these steps, but some of them might happen much faster.
Control v Constraints. Deploying Artificial Intelligence for a specific outcome can seem to be a very unique exercise, especially at the sharper edge of technology progression. This can mean the design of a unique set of features. In an ideal world, it would be easy to create custom applications for your organisation and also easy to continue to tweak and add to them as you learn and as customers demand more. If the unique requirements are the main drivers for a build approach, then be sure to test this with some questions that qualify the assumptions. If there is an existing product available that is close to your requirements but lacks the features you seek, might the vendors be open to adding what you need or might they already have it on their road map for development? Footnote : If you are promised features on a road map in a sales process - get it in writing!
Resource Heavy v Light. This is a ‘how many engineers’ type of consideration. There will be a mix of important skills in a successful AI project - not least of which may not be engineers but people with strong domain knowledge and know-how inside your organisation. Of course a decision to build is likely to include external suppliers of talent and tools. Separately, the credentials and track records of external suppliers must be surfaced and checked. But the main question here is about whether your project will have access to the talent needed for a build process, or would a buy option be lighter in its requirements?
Maintenance - Core v Context. Here you are asking about the skills needed to maintain a solution once completed and for as long as it is in use. While one of the key propositions of Artificial Intelligence is that the machine can learn, there is still an important set of maintenance requirements during the life of an AI project. Models need tuning for improvements in performance. They have ongoing training needs and will need additional design and production if your organization seeks to turn it to new uses in future (the best kind of value extraction from the asset). As touched on elsewhere, there will be needs arising to integrate your models into existing technology and workflows. So your first question might be - what are the talent requirements for maintenance over the first few years of the project’s life and has that been factored in?
As a side note, we have found more than one instance where an AI project has been stood up within an organisation - but the main protagonist has moved on to a new organisation leaving behind no one who has a clue how to manage or change the solution - resulting in someone deciding to throw the switch on it.
Opex v Capex. When GPT3 was released by OpenAI. An article at the time provided an estimate of the cost to train the model - at around $12m USD. That is a lot of compute resources and a significant capital investment in the product. But companies able to make use of the resulting model can do so at a micro cost level by comparison as an expense. The usage fee is based on tokens, which can be complex at first. This kind of comparison may not be as simple for your project but is worth considering if your proposed project is an internal build and will incur significant capital expense.
The cost of waiting. If your organisation waits for the technology to be available off the shelf for the solution you seek, then what are the opportunity costs? Will a competitor or disruptor enjoy significant market advantage while you wait? Waiting for the latest model of smartphone might mean you get the most features when you do buy, but if you put it off too long you have a period where you cannot access the utility available in the model you choose to pass on.
This will be a more subjective judgement for your decision process - but the answers should lie within the information you have regarding the anticipated benefits (financial or otherwise) of the AI project you are considering and the time frame over which they will be available.
It is also worth mentioning that many ‘traditiona’l IT platforms are building AI into their products. For example; Service Now, Intercom and Hubspot, all have virtual assistant platforms baked in now. It is probably easier to use their one - which is tightly integrated to their system already, than to try to build a bespoke integration - unless you have very special requirements.
Non-binary
For an AI project, the build vs. buy part of the decision may not be a simple binary one. The general concept of platforms and pre-trained models being developed and provided by larger vendors with the financial and human capital to do so means that often the ‘build’ component of a project specific to your organisation can be a final layer, built on top of these existing models and providing the unique use you need.
This is often the compromise reached out of necessity, due to the high cost and long lead times to build models from scratch. Good design can mean an underlying platform can be swapped out for lower cost of better performing alternatives later. But a final layer of this type is still a build, so the questions and critical thinking needed during the decision process remains.
In addition to his position as Executive Chairman of ElementX, Richard McLean has over 20 years of experience helping New Zealand businesses tackle growth challenges and bring new products to market.
Richard's AI Governance series can be found here:
- An introduction: Does Artificial Intelligence deserve a place on the board agenda?
- Consideration of key stakeholders in the board decision making process
- Preparing for and avoiding roadblocks to adoption
- Keeping regulation and compliance concerns front of mind during AI project planning
Subscribe below to be the first to know when new posts are published, or follow Richard on LinkedIn.
Want to stay in the loop? Subscribe to get updates from us.
