It is an exciting time in the life of a project. The bulk of the hard work is done, the clients are looking forward to the new system, and the developers are once again getting enough sleep. The project is ready to go live. Before that happens, it is vital that a few important steps be taken to assist in a successful project implementation. You are at one of the most critical times of the project lifecycle, one that can have a lasting impact.
In my environment, this phase is referred to as transition, and I tend to divide it into two groups of steps: steps leading up to deployment, and steps to be done at the time of deployment. This article will discuss the former. It should be noted that none of the steps detailed here are new to the management of this project—in fact many should happen perpetually during project execution:
Revisit the inventory of stakeholders. – The project roster should have included all of the stakeholders encountered during project planning and execution. Take time to analyze this roster again, this time focusing on some key points:
- Has everybody who will be impacted or required for the transition been made aware of the schedule?
- Is each participant aware of his or her role?
- Are there departments or individuals that are not represented in the roster?
A project I was in charge of fell short of its implementation goals because two system users who represented an entire department were overlooked during the transition phase. These two were generally content with the old system, and since we never heard from them they just kind of became invisible. They suddenly became visible to us (and vocal) when they lost their access to the old system and had no idea there was a new system. Lesson learned: It may be worth your while to look at your user database and ensure that you really know its universe.
Establish a set of measurements to evaluate the project’s effectiveness. – Take the time now to ensure that you have defined and can capture meaningful metrics to reveal any savings or efficiencies that were expected as a result of the project. To assist in this, revisit the goals and objectives that were identified in the project charter. These were important at the start of the project and should be the drivers of project success as you proceed. The effect of these goals may not be realized until well after the transition takes place, but the time to begin capturing key performance indicator data is now, while developer resources are available and the important elements are fresh in everyone’s mind. It is unlikely that anybody will want to initiate this type of effort months following a successful implementation.
In my experience, gathering performance data is not terribly complex. With the simple addition of collecting timestamp information at the key steps in the process, you have a method to determine the overall length of a process and how long any step within that process took. With some straightforward programming, you can reveal bottlenecks and also show efficiencies gained by implementing the project.
Review all “licensed” items. – Before you find out that a hardware or software license is unsuitable for the production environment, focus some time and attention on the terms and conditions of the licenses. Pay attention to areas of difference between environments, and evaluate things such as number of processors supported by the license and your ability to include any components within a virtual server environment. Ensure all software licenses are suitable for production as well as development environments.
During one implementation, I discovered that the license allowed for interaction with one vendor’s database management system—the one we were using in development to contain costs, but would not allow interaction with the production environment’s database management system. Although the SQL and the drivers were all the same, a costly change to the license was required.
Review all “expiring” items. – This phase of the project is a good time to gather and produce an inventory of items that will expire at some time during the life of the system. This includes items such as digital certificates, software licenses and subscriptions, or maintenance contracts. While you are aware of these items now, the expiration dates will likely slip from everybody’s attention following a successful implementation.
I have found that the legal team appreciates any heads-up you can give them about expiring contracts. They may be able to schedule a review of the new or updated contract on their terms, not yours. And imagine contacting the vendor, asking for the renewal material in advance!
Ensure that training materials or user documentation is complete. – More importantly, are they correct? Since projects include change, make sure that the materials match the product that has been delivered. As product development continues you should evaluate through your contact with the team—or better yet, through hands-on experience with the products being developed—whether or not the user documentation aligns with the product.
My observation is that the best people for creating user training or documentation are key members of the user community. With far more domain knowledge and personal experience than your documentation specialist or business analyst, these community members can provide the proper levels of focus and hit the proper areas that need to be emphasized. Just make sure the contract or scope of work supports this kind of approach.
In a future article, I will discuss the steps to be taken at the time of deployment.