CHAPTER 7
Cost Estimate
How much will your maintenance effort cost annually? That’s not an easy question to answer. But the answer is needed for several purposes:
• To communicate needs to IT leadership. IT leadership needs accurate information about how much of its overall budget is needed for each maintenance area.
• To communicate to the business customer. An accurate maintenance costs estimate will be important to the business customer during discussions about the SLA and the cost. The cost estimate will give the business detailed information about the services so that, if it wishes to, the business can easily revise its service request to reduce the cost.
• To validate your current cost level. Current maintenance teams will already have a track record of costs. But are those costs still valid? Maybe the cost should be lower because of past improvements. Maybe the cost should be higher to fund improvements to service levels or cover new scope.
• To determine risk of maintenance being outsourced. Current maintenance teams may have priced themselves too high, which might make outsourcing seem to be an attractive option—even using only local outsourced staffing. Knowing how the team’s cost compares to these local alternatives can help keep the manager motivated to improve and lower costs.
Effective estimating is an important task. The manager of maintenance is responsible for providing quality estimates. This chapter is designed to help with that task.
Labor is the most difficult item to estimate, so we will cover labor first. In most cases, labor is also the largest cost for maintenance and an area in which costs can be reduced by continuous improvements such as eliminating low-value process steps in order to decrease overall effort, and then reducing staff. Estimating non-labor costs such as licenses, hardware replacements, and new tools is fairly straightforward, because most of these costs are known. Non-labor estimates are covered later in this chapter.
Labor Estimates
There are many reasons for good estimates, as has been previously discussed, but we are now back to the question of how we can estimate. Traditional bottom-up project estimating based on a WBS will not work well for maintenance. The problem is that you would need to make assumptions about the quantity of each service that will be requested throughout the year. You could use the SBS activities from the previous chapter as a starting point, but you would still have to estimate how much time would be spent on each activity. There may be no accurate way to estimate this, and this approach can’t be relied on in all cases, especially when you don’t have good information based on past experience.
Fortunately, there are other approaches you can take. This chapter presents four approaches for estimating the maintenance effort. Not all of them will apply to a specific situation. The variables are:
• If the maintenance team is new or existing
• If the maintenance team is supporting vendor package systems or custom programs
• If there are similar maintenance teams in your company or if there are external companies you can use for comparison
For best results, use a combination of the four approaches, so that the estimates can be compared and averaged.
These estimates are at a high level. Our unit of measure for labor is not hours but Full-time Equivalent (FTE), which means one person working full-time over a specified period of time (week, month, year). Your team members can share responsibilities, but you will have to account for 100% of each team member’s time (you cannot roll members off your team and then roll them back on).
For any of these approaches, start by listing your assumptions about the service that you will be delivering. Will enhancements be made on the system? Is 24-hour support needed? Documenting the assumptions will help in communicating with others and will increase the likelihood that the assumptions can be proved or disproved. These assumptions should already be clarified in the SLA. See Chapter 5, “Service Level Agreement,” for more details.
The following sections describe the four approaches. These approaches are ordered (most to least) by how much information you have on the cost of maintenance.
Approach 1: Current Team
The easiest approach to the situation is when you are taking over an existing maintenance team. Historical information will show if the team size is too small, too large, or just right. This historical information may not be well documented, so some investigation may be necessary. You can make adjustments based on this information, taking into account any change in scope during the past.
Obtain and document as much historical information as possible to justify the team’s size. Information about demand for service in the past can be found in a variety of sources, such as past work records. The best source, however, is the current membership of the team.
Create a table similar to the one shown in Figure 7-1. List each team member’s responsibilities at a high level so that you can see where time was spent in the past. This can be useful for recognizing labor-intensive activities that may not be easily seen otherwise. See Chapter 6, “Service Breakdown Structure,” for more functions.
Approach 2: New Maintenance Team Established after a Project Team
If you are establishing a new maintenance team, there may still be current information on how many people are needed. That information might be obtained from the development project team that delivered the system.
The project team will typically maintain the system for a short time after it is placed into production. You can base some of your projections on what the project team experienced while maintaining the system during that initial period. Use Figure 7-1 to list the project team members and their maintenance effort plans for the period immediately following the deployment. Even before deployment, the project team can estimate percentages for this table.
Figure 7-1: Current Team Table
If the estimate comes in higher than upper management wants to accept, you can show decreases in staffing at six months and at one year after maintenance starts. Doing this can make sense when a system is new and there is the usual initial high demand for services. When these initial needs are met and you have time to improve the team’s operations, you can expect to require fewer people on your team.
This approach can help mitigate uncertainty about how the new system will perform and can ensure that there are enough team members to help users who are not sufficiently trained on the new system. This approach also means there are enough team members available to fix defects in the new system.
Approach 3: Service Breakdown Structure
Whether the system is new or already exists, you can use the SBS to estimate labor. Create an estimate based on the categories of workers. Even though you can’t estimate each task in the SBS outlined in Chapter 6, “Service Breakdown Structure,” using the SBS can still be useful.
Review the SBS for your maintenance effort. Is there any task that you know would take one or two full-time people to perform? What tasks can be combined and covered by a full-time person (FTE)? Even though the answers to these questions will be highly subjective, they will be based on your review of every type of work that may arise during the year.
To use this approach, you must already have an accurate SBS that was developed for other purposes. After you answer the questions using the table in Figure 7-2, have some of your knowledgeable team members or coworkers informally complete similar tables. You can use their estimates to validate your cost calculation, or you can average them and then create a single estimate.
Approach 4: Benchmark
Whether the system is new or already exists, you can benchmark with other maintenance teams. You can do this yourself, or you can use a research company such as Gartner, Inc., to help. This approach is very practical when your company implements a vendor’s packaged system that has a well-established client base. Ideally, you will find companies using the vendor’s system in implementations that are roughly the same size as yours. The vendor can provide the references.
To a lesser extent, benchmarking can be used for customized programs. You can use this approach internally in your company by comparing your services to maintenance efforts of other systems (customized or packaged) that are roughly the same size as yours.
In either case, you need to determine the factors that drive the size differential of the other companies’ maintenance efforts and multiply them by the number of people on their teams. Figure 7-3 lists factors to consider when benchmarking. Consider these factors and add or remove factors as needed.
Next, use the factors to rate other companies’ maintenance teams, your company’s internal teams, or both. When you have three or more teams that have maintenance factors similar to yours, you will be able to determine a multiplier of how many times bigger or smaller their base is compared to yours. You can then determine how many people you will need to maintain your system.
This approach differs from the others in that it doesn’t provide you with a breakdown of the type and quantity of skill sets you will need. Benchmarking does not provide a detailed estimate at the task levels. It does provide an overall picture of the number of people you will need on your team. To obtain additional information, you can benchmark to include a further breakdown of skills (e.g., programming, database administration, and testing), but you will still be left with a high-level view.
Figure 7-3: Benchmarking Factors
Non-Labor Estimates
There are other categories of expenses to consider besides labor. We will group all of these categories together and refer to them as non-labor, since they are more straightforward than labor. Figure 7-4 provides some of the categories. As with the approach you take to developing the labor rates, you will want to consult with knowledgeable team members or peers to review your list so that you can see if you are missing any categories.
You should have a list of all the software needed to run the systems. This list should also include any software tools that your team will use to monitor, troubleshoot, and fix the system. The cost of these software tools is simply a part of the cost of doing business, and careful budgeting and payment of license costs must be viewed by your company as a critical ethical and legal responsibility.
Figure 7-4: Non-Labor Expenses
Don’t forget to determine if each category is capital expense or operating & maintenance (O&M) expenses. The categorization of capital and O&M is needed for your company’s correct accounting for tax purposes. There are some general rules, but it is best to talk to the appropriate person in your company to see how items should be classified.
Long-Range Plan
The last item to include in our discussion on estimating is long-range planning. Planning for the next year is vital for both your IT team and for your business client. But a longer view that takes into account when systems will reach end-of-life status and need replacement is also important. The projects that are set up as replacements are usually quite expensive endeavors and should be identified years before they are needed. Rolling up all maintenance teams’ Long-Range Plans will provide what IT management and the business customer need to effectively plan the future project portfolio.
You need fewer details for the Long-Range Plan than you need for estimating and budgeting for the next year. Just list the projects and their associated costs. But it is still advisable to break down the total cost of projects into their capital and their O&M expenses.
Figure 7-5 provides a simple template for a Long-Range Plan. The Long-Range Plan is basically nothing more than a list of projects. This plan makes the projects’ start and end dates clear because of where the expenses are listed. Multiyear projects will have expenses in multiple year columns.
One of the simplest types of projects will be life cycle maintenance. The tasks involved include software upgrades or replacing servers that have reached end-of-life status. In most cases, such projects require little labor, but they can have a notable capital cost.
Other projects will be more involved than life cycle maintenance. These projects will be established to add new functionality or replace an entire system.
As we have already stated, the Long-Range Plan is for project work. Alternatively, the maintenance team’s costs could be included in the Long-Range Plan as one row. Doing that could provide a broader picture of the total cost of the systems. It’s also possible to plan a project with a view toward lowering the ongoing maintenance effort, so the Long-Range Plan could show the resulting decrease in maintenance cost after this type of project is completed. Whether or not to include maintenance team costs should be decided by whatever convention the entire IT department uses.
Staffing for projects will differ from company to company. Some use dedicated internal project staff, while others use contractors, or even the maintenance team. You have a unique option if maintenance staff will be working on projects year after year. If this is the case, then the maintenance team could be staffed with more people than are budgeted to perform maintenance work. The unbudgeted staff would work on the various projects and charge their time accordingly. There is a risk of maintenance going over budget if the projects are canceled; however, the manager can mitigate this risk by carefully managing the staff and always having the next project identified so staff can start on that project if the current one is cancelled. This is a good technique because it reflects the true drivers of the business cost. An additional benefit of this technique is that it allows team members to vary the type of work they perform.
Putting It All Together
As you can see, there is no perfectly accurate, one-size-fits-all, scientific approach to estimating maintenance team size and cost. But armed with one or more estimates from the preceding approaches, you should be able to present your conclusions about how large your team should be and how much it should cost.
False assumptions lead to inaccurate estimates and staffing levels. There is also the risk, if the staffing levels are too high, that the business will be paying too much and not know it.
Whatever approaches you use, be disciplined enough to track your estimated categories monthly and forecast where you will be at the end of the year so that you can prove or disprove your estimates. You will then be in a much better position to plan staffing increases or decreases for the following year. After you have the data and apply improvements, you can decrease the team size and look like a hero to upper management. But ground your decisions in facts or you may look like a fool to overworked team members.
Combine your estimates into one spreadsheet or presentation. Take your FTE estimates and multiply by your internal labor rates or contractor rates, whichever applies to your situation. Then include your non-labor estimates. Present this to the business. At some point the business may want to see your justification for the cost of maintaining its system. Having multiple ways of calculating the effort will show that you conducted due diligence, and you may thus experience less scrutiny and questioning.
It is important that the cost you build for maintenance has a cost to the business. A situation where the cost approaches zero will translate into an almost infinite demand for your services. When the business provides funding to the maintenance team, they will be more interested in controlling their demand for services.