dave wave
Posts: 5
Nickname: wave
Registered: Dec, 2006
|
|
Re: The Big Rewrite: Why So Hard?
|
Posted: Dec 29, 2006 3:27 AM
|
|
> I plan to pick richer web client platform
> such as Flex 2 for frontend, hopefully it can cut down the
> project risk.
>
In my experience it's all about managing risk, how big are the risks, the 'hopefully' in your sentence is a red flag that should be examined, don't proceed until all the hopefully's and the I thinks are gone or at least a strategy for managing them has been decided.
Write down all the risks and review it with the team, some obvious ones are
1) new technology (flex) - big
2) requirements - have they changed, are they well understood - don't know
3) development staff availability - for flex probably not available - so big, training required
4) hardware availability - don't know
5) etc.
The other thing you can do is suggest strategies as part of the risk management if the worse case occurs, if there is no alternative then you've identified the highest priority risks that must be evaluated and eliminated.
Management must be made aware of these risks, a risk / benefit analysis should be made, what will flex, as an example, give them, how much will it cost, what support infrastructure will be necessary, etc. It doesn't have to be huge, a couple of pages to start with, the most important thing to outline are unknowns and assumptions.
If these are presented up front an informed decision can be made, and everyone can act on the risks. The assumptions can be questioned (and if necessary pointed to when the blame is going around). Too often it's the other way around, someone says it has to be done in x months, here's a technology that looks good, let's do it, this ends in tears, because developers are always optimistic about how long things take and how good a new technology is, there's always problems, things never work the way you think they would, eliminate all the known gotchas, and wait for the unknown gotchas to get you.
In my experience the best way to mitigate the risks is focus on the unknowns and high risk items, and create small pilot projects to test if the assumptions are valid. For instance if setting up a flex environment and getting samples going takes 2 months instead of the 2 days you thought it would, well there's a problem, however if you've got it working that afternoon well things are good.
In many ways new tech is a separate project from the actual business solution, and all the requirements for the technology should be evaluated before the actual project. Of course the real world is never this neat, and deadlines are always here before you thought they would be.
Good luck.
|
|
Previous Topic
