[...] other day I blogged about choosing a project management system and my decision to go with Teamwork instead of ProjectPlace or Basecamp. Six days later I can [...]

Not sure a categorised discussion hits the mark for Change Requests, but sure, if you can upload documents (with some degree of version control/audit trail) then that’d be fine for Requirements. Audit trail of approvals is always useful, mind.

I also use an offline task manager ‘Omnifocus’, wonderful as Basecamp is there are time when I am offline and cut-off from the data. Omnifocus is only for Mac, but stunning new iPhone app arriving soon and I wouldn’t be surprised if they had a web service running eventually.

If you want to get deeper into ‘real-world’ techniques for Getting Things Done you should definitely read David Allen’s seminal book on this, at least twice! His techniques work on everything from paper lists to Saas offerings like these.

Good luck with the new ‘Super-organised 2008 model Sabrina’

1) Issues

You can create discussions in different tabbed categories. I would create a tab in called Issues there and let people log bug reports that way.

2) Change Requests

See above.

3) Requirements and/or Scope definition

There’s a Notebook feature for documents, and I’d create a notebook for requirements.

4) Deliverables – the formal things that are contractually signed off & handed over.

You can create To Do lists and even re-useable To Do list templates. I am working on my boilerplate Deliverables which will be a to do list with all tasks assigned to me. I can tick them off as the project goes along, and push the Project Report button to create a PDF report of the current status for the client.

5) and – assuming IT projects – some support for Test Cases/Defects would be useful.

Again, a specific tab for that with discussion, or a notebook.

* * *

This might not be sufficient for IBM-level needs, but presumably that’s why you guys rolled your own :) For me, this is pitched at exactly the right level and I’ve had four clients I’ve pushed stuff to jump right in and start using it with not a single “how do I…” question or even an email.

That alone is worth not having a lot of extra stuff, to me at least.

And yeah, couldn’t care less about the risk register :)

1) Issues (as separate from Risks which are Bad Things which might happen: Issues are Bad Things which *have* happened)

2) Change Requests

3) Requirements and/or Scope definition

4) Deliverables – the formal things that are contractually signed off & handed over.

and – assuming IT projects – some support for Test Cases/Defects would be useful.

Enjoy!