Hi, I wrote a pretty detailed response but Netscape crashed.. so here are the highlights.
- Mysql is fine for this job, it will take longer for
Oracle which is overkill. I've used both and Abigail's
comments notwithstanding, I can tell you your choice is fine. I read most of the document she provided and while
there are good points there are also a lot of people with
great experiences on MySQL and I find much of it outdated FUD particularly with regard to the needs of your project.
- You must have telnet access to stay sane now and in the
future, you might need to look at the apache error logs or maybe compile your own perl modules some time. Rackspace is nice, I have not used them but have been very impressed with their responsiveness at night. ssh is better than telnet if you can get it. I recommend linux with RAID 5 disk array.
- Unless you must do clickpath tracking or very high volume
accesses, don't use mod_perl on this project. It is a lot
of fun but you need to be able to restart the server and
it takes a lot longer. There is not a ton of documentation compared to the number of issues that come up with it, so experience is important.
- Don't do credit cards in the beginning. It is complicated
and other companies and laws will be involved.
- As for project schedule, you may have trouble on this project if you allow the client to eat up your development
time with figuring things out. Development time starts after the spec is signed.
- You need to get a dialogue going and confirm your understanding of what they are saying. The client has
to participate in developing a detailed specification,
and must also be coopted to promote success of the project by the following activities:
- Signoff on screen mockups and detailed functional
descriptions before development
- Signoff on delivery of parts, if you can handle that.
- You make weekly risk assessment reports ( a number 1-10
may be good) and use "that increases risk" and "decreases risk" when new functionality or deadlines are
mentioned. The idea is that you do not want to get behind
the eight ball trying to defend yourself against an unrealistic deadline from feature creep or some other problem that may crop up.
- Check out some of the ideas of XP programming philosophy, it has old and new ideas and may give you some
ammunition if you use some of them.
- It will probably take 2-3 times as long as you think. Keep a schedule with expected man-days per task, including testing on your side, bugfixes, testing on their side, content delivery, whatever. Actually content delivery is in addition to that. The variables you generally have include the number of people on the project, the budget, the time until delivery, the quality/robustness of the code, and the SCOPE. Scope means how much you are going to do. It is easiest usually to change scope so you must get
the client involved so they do not make it difficult to change scope.
- There was a very good recommendation above that you look at how your man-days projections match reality and then multiply the difference as a time stretching factor across the entire project. I didn't believe it when I first heard this but it is true.
- Make different phases of the project. The first phase
is consulting which you should get paid for, it involves making the spec and figuring out what they want down to screen mockups (line and text is fine). Also a designer is
probably going to be involved. Make sure of what you are
responsible for, including do you write HTML. Supported
browser types may be another thing to make sure of up front.
- The different phases will make it possible to move functionality to a later phase if you need to. Have the client set priorities (no, they can't say 100% or nothing) so that you can identify what core functionality must be perfect by launch, what is best effort, and what is later phase. Then you can get them to put feature creep functions
into the next phase, or get them to change other variables like schedule or maybe remove a different function.
- Get feedback as soon as possible from other people in
organization so you don't get nailed at the end. Also try to decide as much of the software architecture as early as you can, preferably well before signoff on the spec.
It looks like this is a dangerous project if you don't think of some of the above things. You will have to help your client figure out what he/she wants, and you are only working part time while there is a learning curve for some of the things you will be doing. I would say give yourself a large buffer, start the clock after signoff on the detailed spec, and get the client involved in the process so
they can see what will happen if they become unrealistic about things. Don't handicap yourself in the beginning by
agreeing to a lump payment at the end (especially if you are
meeting milestones and have a consulting report deliverables in the beginning), and if schedule is really important then discuss the possibility of budget changes to add another guy if you really need to at some point.
That's all for now, good luck!
