INNOVATION

Reworking TRL and IRL for App Development: Software Readiness Level

NASAs Technology Readiness Level (TRL) and Steve Blank’s Investment Readiness Level (IRL) are great, usu­ally…

However they are in­ap­pro­pri­ate for soft­ware-based prod­ucts and ser­vices. TRL is too spe­cific, it is un­apolo­get­i­cally hard­ware-fo­cused. Meanwhile, IRL is too gen­eral, as it tries to be ap­plic­a­ble to every­thing.

But some­thing is bet­ter than noth­ing right?

Developing a new prod­uct or ser­vice is hard enough, even Google gets it wrong, which is why you want your re­sources to be a lit­tle more than bet­ter than noth­ing.

Trying to ap­ply TRL and/​or IRL to your ap­p’s de­vel­op­ment time­line prob­a­bly is bet­ter than noth­ing; how­ever, this does put you at risk pri­ori­tis­ing the wrong mile­stones and tasks or miss­ing unique steps that ap­ply only to app de­vel­op­ment.

For ex­am­ple, TRL sug­gests that you should start by re­search­ing the ba­sic prin­ci­pals of your idea in peer-re­viewed pa­pers. Yes, knowl­edge is power, but speed is of the essence. Reading back is­sues of Accounting Programs Quarterly will only help you so much. (Meanwhile, Xero’s YoY growth rate has been 100% or more since 2008!)

The prob­lem is, as great as TRL and IRL usu­ally are, they are in­ap­pro­pri­ate for soft­ware-based prod­ucts and ser­vices, that is why we have re­worked these ex­ist­ing mod­els into a new model that is more aligned with the re­al­i­ties of app de­vel­op­ment.

The Software Readiness Level model

1. Business model can­vasYou’ve a rough out­line of a busi­ness model, but it’s mostly as­sump­tions, which will be val­i­dated in sub­se­quent steps.
2. Problem/solution val­i­da­tionYou’ve val­i­dated that there’s a prob­lem and that your busi­ness model aligns with pos­si­ble so­lu­tions to that prob­lem.
3. Market size/​com­pet­i­tive analy­sisYou’ve com­pleted mar­ket and com­peti­tor re­search, and the re­sults align with your can­vas and prob­lem/​so­lu­tion val­i­da­tion.
4. FundedYou’ve se­cured fund­ing to de­velop your idea (NOTE: ac­cord­ing to Kinvey the av­er­age app takes 7 months and costs $270,000 to de­velop)!
5. ScopedYou and your de­vel­oper have com­pletely scoped your idea’s EXACT tech­ni­cal re­quire­ments and have a roadmap of when each re­quire­ment will be de­vel­oped and what this will cost. This roadmap should or­gan­ise your re­quire­ments into (bite-sized) sprints.
6. DevelopingThere is reg­u­lar com­mu­ni­ca­tion be­tween you and your de­vel­oper, who is de­vel­op­ing your idea in ag­ile sprint cy­cles. Partner meet­ings in­clude a demon­stra­tion of de­sign pro­to­types and tech­ni­cal progress.
7. TestingYour de­vel­oper has re­leased the lat­est ver­sion of your soft­ware to a beta en­vi­ron­ment, where it can be tested by you and your end-users. (This step should be re­peated at the end of each sprint cy­cle.)
8. Minimum Viable ProductYour de­vel­oper has de­vel­oped an app in-line with the scope (SRL 5) in a se­ries of it­er­a­tive cy­cles (SRL 6). This ap­p’s test­ing (SRL 7) has val­i­dated the as­sump­tions made on your busi­ness model can­vas. You’re ready to be­gin com­mer­cial­is­ing your soft­ware.
9. SalesYou have com­mer­cialised your soft­ware and have sales.

Image

SRL 1 - Business model can­vas

Creating a busi­ness model is the open­ing and most im­por­tant step to­wards com­mer­cial­is­ing your idea.

There are some great tem­plates that stream­line this task. Alexander Ostewalder’s busi­ness model can­vas (BMC) is one.

Image

At min­i­mum, you should com­plete each panel by out­lin­ing your un­der­ly­ing as­sump­tions and how each of these will be tested. For ex­am­ple, if you write less time cod­ing and more time cre­at­ing” un­der Value Propositions, as we did when com­plet­ing Codebot’s BMC, one as­sump­tion is that Codebots does equal less time cod­ing, which it does. How do I know? We tested it!

Image

Your busi­ness model needs to be testable as­sump­tions or val­i­dated state­ments.

SRL 2 - Problem/solution val­i­da­tion

Next you must val­i­date that there is in­deed a prob­lem to be solved and that your busi­ness model aligns with pos­si­ble so­lu­tions to that prob­lem. Reaching this level re­quires a ba­sic mar­ket overview.

To be SRL 2 you should have val­i­dated at least one mar­ket-so­lu­tion and in­val­i­dated an­other through end-user in­ter­views. It is rec­om­mended that you con­duct be­tween 50 and 100 in­ter­views.

Engaging your end users early is the best way to avoid the quag­mire that is re­de­vel­op­ment.

SRL 3 - Market size/​com­pet­i­tive analy­sis

At SRL 3, you must have com­pleted, at a min­i­mum, a de­tailed map of the to­tal ad­dress­able mar­ket di­vided into sub­sec­tions, an es­ti­mated re­turn based on to­tal mar­ket value and ex­pected mar­ket share for each of these sub­sec­tions and a petal di­a­gram of com­peti­tors.

You should then in­te­grate this map and di­a­gram with your prob­lem/​so­lu­tion learn­ings.

SRL 4 - Funded

Although you will not know the true cost of your app un­til your app de­vel­oper has scoped your idea, it is im­por­tant that you make steps to se­cure ad­e­quate fund­ing prior to part­ner­ing with a de­vel­oper.

The Global State of Enterprise Mobility 2016 re­port es­ti­mates that most apps cost over $100,000 and more than 25% cost be­tween $250,000 and $500,000.

Click here to see how to avoid slow and ex­pen­sive app de­vel­op­ment

SRL 5 - Scoped

At this stage, your idea’s EXACT tech­ni­cal re­quire­ments should be recorded along­side a roadmap of when each of these re­quire­ments will be de­vel­oped and what this will cost. This roadmap should or­gan­ise your re­quire­ments into (bite-sized) sprints with the in­ten­tion of de­liv­er­ing a Minimum Viable Product (MVP) as soon as pos­si­ble.

Click here to see how WorkingMouse man­ages scope creep with the vari­a­tion met­ric

Your back­log should be a high-level vi­sion of the pieces that make up your app (Epics, User Groups and User Stories).

Epics are the big pic­ture ideas that make-up your idea. For ex­am­ple: Web Portal.

User Groups are types of peo­ple us­ing your prod­uct. For ex­am­ple: Admins and Customers.

User Stories are how a User Group in­ter­acts with an Epic. For ex­am­ple: Customers can log into the Web Portal on Desktop or Mobile and do X, Y and Z so that this re­sult is achieved.

SRL 6 - Developing

At this point, you and your de­vel­oper have part­nered to de­velop a spe­cific back­log of re­quire­ments.

The ques­tion is: do you adopt an ag­ile method­ol­ogy or de­velop your back­log us­ing a tra­di­tional, wa­ter­fall ap­proach? Both method­olo­gies have their ad­van­tages and dis­ad­van­tages and while we’ve been ad­vo­cates of ag­ile in the past, it’s not al­ways clear cut which op­tion is bet­ter.

Click here to see a break­down of Agile vs. Waterfall

SRL 7 - Testing

Once you have de­vel­oped your app, it’s im­per­a­tive that you test it. Otherwise, you might wake up to dis­cover that your ERP pay­roll sys­tem has over­paid em­ploy­ees $53 mil­lion.

You can out­source your test­ing, do it your­self, or au­to­mate it us­ing Codebots.

SRL 8 - Minimum Viable Product

An MVP is a ver­sion of your app that meets your end user’s min­i­mum needs. More specif­i­cally, some parts of your app are must haves and some are nice to haves. It is com­mon prac­tice to de­velop the must haves ini­tially and the nice to haves later. This way, you can be­gin test­ing your ap­p’s UX and rai­son d’e­tre as soon as pos­si­ble.

To be at this stage of readi­ness, your app must be ready to be used by your end users, who could be app store cus­tomers, em­ploy­ees or a clien­t’s em­ploy­ees.

SRL 9 - Sales

Your soft­ware is ready and you have started mak­ing sales.

This is not the fin­ish line, you should con­tinue to it­er­ate on your idea and its tech­ni­cal ex­pres­sion.

Summary

We have re­worked NASAs hard­ware-fo­cused Technology Readiness Level (TRL) and Steve Blank’s Investment Readiness Level (IRL) into a NEW and EXCLUSIVE soft­ware-fo­cused model: Software Readiness Level (SRL).

Image

ABOUT THE AUTHOR

David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book an con­sul­ta­tion