total level of effort for the rollout with a relatively high level of confidence. Answering these questions also helped in scheduling the projects for conversion since we could group and assign them based on project type, maturity level, etc.
Once a project has been "brought to the bright side", it must be deemed "converted" and moved to support. Progress is noted and tracked just like any other project. Metrics are added to the overall benefit being brought to the organization by your effort, and published. We recommend using an Intranet website to advertise the success and improvements being made to the bottom line and keep that up to date. It's amazing how quickly people will forget how it was before your SCM solution, yet be quick to point out its flaws.
A project "in support" should receive routine correspondence from the SCM Team regarding enhancements, happenings, etc. They should be routinely scheduled for "consulting visits" from the SCM Team, otherwise known as audits. ;-) They should be invited to routine brown bag sessions to collect feedback on the solution and recommendations for enhancements. These improvements are then prioritized and scheduled in a constant (much smaller than at the beginning) budget focused on continuous Infrastructure improvements. Without this, the SCM Team's capability to support projects will constantly erode over time and eventually you will be back to working tons of hours performing tactical activities.
The metrics you capture are your best friends. In a world of IT strategies that change with the wind, it's very easy to find your budget being questioned - even after a big successful implementation. We took the metric measuring to a new level at a client where we calculated the average dollar savings of creating a formal release the new way versus the old way. Then we kept an automated counter of every release created. When that counter got to a certain "significant" amount, the system sent a text page to a pager that we gave to the CIO. The CIO would be sitting in a meeting and receive a page that said, "Your SCM group just saved you another $102,832." The CIO loved it because he was able to brag in the meeting, and we loved it because it kept the value we were providing in front of the decision-maker on a constant basis.
The nature of best practices is that they are detailed enough to be tangible, so they need to be specific for a particular situation. The best practices mentioned above won't work for every situation, nor do they attempt to be a complete list of SCM related best practices. Agile SCM has been implemented on many projects the way mentioned above, quite successfully. We hope that you will find some of these ideas useful in your organization or situation.