A packaged solution will inherently help define your project, simply because of the predefined constraints of the package. I apply the "who/what/why/when/where/how" questions to the project that I was introduced to in journalism.
Who - List the clients / list the support people / list the installation people.
You will probably want to identify a pilot group up front who are willing to spend the extra time to give any feedback required prior to the rollout. Successfull rollouts require a champion, and you may find this person during the pilot phase of the project. Often the project manager becomes the champion.
What - Obviously the package, but there are also Server requirments, client hard disk space required, minimum platform requirements, infrastructure issues, backup requirements, training materials, required modifications,
Why - If you are going with a packaged solution, you will have a reason for doing this (usually cost effective solution) and its good to have a formal sheet on the reasoning behind 1) using packaged software and 2) how it will be implemented (overview).
When - Here you get to the PM guts and glory. Get the input from the concerned parties and leave plenty of slack in your schedule. Now double the slack again!
Where - If this is a localized or departmental rollout, this will be a no brainer, but if you are doing a multisite rollout, your 'where' will need to be thought out very carefully.
How - How will this impact current practices for (refer to Who). Get this straight early on. You don't want to find out that a package you are replacing with an off-the-shelf solution lacks a critical function that is required for month end closing.
-------
(continues on next answer)
