Key Initial Deployment Success Factors

Through a multitude of deployment projects spanning more than 10 years, the Kinaxis professional services team has developed a list of our key deployment success factors. We share these with our customers during the initial RapidResponse project kickoff, which generates all kinds of excitement. Most of these factors are not rocket science and are applicable to software deployments in general. The probability of a deployment project going off the rails increases dramatically, however, when these factors are ignored. Obtain executive sponsorship – Projects need a true leader who can navigate the political landscape and communicate the vision of the solution and the overall benefit to their organization. They are the last point of escalation…“the buck stops here”…within the customer organization, assisting with issues that have bubbled up from the project team. Define the business value objectives – Determine what you are trying to achieve from a business aspect, and ensure these objectives are realistic. Set expectations effectively with the project team – Confirm that everyone is on the same page as to what they can expect during the deployment project, and define expectations surrounding the outcome. Put the right people in the right roles – Review the skill set of the people working on the project, as well as their availability to support the project to ensure success for the entire duration. Communicate effectively, early, and proactively – This is particularly important when it comes to expectations and progress on activities, especially in deployments where supply chain partners and CMs are involved. We live in a high-paced 24/7 techno-blogged, crackberried, twittersphered, clouded community – use the tools to facilitate better communication. When in doubt, go “old school,” and pick up the phone and/or meet face to face. Manage the scope during the deployment and assess the impact to changes in scope – What is the impact of this change in terms of schedule, budget and resource load? Is this change a “must have” or can it wait until after the initial deployment project is complete as a phase 2 enhancement? This is the “walk before you can run” approach. Define the plan and expectations for standard product training sessions – Will the customers be ready to take the reins of the solution once the deployment is complete? Will the customer feel comfortable reviewing log files to ensure successful data load, resolve data load or transfer error? Will the customer be familiar with control tables and able to modify these, if required? Will the customer be able to create simple workbooks and resources, or to create users, groups, and provides access? Create an education and roll-out plan for the end-user community – Any deployment can result in shelf-ware, in which the end-user community chooses to continue doing things the way they have always done them despite best efforts: “Why fix when things are not “exactly” broken” or “What is wrong with using Excel?” Changing work habits and process re-engineering are always a challenge, but this can be overcome with a well-thought-out education and roll-out plan. Once end users experience first-hand the robustness of the product, fully configured to their requirements coupled with current ERP data, then this becomes a very easy transition. The key is to involve the end user community in the process early on; gain feedback in UAT and ensure that the workbooks and resources are something that they can actually use. Data, Data, Data – Strength and credibility is based on fully validated and refreshed ERP data. If this data is stale, incomplete, or has known issues, then this will be transferred (garbage in = garbage out). User adoption is key and this is influenced by the data they see coming out. If the data is not credible, user adoption will be weak. Data validation, both input and planning, is key. Do you have anything to add to the list? What lessons have you learned during deployment projects?