I am a non technical person and have a small company who has been supporting my companies software for a number of years. The solution works well and permutations of the solution has been with the current IT service provider for over 15 years. I recently got a more established IT firm to do a general audit on the software. The current solution uses access as a front end with sqlserver 2005 as the database. The company who did the audit presented a list of faults amongst others that the technology is outdated, the solution is not scalable, bad design, non user friendly interfaces, tables not normalised, tables has no referential integrity, non use of proper coding standards and naming conventions, no application security only database security etc. The firm who did the audit proposed that the solution must be re-written and offered to do so. The current service provider aknowledges some of the findings but assures me that it poses very little or no risk to my business. To re-write the application will cost a lot of money. I am in a difficult situation and would appreciate some technical advice. I basically need to know if my business is at risk running on the current technology. I have a maximum of 70 concurrent users working on the system at a given time
Well, if you value Joel's word, i would say that you are indeed, risking alot here.
Rewriting stuff was and will never be a safe thing to do for a company.
To boil it down into simple terms, ask yourself these questions:
Are you having problems with the software currently? Are users complaining about the user interface, or is it particularly hard for new users to pick up the software when using it? Is data being lost or corrupted at any stage, or are you having problems retrieving reports from the database?
Do you currently, or in the future are you likely to need modifications? If your software is badly written, modifications will be more costly, and more likely to break the application and cause downtime in general.
If the answer to both questions is no, then you likely don't need to rewrite the software. You have to remember that good software developers see badly written software and want to re-write it properly - as well as this, there is money for them in developing the software, so their view isn't totally unbiased.
Like others have said, re-writing a system has its own share of risks - old bugs that were fixed a long time ago can rear their heads again, new bugs can be introduced, the developers of the new system can totally miss the point and make the system less usable than the previous system.
If there are problems with the current system though it may be worthwhile to consider having the system re-written by competent developers - if you opt to go this route however, make sure to get feedback from your current users, especially the 'expert' or 'power' users, to ensure that the system will fulfill all of their requirements.
Before you go view your problem from the technical perspective, you must assess how critical the application is to your business. It sounds as though you have a functioning application. If it delivers consistent behavior AND you have no need for upgrades / new development, you may want to leave it alone. We software developers love to complain about everyone else's code, re-write other's work with "elegant" solutions. That means money.
However, you have an investment that may need maintenance, and when you have the underlying code and database in dis-array, you will incur more cost because the application does not lend itself to be modified. You'll want to get a feel for how much change you need to support. Given that it has been in production for 15 years you've had a good run, so you don't have much risk there.
To do a re-write will cost you, because you need to recreate what the app does, and since the supporting database and program seem to be "de-normalized" and unstructured, it's going to a big effort. There are advantages to have a clean database model because it will be easier to do reports, export to Excel, etc. AND should you want to modify it the developers will have an easier time figuring out what to do.
To spend money to get what you already have requires that you challenge the firm to detail what additional benefits you'll receive. Are these benefits beyond what you're getting today, and will this firm deliver on their promises? Will your company be better off if the database is "normalized" but you receive no other benefit than what the current app gives you? Keep these in mind before you make the jump to a new platform.
Fix the problems in the existing app. It will be much cheaper, can be done incrementally, and if done properly, will result in a more maintainable app.
The suggestion to replace the ADP front end sounds like pure prejudice/ignorance to me -- they don't sell Access development so they want to build you an entirely new app.
On the other hand, the advice about the back end sounds like something that you shouldn't wait to fix (though it could require a lot of work, since existing data likely won't fit proper RI).
The front end and back end problems are two separate issues, and can be handled independently (though the app may need to be updated to reflect changes in RI -- impossible to say without a case-by-case evaluation).
I would hire a competent Access developer with ADP experience to handle the project. This will be much cheaper than the complete rewrite and you won't sacrifice any functionality, nor will you re-introduce bugs that have already been addressed in your existing app. It can also likely be done incrementally (depending on what the problems are and how they need to be solved).
The suggestions offered by the "more established IT firm" are pretty common for access/sql server projects. The suggestion is almost always re-write them as web applications.
I just did this myself last year -- took an MS Access front-end/SQL Server back end application, and rewrote the access part as a C#/ASP.Net website. We enjoyed better performance and more flexibility as a result of the switch, but the old front end had been around long enough that we never did get back all of the functionality that we used to have before the rewrite.
If you're actually seeing 70 concurrent users, and none of them are experiencing performance issues, and your corporate network is secure enough, then you may lose more by rewriting the application, at least in terms of functionality. On the other hand, this may be a good chance to evaluate "what works" and "what could work better"--and enhance workflows.
Excellent use of coding standards doesn't necessarily translate to an excellent application.
What prompted the audit? Does their solution address this issue?
Let's do the math:
People: 70
Avg. Hrs Using software/Day: 2 (Conservative)
Salary/Hour: $8.00 (Really Conservative)
Business Days/Year: 250 (Took out weekends & vacation/sick)
Cost of labor using application: 70 * 2 * 8 * 250 = $280,000 / Year (Could go over 500K)
How much improvement can you get? 5%, 10%, 25%
How much will the new application cost? 50K, 100K, 200K
If you are able to save this time, will your users be freed up to do revenue generating activites or will they just have more time to surf the web? You may want to create some worker efficiency factor: 90%, 75%
Simple answer... Most of the "risks" of using Access are surmounted by using SQL server as the backend. You already said your current solution works.
So it boils down to your future plans. If your existing application isn't missing any functionality that can't be provided via access I would just stick with what you have.
If you need new features I would consider a few things.
Are they something Access can't provide or do well (ex: Internet-facing Solutions)?
What is the potential benefit reaped by having the new features?
What is the potential cost incurred by not having the new features?
Can you put a dollar figure on 1 & 2?
How much to develop the solution in Access?
How much to develop the solution in C#
In other words, always do the CBA :) Better yet, do you own CBA, then ask both companies to provide you with one, and compare for fun. In the worst case you might get your existing company to come down on their price to retain you as a client.
Related
I have a Microsoft Access business critical database that was originally created in the 90's and has been enlarged and upgraded up to Access 2007 at this point. We have been using this database as a front end for a custom written ERP system essentially. We have moved most of the data over to an SQL server long ago, but we are still using MS Access as a front end. AS the project grows, we have a full time developer, we have started having stability problems and extremely frequent crashes of unknown causes.
As an example: 1 time out of 10 or so, a certain form will crash if I change the data in 1 specific field. There is no code firing at the time, the data is in a local temporary table that typically only has 5 rows most of the time. If I change the data in the table nothing goes wrong, but if I change it on the form Access will hard crash and dump me to the desktop. There are other examples I could provide of unexplained crashes
I am looking for advice on where to go at this point -- the access front end has all of the business logic for running our company essentially so I can't just abandon it. Ideally we would re-write the entire front end in some other language. The problem is that as a small company we don't have the resources to re-write the entire system in anything resembling a good time frame, and don't have the cash flow to pay someone else to do it. My ideal solution would be a conversion of some sort from the access front end to another end point -- whether web or local windows -- but my searches here and on google make that seem like a non-starter.
So essentially every avenue I look at seems to be a dead-end:
We can't find the source of the crashes to stabilize our current system,
We can't stop production in our current system for as long as it would take to re-write it,
We can't afford to pay someone else to write a new system,
Automated conversion tools seem like a waste of money
Are there other options or which of the options that I have thought of seems best?
We have an enterprise level program with an Access front end and an SQL Server back end. I wonder if it might not help to split the program up into different pieces for diagnostics. For instance if you have Order Entry and Inventory Management you could have one front end for each function. (Yes I can hear the howling in the background but if it was only for the purpose of diagnosis maybe it would help... )
You can also export the Access Database objects to text files and then import them into a fresh new database to get rid of weird errors in some occasions.
Well, I guess I will rephrase the basic issue here. If you have two Computing Science graduates on staff then they should have long ago anticipated that they reached the limits of Access. I fail to see this as any different than an overworked, oven in a restaurant that now have too many customers or a delivery truck that does not have the capacity to deliver goods to customers.
Since funds don't exist to re-write then your staff failed to put aside funds on a monthly bases to deal with this situation and now your choices as a result of this delayed action to deal with this growing problem places you in a difficult situation.
The computing science people you have on staff should have long ago seen this wall and limit you hit coming. In my experience is with most CS people is they consider Access rather limited, and thus even MORE alarm bells should have been ringing here and this means even less excuse exists for you to be placed in this unfortunate predicament.
So, assuming the computing science staff you have are well maintaining this application (and I graciously accept this is the case), then then a logical conclusion is this application has reached or exceeded the limits of Access. As noted such limits should have been long ago anticipated.
As you well point out that funds now do not exist for a re-write, then few choices exist without such funds.
However, you case may not be so bad since we NOW know you have experienced developers on staff. Given this case, then my suggestion would be to consider breaking out modules or small manageable parts and features one at a time from the application and having your well trained and experienced developers build either a web interface, or perhaps even using something like .net if you wish to stay 100% desktop. So this "window" of opportunity is a great chance to consider a change in architecture)
Since the data limits are SQL server and NOT Access, then both applications (existing access front end) and the new parts can BOTH well and easy operate on the same data. As you do this, you then break out and remove the existing parts from the Access application. This would suggest you eventaully return to accetable stability in the Access applicaiton. At that point , you could continue, or stop to save funds.
As noted, without funds to re-write, then the only choice is to find some means to free up SOME limited resources on a monthly basis to solve this problem.
At the end of the day, the solution to this problem is more resources, but without such resources then few technical choices and options exist here. Based on the information given so far YOU have made it clear you don't have resources here. However, the solution to this problem here requires resource allocation and planning.
In other words a technical fix to this problem without resources allocated is not likely an available option for you.
I apologize sincerely for not being able to give you a technology solution here, but this looks to be a solution that will require resources to be allocated to the problem and no simple shortcut or trick or magic silver bullet exists here.
How do you deal with a client who has different time estimates for the software product than yours?
I am going to describe a scenario that is not mine, but that captures broadly the same problem. I am working as a subcontractor to a large company that has a programming department. The software project we are working on is in an area that the department believe they have a handle on, but because their expertise and mine are very different we tend to get different results.
Example: At the start of the project I suggested one way of development which they rubbished as being unrealistically difficult and suggested integrating a different framework (one they are familiar with) with the programming language we are using (Python) to get more or less the same result.
Their estimate for this integration: less than a week (they haven't done the integration before).
My estimate for the integration: above two weeks.
Using my suggested way to get the result needed (including using matplotlib among other libraries used elsewhere within the project): 45 minutes. This is not an estimate, the bit was actually finished in 45 minutes.
Example: for the software to be integrated with their internal system, they needed to provide a web service for me to use. They provided a broken one, though it does work with their internal tool (doesn't work with .Net or Java mainstream packages among other options). They maintain that it is my fault that the integration has taken longer than the time estimated.
The problem is not that they don't know, the problem is that they have enough knowledge about programming to be dangerous (in my opinion). Is there some guidelines for how to deal with this type of situation? A way for expectation management? Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?
If a client isn't happy with a time estimate, don't do the work. If they think they can do it better or faster, tell them to go ahead.
The one thing I never allow is for my estimates to be modified. That's something that caught me out early on in my career but we learn our lessons.
If clients were so good at doing the work, they wouldn't be hiring me. I'd simply point out that they hired me for my expertise so why are they disregarding that expertise. Of course, if they were to allow the scope of the project to change (i.e., less work), that would be another matter, and one up for discussion.
If you didn't lock in exactly what they were meant to provide as part of the deal, then it's a "he says, she says" situation and, unfortunately, the customer controls the purse strings. However, often, the greatest power you can have is the ability to just walk away.
No-one says you have to do the job.
Of course, all that advice above is worth every cent you paid for it :-)
I don't know your specific circumstances.
Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?
My answer for sure. If you can avoid those projects, do it.
Some signs : people thinking they know how to do things when you can guess they can't. The "oh no let's not use this perfectly suitable tool because I don't know it" is a major indicator that the person is technically challenged.
first of all, it is no fun to be in such an environment.
So, if you like to have fun at your job, and you do not need to take this job for extenuating financial reasons, then simply do not take the job that is not fun.
Since that is hardly realistic in many cases, you will end up with the job and need to manage the situation as best you can. One way is to make sure there is a paper trail documenting your objections and concerns with the plan. Try not to be overtly negative, but try to be constructive and present valid alternatives. Here you will need to feel out the political landscape, determine if the 'boss' will be appreciative or threatened by your commentary, and act accordingly.
Many times there are other issues that management is dealing with that you are not aware of. Be cautious of this fact, and maybe ask the management team if this is the case, again without being condescending or negative.
Finally, if you have alternatives that take less time than the meetings it would take to discuss them, just try it in a sandbox, and show it off. This would go a long way to 'proving' your points. Caution here is that you could be accused of not being a team player, or of wasting resources, or not following direction. Make sure this is mitigated by doing these types of things on your own time, or after careful consideration of how long you are spending on these things as well as how vested your boss seems to be on the alternatives.
hth
I ran into the same problem with integration. Example: for the
software to be integrated with their internal system, they needed to
provide a web service for me to use...They maintain that it is my
fault that the integration has taken longer than the time estimated.
Wow very similar to what I was experiencing with a client. The best thing I can suggest is to keep good documentation. In the end that is what saved me. When it came to finger pointing I had all of the emails and facts in order and was prepared to defend my self.
One thing I would suggest is to separate out a target/goal and an estimation. I would not change my estimate unless it involved actually removing features or something is revealed that would make it easier. Tell them you will try to hit the target in anyway you can and you care about the business goal. However, your estimate will not change. If its getting no where and they are just dense then smile and nod and take it if its the only gig around.
Was just writing about this in my blog
How to estimate the WRONG way
We have been trying now for a while to assist the management (of a customer) with the implementation of a a new system that is custom developed by ourselves, to their requirements. Their old system is text based (DOS) and their employees have been using it for years. The new system is Windows GUI and have many advanced features which will make their lives easier and their organisation more efficient. The problem is that the staff do not want to adapt to the new GUI environment and they are now resorting to be unfriendly and as unhelpful as possible, often placing serious obstacles in our way. The management is adamant that implementation must proceed. The system runs trouble free. We have been consistently friendly and helpful with all parties.
Any advise would be greatly appreciated! Have you encountered something like this before and did you manage to turn it round?
Note:This question is intended to help Programmers etc. with implementation difficulties by sharing experiences and factual solutions that worked. It is not intended to be subjective and indeed Programming techniques may help to solve the problem.
Use the tool
Somebody needs to really understand how the existing tool works. Not just well enough to walk through it; but well enough to do it for real. Why not take 2 weeks and go and do their job with them? That will both improve your understanding of the tool, and may foster a better working relationship with them. And while you're there, perhaps buy the drinks once or twice - it sounds corny, but anything that lowers the hostility, and lets you communicate.
User experience
Getting a good developer (or better: designer) who understanding user-experience is probably key. You can't just completely change their tooling and expect their productivity to remain the same.
Keyboard use:
Think of tools like Visual Studio, AutoCAD, etc - in most cases you don't need the mouse, and "die hard" types wouldn't notice if you took their mouse away. Try to respect this; provide shortcuts / chords (ideally the same as the existing system).
Terminology:
Keep it the same. Don't invent new terms for things.
Talk to them?
This may or may not be possible, but getting a few key users "on board" early can be pivotal; especially if you genuinely empower them to help with the user experience.
Find the faults
In the existing system. Take away their existing pain points and they may forgive you a lot.
Unfortunately it sounds like a case of needing to close the barn doors after the horses have bolted. You really need to get grass roots buy-in on the need for an improved system before beginning the project and maintain that relationship during the development.
By having champions of the system at the "coal face" level in the business would a) make sure you meet not only the management requirements but also the users goals which is all important in a successful system and b) the users get a system to which they have been a development party not just had a system thrust on them.
Getting people to moan about the short comings of an existing system is easy. Describing possible new systems before its create in way which allows the users to comment enables them to feel some control and gives you vital feedback. Be absolutely sure to identifier those killer gripes about the old system and make sure those are addressed in the new system.
Of course this all a bit late for you. The way forward is to create a review forum with the most vocal opponents and put them in a room with you and management. Get them to defend their reasons for not wanting the new system. If you can't show how your new system is better then perhaps it isn't. If you can see how the new system might be slightly improved (the movement may only need to be small) then do that, it may go a long way to get back the feeling of involvement you missed out on before.
I would sit together with the staff or a couple of the more loud mouthed opposers, go through what they find lacking with the system and suggest some of these changes to be incorporated in a future release(s). That way they will pay more attention to your the system and also feel more a part of the process instead of just being handed something like some peon. In addition it would also help avoid any misunderstandings about the system.
Get one / more of the user to be your champion by involving them in the development process. Make sure to choose the right ones. Hopefully one that you can reason with. When launching, do a launch event. Make it a big deal. Not necessarily applied to an application, but I've seen it worked in my previous work environments. If this is too late (you went ahead without any involvement from the actual users before), well... there is always things called staff turnover, lol. Out with the old and in with the new. Make the new users your buddy :).
You have to show some kind of benefit for making the change. A demo / mockup can be useful for this. Choose a manager to demo it to and wait. Let it become his idea. Then it might move forward. Being to pushy can cause a negative knee-jerk reaction which might block further consideration of the idea.
It is sad that software often gets replaced by a management decision without any user involvement and then people wonder why the system is rejected.
I've witnessed this first hand. A guy I once worked was told to develop a new version of an application "in secret". At the end of 6 months development it was shown to the users. It didn't meet their requirements and they were angry they hadn't been involved. Needless to say the software didn't make it into production and the developer left shortly after (I felt sorry for him as he had wasted 6 months effort and actually did a real good job considering the circumstances).
The chances are that the software is inferior to the previous application- perhaps data entry is actually slower (you will be biased as you wrote it- everyone likes to think their software is better).
Re-engage with the users, do some analysis and work out what is bad about the old system. If the new system can address the grips the users have with the old system you might be able to turn this around.
Edit- who was involved in engaged with your developers? Presumably the managers at the client, who probably never use the system? This is another big mistake people tend to make- managers driving requirements.
If the old system is perfect, then it never needed to be replaced in the first place!
Personally, I've found that when good developers deal with clients, they often get sucked into the after-sales support process and this process has been difficult to reverse, so was just interested to hear the various strategies that developers employ in maintaining a healthy, useful relationship that keeps clients using the right person at the right time.
So do you and, if so, how do you deal with clients?
Just a tip: Write down every single thing a client says to you.
Most of the projects I work on are done on time-and-materials contracts, which means: we give the customer an initial estimate of how long the project will take but bill for actual hours worked, whether over or under the estimate (I don't know why a client would agree to this, but they do). Once the project is "complete" and in production, we set up a service extension to the time-and-materials contract, creating a block of billable hours to cover after-sales support. When a client is aware that they're being billed for all contact with us, they tend to keep that contact to a minimum.
One other point: I've found that it's best to communicate with clients via email where possible. It's a much more efficient way to transfer information (assuming everyone involved can write), and it leaves a permanent record of what the client told you to do.
I'd go the opposite of what have been said.
The client is your number one information source
Avoid intermediaries (human and technical)
Keep tracks (not to use it against the customers, even if it can happen, but because he pays to get what he wants)
Communicate - on your initiative - in a short regular basis but for small amount of times.
Any doubt can be cleared asking the good questions. The guy don't want that ? Get rid of it (even if you like it better). The guy want that ? Why not, add time and money on the contract.
You must train your communication skills
Most of what has been said here before is essentially related to the fact that programmers usually have poor communications skills. So they fall into the typical traps :
customers give them bad info
they waste time
they get stressed
At the end, nobody is happy.
But with trained communication skills you will learn to direct when, how long and about what your chats will be, and so :
Make any deal quick and nice
Give confidence to the client
Understands what the client wants (not what he says he wants)
Ensure is satisfied with the answer (even if it's nonsens for you)
Everybody will be happier : the customer will feel good and let you work in peace while you will have the information to keep working. Eventually, the resulting software will be better.
Think talking to customer is boring ? They think it too. And paperwork is boring as well, but you must do it, so do it well instead of looking for excuses.
This is a pain we feel as well. Once you help out a customer it is too easy for the customer to directly contact the developer later on and request support. And since we usually aim to please, and probably feel sort of responsible when the application we built for them has a problem, we too often give the customer a quick helping hand.
I think that the developers should be separated from the customers, but this requires that the company has a support/concultancy department which can fix the problem instead. They in turn should be free to contact the developer, unless it's a huge company with a mainstream application where there is a less risk that the problem can be traced back to a problem with the sourcecode.
But let me tell you, I understand how difficult this is. I've been working in our consultancy shop for many years, starting from support and now I'm mostly managing the other consultants and developing. There are a lot of customers (like hundreds) who feel they have a personal relationship with me, and assume that they can call me directly even after years and years.
My tip is to make sure you have a good network of concultants and supportworkers who can help the customer for you, and have them contact you instead if they can't figure it out.
I just finished my education and am working at my first job, but here is what we do:
I communicate through a third party from the same company with "higher rank". The third party is someone knowledgeable of the requirements the software should have, but not in software engineering. When I ask about specifications, or send them proposals he distills the essence of their answers send them to me.
I think this way of working with stuff limits the amount of bullying a customer can get away with when it comes to changing specs, expanding specs etc.
For me it's especially useful since I'm only 21 years old, and people might have trouble believing I can get things done.
best practices:
Remember the client is the one who signs the checks.
Users work for the client.
Refer any user requests to the client for approval.
Always deal with the client because they understand that everything you do will cost them money.
If the client wants after the sale support and is willing to pay for it then give it to him cheerfully.
Oh and what MusiGenesis said!
The best way is to never ever ever give your direct line to a customer. Have them go through Tech support (if it exists) first. We employ this method and it works well. The software developers are the last resort - for things that support simply can't do/don't know how to fix -- such as a DBA not knowing that the servers are instanced. But it will cut down on the "it's not connecting to the internets" type of phone calls.
You could also force all support requests to go through email/secretary. At that point, you can discern which ones are critical, and which ones can be solved with a simple 'tutorial' on how to fix the problem.
And as stated above - record EVERYTHING in an exchange with a customer. Doing so prevents the 'well he said she said' deal that customers can fall into.
Then again -- if you're getting a ton of customer support issues, you should be looking at the cause of it - whether it's a training issue, or whether the software is legitimately buggy.
In our company, every developer is also a salesman. If I step over the door of a Customer then I'm in a good position to make more business.
They know me and I have credabillity because I've allready delivered to them.
I have knowledge about their business
I use my knowledge to ask questionas about other parts in their business
I plant hooks to them when I talk to them, in their best interrests of course.
I make clear that we are not a "hit and run"-company, but there to really support their business.
Maybe this is not how all company does, but I think you should use the people you have that allready has a foot inside the customers company to really work with them and make more business and tie the customer tighter to you.
I personally think developers should never interact with clients. This is why you have the Q/A team. They get requirements, hand them to developers, discuss any issues, schedule development progress meetings. If developers have questions, the go to the Q/A personnel responsible for the requirements and documentation. Developers are engineers, not salesmen or negotiators. They should be given environment to develop stable, working code without getting distracted by customer phone calls. This is how many companies deal with customers regardless of company size. In the end, your chances of completing a project on time are higher than when you customer calls up and decides to change requirements or requests a feature. Which would probably mean you have to go back a couple of iterations and change something that may break everything completed past that point.
Lots and lots of communication. Communication can be as simple as checking in with your customers by stopping by at their desks (if you are co-located) or keeping in touch over the phone. The more personal the communication is (in-person beats phone call, phone call beats email, etc.), the stronger your relationship will be.
Another good conflict resolution practice I've used is keeping as much information as possible in a single, shared place. I've used a bug/feature database (JIRA), a wiki, and even a network share drive for this purpose, but the point is that neither party has exclusive lock/write access. Updates can be made together with your customers, and there is a clear, public record of the change history of your system.
We are developing a web application, which will have a database with over 5 millon documents, all of them will be in various languages. The site is planned to have more than 3 million visits per month (hopefully more).
We need a stable and scalable solution.
We are now using Java EE over JBoss application server with PGSQL DB, but we would like to know if this fits the problem or there is a better solution, because the project is a the beginning and changes are yet viable.
Also, as many of us, doesn't have a lot of experience with this type of projects, the opinions of the ones who does, will be very useful!
I hope I made myself clear. Please let me know if you need more information.
Thanks in advance.
The architectural design considerations of your solution are probably more important than the choice of "platform". In other words, how are you going to make your application scale? Do you need to store distributed session? Do you need real-time database synchronization or something a little less up to date? How will you do request load balancing, or handle fail over? Can the business logic work over a distributed set of nodes/sites or whatever you envisage.
Once you have a design that suits your purposes then the choice of your implementation platform can be a better informed decision. Whether it's java, .net, rails or whatever doesn't really matter. They all have their strength and weaknesses, as do the members of your team. Use their strengths to guide this part of your decision making process. Don't try to learn a new technology in tandem with building what sounds like a fairly serious site.
I've used JBoss on a pretty large distributed ebook delivery system with tens of thousands of page views per day and it never missed a beat. Likewise I think Stack Overflow is a more than adequate example of the capabilities of the ASP.NET platform with regards to the numbers you are mentioning.
Hope that helps.
I personally would not take responsibility to offer own solution to a team without asking for advice from somewhere else first. Same way as chaKa does. What I would not do is to rely on one source of help making final decision.
You may need to consider following criteria:
How much time do you have? What is development plan? Should you start right away or you will be given time to learn.
Do you need framework? Are you expected to deliver quickly? How many requirements do you have? It all affects will it be framework based solution or from scratch.
Will you support project as well? How many people will do it? You need to know also will project grow slowly or it should be deployed quickly and forgotten.
What skills does your team have? What are they good at?
What would make you excited and want to do your best implementing solution?
I believe there is more to think about...