“Quite often people think that maintenance is just finding and fixing bugs, but it’s more than that. It’s also about keeping things updated, about enhancing existing features, and it’s about building out new features. It’s about ensuring your site/software continues to evolve and grow instead of just standing still. In technology, you’re either getting better or you’re falling behind. Standing still isn’t an option.”
Software without maintenance is like buying a car with no budget for gas
Thinking of starting a maintenance program? Picking the right number of hours can make a big difference as to how your project works.
Types of Maintenance Budgets
I’ve done a number of maintenance programs and each one is a little different, however they fall into one of three buckets; no hours, few hours, lots of hours.
No Hours or Low Hours: If you choose to allocate no maintenance hours, meaning you just call when you want work done, or if you have very few hours, the main disadvantages you will encounter are loss of knowledge, access to specific developers, and an impacted timeline.
Maintenance planning that keeps a team together: Ideally, one developer would be on your project to help with all future fixes. Having a developer with background on the project, code, and familiarity with client relationship is beneficial. However, those developers are valuable. They will get assigned to another project if they aren’t busy and they will become unavailable for your unexpected project.
Proper planning will maintain development efficiencies: When you lose the developer, you also lose some of the knowledge. We’re still a team and still transfer knowledge form one developer to the next, but switching developers can reduce some efficiencies. We all do our best, but the new developer still has to learn all the ins-and-outs of the code.
And then there is timeline. If we can’t plan for your maintenance changes, you will have to wait until a developer becomes available. That could be a few days to a few weeks. It all depends on developer availability and the complexity of the changes.
Planning For Success – Keep The Bucket Full
If you have a good amount of hours in your maintenance bucket, it’s easier to keep a developer on the project, retain knowledge, and plan for the work.
I’ve been working with one client for about three years now and I continue to lead the maintenance project, which is supporting the sites that we created. Every time they ask for something I know the project history, I know what we’re talking about, and I know which developers actually built individual pieces of the site. Knowing all this makes it much easier to understand the request, estimate, and execute.
This client also has a good bucket of hours, which helps me plan for changes. I know that – based on the client budget per month – I need to spend X hours per week. Not only does this help me plan for development, but it also helps with setting expectations for the client. Our turnaround time on requests is usually a few days. We’ve gotten ourselves into a groove and it works well for the client and the rest of the team.
What’s a good number of hours?
That’s a good question.
- How many changes do you plan on having?
- Do you think you’ll have some minor changes and updates?
- Do you think you have some features you’d like developed during your maintenance program?
- Are you thinking of a handful of changes per month or do you have a long list already and it just keeps growing?
It all depends on how much work you want done each month and how fast you want to get things completed.
For example, if you’re thinking 40 hours a month, one developer can plan for about six hours per week. When other projects come up, that developer can safely plan for both projects. However, six hours per week also limits the amount of work the developer can get completed. More complex tasks may take a few weeks to complete.
Wait, six hours per week is only 24 hours a month. What about the other 16?
Where most maintenance plans might fall down – “Where’s the QA?”
Another thing to consider when setting up maintenance hours is that the hours are not all development hours. You have to have some time for project management and QA. There will be phone calls, and email communications, status reports, and we’ll want to run any change through QA to help ensure we didn’t fix one thing and break another.
Quite often people think that maintenance is just finding and fixing bugs, but it’s more than that. It’s also about keeping things updated, about enhancing existing features, and it’s about building out new features. It’s about ensuring your site/software continues to evolve and grow instead of just standing still. In technology, you’re either getting better or you’re falling behind. Standing still isn’t an option.