My company has a variety of web-based and instructor-led courses that back up onto a SharePoint library and on a server folder. We are a very small company, with only a few products, and little need for cumbersome management systems. However, we desperately need better processes and practices for managing the constant, little changes that we make to our courses and websites. Anyone out there with models or templates that work for you?

A little context: right now, I am the entire ISD department, and there is also a developer here who makes fixes to the live web-based products as needed, on the fly, without documenting anything, and without making backups. There is also a contracted web developer who makes changes to the live site as we request them. These may or may not be backed up. I am no organizational wiz myself (ADD, actually), and I'm just trying to find some not-cumbersome methods of tracking file changes that work for a small company.

Thanks in advance.

First thing you could implement is a file naming process that both of your developers use. I would ask both to contribute their thoughts and then try to come to a common agreement.

Secondly, I would shop around a bit for version control software. There may be something reasonable and simple.

Sheldon Murphy
Solid State Learning
www.sslearn.com

Version control and backing files up are not quite the same thing. Backing up files is "simply" having another location to copy the latest version of files. Of course you can have archive/version directories, etc.

Version control software that I have used will store "multiple" versions of the same file - no file is ever deleted, and you can go back in time to a previous version, even if it's not the latest. This has saved me a few times. One key to using version control software is that you don't enter every version into it. Determine at what key points in time you want to update - beta test, final version, etc. You will used up drive space otherwise.

Finally, whether backing up or using version control, buy-in by all parties is critical. If you have staff/contractors who don't back up consistently, they aren't going to be "bothered" to keep version control accurate.

It sounds as though your developer is doing "continuous improvement". This may be useful for a development enviornment but is wholly inappropriate for production products. COnsider, if a user has a problem, how does she identify the particular version of the software?

I would go with keeping versions or dated snapshots. That is, release versions and number them (100.201, K.1, etc) or date-code them (20080930, etc.). Keep copies of each version/release. Tools like CVS and other open source software versioning tools support this directly.

Thank you all for your input. We have started implementing some of these things, like the version control numbers. Back-ups are a little tricky for me because most products are web-based. But this gives me some good general rules to consider moving forward.