Key Points
- Viewing “operations as a service” as a fixed monthly cost that fits the current project’s needs and expands in line with the development budget is easier.
- Active development requires DevOps & SysOps, so an increase in development means an increase in DevOps & SysOps, with more monitoring, maintenance, and preventative measures in place.
- When active development decreases, the DevOps and SysOps budgets can be reviewed because there are likely to be fewer ongoing issues created from changing code, and stability can be more easily maintained.
- The amount set for operations as a service represents the minimum realistic time to keep the service stable, monitor regularly, apply security updates and patches, and benefit from the available expertise of the team.
- A well-balanced operations budget, or an increased budget that matches increased usage, compliance or development activity, is crucial to ensure the software is stable and that the operations team is ready to jump into action during emergencies.
- For Topvine-led projects, establishing these costs on day one and communicating them adequately to the client, explaining what they are being used for, and that they will remain in place long after the completion of any deliverables is crucial.
- It’s essential to review these fixed ongoing costs during each project step to match the client’s ongoing needs and budget accordingly.
- Establishing this baseline on existing or inherited projects can be challenging as clients may not understand they are essentially becoming a software development company.
- Separating the operations budget transparently and explaining what it is reserved for is crucial because including operations budget in the development budget directly leads to misunderstandings and unmet expectations.
The issue of deliverable based thinking for Operational roles
Deliverable-based billing and thinking can be problematic for operations roles, as there is often no specific deliverable to provide once the initial stabilization work is completed. This can lead to confusion for clients who may feel that nothing is ever truly finished, which is partially true due to the ongoing nature of the work.
In reality, these roles are focused on support, monitoring, maintenance, and prevention rather than delivering a product or service that marks the completion of a milestone or project. Similarly, applying deliverable-based thinking to other supporting roles, such as project management or other managerial positions, can create challenges in defining deliverables that make sense for everyone involved without diminishing the importance of these roles.
Rethinking pricing for Operations
It’s easier to view “operations as a service” as a fixed monthly cost that fits the current project’s needs and expands in line with the development budget. Generally, active development requires DevOps & SysOps, so any increase in development translates to an increase in DevOps & SysOps, with more monitoring, maintenance, and preventative measures in place.
Similarly, when active development decreases, the DevOps and SysOps budgets can be reviewed because there are likely to be fewer ongoing issues created from changing code, and stability can be more easily maintained. Reducing the monitoring and maintenance budget to a minimum is possible as long as there’s enough budget to retain experts who can jump in during emergencies and handle unexpected situations.
The amount set for operations as a service represents the minimum realistic time to keep the service stable, monitor regularly, apply security updates and patches, and benefit from the available expertise of the team. A well-balanced operations budget, or an increased budget that matches increased usage, compliance or development activity, may seem unnecessary to clients until disaster strikes. However, like an insurance policy, it’s crucial to keep paying for operations to ensure that the software is stable and that the operations team is educated and ready to jump into action during emergencies.
For Topvine-led projects, we establish these costs on day one and communicate them adequately to the client, explaining what they are being used for and that they will remain in place long after the completion of any deliverables. It’s crucial to review these fixed ongoing costs during each project step to match the client’s ongoing needs and budget accordingly.
Establishing this baseline on existing or inherited projects can be challenging as clients may not understand that they are essentially becoming a software development company. However, they generally realize the existing shortcomings with previous providers after communicating the realities involved in maintaining custom software. If there is a communication problem or the client cannot understand the necessity of these budget items, the relationship is unlikely to work.
It’s also a mistake to include operations budget in the development budget directly because it leads to misunderstandings and unmet expectations. Transparently separating the operations budget and explaining what it is reserved for is crucial.