I have worked on projects with long timelines, and they’ve concluded with the rollout of the main deliverable, which is usually a system or a process. My expertise is in Supply Chain Management, but most of my projects have an emphasis on IT. I was interested when I found the article The Rollout Phase of the IT Project (http://www.itpmpro.com/2007/07/rollout-phase-of-it-project.html) by Iman Budi Setiawan.
The author focused on 4 main steps of successfully rolling out an IT project:
1. Identify the Inputs (includes installation and user instructions)
2. Conduct Key Activities (includes the actual IT conversion to the new system)
3. Create the Outputs
4. Meet the Milestone
These steps align with my experience, and there are two main points worth discussing. First, the rollout of the system occurs at the end of the process, but the planning for the rollout should be running concurrently with the rest of the project. Secondly, I think Create the Outputs is the most critical step in ensuring a successful project.
If a project team thinks they can get to the end of the project and accomplish these four steps in a short amount of time, they are setting themselves up for failure. It is important to train end-users near the rollout date to make sure end-users experience a near-complete version of the system, but work must be done several weeks in advance to prepare training documents, arrange travel plans, and orchestrate the training. More importantly, Identify the Inputs requires the identification of hardware needed for the conversion, which, in many cases, is identified during the initial selection of the project to understand investments needed to implement the solution.
Most projects have a time constraint, and the final step in these projects is a variation of a go-live or rollout step. An important point, in my opinion, is that the rollout of the system itself or the flip of the switch to turn the system on should not be in and of itself considered a successful completion of the project even if all training has been conducted and you have full end-user buy-in. While working on a project, the project team does its best to identify any potential needs and mitigate risks, but it is inevitable that some improvements and adjustments will need to be made after the rollout once many more people are working with the new system. This is addressed by the Create the Outputs step. Because these changes are difficult to identify, it is also difficult to understand the amount of time and resources that may be required to address them. If the project team or IT resources are reallocated too quickly after the conversion, the key change requests that come out of the issues will not be addressed in timely manner, which could lead to the system being ineffective and a failure.
Does anyone disagree with opinion on these steps after reading the article? Can anyone relate how this is like or unlike implementations not involving IT?
Yes, it’s absolutely necessary to maintain a portion of the development staff to support post release or go-live support. Our system and software rollouts occur every six months for major releases and every three months for bug fixes and other changes requested by customers. To support this structure, we usually allocate a portion of the development staff to stay with the release and provide the needed changes. This ensures continuity as well as provides learning experiences that can be shared in developing future roll-outs.
I too have experienced technology related roll outs within my company, but perhaps not to the extent as yours or Asif’s roll outs. I have seen a common theme where there is not enough training for staff or enough testing in the final stages before formally rolling it out. I think that this is often due to time constraints of having to meet a deadline, or perhaps a political reason where an executive wants it rolled out faster. However, I agree that there needs to be more support allocated after the roll out to work out the kinks that will inevitabely happen.