Hello,
when you (or your company) comes to the point to choose a technology for a new product to develop: What are your basic steps/approaches to evaluate it's use?
To make it more clearer:
Regards,
Stefan
I think this question is similar enough to my own question here: http://stackoverflow.com/questions/666090/what-is-your-companys-stance-regarding-technological-innovation
Fit: Does it fit our business model. More specifically, will the technology chosen improve the efficiency at which the product is developed.
Cost: Is the technology worth the price? Will the cost of the technology cost less than the potential cost of paying developers to develop the product without it.
Skill: Are there developers already proficient in the new technology? Will there need to be training? Can it be easily picked up? A new technology that everyone is familiar with is better than one in which everyone does not feel comfortable using.
It's generally best to actually have someone research said technology and report back on its advantages and disadvantages. This generally takes a long time (especially in bigger companies where overhead is HUGE). Then, the particular team working on the product gets their say on whether or not they can use the new technology without much difficulty.
You have to make sure that the technology you choose will support what you want to achieve (functionality wise) and that the adoption curve is not too steep and that you are likely to read the break-even point (that is where the business benefits, often in terms of hard cash, outweigh the investments - in licenses, hardware, skills).
Another thing to do is to prove you technology quickly (executable architecture is one example) - do a quick and dirty solution that actually DOES work, then do another one that addresses the critical parts.
Where I work there seems to be a few steps to the process, assuming we are talking about technological products and not processes and this can take years to complete in some cases:
1) Statement of the problem. What is wrong with the current system that someone wants to replace? What is the point of bringing in something new, in other words? For example, a CRM system that wasn't built to handle the current volume of customer interaction we have currently or a CMS system that is no longer supported and doesn't have some desired functionality for critical business needs. Sometimes this comes from outside IT and sometimes from within.
2) Request for Information. Who can do this kind of work and what are some of the key details to get when asks for a quote or estimate. This is where the leg work of finding out what all is in the system and what features or options are needed or wanted as well as what is the cost to get those features in terms of time or money. This is where IT people have a role to play in making sure the right kinds of questions are asked and a list of vendors can be drafted. Basically this boils down to who has the good products and who would help with the systems integration process that may take a long time and require a lot of resources.
3) Request for Pricing. Get a list of vendors to provide quotes on what it'll cost, both in money and time, and what will be done. While this may seem like something small, it can be quite a task if there are many pages in the quotes given. This takes time and may have a few e-mails back and forth to clear up any questions they have about what is wanted. A spreadsheet matrix is usually made to compare the various quotes and determine which vendors are worth doing a little prototype to see how well things work.
4) Proof of concept for short list. If there are a few good vendors after an initial weeding, there may be a mini-project to select which one should get the recommendation to go forward. This is where an architect may take a few laptops and try out the software in a controlled environment in order to gain some data to show where various products are good and bad in terms of providing the recommendation. Result tends to be either a spreadsheet or a word document summarizing the findings.
5) Start project to bring on new system which may involve training or scheduling or other issues to get the ball rolling on integrating something new. Note that this can be a multi-year multi-release project with a total cost in the millions of dollars.
For process changes, it works a bit differently, though there is a similar method of why would we do this, how much will it cost, can we try it and see, and if it works can our standard incorporate this into regular practices.
How big a user community the new technology has. A good user community can save a lot of time when troubleshooting the inevitable implementation issues.