​Project Deployment Success: What to Know

5/22/2017
By Albert Chapman-Layland, Principal Consultant at Navigator

Deployment isn’t sexy. That's shocking, I know. Nevertheless, project deployment must be flawless.  Like any essential part of a project, a successful deployment can make or break a project's long-term future. The challenge with deployment is that you have only one chance to do it right. Deployment of business-critical applications must be completed on time so that the business users can perform the tasks that the project is enabling or streamlining. Only when deployment is complete can the project begin to provide the financial, compliance, strategic, or other benefit envisioned long ago when even the business case was but a dream. 

Deployment is not a black box: sound, proven project management techniques can be applied to manage risk to the project and ensure a successful deployment and uptake by the business.  

For our purposes, I'll define "deployment" as follows:  the sequence of events and changes performed to a production landscape culminating in releasing a new or changed business system to end-users, along with a specified period of intensified support for issues (post-production support). The "cutover" is the series of events that occur during a time of limited production availability or a full black-out. Here are three recommendations:

Work from a battle-tested plan

A good rule of thumb to work from is that no task should be done in a production environment for the first time. What does this mean? Even with the creation of the first test environment, work from a plan. 
  • Conduct a series of deployment tests as environments are built. At the time of the first deployment test, some parts of the plan may be very high-level, but all steps that are known at the time should be articulated and sequenced. Drive out as much detail as possible even at this early stage. 
  • If there are tasks that can't be done in a given environment, capture the tasks and mark them as not applicable for execution. There will be tasks that cannot be performed in a test environment, for example, many organizations have rules against turning on SMTP servers in a non-prod environment. It may be that not all production environments have test instances. Whatever the reason, ensure those are documented are subjected to cross-team and cross-organization scrutiny.
  • Begin to develop the specific procedures that will be used for verification, both by the project team and the business owners of the systems who must ultimately validate and sign-off on the results. 
  • Use and refine a process for collecting and incorporating changes and use that from the very first deployment test. 
  • Ensure that the resources who will execute a task in production perform that task at least once in a test environment with the authorizations they'll have in production. Identify backups for every resource executing a production task. Ensure processes are documented so that if a backup has to step in, he or she can perform the task. 
  • Strive to keep tasks to less than two hours each. If there is a task that can’t be broken down lower than that, insist on check-ins and metrics to show progress.

Begin with the end in mind

Begin with the end in mind is a fairly well-known piece of advice for personal self-improvement. However, it applies here as well. Deployment needs to be considered throughout the project planning and execution. That doesn't mean that on day one you break out an MS Project Plan or spreadsheet to start gathering tasks and times. What it means is begin thinking about deployment questions at the outset:  
  • How will open transactions be handled? Will they close out in legacy or be migrated to the new system? What processes are needed for keeping the systems in sync?
  • Is a full production outage necessary, and what are the constraints around that? For example, many businesses choose to manage major financial system changes at year-end. That said, what is the impact to year-end close, etc., from having a systems implementation? 
  • What deployment tasks are not required to take place within the cutover? For example, it is beneficial to stage master data before the cutover. This allows time for the business to check the data, see the configuration that has been deployed thus far, and to correct unexpected issues. It also shortens the time business functionality is unavailable and mitigates risk during the cutover. This is easier for a new system deployment, but it can and should be done for deployments in a production environment that is live. Of course, there is a cost to the benefits. Thus, you must consider how to do necessary code and configuration migrations to support data migration and, in the course of testing, confirm that the changes do not harm existing production functionality. Process and objects need to be developed and practiced that keep the project and legacy systems in sync, whether it is a data change freeze or automated or manual dual-entry.  

Have realistic expectations

Now, you may point out that I said "deployment must be flawless". We know that isn't realistic--there will be issues. I'd draw a distinction between process and result. 
  • The team must strive for a flawless deployment result--on-time, all expected data and functionality available and key processes checked. However, the execution itself will encounter unexpected challenges. There must be adequate contingency built into the plan to allow for identifying, vetting, and executing corrections. Team members must be empowered to raise issues and have them worked transparently. 
  • In case of emergency, rollback points and the corresponding rollback processes must be identified in advance. Mission-critical features must be identified in advance so that there is agreement about what triggers extending the cutover or rolling back. 
  • Managing stakeholder expectations applies to post-production support. The criteria for assigning priority to issues must be consistent with the standards for other production issues. It is easy to let the "biggest" issue at any time become critical. However, your organization has a definition of what a critical issue is. Use those and other tools to manage external stakeholders and your team.  

Conclusion

Deployment is highly complex and can be challenging to get right. This is where Navigator Management Partners can help. We have managed system deployments for many customers, including large utilities, multi-national pharmaceutical distributors, universities, and government agencies. We've seen ERP (HR/FI and manufacturing/distribution) and Business Intelligence, on premise and cloud whether PaaS or SaaS. We can share the lessons learned with you to help ensure that your next project, and future projects, are deployed successfully to the business with uptake on day one.  
Navigator Management Partners
Navigator Management Partners was founded in 2001 to offer organizations a different kind of management and technology consulting partner. Our team is comprised of top-performing consultants with years of experience in solving business challenges by implementing information technology and management solutions, including Strategy, Program / Project Management, Organizational Change Management, Business Intelligence, Business Analysis and Process Design, Testing and Deployment, Solution Architecture, and Software Solution Selection, including cutting-edge, cloud-based solutions. Through collaborative partnership, we advise clients on solving tough business challenges in ways that improve operational performance and drive sustainable results.

Offices

Sign up for our newsletter