The Implementation Readiness Framework starts from a problem you describe in your own words. It checks whether blockchain fits that problem and writes the answer for the person who decides. If the answer is yes, it helps you put the work out to tender.
Each box links to its stage further down the page. The dashed boxes are early exits, for a problem that is small or has no match.
You describe your organisation and what goes wrong, in your own words, typed or spoken. A few questions about you come first, so that the later ones fit your situation. Then you say what the problems are, and the framework finds the uses of blockchain that match. No use is suggested before you have described your problem. If the problem turns out to be small, this is where the framework says so. What you type stays in your browser.
The framework shows what matched your description, in order of how closely each use fits. You choose which one to look at first. The others stay on the list, and you can come back to them whenever you like, in the same session or from a saved file. If nothing matched, this is where you find out, and the brief says which kind of simpler tool to try.
For the use you chose, the framework asks whether blockchain is the right tool for that problem. It looks at who holds the record today, who has to trust it, whether its history may be rewritten and whether it crosses borders. Then it asks whether your organisation could start. The answer is one of four: yes; yes, with conditions; yes, once these change; or no, use something simpler. Two early exits stay open: a problem too small to change much, and a problem that no use case fits.
The brief is written for the person who decides. It states the decision first, then gives the reasons in your own answers and one next step. Both yeses that carry gaps list what has to be met. With conditions means the gaps close during the pilot. Once these change means your organisation has to change before a pilot could be carried, such as a named owner or a budget line. Often it is the connection: no pilot runs where the signal does not reach. A no names a simpler kind of tool. You can still go on to Requirements and the tender after a yes, once these change. The gaps go in as preconditions for the pilot, and the brief keeps its verdict.
Before any supplier sees anything, the framework sets what a solution has to meet. That covers data protection, the rules of the countries you named, how much security the use calls for and what stays with you. The tender builder carries these into the tender, and you mark each one as a must-have or a nice-to-have. This stage opens after a yes.
The tender asks for lots and names no products. A lot is one part of the solution, such as payments or custody, and a supplier can bid for one lot or several. You can post the tender on the board with your organisation’s name left out, or send it yourself. A conventional alternative, one without blockchain, is always invited, so a supplier can show that a simpler system would do.
Pilot and implementation happen with the supplier you choose. The tender asks for a small pilot first, with a written test of what it must show before you scale it. The guides for those stages exist and will come to this site later. When the work is done, tell us how it went. With your agreement, that account can go into the case studies.
Typed or spoken, one question at a time. It covers Discover to Decide.
A downloadable pack that runs the same interview where your data already is.
For a single use you already have in mind.
All three draw on the same questions and run the same scoring, so the answer does not depend on the way in. Check one idea skips Discover, which is why it can only say whether that one idea fits.
Guidance on blockchain often starts once the decision to use it has been taken. This framework comes before that decision, while changing your mind still costs nothing.
It starts from your problem. The technology comes last.
A no comes with the reason and a simpler kind of tool to try. It can save a pilot that would not have worked.
It costs nothing to use and sells nothing. What you type stays in your browser, and anything sent goes only where you choose to send it.
Download the framework as a pack of files you can read first, and run it inside your own AI assistant, where your data already is.
The tender names lots and invites a conventional alternative. The board where you can post it has no commercial side.
Ask these before you talk to a supplier or a consultant, and before you use this framework.
If agencies, partners, governments or donors each need a record they can check, a shared record has something to offer. If you work alone, it probably does not.
For payments and credentials, a record that cannot be changed unseen is a real need. For internal plans and programme reports, it is more than you need.
Every go-between in a payment and every manual match between partner databases costs money. If that is a large part of your budget, a shared record may reduce it.
A solution that needs steady internet where there is none, or smartphones where people have basic phones, will not work, however well it is built.
If your interest is still exploratory, it is early. Come back when you have a concrete problem and a willingness to test a solution.
If most of your answers are no, an ordinary system will probably do the job, and the framework will say so.
Trading tokens is one thing people do with the technology. The uses in this framework are about shared records and payments that follow agreed conditions, and each starts from a problem.
Ask why it failed. If the pilot began with the technology and went looking for a problem, this framework turns that round. It begins with the problem, and a no is a normal answer. If it failed for lack of connection or skills, the readiness questions look at both.
That is a question for your donors, and this framework cannot answer it for them. It gives you something to take to them: a brief with the reasons for the answer and the next step, and a tender that invites a conventional alternative. A donor can see that you checked the simpler options first.
The readiness questions measure it. If capacity is the gap, the answer is yes, once these change, and the brief names the gap and a first step. The tender lets you ask one provider to carry the whole build.
In a well-designed solution the people you serve never touch the blockchain. They use what they use today, such as a phone or a card, and the record sits behind it. The questions ask about the phones and connection the users have, and any gap becomes a requirement a supplier has to meet.
Energy use depends on the kind of network. Networks that prove work by heavy computation use a great deal. Networks run by a known group of parties use far less. The framework names no network, so you can ask each supplier to state the energy use of what it proposes.
In many countries they are, and more so in fragile or conflict-affected places. The framework takes the countries you name and puts the data-protection and other rules that apply into the tender as requirements. The tender also says to check with your own legal adviser.
Every answer ends in a brief of one or two pages. Here are five, one for each answer the framework can give, all for a fictional organisation.