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.17.2006
An open letter to PBS
This is an open letter to PBS US not providing a national platform for Armenian Genocide deniers.
Dear Ms. Atlas;
As a citizen of the Modern Republic of Turkey, I appeal to you to reject the wrong-headed petition being prepared by Armenian Americans who wish to stifle all research, debate and expression that takes any position other than that the Armenian tragedy of the late Ottoman Empire constituted genocide.
The petition, available at http://www.petitiononline.com/pbspanel/petition.html, seeks to prevent the airing of a discussion produced for PBS by Oregon Public Broadcasting in which diverse views on the Armenian issue were presented.
I have noted that some people are participating in the petition just to comment that the petition is against free speech.
By no means does the Turkish seek to deny Armenians their voice to tell their story as they perceive it. Yet many Armenian-Americans work tirelessly to ensure that their view of history is the only view that shall ever be known.
If rewarded, these efforts would harm the fundamental rights of many Americans, not just Turkish-Americans, to learn an historic controversy from a plurality of viewpoints and to make up their own minds. Moreover, PBS' standards of balance and objectivity would be crushed by accepting the petition in question.
In addition to urging you to reject the petition, I therefore congratulate PBS for supporting the OPB program and urge you further to consider programming that presents views other than the
Armenian viewpoint, which, to date, has exclusively been represented in PBS programming.
Thank you for your consideration.
Kind Regards,
Volkan Ozcelik,
Just a Turkish Citizen
defending the right of mutually sharing ideas.
Dear Ms. Atlas;
As a citizen of the Modern Republic of Turkey, I appeal to you to reject the wrong-headed petition being prepared by Armenian Americans who wish to stifle all research, debate and expression that takes any position other than that the Armenian tragedy of the late Ottoman Empire constituted genocide.
The petition, available at http://www.petitiononline.com/pbspanel/petition.html, seeks to prevent the airing of a discussion produced for PBS by Oregon Public Broadcasting in which diverse views on the Armenian issue were presented.
I have noted that some people are participating in the petition just to comment that the petition is against free speech.
By no means does the Turkish seek to deny Armenians their voice to tell their story as they perceive it. Yet many Armenian-Americans work tirelessly to ensure that their view of history is the only view that shall ever be known.
If rewarded, these efforts would harm the fundamental rights of many Americans, not just Turkish-Americans, to learn an historic controversy from a plurality of viewpoints and to make up their own minds. Moreover, PBS' standards of balance and objectivity would be crushed by accepting the petition in question.
In addition to urging you to reject the petition, I therefore congratulate PBS for supporting the OPB program and urge you further to consider programming that presents views other than the
Armenian viewpoint, which, to date, has exclusively been represented in PBS programming.
Thank you for your consideration.
Kind Regards,
Volkan Ozcelik,
Just a Turkish Citizen
defending the right of mutually sharing ideas.
2.12.2006
baby all I need is time!
As an dumb-headed engineer, still not leaving his engineering habits; I think I have an optimization problem somewhere:
Yes, obviously there is an optimization problem somewhere.
As I observe from my web stats I have a crowd (okay less than a crowd) of readers who mostly visit my blogs through google queries.
Since I don't blog regularly I am doubtful that I have regular passionate readers.
Some people find my entries worth reading anyway.
So my words are to you, my anonymous reader who is not likely to visit my blog again until you google and find something of your interest at some time later on.
I know what to do to gain your loyalty:
It's that simple. It not magic. Nor it is about luck.
However I cannot :(
I don't know whether it's just me running out of time.
Anyways, for anyone who are interested:
I will be participating less frequently on my blogs until things settle down a bit.
Later, when I have time to breathe, I will go back to my collaborative days.
As I said, I rlly rlly need some time :)
- I have several blogs which I spare for different topics.
- My todo list is expanding.
- My incoming mails far exceed the number of e-mails I read.
- I haven't looked at my rss feeds for weeks.
- I haven't called my friends for months!
- I have three or four articles to write.
- I have several blog entries, photos etc to share.
- sardalya's add on's todo's and optimization.
- I have sevaral lists and forums (both native and global) to participate.
- I have to follow the recent technical buzzes,
- and the recent marketing buzzes.
- My MBA graduate project has weeks to its deadline.
Yes, obviously there is an optimization problem somewhere.
As I observe from my web stats I have a crowd (okay less than a crowd) of readers who mostly visit my blogs through google queries.
Since I don't blog regularly I am doubtful that I have regular passionate readers.
Some people find my entries worth reading anyway.
So my words are to you, my anonymous reader who is not likely to visit my blog again until you google and find something of your interest at some time later on.
I know what to do to gain your loyalty:
- Write quality and useful stuff,
- Write them daily,
- focusing on a particular subject / area / field of expertise.
It's that simple. It not magic. Nor it is about luck.
However I cannot :(
I don't know whether it's just me running out of time.
Anyways, for anyone who are interested:
I will be participating less frequently on my blogs until things settle down a bit.
Later, when I have time to breathe, I will go back to my collaborative days.
As I said, I rlly rlly need some time :)
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!
