Support and Maintenance
Custom Software Support and Maintenance (Step 4)
Once upon a time, off-the-shelf and custom software applications received major upgrades every two to three years, with minor maintenance updates and patches issued a few times each year. Those days are long gone – stuck in the back of the storage closet between the stack of dial-up modems and dot matrix printers.
Between evolving business needs, competitive realities, IT needs following mergers and acquisitions, corporate reorganizations, integrations, and new security vulnerabilities, custom software support, administration, and maintenance is now a continuous, non-stop initiative.
Following process and strategy, design, and development, end users of your custom software will inevitably need help desk support by well-trained staff that’s familiar with your custom software application.
For anyone that’s used software of any kind, you’re likely familiar with what a great software support experience looks like as compared to a not-so-great support experience.
You know the drill. End users with questions will reach out either by phone, live chat, or online ticketing to get help figuring out the answers to their questions.
1. Help Desk Incident Resolution
Help desk staff works with end users to answer how-to questions, providing some ad-hoc training as needed. Many times, the software support technicians will troubleshoot errors with users to help on the spot. Sometimes, a support technician will need to research an issue further or get assistance from a more seasoned colleague.
Great help desk staff knows just how important it is to continue communicating with end users while an incident is being worked, assuring users that progress is being made when an incident can’t be immediately resolved.
Other times, the support technicians may determine that a particular incident needs to be escalated to the development team. When that’s necessary, the support technician again remains the single point of contact, protecting end users from the all-too-common runaround and finger-pointing frustrations.
2. End User Support Compared to Management Support
Many times software support needs will vary depending on whether the request is coming from an end user or a manager.
Often end users require support because they are having trouble logging on or learning how to use the software.
When a manager contacts the help desk, it’s often because some aspect of the software is not working as expected. So the help desk technician works with the manager to determine whether there is a bug or whether the question has more to do with a limitation of functionality.
Most custom software support plans include some development hours. So if the missing software functionality is an issue that can be addressed fairly easily and fits within the budget, the support technician will work with development resources to get the request implemented within a few days.
If the missing functionality is more involved, such as perhaps developing a new module, the support technician will coordinate with their software development project manager to get the client’s manager a price quote for the new functionality.
Administration and Maintenance
A typical custom software development project is governed by a business requirements document (BRD), a collection of descriptions of processes and screenshots of prototypes showing how things will work and which describes the project requirements. After the project launches, epics, features, stories, and tasks are created by a business analyst. This type of breakdown is part of an Agile or Scrum methodology which makes project management more predictable and efficient.
1. Organizing and Prioritizing Capacity During Development
Overall progress can be measured and tracked in a variety of ways. One great tool for doing so is a burndown chart; which shows graphically how much work is left to do compared to how much time remains. A burndown chart can be very helpful with forecasting when all of the project work will be completed.
In this context, every task is assigned an estimated number of hours. And both individual developers and the project as a whole have a certain capacity for additional work.
For example, if there are 10 people on the development team and each developer has 40 hours per week of capacity that can be spent on a project, then there are 400 hours per week of capacity across the team.
Development is usually organized into sprints: two to three weeks in length, for example. And the burndown chart gets updated daily, so all stakeholders know if the project is on time, if the estimates were done correctly, and if capacity is burned down efficiently.
2. Organizing and Prioritizing Capacity During Maintenance
For a custom software project, ongoing administration and maintenance are handled in a very similar manner to how capacity is managed during the development phase.
Clients buy a certain amount of monthly development capacity that’s needed for new features and support. This way clients ensure that they have the developers available when needed.
Whenever possible, the developers who built a particular project are the best candidates to handle ongoing maintenance.
Project managers and business analysts are almost always maintaining a backlog of features that are not yet implemented. During maintenance, new features are added and bugs are fixed which are done in order of highest priority.
Clients and their project managers work together to prioritize which tasks get included during administration and maintenance capacity, similar to the idea of filling up a shopping cart.
To prioritize certain kinds of support tasks, clients can literally drag items into their shopping cart to fill up their cart for specific administrative and maintenance items.
Ongoing Project Management and Project Support
Nearly all companies that invest in custom software will also need some kind of ongoing project management.
This project management should be very familiar, and quite similar to, following on the heels of a completed custom software development project. The project management will just be at a slower pace post-launch, with reduced development capacity — and to most clients and developers alike, this kind of ongoing project management will feel less intense, compared to the hyperintense project management typical during software development.