Chris Tan:
Welcome to webinar Wednesday, a new webinar series hosted every first Wednesday of the month. Before we begin a few housekeeping items. The webinar will be recorded and shared on our blog and our YouTube channel in a few days. For those of you dialing in today the slide deck will be shared via email immediately following the webinar. We also have a moderator standing by to take your questions so please feel free to submit those via the go to webinar interface. If you have any ideas for additional webinar topics or something you would like to see presented please let us know.
This is the last webinar for today. On June 6th we will review our RPI Lawson COM object integration, AP agility for Kofax KTA and the OnBase Approval Manager. Please visit www.rpic.com/webinars to register online.
My name is Chris Tan and I’m a Senior Consultant here at RPI with six plus years of experience delivering ECM solutions primarily focused in the healthcare space. I reside here in Kansas City and I am a husband and a father of two.
Sean LaBonte:
My name is Sean LaBonte. I’m a Project Coordinator with RPI. I have managed multiple client projects including upgrades, heath checks and new solution designs. While I don’t happen to be a husband or a father of two I do happen to be the Kansas City’s most eligible bachelor.
Today’s agenda we’re gonna cover a little bit about us, RPI and how we go through upgrades and which upgrades we have gone through. Why some businesses do upgrade, planning and upgrade project from a project management standpoint and Chris will kind of go over upgrade and delivery and cutover. At the end we’ll have a Q and A segment as well
Chris Tan:
RPI consultants is a comprehensive professional services organization with over 18 years of experience designing, implementing and supporting ERP, ECM and data capture solutions.
We have roughly 80 full-time employees based out of our office locations in Tampa, Baltimore and Kansas City. We offer many different services and specialize in product partnerships with companies like Hyland, Kofax and Infor.
In terms of RPI and upgrades we have performed over 36 upgrades this past year. Upgrades can be done on your own, but we are typically engaged to advise due to our often repeated experience with these types of projects. Upgrades can be big or small, largely dependent on the scope or timeline. Our services include offering ad hoc support and advice for internal staff, upgrade training and most common facilitating the entire upgrade project.
Now we will discuss various reasons to upgrade your environment. There are a lot of reasons to upgrade an enterprise solution including the opportunity to take advantage of any features and functionality.
Software end of life is probably the most common reason to upgrade. Customers wanna stay supportable with the software vendor. New features and functionality are also a major reason to upgrade. This includes end user features, new clients and platform updates. Fixing bugs and ending user frustration is also a common reason to upgrade. Finally, software compatibility with third party applications as well as staying on the cutting edge are also reasons for an upgrade.
In terms of types of upgrades vendors often make the distinction between a patch low effort minimal changes and an upgrade, high effort, significant changes. This distinction doesn’t always make sense as some of the patches take just as much work and testing. An in place upgrade is upgraded in the application on an existing hardware in your environment. A hard cutover is creating a net new environment and transitioning your database and documents to this upgraded environment. Lastly, a phase rollout option is supported in software such as OnBase where not all clients and components have to be on the new version.
Sean LaBonte:
Okay. Now that we’ve discussed why to upgrade let’s go over the next steps where we can take a high level look at some of the keystones of planning for a successful upgrade. You always wanna start out with building your foundation. Either give yourself a clear vision behind your efforts by defining your purpose of objective statement. This is going to give you your requirements and to find the why for your end users. This is gonna start leading you into developing a high level project plan where you wanna start building out some of your phases for example. Right now, you’re in planning. You’ll move to a test server, UAT, Go-Live. Just some very high level overview there. From there you can start going through each one of these phases digging into more documentation, more detail. As you revisit each phase it’ll be kind of an iterative process to identify and allocate some of your resources, your stakeholders. This also includes any outside vendors of course.
As you move through that you’ll speak with them, allocate your resources and build out a little estimate for each responsibility to develop your timeline. Now, first schedule is usually pretty optimistic, but obviously necessary. You need to try to maintain realistic expectations to communicate with any of your stakeholders for these requirements. Point being, really be up front with the nature of your goals to say on course throughout your project. As you dig into your documentation you may also be aware of some of this low level requirements such as any licensure. You’ll need to assess what you currently have, what you need, what you need to get rid of and then any technical or hardware requirements. Of course, follow the specs that are in your documentations as well.
One of the biggest points of frustrations for any upgrade is just something simple like under spec server, for instance.
While you’re focusing on that technical documentation, building out your schedule don’t lose sight of any of your established internal processes in your project schedule. For example, some organizations may have a change management procedures where any changes to your production server need to go through change request. You’ll want to build in lead time for these changes. That way you can address any change requests, any documentation that needs to be submitted well ahead of schedule.
This also includes any security or access requirements. Access speaks a little bit more to any outside vendors. Security’s going to be, let’s say for instance if you have a utility that’s gonna help you copy over from production to your test environment. You wanna make sure your security team is on board with all the tools, everything you might be using and we don’t suffer any unnecessary setbacks throughout your project. Plan for any downtime. Some environments need to up and have end user access 24/7. In this case you need to address when copy over may be, when you need to have users out of the system. This may be on a weekend for instance. Just plan ahead of time, make sure you document and add visibility and a responsibility to your plan. Of course, once you do this, this leads you to developing a communication plan.
Everyone can agree great communication is vital to any successful project. It’s always preferred to over communicate than under. Defining your communication plan really comes down to creating a necessary dialogue between stakeholders that drive you towards completion.
Define your stakeholders first. This is gonna be anyone that’s directly or indirectly impacted by your project. This can be primarily focused on executive sponsors, functional/technical managers, end users, IT teams, any outside resources.
Now you’ve defined the who you need to define the what. Find the roles. Find the responsibilities. Address them to system admin teams. Maybe someone’s in charge of testing who’s going to come up with a training plan. Who has approval and sign off each one of your phases so you know you can move on to the next wave? Right.
Communication plan is gonna also be made up of maybe your weekly sync up meetings where you need to delegate your task to. You need to be aware of any overlap in responsibility as well. Clearly define who has what role, who has what responsibility. Also, define if there’s any capability gaps. It maybe prove worthwhile to your upgrade to wait a couple weeks for the right stakeholders to be engaged. Point is engage a diverse, disciplined and capable team for optimal results then use your deliverables to establish a method to ask questions, concerns or offer any critical feedback.
You’ll also be defining your scope through this process. You’ll want to complete a technical audit or your internal system, plan for any storage growth that might occur. Also assess if this new upgrade includes any new functionality. Does it eliminate any old functionality? Scope needs to be clear to all your stakeholders otherwise you risk derailment, timeline extensions and increased budget. Make it visible. Make it known. Then have clear sign off on all your design documentation. You’ll want to stick to the limits of your scope of the project. Keep your enhancements as a separate project. Then as you progress through each one of these built items of course build out your training documentation. It’s an upgrade obviously there’s gonna be changes. The earlier you start preparing material for end users, the better and the quicker you can move through testing, training and then of course into go live.
One of the last things we want to assess now that you understand the scope of your project is you can take a look at some of the risk that might arise. Plan accordingly, try to look towards the future and assess what might be some of the unknown qualities. Right at kickoff this is not when you start preparing for a project. You need to be ready to go right at kickoff and have all your responsibilities, due dates, timelines all assigned. You don’t wanna introduce risk to your project right at the very beginning.
Access can kind of go back towards third party vendors where you want to make sure that they have the adequate VPN, RDP access, admin server rights, software roles. Any of these if they’re not set up in a timely manner it’s gonna cause a timeline extension and of course an impact to your budget sometimes even.
One of the biggest things I can hit on here is having a proper testing plans and procedures. You need to develop your test scripts, your test cases for UAT. Make sure all that is signed off accordingly by your sponsor or whoever you have deemed of course in charge of it. Having an adequate testing plan is going to make sure that your go live goes smooth and thereafter. If you have any new features, functionalities, upgrade in other systems you need to account for any budget or timeline risk. Usually it’s gonna be advised to stick to the scope of your upgrade, separate these out to other projects. That’s the PM portion to focus on. Next will be the technical aspect that Chris will go over.
Chris Tan:
Now we will discuss the upgrade delivery and cutover process. There are a number of technical and business tasks that need to be completed to effectively upgrade a production environment with minimal disruption.
As part of our upgrade analysis we would review your current architecture, recommend in place replacements for end of life components, provide you with a technical architecture diagram that would adhere to our best practices, offer scalability and ensure smooth transition from your current environment to your new upgraded environment. We would utilize the latest and greatest supported software versions to maximize performance and functionality.
As part of the upgrade process we would built out your new environment in a pre-prod environment. We would stage a copy of your current database and documents and prepare the environment for user acceptance testing. Once all test plans have been successfully executed we would work with you to determine your go live cutover data and time.
As a best practice user acceptance testing is a crucial part of the update process. Businesses must have test cases prepared and this allows users to fully experience new features and functionality. We would recommend driving testing daily and to obtain sign off from various stakeholders regarding the completion of UAT.
At the time of cutover we would shut down your current environment and upgrade your database to align with your new application servers. In addition, any documents remaining in your current production environment would be migrated to the new environment. The updated database would be associated with the new environment and would be validated to ensure a successful cutover.
Thank you for attending today’s webinar. At this time we will open the floor to any questions you may have regarding the topics that we’ve discussed today.
Moderator:
Thank you guys. What are some tools that both of you have found in managing an upgrade?
Sean LaBonte:
Sure. One of the biggest key points to probably going back to like the communication process of an upgrade. You wanna find some central repository to kind of house your dashboard where you have your project plan easily accessible. This is of course gonna have all your responsibilities tied to it so you wanna make sure anyone can have full visibility to it along with maybe meeting notes. Make sure those are well dispersed. An issues log where you can track any issues that are known and need to be mitigated. Of course, maybe even an action item log where there’s sort of deliverables that need to be gone through.
Chris Tan:
From a technical standpoint, I like to use certain pieces of free software like Notepad ++ to review configuration files, XML files, INIs. I also like using a program called WindMerge to do a compare and contrast for files in the old convention versus the new. This also has the ability to do folder structure comparison for web service calls. Applications like Postman and Fiddler are some of the apps I use.
Thanks for the great question. We reviewed the topics at a very high level so if they’re any topics that we didn’t cover or items you’d like us to dive into greater detail, please let us know for future webinars. If you visit our webinars page you can register for upcoming webinars and you can also watch recordings from our past webinars. You can also visit our knowledge base, which has a lot of great content including free white papers, case studies, product demos and help articles. Thanks you for dialing in and we hope to hear from you soon.
