So you’re finally in production with your package software. Users are giving feedback, the system is stabilizing, and your program team is starting to wind down. Now what? Work on your solution never stops, and these key topics have to be addressed: Maintenance / Support and Upgrades / Patches. Now, when compared with custom-coded application, these topics require some different thinking. First, by leveraging a package solution, your software vendor takes on the burden of providing you with patches and upgrades for your base software. They often can play a role in helping tune your application as well. Finally, your software vendor will almost always have escalation paths for complex support issues as they arise.
You can break down your RUN state in the following way: Business Enhancements, Performance Tuning, Support Services, Software Updates, and ongoing Program Support.
Business Enhancements
By the second day (if not the first), you will start to receive requests for business enhancements for the solution that just went into production. These could range from minor tweaks to missed requirements. The work efforts can also range from a few hours to more than 30 days of development. As these requests come in, you will need to set up a RUN state team that can move ideas through the software development life cycle and get to production on a daily, weekly, monthly or quarterly basis. Most importantly, you need to plan for a period of continuous development to address key enhancement requests immediately after going live. Ideally, your organization is already operating in a model of continuous development.
“Packaged software does a great job keeping up with regulatory and security issues and usually pushes these code updates via Notes, Patches or Hot Fixes.”
Performance Tuning
No matter how much performance testing was performed during the build of the package solution, you will have unexpected results when you hit production. Being prepared to have engineers at the ready to tune the infrastructure, database, middleware, and UX layers of the application will be critical to a good experience for your end users. Don’t plan on just turning this responsibility over to your support teams, but rather retain this in your engineering organization: the engineers that built the solution are in the best position to advise on how to tune it. This function is also something you will need to turn to after every major release or upgrade.
Support Services
Support, in this context, is defined as Level 1 and Level 2 support for both end users and the application itself. This typically means that they focus on usability issues for users who may not be trained up on the system yet, as well as data, integration or performance errors. What support organizations should not be doing immediately after the system goes to production is try to troubleshoot problems (i.e. recurring incidents) or fix “Missed Requirements.” Support should be focused simply on break/fix and consistency of service. Level 3 teams (i.e. engineers that implemented the system) should be on point for problems or missed requirements.
“Don’t plan on just turning this responsibility over to your support teams, but rather retain this in your engineering organization: the engineers that built the solution are in the best position to advise on how to tune it.”
Ideally, Level 3 teams are embedded with the Support teams during the first 90 days post-production. This will help with knowledge transfer and incident resolution as well as quality. If the Level 3 teams are on the hook for support in the first 90 days, they will have motivation to ensure quality in development leading to a stable production implementation. Finally, before full transition from the development teams to Support, there should be pre-defined criteria that must be met for the system to be turned over. For example, zero high incidents for 4 weeks running or zero open high problems.
One point to note is that many software vendors have programs that will evaluate the quality of your implementation and flag areas of concern. You can leverage these programs to hold your organization and your implementation partners accountable for the quality of their implementation.
Software Updates
Patches, Hot fixes, Upgrades, and Notes are all things your software vendor will push out. Sometimes these are on a quarterly basis, but with the pace of technology change and security, these can be as frequent as weekly. Packaged software does a great job keeping up with regulatory and security issues and usually pushes these code updates via Notes, Patches or Hot Fixes. These tend to be relatively straightforward to implement and require minimal regression testing if any at all.
Upgrades can be more complex and typically are delivering major functionality changes. In most cases, you will need to plan for full regression testing, which usually means spinning up a full project to manage the upgrade. In particular you will have to pay attention to your integrations, reports, security, and any customizations you may have made during your implementation. Taking an end-to-end approach to an upgrade initiative will be imperative to success. This means starting with what changes the users will experience, and ensuring data / master data is not impacted by the upgrade.
In summary, Package Software can provide a lower cost, faster to market approach to enable many business capabilities. Package Software brings built-in innovation and continued development, security and regulatory controls, tested code beds leading to more consistent system performance, and increased data quality.
Final Installment
For most companies that choose package software, they have multiple vendors that assist them in implementation. The vendor ecosystem often ends up being the software vendor, a system integrator responsible for the bulk of the implementation, a RUN state vendor, and a smattering of niche vendors or staff augmentation providers. Our supplemental article on Vendor Management will dig into how to best leverage your vendors to get the most out of them.
Links
The Case for Package Software
The Case for Package Software, Part II
The Case for Package Software, Part III
