Moving on to the next phase -- QA Site

This past week I've been procrastinating. I have the One-Shore.com website (sort of) complete. It's good enough for now. It's untested on older browsers (including IE 6) and it's not the prettiest thing, and the copy is terrible. But it's there. I have what I want, it just needs edited.

Now the thing to do is get a working QA Site (a demo at least.) I've been putting it off. To be fair, Christmas has intervened. I decided about a week ago that I should do it like a real project - from concept, to proposal, to requirements, schedule, budget, on down to deployment. At that point I got lost in the process. After all, part of what I want to do is identify (or build) tools to help me do that sort of thing.

Speaking of which, something else I could be doing when I'm procrastinating is writing blog posts and wiki entries on tools and techniques.

I'm suffering from paralysis on what frameworks and tools to use as well. Should I use a project management suite like dotProject or keep it lightweight? Should I use bugzilla or trac? Should I use django, rails, php (which php framework), or java (which java framework)? Should I write my own framework (in which language?) Which tools should I promote? Should I write my own test case tool? How much should I do up front -- dashboard, web services, virtual appliance?
Should I be spending time looking for customers? Where?

Stuff like that. I need discipline. I need scoping. So that's what I'm going to do. Treat it like I would any other project. Only I'm the CEO, graphic designer, copy writer, developer, tester, project manager, sysadmin, accountant, and consultant.

I'll start with ONE RFP. Written by myself. I started to say "a series of RPFs" but then changed that. Now I'm changing it again. I'll write two. One as a potential perfect customer (knowing what I want to build.) And another as an internal RFP to implement that proposed solution. A "concept" document will proceed the internal RFP.

And then I'll do scoping. I'll come up with a list of features, and then pick the ones I can implement at first. That will (hopefully) be based on the fictional customer's RFP, but with an eye towards expansion to meet future functionality.

The next step is a project plan. How am I going to implement it? What tools am I going to use? It's okay if I don't like what I choose. After a month (or three), I can change. I'll give myself a schedule, and a budget.

After that, then is the design. I'll decide architecture and requirements. I'll document them according to my project plan. If my plan says word docs on a local file, fine. If it says dotProject, or a wiki, fine. I can change it. But try one and stick to it for a month. If I decide django's for sucks, or I really want to build my own PHP framework, fine -- but stick with something. Get a 1.0 out there. Make it a really small 1.0 There's always 2.0.

Plan monthly or quarterly. I think eventually quarterly will be a better fit. But when I'm by myself, monthly is fine. There will be a lot of rapid changes in tools, process, design, features. Release weekly or more. Document it, blog it.

There. Now I'm off to write my concept and fictional RFP. And read a bit more about writing proposals. That's what I'm doing today.