In my recent posts, I segmented technology projects into four phases (project specification, planning, execution, post-go-live) and highlighted common – and often neglected – points and risks to consider during the first two phases of a technology implementation – project specification and planning.

Technology ImplementationThis post tackles the third and fourth phases: execution and post-go-live. Most problems are likely to surface during these phases, especially if implementation is poorly planned. The post-go-live phase is often an afterthought, but it is critical to project success and user adoption.


  • Status reports. Inform stakeholders of the project’s status at regular intervals (determined in the project charter). Reporting components (e.g. timelines/milestones, budget, resource management, successes, challenges) should be tailored to each audience’s needs.
  • Project changes. Sometimes specifications change mid-project. The project charter should have an established process (including approval/veto options) for changes that fall outside the original scope. Changes typically delay projects, so it is prudent to build appropriate buffers into the project plan.
  • Documentation. Every phase of the project should be documented in detail. This serves as a system of record that not only confirms that the project was completed on time and on budget, but also provides a working knowledge base that can be referenced so future projects avoid pitfalls or can repeat successful steps. Documentation may be a legally requirement for certain companies and industries.
  • Communication. Throughout the implementation process, communicate with end users about the purpose of the project, how it ties to enterprise goals, what they should expect, and how/why it will affect them. Highlight project successes.


  • Transition. A common pitfall is assuming that once a project goes live, the work is over. Implement a technological transition period (defined by the project team) during which legacy and new systems operate simultaneously. Establish and clearly communicate the “kill date” when the old system will no longer be used. A transition period gives users an opportunity to ease into using the new system and solve any glitches that might impede business operations. During the transition, the project team ensures that business operations are fully functional on the new system.
  • Exit strategy. At a predetermined time, operations are handed over to the business unit that will own the systems. Generally, the project team stays on retainer for an agreed amount of time to ensure a smooth transition to the new system.
  • Measurement and feedback. Every properly executed project establishes metrics and measurements during the planning phase that are used throughout the duration of the project – and continually after the project goes live. This helps establish baselines for future projects, determine ROI of the project and provide valuable feedback on how future projects can be improved. Additionally, it helps surface any new (possibly unforeseen) requirements that can be added to the system in future scheduled releases and updates.
  • Stakeholder communication. Post-go-live, communication and training are critical to ensure proper adoption of the new system and processes. Solicit feedback from all stakeholders to close the feedback loop, help improve future projects and increase user adoption.
  • Ongoing training. Don’t forget that as new users come onboard, they need to be trained. Additionally, make refresher training and training for updated system features available to all users. Factor training costs into ongoing cost calculations for the new system.