Every project to implement a specific application or technology should be at least two phases:
1. Get it working for the first time. Check it out and learn about it, with the intention of throwing this copy away.
2. Get it working in production. Do it for real.
You cannot plan out how you are going to support something in production until you know something about the application. You won’t know anything about the application until you’ve tried using it once. Therefore the first steps of a project should be to check it out first. Then do it again for real later.
This goes for small applications and projects, too. Sure, you might be tempted to just start using that copy of MediaWiki you installed last week so that you could check it out. Don’t. Install it again from scratch and do it right so that all your mess-ups, all your false starts, and all the cruft that comes along with a first installation gets cleaned up.
I usually enforce this for small projects by having separate development and production environments for things. If I want to check something out I do it on my development box. When I want to do it for real I redo it on my production box. Once in a while I just level and rebuild my development box so that all the old mistakes, orphaned files, etc. go away.
If you’re a project manager this approach has several benefits. First, your team can make better decisions about how to implement it once they’ve had it running as a test. Second, your team can develop implementation documentation and procedures with the test instance, and then follow that documentation precisely for production so you know it’s accurate. Third, your production instance won’t be saddled with all the cruft from the testing. Fourth, you have a fighting chance at maintaining a test instance of the software, away from the production copy, which you can use for upgrades, etc.