Note: This blog is sorta marketing-related and less frequently updated than other blogs that I author.
If you are more of a techy-geek than a marketing wizard then cre8ive hut
will be much interesting for you.
Volkan.
Volkan.
2.05.2006
some risk analysis
Currently, I am elaborating on a high-risk (and hopefully) high return (secret) project.
I will not share the name (or URL) of the project until I see it's worth sharing.
However, I thought it would be a good thing to share my risk analysis decisions.
Define the risk factors
The first thing in a risk analysis (also known as requirement analysis) is to define the risk factors. Here are my risk factors at a glance:
I possibly will not have a project sponsor unless the project is successful. So I need to go on my own for a long time.
Results:
The project may not get the resources it needs. This may delay the project. Issues may not be resolved in a timely manner. And time is more is much more precious than you imagine (because in order to be first in a market you need to act fast.
And acting fast requires money.
You should have known that, financial requirements, time requirements, and quality requirements cannot be decreased together. You have to sacrifice from one to decrease the other two. For instance if you have less money to support a project you either lower the quality or extend the project development time.)
Action:
Either try harder to find a sponsor. Or spend some more money (since time is important and you can't sacrife from the quality then it's the only choice). Or do not start the project at all (and just watch others skim the market, helplessly). Note that if you need return, you have to take risk. As the Turkish proverb says: "bogulacaksan, buyuk denizde bogul." (if you're gonna be drown somewhere, be it a large deep ocean; instead of a small little lake -- Yes Turkish is a really compact language)
* * *
I need a high system availability requirement (in terms of server uptime, notification and support)
Results:
Downtime problems may result in productivity decreases and loss of revenue. Newer and advanced technology may be required. More procedures and processes are needed to maintain the system environment.
Action:
Allocate more time to design, analysis, testing and quality assurance activities. Think twice when designing the database schema. Focus extra time and energy on technology architecture (both software and hardware). Use industy best-practices whenever possible. And determine exactly which portions of the system has a high availability requirement. And finally, look for outside experts to validate overall technical design and architecture.
* * *
The technical requirements of the project are new and complex.
Results:
May be difficult to understand the requirements and the implications of design decisions.
You may need some integration between old and new technology. It may be difficult to test a complex technology. Hence, the more complex the technology, the greater the risk that the problems will occur.
Action:
Document any and every single bit of code. Have printouts of your ddl statements. Have a copy of your database schema diagram on your desk. Have detailed explanations of all your DB tables, and code modules.
Define the overall system architecture and have it approved by knowledgable people (remember anyone can make a mistake, included but not limited to you. The more people approve your architecture, the higher the possibility that you're on the right track)
Create sandboxes, pilot tests and prototypes before a full launch.
Try to substitute more proven and familiar technology in the architecture.
* * *
The database schema is relatively simpler (9 tables, 2 of which are lookup tables), however the data storage and data mining requirements may not be that simple.
Results:
Solution may have a more limited value if all required data is not present (due to inefficient mining). Solution will take longer to analyze and test (if the data grows too much)
Action:
The large amount of data is not a problem if you have a reliable database. However, make sure that you really understand the relational integrity of your database design. It is likely that some elements will be discovered missing until the system constuction. Make your design flexible to be able to handle that situation. And lastly as an expert's opinion on the issue.
* * *
The product (or release) is new to the market (the current buzzword for it is: it is a beta product)
Results:
Learning curve may result in lower initial collaboration and productivity. It may be difficult testing the new technology. Technology may not be installed or configured correctly which will lead project delays. A new technology may require substantial conversion efforts. Finally, system performance may be poor while expertise is gained in configuring and optimizing the technology.
Action:
Provide as much training, help documents, tutorials on the technology as possible. Train everyone who needs to use this technology. Ensure that solid analysis is completed regarding the new technology functions, features and capabilities. Create procedures and standards on how the new technology should be utilized. Create and test a small prototype before a full launch (that's the second time I'm saying this :) )
* * *
That's it.
Hope this analysis was as useful to you as it was to me.
I'll have more things to write here when I become a millonaire ;)
Cheers!
I will not share the name (or URL) of the project until I see it's worth sharing.
However, I thought it would be a good thing to share my risk analysis decisions.
Define the risk factors
The first thing in a risk analysis (also known as requirement analysis) is to define the risk factors. Here are my risk factors at a glance:
- I possibly will not have a project sponsor unless the project is successful. So I need to go on my own for a long time.
- I need a high system availability requirement (in terms of server uptime, notification and support)
- The technical requirements of the project are new and complex.
- The database schema is relatively simpler (9 tables, 2 of which are lookup tables), however the data storage and data mining requirements may not be that simple.
- The product (or release) is new to the market (the current buzzword for it is: it is a beta product)
I possibly will not have a project sponsor unless the project is successful. So I need to go on my own for a long time.
Results:
The project may not get the resources it needs. This may delay the project. Issues may not be resolved in a timely manner. And time is more is much more precious than you imagine (because in order to be first in a market you need to act fast.
And acting fast requires money.
You should have known that, financial requirements, time requirements, and quality requirements cannot be decreased together. You have to sacrifice from one to decrease the other two. For instance if you have less money to support a project you either lower the quality or extend the project development time.)
Action:
Either try harder to find a sponsor. Or spend some more money (since time is important and you can't sacrife from the quality then it's the only choice). Or do not start the project at all (and just watch others skim the market, helplessly). Note that if you need return, you have to take risk. As the Turkish proverb says: "bogulacaksan, buyuk denizde bogul." (if you're gonna be drown somewhere, be it a large deep ocean; instead of a small little lake -- Yes Turkish is a really compact language)
* * *
I need a high system availability requirement (in terms of server uptime, notification and support)
Results:
Downtime problems may result in productivity decreases and loss of revenue. Newer and advanced technology may be required. More procedures and processes are needed to maintain the system environment.
Action:
Allocate more time to design, analysis, testing and quality assurance activities. Think twice when designing the database schema. Focus extra time and energy on technology architecture (both software and hardware). Use industy best-practices whenever possible. And determine exactly which portions of the system has a high availability requirement. And finally, look for outside experts to validate overall technical design and architecture.
* * *
The technical requirements of the project are new and complex.
Results:
May be difficult to understand the requirements and the implications of design decisions.
You may need some integration between old and new technology. It may be difficult to test a complex technology. Hence, the more complex the technology, the greater the risk that the problems will occur.
Action:
Document any and every single bit of code. Have printouts of your ddl statements. Have a copy of your database schema diagram on your desk. Have detailed explanations of all your DB tables, and code modules.
Define the overall system architecture and have it approved by knowledgable people (remember anyone can make a mistake, included but not limited to you. The more people approve your architecture, the higher the possibility that you're on the right track)
Create sandboxes, pilot tests and prototypes before a full launch.
Try to substitute more proven and familiar technology in the architecture.
* * *
The database schema is relatively simpler (9 tables, 2 of which are lookup tables), however the data storage and data mining requirements may not be that simple.
Results:
Solution may have a more limited value if all required data is not present (due to inefficient mining). Solution will take longer to analyze and test (if the data grows too much)
Action:
The large amount of data is not a problem if you have a reliable database. However, make sure that you really understand the relational integrity of your database design. It is likely that some elements will be discovered missing until the system constuction. Make your design flexible to be able to handle that situation. And lastly as an expert's opinion on the issue.
* * *
The product (or release) is new to the market (the current buzzword for it is: it is a beta product)
Results:
Learning curve may result in lower initial collaboration and productivity. It may be difficult testing the new technology. Technology may not be installed or configured correctly which will lead project delays. A new technology may require substantial conversion efforts. Finally, system performance may be poor while expertise is gained in configuring and optimizing the technology.
Action:
Provide as much training, help documents, tutorials on the technology as possible. Train everyone who needs to use this technology. Ensure that solid analysis is completed regarding the new technology functions, features and capabilities. Create procedures and standards on how the new technology should be utilized. Create and test a small prototype before a full launch (that's the second time I'm saying this :) )
* * *
That's it.
Hope this analysis was as useful to you as it was to me.
I'll have more things to write here when I become a millonaire ;)
Cheers!
