Risks List

This is the risk list of all Mochimo projects related.

Aim and explanation

The aim of this risk list is to put on paper what might be considered as a risk for he project. It can be of any type: Technical, exchanges related, wallet related, blockchain, block explorer, transactions, cryptography, algorithms, discord server issues, marketing related, and so on. It can also involve several components, and yet he doesn't even need to know which part or person it would be realted to. If the risk grows too much we can categorize them.

The advantage of such a risk list is that anybody, from most experienced developers from team members to first comers, can provide a risk item related on some experience he had that was bad or he wonders how it would behave, and that he felt was really important or could potentially jeopardize the project, as he thinks. He might be wrong, but the risk for him is there. By expressing it in this risk list as a new risk item, it allows Mochimo experts to answer to that risk supposition, validating or invalidating it, provide solutions or mitigations for it, realizing tests to dismiss it or involve people to work on them to lower that risk. The newcomer can also define a risk rating, if the impact of such a realized issue would be very high or quite little. Usually a risk item will translate in new bugs tickets created in one or more projects, but it doesn't have to. Generally, this list is maintained by the project manager, because he must make sure that the project will be successful in the end, and he has the role to enforce making sure the risk is not real, or solve it with his team. However in an open source project it can be different, but a maintainer should have enough self responsability to be willing to take this role.

Risk lists allow having a more in-depth view of what is going on in the project, what are the current most important risks and if someone is taking care of them or not, trying to provide solutions. Generally it is especially used by directors, to know what are the biggest issues the project is facing. Also the project manager will be able to show them this risk list to demonsrtate that more ressources or money is needed to be able to reach the time and features goals.

For project managers, it can really help them concentrate on the most important tasks, and organize the project schedule to synchronize all components needed to be able to move to the next step, and assign ressources appropriately. It usually helps a lot to generate the timeline like with Microsoft project for example, and helps him adapt it when needed.

More specifically for projects, devs can see what other devs are facing as issues and try to figure out powerful solutions in just a few seconds thinking of it, which brings a huge distribution of ressources and optimizations that one dev wouldn't even see himself. It helps communication and reduces drastically the time to solve an issue or implement something, thanks to other specialists that are queried about each situations, if they know about. They can provide a technology name to do it for example. It puts all brains quickly on a situation and the best solution is found and validated by the whole core team, or else the impact rating can be increased, to show that something needs to be investigated on that point.

It is important that anyone interested in the project, especially core developers, try to be "risk-aware" and create a new risk item in this list as soon as they have a doubt about something and feels that things might become complicated or risky if this or that situation is not solved. Either in their own code or in the code of someone else. Usually in a meeting one dev will say to another "hey, did you thing about that? what happens if... Please have a look, or else write the risk item so we can take care of it when we can".

Definition of a risk item

It is a simple line in a table that contains several columns, usually in a spreadsheet to be able to compute points and categorize them easily. The only required field is the description of the risk. All others are optional and can be filled by the risk maintainer or anyone of the core members who knows what to do with this item at best. Other members can also provide corrections, suggestions about that risk and a solution or mitigation to it, directly in the table. Each risk item has two ratings: a likelyhood rating that the risk occurs and an impact rating (on the whole project), each in a scale between 0 and 10. There is a mitigation field where either a solution is provided by fixing a bug, or a mitigation is given to reduce the risk, to bring it to an acceptable level that is very unlikely to happen, which is usually a workaround or blocking a feature, etc...

Example: The project manager knows his team and he sees that the project will take probably longer as expected, because there is too much work in the end. He needs more people to work on a specific part. He will enter a risk that shows the importance of that risk like this: Description: The milestone set for this date will probably not be met due to unexpected work overhead, not enough ressources Likelyhood rating: 7/10 (it might very well happen) Impact rating: 10/10 (the impact will be big, the expectations will not be met at that date) Mitigation: hire more devs or delay the milestone.

The director will see this risk list with the project manager and as the director has promised this feature to be done quickly to his board of directors, he allows $1M more, and the risk is mitigated, the timeline should still be met unchanged due to this action.

Risk list

Item #	Description	Likelyhood rating / 10	Impact rating / 10	Mitigation	Next step	Assigned to
1	Block explorer not showing all movements on a tag since block 1 might rebuke exchanges or users	5	6	Correct the block explorer so it shows all transactions per tag and wots addresses	Implement mitigation suggestion	-
2	Not enough trading volume on coinsbit.io might kick MCM out of it, like stated on their terms of use	8	4	Check with exchange if it can really happen or if there is a specific exemption for MCM. If real, ask if chances are that some bot will come in automatically. Else figure out how to motivate bots to come or evaluate if possible to create one	Take contact with exchange	-
3	The tag address is very small, it could be hacked or recovered very easily	0	4	This cannot happen because the tags are only pointers to much bigger WOTS addresses, so there is no risk that they could be recovered or find out cryptographically.	None. There is nothing to do, it is safe	-
4	Coffee might be missing and not deliverable anymore due to current crisis and bottlenecks, so devs might be missing it and could fall asleep	3	0	Devs can go for jogging instead if it happens, and project won't suffer from it	None	-